1.3.3 可測試性的3個核心觀點

在正式討論可測試性的技術細節之前，很有必要先介紹可測試性的核心觀點。筆者認為可測試性有3個核心觀點（如圖1-10所示）。

圖1-10 可測試性的3個核心觀點

1. 可測試性是設計出來的

毋庸置疑，可測試性不是與生俱來的，而是被設計出來的。可測試性必須被明確地設計，

并且正式納入需求管理的范疇。在研發團隊內，測試架構師應該牽頭推動可測試性的建設，并與軟件架構師、開發工程師和測試工程師達成一致。測試工程師和測試架構師應該是可測試性需求的提出者，并且負責可測試性方案的評估和確認。在研發過程中，可測試性的評估要盡早開始，一般始于需求分析和設計階段，并貫穿研發全流程，所以可測試性不再只是測試工程師的職責，而是整個研發團隊的職責。

2. 提升可測試性可以節省研發成本

良好的可測試性意味著測試的時間成本和技術成本都會降低，還能提升自動化測試的可靠性與穩定性。今天在可測試性上的前期投資，會帶來后續測試成本的大幅度降低。今天多花的一塊錢可以為將來節省十塊錢，這再次證明了“很多時候選擇比努力更重要”。

3. 關注可測試性可以提升軟件質量

可測試性好的軟件必然擁有高內聚、低耦合、接口定義明確、行為意圖清晰的設計。在準備寫新代碼時，要問自己一些問題：我將如何測試我的代碼？我將如何在盡量不考慮運行環境因素的前提下編寫自動化測試用例來驗證代碼的正確性？如果你無法回答好這些問題，那么請重新設計你的接口和代碼。當你開發軟件時，時常問自己如何驗證軟件的行為是否符合預期，并且愿意為了達成這個目標而對軟件進行良好的設計，作為回報，你將得到一個具有良好結構的系統。

要讓研發團隊重視可測試性是件很難的事情，究其根本原因，在于研發團隊“不夠痛”。

長久以來，測試團隊和開發團隊一直是獨立的兩個團隊，開發工程師往往更關注功能的實現，其次才會關注一些類似性能、安全和兼容性相關的非功能需求，可測試性基本是沒有任何關注優先級的，因為測試工作并不是由開發工程師自己完成的，可測試性的價值開發工程師往往感受不到。而測試工程師雖然飽受可測試性的各種折磨，卻苦于處于軟件研發生命周期的后期，對此也無能為力，因為很多可測試性需求是需要在設計階段就考慮并實現的，到了最后的測試階段很多事情為時已晚。

很多時候，你不想改是因為你不痛，你不愿意改是因為你不夠痛，只有真正痛過才知道改的價值。所以應該讓開發工程師自己承擔測試工作，這樣開發工程師才會切身地感受到可測試性的重要性與價值，進而在設計與開發階段賦予系統更優秀的可測試性，由此形成的良性循環能讓系統整體的可測試性始終處于較高水平。