軟件測試面試200問（全）

1、B/S架構和C/S架構區別

B/S 只需要有操作系統和瀏覽器就行，可以實現跨平臺，客戶端零維護，維護成本低，但是個性化能力低，響應速度較慢

C/S響應速度快，安全性強，一般應用于局域網中，因為要針對不同的操作系統,需要針對性的開發,并且維護成本高

2、HTTP協議

http協議又叫做超文本傳輸協議，在做網絡請求的時候，我們基本上是使用http協議。

http協議包括請求和響應。

請求中包括：請求地址，請求方式，請求方式包括get請求和post請求，get和post的區別是get請求是在地址欄后邊跟隨請求參數，但是請求參數大小是有限制，不同瀏覽器是不同的。一般是4KB。post請求主要用于向服務器提交請求參數。post請求的參數是放到請求實體內容中的，相對get請求較為安全一些。另外，請求中會有各種請求頭信息，比如支持的數據類型，請求的來源位置，以及Cookie頭等相關頭信息。

響應，主要包含響應的狀態碼，像200，304，307，404，500

還有各種響應頭信息，比如設置緩存的響應頭，Content-Type內容類型，設置cookie頭信息。

200：（成功）服務器已成功處理了請求
304：（未修改）客戶端發出了條件式請求，但服務器上的資源未曾發生改變，則通過響應此響應狀態
307：（重定向）瀏覽器內部重定向
404：（未找到）服務器無法找到客戶端請求的資源；Not Found
500：（服務器內部錯誤）無法完成請求；

3、POST與GET區別

Get請求一般是去取獲取數據（其實也可以提交，但常見的是獲取數據）；post請求一般是去提交數據。

Get是不安全的，因為在傳輸過程，數據被放在請求的URL中；Post的所有操作對用戶來說都是不可見的，請求數據是放在body體中（最常用場景，用戶登錄密碼提交，一定是使用post請求的）

Get傳送的數據量較小，這主要是因為受url長度限制；Post傳送的數據量較大，一般被默認為不受限制。

Get請求可以被緩存，Post請求不會被緩存

4、Cookie和Session的區別與聯系

Cookie和Session都是會話技術，Cookie是運行在客戶端，Session是運行在服務器端。

Cookie有大小限制以及瀏覽器在存cookie的個數也有限制，Session是沒有大小限制和服務器的內存大小有關。

Cookie有安全隱患，通過攔截或本地文件找得到你的cookie后可以進行攻擊。

Session是保存在服務器端上會存在一段時間才會消失，如果session過多會增加服務器的壓力。

5、測試的目的

簡單地說，就是替用戶受過，測試的最終目的是確保最終交給用戶的產品的功能符合用戶的需求，把盡可能多的問題在產品交給用戶之前發現并改正

6、軟件測試分為哪幾個階段？

單元測試、集成測試、系統測試、驗收測試。

單元測試

是在軟件開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試，測試重點是系統的模塊，包括子程序的正確性驗證等。

集成測試

也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。測試重點是模塊間的銜接以及參數的傳遞等。

系統測試

是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。測試重點是整個系統的運行以及與其他軟件的兼容性。

系統測試范圍

功能測試、ui測試、性能測試、容錯測試、可用性測試、異常問題測試、穩定性測試、系統穩定性測試、兼容性測試、接口測試、安全性測試、登錄權限測試

驗收測試

是軟件產品檢驗的最后一個環節。按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審，決定是否接收或拒收系統。

其它得幾個階段劃分

回歸測試

是指對軟件的新版本測試時，重復執行之前某一個重要版本的所有測試用例目的：

1.驗證之前版本產生的所有缺陷已全部被修復；
2.確認修復這些缺陷沒有引發新的缺陷

冒煙測試

是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。也叫可測性測試。

7、a測試與?測試的區別

а測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。

?測試是一種驗收測試。beta測試是指在一個或多個用戶的場所進行的測試。

8、驗收測試怎么做？

