軟體測驗計劃-有解無憂

引言：

編號	確定專案	描述
1	確定范圍	確定被測專案中功能模塊，子功能模塊等需要測驗的范圍，
2	確定需求	確定每個功能結果定義，確定此功能是否存在缺陷，
3	確定策略	確定對專案做哪些測驗，如：功能測驗，性能測驗等，
4	確定方法	確定對每個策略是用哪些方法，如：邊界值，等價類等，
5	確定工具	如: 功能測驗使用Seleium，性能測驗使用Jmeter等，
6	確定資源	測驗需要的設備，服務器、參與測驗的人員、測驗任務的分工，測驗作業的進度，
7	交付檔案	確定測驗作業中生成哪些檔案，可提交檔案有哪些，

測驗專案：

專案名稱	XX專案
使用背景	// 用戶協會分會負責人、期刊客戶
開發者	XX集團
專案簡介	學術專著出版平臺” 定位是一家圖書產品聯合創建、銷售、返利的平臺；平臺聯合各專業協會、學會、出版社等機構，組織大批專家人才建立“專家指導委員會”，為圖書進行策劃、上報、審校、出版、運營等服務；主要業務情景是：策劃人尋求參編人，共同創建圖書及銷售，參編人支付參編圖書的預購款，該筆資金作為公司運營圖書的成本，等待圖書出版后，讓消費者以個人名片或鏈接的形式進行購買圖書，參編人員不僅可以通過圖書評職稱、擴大知名度、傳播學術價值，另外讓參編人通過銷售，實作“0”元出書并且獲得額外收入；策劃人在發展參編和策劃人同時，獲得相應獎勵，

測驗目的：

編號	目的
1	軟體測驗是為了發現錯誤而執行程式的程序，
2	測驗是為了證明程式有錯，而不是證明程式無錯，
3	一個好的測驗用例在于它發現至今未發現的錯誤，
4	一個成功的測驗是發現了至今未發現的錯誤的測驗，

檔案受眾：

編號	人員	原因
1	產品設計人員	明確說明測驗范圍，方法，作業周期資訊，
2	產品研發人員	明確說明測驗范圍，方法，作業周期資訊，
3	產品測驗人員	明確說明測驗范圍，方法，任務分工，預計完成時間，
4	備注	此為內部開發檔案，不做外部參考，

測驗參考檔案

編號	檔案名稱	作用
1	需求檔案	確定專案功能模塊，功能運行結果，
2	技術檔案	確定專案中使用開發語言，資料庫資料限制，
3	專案模型檔案	初步了解專案頁面內容，方便撰寫用例，

測驗提交檔案：

編號	檔案名稱	作用
1	測驗計劃	明確說明測驗范圍，方法，作業周期資訊，
2	測驗用例	明確說明測驗作業的細節測驗作業，
3	缺陷報告	明確說明專案中的缺陷描述，與修復情況，
4	測驗報告	明確說明測驗結果，測驗模塊，缺陷分布情況等等資訊，

術語定義：

專案術語：

編號	縮寫、術語	解釋
1
2

測驗專業術語：

編號	術語	解釋
1	單元測驗	開發者撰寫的一小段代碼，檢驗被測代碼的一個很小的、很明確的功能是否正確，
2	集成測驗	開發者撰寫的多個段代碼單元，組合到一起形成集成測驗，檢查多個單元組合功能是否正確，
3	冒煙測驗	針對產品的基本功能進行測驗，
4	功能測驗	又稱正確性測驗，它檢查軟體的功能是否符合規格說明，
5	可靠性測驗	對服務器施加一定壓力，測驗服務器是否可以長期穩定運行，
6	壓力測驗	對服務器施加一定壓力后進行功能測驗，測驗服務器在一定壓力下是夠可以正常計算，
7	負載測驗	對服務器施加壓力，測驗服務器可以容納多少人訪問，多少人訪問后出現BUG，
8	易用性測驗	主要從使用的合理性和方便性等角度對軟體系統進行檢查，用戶來測，
9	兼容性測驗	測驗Web頁面是否支持所有瀏覽器，訪問后頁面所有功能無例外，
10	安全測驗	服務器資料安全性，用戶資料安全性，用戶操作安全性，用戶財產安全性、公司財產安全性，
11	資料完整性測驗	對資料及資料庫能否正常運行訪問的測驗，
12	回歸測驗	開發修改后的BUG在測驗一遍，
13
14

