測試基本知識

1、請你分別介紹一下單元測試、集成測試、系統測試、驗收測試、回歸測試：

（1）單元測試：完成最小的軟件設計單元（模塊）的驗證工作，目標是確保模塊被正確的編碼，使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模塊內的錯誤，通常情況下是白盒的，對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早的發現和解決不易顯現的錯誤。

（2）集成測試：通過測試發現與模塊接口有關的問題。目標是把通過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構，應當避免一次性的集成（除非軟件規模很小），而采用增量集成。

自頂向下集成：模塊集成的順序是首先集成主模塊，然后按照控制層次結構向下進行集成，隸屬于主模塊的模塊按照深度優先或廣度優先的方式集成到整個結構中去。

自底向上集成：從原子模塊開始來進行構造和測試，因為模塊是自底向上集成的，進行時要求所有隸屬于某個給頂層次的模塊總是存在的，也不再有使用穩定測試樁的必要。

（3）系統測試：是基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。系統測試的對象不僅僅包括需要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此，必須將系統中的軟件與各種依賴的資源結合起來，在系統實際運行環境下來進行測試。

（4）回歸測試：回歸測試是指在發生修改之后重新測試先前的測試用例以保證修改的正確性。理論上，軟件產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新軟件版本上再次出現。根據修復好了的缺陷再重新進行測試。回歸測試的目的在于驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。

（5）驗收測試：驗收測試是指系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。驗收測試包括測試和測試。

?測試：是由用戶在開發者的場所來進行的，在一個受控的環境中進行。

?測試：由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測試中遇到的問題并報告給開發者，開發者對系統進行最后的修改，并開始準備發布最終的軟件。

2、請你回答一下單元測試、集成測試、系統測試、驗收測試、回歸測試這幾步中最重要的是哪一步

這些測試步驟分別在軟件開發的不同階段對軟件進行測試，我認為對軟件完整功能進行測試的系統測試很重要，因為此時單元測試和集成測試已完成，能夠對軟件所有功能進行功能測試，能夠覆蓋系統所有聯合的部件，是針對整個產品系統進行的測試，能夠驗證系統是否滿足了需求規格的定義，因此我認為系統測試很重要。

3、請回答集成測試和系統測試的區別，以及它們的應用場景主要是什么？

區別：

（1）計劃和用例編制的先后順序：從V模型來講，在需求階段就要制定系統測試計劃和用例，HLD的時候做集成測試計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統測試計劃用例，再做集成。

（2）用例的粒度：系統測試用例相對很接近用戶接受測試用例，集成測試用例比系統測試用例更詳細，而且對于接口部分要重點寫，畢竟要集成各個模塊或者子系統。

（3）執行測試的順序：先執行集成測試，待集成測試出的問題修復之后，再做系統測試。

應用場景：

（1）集成測試：完成單元測試后，各模塊聯調測試；集中在各模塊的接口是否一致、各模塊間的數據流和控制流是否按照設計實現其功能、以及結果的正確性驗證等等；可以是整個產品的集成測試，也可以是大模塊的集成測試；集成測試主要是針對程序內部結構進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結合。

（2）系統測試：針對整個產品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個用戶的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各種性能參數的測試。系統測試測試軟件《需求規格說明書》中提到的功能是否有遺漏，是否正確的實現。做系統測試要嚴格按照《需求規格說明書》，以它為標準。測試方法一般都使用黑盒測試法。

4、請說一說黑盒與白盒的測試方法

黑盒測試：

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。

“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。

白盒測試：

白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程序的控制結構設計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設計規范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與數據相關的錯誤。

白盒測試需要遵循的原則有：

（1）保證一個模塊中的所有獨立路徑至少被測試一次；

（2）所有邏輯值均需要測試真（true）和假（false）；兩種情況；

（3）檢查程序的內部數據結構，保證其結構的有效性；

（4）在上下邊界及可操作范圍內運行所有循環。

常用白盒測試方法：

靜態測試：不用運行程序的測試，包括代碼檢查、靜態結構分析、代碼質量度量、文檔測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具（Fxcop）自動進行。

動態測試：需要執行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等。

白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：

（1）語句覆蓋每條語句至少執行一次。

（2）判定覆蓋每個判定的每個分支至少執行一次。

（3）條件覆蓋每個判定的每個條件應取到各種可能的值。

（4）判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

（5）條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。

（6）路徑覆蓋使程序中每一條可能的路徑至少執行一次。

5、請說一下手動測試與自動化測試的優缺點

手工測試缺點：

（1）重復的手工回歸測試，代價昂貴、容易出錯。

（2）依賴于軟件測試人員的能力。

手工測試優點：

