學習筆記 第一章 —— 如何撰寫軟體測驗計劃？
測驗計劃的好處
- 知道確切的測驗范圍，采取怎么樣的測驗策略
- 預估具體的作業量和測驗資源，每個人分工明確，不容易出現重復測驗的情況
- 測驗進度是可控的，實時知道目前測驗完成情況
- 可以提前識別潛在風險，當需求發生變化時，我們需要做出回應
測驗范圍
包含： 被測物件，主要的測驗內容
確定測驗范圍一般在測驗需求分析完成后進行，所以確定測驗范圍的程序在一定程度上也是對測驗需求分析的進一步檢驗，有助于在早期階段發現潛在的測驗遺漏；
由于測驗時間和成本有限，必須進行針對性的測驗，因此測驗范圍中要明確 測什么 和 不測什么 ，
測驗策略
測驗策略就是要明確 先測什么后測什么 和 如何來測 ，明確測驗的重點，以及各項測驗的先后順序；
比如： 對用戶登錄模塊來講，“用戶無法正常登錄”和“用戶無法重置密碼”這兩個潛在問題重要性并不高，所以應該按優先級來先測“用戶正常登錄”
測驗策略還要說明，采用什么樣的 測驗型別 和 測驗方法 ，不僅要給出為什么要選用這個測驗型別，還要詳細說明具體的實施方法，
第一：功能測驗
- 對于功能測驗，應該根據測驗需求分析的思維導圖來設計測驗用例
- 另外，還要評估被測軟體的可測性，如果有可測性的問題，需要提前考慮切實可行的變通方案，要求開發人員提供可測性的介面
第二：兼容性測驗
- Web 測驗需要確定覆寫的瀏覽器型別和版本，移動設備測驗需要確定覆寫的設備型別和具體 iOS/Android 的版本
- 兼容性測驗的實施，往往是在功能測驗的后期，也就是說需要等功能基本都穩定了，才會開始兼容性測驗
- 當前端引入新的前端框架或者組件庫時，往往會在前期做兼容性評估，確保不會引入后期無法解決的兼容性問題
第三：性能測驗
前期，明確性能需求（ 并發用戶數 、 回應時間 、 事務吞吐量 ），結合被測系統的特點，設計性能測驗場景并確定性能測驗框架
比如：
- 是直接在API級別發起壓力測驗，還是必須模擬終端用戶行為進行基于協議的壓力測驗；
- 是基于模塊進行壓力測驗，還是發起全鏈路壓測
如果性能是背景資料敏感的場景，還需要確定背景資料量級與分布，并決定產生背景資料的技術方案，比如是通過 API 并發呼叫來產生測驗資料，還是直接在資料庫上做批量 insert 和 update 操作，或者是兩種方式的結合，
最后，無論采用哪種方式，都需要明確待開發的單用戶腳本的數量，以便后續能夠順利組裝壓測測驗場景，
關于性能測驗的實施，首先，需要根據你想要解決的問題，確定性能測驗的型別，然后，根據具體的性能測下型別開展測驗，
性能測驗實施相關
1、性能測驗的實施，往往先要根據業務場景來決定需要開發哪些單用戶腳本，腳本的開發會涉及到很多性能測驗腳本特有的概念，比如思考時間、集合點、動態關聯等等，
2、腳本開發完成后，你還要以腳本為單位組織測驗場景（Scenario），場景定義簡單來說就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個用戶的操作步驟之間需要等待多少時間、并發用戶的增速是 5 秒一個，還是 5 秒 2 個等等，
3、最后，才是具體的測驗場景執行，和自動化功能測驗不同，性能測驗執行完成后性能測驗報告的解讀，是整個測驗程序中最關鍵的點，
還有很多測驗型別
比如：介面測驗、集成測驗、安全測驗、容量驗證、安裝測驗、故障恢復測驗
測驗資源
包含：測驗人員和測驗環境
測驗資源需要明確 誰來測 和 在哪里測
測驗進度
主要描述：各類測驗的開始時間，所需作業量，預計完成時間，并以此為依據來建議最終產品的上線發布時間
在傳統瀑布模型中：測驗進度完全依賴于開發完成并遞交測驗版本的時間，如果開發提交測驗版本發生了延誤，那么在不裁剪測驗需求的情況下，產品整體的上線時間就同樣會延期，
然而在敏捷模式中：測驗活動貫穿于整個開發程序，很多測驗作業會和開發作業同步進行，比如采用行為驅動開發（Behavior-Driven Development）模式，這樣測驗進度就不會完全依賴于開發遞交可測驗版本的時間，
行為驅動開發：就是平時我們經常說的 BDD，指的是可以通過自然語言書寫非程式員可讀的測驗用例
測驗風險預估
對于需求變更，如增加需求、刪減需求、修改需求，一定要重新進行測驗需求分析，確定變更后的測驗范圍和資源評估，并與專案經理和產品經理及時溝通因此引起的測驗進度變化
測驗程序中，可能會發生以下情況
1、測驗作業量評估不準確
2、需要增加額外的測驗型別
3、修復某些嚴重缺陷，導致需要全量回歸
4、送測延期
5、人員變動
所以，在制定測驗計劃時，就要預估整個測驗程序中可能存在的潛在風險，以及風險發生時的應對策略，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/317477.html
標籤：其他