全程軟件測試之測試需求分析與計劃（3）

2.6  測試風險分析

在1.1.4節 討論了測試的風險觀點，測試被定義爲「對軟件系統中潛在的各類風險進行評估的活動」，這意味着軟件測試有較高的風險，因此軟件測試的風險分析很是重要。軟 件測試風險，就是要將測試範圍、測試過程當中的風險識別出來，肯定哪些是可避免的風險，哪些是不可避免的，對可避免的風險要儘可能採起措施去避免。

風險識別的有效方法是創建風險項目檢查表，按風險內容進行逐項檢查、逐個確認。對於測試的風險，能夠給出以下一個風險項目檢查表，如表2-8所示。

在測試風險分析中，逐項檢查，確認風險以後，要找出對策，以免風險產生或下降風險所帶來的影響。表2-9給出了軟件開發中常見的風險，說明這些風險發生的可能性、對測試的影響和影響程度以及如何進行預防和控制。

下面會針對本書的兩個典型案例給出簡單的風險分析。客戶端軟件的測試風險相對來講會低一些，因此不作討論。並且本書對軟件測試中廣泛存在的風險也不作討論。

 

1．Google Talk的幾個測試風險

?  若是基本功能方面的問題太多，將嚴重影響性能壓力測試的進度。

?  在第二輪測試後，產品應該基本無大的問題。開發要在第三輪測試開始前保證修復好全部已發現的主要問題。

?  多語言版的測試要求測試人員前期準備充分，測試人員對所測語言有可能不太瞭解，對該語言國家的使用習慣也不是很熟悉。

?  開發人員拿出產品的初版本時，要提供或與測試人員共同完成壓力測試工具的開發。

2．Google日曆的測試風險

（1）項目複雜度。因爲開始對項目的複雜度估計不足，致使項目後期的產品代碼不能按時完成，這樣勢必會影響到測試的環節。

（2）需求的變化。用戶的反饋、市場需求的變化會致使項目後期增長一些新的產品功能，這樣就會使產品不能按照原定的測試計劃完成，以至測試人員處於等待狀態中。

（3）服務器的升級。基於Web方式的產品，隨着不斷推出的新服務器產品（如Linux和Apache的版本升級），其兼容性須要驗證，並且其安全性、穩定性和性能等方面所受到的影響須要分析，在測試過程當中更換第三方產品的新版本，就要面臨這樣一個問題——是否要從新測試已測試的範圍。每每不會從頭再來，而是根據已定義的策略進行選擇性的測試。

（4）數據庫的升級。基於Web方式的產品，後臺通常都離不開數據庫的支持。若是測試過程當中遇到數據庫表結構的變化、版本升級（例如Oracle 9i升級到Oracle 10G），都會給測試過程帶來風險。例如，升級後的數據庫變得不穩定，有可能退回到原來的版本，影響測試甚至致使測試的失敗。

（5）測試環境的不穩定性。例如被測試的服務器不能被訪問，須要從新啓動和配置，這會佔用必定的時間。一旦不能訪問測試環境，測試人員不只無事可作，還經常會抱怨。這種狀況影響了測試人員的情緒，最終也影響了測試結果。

（6）國際化和本地化的影響。如支持哪些語言版本？國際化版本的測試策略和方法、翻譯公司是否能及時完成任務，以及翻譯是否準確也會帶來風險。

 

3．測試風險的控制方法

（1）根據風險發生的機率和帶來的影響肯定風險的優先級，而後採起措施避免那些能夠避免的風險。如測試環境不對，能夠事先列出要檢查的全部條目，在測試環境設置好後，由其餘人員按已列出條目逐條檢查。

（2）風險轉移。有些風險帶來的後果可能很是嚴重，可否經過一些方法，將它轉化爲其餘一些不會引發嚴重後果的低風險。如產品發佈前發現某個不是很重要的新功能給原有的功能帶來了一個嚴重的Bug，這時處理這個Bug所帶來的風險就很大。對策是去掉那個新功能，轉移這種風險。

（3）有些風險不可避免，就設法下降風險。如「程序中未發現的缺陷」這種風險老是存在，就要經過提升測試用例的覆蓋率來下降這種風險。

（4）爲了不、轉移或下降風險，事先要作好風險管理計劃。例如，把一些環節或邊界上有變化、難以控制的因素列入風險管理計劃中。

（5）對風險的處理還要制定一些應急的、有效的處理方案。例如，爲每一個關鍵性技術人員培養後備人員，作好人員流動的準備，採起一些措施確保人員一旦離開公司，項目不會受到嚴重影響，仍能夠繼續下去。對全部過程進行平常跟蹤，及時發現風險出現的徵兆，避免風險。