（1）測試人員具有經驗和對錯誤的猜測能力。

（2）測試人員具有審美能力和心理體驗。

（3）測試人員具有是非判斷和邏輯推理能力。

自動化測試的優點：

（1）對程序的回歸測試更方便。這可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是非常明顯的。由于回歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。

（2）可以運行更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時間內運行更多的測試。

（3）可以執行一些手工測試困難或不可能進行的測試。比如，對于大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。

（4）更好地利用資源。將繁瑣的任務自動化，可以提高準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合于自動測試，僅適合于手工測試，將可自動測試的測試自動化后，可以讓測試人員專注于手工測試部分，提高手工測試的效率。

（5）測試具有一致性和可重復性。由于測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重復的效果。

（6）測試的復用性。由于自動測試通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。

（7）增加軟件信任度。由于測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決于測試的設計質量。一旦軟件通過了強有力的自動測試后，軟件的信任度自然會增加。

自動化測試的缺點：

（1）不能取代手工測試

（2）手工測試比自動測試發現的缺陷更多

（3）對測試質量的依賴性極大

（4）測試自動化不能提高有效性

（5）測試自動化可能會制約軟件開發。由于自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發。

（6）工具本身并無想像力

6、你覺得自動化測試有什么意義，都需要做些什么

自動化測試的意義在于

（1）可以對程序的新版本自動執行回歸測試

（2）可以執行手工測試困難或者不可能實現的測試，如壓力測試，并發測試，

（3）能夠更好的利用資源，節省時間和人力

執行自動化測試之前首先判斷這個項目是不是和推廣自動化測試，然后對項目做需求分析，指定測試計劃，搭建自動化測試框架，設計測試用例，執行測試，評估

7、請你回答一下測試的相關流程是什么？

測試最規范的過程如下

需求測試->概要設計測試->詳細設計測試->單元測試->集成測試->系統測試->驗收測試

8、請你說一下如何寫測試用例

（1）測試人員盡早介入，徹底理解清楚需求，這個是寫好測試用例的基礎

（2）如果以前有類似的需求，可以參考類似需求的測試用例，然后還需要看類似需求的bug情況

（3）清楚輸入、輸出的各種可能性，以及各種輸入的之間的關聯關系，理解清楚需求的執行邏輯，通過等價類、邊界值、判定表等方法找出大部分用例

（4）找到需求相關的一些特性，補充測試用例

（5）根據自己的經驗分析遺漏的測試場景

（6）多總結類似功能點的測試點，才能夠寫出質量越來越高的測試用例

（7）書寫格式一定要清晰

9、請問你覺得測試項目具體工作是什么？

搭建測試環境——撰寫測試用例——執行測試用例——寫測試計劃，測試報告——測試，并提交BUG表單——跟蹤bug修改情況——執行自動化測試，編寫腳本，執行，分析，報告——進行性能測試，壓力測試等其他測試，執行，分析，調優，報告

10、請你說一說測試用例的邊界

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

常見的邊界值：

（1）對16-bit 的整數而言 32767 和 -32768 是邊界

（2）屏幕上光標在最左上、最右下位置

（3）報表的第一行和最后一行

（4）數組元素的第一個和最后一個

（5）循環的第 0 次、第 1 次和倒數第 2 次、最后一次

11、請你說一下軟件質量的六個特征

按照軟件質量國家標準GB-T8566--2001G，軟件質量可以用下列特征來評價：

（1）功能特征：與一組功能及其指定性質有關的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。

（2）可靠特征：在規定的一段時間和條件下，與軟件維持其性能水平的能力有關的一組屬性。

（3）易用特征：由一組規定或潛在的用戶為使用軟件所需作的努力和所作的評價有關的一組屬性。

（4）效率特征：與在規定條件下軟件的性能水平與所使用資源量之間關系有關的一組屬性。

（5）可維護特征：與進行指定的修改所需的努力有關的一組屬性。

（6）可移植特征：與軟件從一個環境轉移到另一個環境的能力有關的一組屬性。

12、請你說一下設計測試用例的方法

黑盒測試：

（1）等價類劃分

等價類劃分是將系統的輸入域劃分為若干部分，然后從每個部分選取少量代表性數據進行測試。等價類可以劃分為有效等價類和無效等價類，設計測試用例的時候要考慮這兩種等價類。

（2）邊界值分析法

邊界值分析法是對等價類劃分的一種補充，因為大多數錯誤都在輸入輸出的邊界上。邊界值分析就是假定大多數錯誤出現在輸入條件的邊界上，如果邊界附件取值不會導致程序出錯，那么其他取值出錯的可能性也就很小。

