1. 概述

本規範是對專案軟體測試的一份指導性檔案，對軟體測試過程中所涉及到的測試理論、測試型別、測試方法、測試標準以及測試流程進行總體規範，以有效保證軟體產品的質量。

專案軟體測試是對軟體設計的一種控制手段，是對軟體產品質量的一種檢查和稽核手段，專案測試人員應按本規範要求對軟體進行檢查、測試。

2. 測試目標

（1）測試是為了發現程式中的錯誤而執行程式的過程；

（2）好的測試用例是極可能發現迄今為止尚未發現的錯誤的用例；

（3）成功的測試是發現了至今為止尚未發現的錯誤的測試。

3. 軟體測試流程

無規矩不成方圓，做好專案就是做正確的事情，而正確地處理事情才能更好地提高效率。測試部門在接到一個新的專案後，需要按照以下五個流程逐步開展測試工作，該流程在實際的工作中，可根據實際情況進行補充和完善。

3.1. 測試參考文件

在測試人員開展工作之後，需要藉助產品人員和開發人員提供的文件，形式的文件可以給測試工作帶來依據。具體參考文件包括：產品需求說明書、產品設計原型、資料庫設計方案、開發部門程式碼規範說明、開發人員（前端和後臺）任務分配表等。

3.2. 測試工作流程圖

測試工作的基本流程圖如下圖所示：

4. 軟體測試方法

根據專案需要，目前主要進行的有功能測試和效能測試。現階段以功能測試為主，而功能測試目前使用最多的測試方法有等價類劃分法、邊界值分析法和錯誤推測法。這三種都屬於最常用、最典型、也是最重要的黑盒測試方法。 其他的方法還會涉及到因果圖法、判定表法、正交分析法、場景法等。

4.1. 等價類劃分方法　

將所有可能的輸入資料劃分成若干個子集，在每個子集中，如果任意一個輸入資料對於揭露程式中潛在錯誤都具有同等效果，那麼這樣的子集就構成了一個等價類。後續只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。

4.2. 邊界值分析方法

選取輸入、輸出的邊界值進行測試。因為通常大量的軟體錯誤是發生在輸入或輸出範圍的邊界上，所以需要對邊界值進行重點測試，通常選取正好等於、剛剛大於或剛剛小於邊界的值作為測試資料。從方法論上可以看出來，邊界值分析是對等價類劃分的補充，所以這兩種測試方法經常結合起來使用。 　　

4.3.

錯誤推測法

在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。

示例：針對“使用者登入”功能，基於等價類劃分和邊界值分析方法，我們設計的測試用例包括：

1. 輸入已註冊的使用者名稱和正確的密碼，驗證是否登入成功；

2. 輸入已註冊的使用者名稱和不正確的密碼，驗證是否登入失敗，並且提示資訊正確；

3. 輸入未註冊的使用者名稱和任意密碼，驗證是否登入失敗，並且提示資訊正確；

4. 使用者名稱和密碼兩者都為空，驗證是否登入失敗，並且提示資訊正確；

5. 使用者名稱和密碼兩者之一為空，驗證是否登入失敗，並且提示資訊正確；

6. 如果登入功能啟用了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入正確的驗證碼，驗證是否登 錄成功；

7. 如果登入功能啟用了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登 錄失敗，並且提示資訊正確。

如果再加上錯誤推測法（因人而異），會再增加以下的測試用例：

1. 使用者名稱和密碼是否大小寫敏感；

2. 頁面上的密碼框是否加密顯示；

3. 後臺系統建立的使用者第一次登入成功時，是否提示修改密碼；

4. 忘記使用者名稱和忘記密碼的功能是否可用；

5. 前端頁面是否根據設計要求限制使用者名稱和密碼長度；

6. 如果登入功能需要驗證碼，點選驗證碼圖片是否可以更換驗證碼，更換後的驗證碼是否可用；

7. 重新整理頁面是否會重新整理驗證碼；

8. 如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性；

9. 使用者登入成功但是會話超時後，繼續操作是否會重定向到使用者登入介面；

10. 不同級別的使用者，比如管理員使用者和普通使用者，登入系統後的許可權是否正確；

11. 頁面預設焦點是否定位在使用者名稱的輸入框中；

12. 快捷鍵 Tab 和 Enter 等，是否可以正常使用。

5. 非功能性測試

一個質量過硬的軟體系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。顯式功能性需求的含義從字面上就可以很好地理解，指的是軟體本身需要實現的具體功能。比如“正常使用者使用正確的使用者名稱和密碼可以成功登入”、“非註冊使用者無法登入”等，這都是屬於典型的顯式功能性需求描述。從軟體測試的維度來看，非功能性需求主要涉及安全性、效能以及相容性三大方面。 在上面所有的測試用例設計中，我們完全沒有考慮對非功能性需求的測試，但這些往往是決定軟體質量的關鍵因素。

示例：我們來繼續完善“使用者登入”的測試用例。

在安全性方面補充的測試用例包括：

1. 使用者密碼後臺儲存是否加密；

2. 使用者密碼在網路傳輸過程中是否加密；

3. 密碼是否具有有效期，密碼有效期到期後，是否提示需要修改密碼；

4. 不登入的情況下，在瀏覽器中直接輸入登入後的URL地址，驗證是否會重新定向到使用者登入介面；

