軟件測試功能/數據庫/linux/接口/自動化/測試開發(fā)面試真題解析
功能測試：1、你的測試職業(yè)發(fā)展是什么？
測試經驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時間積累的，一步步向著高級測試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前 2 年積累測試項目經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。
然后學習自動化測試，編程語言，測試開發(fā)技術，能夠為測試圈帶來一些貢獻
2、你認為測試人員需要具備哪些素質？
做測試應該要有一定的協(xié)調能力，因為測試人員經常要與開發(fā)接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。
持有一顆懷疑的心，不能輕易相信開發(fā)自測過
耐心加技術是測試人員在企業(yè)中生存之道
掌握基本的測試基礎理論本著找出軟件存在的問題的態(tài)度進行測試，不要以挑刺的形象出現可熟練閱讀需求規(guī)格說明書等文檔以用戶的觀點看問題有強烈的質量意識細心和責任心良好的有效的溝通方式(與開發(fā)人員及客戶)具有以往的測試經驗能夠及時準確的判斷出高危險區(qū)在何處
3、軟件測試的目的是什么？
軟件測試的目的并不是證明軟件沒有錯誤，而是找出軟件產品中的錯誤，使軟件盡可能的符合用戶的要求。
當然軟件測試是不可能找出全部錯誤的。
4、測試分為哪幾個階段？
一般來說分為 5 個階段：單元測試、集成測試、確認測試、系統(tǒng)測試、驗收測試
5、結合你以前的學習和工作經驗，你認為如何做好測試，做好軟件測試的一些關鍵點
具備較強的需求分析能力，測試人員必須非常熟悉系統(tǒng)功能和業(yè)務測試要有計劃，而且測試方案要和整個項目計劃協(xié)調好必須實現編寫測試用例，測試執(zhí)行階段必須根據測試用例進行
易用性，功能，分支，邊界，性能等功能性和非功能性需求都要進行測試
對于復雜的流程一定要進行流程分支，組合條件分析，再進行等價類劃分準備相關測試數據
定位 bug 要盡量準確，提高與開發(fā)人員協(xié)調的效率，盡早的解決 bug 充實自己的技能：不僅熟練掌握軟件測試基礎知識和理論，還要學習編程語言、數據庫、linux 腳本，自動化測試、性能測試技術 6、談談你之前測試的項目流程，在每個階段的輸出有哪些？
a 新功能：首先會召開需求分析會議，參加人員有產品、開發(fā)和測試，主要是探討需求主要的一些功能點；(輸出：數據庫表設計；接口設計，需求文檔,提測時間)
b.然后開發(fā)就排期進行開發(fā)，主管開始編寫測試計劃，對我們進行任務分配。(輸出：：測試計劃)
c.我們參考需求規(guī)格說明書及原型圖編寫測試用例，寫完之后會進行用例評審，有評審修改的就修改整理形成最終的用例版本；（輸出：測試用例）
d.提測（測試去 Jenkins 部署構建）：開發(fā)人員版本編譯完成后，我們會先進行預測，主要對主功能業(yè)務進行測試，接口測試
如果主業(yè)務流程不通過，直接返回給開發(fā)進行修改。預測通過，依據測試用例進行系統(tǒng)測試。測試過程中，提交 bug，跟蹤 bug，進行回歸測試直至不存在嚴重 bug，滿足用戶需求，（輸出：測試報告）
e.產品發(fā)布上線后，關注 web 是否正常運行，要進行常規(guī)的維護性測試?；貧w測試
（輸出：上線記錄，上線的新功能）
7、怎樣寫測試計劃和編寫測試用例？
簡單點，測試計劃里應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至于測試用例，那是依賴于需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。
1、測試人員盡早介入，徹底理解清楚需求，這個是寫好測試用例的基礎
2、如果以前有類似的需求，可以參考類似需求的測試用例，然后還需要看類似需求的 bug 情況
3、清楚輸入、輸出的各種可能性，以及各種輸入的之間的關聯關系，理解清楚需求的執(zhí)行邏輯，通過等價類、邊界值、判定表等方法找出大部分用例
4、找到需求相關的一些特性，補充測試用例
5、根據自己的經驗分析遺漏的測試場景
6、多總結類似功能點的測試點，才能夠寫出質量越來越高的測試用例
7、書寫格式一定要清晰
8、為什要在一個團隊中開展測試工作？
因為沒有經過測試的軟件很難在發(fā)布之前知道該軟件的質量，就好比 ISO 質量認證一樣，測試同樣也需要質量認證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程中發(fā)現軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質量情況。
9、你所熟悉的軟件測試類型有哪些?
測試類型有：功能測試、性能測試、界面測試
功能測試在測試工作中占有比例最大，功能測試也叫黑盒測試
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行
界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象
區(qū)別在于，功能測試關注產品的所有功能，要考慮到每個細節(jié)功能，每個可能存在的功能問題。性能測試主要關注產品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試則關注與用戶體驗相關內容，用戶使用該產品的時候是否已用，是否易懂，是否規(guī)范(用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告)。做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒有問題的，然后再考慮性能的問題。
10、黑盒測試，編寫測試用例方法有哪些？
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。
“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
11.請說一下白盒測試是什么，編寫測試用例方法有哪些？
白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程序的控制結構設計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設計規(guī)范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發(fā)現不了一些與數據相關的錯誤。
白盒測試需要遵循的原則有：1. 保證一個模塊中的所有獨立路徑至少被測試一次；2. 所有邏輯值均需要測試真（true）和假（false）；兩種情況；3. 檢查程序的內部數據結構，保證其結構的有效性；4. 在上下邊界及可操作范圍內運行所有循環(huán)。
常用白盒測試方法：
靜態(tài)測試：不用運行程序的測試，包括代碼檢查、靜態(tài)結構分析、代碼質量度量、文檔測試等等，它可以由人工進行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具（Fxcop）自動進行。
動態(tài)測試：需要執(zhí)行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等。
白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發(fā)現錯誤的能力呈由弱到強的變化：
1.語句覆蓋每條語句至少執(zhí)行一次。
2.判定覆蓋每個判定的每個分支至少執(zhí)行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次。
12、Beta 測試與 alpha 測試的區(qū)別？
答：alpha 測試是公司內部在模擬實際操作環(huán)境下進行的一種驗收，公司內部會組織內部員工進行的測試，alpha 測試不能由程序員或者測試完成。
Beta 測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試，beta 測試不能由程序員或測試員完成。
13、寫過測試計劃或者是測試報告么？測試計劃包括哪些主要步驟和信息？測試報告包括哪些內容？
測試報告交付文檔有哪些？
答：寫過；1、測試計劃包括：項目信息、參與文檔、測試范圍、測試策略、測試時間人員安排、測試環(huán)境；2、測試報告包含：項目背景、參考資料、測試范圍、測試結果及缺陷分析、測試結論與建議，風險評估；3、交付文檔：主要是測試用例、測試計劃、測試報告。
14、對于重現率不高的 BUG 怎么處理？
先在出現問題的環(huán)境上盡量重現，保持瀏覽器環(huán)境、出現問題的特定賬號等的一致，多次嘗試仍然不能重現，也要記錄到 bug 平臺，將出現問題的特征步驟盡量描述清楚，附帶問題截圖及日志截圖、注明偶現；如果項目時間允許，bug 等級高，需要開發(fā)協(xié)助重現；如果時間不允許，記錄到 BUG 平臺后續(xù)在跟進。
15、bug 的生命周期？
答：Bug 的生命周期，就是一個 bug 被發(fā)現到這個 bug 被關閉的過程，生命周期中一般缺陷狀態(tài)：新建、指派、已解決、待驗、關閉
如果待驗證的 bug 在驗證是沒有解決好，我們需要重新打開（激活）→指派→已解決→待驗，循環(huán)這個過程，中間其他狀態(tài)：重新打開、拒絕、延期等
16、說一說 bug 的類型
Bug 類型
? 代碼錯誤 界面優(yōu)化 設計缺陷 配置相關 安裝部署 安全相關 性能問題 標準規(guī)范 測試腳本 其他
17、當你提了一個 bug，開發(fā)認為這不是 bug，怎么處理？
答：首先確認開發(fā)環(huán)境是否跟自己測試環(huán)境一致，確認在測試環(huán)境能重現，如果確認是缺陷跟開發(fā)保持有效溝通，如果是級別較低的建議性 bug，可以先記錄到 bug 平臺，先保留溝通。如果是 bug 級別較高的問題，對應需求文檔的預期結果跟開發(fā)說明，更有說服力；耐心講解 BUG 的危害，不行就找產品確認，確實是 BUG 注明情況并再次指派給開發(fā)
18、有沒有你印象深刻的 bug，bug 的原因？
答：身份證末尾 X 結尾的， 實名認證顯示成功，但是在后面提現的時候，會報錯，后面發(fā)現是保存到庫里面的，都是小寫 X 的，導致提現這邊不識別，印象深刻的原因是因為花了一定的時間去找到這個 bug，并且自己嘗試定位到原因，所以印象深刻。
19.作為測試工程師對需求分析的理解？（用戶場景）
a.了解需求背景及商業(yè)價值
明確了解背景，為什么要做這個需求，明白需求存在什么樣的商業(yè)價值后，才更明確該站在用戶哪個角度去判斷考慮該需求
b.站在用戶角度去分析需求
產品提出的功能，站在真實的用戶角度判斷該需求使用對用戶來說使用起來是否順暢，操作路徑是否多且復雜存在冗余，有什么風險
顯性需求：產品明確提出的需求
隱性需求：明確需求背后可能存在的需求（異常場景）
功能性需求：顯性及隱形需求里面相關業(yè)務
非功能性需求：用戶體驗，性能，可靠性，安全性，可維護性，可繼承性
c.站在產品的實現角度去分析該需求
該需求對繼承性需求在邏輯上是否存在沖突，原有邏輯是否存在沖突，遺漏
d.站在項目的角度去分析該需求
需求拆解的是否足夠細，是否可再拆解，是否可測試，優(yōu)先級如何，有什么風險
20.你在瀏覽器打開一個 web 項目網址，中間發(fā)生了什么？
網絡請求，域名解析、請求后端接口，獲取接口響應值，根據數據展示，關閉請求
1、DNS 解析
2、TCP 連接
3、發(fā)送 HTTP 請求
4、服務器處理請求并返回 HTTP 報文（apach，tomcat。nginx）
5、瀏覽器解析渲染頁面
6、連接結束
21.如何分析一個 bug 是前端還是后端的問題？
檢查接口，前端和后臺之間是通過接口文件相互聯系的，需要查看接口文件
檢查請求的數據是什么，反饋的數據又是什么
頁面可以直接 F12，或者抓包查看。如果發(fā)送的數據是正確的，但是后臺反饋的數據是不符合需求的，那就是后臺的問題；如果前端沒有請求接口或請求的時候發(fā)送數據與需求不符，那這個時候就是前端的問題了。
22、V 模型和 W 模型
測試和開發(fā)應該按照 W 模型的方式進行結合，測試和開發(fā)同步進行，能夠盡早發(fā)現軟件缺陷，降低軟件開發(fā)的成本。
在 V 模型中，測試過程被加在開發(fā)過程的后半部分，單元測試所檢測代碼的開發(fā)是否符合詳細設計的要求。集成測試所檢測此前測試過的各組成部分是否能完好地結合到一起。系統(tǒng)測試所檢測已集成在一起的產品是否符合系統(tǒng)規(guī)格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。V 模型的缺陷在于僅僅把測試過程作為在需求分析、系統(tǒng)設計及編碼之后的一個階段，忽視了測試對需求分析、系統(tǒng)設計的驗證，因此需求階段的缺陷很可能一直到后期的驗收測試才被發(fā)現，此時進行彌補將耗費大量人力物力資源。
相對于 V 模型，W 模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動。W 模型由兩個 V 字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關系。
W 模型強調：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發(fā)是同步進行的。W 模型有利于盡早地全面的發(fā)現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。
W 模型中測試的活動與軟件開發(fā)同步進行，測試的對象不僅僅是程序，還包括需求和設計，因此能夠盡早發(fā)現軟件缺陷，降低軟件開發(fā)的成本。
23.請回答集成測試和系統(tǒng)測試的區(qū)別，以及它們的應用場景主要是什么？區(qū)別：
1、計劃和用例編制的先后順序：從 V 模型來講，在需求階段就要制定系統(tǒng)測試計劃和用例，HLD 的時候做集成測試計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統(tǒng)測試計劃用例，再做集成。
2、用例的粒度：系統(tǒng)測試用例相對很接近用戶接受測試用例，集成測試用例比系統(tǒng)測試用例更詳細，而且對于接口部分要重點寫，畢竟要集成各個模塊或者子系統(tǒng)。
3、執(zhí)行測試的順序：先執(zhí)行集成測試，待集成測試出的問題修復之后，再做系統(tǒng)測試。
應用場景：
集成測試：完成單元測試后，各模塊聯調測試；集中在各模塊的接口是否一致、各模塊間的數據流和控制流是否按照設計實現其功能、以及結果的正確性驗證等等；可以是整個產品的集成測試，也可以是大模塊的集成測試；集成測試主要是針對程序內部結構進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結合。
系統(tǒng)測試：針對整個產品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個用戶的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各種性能參數的測試。系統(tǒng)測試測試軟件《需求規(guī)格說明書》中提到的功能是否有遺漏，是否正確的實現。做系統(tǒng)測試要嚴格按照《需求規(guī)格說明書》，以它為標準。測試方法一般都使用黑盒測試法。
24、請你說一說 web 測試和 app 測試的不同點系統(tǒng)架構方面：
web 項目，一般都是 b/s 架構，基于瀏覽器的
app 項目，則是 c/s 的，必須要有客戶端，用戶需要安裝客戶端。
web 測試只要更新了服務器端，客戶端就會同步會更新。App 項目則需要客戶端和服務器都更新。
性能方面:
web 頁面主要會關注響應時間
而 app 則還需要關心流量、電量、CPU、GPU、Memory 這些。
它們服務端的性能沒區(qū)別，都是一臺服務器。
兼容方面：
web 是基于瀏覽器的，所以更傾向于瀏覽器和電腦硬件，電腦系統(tǒng)的方向的兼容
app 測試則要看分辨率，屏幕尺寸，還要看設備系統(tǒng)。
web 測試是基于瀏覽器的所以不必考慮安裝卸載。
而 app 是客戶端的，則必須測試安裝、更新、卸載。除了常規(guī)的安裝、更新、卸載還要考慮到異常場景。包括安裝時的中斷、弱網、安裝后刪除安裝文件 。
此外 APP 還有一些專項測試：如網絡、適配性。
25 請你說一說簡單用戶界面登陸過程都需要做哪些分析參考回答：一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤信息。
3.登錄成功后能否能否跳轉到正確的頁面
4.用戶名和密碼，如果太短或者太長，應該怎么處理
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
6.記住用戶名的功能
7.登陸失敗后，不能記錄密碼的功能
8.用戶名和密碼前后有空格的處理
9.密碼是否非明文顯示顯示，使用星號圓點等符號代替。
10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用
11.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
13.什么都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox 和按鈕是否整齊。
2.testbox 和按鈕的長度，高度是否復合要求。
界面的設計風格是否與 UI 的設計風格統(tǒng)一。
界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功后生成的 Cookie，是否是 httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發(fā)送給 Web 服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用 javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽 SQL 注入攻擊。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止 XSS 攻擊）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。
是否支持多用戶在同一機器上登錄。
同一用戶能否在多臺機器上登錄。
五、可用性測試
是否可以全用鍵盤操作，是否有快捷鍵。
輸入用戶名，密碼后按回車，是否可以登陸。
輸入框能否可以以 Tab 鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如 Windows, Mac。
3.移動設備上是否正常工作，比如 Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
不同語言環(huán)境下，頁面的顯示是否正確。
26.如果做一個杯子的檢測，你如何測試參考回答：1.功能
（1）水倒水杯容量的一半
（2）水倒規(guī)定的安全線
（4）水杯容量刻度與其他水杯一致
（5）蓋子擰緊水倒不出來
（6）燙手驗證
2.性能
（1）使用最大次數或時間
（2）掉地上不易損壞
（3）蓋子擰到什么程度水倒不出來
（4）保溫時間長
（5）杯子的耐熱性
（6）杯子的耐寒性
（7）長時間放置水不會漏
（8）杯子上放置重物達到什么程度杯子會被損壞
3.界面
（1）外觀完整、美觀
（2）大小與設計一樣（高、寬、容量、直徑）
（3）拿著舒服
（4）材質與設計一樣
（5）杯子上的圖案掉落
（6）圖案遇水溶解
4.安全
（1）杯子使用的材質毒或細菌的驗證
（2）高溫材質釋放毒性
（3）低溫材質釋放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）攜帶方便
（4）使用簡單，容易操作
（5）防滑措施
6.兼容性
（1）杯子能夠容納果汁、白水、酒精、汽油等。
7.震動測試
（1）杯子加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。
8.可移植性
（1）杯子在不同地方、溫度環(huán)境下都可以正常使用。
27.請你來說一下購物車的測試用例參考回答：界面測試
? 界面布局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區(qū)分明顯。
2.功能測試
未登錄時：
? 將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數量增加；
? 點擊購物車菜單，頁面跳轉到登錄頁面。
登錄后：
? 所有鏈接是否跳轉正確；
? 商品是否可以成功加入購物車；
? 購物車商品總數是否有限制；
? 商品總數是否正確；
? 全選功能是否好用；
? 刪除功能是否好用；
? 填寫委托單功能是否好用；
? 委托單中填寫的價格是否正確顯示；
? 價格總計是否正確；
? 商品文字太長時是否顯示完整；
? 店鋪名字太長時是否顯示完整；
? 創(chuàng)新券商品是否打標；
? 購物車中下架的商品是否有特殊標識；
? 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；
? 是否支持 TAB、ENTER 等快捷鍵；
? 商品刪除后商品總數是否減少；
? 購物車結算功能是否好用。
3.兼容性測試
? 不同瀏覽器測試。
4.易用性測試
? 刪除功能是否有提示；是否有回到頂部的功能；商品過多時結算按鈕是否可以浮動顯示。
5.性能測試
? 壓力測試；并發(fā)測試。
28.請你進行一下弱網模擬方法一：charles 弱網模擬
使用 chrome 的 webview 調試工具，缺點是只適用于 web 頁面的弱網模擬。
方法三：iOS 手機自帶 Network Link Conditioner 弱網模擬
iPhone 手機打開開發(fā)者選項，具體參考：
設置-開發(fā)者選項 > Network Link Conditioner 入口。
系統(tǒng)已經內置常見網絡配置，也可以增加自定義配置。
具體配置參數：
in Bandwidth 下行帶寬，即下行網絡速度
In packet loss 下行丟包率
in delay 下行延遲，單位 ms
out bandwidth 上行帶寬
out packet loss 上行丟包率
out delay 上行延遲
DNS delay DNS 解析延遲
protocol 支持 Any，IPV4、IPV6
interface 支持 Any，WI-Fi，cellular（蜂窩網）
總結：
最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：938856006資料在裙里，需要可以自取
這些資料，對于【軟件測試】的朋友來說應該是最全面最完整的備戰(zhàn)倉庫，這個倉庫也陪伴上萬個測試工程師們走過最艱難的路程，希望也能幫助到你!
?既然都看到這里啦，請你幫個忙：
1、點贊，讓更多小伙伴看到；
2、關注我，持續(xù)更新測試干貨。
