Quality Attribute Scenarios（12）：Testability General Scenarios

April 30 10:02~23:20

 

今天好累，可能是因為昨天去新店獅頭山爬山的原因。套句廣告的台詞：｢再累，也要寫一篇部落格文章｣。請翻開課本第89-90頁。

元素	可能的內容
Source	單元測試工程師，整合測試工程師，系統驗證工程師，驗收測試工程師，使用者，持續整合系統
Stimulus	分析完成，架構完成，設計完成，類別設計完成，子系統整合完成，系統交付
Artifact	設計片段，程式碼片段，完整的應用程式
Environment	設計時間，開發時間，編譯時間，部署時間
Response	提供存取狀態變數，提供存取計算後的變數，準備測試環境
Response Measure	有多少比例的可執行敘述被執行到，如果程式中真的有缺陷，那麼有多少的機率可以讓這些缺陷暴露出來，執行測試的時間，在一個測試案例中，最長的相依鏈長度，準備測試環境的時間

有了上面這個Testability General Scenario Generation表格，鄉民們就可以替自己的軟體架構定義出很多個testability QAS。接下來請看幾個例子：

Quality Attribute	Source	Stimulus	Artifact	Environment	Response	Response Measure
Testability	單元測試工程師	執行單元測試	系統元件	在元件開發完成之後	元件必須要提供控制自身行為的介面，而且元件的輸出必須要能夠被觀察到	在三小時之內必須做到85%的path coverage
Testability	整合測試工程師	執行整合測試	若干個子系統	子系統開發完成之後	子系統必須要提供控制自身行為的介面，而且子系統的輸出必須要能夠被觀察到	準備測試環境的時間必須少於10分鐘，在兩小時之內必須做到function coverage達到90以上。
Testability	持續整合系統	執行驗收測試	完整的應用程式	每天晚上七點(nightly build)	測試結果必須產生XML報表並上傳到持續整合系統中	在四小時之內必須執行完全部的驗收測試，且function coverage必須達到90以上
Testability	單元測試工程師	執行單元測試	method	在每一個method完成之後	method所需要的執行環境必須要能夠用mock object取代，且method所影響的物件狀態或輸出資料要能夠被觀察	在兩小時之內必須做到95的line coverage

以上就是testability QAS的內涵以及幾個簡單的範例。Teddy個人認為，testability是一件頗為困難的問題，它不但牽扯到軟體架構，也跟設計與實作的細節息息相關。例如，如果你的系統架構像是一坨糾纏不清的義大利麵，想必這樣的系統就很難切成一個個模組來單獨被測試。如果系統的設計遵循GoF Design Patterns裡面所說的programming to an interface，那麼就比較容易用mock objects來取代real objects，程式除了比較有彈性以外，也會變得比較容易測試（因為測試環境比較容易準備，也可以傳入不同的mock objects或是測試資料來改變程式執行的路徑，以達到較高的test coverage）。

課本中對於testability只提供了很大原則的方向，還有很多細節其實並沒有介紹到，但是至少算是一個起點。Teddy以前念書的時候有一度也差點拿design for testability來當作博士研究題目，後來因為題目太難而放棄了…Orz。有機會再把以前看過的testability資料拿出來整理一下，畢竟武功秘笈不能只有架構、設計與coding啊，design for testability也是很重要而且很難學（學不到，沒人教？！）的一門功課。

***

友藏內心獨白：還好課本的testability內容比較少，可以快速結束這一篇…XD。