1、界面測試；指軟件產品所有的頁面瀏覽時功能按鈕或者界面是否能正常顯示。
2、功能測試；產品的功能是否都能正常實現。
3、性能測試；發現性能瓶頸的過程，包括對CPU、內存、網絡環境、版本等多項測試內容。
4、安全測試；產品的信息保密，密碼保護等功能的測試。

9、白盒、黑盒和灰盒測試區別

黑盒和灰盒的區別：

如果某軟件包含多個模塊，當使用黑盒測試時，你只要關心整個軟件系統的邊界，無需關心軟件系統內部各個模塊之間如何協作。而如果使用灰盒測試，則需要關心模塊與模塊之間的交互。

白盒和灰盒的區別：

在灰盒測試中，你無需關心模塊內部的實現細節，對于軟件系統的內部模塊，灰盒測試依然把它當成一個黑盒來看待。而白盒測試還需要再深入地了解內部模塊的實現細節和各個分支。

10、冒煙測試的目的

為正式測試前，驗證是否產品或系統的主要需求或預置條件是否存在bug。

11、回歸測試怎么做？

1.在測試策略制定階段，制定回歸測試策略
2.確定需要回歸測試的版本
3.回歸測試版本發布,按照回歸測試策略執行回歸測試
4.回歸測試通過，關閉缺陷跟蹤單（問題單）
5.回歸測試不通過，缺陷跟蹤單返回開發人員，開發人員重新修改問題，再次提交測試人員回歸測試

12、需求分析的目的

第一、把用戶需求轉化為功能需求：1）對測試范圍進度量 2）對處理分支進行度量 3）對需求業務的場景進行度量 4）明確其功能對應的輸入、處理和輸出 5）把隱式需求轉變為明確。

第二、明確測試活動的五個要素：測試需求是什么、決定怎么測試、明確測試時間、確定測試人員、確定測試環境：測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到盡可能的詳細明確，以避免測試遺漏和誤解。

13、測試計劃的目的

1.盡早地明確測試工作內容（范圍）、測試工作的方法以及測試工作所需要的各種資源。
2.所有涉及到測試工作的人員，盡快將下一步測試工作需要考慮的問題和準備的條件落實。
3.測試計劃工作的重點在于：對當前工作任務的準備和規劃以及信息的交流。

14、什么時候開始寫測試計劃

測試計劃是在需求整理完成，和開發計劃一起制定的一份計劃書，它屬于項目計劃中其中的一個計劃

15、由誰來編寫測試計劃

項目經理（從項目角度考慮）
測試經理（從測試組角度考慮）
測試人員（編寫具體測試計劃）

16、測試計劃的內容

1.?測試目標：對測試目標進行簡要的描述。
2.測試概要：摘要說明所需測試的軟件、名詞解釋、以及提及所參考的相關文檔。
3.測試范圍：測試計劃所包含的測試軟件需測試的范圍和優先級，哪些需要重點測試、哪些無需測試或無法測試或推遲測試。
4.重點事項：列出需要測試的軟件的所有的主要功能和測試重點，這部分應該能和測試案例設計相對應和互相檢查。
5.質量目標：制定測試軟件的產品質量目標和軟件測試目標。
6.資源需求：進行測試所需要的軟硬件、測試工具、必要的技術資源、培訓、文檔等。
7.人員組織：需要多少人進行測試，各自的角色和責任，他們是否需要進行相關的學習和培訓，什么時候他們需要開始，并將持續多長時間。
8.測試策略：制定測試整體策略、所使用的測試技術和方法。
9.發布提交：在按照測試計劃進行測試發布后需要交付的軟件產品、測試案例、測試數據及相關文檔。
10.測試進度和任務人員安排：將測試的計劃合理的分配到不同的測試人員，并注意先后順序.如果開發的Release不確定，可以給出測試的時間段.對于長期大型的測試計劃，可以使用里程碑來表示進度的變化。
11.測試開始/完成/延遲/繼續的標準：制定測試開始和完成的標準；某些時候，測試計劃會因某種原因(過多阻塞性的Bug)而導致延遲，問題解決后測試繼續。
12.風險分析：需要考慮測試計劃中可能的風險和解決方法。

