需求階段測試可以做哪些事情？

MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">測試人員不是在開發人員代碼實現后才開始介入一個項目的，而是在一個項目開始立項后就開始介入，這個已經是個不爭的問題了。那么，測試在項目的早期可以做哪些工作呢？測試前移是個很大的話題，今天只討論一下需求階段測試人員如何介入？

首先，需求階段如何定義？比較完整的需求階段至少包括兩個部分：一是初始包需求（OR－Offered Requirement）確定階段，這個階段的參與人員會直接和市場、用服、客戶溝通交流、調研，確定產品開發的初始需求；二是初始需求交給研發團隊，系統工程師進一步分析，結合產品原有基礎、收集內外部需求，得出產品要實現的包需求，并采用系統分析的工程方法開展對包需求的深入分析，得出更細化的需求描述，輸出可以被實現的設計需求，交給軟件實現人員。如果按照CMM流程，前面一個階段CMM沒有涉及，對應Charter之前的工作；后面一個階段對應TR2之前的工作。

一般而言測試的前期介入大多指介入后面一個階段，其實前面一個階段測試也應該參與，當然，參與前面一個更早的需求分析階段，對測試人員的要求會更高一些，需要對系統層面有較好的把握。本文就談談這兩個階段測試分別可以做哪些事。

（1）測試參與早期需求分析

這個階段收集到的需求都是比較粗的，測試更多的可以從SVT的角度考慮問題，即這些粗的需求如果實現后，后期交給客戶時，是否可驗收，有哪些驗收場景、驗收的思路是什么、具體的商用使用場景、需求驗收是否需要特殊的驗證平臺、有哪些驗收難點等等�？梢暂敵觥缎枨篁炇辗治鰣蟾妗�。這樣做的好處，一是測試人員通過早期參與，更清楚需求的來源和目的，有利于后期更好的從用戶的角度開展測試活動；二是可以為后期設計驗收測試用例提供很好的分析依據。

當然，這個階段的實踐經驗目前應該比較少，至少測試業界還沒有形成完整的理論體系，歡迎網友分享經驗。

（2）測試參與TR2之前的需求分析

這個階段的需求仍然比較粗，至少開發人員拿到這些OR直接去實現難度還是很大的。系統工程師會從全系統的層面開展稍微細一些的需求分析，得到具體的設計需求，其主要的思路主要是針對每個OR開展場景分析，測試介入的主要工作就是重點參與場景分析工作，因為開發的SE和測試的TSE分析問題的思路是不同的，可以做到很好的互補，所以理想的方式是SE和TSE一起完成場景分析工作：SE偏向從功能、實現的角度分析，TSE更多的考慮非功能屬性方面，比如可靠性、可測試性等，還會考慮用戶分類、異常場景、組網的不同等，這樣二者合作的結果，使得設計需求更易于實現，也一定程度消弱了需求由于分析不充分導致后期的頻繁變更的問題。

另外，這個階段測試還應該發揮測試的優勢，提出產品的可測試性需求，以便開發在實現階段就考慮進去。

當然，除了上面提到的以外，測試在早期的任何時候都可以針對開發的各種分析輸出件給予很好的評審檢視，我們都知道缺陷越早暴露成本越低。