1. Web前端站點有哪些功能測試的方法
有些測試方法的界限比較模糊，比如功能測試的同時會穿插一些兼容性和安全性的測試，以下列出簡單的一些點，可以參考下：
1、該頁所提供的功能邏輯方面有無問題；
2、各輸入項的合法性測試、輸入順序；(是否只做了前端的js驗證)
3、該頁許可權，既無訪問許可權的用戶能否直接訪問該頁；
4、不同瀏覽器下該頁的顯示；
5、該頁鏈接的參數是否可以修改，對功能的影響；
7、多個頁面打開該頁，進行操作，是否有不合法的影響；
8、網路環境異常情況下系統的處理；
9、頁面鏈接是否正確；
10、cookies測試；
2. 介面測試的測試點有哪些
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
測試的策略：
介面測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
評審測試介面文檔（需求文檔）
根據介面文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）
執行測試，查看不同的參數請求，介面的返回的數據是否達到預期
介面的功能是否正確實現了
介面是否按照設計文檔中來實現（比如username參數寫為了user，那麼這就不符合，因為介面文檔在整個開發中都需要使用，所以介面實際的設計要與介面設計文檔中保持一致）
兼容性測試： 比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的調用方式
錯誤碼測試： 通用的錯誤碼與業務錯誤碼是否能夠清晰的說明調用問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
返回值測試： 返回值除了內容需要是正確的，還需要類型也是正確的，保證調用方拿到這些參數能夠正確的解析
參數邊界值、等價類測試
json格式測試： 通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試 如果傳遞非json的情況，這時候程序會不會正確的處理，返回相應的 error code
默認值測試： 很多情況一些非必填的參數會有默認值，比如說一個查詢的介面，參數count為返回查詢的結果數量， 默認為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的數據超過10條。
是否有依賴業務，比如查看訂單，是需要用戶首先登錄的，所以肯定要保證登錄了或有相應的cookie
業務邏輯測試： 傳遞正確的參數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行 增刪改的操作，也需要看資料庫是否同步進行了這些操作
關鍵字參數：將參數寫為開發語言中的關鍵字
參數為空：比如去掉了username參數
多或少參數：多或者少參數的驗證，現在還不確定如果一個介面多了參數如果沒有報錯是否是合理的，或者是否需要優化，因為就目前開發給予的答案是，一般不對介面多了參數的處理
錯誤參數：比如將username參數寫為了user等看是否能返回相應的errorcode
關鍵字數據：將參數的值填為開發語言中的關鍵字
數據為空：將參數的額值填為空
長度不一致：因為資料庫中每個欄位都設置有欄位長度，填寫不符合的長度進行驗證
錯誤數據：就是將參數的值任意填寫，或填寫不存在的數值
異常類型測試： 比如count參數，這個參數的類型一定是可以轉換為int類型的，這時候我們需要測試如果傳的一些不可以 轉換為int類型值來測試代碼是否加入判斷
響應時間
吞吐量
並發用戶數
佔用內存，CPU等
敏感信息是否加密
必要參數是否後端也進行校驗（現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證）
介面是否防惡意請求（SQL注入）
cookie：就是將header中的cookie修改或刪除後看是否能返回相應的errorcode
header：就是刪除或修改header中部分參數的值，看是否能返回相應的error code
唯一識別碼：刪除修改唯一識別碼測試
那麼設計測試用例時我們主要考慮如下幾個方面：
功能測試：
邏輯業務：
異常測試：
異常分為兩類，參數異常和數據異常
參數異常：
數據異常：
性能測試：
安全性測試：
3. 瀏覽器中輸入什麼測試應用
是指不同瀏覽器使用內核及所支持的 HTML 等網頁語言標准不同，用戶客戶端的環境不同造成的顯示效果不能達到理想效果。對於用戶而言，無論使用哪款瀏覽器，期望看到的效果是正常的統一的。
市面上發布的瀏覽器版本非常之多，礙於測試環境和人力資源的不足，要想做到全面的兼容性測試很難。如何進行高效的瀏覽器兼容性測試，對於前端開發人員還是測試工程師來說，都算得上一個頭疼的問題。
為此，我們可以在多台計算機或者多台虛擬機上部署不同瀏覽器進行測試，但這種方法會造成一定的資源浪費、或存在卡頓情況。為提高測試效率，可以利用一些瀏覽器兼容性測試工具來完成測試工作。以下介紹 8 款瀏覽器兼容性測試工具，可以依據自己需求選擇，有需要的歡迎收藏！【點擊領取：測試進階資料傳送門】
4. 前端開發ie瀏覽器的兼容問題怎麼解決
所謂的瀏覽器兼容性問題，是指因為不同的瀏覽器對同一段代碼有不同的解析，造成頁面顯示效果不統一的情況。在大多數情況下，我們的需求是，無論用戶用什麼
瀏覽器來查看我們的網站或者登陸我們的系統，都應該是統一的顯示效果。所以瀏覽器的兼容性問題是前端開發人員經常會碰到和必須要解決的問題。
在學習瀏覽器兼容性之前，我想把前端開發人員劃分為兩類：
第一類是精確按照設計圖開發的前端開發人員，可以說是精確到1px的，他們很容易就會發現設計圖的不足，並且在很少的情況下會碰到瀏覽器的兼容性問題，而這些問題往往都是瀏覽器的bug，並且他們製作的頁面後期易維護，代碼重用問題少，可以說是比較牢固放心的代碼。
第二類是基本按照設計圖來開發的前端開發人員，很多細枝末節差距很大，不如間距，行高，圖片位置等等經常會差幾px。某種效果的實現也是反復調試得到，具體為什麼出現這種效果還模模糊糊，整體布局十分脆弱。稍有改動就亂七八糟。代碼為什麼這么寫還不知所以然。這類開發人員往往經常為兼容性問題所困。修改好了這個瀏覽器又亂了另一個瀏覽器。改來改去也毫無頭緒。其實他們碰到的兼容性問題大部分不應該歸咎於瀏覽器，而是他們的技術本身了。
5. 什麼是兼容性測試兼容性測試側重哪些方面
一、兼容性測試就是測試電腦硬體之間是否有不兼容等問題或軟體問題。
二、兼容性測試側重哪些方面
1、向前兼容和向後兼容。向前兼容是指可以使用軟體的未來版本，向後兼容是指可以使用軟體的以前版本。
2、不同版本之間的兼容。實現測試平台和應用軟體多個版本之間能夠正常工作。
3、 標准和規范
高級標準是產品應當普遍遵守的。若應用程序聲明與某個平台兼容，就必須接受關於該平台的標准和規范。低級標準是對產品開發細節的描述。
4、數據共享兼容。數據共享兼容是指要在應用程序之間共享數據，要求支持並遵守公開的標准，允許用戶與其他軟體無障礙的傳輸數據。
(5)前端兼容性測試擴展閱讀：
軟體的兼容性是衡量軟體好壞的一個重要指標，在具體測試中可以從以下幾個方面來判斷：
1、操作系統兼容性 有些軟體在不同的操作系統平台上重新編譯即可運行，有些軟體需要重新開發或是改動較大。
2、異構資料庫兼容性 這類軟體要考慮其對不同資料庫平台的支持能力，軟體是否可直接掛接，或需提供相關的轉換工具。
3、新舊數據轉換軟體是否提供新舊數據轉換的功能。
4、異種數據兼容性 可否完全正確地讀出這些格式的文件
5、應用軟體兼容性
6、硬體兼容性 硬體兼容性考察軟體對運行的硬體環境有無特殊說明，
6. 蘋果電腦做網站前端頁面瀏覽器兼容性測試問題
網路建設公司很多，沒有具體的衡量標準的。但是可以從幾方面去選擇：
1 有做了很多精明案例的
2 案例都是可以驗證方法的
3 只做網站建設的，沒有做別的業務的
4 做的比較久的。
7. 前端測試有哪幾種類型
目前在軟體系統開發中，測試是一個非常重要的環節，特別是前端測試，有幾種類型的測試被認為是前端測試所必需的，讓我們簡單了解一下。
01
單元測試
在修復bug或添加一點功能時，軟體的其他部分可能會停止工作。為了處理這種情況，單元測試將代碼的各個部分分開，以單獨檢查其准確性。跳過或最小化單元測試可能會導致修復缺陷的成本增加。Javascript單元測試包括一個套件中有組織的測試數量，這些測試彼此不沖突，並且相互之間的依賴性更少。
02
端到端測試
端到端測試涵蓋了應用程序從頭到尾的流程，結束測試跟蹤用戶的旅程，如打開瀏覽器、導航，並體驗完整的生產場景。端到端測試驗證互連系統和軟體系統，它包括一個完整的前端和後端系統。
03
集成測試
集成測試的目的是使模塊/組件按預期運行。集成測試技術應用於許多模塊緊密耦合的大型應用中，模塊被單獨測試，一旦集成，組合行為被驗證，它是與開發並行進行的。在集成測試中，您需要更多的邏輯技能，因為在測試期間，某些模塊可能尚未准備就緒或正在構建中。
集成時使用測試存根和驅動程序，集成測試將分析開發人員實現的邏輯是否遵循規定的標准。當模塊與第三方API交互時，查看響應非常重要。當開發人員跳過單元測試時，集成測試就不可避免了。
04
功能測試
功能測試，用於驗證應用程序或網站對目標用戶能正確工作。使用適當的平台、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好。功能測試是為了確保程序以期望的方式運行而按功能要求對軟體進行的測試，通過對一個系統的所有的特性和功能都進行測試確保符合需求和規范。
05
可視化/用戶界面測試
視覺/UI測試包括屏幕截圖的驗證。這是一項質量保證活動，旨在確保屏幕在任何設備、屏幕解析度、瀏覽器和操作系統上的外觀與預期一致。通過無頭瀏覽器中捕獲的不同屏幕截圖比較渲染版本的結果，可視化回歸測試允許您檢測偏差。
在構建應用程序時，事情會變得過載和復雜，這種情況很容易破壞現有的功能並引入新的bug—單元、行為和集成測試將到位，以使應用程序穩定。
06
性能/壓力測試
性能測試是一種非功能性技術，它在各種工作負載下檢查軟體的穩定性、響應性、速度、可靠性和資源使用等系統參數。
壓力測試：應用程序被重載以檢查意外行為並了解其承受能力。
為網站執行一個高質量的前端測試將提高生產力，並增加客戶對您的服務的依賴。了解趨勢通用模式並結合專家經驗來定義質量測試套裝是很重要的。
07
跨瀏覽器測試
Web端應用測試主要障礙之一就是在不同的瀏覽器上「測試他們的網站/應用程序」，也稱為「跨瀏覽器測試」或者「兼容性測試」。瀏覽器和瀏覽器版本很多（Google Chrome，Mozilla Firefox，Internet Explorer，Microsoft Edge，Opera，Yandex等），可以通過多種設備（通過台式機，筆記本，智能手機，平板電腦等）訪問網站/應用。）以及可能用於訪問網站的多種操作系統（Windows，MacOS，Linux，Android，iOS等）。
要確保網站的UI/UX及其功能正常運行，並且在「瀏覽器+瀏覽器版本+操作系統+設備配置」的組合上沒有任何BUG，則將需要大量的開發，測試和維護工作。
8. UI測試、功能測試和兼容性測試
關於網站 測試 的幾個小套路，希望對大家有所幫助。
因為所在團隊沒有專業測試人員，所以測試 工作 由我這個產品新人來負責。本文是抱著總結才能提升的小心思，想來簡單寫寫從測試零經驗到開發葛葛「談心」的次數逐漸變少，這期間所踩過得坑和心得體會。
一、 UI測試
用戶界面測試主要是拿待測網頁和設計稿進行對比，個人覺得主要需做到以下4點：
1.注重細節：
這點最基本，就是對比時細心、細心再細心。像我現在被虐到網頁上元素和設計稿差一個像素都能看出來…
2.勿忘整體性：
由於PC網頁頁面空間大，模塊多，很容易在測試時只注意到模塊內設計元素是否正確，而忽略了模塊間的間距或整個頁面的布局是否正確。所以最好按照由局部到整體的順序測試。
3.注意頁面間相互對比：
即注意相同系列頁面、頁簽布局一致性。就是說的是同一系列頁面中同類元素和模塊的樣式、間距一般要相同；同一個tab下，不同選項對應
的頁簽中同類元素和模塊的樣式、間距一般要相同。例如下圖QQ空間-日誌頁面里我的日誌和私密日記tab中，紅框圈出的位置高度是否一致。
一般情況下這些不一致問題出現的情況不多，畢竟相類似的布局前端同學應該會用相同的盒子，但是測試時還是需要留意。
4.注意極端情況下顯示情況：
即要注意長度可變的元件、模塊或欄位在極端情況下的顯示是否正常。
例如： 文章 標題最多可顯示50字元（25漢字），測試時就要在所有會出現標題的位置（文章列表頁、推薦邊欄、轉發彈框…）是否能正常顯示含有50字元的標題，會不會出現破框而出、自動切掉等情況。
由於UI測試時需要檢查的細節很多，特別是像我們團隊，網站還在搭建中並未上線，UI測試的工作量更是大，測久了難免會覺得枯燥繁瑣，但其實每項任務都能總結出套路、有所收獲，故下面僅列出我平時在測這部分時的主要注意點和心得。
UI測試注意點總結：
1、模塊間距
2、元素間距
3、不同類型文本（數字、漢字、英文）顏色、格式（全形、半形）大小、字體、（不必須）
4、固定文案：內容的可讀性、正確性?排版的合理性
5、可變欄位：極多、極少文字的排版情況
6、Icon用錯、用混
7、相似頁面的差異性和一致性
小體會：
其實界面測試雖然沒啥 技術 含量，但測久了就會發現自己對網頁元素有時彼此間的間距差了1、2個像素，整體的視覺效果就尺寸和布局的敏感度有提升，例如像同樣一組元素，會大有不同， web 是這樣， 移動 端更是如此。
隨手畫張圖舉個栗子：左圖網頁做出來名稱、作者、互動統計三者之間行距相等，中文字大小相
同，而設計稿原本應如右圖，行距不同，不同欄位的字型大小也不同。所以假如測試時遇到類似這種問題，我們除了可以提個bug，還會被引導去思考設計初衷，即利用間距細微差異進行視覺分組，利用字型大小細微差異突出主次。
二、 功能測試
1.操作反應：
（1） 頁面元素（按鈕、錨文本、輸入框…）自身狀態變化：滑鼠移入/移出時效果、點擊後效果、獲取/失去焦點時效果…（可以想想axure里的用例狀態）
eg：滑鼠移入按鈕，按鈕是底色是否應改變；若輸入框內有默認提示文字，則是當輸入框獲得焦點後文字就消失，還是用戶輸入文字後提示文字才消失…
（2）操作成功後續反應：頁面跳轉、彈框、提示文字…
a.頁面跳轉：
頁面切換方式：另開頁面、本頁切換
頁面起始定位：頁面起始位置、頁面其他錨點（例如用戶想評論某文章，在列表頁點評論按鈕後，就會在另開的文章內容頁直接定位到評論區）
b.彈框：
匹配情況：彈出的彈框是否和觸發條件匹配
出現位置：一般情況下要一致。因為彈框使用不同插件，可能導致彈出位置不同。
顯示時間（非操作類彈框）：某些僅起到提示功能的彈框會自動顯示若干秒關閉。一般情況此類彈框上文案較少，顯示秒數應該是全站一致的。
c.提示文字：
匹配情況：出現的提示文案是否和觸發條件匹配
關於操作成功後續反應，以上主要是在已確定會觸發某反應情況下，測試其正確性。其實這里更重要的是要考慮在前置條件不同的情況下，對某元素進行相同操作，會觸發什麼不同的反應。即需要對各類情況進行窮舉。
eg：點擊關注按鈕觸發反應窮舉：
a.未登錄用戶點擊該按鈕後效果；
b.已登錄用戶點擊該按鈕後效果（b1.未關注過對方、b2.已關注過對方、b3.自己關注自己）
窮舉時可以參考PRD，但不要局限於PRD上列出的情況，畢竟有時也許PRD上會有小疏漏，要是程序員做的時候發現疏漏，就自己隨手碼了一個簡易提示而忘記通知產品，而測試的時候也沒觸發到，等用戶實際操作出來就會造成不佳的用戶體驗。
原文來自：http://www.51testing.com/html/10/n-3714410.html
9. 想問下前端需要考慮的兼容性瀏覽器有哪些
一、瀏覽器的佔有率：
ie6 - 30.23%
ie7 - 4.8%
ie8 - 30.6%
ie9 < 1%
chrome - 13.99%
firefox - 7.17%
safari ~ 5%
其他 ~ 8%
從數據上可以看出chrome + firefox + safari + ie9是高端瀏覽器，ie8勉強算準高端吧。這樣這部分佔有率約57%(如果加上其他webkit內核的瀏覽器會更高一些) 已經大於ie6 + ie7，但是IE6兼容性還是要解決。
二、web前端主要這些兼容瀏覽器：
1，firefox是開源的瀏覽器內核，插件很齊全，是代碼人員的愛寵。
2、IE瀏覽器，要在Windows中開發適合自己的瀏覽器，很多人都在用。
推薦：ie8以上，360安全瀏覽器
3、Google瀏覽器，是谷歌公司開發的網頁瀏覽器，穩定性和安全性很好。
推薦：Google Chrome
4、Opera12.17及更早版本曾經採用的內核是Presto，Opera15及以後的版本採用Blink的內核。用於手機代碼測試也很方便。
推薦：Opera15