17、結束條件(項目上線的條件)

1.軟件經過充分的測試

開發人員測試—〉交叉測試—〉測試人員測試—〉用戶的業務專家測試—〉一定數量的用戶業務專家集中測試—〉上線前試運行----〉上線。

2.用戶培訓

管理員，一定廠或地區必須有一個人經過了培訓。

3.基礎數據導入完成

用戶、組織機構、業務數據等基礎必須數據導入完成。

4.授權必須完成

5.新老系統的切換必須提前演練過，各種老數據的導入工作完成。

6.應急方案必須有。

18、常見的測試風險

1.需求風險、2.測試用例風險、3.缺陷風險、4.代碼質量風險、5.測試環境風險、6.測試技術風險、7.回歸測試風險、8.溝通協調風險、9.研發流程風險、10.其他不可預計風險

19、測試用例的要素

1.用例編號、2.測試模塊、3.用例的標題、4.測試級別、5.測試目的和條件、6.測試輸入、7.操作步驟、8.預期結果

20、測試用例級別的劃分

測試用例優先級的目的：測試用例優先級可以用來方便地基于測試策略來篩選用例。比如某塊功能改動小，就只用測高或中高優先級的用例。比如冒煙測試的時候我們只需要篩選優先級最高的用例執行即可。

根據我們測試用例優先級目的：那么優先級越高的測試用例覆蓋的測試點應該是用戶最關心的，比如一個注冊功能，能夠注冊成功這個用例的優先級就是最高的（但是不是所有的注冊成功的case都是優先級最高，只需要挑選一個即可），其他各種異常校驗都是次要優先級的，還有一些場景覆蓋的測試點很難出現，或者叫就算有問題影響也不大，可以放到低優先級

21、怎樣保證覆蓋用戶需求？

1.確認需求、2.梳理需求，確認測試范圍、3.制定測試計劃、4.根據測試計劃編寫測試用例、5.執行測試步驟

22、寫好測試用例的關鍵 /寫好用例要關注的維度

測試前：

1.對測試目的有一個清晰的認知

2.熟悉產品的功能測試點

3.熟悉模塊原理，避免“互相影響”問題的產生

4.關注用戶場景問題和上網問題

5.不可馬虎的關鍵測試用例設計

編寫測試用例時：

1.構建測試用例框架

2.測試步驟的設計（一是如果步驟過于粗糙很容易出現漏測問題；二是寫的過于細致，可能耗時耗力，并且會限制執行人員的思維。）

測試用例設計方法及思考

1.切記產品測試的主要目標

2.注意用詞精準問題

23、常見的測試用例設計方法

等價類劃分、邊界值分析、錯誤推斷法、判定法表、正交實驗法

24、什么時候用到場景法

場景法適用于解決業務流程清晰和業務比較復雜的系統或功能，場景法是一種基于軟件業務的測試方法。

使用場景法，目的是用業務流把各個孤立的功能點串起來，為測試人員建立整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向。例：語音通話典型業務流程就把語音通話、同振順振、語音留言、呼叫保持、呼叫轉移這些功能都串到一起來。

基本上每個軟件都會用到場景法，因為每個軟件背后都有業務的支撐。

場景法主要用來測試軟件的業務邏輯和業務流程。當拿到一個測試任務時，我們并不是先關注某個控件的細節測試（等價類+邊界值+判定表等），而是要先關注主要業務流程和主要功能是否正確實現，這就需要使用場景法。當業務流程和主要功能沒有問題，我們再從等價類、邊界值、判定表等方面對控件細節進行測試（先整體后細節）。

Note：場景法測試用例設計的重點是測試業務流程是否正確，測試時需要注意的是，業務流程測試沒有問題并不代表系統的功能都正確，還必須對單個功能進行詳細的測試，這樣才能保證測試的充分性。

25、偶然性問題的處理

一定要提交bug