缺陷優先級：

級別	描述
P0	嚴重級別比較高的，影響測驗進行或者系統無法繼續操作，立即修復，1天，
P1	基本功能沒有實作，對系統操作有影響，2－3天，
P2	一般性功能，頁面缺陷，4－5天，
P3	準備在下一輪測驗前修改完畢，準備在下一版本中修改，

嚴重程度定義：

級別	嚴重程度描述
S0	資料丟失，資料計算錯誤、資料傳遞錯誤、對資料庫造成破壞，造成作業系統或其他支撐系統崩潰、非正常關閉和非正常死機，
S1	應用系統崩潰、非正常關閉和無回應，但沒有造成資料丟失，系統的主要功能不能正確實作或不完整，
S2	規定的非主要功能沒有實作或不完整、影響系統的運行；設計不合理造成性能低下，
S3	不影響業務運行的功能問題，
S4	軟體設計和功能實作等不完全合理之處提出建議，

用例優先級定義：

級別	優先級描述
P0	確保系統基本功能及主要功能的測驗用例
P1	確保系統功能的完善方面的測驗用例
P2	關于用戶體驗，輸入輸出的驗證；較少使用或輔助功能的測驗用例，

測驗策略：

1、單元測驗

	單元測驗
測驗目標	開發者撰寫的一小段代碼，檢驗被測代碼的一個很小的、很明確的功能是否正確，
測驗范圍	測驗整個專案中的每一行代碼進行測驗，
完成標準	代碼的一個很小的、很明確的功能都正確，
需要考慮的特殊事項	//
使用工具	Python + Selenium + unittest

2、集成測驗：

	集成測驗
測驗目標	開發者撰寫的多個段代碼單元，組合到一起形成集成測驗，檢查多個單元組合功能是否正確，
測驗范圍	開發者撰寫的多個段代碼單元，組合到一起形成的集合，
完成標準	多個單元組合功能正確，
需要考慮的特殊事項	//
使用工具

3、冒煙測驗：

	冒煙測驗
測驗目標	版本是否值得系統測驗
測驗范圍	1、返測上一版本提交的測驗報告， 2、測驗系統的基本功能，
完成標準	基本功能通過，并繼續測驗，
需要考慮的特殊事項	此階段不超過1天，

4、功能測驗：

	功能測驗
測驗目標	確保測驗計劃中所列出的測驗范圍，保證其功能正常，
測驗范圍	1、按照測驗計劃所規定的測驗范圍， 2、利用有效的和無效的資料來執行各個用例、用例流或功能 3、以核實以下內容： 1）在使用有效資料時得到預期的結果， 2）在使用無效資料時顯示相應的錯誤訊息或警告訊息，
完成標準	按照測驗計劃的測驗通過標準，完成測驗，
需要考慮的特殊事項	確定或說明那些將對功能測驗的實施和執行造成影響的事項或因素，（內部的或外部的）
使用工具	Seleium + python + 谷歌

易用性測驗：

	易用性測驗
測驗目標	模擬真實用戶，無經驗用戶，測驗系統的易用性
測驗范圍	前臺
完成標準	成功地核實出前臺各個網頁符合可接受易用性標準，
需要考慮的特殊事項	無

7、兼容測驗：

	兼容測驗
測驗目標	測驗Web頁面是否支持所有瀏覽器，訪問后頁面所有功能無例外
測驗范圍	前臺
完成標準	使用多個不同瀏覽器訪問后界面無例外即為通過，
需要考慮的特殊事項	瀏覽器版本；瀏覽器型別是否都測到，

