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

  最近閱讀微軟關于自動化存在明顯差異的兩派討論，對微軟內部的爭論不便置評。我所從事的領域與微軟的有一些差異，主要是側重電信領域的軟交換及BOSS業務的測試，從本人多年所處理的現場問題來看，在現場發生的約80%的問題來源于軟件版本升級后引入的新功能帶來的對老功能的影響，有過不少沉痛的經驗教訓。

      我們公司曾經設置過專門的自動化測試部門，轟轟烈烈的從事自動化平臺的開發，基本上發動了測試部門的所有同事從事測試CASE的腳本開發，時間力行半年，結果由于眾所周知的原因，整個自動化體系以失敗告終，最后，該自動化測試部門也就無疾而終了。我總結了一下，主要是下面的原因造成，這基本上也是行業內不同公司實施自動化失敗的主要原因：

      1.自動化平臺的思路缺乏創造性，基本上都是以腳本編寫CASE，錄制回放為主。

      2.傳統的自動化體系存在以下成本因素，導致自動化的投入產出比較高，從而制約了自動化的有效實施

         2.1 開發成本

      2.2 調試成本

      2.3 維護成本

      2.4 培訓成本

      2.5 規范化成本

    眾所周知，BOSS系統以業務眾多為主，以業務受理單一個接口為例，我們的測試案例庫就存在不下3000個CASE，如果通過傳統的編寫自動化腳本來進行CASE轉化的話，從我們以前實施的代價是：由于每個CASE都要涉及到腳本編寫，環境清理，環境設置，結果檢查，調試等幾個步驟，一個人一個月能完成的CASE不過50個，一旦應用的業務發生變化，相關的CASE也就作廢了，在這種情況下，大家也就清楚了自動化為何操作不下去的原因了.

    通過分析傳統自動化所固有的缺陷，我重新定義了自動化架構的核心新思路：自動化架構必須實現CASE的產生，執行，結果檢查三大要素的分離。我把新自動化的架構命名為ROBOT，無巧不成書，IBM也存在名字為RATIONAL ROBOT的一個架構產品，我事先是不知道的，文章后面，我把我們的ROBOT和IBM的RATIONAL ROBOT的特性進行了比較。

    通過將近六個月左右時間的開發，這個架構基本開發成功，并應用到了10多個應用的接口測試中，發現了超過200個問題，實現了以下功能：

    1.對新應用的接口支持只需要不到2周的時間

    2.以通用模板為基礎，所有CASE自動產生

    3.結果檢查點自動產生，可以快速產生包括100萬的結果檢查點

    4.可支持多協議

    通過ROBOT框架測試過的產品在多個現場實施之后，竟然在半年的時間內沒有報過任何一個問題，以前1個月都跑不了100個CASE通過ROBOT框架可以在2天的時間內完成3000個CASE,50萬結果檢查點的檢查，這點也印證了這篇文章的標題：開放性敏捷自動化測試架構

      下面的表格是傳統自動化體系與ROBOT架構的特性比較：

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 架構 自動化 開放性