1．記得有這么個缺陷，以后再遇到的時候可能就會了解發生的原因。
2．盡力去查找出錯的原因，比如有什么特別的操作，或者一些操作環境等。
3．程序員對程序比測試人員熟悉的多，也許你提交了，即使無法重現，程序員也會了解問題所在。
4．無法重現的問題再次出現后，可以直接叫程序員來看看問題。
5．記錄bug要盡量描述清楚發生問題時的測試步驟、測試環境、測試數據。

盡量重現bug

26、當我們認為某個地方是bug，但開發認為不是bug，怎么處理？

1.告知開發bug的判斷依據，同時明確開發說不是bug的理由。
2.對開發的理由進行校驗，校驗依據1.參照需求文檔，2.跟產品經理進行溝通確認。
3.校驗結果不是bug，關閉bug，如果是bug提交給開發進行處理，確保產品質量

27、產品在上線后用戶發現bug，這時測試人員應做哪些工作？

1、測試人員復現問題后，提交問題單進行跟蹤；
2、評估該問題的嚴重程度，以及修復問題時的影響范圍，回歸測試需要測試哪些功能；
3、問題修復后，先在測試環境上回歸，通過后再在生產環境上打補丁，然后再進行回歸測試；
4、總結經驗，分析問題發生的原因，避免下次出現同樣問題。

28、二八定理

缺陷往往喜歡扎堆，一個模塊已經發現的缺陷比別的模塊多，通常不是代表這個模塊已經把缺陷暴露完了，而是意味著這個模塊還存在有同樣多的缺陷尚未被發現。這就是著名的二八定理：80%的缺陷出現在 20%的模塊。

29、如何跟蹤缺陷

當發現缺陷后，我們要在禪道上提交問題單給開發，并每隔一段時間(間隔一個小時，或兩個小時都可以)去檢查缺陷是否被處理，如果沒及時處理，就要提示開發，讓開發及時修復問題，問題修復后，要及時進行回歸測試。

30、缺陷的狀態

1、初始化：缺陷的初始狀態；
2、待分配：缺陷等待分配給相關開發人員處理；
3、待修正：缺陷等待開發人員修正；
4、待驗證：開發人員已完成修正，等待測試人員驗證；
5、待評審：開發人員拒絕修改缺陷，需要評審委員會評審；
6、關閉：缺陷已被處理完成。

31、缺陷的等級

輕微缺陷、一般缺陷、嚴重缺陷、致命缺陷

32、缺陷單應該包含這些要素

缺陷標題、缺陷類型、重現步驟、預期結果、實際結果、缺陷優先級、附件備注

33、測試報告的主要內容

測試報告包括哪些內容: 測試模塊（每個模塊里需要記錄測試的開始時間、結束時間、設計多少用例、通過多少、失敗多少、有多少BUG、遺留多少BUG、解決多少BUG、追后對這個模塊總結一下）

BUG的統計，根據時間軸來統計BUG的數量，例如：XXXX年X月X日，發現BUG多少，關閉BUG多少，剩余BUG多少，高級的BUG有多少，中級的BUG有多少，低級和建議的BUG有多少，一直羅列到項目完結

項目總結，匯報一下測試的大致結果。

遺留和風險，該軟件還有什么遺留問題，還有什么風險，都要一一說明

最后評判該軟件是否符合上線標準，日期，簽字，加蓋章等

34、如何定位bug

1、發現bug，首先要查看bug的詳細信息，根據描述初步分析是哪個模塊哪段代碼的問題
2、檢查引發bug的測試環境、測試代碼段和測試數據，排除測試人員的誤操作導致的程序異常
3、確認測試代碼、測試環境和數據都正確后，再進一步分析bug根源。這里就需要看具體的測試業務了，可借助相關的工具進行分析
4、如果產品或業務有相關的日志記錄，可通過分析日志來確認bug
5、當測試人員經過一系列的分析，可以基本確認bug產生的原因后，就可以直接找開發提bug了（注意溝通技巧）
6、如果各方面都分析完還不能確認bug的原因，可以找開發一起定位（注意保留bug現場或者可以復現bug場景）
7、確認bug后，提單給開發進行bug跟蹤。
問題單上要描述清楚以下信息：
具體的測試時間、測試環境、測試場景、測試的具體業務和功能、使用的測試代碼和測試數據、測試執行步驟、測試結果、bug現象（最好截圖）、日志記錄、預期結果、bug確認相關人員等
8、跟蹤bug，等開發人員修復bug后進行回歸測試。（關注bug是否完全修復、有沒有對其他功能造成影響、有沒有引入新的問題）

