目前日期文章:200806 (2)

瀏覽方式: 標題列表 簡短摘要
3. 越早開始越好

(1) 儘早和高層取得對測試自動化的共識

測試自動化有不少好處,但是它不是萬靈丹,它有它極限以及所要付出的代價。因此要及早和高層取得共識,讓他們知道什麼是測試自動化可以做到的,以及我們可以做到多少,並且要花多少effort。之後他們才不會有過度的期待,你也會較容易得到適當的支援,讓雙方能夠達到雙贏的結果。

 
(2) 及早和RD討論以增加可測試性(testability)

測試程式的撰寫是否可以有效率,有一部分是決定於受測程式的可測試性(testability)高不高。所謂可測試性是指什麼呢,就是指你對受測程式的可控制性,即你可以用哪些方法來控制受測程式的運作,方法越多或是越容易實作就代表可測試性越高。

有哪些控制的方法呢?有些像是增加一些額外的API;有些是在debug log中加入一些特別的output;有些是在UI上顯示一些訊息;有些是產生一些訊息在event viewer中。

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

測試自動化做了幾年後,累積了一些心得,希望能夠跟大家交流一下。

1. 僱用開發能力強的QA
一般公司的QA通常沒有coding能力或是coding經驗不夠,因此若是要測試自動化有顯著效果,必需能僱用開發能力強的QA來應付以下狀況:
(1) 需求經常變動
每個人都知道需求是一直在變動的,因此RD常常需要修改程式來配合。此時若是QA的開發能力不強,他是無法在短時間反應這樣的變動。再加上若是手動測試(manual testing)的工作忙碌,不難想像測試自動化會放到一旁,最後甚至可能就會無疾而終。

(2) 測試結果的確認很複雜

有時候寫測試程式不一定很難,但是要檢查測試結果是否正確,卻不是一件簡單的事。例如要檢查安裝程式是否安裝正確,你可能要檢查files、 registry keys、services、processes等等是否正確
若是它是網頁程式你可能還要檢查Web server的設定。手腳不快或是功力不強,可能無法順利用寫程式來一一檢查。


2. 有彈性的架構設計
因為需求經常變動,因此需要有彈性的架構設計來加以減輕重寫的effort。不要因為RD程式一變動,就幾乎測試程式要全面性修改。當然有時候也不是需求變動才會造成測試程式有問題,有時候是因為執行環境的複雜度、測試
輔助工具的低掌握度、或是其他一些外在的問題。

例如檢查license key是否過期的測試程式,測試的流程可能是輸入一把license key,然後檢查他是否啟動過。如果是,才檢查他是否已經過了使用期限。此時測試程式若只是單純的讀入license key(如它的使用期限是2009/01/01)去檢查其結果,這測試結果在2008年執行的時候是未過期的,但是在2009測試的時後便會出現已過期,所以這測試程式在2009年後已經無法再使用。


因此這時候架構設計的重要性就顯示出來了,因為一般測試程式大多是直接讀取raw test data,沒有經過一些特別的設計。若是將raw test data改成是如何產生license key的方式(如建立一把離現在一年後才會過期license key),而測試程式會根據此指示,產生真正的測試資料去做驗證。這樣這支測試程式便可以永久使用,不會因為時間久了,導致測試資料過期無法再運作。

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