8、可靠性測驗：

	可靠性測驗
測驗目標	使用LR模擬真實用戶對服務器施加一定壓力
測驗范圍	專案服務器，
完成標準	持續運行特定時間不出現問題，
需要考慮的特殊事項	測驗機是否滿足需求，

9、壓力測驗：

	壓力測驗
測驗目標	使用LR模擬真實用戶對服務器施加壓力，
測驗范圍	專案服務器，
完成標準	直到服務器卡死，獲得服務器資源，最大與鏈接數等資料，
需要考慮的特殊事項	測驗機是否滿足需求，
使用工具	Jmeter + fiddler + 火狐

10、負載測驗:

	負載測驗
測驗目標	使用LR模擬真實用戶對服務器施加一定壓力，對服務器進行主要功能測驗，
測驗范圍	專案服務器&前臺界面
完成標準	對服務器施加一定壓力后前臺功能正常，訪問時間3-8之內，
需要考慮的特殊事項	測驗機是否滿足需求，
使用工具	Jmeter + fiddler + 火狐

11、資料完整性測驗：

	資料完整性測驗
測驗目標	確保資料庫設計完整性，
測驗范圍	資料庫及表結構
完成標準	資料庫約束、完整性等設定達到需求標準，
需要考慮的特殊事項	資料遭到破壞，易恢復性，

12、回歸測驗：

	回歸測驗
測驗目標	確保BUG修復的完整性，
測驗范圍	專案中出BUG 的部分
完成標準	專案中出現的BUG完成修復，并將缺陷保存下來，
需要考慮的特殊事項	出BUG的功能和BUG相關的功能都需要回測，

13、功能測驗范圍：

模塊	功能	應用策略	備注

四、測驗規則：

1、準入規則

編號	測驗策略	進入準則
1	單元測驗	專案編碼階段，開發人員每撰寫完一個單元時進入測驗
2	集成測驗	專案編碼階段，開發人員每撰寫完多個單元時進入測驗
3	功能測驗	專案系統測驗階段，開發人員根據需求開發完成時，進入測驗，
4	易用測驗	功能測驗完成后進入測驗，
5	兼容測驗
6	可靠測驗	功能測驗完成后進入測驗，
7	壓力測驗
8	負載測驗
9	資料完整性	性能測驗完成后進入測驗，
10	回歸測驗	提交的缺陷報告修改后，

2、暫停/退出規則

編號
1	軟體系統在進行單元、集成、確認、系統、安裝、驗收測驗時，發現缺陷達到一定數量或出現重大錯誤導致無法測驗時，暫停測驗回傳開發，
2	發生其他未知因素需要暫停時，測驗應隨之暫停，并備份暫停點資料，

測驗資源：

硬體資源

編號	CPU	記憶體	硬碟	系統	軟體
1	2.5	4+	100+	Win7	Jmeter，seleium，AppScan

測驗人力資源：

編號	角色	人員	具體職責
1	確認需求		明確需求
2	制定計劃		決定測驗策略，人員分工，測驗周期
3	準備測驗環境		測驗作業開始前準備作業
4	執行測驗作業		撰寫用例，執行用例，提交缺陷報告，回測等，
5	撰寫測驗報告		撰寫專案的測驗結果，

測驗作業進度：

編號	任務	范圍	人員	時間
1	確認需求
2	定制測驗計劃
3	準備測驗環境
4	單元測驗
5	集成測驗
6	冒煙測驗功能測驗兼容測驗易用性測驗
7	可靠性測驗壓力測驗負載測驗
8	安全測驗
9	資料完整性測驗
10	回歸測驗
11	撰寫測驗報告

系統風險

1、系統風險：

（1）、計劃的測驗時間，不能滿足測驗組的要求，主要是功能凍結后的系統測驗的時間可能不夠，