35、開發沒時間修復，如何推進bug的修復

1、針對路徑較深的bug，測試在推動開發修復bug時，需要注意以下幾點：

a) 從用戶的角度分析問題的嚴重性，分析用戶的遇到此問題的概率，引導開發站在用戶角度去思考，從而使開發意識到問題的嚴重性
b) 可以和開發人員列舉一個之前的類似問題，為開發提供參考
c) 產品是負責這個軟件的人員，當測試與開發意見無法達成一致時，不要因為無法推動開發修改而放棄，一定要找產品確認，最終的決定權交給產品人員。

2、上線時間緊張，開發來不及修改了，這個時候測試應該分析問題的嚴重性，和產品人員商議是否需要修改

3、修改bug改動較大，影響范圍廣，沒有最優的解決方案等情況在項目即將上線的節點比較忌諱這種事情的發生。面對這種情況，建議開發人員做調研工作，請教其他的同事，或者組織一個臨時會議，集眾人之力研究好的修改方案

4、第三方應用問題，開發無法修改。確認原因之后需要找相關的工作人員，例如產品，聯系第三方的工作人員，反饋問題，盡量推動應用解決問題

小結

總之，bug修不修，測試應該有一個自己的原則，同時也要權衡利弊。不能因為推不動開發，就放棄，由著bug上線，也不能揪著一個小bug不放，影響上線時間。

36、軟件測試流程

了解用戶需求–》參考需求規格說明書–》測試計劃（人力物力時間進度的安排）–》編寫測試用例–》評審用例–》搭建環境–》測試包安排預測（冒煙測試）-正式測試-bug-測試結束出報告–》版本上線–》面向用戶

37、對一支圓珠筆進行測試，要從哪些方面進行測試？三角形測試用例設計

性能測試

能否正常書寫是否有筆油泄露筆帽是否能正常按下彈起來

功能測試

一支筆可以用多長時間、寫出的字是否褪色

易用性測試

筆的長短粗細是否順手一根筆芯用盡是否方便更換

界面測試

外形是否美觀時尚有趣

安全性測試

筆油是否含有有害物質筆尖是否容易傷到人筆油或者墨水保質期多長過期是否產生有害物質、

兼容性測試

在不同的溫度、氣壓、和重力下能否正常使用在不同的紙質和力度下書寫結果如何

三角形測試用例設計

1、當三邊不可能構成三角形時提示錯誤，可構成三角形時計算三角形周長。
2、若是等腰三角形打印“等腰三角形”，若兩個等腰的平方和等于第三邊平方和，則打印“等腰直角三角形”。
3、若是等邊三角形，則打印：“等邊三角形”。
4、畫出程序流程圖并設計一個測試用例。
因果圖、等價類劃分（推薦測試方法）

38、在項目中發現哪些經典bug？什么原因導致的？

編碼的問題

接口限流防刷的時候，通過計數器限流，如果超過某個閾值，向前端返回一個codeMsg對象用于顯示的時候，顯示的是String是亂碼的問題，之前由于一直返回都是json 格式，都是封裝好在data里。

這次返回是直接通過輸出流直接寫到response直接返回字節數組的，而不是spring controller 返回數據（springboot 默認utf-8），出現亂碼問題，用utf-8編碼，解決。

比較難解決的bug無非就兩種，一種就是程序的邏輯出現問題，導致得不到正確的結果，第二種就是一些中間件，開發環境的問題。

（1）如果是邏輯出現了問題，你項目比較大的話，那只能是通過單步調試，或者用System.out.println()打印出來想要得到的數據看看是哪步出了問題。

