軟體測試文檔的深度與廣度_文檔

 

　　[概述]

　　軟體測試文檔是測試過程中輸出的軟體測試工作產品，類似於軟體工作產品。然而實踐中經常面臨有無數的軟體測試文檔需要撰寫，而使用文檔的效果卻是非常有限。本文闡述了軟體測試文檔深度與廣度選擇需要考慮的一些因素。

　　[本文]

　　測試文檔是測試人員在測試過程中輸出的測試工作產品，類似於軟體工作產品，是形式化測試過程的重要組成部分。IEEE829是軟體測試行業內最有名的文檔標準，它提供了一種很好的軟體測試文檔描述，同時描述了軟體測試文檔之間以及與測試過程之間的關係。

　　行業內不少公司在使用IEEE829測試文檔標準，或者以IEEE829為基礎開發自己公司的文件範本，但是實際的結果並不樂觀，主要表現在：

　　1）成本較高：測試人員需要花費大量的時間投入到測試文檔的編寫，按照模板填充類似格式的案頭工作；

　　2）效果較差：按照測試文件範本編寫出的並不是特別有價值的大量原始材料，甚至由於時間的限制，測試文檔幾乎在測試過程中沒有什麼人看；

　　3）文檔維護成本高：特別是在測試文檔的輸入軟體工作產品變更的時候，不僅要修改捆綁到軟體變更部分，而且還要搜尋必須修改的其他有關聯的內容。

　　因此，純粹照搬使用IEEE829測試文件範本，或者公司內部開發的文件範本並不是提供測試文檔的初衷。為了提高測試文件範本的效率和有效性，測試人員需要考慮測試文檔需要解決什麼問題，它的主要目的是什麼。假如希望編寫出好的測試文檔，需要有測試文件範本的支援，而更重要的是測試人員需要瞭解模板沒部分的含義，為什麼需要有這部分，什麼時候可以刪除這部分內容，即測試人員必須能夠根據公司特徵和項目特點合理裁剪測試文件範本。

　　決定什麼內容包含到測試文檔中，什麼內容不包含，應該以項目需求為基礎。為了更好的確定測試文件範本的深度與廣度，即合理裁剪測試文件範本，測試人員至少需要考慮下面的這些因素：

　　1）測試目標

　　測試人員測試該產品或者系統的目標是什麼。假如測試文檔不能支援這個目標，或者無助於達到這個目標，那麼這樣的測試文檔（與所建立的所有其他軟體工作產品一樣）價值就會降低很多。

　　2）測試文檔是產品還是工具

　　假如測試文檔是軟體系統或者產品的一部分，那麼這些文檔是需要發布給客戶使用的，這時候測試文檔就需要按照客戶的要求遵循某種表尊。而假如測試文檔只是內部使用的工具，那麼就不必太完整、太整齊，能夠在最低限度上有助於達到目標即可。

　　3）軟體設計變更是否頻繁

　　如果軟體設計變更很頻繁，則不要將許多細節寫入測試文檔中，因為這些細節很快就會過時。這種情況下，不要編寫大量的測試文檔，它們被修改或者放棄的速度太快，不值得在測試文檔上投入太多。

　　4）採用的測試方法

　　假如目前採用的軟體開發模型是V模型之類的線性模型，那麼採用的測試方法通常是依賴於預先定義的測試，這時候需要詳細的測試案例的操作和維護文檔。假如採用的是探索性測試，則更需要策略方面的文檔，例如：關於某個測試領域的想法，但不是具體的測試案例。

　　5）測試文檔給誰看

　　假如測試文檔是主要給新的測試人員或者沒有經驗的測試人員看，那麼需要足夠詳細使得他們能夠正常開展工作。

　　測試人員在裁剪測試文檔的時候，上面的這些問題可以協助測試人員思考，寫出他們所需要的東西，以及內容的詳細程度，以達到測試文檔的目標。

本文轉載自51Testing軟體測試網，查看更多：http://www.51testing.com/html/news.html