l

2012年5月1日 星期二

Quality Attribute Scenarios(12):Testability General Scenarios

April 30 10:02~23:20

image

 

今天好累,可能是因為昨天去新店獅頭山爬山的原因。套句廣告的台詞:「再累,也要寫一篇部落格文章」。請翻開課本第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。

沒有留言:

張貼留言