軟體可測試性(Software testability)是指一個软件工件(軟體系統、模組、需求文件或設計文件等)在一給定的測試環境下,可支援測試的程度。
許多軟體系統是不可測試的,或是無法立即測試。例如Google的ReCAPTCHA,若沒有任何有關圖的元資料,則無法成為可測試的系統。不過若針對每一張圖,都有對應說明應有結果的標籤,就可以測試此一系統。因此软件工件的可測試性不是性質,不像軟體大小一様可以直接量測。軟體可測試性是外在性質,由待測試的軟體及測試目標、方法及測試資源(測試環境)之間的相互關係來決定。
「可測試性」和設計良好程度的相關性可由以下現象看出:低內聚性、高耦合力、存在多餘程式碼,以及缺乏封裝的程式往往也是不容易測試的程式。若軟體的可測試性低,可能會造成測試工作的增加。在一些極端的情形下,缺乏可測試性可能會使部份甚至全部的測試或对的评估無法進行。
為了要找到可測試性以及利用測試找到系統中潛在錯誤(假設有錯誤時)的難度的關係,有一種評估可測試性的相對指標,是每一次需要多少的測試用例才能形成完整的測試套件(在測試了所有測試用例後,所得到的結果可以確定此系統符合某規格,或不符合某規格,不會有模糊地帶)。若數量不大,表示程式的可測試性高。依照此方式,已有提出可測性等級(testability hierarchy)。
背景知識
依照实证的假設,軟體測試的工作量及有效性和以下幾個因素有關:
- 的性質。
- 軟體本身的性質(像大小、複雜度及可測試性)。
- 測試方法的的性質。
- 開始及測試流程的性質。
- 和測試流程有關人員的资格和动机。
軟體元件的可測試性
軟體元件(模組或類別)的可測試性和以下因素有關:
- 可控制性:是否可以將待測元件的狀態控制到如測試條件要求。
- 可觀察性:是否可以觀察(中間或最後的)測試結果。
- 可隔離性:待測元件是否可以隔離測試。
- 关注点分离:待測元件是否有單一且清楚定義的任務。
- 易懂性:待測元件是否有說明文檔,或是本身可讀性很高。
- 可自动化性:待測元件是否可以自動測試。
- 异质性:是否需要不同的測試方法及工具平行測試。
軟體元件的可測試性可以用以下方式提昇:
- 测试驱动开发
- 可测性设计(design for testability),類似硬體的為測試而設計。
需求的可測試性
具有測試性的需求要符合以下的條件:
- 一致性
- 完整性
- 明确不含糊
- 可量化(像「反應時間快」的需求是無法被驗證的)
- 實務上的軟體驗證及確認(不只是理論上可行,在有限資源下也是可實現的)
相關條目
*可測試性
參考資料
- Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, ISBN 0-201-80938-9
- Stefan Jungmayr: [https://web.archive.org/web/20071009021801/http://www.dissertation.de/index.php3?active_document=%2FFDP%2Fsj929.pdf Improving testability of object-oriented systems], ISBN 3-89825-781-9
- Wanderlei Souza: [https://web.archive.org/web/20110716104553/http://patterns-wg.fuka.info.waseda.ac.jp/SPAQU/proceedings2009/3-P2-AbstractTestabilityPatterns.pdf Abstract Testability Patterns], ISSN 1884-0760
评论 (0)