3. 越早開始越好
(1) 儘早和高層取得對測試自動化的共識
測試自動化有不少好處，但是它不是萬靈丹，它有它極限以及所要付出的代價。因此要及早和高層取得共識，讓他們知道什麼是測試自動化可以做到的，以及我們可以做到多少，並且要花多少effort。之後他們才不會有過度的期待，你也會較容易得到適當的支援，讓雙方能夠達到雙贏的結果。
(2) 及早和RD討論以增加可測試性(testability)
測試程式的撰寫是否可以有效率，有一部分是決定於受測程式的可測試性(testability)高不高。所謂可測試性是指什麼呢，就是指你對受測程式的可控制性，即你可以用哪些方法來控制受測程式的運作，方法越多或是越容易實作就代表可測試性越高。
有哪些控制的方法呢？有些像是增加一些額外的API；有些是在debug log中加入一些特別的output；有些是在UI上顯示一些訊息；有些是產生一些訊息在event viewer中。
kojenchieh 發表在 痞客邦 留言(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 發表在 痞客邦 留言(0) 人氣()
