一.概述
本規範是對項目軟件測試的一份指導性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準以及測試流程進行總體規範，以有效保證軟件產品的質量。
項目軟件測試是對軟件設計的一種控制手段，是對軟件產品質量的一種檢查和審覈手段，項目測試人員應按本規範要求對軟件進行檢查、測試。
二.測試目標
a.測試是爲了發現程序中的錯誤而執行程序的過程；
b.好的測試用例是極可能發現迄今爲止尚未發現的錯誤的用例；
c.成功的測試是發現了至今爲止尚未發現的錯誤的測試。
軟件測試流程
無規矩不成方圓，做好項目就是做正確的事情，而正確地處理事情才能更好地提高效率。測試部門在接到一個新的項目後，需要按照以下五個流程逐步開展測試工作，該流程在實際的工作中，可根據實際情況進行補充和完善。
a.測試參考文檔
在測試人員開展工作之後，需要藉助產品人員和開發人員提供的文檔，形式的文檔可以給測試工作帶來依據。具體參考文檔包括：產品需求說明書、產品設計原型、數據庫設計方案、開發部門代碼規範說明、開發人員（前端和後臺）任務分配表等。
b.測試工作流程圖
測試工作的基本流程圖如下圖所示：
軟件測試方法
根據項目需要，目前主要進行的有功能測試和性能測試。現階段以功能測試爲主，而功能測試目前使用最多的測試方法有等價類劃分法、邊界值分析法和錯誤推測法。這三種都屬於最常用、最典型、也是最重要的黑盒測試方法。 其他的方法還會涉及到因果圖法、判定表法、正交分析法、場景法等。
a.等價類劃分方法
將所有可能的輸入數據劃分成若干個子集，在每個子集中，如果任意一個輸入數據對於揭露程序中潛在錯誤都具有同等效果，那麼這樣的子集就構成了一個等價類。後續只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。
b. 邊界值分析方法
選取輸入、輸出的邊界值進行測試。因爲通常大量的軟件錯誤是發生在輸入或輸出範圍的邊界上，所以需要對邊界值進行重點測試，通常選取正好等於、剛剛大於或剛剛小於邊界的值作爲測試數據。從方法論上可以看出來，邊界值分析是對等價類劃分的補充，所以這兩種測試方法經常結合起來使用。
c.錯誤推測法
在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。
示例：針對“用戶登錄”功能，基於等價類劃分和邊界值分析方法，我們設計的測試用例包括：
輸入已註冊的用戶名和正確的密碼，驗證是否登錄成功；
輸入已註冊的用戶名和不正確的密碼，驗證是否登錄失敗，並且提示信息正確；
輸入未註冊的用戶名和任意密碼，驗證是否登錄失敗，並且提示信息正確；
用戶名和密碼兩者都爲空，驗證是否登錄失敗，並且提示信息正確；
用戶名和密碼兩者之一爲空，驗證是否登錄失敗，並且提示信息正確；
如果登錄功能啓用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登 錄成功；
如果登錄功能啓用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登 錄失敗，並且提示信息正確。
如果再加上錯誤推測法（因人而異），會再增加以下的測試用例：
用戶名和密碼是否大小寫敏感；
頁面上的密碼框是否加密顯示；
後臺系統創建的用戶第一次登錄成功時，是否提示修改密碼；
忘記用戶名和忘記密碼的功能是否可用；
前端頁面是否根據設計要求限制用戶名和密碼長度；
如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼，更換後的驗證碼是否可用；
刷新頁面是否會刷新驗證碼；
如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性；
用戶登錄成功但是會話超時後，繼續操作是否會重定向到用戶登錄界面；
不同級別的用戶，比如管理員用戶和普通用戶，登錄系統後的權限是否正確；
頁面默認焦點是否定位在用戶名的輸入框中；
快捷鍵 Tab 和 Enter 等，是否可以正常使用。
非功能性測試
一個質量過硬的軟件系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。顯式功能性需求的含義從字面上就可以很好地理解，指的是軟件本身需要實現的具體功能。比如“正常用戶使用正確的用戶名和密碼可以成功登錄”、“非註冊用戶無法登錄”等，這都是屬於典型的顯式功能性需求描述。從軟件測試的維度來看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的測試用例設計中，我們完全沒有考慮對非功能性需求的測試，但這些往往是決定軟件質量的關鍵因素。
示例：我們來繼續完善“用戶登錄”的測試用例。
在安全性方面補充的測試用例包括：
用戶密碼後臺存儲是否加密；
用戶密碼在網絡傳輸過程中是否加密；
密碼是否具有有效期，密碼有效期到期後，是否提示需要修改密碼；
不登錄的情況下，在瀏覽器中直接輸入登錄後的URL地址，驗證是否會重新定向到用戶登錄界面；
密碼輸入框是否不支持複製和粘貼；
密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看；
用戶名和密碼的輸入框中分別輸入典型的“SQL 注入***”字符串，驗證系統的返回頁面；
用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本***”字符串，驗證系統行爲是否被篡 改；
連續多次登錄失敗情況下，系統是否會阻止後續的嘗試以應對暴力破解；
同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期；
同一用戶先後在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
站在性能壓力測試的角度測試用例包括:
單用戶登錄的響應時間是否小於 3 秒；
單用戶登錄時，後臺請求數量是否過多；
高併發場景下用戶登錄的響應時間是否小於 5 秒；
高併發場景下服務端的監控指標是否符合預期；
高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；
長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏。
站在兼容性測試角度測試用例補充包括：
不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。
對於高質量的軟件測試，用例設計不僅需要考慮明確的顯式功能性需求，還要涉及兼容性、安全性和性能等一系列的非功能性需求，這些非功能性需求對軟件系統的質量有着舉足輕重的作用。但軟件測試的用例設計是不可窮盡的，工程實踐中難免受制於時間成本和經濟成本，所以測試部門需要兼顧缺陷風險和研發成本之間的平衡。
缺陷分類
根據缺陷的定義，將缺陷分爲如下4類:
a.文檔缺陷
指對文檔的靜態檢查過程中發現的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定，被評審的對象包括最終出產出物和中間過程產出物。比如產品需求文檔、原型設計文檔、測試計劃、測試用例等。
b.代碼缺陷
指對代碼進行同行評審、審計或代碼走查過程中發現的缺陷。
c.測試缺陷
指由測試活動發現的測試對象的缺陷，被測對象一般是指可運行的代碼、系統，不包括靜態測試發現的問題。
d.過程缺陷
又叫做不符合項問題，是指通過過程審計、過程分析、管理評審、質量評估、質量審覈等活動發現的關於過程的缺陷和問題。過程缺陷的發現者一般是測試人員、項目經理等。
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類：測試建議
Bug的優先級定義
根據所提交bug的優先級，本規範定義以下五個級別。
Highest ：表示問題必須馬上解決，否則系統根本無法達到預定的需求。
High：表示問題的修復很緊要，很急迫，關係到系統的主要功能模塊能否正常。
Medium：表示有時間就要馬上解決，否則系統偏離需求較大或預定功能不能正常實現。
Low：表示計劃解決，表示問題不影響需求的實現，但是影響其他使用方面，比如頁面調用出錯，調用了錯誤的等。
Lowest：即問題在系統發佈以前必須確認解決或確認可以不予解決。
測試標準
功能測試的通過準則一般有：
1.單元功能同設計需求一致；
2.規定的路徑覆蓋率及覆蓋類達到要求，且執行正確；
3.所規定的黑盒測試手段被使用，且執行正確；
4.對殘留錯誤有合法解釋或被認可暫留；
5.雖然路徑覆蓋率不能達到，但其他各測試的錯誤查出率趨產0或穩定(時間的長短視情況而定)。
各類軟件測試合格須符合以下標準。
在這裏插入圖片描述
以上比例爲錯誤佔總測試模塊的比例。
軟件產品未經測試合格，不允許上線發佈。