一、概述
1.風險:目前未發生而未來有可能會發生并造成一定負面影響的事件
2.軟體測試是通過各種測試活動來發現軟體或服務中是否存在引起風險的缺陷
3.功能和非功能:最終展現在産品或服務風險上
4.軟體開發過程中的各種技術問題、資源問題、管理問題也展現在産品開發過程的風險上
5.風險相比軟體測試和開發的專業知識更容易被各方了解和接受,應該圍繞發現風險、緩解風險的目标來建設測試團隊的能力
6.測試政策和測試計劃的制定本質上與制定 商業計劃、做職業計劃等工作一樣,第一是面對不确定性、第二是面對有限資源,第三是試圖做出目前時間點的最佳決策
7.測試計劃内容的核心是解決圖中所示的4個問題
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsISPrdEZwZ1Rh5WNXp1bwNjW1ZUba9VZwlHdsATOfd3bkFGazxCMx8VesATMfhHLlN3XnxCMwEzX0xiRGZkRGZ0Xy9GbvNGLpZTY1EmMZVDUSFTU4VFRR9Fd4VGdsYTMfVmepNHLrJXYtJXZ0F2dvwVZnFWbp1zczV2YvJHctM3cv1Ce-cmbw5CN0ATO3ImYkNTY4EmMilDZxUmN4UmNidjMwMmZ0M2M48CX5IzLclDMxIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjL1M3Lc9CX6MHc0RHaiojIsJye.png)
制定測試計劃步驟:
分析-識别風險、選項、估算、平衡;形成決策
二、風險分析和緩解措施
1.風險識别是基于風險的測試的起始點,目前并沒有一個确定機械化的算法來保證找出所有的風險,通常方法:專家訪談、頭腦風暴、風險架構或檢查表來盡量保證識别完整的風險
專家訪談:可以得出基礎的風險清單或對已有的風險清單進行補充
頭腦風暴:邀請利用相關方參與,列舉出利益關心的風險
風險框和檢查表:提供風險識别的曆史經驗和盡量完整、全局的視角
2.風險來源擷取:各種規格說明、實作的細節、銷售市場資料、競争對手的研究、獨立評估機構、過去曆史項目、個人曆史經驗
3.風險可能發生影響事件:風險發生的可能性、風險一旦發生可能造成的影響
4.風險計劃還應區分該風險是否與軟體品質相關,與軟體品質無關的則不應納入測試計劃的分析工作
5.軟體測試活動究竟在産品風險緩解上能起到什麼作用
6.基于風險的測試計劃中的風險分析:區分能通過軟體測試活動來緩解的風險;從業務出發,估計風險的影響;從業務出發,估計在最終産品中允許的殘留風險發生的機率;從産品開發測試出發。了解目前産品中風險的機率
7.風險展現為某種軟體的品質的特性的缺陷,則能通過測試活動來發現風險進而得到緩解
8.風險的影響估計,必須控制風險影響估算這個活動本身的複雜度工作量
9.上市後産品中允許殘留風險發生機率的估計,其實是設計産品的品質目标
10.與利益相關方溝通,參考競品來擷取對産品品質的總體期望
11.由測試經理從自身的經驗出發,或對組織測試團隊進行頭腦風暴,推算出使用場景中出現失效的受容忍度
12.産品開發測試中遇到風險機率的估計原則:
當功能還未開發時,其發生的機率時100%;
當開始測試活動時,則測試結果的通過率可以近似地作為開發測試中遇到風險的機率
公式:R=(C-R)*I
13.通過設計緩解風險的一套辦法:
測試級别的劃分,能對應解解決軟體開發的複雜性問題;
測試類型的設計和安排:将測試類型安排在最合适對應的測試級别來識别和緩解産品風險
測試設計方法,在每個測試級别和類型中,都要進行測試設計和執行的工作
測試執行方法,對每個測試級别和測試類型都應具體地設計安排對應的測試執行手段
14.一般性的緩解措施指南
系統複雜性非常高,推薦采用區分主測似計劃和分級别的測試計劃
一般對測試結拜進行定義和劃分,定義各個測試級别所達成的品質目标,主要應對系統的複雜性風險,對各個級别的測試活動所采取的測試類型、測試技術、工具和環境做出初步的指導性說明
15.設計風險環境措施基本步驟
1)安排測試級别來對應軟體系統的複雜度風險
2)通過特定的測試類型在本級别内對應特定的品質特性風險
3)考慮采用哪些測試設計方法設計測試用例
4)根據被測對象的互動方式設計測試執行的方法
16.測試步驟順序,基于風險原則:
1)風險導出相關品質特性,而非單純考慮品質特性
2)由品質特性得到測試類型,避免安排無意義的測試活動來進行某些特定目标的測試
3)根據測試類型考慮測試設計方法,更有針對性
4)更加測試類型和測試級别設計測試執行的方法
17.制定主測試計劃時,應根據每個測試級别所能緩解的風險,安排适合的測試級别并将風險處理配置設定到各個級别的測試
單元測試:擅長發現代碼級别的缺陷,擅長識别詳細設計和編碼錯誤
內建測試:擅長發現子產品間交換的缺陷,擅長識别功能設計或架構設計的錯誤造成
系統測試:擅長發現軟體需求的缺陷,識别需求的風險,包括各種非功能的風險
驗收測試:擅長發現軟體需求的缺陷,重點在于識别軟體行為是否符合客戶的使用場景
三、測試級别與測試實施
1.選擇測試設計技術的通用規則:使用測試條件描述形式最接近功能或品質特性的描述方式的測試設計技術
等價類劃分:測試條件描述形式時資料區間或集合
邊界值:有序的或者有邊界的
分類樹:多種複雜的情況和參數取值,互相獨立,又沒有缺漏的子集
文法測試:将需求規格描述轉化未BNF範式
組合測試:多個參數取值和不同取值共同作用的需求規格
判定表測試:在輸入參數取值和輸出之間規定了從輸入取值得到輸出的邏輯規則
因果圖測試:本質上與判定表一緻
狀态轉移測試:某個軟體的多個行為,并且這些行為能夠被抽象未狀态遷移模型
場景測試:集合适合任何功能
随機測試:對輸入的機率描述或分布描述
各種基于規格說明書的測試設計方法:控制流圖描述
2.測試設計技術的選擇直接決定測試工作量投入的大小
3.測試計劃中包含對測試執行方法的設計和指導
測試執行的環境設計、測試執行的方法定義、測試執行和回歸政策
4.單元測試設計與實施:依據單元(子產品、元件、函數)的詳細設計書或代碼
方法為灰盒測試設計,綜合運用基于規格說明的測試設計技術盒基于結構的測試設計技術來設計測試用例
5.單元測試設計參考規則:
以場景測試為主、應用等價類和邊界值方法、考慮異步通信帶來的固有風險、狀态轉移測試、語句測試、分支測試
6.內建測試以基于規格說明的測試設計方法為主,基于結構的測試設計技術補充前者
7.內建測試工具具備以下功能:
擷取子產品間調用的資訊、比對子產品間調用、修改子產品間調用、重複子產品間調用、丢棄子產品間調用、延遲發送子產品間調用
8.自動化測試是內建測試的主要執行方法,由內建CI工具觸發
9.系統測試設計與實施:主要應用基于規格說明的各種測試技術,手工測試和自動化測試組合
10.驗收測試:一是從系統測試用例随機抽取一些基本使用場景,二是從使用者實際使用的場景出發,采用場景發來設計測試用例
驗收測試實施:通常以手工測試為主
四、測試估算與平衡決策
1.測試估算方法
1)寬帶德爾斐法(Delphi),專家法,各自獨立地對識别風險和風險緩解措施進行頭腦風暴估算
2)基于曆史資料法:參考過去項目的曆史經驗;沒有曆史資料,抽取一部分措施内容為工作任務,收集工作效率、返工次數等作為基礎進行測試估算
3)根據測試級别、測試類型和測試技術進行測試估算,可以從功能和風險的測試類型設計