開放性敏捷自動化測試架構介紹(5)

　　這個比賽的目的是提升公司各個環節的持續改進能力，最終達到提高質量，降低成本，縮短周期的目標。ROBOT作為參賽項目之一，一共有18只隊伍參加，參賽隊伍覆蓋了從生產線、質量部、客服部、技術支持部、研發部等各個環節的部門;大部分的隊伍都是與生產線有關，因為生產線是最好量化及體現成本節約成果的。我們的隊伍是兩只與軟件測試相關的隊伍之一。比賽在杭州與深圳通過視頻會議兩地同步進行，總體感覺演講的效果還不錯，贏得了不少的掌聲。有幸的 ROBOT項目進入了8強，下周要參加在杭州的總決賽。

　　言歸正傳，我們還是來討論自動化技術方案。上周末參加了IBM舉辦的技術加油站，主要是以介紹工具為主，感覺IBM的測試工具就是進行界面的自動化錄制等等，與行業的LR,QTP沒有太本質的區別，對于接口測試，舉了SOA應用的例子，感覺也就是簡單的手工接口測試，要想實現大規模的接口回歸測試還有很大的差距，如果要想支持不同特點的應用的測試就更加不可能。

　　我一直提倡用有效性來衡量一項創新的用途，包括自動化測試也一樣，如果自動化測試單純停留在宣傳上說又多么多么的重要，多么多么的節省人力，另外一方面卻發現不了問題，沒有數據的支撐的話，是經不起時間考驗的，更不能說服別人心甘情愿的學習和推行自動化。另外一方面，如果自動化很有效果，但要花很多時間去寫自動化腳本的話，其維護量是驚人的，這條路走起來代價非常大，測試人員根本享受不到自動化帶來的便捷，因為我們以前是走過彎路的，所以感受特別深;試想，當你開發了一萬個CASE，但是一旦系統修改了設計，要去修改一半的CASE，即使你再有耐心，也會被這種修改腳本的無意義勞動所打倒。

　　如果想當然的認為一個軟件版本到一定程度就能穩定，那是理想的狀況，一般情況下除非小軟件或者軟件被廢棄了才會有這種情況，實際情況下，對于有一定規模的軟件公司，其軟件版本的代碼超過千萬行是很普遍的，而且系統會隨著不同客戶的需求不斷的增加修改和刪除，這就是軟件缺陷的來源。UT ROBOT就是在這種背景下產生的，把ROBOT比喻為一條生產線的話，解析引擎是核心，抽象的模板的機器運轉的傳輸帶，數據就是原料，數據整合部分一個過濾器，分離的結果檢查點則是自動質檢系統，每一部分看似都是獨立的部分，因為獨立也就意味著低耦合，這也就是ROBOT能實現不同類型的軟件自動化測試的原因。

　　有很多人發郵件問我ROBOT怎么可能不需要編寫腳本，其實大家有所誤解，ROBOT與業務無關，但是對于數據模板的解析還是要根據不同的應用進行模塊化擴充的，實際的擴充代價是比較少，因為我把模板中的標簽進行了自動解析識別，增加模板中的元素只需要配置解析的規則就可以輕易支持新的模板。另外如果有新的傳輸協議，還是要增加底層支持的。一旦新的模板加入，測試人員就只需要根據接口文檔進行業務數據接口配置，再通過ROBOT的編譯引擎產生大量的自動化可執行CASE，一定業務邏輯發生了變化，只需要在數據配置文檔進行數據的修改，重新編譯數據文檔就可以重新生成自動化CASE，維護代價是非常低的。

　　我認為如果要推行自動化測試，就不要盲目的使用商業測試工具，從長遠來講，要根據各行業各公司的特點去開發符合自己需求的的自動化框架。測試無止境，需要我們在平時的工作中敢于發現問題、多從不同的角度去思考，才能真正開發出有效的自動化測試軟件，技術不是自動化最重要的因素，好的想法才是王道。

原文轉自：http://www.uml.org.cn/Test/2008090410.asp