每次做測試架構師，就會面臨測試工具的問題。尤其是在System Verification部門，他們的case是在模擬使用者對產品的使用，產品的功能不斷新增，但是使用者的行為卻是可遵循的，而且是複雜的，是各種行為的組合。不斷地重複測試，似乎是在浪費測試人員的時間。在這種情況下，自動化測試工具就成為提高測試效率，解放測試人員的法寶。
如何開發測試工具，有很多需要注意的地方。
記得我剛去WiMax部門做測試架構師的時候，WiMax功能測試組需要軟體組幫他們做一個截獲正常報文，產生錯誤報文的工具。我和測試人員交流的時候，測試人員說這個工具很不好用。我再去詢問軟體人員，他們很驚訝。說已經完全按照需求實現了功能，該做的都做了，怎麼就不肯用呢？我具體看了看他們的實現，發現基本功能確實都實現了，可是確實沒辦法用。測試人員不僅僅需要這個軟體實現截獲和修改報文的功能，更需要在實際的測試過程中靈活地使用它來實現整體的測試。軟體人員沒有做過測試，無法正確地理解測試人員的需要，再加上兩個部門一個在15樓，一個在16樓，交流很不通暢，才造成彼此無法理解，做不出真正需要的東西。我和軟體人員坐在一起，仔細地告訴他們我需要怎樣來用這個工具，需要他們提供什麼樣的介面，測試人員該如何接入和管理這個軟體，哪些配置要圖形化，哪些配置要被自動化工具呼叫，需要什麼樣的輸出，哪些狀態實時顯示，哪些資料需要統計，哪些log需要輸出到統一的log文件中，等等。他們才恍然大悟，原來截獲和修改報文只是很基本的需求，還有那麼多事情要做。
所以，開發測試工具，最理想的情況是找一個既精通開發，又精通測試的人來做。但這樣的人比較難找。更普遍的辦法是讓軟體人員和測試人員緊密合作，互相理解，才能夠真正完成可用好用的產品。
在我看來，一個好的自動化測試工具，需要注意以下特點：
第一，必須將資料、配置和功能分開
第二，儘量使用已有的穩定的公開庫
第三，使用c，java還是tcl，python，各有利弊
第四，封裝基本功能，提供呼叫介面，用於測試人員的二次開發
第五，儘量採用統一的可直接編輯的格式用於記錄資料、配置和log
第六，不要求大求全，也不要採用過於複雜和靈活的測試框架，要有針對性，簡單為上
第七，圖形介面友好，符合測試人員的使用習慣
第八，注重系統效率，要採用多程式以利用多核CPU
第九，提供測試結果採集、統計和log分析頁面
第十，要考慮如何容納已有的測試case
我們曾經使用過Mobile Metrics的測試套件，據說這個公司只有9個人在開發和維護這個產品，但這個測試套件功能強大，比一般大公司100個人做出來的東西還要好，絕對是我們學習的楷模。這個套件是用c和java寫的，底層呼叫和報文處理都是c，以提高系統效能。使用者介面都是java，非常友好。提供了眾多的介面呼叫，封裝粒度合理，測試人員可以用非常簡單的java語言實現非常複雜的測試行為，如入網、退網、handover等等。提供標準的java呼叫，讓測試人員方便地使用其他標準功能，如產生隨機數，條件語句，迴圈語句，網路連線，檔案讀寫，報文分析等等。
還有Spirent的自動化測試套件，這個套件在使用介面上非常友好，配置和執行測試都很方便。我們曾經仿照它的模式來管理自己的測試case。但它不夠開放，要想在上面做2次開發不是很容易，需要請Spirent專門派人來協助和培訓。Spirent的測試套都是用Tcl寫的，我們覺得Tcl在開發大型測試軟體的時候有點難度，出了錯很難查錯，開發環境不夠友好，不如c和java方便。Python近幾年發展比Tcl快，可以呼叫的庫很多，開發環境也友好一些了。但Tcl和Python的效率都要差一些。我們自己寫的測試管理工具還相容了原先大量使用的內部測試工具，可直接執行原來的case，只是將測試結果和log記錄下來。這樣就不需要重寫了。
我們曾經研究過泰克的測試工具。泰克的圖形化做得是最面面俱到的，連設計一個測試流程，也只需要用滑鼠拉來拉去，這樣其實很限制靈活性，只能按照它所設定的模式來設計測試，二次開發很難。它的配置和資料也都是用自有的格式儲存的，必須用它的工具來開啟和修改。我個人不大喜歡這樣的測試工具。
我們公司內部也有一些自動化測試的工具，有些是自己開發的，有些是外包的。我也不大喜歡這些工具，因為功能很弱，圖形化差，不靈活，也不能與時俱進。這些程式碼都是從頭開始寫的，比起外面那些開原始碼和公開庫，無論是質量還是數量，都差遠了。
順便說說開發測試工具的流程。
要開發一個測試工具，首先就是要了解測試人員的需求。需求包括測試功能本身的需求，和如何使用工具的需求。
然後是定義模組和介面。模組包括功能模組和輸入輸出模組。功能模組由上及下逐步細分，分到多細取決於功能的複雜程度和介面的數量。每個模組要儘量獨立，減少彼此的依賴。畫幾個資料流程圖，看看需要哪些介面，介面引數如何定義。定義介面的時候要考慮到擴充套件性。當然，擴充套件性和簡單化，有的時候要進行取捨。我們沒必要面面俱到，但至少要考慮近期的擴充套件需求。查詢已有的庫函式，儘量減少自己開發的工作量，儘量採用一些標準做法。輸入輸出模組要和測試人員一起溝通，給測試人員儘量多的呼叫介面以實現複雜的測試行為。輸入輸出模組往往是一個測試工具成敗的關鍵，這常常是軟體人員容易忽視的。如果是效能測試工具，必須要考慮硬體的承受能力。如果能夠做到分佈執行，那當然是最好的了。
測試工具的開發過程最好是和測試人員pair-work的，讓測試人員不斷地使用工具以獲得反饋。測試人員是測試工具的使用者，來自使用者的聲音永遠是最重要的。自動化的程度是可以協商的，測試結果分析自動化往往是吃力不討好的，自動化應該偏重於配置、執行和管理。出錯處理是需要很小心的，儘量不要測試一出錯就停止測試，這個要讓測試人員來權衡。
其實測試工具的開發和普通的軟體開發沒有太多的區別，這麼蜻蜓點水一下，似乎沒有多大的幫助。只是很多公司都在面臨如何開發和使用自有測試工具的問題，我也順嘴談一談。