5. 密碼輸入框是否不支援複製和貼上；

6. 密碼輸入框內輸入的密碼是否都可以在頁面原始碼模式下被檢視；

7. 使用者名稱和密碼的輸入框中分別輸入典型的“SQL 注入***”字串，驗證系統的返回頁面；

8. 使用者名稱和密碼的輸入框中分別輸入典型的“XSS 跨站指令碼***”字串，驗證系統行為是否被篡 改；

9. 連續多次登入失敗情況下，系統是否會阻止後續的嘗試以應對暴力破解；

10. 同一使用者在同一終端的多種瀏覽器上登入，驗證登入功能的互斥性是否符合設計預期；

11. 同一使用者先後在多臺終端的瀏覽器上登入，驗證登入是否具有互斥性。

站在效能壓力測試的角度測試用例包括:

1. 單使用者登入的響應時間是否小於 3 秒；

2. 單使用者登入時，後臺請求數量是否過多；

3. 高併發場景下使用者登入的響應時間是否小於 5 秒；

4. 高併發場景下服務端的監控指標是否符合預期；

5. 高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；

6. 長時間大量使用者連續登入和登出，伺服器端是否存在記憶體洩漏。

站在相容性測試角度測試用例補充包括：

1. 不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；

2. 相同瀏覽器的不同版本下，驗證登入頁面的顯示以及功能正確性；

3. 不同移動裝置終端的不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；

4. 不同解析度的介面下，驗證登入頁面的顯示以及功能正確性。

對於高質量的軟體測試，用例設計不僅需要考慮明確的顯式功能性需求，還要涉及相容性、安全性和效能等一系列的非功能性需求，這些非功能性需求對軟體系統的質量有著舉足輕重的作用。但軟體測試的用例設計是不可窮盡的，工程實踐中難免受制於時間成本和經濟成本，所以測試部門需要兼顧缺陷風險和研發成本之間的平衡。

6. 缺陷分類

根據缺陷的定義，將缺陷分為如下4類:

 6.1文件缺陷

指對文件的靜態檢查過程中發現的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據被評審物件的型別來確定，被評審的物件包括最終出產出物和中間過程產出物。比如產品需求文件、原型設計文件、測試計劃、測試用例等。

6.2程式碼缺陷

指對程式碼進行同行評審、審計或程式碼走查過程中發現的缺陷。

6.3測試缺陷

指由測試活動發現的測試物件的缺陷，被測物件一般是指可執行的程式碼、系統，不包括靜態測試發現的問題。

6.4過程缺陷

又叫做不符合項問題，是指通過過程審計、過程分析、管理評審、質量評估、質量稽核等活動發現的關於過程的缺陷和問題。過程缺陷的發現者一般是測試人員、專案經理等。

7 Bug的嚴重性定義

根據所提交bug的嚴重性，本規範定義以下五個級別。

A類：嚴重錯誤，包括以下各種錯誤：

（1）由於程式所引起的宕機，非法退出。

（2）死迴圈

（3）資料庫發生死鎖

（4）因錯誤操作導致的程式中斷

（5）功能錯誤

（6）與資料庫連線錯誤

（7）資料通訊錯誤

B類：較嚴重錯誤，包括以下各種錯誤：

（1）程式錯誤

（2）程式介面錯誤

（3）資料庫的表、業務規則、預設值未加完整性等約束條件

C類：一般性錯誤，包括以下各種錯誤：

（1）操作介面錯誤（包括資料視窗內列名定義、含義是否一致）

（2）列印內容、格式錯誤

（3）簡單的輸入限制未放在前臺進行控制

（4）刪除操作未給出提示

（5）資料庫表中有過多的空欄位

D類：較小錯誤，包括以下各種錯誤：

（1）介面不規範

（2）輔助說明描述不清楚

（3）輸入輸出不規範

（4）長操作未給使用者提示

（5）提示視窗文字未採用行業術語

（6）可輸入區域和只讀區域沒有明顯的區分標誌

E類：測試建議

8. Bug的優先順序定義

根據所提交bug的優先順序，本規範定義以下五個級別。

1. Highest ：表示問題必須馬上解決，否則系統根本無法達到預定的需求。

2. High：表示問題的修復很緊要，很急迫，關係到系統的主要功能模組能否正常。

3. Medium：表示有時間就要馬上解決，否則系統偏離需求較大或預定功能不能正常實現。

4. Low：表示計劃解決，表示問題不影響需求的實現，但是影響其他使用方面，比如頁面調用出錯，呼叫了錯誤的等。

5. Lowest：即問題在系統釋出以前必須確認解決或確認可以不予解決。

9、測試標準

功能測試的通過準則一般有：

（1）單元功能同設計需求一致；

（2）規定的路徑覆蓋率及覆蓋類達到要求，且執行正確；

（3）所規定的黑盒測試手段被使用，且執行正確；

（4）對殘留錯誤有合法解釋或被認可暫留；

（5）雖然路徑覆蓋率不能達到，但其他各測試的錯誤查出率趨產0或穩定(時間的長短視情況而定)。

各類軟體測試合格須符合以下標準。

以上比例為錯誤佔總測試模組的比例。

軟體產品未經測試合格，不允許上線釋出。

更多精彩都在洋哥視訊課程學習地址：http://edu.51cto.com/lecturer/5811414.html