（2）如果是開發環境或者是中間件的問題，那只能是通過網上查閱資料來解決問題。如果你英語閱讀能力還可以的話，我推薦使用Stack Overflow來查閱資料。

39、在需求文檔不太詳細的情況下，如何開展測試？

1.主動了解做這個功能的背景，意圖，要去解決一個什么樣的問題，這個可以找產品或者開發要，或者誰要求做這個功能的人要，知道這些后，測試的時候才心中有數，知道功能實現對不對

2.盡量讓熟悉這塊的業務的人去測試，這樣功能的一些業務問題就可以測試出來

3.因為沒有需求說明書，測試這邊只有在功能做好了，轉測試了，才知道功能是什么樣子，所以這個時候寫測試用例來不及，就采取這樣思路操作，測試的時候邊測試邊記錄測試的點，然后組內把這些測試點評審下，看看是否還有遺漏的地方，

40、如何盡快找到軟件中的bug?

優先解決可重現的bug、對于某些沒有頭緒的bug，可以找有經驗的同事商討、bug放大、二分定位法、模擬現場、等

41、ATM機吞卡的吞卡現象是不是BUG?

不是，是特意設置的安全措施，防止有人馬虎，操作后忘記取走銀行卡而被人冒領卡中的錢款，所以特意設置了倒計時，限時內沒有取走銀行卡就會吞卡

42、如何減少非問題單的提交？

1、缺陷的概要描述要清晰準確，要使相關開發負責人員能夠一目了然問題是什么。
2、一個完整的缺陷報告單，必須包含其必要的元素信息，例如：概要描述，缺陷發現人，測試環境，瀏覽器，缺陷重現步驟，嚴重等級，指派人，所屬功能模塊等等，必要元素信息必須描述全面清楚。
3、缺陷的重現步奏必須描寫清晰明了，使相關開發負責人能夠根據重現步驟準確的重現所提交的缺陷，使其定位缺陷的原因所在。
4、指派給人一定要明確，如知道缺陷是所屬具體的某一個開發人員時，應該直接指派給對應的負責人，這樣就能減少中間分配環節的時間。
5、測試數據，測試的數據作為重現缺陷的一個重要元素信息，一定要將測試時所使用的信息給描寫清楚準確。讓開發人員根據測試所提供的測試數據準確重現缺陷。
6、附件截圖信息，附件或截圖信息能讓開發人員能夠一目了然的清楚問題的所在，所以必要的時候提供附件或者截圖信息也非常的重要。
7、描述缺陷內容的語氣，在進行缺陷單書寫時，盡量使用專業術語（體現測試的專業性），其次注意書寫缺陷報告單時不要帶有個人客觀的語氣內容，以免影響開發和測試人員之間的關系。

43、有個程序，在windows上運行很慢，怎么判斷是程序存在問題，還是軟硬件系統存在問題？

1、檢查系統是否有中度的特征，如：瀏覽器窗口連續打開，系統中文件圖標改成統一圖標，CPU使用率保存90%以上等
2、檢查軟件/硬件的配置是否符合軟件的推薦標準
3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU資源的服務，如：虛擬機運行
4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況，

44、搜索功能怎么測試

功能方面的測試