邊界值分析法是通過優先選擇不同等價類間的邊界值覆蓋有效等價類和無效等價類來更有效的進行測試，因此該方法要和等價類劃分法結合使用。

（3）正交試驗法

正交是從大量的試驗點中挑選出適量的、有代表性的點。正交試驗設計是研究多因素多水平的一種設計方法，他是一種基于正交表的高效率、快速、經濟的試驗設計方法。

（4）狀態遷移法

狀態遷移法是對一個狀態在給定的條件內能夠產生需要的狀態變化，有沒有出現不可達的狀態和非法的狀態，狀態遷移法是設計足夠的用例達到對系統狀態的覆蓋、狀態、條件組合、狀態遷移路徑的覆蓋。

（5）流程分析法

流程分析法主要針對測試場景類型屬于流程測試場景的測試項下的測試子項進行設計，這是從白盒測試中路徑覆蓋分析法借鑒過來的一種很重要的方法。

（6）輸入域測試法

輸入域測試法是針對輸入會有各種各樣的輸入值的一個測試，他主要考慮?極端測試、中間范圍測試，特殊值測試 。

（7）輸出域分析法

輸出域分析法是對輸出域進行等價類和邊界值分析，確定是要覆蓋的輸出域樣點，反推得到應該輸入的輸入值，從而構造出測試用例，他的目的是為了達到輸出域的等價類和邊界值覆蓋。

（8）判定表分析法

判定表是分析和表達多種輸入條件下系統執行不同動作的工具，他可以把復雜的邏輯關系和多種條件組合的情況表達的即具體又明確；

（9）因果圖法

因果圖是用于描述系統輸入輸出之間的因果關系、約束關系。因果圖的繪制過程是對被測系統的外部特征的建模過程，根據輸入輸出間的因果圖可以得到判定表，從而規劃出測試用例。

（10）錯誤猜測法

錯誤猜測法主要是針對系統對于錯誤操作時對于操作的處理法的猜測法，從而設計測試用例

（11）異常分析法

異常分析法是針對系統有可能存在的異常操作，軟硬件缺陷引起的故障進行分析，分析發生錯誤時系統對于錯誤的處理能力和恢復能力依此設計測試用例。

白盒測試：

白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程序的控制結構設計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設計規范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與數據相關的錯誤。

白盒測試需要遵循的原則有：

（1）保證一個模塊中的所有獨立路徑至少被測試一次；

（2）所有邏輯值均需要測試真（true）和假（false）；兩種情況；

（3）檢查程序的內部數據結構，保證其結構的有效性；

（4）在上下邊界及可操作范圍內運行所有循環。

常用白盒測試方法：

靜態測試：不用運行程序的測試，包括代碼檢查、靜態結構分析、代碼質量度量、文檔測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具（Fxcop）自動進行。

動態測試：需要執行代碼，通過運行程序找到問題，包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等。

白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：

（1）語句覆蓋每條語句至少執行一次。

（2）判定覆蓋每個判定的每個分支至少執行一次。

（3）條件覆蓋每個判定的每個條件應取到各種可能的值。

（4）判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

（5）條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。

（6）路徑覆蓋使程序中每一條可能的路徑至少執行一次。

13、請你說一下app性能測試的指標

（1）內存：內存消耗測試節點的設計目標是為了讓應用不占用過多的系統資源，且及時釋放內存，保障整個系統的穩定性。當然關于內存測試，在這里我們需要引入幾個概念：空閑狀態、中等規格、滿規格。

空閑狀態指打開應用后，點擊home鍵讓應用后臺運行，此時應用處于的狀態叫做空閑；中等規格和滿規格指的是對應用的操作時間的間隔長短不一，中等規格時間較長，滿規格時間較短。

內存測試中存在很多測試子項，清單如下：

l? 空閑狀態下的應用內存消耗；

l? 中等規格狀態下的應用內存消耗；

l? 滿規格狀態下的應用內存消耗；

l? 應用內存峰值；

l? 應用內存泄露；

l? 應用是否常駐內存；

l? 壓力測試后的內存使用。

（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）流量：

網絡流量測試是針對大部分應用而言的，可能還有部分應用會關注網速、弱網之類的測試。

流量測試包括以下測試項：

l? 應用首次啟動流量提示；

l? 應用后臺連續運行2小時的流量值；

l? 應用高負荷運行的流量峰值。

（4）電量：

l? 測試手機安裝目標APK前后待機功耗無明顯差異；

l? 常見使用場景中能夠正常進入待機，待機電流在正常范圍內；

l? 長時間連續使用應用無異常耗電現象。

（5）啟動速度：

l? 第一類：首次啟動--應用首次啟動所花費的時間；

