軟體可測試性（Software testability）是指一個软件工件（軟體系統、模組、需求文件或設計文件等）在一給定的測試環境下，可支援測試的程度。

許多軟體系統是不可測試的，或是無法立即測試。例如Google的ReCAPTCHA，若沒有任何有關圖的元資料，則無法成為可測試的系統。不過若針對每一張圖，都有對應說明應有結果的標籤，就可以測試此一系統。因此软件工件的可測試性不是内在（英语：Intrinsic and extrinsic properties）性質，不像軟體大小一様可以直接量測。軟體可測試性是外在性質，由待測試的軟體及測試目標、方法及測試資源（測試環境）之間的相互關係來決定。

「可測試性」和設計良好程度的相關性可由以下現象看出：低內聚性、高耦合力、存在多餘程式碼，以及缺乏封裝的程式往往也是不容易測試的程式^[1]。若軟體的可測試性低，可能會造成測試工作的增加。在一些極端的情形下，缺乏可測試性可能會使部份甚至全部的測試或对軟體需求（英语：Software requirements）的评估無法進行。

為了要找到可測試性以及利用測試找到系統中潛在錯誤（假設有錯誤時）的難度的關係，有一種評估可測試性的相對指標，是每一次需要多少的測試用例才能形成完整的測試套件（在測試了所有測試用例後，所得到的結果可以確定此系統符合某規格，或不符合某規格，不會有模糊地帶）。若數量不大，表示程式的可測試性高。依照此方式，已有提出可測性等級（testability hierarchy）^[2][3]。

依照实证的假設，軟體測試的工作量及有效性和以下幾個因素有關：

• 軟體需求（英语：Software requirements）的性質。
• 軟體本身的性質（像大小、複雜度及可測試性）。
• 測試方法的的性質。
• 開始及測試流程的性質。
• 和測試流程有關人員的资格和动机。

軟體元件（模組或類別）的可測試性和以下因素有關：

• 可控制性：是否可以將待測元件的狀態控制到如測試條件要求。
• 可觀察性：是否可以觀察（中間或最後的）測試結果。
• 可隔離性：待測元件是否可以隔離測試。
• 关注点分离：待測元件是否有單一且清楚定義的任務。
• 易懂性：待測元件是否有說明文檔，或是本身可讀性很高。
• 可自动化性：待測元件是否可以自動測試。
• 异质性：是否需要不同的測試方法及工具平行測試。

軟體元件的可測試性可以用以下方式提昇：

• 测试驱动开发
• 可测性设计（design for testability），類似硬體的為測試而設計。

具有測試性的軟體需求（英语：Software requirements）需求要符合以下的條件：

• 一致性
• 完整性
• 明确不含糊
• 可量化（像「反應時間快」的需求是無法被驗證的）
• 實務上的軟體驗證及確認（不只是理論上可行，在有限資源下也是可實現的）

• 可測試性

• Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, ISBN 0-201-80938-9
• Stefan Jungmayr: Improving testability of object-oriented systems, ISBN 3-89825-781-9
• Wanderlei Souza: Abstract Testability Patterns, ISSN 1884-0760