搜索單個字，詞語，句子，檢索到的內容是否準確，鏈接是否準確
長度：例如輸入框支持100字符，那需要測試100字符、101字符，最大長度的顯示是否正常；
哪些是支持的字符類型：數字、字母、漢字、字符！@！#、特殊字符；(需求而定）
字符串前后中帶空格，前后的空格是否過濾，中間的空格是否保留；(需求而定）
全角半角的字母、數字(需求而定）

性能方面的測試

點擊搜索按鈕后，搜索結果多長時間能夠顯示
進入搜索頁面需要多久

安全性方面的測試

能否防止SQL注入攻擊,否防止XSS攻擊

用戶體驗測試

頁面布局是否合理，輸入框和按鈕是否對齊
輸入框的大小和按鈕的長度，高度是否合理
快捷鍵：能不能全選，部分選擇，復制剪切粘貼是否可用，粘貼超過最大長度的字符串怎么顯示

兼容性測試

BS架構：不同瀏覽器測試，比如：IE，火狐，谷歌，360這些。
APP：在主流的不同類型，不同分辨率，不同操作系統的手機上測試，華為，vivo，oppo等

45、登錄功能怎么測試

功能方面的測試

輸入正確的用戶名和密碼，點擊提交按鈕，登錄成功，跳轉到正確的頁面
輸入正確的的用戶名, 錯誤的密碼，登錄失敗，并且提示相應的錯誤信息
輸入錯誤的用戶名，正確的密碼, 登錄失敗，并且提示相應的錯誤信息
用戶名為空, 驗證登錄失敗，并且提示相應的錯誤信息
密碼為空, 驗證登錄失敗，并且提示相應的錯誤信息
用戶名和密碼都為空，點擊登陸
用戶名和密碼前后有空格，，中間空格是否處理（需求而定）

性能方面的測試

打開登錄頁面，需要多長時間
輸入正確的用戶名和密碼后，登錄成功跳轉到新頁面，需要多長時間

安全性方面的測試

密碼是否在前端加密，在網絡傳輸的過程中是否加密
用戶名和密碼的輸入框，能否防止SQL注入攻擊
用戶名和密碼的輸入框，能否防止XSS攻擊
錯誤登陸的次數限制（防止暴力破解）
是否支持多用戶在同一機器上登錄
一個用戶在不同終端上登陸
用戶異地登陸

用戶體驗測試

頁面布局是否合理，輸入框和按鈕是否對齊
輸入框的大小和按鈕的長度，高度是否合理
是否可以全用鍵盤操作，是否有快捷鍵
輸入用戶名，密碼后按回車，是否可以登陸
牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），刷新或換一個按鈕是否好用

兼容性測試

BS架構：不同瀏覽器測試，比如：IE，火狐，谷歌，360這些。
APP：在主流的不同機型，不同分辨率，不同操作系統的手機上測試，華為，vivo，oppo、蘋果等

46、如果需要你來測試淘寶的購物車，你會如何設計測試用例，需要從哪些方面來考慮。

1.打開淘寶頁面后，頁面的布局是否是完整的
2.頁面的功能按鈕是否可以正常顯示
3.在商品頁面是否會顯示加入購物車
4.選中的商品是否能加入購物車
5.加入購物車后是否可以顯示商品的所有信息
6.添加到購物車的商品是否可以進行刪除
7.如果在網絡不佳或無網絡時是否可以成功的加入購物車
8.添加購物車后，點擊加號的時候數量是否會增長
9.添加購物車后，點擊減號的時候數量是否會減少
10.如果點擊減號減到一定程度時，是否會提示不能再減少了
11.如果淘寶用戶未登錄時，如果添加到購物車時是否會提示請先登錄
12.如果沒有選擇任何商品，點擊結算，是否會提示用戶“請添加要結算的商品”
13.勾選商品后已選商品的總價是否會顯示
14.勾選商品顯示總價后，總價計算是否正確
15.勾選商品，點擊結算按鈕后，是否會進入確認訂單信息的頁面
16.進入確認訂單信息頁面的總價是否正確
17.總價是否會出現精度不準的情況，比如：正確總價是18.99，結果顯示的確實18.999999999999
18.是否有回到頂部功能
19.是否可以編輯商品屬性
20.能否移入到收藏中
21.店鋪名稱是否顯示
22.能否選擇全部商品
23.能否取消選擇全部商品
24.是否可以在購物車中修改商品的規格
25.添加購物的數量超過庫存數量是否進行限制
26.是否可以進行清空購物車
27.結算金額是否會隨著商品數量的增加減少進行變化
28.如果刷新的次數過多，是否會出現閃退的現象
29.當手機來電話時淘寶頁面是會還會運行
30.當手機內存不夠時，淘寶運行起來是否會出現卡頓的現象