互聯網業務測試團隊如何快速構建輕量級的自動化(2)

　　每個子系統的目錄組織如下：

　　這里有個小的tricky的地方，為了部署的時候更靈活，希望腳本里面互相引用的文件是相對的路徑，但是JMeter支持不太好，默認的根目錄是bin，所以簡單的做法是把整個自動化用例的目錄copy到JMeter的bin下面。

　　2. 因為我們有多個系統，對應多個測試小組，大家各有專注，而我們電商的業務又是一個長鏈條。function層就是我們復用的基礎，里面再包含對CGI層接口的調用。這里有點JMeter的技術細節，2.10開始建議用TestFragment來組織，而TestFragment是不能直接執行的，只是些積木，到了TestCase層面再用ThreadGroup現場組，才可以執行。

　　下面是一個完整的TestCase，include了本系統和其他系統的一些function座位步驟。用例細節其實還有很多需要打磨的地方，比如命名規范，執行起來不容易。

　　3. 自動化的報告，每次執行完了之后自動的發郵件報告出來。

　　為了更好的定位問題，需要把每個接口執行的細節也暴露出來，點擊詳情可以看到調用的情況，包括request和response的數據。

　　除了好處，也有一些不方便的地方：

　　1. JMeter在include其他的jmx腳本后，不能直接在界面顯示加載的內容，所以看不到被include的腳本里面的步驟，調試的時候不方便。不過好在JMeter可以一套binary啟多個，并著看。

　　2. 最后的結果報告里面，不能控制展示的粒度，是直接攤開成CGI層面的步驟，顯得比較雜。

　　目前我們執行的情況

　　1. 目前覆蓋了200多個CGI接口，以及100多個功能點，初步有4個系統掛接到了自動部署后的執行。用例還在進一步的擴展中，框架不需要改動。JMeter本身的穩定性還是不錯的。

　　2. 整個過程，不算制作用例的時間，我們實際投入的測試開發的人力合起來不到一個人月。

　　3. 大部分業務測試同學都參與到了用例的制作，提升了對業務邏輯的理解，并且對部分同學來說，也補了HTTP協議等基礎知識的課，實際動手比聽聽培訓效果要好。

　　從實際的效果和投入來說還是比較滿意的。

　　除了技術層面，自動化執行起來有幾個核心的要點：

　　1. 一定要強掛鉤到測試和發布的環節。

　　這一點看起來沒那么重要，但是如果不希望自動化成為花瓶，就必須要這樣做。像互聯網產品這樣快的節奏跑起來，任何花哨的環節會逐漸被洗掉，因為人員的配比和版本的數量，不是必做的東西慢慢就堅持不下來。所以自動化如果要能發揮效果，目前來看最合適的點是在每次自動部署后快速的刷一遍，在手工測試開始之前。而且如果要人工去點，這事兒時間長了也不靠譜，一定要把這個過程也自動化，版本在測試環境部署好了之后，自動化自動跑完，這就是強的掛鉤。

　　2. 報告也是要自動的，并且郵件抄送給相關的開發，測試和團隊的負責人。我們現在的做法是跑完了腳本解析后自動的發郵件報告。

　　3. 非100%成功的都要跟進。

　　寧愿少而精，這個也類似broken window理論，如果能容忍一個用例失敗，就會有2個，3個，也會讓自動化慢慢失去意義。目前的做法是只要有失敗，對應系統的負責同學要郵件reply all跟進原因。

原文轉自：http://blog.csdn.net/superqa/article/details/20644285