什麼是軟體可測試性？

不是每個應用程式都可以測試嗎？很可能是，但基於系統設計和架構，進行測試和發現bug實際上可能更容易或更困難。
有很多方法可以定義可測試性。在最基本的層面上，可測試性考慮了軟體測試的難易程度。檢視可測試性的另一種方法是測試暴露應用程式中錯誤的可能性。
有時，不管你運行了多少測試，應用程式的覆蓋範圍有多大，bug似乎仍然會悄悄地傳到客戶那裡。
這樣，可測試性是開發、產品和測試團隊之間有效溝通的產物。在建立功能時考慮的測試能力越多，其他團隊成員在此階段要求測試人員的輸入越多，測試就會越有效。
影響可測性的因素有很多，並且沒有好的方法來給出精確的度量，但是對被測系統的瞭解越多，測試就越直接，結果對整個團隊就越有價值。

為什麼可測試性很重要？

提出一個軟體可測試性的例子，並提倡它如何影響最終產品，意味著在產品進行測試之前的關鍵階段，如規劃、設計和程式碼評審，將更多地考慮這個想法。
可測試性是在設計和開發階段確定的，但對於其他需求（如可用性和功能性），它常常被忽略，因為應用程式通常是為使用者而不是為QA團隊構建的。
然而，建立一個高度可測試的應用程式最終也會讓使用者受益。可測試性影響可交付性。當測試人員更容易定位問題時，就可以更快地對其進行除錯，並且應用程式能夠更快地到達使用者手中，並且沒有隱藏的故障。此外，可測試性也將有助於產品和開發團隊。通過具有更高的可測試性，這些團隊將受益於更快的反饋，這將允許更頻繁的修復和迭代。
在軟體開發的生命週期中，我們經常談到更快地考慮質量。而不是等到測試，擁有一個完整的團隊方法來實現可測試性意味著在規劃、設計和開發過程中對應用程式給予周到的考慮。這包括強調多個方面，如文件、日誌和需求。測試人員對產品或特性、其用途和預期行為的瞭解越多，他們的測試和測試結果就越有價值。

可測試性與自動化能力

有時在考慮可測試性時，我們可能會將其與自動化能力或“自動化”混淆。相反，自動化能力會詢問多次執行測試是否有好處。雖然這兩者肯定是相關的，並且可能會相互影響，但有些東西可能是高度可測試的，但不是測試自動化的好候選物件，反之亦然。
當我們談論軟體測試和可測試性時，我們關心的是人類在測試期間能夠從應用程式中獲得哪些新資訊。在將測試包含在自動化套件中之前，確定測試的優先順序以及自動化測試的價值是很重要的。僅僅因為在自動化測試之後收到了“通過”或“失敗”，並不意味著這些資訊對團隊是有價值的。此外，有些測試可能很難或不可能自動化。
在花時間在自動化套件中建立和維護測試之前，瞭解自動化是否適合某個測試是很重要的。然而，退一步並首先確定應用程式的可測試性也很重要。雖然可測試性通常會告知測試是否自動化，但團隊可能會犯跳過可測試性而直接轉到自動化或自動化的錯誤。

為可測試性騰出時間

測試的核心是驗證某些東西是否有效。然而，許多事情會干擾測試的有效性——需求、條件、環境、工具、知識、資料、文件。
雖然可測試性對每個團隊來說可能意味著不同的東西，但重要的是確定哪些措施將幫助組織改進反饋和功能釋出。
此外，雖然“可測試性”一詞可能暗示這是QA 團隊的工作，但實際情況是，可測試性是整個團隊的質量方法，需要在釋出之前、期間和之後進行考慮。
當我們討論左移並在軟體開發生命週期中更快地將質量作為優先事項時，可測試性應該成為對話的一部分。通過將應用程式設計為固有的可測試性，釋出功能強大的高質量應用程式的障礙就會減少。
演示工具：www.eolinker.com