總結、探尋我所理解的測試策略,輸出可執行的文案,只為回首往事時不因虛度年華而悔恨,不因碌碌無為而羞恥。
參考:軟件需求分析方法?
軟件需求分析是一個項目的開端,也是項目實施最重要的關鍵點,一個項目的成功軟件需求分析是關鍵的一步。
我所理解的需求分析流程可以如下:
一、識別測試需求
理想的測試需求獲取路徑當然是需求文檔(需求規格說明書),但是實際很多時候需求文檔并不一定是最完整且時時的(理論上應該是最完整且時時的),所以作為測試人員一方面要求完整且時時的需求文檔,另一方面要多渠道獲取需求的相關信息,豐富自己對需求的了解,如下圖所示:
二、分析測試需求:
1 依據識別的測試需求,通讀需求文檔和設計,重點關注以下問題:
(1).需求文檔和設計是否是用戶真實意圖的體現?
(2).需求文檔和設計中是否有模棱兩可和有歧義的地方?
(3).及時反饋問題,在測試用例設計前理清需求事實和可能的問題,并得到明確的結果。
2 依據需求文檔和設計圖畫業務流程圖。目標是通過流程圖的繪制,對整個業務的處理邏輯及其細節有非常清楚的認知,為后續編寫測試用例設計做準備。
(1).流程圖要畫,在這個過程中一方面是對需求邏輯的理解,另一方面也督促自己與開發確認邏輯(或者用例評審時輔助使用);
(2).流程圖盡可能細化,每個業務判斷邏輯都要應該有各種情況的處理邏輯;
(3).各種輸入條件之間的關聯關系、輸出數據之間的關聯關系標注清楚;
(4).梳理邏輯的過程也是在測試需求在邏輯上有無漏洞和考慮欠佳的地方,為后續測試打基礎。
3 需求對于其他類型有無要求,如果有,需要明確并在需求測試總結中標注,在用例設計階段需要設計對應的用例,舉例如下:
(1).是否對性能提出了明確的要求?
(2).是否對運行環境、操作習慣提出了明確要求?
(3).是否對安全性方面提出了明確的要求?
三、提取測試對象
提取的前提是對需求本質明確,需求文檔和設計已無階段性問題,在次基礎上可以制作需求測試結果表。
總結:輸出了需求測試結果表,預示著對需求已無階段性的疑問,對需要要測試的方向已經明確;對具體的方向要測試的種類已經清晰,后續就是依據該表和業務邏輯設計對應的類別測試用例。
備注:該表格不是一成不變的,隨便測試用例設計的推薦和需求的變更,需要持續更新該表,當一段時間過后再去回歸該需求,此表可以提供明確的需求說明(較之需求文檔和設計更清晰)