談談測試工具的開發

　　每次做測試架構師，就會面臨測試工具的問題。尤其是在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的，讓測試人員不斷地使用工具以獲得反饋。測試人員是測試工具的用戶，來自用戶的聲音永遠是最重要的。自動化的程度是可以協商的，測試結果分析自動化往往是吃力不討好的，自動化應該偏重于配置、執行和管理。出錯處理是需要很小心的，盡量不要測試一出錯就停止測試，這個要讓測試人員來權衡。

　　其實測試工具的開發和普通的軟件開發沒有太多的區別，這么蜻蜓點水一下，似乎沒有多大的幫助。只是很多公司都在面臨如何開發和使用自有測試工具的問題，我也順嘴談一談。

原文轉自：http://www.spasvo.com/news/html/2013327154929.html#