（6）在作計劃時，估算資源、時間、預算等要留有餘地，不要用到100%。

（7）制定文檔標準，並創建一種機制，保證文檔及時產生。對全部工做多進行互相審查，及時發現問題。

知識點:

風險管理的基本內容有兩項：風險評估和風險控制（如圖2-8所示）。

（1）風險評估，主要依據三個因素：風險描述、風險機率和風險影響。能夠從成本、進度及性能三個方面對風險進行評估，它是在創建在風險識別、風險分析和風險排序基礎上的。經過評估能夠肯定這些風險的特色或可能帶來的危害。

（2）風險控制，制定風險管理計劃和風險應急處理方案，來下降風險和消除風險。

2.7  制定有效的測試策略

爲了最大限度地下降測試風險，儘早地發現各類潛在的軟件缺陷，在測試實施以前，測試組必須肯定合適、有效的測試策略，並以此爲依據選定測試方法、測試工具和測試用例設計思想。經過制定測試策略來指導測試用例的設計、測試工具的選擇和執行，特別是能解決測試當中常常碰到的一些問題。良好的測試策略必將給軟件測試帶來事半功倍的效果，能夠充分利用有限的人力和物力資源，高效地完成測試目標。

測試策略描述當前測試項 目的目標和所採用的測試方法，針對某個應用軟件系統或程序，具體的測試項目要達到的預期結果還包括在規定的時間內哪些測試內容要完成，軟件產品的特性或質 量在哪些方面獲得確認。測試策略還要描述測試不一樣階段（單元測試、集成測試、系統測試）的測試對象、範圍和方法，以及每一個階段內所要進行的測試類型（功能 測試、性能測試、壓力測試等）。其內容包括以下。

?  對測試的公正性、遵守的標準作一個說明，證實測試是客觀的，軟件功能要知足總體需求，實現正確，並與用戶文檔的描述保持一致。如聲明測試完成的標準是95%的測試用例經過而且兩個最高級別的缺陷所有被修正，用以計劃、實施及通報測試結果。

?  描述測試用例是什麼樣的，如何執行，用了什麼樣的數據，又如何執行後續的迴歸測試。

?  選定要使用的測試技術和工具。如採用了什麼工具，工具的來源是什麼，是否60%用Rational Robot自動測試、40%用手工測試。

?  根據經驗判斷和頭腦風暴，對以往測試中常常出現的問題加以考慮。又如採起一些發散性的思惟，每每能幫助找到新的測試途徑。

?  考慮影響資源分配的特殊狀況。例若有些測試必須在週末進行，有些測試必須經過遠程環境執行，有些測試須考慮與外部或硬件的接口。

爲了更好地肯定軟件測試策略，能夠試着問以下一些問題，在尋找這些答案的過程當中，也就找到了最佳的測試策略。

?  迴歸測試的範圍如何肯定？

?  如何利用可重複性的測試？

?  測試缺少可預見性，如何收集衡量測試結果的指標？

?  如何創建穩定的、模擬系統實際運行的測試環境？

?  如何從無窮的輸入數據中選擇合理的、有效的測試數據集？

?  如何增強靜態測試——規格說明書、設計文檔和程序代碼等的審查？

?  如何處理單元測試和集成測試的關係？

?  如何處理手工測試和自動化測試之間的平衡，使它們的互補性獲得發揮，使測試的效率和質量達到最佳狀態？

?  如何衡量這種測試策略的有效性？

1．測試策略制定的三項基本要素

軟件測試策略制定有三項基本要素：輸入、輸出和過程。

（1）輸入，做爲制定測試策略的依據，包括限制條件和已具備的資源：

?  所要求的軟、硬件的詳細說明，包括測試環境、測試工具等；

?  人力資源和測試進度的約束，包括測試組成員的角色和職責說明；

?  測試方法和衡量測試是否經過的標準；

?  被測軟件組件或系統的功能性和技術性需求文檔，及其變動請求的控制流程；

?  軟件系統所受到的其餘限制。

（2）輸出，制定策略的成果，即最終對所制定策略的定義或說明：

?  經過/失敗的準則和測試風險評估的結果；

?  已批准和簽署的測試策略文檔；

?  和測試策略相對應的測試計劃、測試用例的設計思想和思路。

（3） 制定策略的過程。測試組分析需求，參與設計的討論，要求開發、編寫針對全部測試級別的測試策略，並和項目組一塊兒複審測試策略和測試計劃。測試策略應該覆蓋 整個項目的生命週期，須要各種技術人員（系統架構師、數據庫管理員、編程人員等）參與。各種技術人員相互之間應多交流、討論，以保證制定正確的測試策略。

2．基於測試技術的測試策略

著名的軟件測試專家Myers指出了使用各類測試方法的綜合策略。