l? 第二類：非首次啟動--應用非首次啟動所花費的時間；

l? 第三類：應用界面切換--應用界面內切換所花費的時間。

（6）滑動速度、界面切換速度

（7）與服務器交互的網絡速度

14、請你說一說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：

l? Bug類型

l? 代碼錯誤

l? 界面優化

l? 設計缺陷

l? 配置相關

l? 安裝部署

l? 安全相關

l? 性能問題

l? 標準規范

l? 測試腳本

l? 其他

15、請你說一說web測試和app測試的不同點

（1）系統架構方面：

l? web項目，一般都是b/s架構，基于瀏覽器的

l? app項目，則是c/s的，必須要有客戶端，用戶需要安裝客戶端。

web測試只要更新了服務器端，客戶端就會同步會更新。App項目則需要客戶端和服務器都更新。

（2）性能方面:

l? web頁面主要會關注響應時間

l? 而app則還需要關心流量、電量、CPU、GPU、Memory這些。

l? 它們服務端的性能沒區別，都是一臺服務器。

（3）兼容方面：

l? web是基于瀏覽器的，所以更傾向于瀏覽器和電腦硬件，電腦系統的方向的兼容

l? app測試則要看分辨率，屏幕尺寸，還要看設備系統。

l? web測試是基于瀏覽器的所以不必考慮安裝卸載。

l? 而app是客戶端的，則必須測試安裝、更新、卸載。除了常規的安裝、更新、卸載還要考慮到異常場景。包括安裝時的中斷、弱網、安裝后刪除安裝文件 。

l? 此外APP還有一些專項測試：如網絡、適配性。

16、請問你了解什么測試方法

等價類劃分，邊界值分析，錯誤推測，因果圖法，邏輯覆蓋法，程序插樁技術，基本路徑法，符號測試，錯誤驅動測試

17、請問黑盒測試和白盒測試有哪些方法

l? 黑盒測試方法有等價類劃分，邊界值分析，錯誤推測，因果圖法

l? 白盒測試方法有邏輯覆蓋法，程序插樁技術，基本路徑法，符號測試，錯誤驅動測試

18、請問你怎么看待測試，知道哪些測試的類型，有用過哪些測試方法？

l? 測試是軟件開發中不可或缺的一環，測試通過經濟，高效的方法，捕捉軟件中的錯誤，從而達到保重軟件內在質量的目的。

l? 測試分為功能測試和非功能測試，非功能測試又可以分為性能測試、壓力測試、容量測試、健壯性測試、安全性測試、可靠性測試、恢復性測試、備份測試、協議測試、兼容性測試、可用性測試、配置測試、GUI測試。

l? 測試方法用過等價劃分法、邊值分析法、錯誤推測法、因果圖法。

19、請問你怎么測試網絡協議

協議測試包括四種類型的測試

（1）一致性測試：檢測協議實現本身與協議規范的符合程度

（2）、互操作性測試：基于某一協議檢測不同協議實現間互操作互通信的能力

（3）性能測試：檢測協議實現的性能指標，比如數據傳輸速度，連接時間，執行速度，吞吐量，并發度，

（4）健壯性測試：檢測協議是現在各種惡劣環境下運行的能力，比如注入干擾報文，通信故障，信道被切斷

20、請你說一說簡單用戶界面登陸過程都需要做哪些分析

（1）功能測試

l? 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。

l? 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤信息。

l? 登錄成功后能否能否跳轉到正確的頁面

l? 用戶名和密碼，如果太短或者太長，應該怎么處理

l? 用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況

l? 記住用戶名的功能

l? 登陸失敗后，不能記錄密碼的功能

l? 用戶名和密碼前后有空格的處理

l? 密碼是否非明文顯示顯示，使用星號圓點等符號代替。

l? 牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用

l? 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確

l? 輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。

l? 什么都不輸入，點擊提交按鈕，檢查提示信息。

（2）界面測試

l? 布局是否合理，testbox和按鈕是否整齊。

l? testbox和按鈕的長度，高度是否復合要求。

l? 界面的設計風格是否與UI的設計風格統一。

l? 界面中的文字簡潔易懂，沒有錯別字。

（3）性能測試

l? 打開登錄頁面，需要的時間是否在需求要求的時間內。

l? 輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。

l? 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。

（4）安全性測試

l? 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。

l? 用戶名和密碼是否通過加密的方式，發送給Web服務器。

l? 用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。

l? 用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊。

l? 用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊）。

l? 防止暴力破解，檢測是否有錯誤登陸的次數限制。

l? 是否支持多用戶在同一機器上登錄。

l? 同一用戶能否在多臺機器上登錄。