（2）、測驗資源的及時到位（設備和人員），

（3）、需求不明確可能導致開發的產品與目標不一致，

（4）、測驗人員對測驗工具的使用熟悉程式不夠；

（5）、被測驗產品存在重大錯誤，以至于測驗無法繼續，需要開發組進行額外的除錯和修改才能繼續；

（6）、硬體、軟體或網路環境出現故障等

2、應急措施：

（1）、如果上述潛在的可能事件發生，則通過適當加班來保證計劃的按時完成，

（2）、如果是由于被測驗產品存在重大錯誤而嚴重影響測驗進度，則考慮按照測驗暫圖示準來暫停該測驗，

（3）、如遇到功能需求不明確，需要溝通協商解決，

（4）、人員不足，則加班、或者進行不同組人員調動，按照測驗進度完成測驗任務，

測驗的完成標準

完成標準

單元測驗完成標準:

(1)、按照單元測驗計劃完成了所有規定單元的測驗

(2)、達到了測驗計劃中關于單元測驗所規定的覆寫率的要求

(3)、軟體單元功能與設計一致

(4)、在單元測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

2、集成測驗完成標準

（1）、按照集成構件計劃及增量集成策略完成了整個系統的集成測驗

（2）、達到了測驗計劃中關于集成測驗所規定的覆寫率的要求

（3）、被測驗的集成作業版本每千行代碼必須發現至少2個錯誤（不含優化級別錯誤）

（4）、集成作業版本滿足設計定義的各項功能、性能要求

（5）、在集成測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

3、功能/易用測驗完成標準

（1）、功能測驗用例設計已經通過評審

（2）、按照功能測驗計劃完成了功能測驗

（3）、達到了功能測驗計劃中關于功能測驗所規定的覆寫率的要求

（4）、系統達到詳細設計定義的各項功能，性能

（5）、在功能測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

4、兼容測驗完成標準

（1）、兼容測驗用例設計已經通過評審

（2）、按照兼容測驗計劃完成了兼容測驗

（3）、達到了兼容測驗計劃中關于兼容測驗所規定的瀏覽器的要求

（4）、在兼容測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

5、系統測驗完成標準

（1）、系統測驗用例設計已經通過評審

（2）、按照系統測驗計劃完成了系統測驗

（3）、達到了測驗計劃中關于系統測驗所規定的覆寫率的要求

（4）、被測驗的系統每千行代碼必須發現至少1個錯誤（不含五級錯誤）

（5）、系統滿足需求規格說明書的要求

（6）、在系統測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

6、驗收測驗完成標準

（1）、軟體需求分析說明書中定義的所有功能已全部實作，性能指標全部達到要求，

（2）、在驗收測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準

（3）、所有測驗項沒有殘余緊急、嚴重級別錯誤，

（4）、需求分析檔案、設計檔案和編碼實作一致，

（5）、驗收測驗工件齊全（測驗計劃、測驗用例、測驗日志、測驗通知單、測驗分析）

7、可靠/壓力/負載測驗完成標準

（1）、性能測驗用例設計已經通過評審

（2）、按照性能測驗計劃完成了性能測驗

（3）、達到了性能測驗計劃中關于性能測驗所規定要求

（4）、在性能測驗中不通過的用例已經得到修改，性能達到預計標準

8、缺陷修復率標準

（1）、緊急、嚴重級別錯誤修復率應達到100%

（2）、普通級別錯誤修復率應達到95%以上

（3）、優化級別錯誤修復率應達到60%以上

注：專案緊急時，普通級別錯誤修復率達60%以上；優化級別錯誤修復率達20%即可，

9、覆寫率標準

（1）、測驗用例執行覆寫率應達到100%（功能測驗用例均已執行）

（2）、測驗需求執行覆寫率應達到100%（業務測驗用例均已執行）

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/6100.html

標籤：其他

上一篇：關于Github訪問速度巨慢

下一篇：專案章程