軟件測試工具Mercury“最佳功能測試實踐”（二）

軟件測試工具Mercury“最佳功能測試實踐”（二）

1.1測試策略和計劃

        在制定測試策略時，要基于被測軟件的質量目標。質量目標就是測試的需求。它們決定了測試的階段和質量的目標。要想最優化測試的活動并制定一個切實可行的測試計劃，需要將被測軟件分解成為一個一個的業務功能。在進行業務功能分解時，要以黑盒的方法來看待被測軟件的功能，即獨立于軟件的實現方法。若想計算測試的效果并且保證測試的活動適合于特定業務的需要，則需要引入風險評估的手段。

        1.1.1   需求

        測試的必要條件是要確定預期結果或者需求。為了能更好的了解需求，將需求進行分類是非常有幫助的。以我們的觀點，可以將需求分為功能性需求和質量需求（非功能性需求）。功能性需求描述了在業務上期望如何使用新的軟件系統，且該系統中應該包括哪些功能。質量需求包括的是軟件系統的通用特性，且獨立于功能。

        1.1.1.1      功能性需求

        功能性需求以業務設計圖的方式記錄于文檔中。為了在TestDirector中將需求作為測試的基礎，需要將需求導入到TestDirector中。相應的業務設計圖作為需求的附件存在，并作為將來測試活動的依據。

        1.1.1.2         質量需求

        質量需求由兩部分構成，一部分是為整個產品或者項目定義的質量目標，另一部分是每個業務功能的質量需求，這些業務功能的質量需求取決于風險評估的結果。

        1.1.1.2.1       質量目標

        1）適應性

        組件被修改以適應新需求的難易程度。

        2）完整性

        組件實現所有需要的能力的程度。

        3）正確性

        a)        組件在規格分析、設計和實現過程中無錯誤的程度
        b)        組件滿足需求或者用戶需要與期望的程度
        c)        基于給定輸入產生相應輸出的能力，并且這個過程符合或者滿足需求

        4）有效性

        當組件完成指定任務時，能最少使用所需資源的程度。

        5）可維護性

        組件被修改以糾正錯誤，提高性能或其他屬性，或者適應被改變了的環境的難易程度

        6）模塊性

        軟件系統由離散的組件組成的程度，即改變一個組件時能將對其他組件的影響降至最低。

        7）可移植性

        軟件系統或組件能被轉移到其他硬件平臺或者軟件平臺上的難易程度。

        8）可靠性

        組件在一定的時間內、一定的條件下執行所需完成功能的能力。

        9）可用性

        用戶對軟件組件的理解和操作的難易程度。

        1.1.1.2.2       業務功能的質量需求

        業務功能的質量需求是依據業務的風險進行定義的。業務風險和技術復雜度的信息存儲在測試的需求中。這兩個參數決定了測試的程序和測試的工作量。另外，針對業務功能分配測試員，并且將測試活動的當前狀態落實到紙面上。只有這樣做才能在針對業務功能的整個測試過程中監控測試的狀態。