?  在任何狀況下都要使用邊界值分析方法，由於爲邊界值分析方法所設計的測試用例能頗有效地發現軟件代碼的缺陷。

?  等價類劃分方法是對邊界值分析方法的有效補充。

?  如果軟件某些功能的輸入數據/條件存在多種組合狀況，則一開始就可選用因果圖法。

?  錯誤推測法能夠幫助追加一些比較特殊、不易直接推理出來的測試用例。

?  對照程序邏輯來審查已有測試用例的邏輯覆蓋程度。若是沒有達到要求的覆蓋率，則應當再增長一些測試用例。

?  儘管用戶更傾向於基於程序規格說明的功能測試，可是白盒測試能發現潛在的邏輯錯誤，而這種錯誤每每是功能測試發現不了的。

3．分階段的測試策略

?  嚴格地執行代碼複查，以保證在早期就發現問題，而不是在代碼發佈以後。

?  利用單元測試和集成測試，能夠儘早地發現更多的問題，並準備好自動化測試的BVT（Build Verification Test，軟件包驗證測試）。

?  須要創建一個正規的且自動化的冒煙測試，只有100%經過冒煙測試，才能進入下一個階段。

?  系統測試中，以每次發佈用戶基線爲結束標誌，用戶基線會增加，同時也會逐漸地要求一些更爲精確的性能測試。

?  不能忽略安全性測試、可用性測試、配置測試和數據完整性測試。

?  在功能性測試、安全性測試、配置測試中可進行一些探索性測試。

?  制定更爲詳細的UAT（用戶驗收測試）測試計劃，將其與測試腳本和培訓材料一塊兒提供給用戶，以幫助用戶快速提升並完成任務。

4．基於測試方案的綜合測試策略

（1）根據軟件產品或服務特性對客戶的使用價值以及特性失效所形成的損失，來肯定相應特性的測試優先級。產品特性的優先級越高，其被測試的時間越早，測試的力度也越大。

（2）要使用盡量少的測試用例，發現儘量多的程序錯誤。一次完整的軟件測試事後，若是程序中遺漏的（較）嚴重錯誤過多，則代表本次測試是不足的或失敗的，這意味着可能讓用戶承擔較大的利益損失風險。反過來講，若是過分測試，則又會浪費軟件企業自身的寶貴資源。因此，須要在以上兩點——風險和效率上進行權衡，找到一個最佳平衡點。

（3）測試策略應該儘可能的簡單、清晰，例如能夠在有限的白板上經過2～3行字和1～2個圖就描述出測試策略來，或者能夠經過一個簡短的會議（20～30分鐘），就能把測試策略解釋清楚。

（4）基於缺陷分析的測試策略。經過缺陷分析，能夠更好地瞭解開發人員的習慣，找到容易犯錯誤的地方，能夠更好地設計測試用例，更快地發現缺陷。也能夠從缺陷出發，反推回去，找到合適的測試策略。

5．測試策略的示例

在Google日曆的測試項目中，要考慮在瀏覽器和操做系統的不一樣組合下進行測試。最簡單的辦法就是完成全部組合的測試，如5個操做系統（Windows 2010 server、Windows 7、Windows 8、Mac 10.8、Linux）和7個瀏覽器（IE8、IE9、某個中文、Chrome、Firefox、Opera、Safari）的組合有近35種——由於有些組合是不多出如今實際的環境中。之前面所說的360個測試用例爲基礎，在各類環境上共要執行12 600多個測試用例，工做量太大。這時就須要根據操做系統和瀏覽器的市場佔有率、對測試用例的影響程度、缺陷分析的結論和經驗等，簡化或優化組合。從表2-10能夠看出，等價組合降到了8，只要執行大約2880個測試用例，測試的工做量大大減小。

針對Google日曆這樣的產品，還能夠制定針對功能性和用戶界面的測試策略。如按照Google日曆的功能劃分來設計測試用例，保證一系列的邏輯被有效地驗證。

?  輸入時間或活動的組合（不一樣長度和單雙字節的字符串長度）。

?  在相同的時間或活動在不一樣日曆裏面的顯示和跳轉（用戶界面）。

?  改變用戶的不一樣設置。

測試上述的功能在不一樣的分辨率和上述操做系統、瀏覽器的組合。

概念

（1）冒煙測試（Smoke Testing）是在代碼被檢查進入（check in）代碼庫以前對代碼修改進行驗證的流程或活動。在代碼複審（code reviews）以後，冒煙測試是識別和修正軟件缺陷的最有效方法。它能夠確認代碼的修改符合要求和指望，且不會形成軟件包構建的失敗。冒煙測試和自動化迴歸測試的腳本集一塊兒被用來測試那些高風險的功能或高容量的事務處理。

