主題：如何定義測試流程 好的測試流程必須滿足一柔一剛兩種要求。其柔性的要求是：測試的所有活動能夠被組織和定義的平滑高效，實施起來沒有阻滯和混亂。而其剛性的要求是：組織中的每個人能夠充分了解自己的工作輸入條件和輸出準則，大家既有檢查上一步工作是否到位的權利，又有按時保質保量地完成工作的義務。
所謂開發過程中的正規化，核心就是科學的定義流程和嚴格的執行流程。一個測試項目成功的關鍵是各個環節能夠環環相扣和緊密配合，這就要求測試流程必須定義的清晰科學。
一、柔性要求：流暢的測試流程
測試的所有活動能夠被組織和定義的平滑高效，實施起來沒有阻滯和混亂。
一個普通的版本測試過程中，會經歷的一些活動：
新版本發布說明（Release Notes）
測試任務書（Task Description）
升級測試版本（Release Update）
問題驗證（Error Verification）
基本功能測試（Release Test）
新功能測試（New Feature Test）
壓力測試（Stress Test）
自由測試（Free Test）
問題報告（Error Report）
進度報告（Progress Report）
二、剛性要求：嚴格的測試規程
組織中的每個人能夠充分了解自己工作的輸入條件和輸出準則，大家既有檢查上一步工作是否到位的權利，又有按時保質保量地完成工作的義務。
輸入條件：
（1）輸入之一：測試用例（case）
測試用例必須簡明扼要，分布均勻，不能有太多重復的用例，又不能有明顯的疏漏。這些都需要在測試項目開始之前得到保證，指望測試執行階段的自我修復是靠 不住的。所以需要根據需求跟蹤矩陣來設計測試用例，同時建立定期評審的機制來彌補被忽略的功能點和根據實踐中遇到的各種情況來更新補充測試用例。
（2）輸入之二：測試分工
測試分工是為了讓每個測試的執行者清楚地了解自己在何時應該做什么，有哪些具體的要求。測試經理在每輪測試之前進行詳盡的任務細化并通過有效的溝通機制傳達給團隊中的每個成員，最正規的途徑是下達書面的測試任務書（測試計劃）給團隊的每一個成員。
（3）輸入之三：測試工具
對于測試工具的要求有兩個。
第一是好用，在選擇測試工具的時候要慎重和廣泛的比較，要保證我們即將使用的工具確實能夠幫助我們——可以制定一個規范的測試工具評審表，按照測試的需求把測試工具的表現做定量的評估。
第二是大家都會用，每個測試人員都必須了解自己需要用到的測試工具及其使用方法。——要制定完備的培訓計劃，讓每位項目成員通過培訓來學到工具的使用方 法和各種規則，同時測試的管理者應該能夠一目了然的看到培訓的組織和參加情況（簽到表），避免因新加入的成員培訓不及時而影響工作的質量。
（4）輸入之四：提交物的模板（BUG提交工具）
模塊化是讓工作步調一致的捷徑，它能讓一個即使經驗不夠豐富的項目成員也能夠在很短的時間內提交出質量不錯的輸出物。所以模板必須要簡單清晰，盡量避免給使用者過多的自我發揮的空間，用形式來約束內容。
輸出準則：
（1）輸出之一：測試結果（用例執行結果）
測試結果的意義并不在于有沒有人看，它的意義主要體現在，當測試的粒度均勻的情況下，能夠定量地描述出當前軟件的穩定程度。而且多輪測試的力度相同，那么可以從測試結果的通過率上可以看出軟件功能實現的變化趨勢。
要降低用例的“不可測率”，測試團隊需要制定有針對性的工作流程來監控“不可測”的測試用例；對于長期“不可測”的測試用例即使封殺，使之不再占用測試人員的時間；對于短期“不可測”的測試用例，要及時快速的創造測試的條件，把測試的黑洞及時修補上。
（2）輸出之二：問題報告（提交BUG的描述信息）
問題報告是測試工作最主要的輸出物，必須做到清晰、詳盡，提供盡可能多的信息。包括問題出現的軟件版本、日期、測試人員的姓名和聯系方式、問題的概要描述、重現概率、重現步驟、和先決條件、期望的輸出和實際的輸出等。
（3）輸出之三：調試信息（Log日志）
調試信息是必不可少的，它能夠幫助開發人員了解問題發生的時候系統在做些什么事情。在測試開始之前要對測試團隊進行深入的培訓，需要每個人都明確哪一類問題需要提交哪一類調試信息，獲取調試信息的手段、工具、配置等。
（4）輸出之四：模塊測試報告
模塊測試報告是很有價值的開發文檔之一。第一條就是，報告的完成要及時，不能等新聞成了舊聞才看到事后諸葛亮似的報告。另外內容要既粗且細，粗 是為了迎合層次比較高的管理者；細是為了當讀者有興趣的時候，能夠從報告中了解到足夠詳細的內容。此外模塊測試報告中應當盡量提供：模塊的穩定程度 （case通過率）、模塊的穩定趨勢（與上一個版本的case通過率做比較）、嚴重問題的列表。
（5）輸出之五：修改驗證（BUG修改驗證）
對一般的開發團隊來講，衡量其績效的一個重要指標就是改BUG的反應速度，而一個BUG的終結一定是以通過測試人員驗證的時間為準。修改驗證的 優先級永遠都應該是測試人員案頭優先級最高的任務。因為遲早對于此BUG的修改一定是會進入到產品基線中的，所以與其晚驗證不如早驗證，這樣我們可以有更 多的時間測試那些可能由此修改帶來的風險。
及早對修改進行驗證，這一方面是對開發人員的支持，另一方面如果此修改不解決問題甚至帶來了其他問題，及早驗證能給開發人員更多的時間做進一步檢查。
三、自我約束：測試過程評估
在測試過程中要對測試的過程有定期嚴格的評估，以便及時發現并糾正測試過程中出現的問題。
組織一個兼職的監督小組，成員包括測試項目組長，若干測試工程師和獨立的軟件QA，由他們按照事先約定的項目和內容定期評估測試過程。對測試質量的評估不僅僅要停留在一兩個測試用例執行的結果上，更高層次的評估重點是評估測試過程的合理性和效率。
三張圖表：測試工作流程圖、宏觀測試流程、項目評估方法
版權聲明：本文出自 hellorenwei 的51Testing軟件測試博客：http://www.51testing.com/?578951
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關鏈接：
《笑傲測試》筆記（前言+第一式：廬山面目）
《笑傲測試》筆記（第二式：蓬門始開）
《笑傲測試》筆記（第四式：矯如龍翔）