測試自動化做了幾年後，累積了一些心得，希望能夠跟大家交流一下。
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)，而測試程式會根據此指示，產生真正的測試資料去做驗證。這樣這支測試程式便可以永久使用，不會因為時間久了，導致測試資料過期無法再運作。
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)，而測試程式會根據此指示，產生真正的測試資料去做驗證。這樣這支測試程式便可以永久使用，不會因為時間久了，導致測試資料過期無法再運作。
全站熱搜
留言列表