（2）BVT（Build Verification Test）是軟件包構造以後由測試工具（腳本）完成的驗證測試，用以確認基本功能正常，沒有出現嚴重的缺陷。BVT經過後，才進行手工測試，或者進一步的自動化測試。

2.8  完整生成測試計劃書

在軟件測試需求和測試範圍分析、工做量估計、測試資源和進度安排、測試風險評估、測試 策略制定等工做作完以後，測試計劃也就基本大功告成了。測試計劃自己就是爲了解決測試目標、任務、方法、資源、進度和風險等問題，因此當這些問題被解決或 找到相應的對策和處理措施以後，測試計劃剩下的工做就是寫好這個文檔，將上述內容描述清楚。有一點必須在這裏說明的是，測試計劃是一個過程，不只僅是「測 試計劃書」這樣一個文檔，測試計劃會隨着狀況的變化不斷進行調整，以便於優化資源和進度安排，減小風險，提升測試效率，並及時修改「測試計劃書」。

在計劃書中，有些內容是介紹測試項目的背景、所採用的技術方法等的，這些內容僅僅做爲 參考，但有些內容（如人員組成、日程安排）也能夠看做是一種結論，或者承諾，是必需要實施或達到的目標，如測試小組的結構和組成、測試項目的里程碑、面向 解決方案的交付內容、項目標準、質量標準、相關分析報告等。測試計劃內容的焦點則集中在下列內容上。

（1）目標和範圍：包括產品特性、質量目標，各階段的測試對象、目標、範圍和限制。

（2）項目估算：根據歷史數據和採用恰當的評估技術，對測試工做量、所需資源（人力、時間、軟硬件環境）作出合理的估算。

（3）風險計劃：對測試可能存在的風險進行分析、識別，以及對風險的迴避、監控和管理。

（4）進度安排：分解項目工做結構，並採用時限圖、甘特圖等方法制定時間/資源表。

（5）資源配置：人員、硬件和軟件等資源的組織和分配包含每個階段和每個任務所須要的資源。人力資源是重點，並且與日程安排聯繫密切。當發生相似到了使用期限或者資源共享的時候，要及時更新這個計劃。

（6）跟蹤和控制機制：包括質量保證和控制、變化管理和控制等，明確如何準備去作一個問題報告以及如何去界定一個問題的性質，問題報告要包括問題的發現者和修改者，問題發生的頻率，是用什麼樣的測試用例測出該問題的，以及明確問題產生時的測試環境。

測試計劃書的內容也能夠按集成測試、系統測試、驗收測試等階段去組織。爲每個階段制定一個計劃書，還能夠爲每一個測試任務/目的（安全性測試、性能測試、可靠性測試等）制定特別的計劃書。

同時，能夠爲上述測試計劃書的每項內容制定一個具體實施的計劃，如將每一個階段的測試重點、範圍、所採用的方法、測試用例設計的思想、提交的內容等進行細化，供測試項目組的內部成員使用。對於一些重要的項目，會造成一系列的計劃書，如測試範圍/風險分析報告、測試標準工做計劃、資源和培訓計劃、風險管理計劃、測試實施計劃、質量保證計劃等。對於更爲詳細的要求，能夠參考國家標準《測試計劃（GB8567—88）》中制定的測試計劃通用模板。

2.9 小結

本章主要討論測試需求和如何建立有效的測試計劃。測試需求包括功能測試需求和非功能性 測試需求，而非功能性測試需求包括性能、安全性、可靠性、兼容性、易維護性和可移植性等測試需求。對於非功能性測試需求，既要獨立考慮它們各自的特色和各 自的測試需求，也要考慮它們之間的關係和相互影響，例如安全性和可靠性密切相關，越安全越可靠，越可靠越安全。而安全性會增長許多保護措施，每每會下降性 能。在整個系統測試需求分析時，不只要考慮來自總體系統的測試需求，還要考慮系統數據、外部接口等測試需求，如圖2-9所示。

在測試計劃過程當中，主要作好下列各項工做。

?  肯定軟件功能性、非功能性的測試需求，以及各個階段的測試任務。

?  進行測試範圍分析，從而對測試工做量進行估算。工做量估算方法主要介紹工做分解結構表方法，並給出了實例。

?  測試資源需求、團隊組建，包括培訓。

?  測試里程碑和進度的安排。

?  對測試風險進行分析。

?  制定有效的測試策略。

最後完整地生成測試計劃書，進行計劃書的評審、跟蹤和及時修改，測試計劃是一個過程，不只僅是「測試計劃書」這樣一個文檔，測試計劃會隨着狀況的變化不斷進行調整，用以優化資源和進度安排，下降風險，提升測試效率。

——————本文節選自《全程軟件測試（第2版）》