TOp4：金蝶自動化測試發展之路
一、引言
我們為什麼需要自動化測試？
ERP軟體的測試工作面臨如下挑戰：
業務複雜度高、功能眾多。
需求變化頻繁。
產品部署複雜。
以黑盒測試為主。
單靠手工測試需要花費巨大的人力和時間成本，集成測試周期越來越長，已經無法滿足產品發布要求，需要尋找一種更高效率的測試手段來保證合理的產品發布周期。
同樣，我們也有如下機遇：
（1）隨著公司業務的快速發展，客戶日益增多，市場對產品的質量要求越來
越高，公司研發團隊在當年進行了較大的組織架構調整，獨立設制了測試部，下設技術測試部，成立了獨立的自動化測試組，從此KD的自動化測試發展走向正規化。
（2）我們公開的新產品架構較為先進，對ERP業務進行了高度抽象，形成了獨特的業務開發平台，基於此平台開發的ERP軟體具有標準化、規範化的特點，界面的一致性對自動化測試的技術發展非常有利。基於以上原因，KD的自動化測試有了良好的起點。
二、案例解讀
我們回顧一下KD公司在自動化測試領域的發展歷程。希望大家通過了解我們公司自動化測試的發展過程，能夠帶來一些借鑒作用，特別是在這個領域剛開始起步或者正準備起步的一些同仁們。
時間回到2004年，當時我們公司正處於一個高速發展期，客戶數量成指數級增長，公司對我們研發產品的質量要求越來越高，這時候測試部發現單靠增加人力已經很難解決當前的問題，於是開始了自動化測試的研究，希望通過自動化測試能夠在提升研發效率方面發揮作用。當時，自動化測試這個概念在國外軟體發達國家已經非常火，所以我們對它還是抱以非常高的期望，測試部門召集了幾個對自動化測試感興趣的同事一起成立了自動化虛擬團隊，開始把現有的手工用例轉換成自動
化測試腳本，採用的是當時最流行的套路——錄製回放，然後我們也加入一些數據驅動和腳本編輯等功能，大家熱情非常高漲，很快就開發出相當一部分測試腳本，能夠覆蓋產品的最基本功能。可是很快就發現腳本維護是個很大的問題，測試腳本極其不穩定，每次產品重新構建發布，都有相當一部分用例執行失敗，又得重新錄製腳本再進行編輯，成本相當高，並且隨著時間的推移，一些腳本很難讀懂，最後到了無法維護的地步，這時候大家極其希望自動化測試能夠更加專業化。
時間再到了2005年，研發領導開始重視測試專業化的發展，在部門結構上進行了重大調整，專門成立獨立的技術測試部門，致力於研究一些先進的測試手段來提高研發的測試效率。技術測試部理所當然地下設了自動化測試小組，專門從事自動化測試的研究工作。這個時候，金蝶的自動化測試終於有了正規軍，從此開始了突飛猛進的發展。自動化測試組在2006年初步建立了一套基於關鍵字驅動的自動化測試框架，開始在整個測試部門大力發展自動化測試，測試用例的數量規模到達一個新的高度，並且實現了夜間無人值守的自動化測試執行，從代碼自動構建輸出到產品自動安裝部署再到啟動自動化測試執行，以及最後形成測試報告，都是夜間自動完成的。可以說，成績非常喜人，大家看到了勝利的曙光。 然而，過了一兩年後，我們又遇到新的發展瓶頸，自動化測試覆蓋率的繼續提升成了一個非常頭疼的問題，自動化測試用例的數量很難再有較大的提升，只有五個人的自動化測試小組很難維護兩條產品線上數百條自動化測試用例，主要原因也跟我們測試團隊的人員結構相關。也許大家都知道，國內軟體測試團隊主要是以用戶測試為主，所以招聘的測試人員主要是業務出身，以我們公司這類的ERP軟體公司為例，大部分測試
人員以前的工作性質都是會計、供應鏈、生產製造等專業，對編程知識完全沒有接觸，如果讓他們來編寫自動化測試腳本幾乎是不可能完成的任務。所以當時我們採用的模式是，由業務測試人員按照我們提供的自動化測試用例模板填寫測試用例，然後再由自動化測試人員把它轉換成自動化腳本，經過調試通過後發布到正式的夜間自動化測試環境中，當用例執行失敗的時候，先由自動化測試人員分析是否為自動化測試本身引起，如果確認不是，則與用例對應業務測試人員溝通，確認是否為產品Bug還是需要調整測試用例，直到用例再次調試通過。這樣，自動化測試人員的腳本調試及後期的用例維護都需要相當多的工作量，其中跟業務測試人員之前的溝通成本也佔了相當一部分工作量，以至於到最後我們無法承接業務測試組提交過來的更多自動化測試用例了。這個階段自動化測試的發展又遇到新的瓶頸。是繼續補充自動化測試組的成員，還是尋找新的發展方向？我們確實迷茫了好一陣子。
看看我們當時是如何做的。2008年，經過大家的思考，我們最終確立新的發展方向，嘗試建立一套強大的、覆蓋整個自動化測試生命周期並且基於業務驅動的自動化測試平台，通過大幅降低自動化測試的技術門檻，幫助業務測試人員能夠獨立開展自動化測試工作。而自動化測試組成員不再承擔自動化腳本調試的工作，而是把主要精力放在完善自動化測試平台的工作上。隨著自動化測試的開發維護工作下放到每一個業務測試組，逐步實現全員開展自動化測試，從而讓自動化測試的規模能達到一個新的高度。通過這一系列的平台改造，自動化測試平台確實得到了長足的進步，也讓自動化測試的發展得到了延續，逐步邁向成熟階段。
自動化測試平台結構圖，如圖1-36所示。
三、案例成功（或教訓）要點
（一）技術維度
1. 自主研發測試框架
為符合企業自身的自動化測試需求，需要設計一套適合企業自身特點的自動化測試平台，可以基於現有的商業測試工具或開源測試工具或框架。
2. 元數據解析
元數據是金蝶產品的架構特點，可以根據元數據信息抽取出界面元素以及測試步驟，比錄製測試對象有一定優勢，提取速度快，自定義提取信息。
3. 關鍵字驅動
關鍵字驅動是當前比較主流的自動化測試設計思路，利用它可以大幅減少後期的腳本維護成本。
4. 分散式執行
隨著自動化測試規模的擴大，單機版自動化已經不能滿足需求，需要建立自動化測試機器群來分散式執行用例，目前我們夜間同時運行的自動化測試機器已經接近兩百台。
5. 多媒體日誌
通過圖片日誌、視屏日誌等多種日誌展示手段，幫助測試分析人員快速定位錯誤原因。
6. 虛擬化技術
利用虛擬化技術可以充分利用現有機器硬體資源，並且利用它的克隆功能可以快速搭建自動化執行機的環境。
7. 多種測試手段
自動化測試不僅僅局限於基於界面的功能測試，也應包括單元測試、介面測試等多種測試手段。
（二）管理維度
1. 平台化思維
自動化測試工具應該樹立平台化發展思路，加大技術投入力度，適應企業測試模式的規模化、標準化、普及化、長期化的發展。
2. 持續集成模式
按照持續集成的理念建立自動化測試體系，更加有效地發揮自動化價值。
3. 上層領導的支持
自動化測試的成功是長期積累後才能得到的結果，需要持續的投入和運營，所以獲得上層領導的長期支持是至關重要的一環。
四、案例ROI分析
自動化用例已覆蓋產品主要功能，形成研發質量的基石，自動化通過率已成為項目各階段里程碑的重要指標。
持續集成系統保障開發輸出成果穩定，確保大型研發團隊有效運作。
逐步推進質量前移，開發人員開始參與到質量工作中來，通過有效開展自測降低集成風險。
五、案例啟示
每個企業都有不同的特點，只有找到適合企業自身特點的方法才是最有效的。在整個發展過程中，要不斷保持創新，持續改進，敢想敢幹，終究會找到一條適合自已的發展道路。研發產品的質量不單單是靠測試人員來保障的，需要全員保持質量意識，通力合作才能達到理想的質量目標。
TAG:開源測試聯盟 |