本篇內容來源於網絡
1. 什么是軟件測試?
答:軟件測試是為了發現錯誤而執行程序的過程。
2. 軟件測試的目的?
答;測試的目的是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正錯誤和缺陷提高軟件質量，回避軟件發布后由於潛在的軟件缺陷和錯誤造成的隱患帶來的商業風險。
3. 什么是需求文檔測試?
答:主要測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現;
4. 什么是設計文檔測試?
答:測試設計是否符合全部需求以及設計是否合理。
5. 請問你了解什么測試方法
（黑盒測試方法）等價類划分，邊界值分析，錯誤推測，因果圖法，
（白盒測試方法）邏輯覆蓋法，程序插樁技術，基本路徑法，符號測試，錯誤驅動測試
6. 測試的類型
測試分為功能測試和非功能測試，非功能測試又可以分為性能測試、壓力測試、容量測試、健壯性測試、安全性測試、可靠性測試、恢復性測試、備份測試、協議測試、兼容性測試、可用性測試、配置測試、GUI測試。
7. 什么是驅動模塊？
答:驅動模塊在大多數場合稱為"主程序"，它接收測試數據並將這些數據傳遞到被測試模塊.單元測試一個函數單元時，被測單元本身是不能獨立運行的，需要為其傳送數據，為此寫驅動。驅動模塊主要完成以下事情：
- 接受測試輸入;
- 對輸入進行判斷;
- 將輸入傳給被測單元，驅動被測單元執行;
- 接受被測單元執行結果，並對結果進行判斷;
- 將判斷結果作為用例執行結果輸出測試報告。
8. 什么是樁模塊?
答:比如對函數A做單元測試時，被測的函數單元下還包括了一個函數B，為了更好的錯誤，定位錯誤，就要為函數B寫樁，來模擬函數B的功能，保證其正確。
9. 軟件測試應該划分幾個階段?簡述各個階段應重點測試的點?各個階段的含義?
答:大體上來說可分為單元測試,集成測試,系統測試,驗收測試。每個階段又分為以下五個步驟: 測試計划，測試設計，用例設計，執行結果，測試報告。
單元測試集中在每個模塊(函數)上，保證源代碼的正確性，主要用白盒測試方法。然后是集成測試，集成測試主要考慮各模塊之間是否存在問題，主要采用灰盒測試方法。系統測試的目的是確保整個系統的運行以及與其他軟件的兼容性。系統測試包括：功能測試，性能測試，可靠性測試，安全性測試等，只需要進行黑盒測試方法。
驗收測試是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。它的測試數據通常是系統測試的測試數據的子集。驗收測試包括正式驗收測試，非正式驗收測試：Alpha測試和Beta測試。
Alpha測試(α測試)是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試,Alpha測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評價軟件產品的功能、可使用性、可靠性、性能和支持。尤其注重產品的界面和特色。
Beta測試(β測試)是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。在Beta測試中，由用戶記下遇到的所有問題，包括真實的以及主管認定的，定期向開發者報告，開發者在綜合用戶的報告后，做出修改，最后將軟件產品交付給全體用戶使用。
10. 自頂向下測試和自底向上測試
自頂向下測試：是從程序的初始模塊開始測試。
（1）該方法會在早期發現頂層的錯誤。
（2）早期的程序框架可以進行演示
（3）需要開發樁模塊輔助測試。有些甚至需要多個樁模塊輔助，加大了樁模塊本來的錯誤影響。
（4）測試完一個上層模塊后，挑選哪個模塊作為下一個測試模塊，以及測試的順序沒有唯一的界定標准。
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
自底向上測試：是從程序的底層模塊開始測試。
（1）I/O操作可以提前測試，更好提交測試用例。
（2）測試后比較容易觀察輸出。
（3）需要開發驅動模塊。
（4）直到最后一個模塊提交，程序才能完整的系統測試。
優點：對底層組件行為較早驗證；工作最初可以並行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
11. 請你回答一下單元測試、集成測試、系統測試、驗收測試、回歸測試這幾步中最重要的是哪一步？
這些測試步驟分別在軟件開發的不同階段對軟件進行測試，我認為對軟件完整功能進行測試的系統測試很重要，因為此時單元測試和集成測試已完成，能夠對軟件所有功能進行功能測試，能夠覆蓋系統所有聯合的部件，是針對整個產品系統進行的測試，能夠驗證系統是否滿足了需求規格的定義，因此我認為系統測試很重要。（言之有理即可）
12. 什么是白盒測試?
白盒測試，又稱邏輯驅動測試,結構測試。它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟件驗證。“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。
常用白盒測試方法： 靜態測試：不用運行程序的測試，包括代碼檢查、靜態結構分析、代碼質量度量、文檔測試等等，它可以由人工進行，也可以借助軟件工具（Fxcop）自動進行。動態測試：需要執行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等。
白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標准發現錯誤的能力呈由弱到強的變化：
- 語句覆蓋每條語句至少執行一次。
- 判定覆蓋每個判定的每個分支至少執行一次。
- 條件覆蓋每個判定的每個條件應取到各種可能的值。
- 判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
- 條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
- 路徑覆蓋使程序中每一條可能的路徑至少執行一次。
13. 什么是黑盒測試?
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如數據庫或文件）的完整性。
“黑盒”法着眼於程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
常用的黑盒測試方法有：等價類划分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
14. 設計用例的方法、依據有那些?
白盒測試用例設計有如下方法:基本路徑測試\邊界值分析\覆蓋測試\循環測試\數據流測試\程序插樁測試\變異測試。這時候依據就是詳細設計說明書及其代碼結構
黑盒測試用例設計方法:基於用戶需求的測試\功能圖分析方法\等價類划分方法\邊界值分析方法\錯誤推測方法\因果圖方法\判定表驅動分析方法\正交實驗設計方法.依據是用戶需求規格說明書,詳細設計說明書。
既可以用於黑盒測試，也可以用於白盒測試的方法的是（邊界值分析）
15. 如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎?(白盒與黑盒的區別)
答:任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。 白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
- 是否有不正確或遺漏的功能?
- 在接口上，輸入是否能正確的接受?能否輸出正確的結果?
- 是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤?
- 性能上是否能夠滿足要求?
- 是否有初始化或終止性錯誤?
軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
- 對程序模塊的所有獨立的執行路徑至少測試一遍。
- 對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
- 在循環的邊界和運行的界限內執行循環體。
- 測試內部數據結構的有效性等等。
以上事實說明，軟件測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程序只能進行少量(相對於窮舉的巨大數量而言)的有限的測試，在未發現錯誤時，不能說明程序中沒有錯誤。
16. 什么是靜態測試?
答:通過運行程序測試軟件稱為動態測試.通過評審文檔、閱讀代碼等方式測試軟件稱為靜態測試,在動態測試中,通常使用白盒測試和黑盒測試從不同的角度設計測試用例,查找軟件代碼中的錯誤.
靜態測試方法是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。
17. 什么是回歸測試?
答: 回歸測試是在軟件維護階段，對軟件進行修改之后進行的測試。其目的是檢驗對軟件進行的修改是否正確。是在程序有修改的情況下，保證原有功能正常的一種測試策略和方法。
18. 軟件的缺陷等級應如何划分?
軟件缺陷的等級可以用嚴重性和優先級來描述；
嚴重性：衡量缺陷對客戶滿意度影響的滿意程度，分為：
1,致命錯誤，可能導致本模塊以及其他相關的模塊異常，死機等問題；
常見的有嚴重花屏、內存泄漏、用戶數據丟失或破壞、系統崩潰/死機/凍結、模塊無法啟動或異常退出、嚴重的數值計算錯誤、功能設計與需求嚴重不符、其它導致無法測試的錯誤， 如服務器500錯誤。
2.嚴重錯誤，問題局限在本模塊，導致模塊功能失常或異常退出；
常見的有：功能未實現，功能錯誤、系統刷新錯誤、數據通訊錯誤、輕微的數值計算錯誤、影響功能及界面的錯誤字或拼寫錯誤。
3.一般錯誤，模塊功能部分失效；
常見的有：操作界面錯誤，邊界條件錯誤，提示信息錯誤，長時間操作無進度提示，系統未優化，兼容性問題。
4.建議模塊，有問題提出人對測試模塊的改進建議；
優先級：缺陷被修復的緊急程度：
- 立即解決（P1級）：缺陷導致系統功能幾乎不能使用或者測試不能繼續，需立即修復；
- 高優先級（P2級）：缺陷嚴重，影響測試，需優先考慮；
- 正常排隊（P3級）：缺陷需要正常排隊等待修復；
- 低優先級（P4級）：缺陷可以在有時間的時候被糾正；
19. 針對缺陷采取怎樣的管理措施?
- 要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的都可。
- 根據缺陷的生命周期，考慮缺陷提交的管理、缺陷狀態的管理和缺陷分析的管理。
- 所有發現的缺陷(不管是測試發現的還是走讀代碼發現的)都必須全部即時的、准確的提交到缺陷管理工具中，這是缺陷提交的管理。
- 缺陷提交后，需要即時的指派給相應的開發人員，提交缺陷的人需要密切注意缺陷的狀態，幫助缺陷的盡快解決。缺陷解決后需要即時對缺陷的修復進行驗證。這樣的目的有兩個：一個是讓缺陷盡快解決;二是方便后面缺陷的分析(保證缺陷相關的信息准確，如齡期等)，這是缺陷狀態的管理。
- 為了更好的改進開發過程和測試過程，需要對缺陷進行分析，總結如缺陷的類別、缺陷的齡期分布等信息，這是缺陷分析的管理。
20. 描述使用bugzilla缺陷管理工具對軟件缺陷(BUG)跟蹤的管理的流程
- 測試人員或開發人員發現bug后，判斷屬於哪個模塊的問題，填寫bug報告后，系統會自動通過Email通知項目組長或直接通知開發者。
- 經驗證無誤后，修改狀態為VERIFIED.待整個產品發布后，修改為CLOSED.
- 還有問題，REOPENED，狀態重新變為“New"，並發郵件通知。
- 項目組長根據具體情況，重新reassigned分配給bug所屬的開發者。
- 若是，進行處理，resolved並給出解決方法。(可創建補丁附件及補充說明)
- 開發者收到Email信息后，判斷是否為自己的修改范圍。
- 若不是，重新reassigned分配給項目組長或應該分配的開發者。
- 測試人員查詢開發者已修改的bug，進行重新測試。
21. 請說一下手動測試與自動化測試的優缺點
手工測試缺點：
- 重復的手工回歸測試，代價昂貴、容易出錯。
- 依賴於軟件測試人員的能力。
- 手工測試優點：
- 測試人員具有經驗和對錯誤的猜測能力。
- 測試人員具有審美能力和心理體驗。
- 測試人員具有是非判斷和邏輯推理能力。
自動化測試的優點：
- 對程序的回歸測試更方便。這可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是非常明顯的。由於回歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。
- 可以運行更多更繁瑣的測試。是可以在較少的時間內運行更多的測試。
- 可以執行一些手工測試困難或不可能進行的測試。比如，對於大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。
- 更好地利用資源。將繁瑣的任務自動化，可以提高准確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合於自動測試，僅適合於手工測試，將可自動測試的測試自動化后，可以讓測試人員專注於手工測試部分，提高手工測試的效率。
- 測試具有一致性和可重復性。由於測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重復的效果。
- 測試的復用性。由於自動測試通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。
- 增加軟件信任度。由於測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決於測試的設計質量。一旦軟件通過了強有力的自動測試后，軟件的信任度自然會增加。
自動化測試的缺點：
- 不能取代手工測試
- 手工測試比自動測試發現的缺陷更多
- 對測試質量的依賴性極大
- 測試自動化不能提高有效性
- 測試自動化可能會制約軟件開發。由於自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發。
- 工具本身並無想像力
22. 你覺得測試和開發需要怎么結合才能使軟件的質量得到更好的保障
測試和開發應該按照W模型的方式進行結合，測試和開發同步進行，能夠盡早發現軟件缺陷，降低軟件開發的成本。
W模型強調：測試伴隨着整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利於及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。
需求測試->概要設計測試->詳細設計測試->單元測試->集成測試->系統測試->驗收測試
23. 請問你覺得測試項目具體工作是什么？
- 搭建測試環境
- 撰寫測試用例
- 執行測試用例
- 寫測試計划，測試報告
- 測試，並提交BUG表單
- 跟蹤bug修改情況
- 執行自動化測試，編寫腳本，執行，分析，報告
- 進行性能測試，壓力測試等其他測試，執行，分析，調優，報告
24. 請你說一下軟件質量的六個特征
功能特征、可靠特征、易用特征、效率特征、可維護特征、可移植特征
25. 描述測試工具的功能？
LoadRunner-負載壓力測試：預測系統性能。
JMeter+Badboy：基於JAVA的壓力測試工具，Badboy用來進行腳本的錄制
功能測試：通過自動錄制、檢測和回放用戶的應用操作。將輸出記錄同預先給定的記錄比較。
Junit：白盒測試工具：針對代碼測試
測試管理工具：對測試需求、計划、用例、實施進行管理
測試輔助工具：本身不執行，可以生成測試數據，為測試提供數據准備
負載壓力測試：LoadRunner:預測系統行為和性能的工業標准級負載測試工具。模擬上千萬用戶同時實施並發操作，來實時監控可能發生的問題。
功能測試： QTP(quicktest professional):自動測試工具
白盒測試：C++ TEST（做C和C++的白盒測試）、JUnit（Java白盒測試）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
測試輔助工具：SVN
測試實例設計
26. 請你說一下app性能測試的指標
1、內存：
內存消耗測試節點的設計目標是為了讓應用不占用過多的系統資源，且及時釋放內存，保障整個系統的穩定性。當然關於內存測試，在這里我們需要引入幾個概念：空閑狀態、中等規格、滿規格。
空閑狀態指打開應用后，點擊home鍵讓應用后台運行，此時應用處於的狀態叫做空閑；中等規格和滿規格指的是對應用的操作時間的間隔長短不一，中等規格時間較長，滿規格時間較短。
內存測試中存在很多測試子項，清單如下：
●空閑狀態下的應用內存消耗；
●中等規格狀態下的應用內存消耗；
●滿規格狀態下的應用內存消耗；
●應用內存峰值；
●應用內存泄露；
●應用是否常駐內存；
●壓力測試后的內存使用。
2、CPU：
使用Android提供的view plaincopy在CODE上查看代碼片派生到我的代碼片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt來獲取；
使用top命令view plaincopy在CODE上查看代碼片派生到我的代碼片
adbshell top |grep packagename>/address/CPU.txt來獲取。
3、流量：
網絡流量測試是針對大部分應用而言的，可能還有部分應用會關注網速、弱網之類的測試。
流量測試包括以下測試項：
應用首次啟動流量提示；
應用后台連續運行2小時的流量值；
應用高負荷運行的流量峰值。
4、電量：
●測試手機安裝目標APK前后待機功耗無明顯差異；
●常見使用場景中能夠正常進入待機，待機電流在正常范圍內；
●長時間連續使用應用無異常耗電現象。
5、啟動速度：
第一類：首次啟動–應用首次啟動所花費的時間；
第二類：非首次啟動–應用非首次啟動所花費的時間；
第三類：應用界面切換–應用界面內切換所花費的時間。
6、滑動速度、界面切換速度
7、與服務器交互的網絡速度
27. 請你說一說app測試的工具
功能測試自動化
a) 輕量接口自動化測試
jmeter，
b) APP UI層面的自動化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator，
iOS:基於Instrument的iOS UI自動化，
性能測試
a) Web前端性能測試
網絡抓包工具：Wireshark
網頁文件大小
Webpagetest pagespeed insight chrome adb
b) APP端性能測試
Android內存占用分析：MAT
iOS內存問題分析：ARC模式
Android WebView性能分析：
iOS WebView性能分析
c) 后台服務性能測試
負載、壓力、耐久性、可拓展性、基准
工具：apacheAB、Jmeter、LoadRunner，
專項測試
a) 兼容性測試
手工測試：操作系統，分辨率，rom，網絡類型
雲平台：testin，腳本編寫，Android。
b) 流量測試
Android自帶的流量管理，
iOS自帶的Network tcpdump抓包
WiFi代理抓包：Fiddler
流量節省方法：壓縮數據，json優於xml；WebP優於傳統的JPG，PNG；控制訪問的頻次；只獲取必要的數據；緩存；
c) 電量測試
基於測試設備的方法，購買電量表進行測試。
GSam Battery Monitoe Pro
iOS基於Instrument Energy工具
d) 弱網絡測試
手機自帶的網絡狀況模擬工具
基於代理的弱網絡的模擬:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner
28. 請你說一說bug的周期，以及描述一下不同類別的bug
1、New:（新的）
當某個“bug”被第一次發現的時候，測試人員需要與項目負責人溝通以確認發現的的確是一個bug，如果被確認是一個bug，就將其記錄下來，並將bug的狀態設為New
2、Assigned（已指派的）
當一個bug被指認為New之后，將其反饋給開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為“Assigned”
3、Open（打開的）
一旦開發人員開始處理bug的時候，他（她）就將這個bug的狀態設置為“Open”，這表示開發人員正在處理這個“bug”
4、Fixed（已修復的）
當開發人員進行處理（並認為已經解決）之后，他就可以將這個bug的狀態設置為“Fixed”並將其提交給開發組的負責人，然后開發組的負責人將這個bug返還給測試組
5、Pending Reset（待在測試的）
當bug被返還到測試組后，我們將bug的狀態設置為Pending Reset”
6、Reset(再測試)
測試組的負責人將bug指定給某位測試人員進行再測試，並將bug的狀態設置為“Reset”
7、Closed（已關閉的）
如果測試人員經過再次測試之后確認bug 已經被解決之后，就將bug的狀態設置為“Closed”
8、Reopen（再次打開的）
如果經過再次測試發現bug（指bug本身而不是包括因修復而引發的新bug）仍然存在的話，測試人員將bug再次傳遞給開發組，並將bug的狀態設置為“Reopen”
9、Pending Reject（拒絕中）
如果測試人員傳遞到開發組的bug被開發人員認為是正常行為而不是bug時，這種情況下開發人員可以拒絕，並將bug的狀態設置為“Pending Reject”
10、Rejected(被拒絕的)
測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之后認為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設置為“Rejected”
11、Postponed（延期）
有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試數據，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設置為“Postponed“
不同的Bug類型：
• 代碼錯誤
• 界面優化
• 設計缺陷
• 配置相關
• 安裝部署
• 安全相關
• 性能問題
• 標准規范
• 測試腳本
• 其他
29. 請問你怎么測試網絡協議
協議測試包括四種類型的測試
- 一致性測試：檢測協議實現本身與協議規范的符合程度
- 互操作性測試：基於某一協議檢測不同協議實現間互操作互通信的能力
- 性能測試：檢測協議實現的性能指標，比如數據傳輸速度，連接時間，執行速度，吞吐量，並發度，
- 健壯性測試：檢測協議是現在各種惡劣環境下運行的能力，比如注入干擾報文，通信故障，信道被切斷。
30. 請你說一說簡單用戶界面登陸過程都需要做哪些分析
一、功能測試
- 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。
- 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，並且提示相應的錯誤信息。
- 登錄成功后能否能否跳轉到正確的頁面
- 用戶名和密碼，如果太短或者太長，應該怎么處理
- 用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
- 記住用戶名的功能
- 登陸失敗后，不能記錄密碼的功能
- 用戶名和密碼前后有空格的處理
- 密碼是否非明文顯示顯示，使用星號圓點等符號代替。
- 牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用
- 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
- 輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
- 什么都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
- 布局是否合理，testbox和按鈕是否整齊。
- testbox和按鈕的長度，高度是否復合要求。
- 界面的設計風格是否與UI的設計風格統一。
- 界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
- 打開登錄頁面，需要的時間是否在需求要求的時間內。
- 輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
- 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
- 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。
- 用戶名和密碼是否通過加密的方式，發送給Web服務器。
- 用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。
- 用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊。
- 用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊）。
- 防止暴力破解，檢測是否有錯誤登陸的次數限制。
- 是否支持多用戶在同一機器上登錄。
- 同一用戶能否在多台機器上登錄。
五、可用性測試
是否可以全用鍵盤操作，是否有快捷鍵。輸入用戶名，密碼后按回車，是否可以登陸。輸入框能否可以以Tab鍵切換。
六、兼容性測試
- 不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
- 同種瀏覽器不同版本下能否顯示正常且功能正常。
- 不同的平台是否能正常工作，比如Windows, Mac。
- 移動設備上是否正常工作，比如Iphone, Andriod。
- 不同的分辨率下顯示是否正常。
七、本地化測試
不同語言環境下，頁面的顯示是否正確。
(說明：內容來源於網絡，基本上都是博主學習時看到一些容易理解的知識點，如果想要查看原文，可以點擊鏈接查看)