軟件測試自動化的糾結

 人們在談到軟件測試自動化時，首先會想到測試工具，包括功能測試工具、性能測試工具等。而測試工具能執行各種不同的、具體的測試，就依賴于測試腳本。測試人員通過開發測試腳本（test script），來實現測試用例所要進行的具體操作和驗證。一旦選定測試工具，則測試腳本的開發就成為測試人員的日常工作之一，也是測試自動化的最主要的工作。也就是說，測試腳本的開發和維護直接關系到軟件測試自動化的成敗，至少對自動化測試的投入產出存在巨大的影響。

      測試腳本從最初的錄制腳本發展到結構化腳本、數據驅動 （data-driven）腳本，再發展到關鍵字驅動（keyword-driven）腳本。從歷史發展過程來看，數據驅動腳本和關鍵字驅動腳本對提高自動化測試腳本開發效率有顯著的幫助，而且也有利于腳本的維護。下面這個表，可以充分說明不同類型的測試腳本對自動化收益的影響是很大的。

下面是一個簡單的關鍵字驅動腳本示例：

       從中看出，這樣的業務邏輯很清楚，操作起來簡單。而且，伴隨著關鍵字驅動腳本的誕生，也相繼出現了各種自動化測試框架，形成良好的腳本開發環境或平臺，使得自動化測試腳本的開發更具開放性、可視性和層次性，測試人員開發和維護腳本都變得更輕松、容易，從而在整體上進一步提高自動化測試的效率和應用范圍。

       當然，任何事情都不會十全十美，會存在另外一個問題。一旦自動化測試框架及其工具完成之后，測試人員的腳本開發工作簡單，缺乏技術含量，可能缺少編程的鍛煉機會，從而在自動化測試的實施過程中帶來一個新的糾結問題——是使用關鍵字驅動腳本開發模式還是使用原生態的腳本語言（如Python、VBScript，甚至C++/C#、Java等）開發模式？這里主要指Frontend功能測試的自動化，涉及UI。如果是backend 或API 的自動化測試，相對容易。

       如果采用關鍵字驅動腳本的開發模式，個人能力得不到提高。而且感覺，一旦離開公司原有的腳本開發經驗幾乎沒有價值。而如果采用原生態的腳本語言，個人編程能力得到實實在在的鍛煉，這些能力是業界普遍需要的，所以個人的價值得到提高。從這個職業發展角度看，測試人員更樂于采用原生態的腳本語言，而不愿采用關鍵字驅動腳本，特別是對那些看作個人發展的員工，會有一個權衡的考慮。

       站在公司角度看，應更多考慮自動化測試的投入產出，毫無疑問選擇關鍵字驅動腳本，保證自動化測試效率。如果選用原生態的腳本語言，那么自動化測試的開發工作量會增加，要求測試人員和開發人員達到1：1的配備，將來自動化測試的腳本維護也會是一個很大的問題。如果選擇像C++/C#這樣高級語言來寫自動化測試腳本，腳本變得復雜，會帶來腳本本身測試/驗證的問題，形成了一個無窮的“遞歸循環”。

       從管理角度看，可以采取行政命令，統一行動，全面采用優秀的自動化測試框架和關鍵字驅動腳本，確保有高產出投入比（ROI）。同時，過于強制實施某套方案，可能會不利于員工的工作積極性或主動性，也會對生產力產生負面影響。

        站在公司角度，也要關懷員工，幫助員工的職業發展，如何創建更多的機會給員工來提高自己的能力。所以，全面推行關鍵字腳本的軟件開發呢，還是允許部分團隊采取那種相對原始的腳本開發模式呢？ 這是一對矛盾，需要平衡和疏導。有些獨立的項目、周期短的項目、局部的項目可以放開，由團隊自己來決定，而對最核心的全局產品開發、周期長的項目統一到同一個支持關鍵字驅動腳本的自動化框架上來。