April 26 17:19~17:58
趁著還沒把書放回書架，就繼續介紹testability（可測性）這個QAS好了。Testability這個非功能需求長久以來普遍的被軟體開發人員所忽視，反正軟體能動就好了，「容不容易測」這個問題老闆跟客戶也都看不到，幹嘛花時間在這上面。但是，根據Teddy的觀察，近年來在台灣已經逐漸有越來越多的軟體開發團隊，會要求程式設計師撰寫單元測試，此時自己所寫的程式「容不容易測」常常會影響到軟體的開發時程與軟體品質。
好，testability、testability，這個字大家都會念，但是，什麼叫做testability？怎樣去衡量一個軟體的可測性高不高哩？
依據課本88頁的解釋，testability表示軟體透過測試（通常是以執行待測程式的方式來測試）可以被找出錯誤的難易程度。因為軟體開發至少有40%的成本是花費在測試上面，所以如果軟體架構師可以投注心力在減少測試成本上，這樣的投資將會非常地值回票價。
學過測試的人應該都知道（真的嗎？），一個軟體要能夠充分地被測試，測試者就必須要能夠控制軟體內每一個元件的內部狀態。控制狀態的方法通常是藉由控制輸入資料來達成，然後觀察輸出結果來判斷軟體行為是否正確。通常開發人員對使用測試工具（test harness）來對軟體做自動化測試，這類的工具像是著名的xUnit系列，或是利用capture and play方式測試使用者介面的工具。
執行測試的角色包含開發人員、測試人員、驗證人員（verifier）、或是使用者。關於測試的時間點，課本還是採用waterfall的方式來看待軟體開發，所以課本上說測試是軟體開發生命周期的最後一個階段。這一點可以不用理會課本的講法，因為現在鄉民們應該都知道，寫程式跟測試（至少在單元測試這一層）其實是一體兩面，或是說不可分割的一部分。而且測試要越早做越好，千千萬萬不要拖到「軟體開發生命周期的最後一個階段」，那將會是很恐怖滴。
至於衡量「容不容易測」的標準，可藉由觀察測試案例是否能夠很有效率的發現一個軟體缺陷，或是為了達到一定的測試涵蓋率而必須花費多久的時間來執行測試案例。
***
友藏內心獨白：怎麼一下子就寫完了…XD。
斗膽請問，如果我寫的程式是不是處理業務邏輯那種的，而是比較接近處理影像相關的 (其實是一個2D動畫軟體)，那該怎麼做到高可測性、甚至是自動測試呢?
回覆刪除To chchwy Chang:
回覆刪除這個問題太難了，如果要透過 GUI去自動化測試2D動畫（是game嗎？）這Teddy沒有這方面的經驗。大體上，一個軟體（不管是不是遊戲軟體）要容易被測試，至少要做到model和view分離，並且在view中儘量不要有什麼複雜的邏輯。如此，就可以針對model做自動化測試，至少可以確保程式中重要的邏輯是正確的。這樣一來就算view無法自動化測試，也可以將人工測試的工作減到最低。
另外，為了讓view『有可能』或是『比較容易』被測試，有時候程式裡面會設計一些專門為了自動化測試而存在的介面，讓測試程式可以呼叫。