第2章 軟件自動化測試

軟件自動化測試是軟件測試的發展方向，但是，如果盲目追求自動化測試，則有可能導致軟件測試的失敗。本章介紹如何開展軟件自動化測試項目，以及軟件自動化測試的管理方法。

2.1 手工測試與自動化測試

手工測試和自動化測試是很多測試人員爭相討論的兩種測試方法。有人對自動化測試趨之若鶩，也有人對自動化測試嗤之以鼻。在做出如何看待自動化測試的決定之前，首先要對自動化測試有一個清晰的概念。

2.1.1 手工測試的缺點

軟件測試的一個顯著特點是重復性，重復讓人產生厭倦的心理，重復使工作量倍增，因此，人們想到用工具來解決重復的問題。

另外，手工測試還存在精確性的問題，尤其是面對大量的數據需要檢查時，人工的比較和搜索不僅存在效率問題，而且容易出錯，覆蓋面偏低。

手工測試存在效率問題，這在軟件產品的研發后期階段尤其明顯，因為隨著產品的日趨完善，功能日漸增多，需要測試和檢查的內容越來越多，很容易遺漏。加之產品發布日期日益臨近，人工重復進行回歸測試的難度加大，很難在短時間內完成大面積的測試覆蓋。

2.1.2 什么時候使用自動化測試

手工測試有其不可替代的地方，因為人是具有很強智能判斷能力的動物，而工具是相對機械、缺乏思維能力的東西。手工測試不可替代的地方至少包括以下幾點：

? 測試用例的設計：測試人員的經驗和對錯誤的猜測能力是工具不可替代的。

? 界面和用戶體驗測試：人類的審美觀和心理體驗是工具不可模擬的。

? 正確性的檢查：人們對是非的判斷、邏輯推理能力是工具不具備的。

但是，自動化測試有很強的優勢，它的優勢是借助了計算機的計算能力，可以重復地、不知疲倦地運行，對于數據，能進行精確的、大批量的比較，而且不會出錯。

因此，自動化測試適宜用在需要重復執行機械化的界面操作、計算、數值比較、搜索等方面。我們應該充分利用自動化測試工具的高效率來幫助測試人員完成一些基本的測試用例的執行，從而實現更加快速的回歸測試，并且提高測試的覆蓋率。

2.1.3 自動化測試——你準備好了嗎

在進行項目的自動化測試之前，先要考慮以下5個方面，這5個方面是成功開展自動化測試需要考慮的方面，也可用于衡量目前的項目是否有足夠的條件進行自動化測試：

（1）測試自動化類似于軟件開發過程

錄制/回放的腳本開發方式是不可能應付所有自動化測試的需求的，因此，需要測試人員掌握必要的開發知識和編碼技巧。

（2）測試自動化是一個長期的過程

首先，不能期望自動化測試在短期內找到很多Bug，自動化測試只有在長期的多次運行后才能體現出它的價值。其次，不要認為只要購買了工具，錄制一些腳本，然后，就可以安枕無憂地看著自動化測試實現想要的效果，需要考慮自動化測試腳本的維護成本，隨著被測試應用程序功能的增加和修改，測試腳本的維護工作量會急劇地增加。

（3）確保測試自動化的資源，包括人員和技能

最好有專門的自動化測試工程師來保證測試自動化持續、順利地進行下去，自動化測試工程師需要對項目的測試自動化負責，設計測試框架和腳本結構，解決各種測試腳本的開發問題，確保自動化測試得以計劃、設計和有序地開發、維護。

（4）循序漸進地開展自動化測試

不要一開始就把自動化測試設想得很大，這往往是不可實現的，應該從小開始，先熟悉工具和自動化測試的基本技能，然后，整合資源開始實現一些基本的自動化測試用例，例如，冒煙測試類型的自動化測試腳本。先實現那些容易實現、且相對穩定的功能模塊的自動化測試，然后再考慮逐步擴展和補充其他相對難實現，或者是比較不穩定的功能模塊。

（5）確保測試過程的成熟度

如果軟件企業的測試過程和項目管理過程的能力成熟度比較低，則實現自動化測試的成功率也比較低。在開展自動化測試之前，先考察一下軟件企業各方面的管理能力，例如，測試是否獨立進行？有無配置管理？進度控制能力如何？如果各方面的能力成熟度都比較差的話，則不要盲目引入測試自動化。

2.2 如何開展自動化測試

自動化測試應該被當成一個項目來開展，自動化測試工程師應該具備額外的素質和技能，并且在開展自動化測試的過程中，要注意合理地管理和計劃，從而確保自動化測試成功實施。

2.2.1 選取合適的測試項目來開展自動化測試

自動化測試只有在多次運行后，才能體現出自動化的優勢，只有不斷地運行自動測試，才能有效預防缺陷、減輕測試人員手工的回歸測試的工作量。如果一個項目是短期的，并且是一次性的項目，則不適合開展自動化測試，因為這種項目得不到自動化測試的應有效果和價值體現。

另外，不宜在一個進度非常緊迫的項目中開展自動化測試。有些項目經理期待在一個進度嚴重拖延的項目中引入自動化測試來解決測試的效率問題，結果適得其反。這是因為，自動化測試需要測試人員投入測試腳本的開發，同時，需要開發人員的配合，提供更好的可測試的程序，有可能需要對被測試的軟件進行改造，以適應自動化測試的基本要求，如果在一個已經處于進度Delay狀態的項目中開展自動化測試，則很可能帶來反效果。

2.2.2 自動化測試介入的時機

過早的自動化會帶來維護成本的增加，因為早期的程序界面一般不夠穩定，處于頻繁更改的狀態，這時候進行自動化測試往往得不償失，疲于應付“動蕩”的界面。

那么，什么時候開始自動化測試項目呢？自動化測試不應該在界面尚未穩定的時候開始，但是，并不意味著不需要計劃和準備工作。在界面雛形時期，可以基于界面原型提供的控件來嘗試自動化測試工具的適用性，因為有些控件是自動化測試工具不能識別和測試的。這時候，就要考慮工具的選擇問題。

在開發人員著手開發一些核心的代碼時，可能會同時開發出一些核心可重用的控件，而且是那種自定義的個性化控件，那么就需要在這個階段取到這些控件，并且嘗試使用自動化工具來測試這些控件，如果發現有不適用的地方，則要考慮讓開發人員重新設計控件，或者提供更多的測試接口。

2.2.3 自動化測試工程師的基本素質和技能要求

自動化測試工程師應該具備一定的自動化測試基礎，包括自動化測試工具的基礎、自動化測試腳本的開發基礎知識等；還需要了解各種測試腳本的編寫和設計方法，知道在什么時候選取怎樣的測試腳本開發方式，知道如何維護測試腳本；需要具備一定的編程技巧，熟悉某些測試腳本語言的基本語法和使用方法。

另外，自動化測試工程師與手工測試的工程師一樣，需要具備設計測試用例的基本方法和能力，具備軟件涉及的基本業務的理解能力。而且，應該有把測試用例轉換成自動化測試用例的能力。

2.2.4 自動化測試的成本

成功開展自動化測試必須考慮自動化測試的成本問題。成本包括測試人員、測試設備、測試工具等。

（1）應該能抽出專職的測試人員進行自動化測試腳本的開發，并且抽調的測試人員不會對已有的手工測試人員造成影響，需要保證自動化測試的開展不會影響到手工測試的正常進行。

（2）自動化測試可能需要額外的測試設備，例如，測試執行的機器、文件服務器、數據庫等。應該能為自動化測試準備專門的測試設備。

（3）有引入測試工具或開發測試工具的成本預算。缺乏工具的自動化測試是不可能實現的。在上馬一個項目的自動化測試之前應該進行測試工具的引入準備、測試工具的培訓工作的開展等。

（4）某些項目選用了很多第三方控件或自定義的控件，而這些控件的可測試性非常差，那么對這個項目進行自動化測試的成本會非常高，不適宜進行自動化測試。

2.3 自動化測試方案

自動化測試是一項需要計劃和設計的活動，在開始測試腳本的開發之前，應該考慮清楚采用怎樣的自動化測試方案，采用怎樣的自動化測試腳本開發方法。

2.3.1 選擇自動化測試方案

采用什么樣的自動化測試方案，需要考慮以下幾個方面的因素：

（1）項目的影響：自動化測試能否對項目進度、覆蓋率、風險有積極的作用，或者讓開發更敏捷？

（2）復雜度：自動化是否容易實現，包括數據和其他環境的影響。

（3）時間：自動化測試的實現需要多少時間？

（4）早期需求和代碼的穩定性：需求或早期的代碼是否能證明是在一定范圍內變化的？

（5）維護工作量：代碼是否能長期保持相對穩定？功能特性是否會進化？

（6）覆蓋率：自動化測試能否覆蓋程序的關鍵特性和功能？

（7）資源：測試組是否擁有足夠的人力資源、硬件資源和數據資源來運行自動化測試。

（8）自動化測試的執行：負責執行自動化測試的小組是否擁有足夠的技能和時間去運行自動化測試？

以上方面的各因素對于選擇什么樣的自動化測試方案，達到怎樣的目標，投入多少測試資源，自動化測試項目的進度安排，自動化測試用例的設計等都會造成一定的影響。

2.3.2 自動化測試腳本的編寫方法

自動化測試項目也像普通的軟件開發項目一樣，有編碼階段，自動化測試的編碼階段主要是通過編寫測試腳本實現所設計的自動化測試用例。自動化功能測試腳本的開發方式主要有以下幾種：

? 線性的

? 結構化的

? 共享的

? 數據驅動的

? 關鍵字驅動的

2.3.3 線性腳本的編寫方法

線性腳本編寫方法是使用簡單的錄制回放的方法，測試工程師使用這種方法來自動化地測試系統的流程或某些系統測試用例。它可能包含某些多余的、有時候并不需要的函數腳本。線性腳本編寫方法的特點是：

? 一種非結構化的編程方式

? 測試用例由腳本定義

? 非常低的開發成本

? 測試人員所需要的編程方面的技巧幾乎可以忽略

? 不需要計劃、設計

? 測試數據在腳本中是硬編碼的

? 腳本會很脆弱，因此維護成本會很高

? 沒有公用的腳本，因此可能造成重復勞動

2.3.4 結構化腳本的編寫方法

結構化腳本編寫方法在腳本中使用結構控制。結構控制讓測試人員可以控制測試腳本，或測試用例的流程。在腳本中，典型的結構控制是使用“if-else”，“switch”，“for”，“while”等條件狀態語句來幫助實現判定、實現某些循環任務、調用其他覆蓋普遍功能的函數。結構化腳本編寫方法的特點是：

? 結構化的腳本編寫方法

? 測試用例在腳本中定義

? 編程的成本要比線性腳本編寫方法略為高一點

? 需要測試員的調整編碼技巧

? 需要某種程度上的計劃、設計

? 測試數據也是在腳本中被硬編碼

? 因為相對穩定一點，所以需要相對少的腳本維護，維護成本比線性腳本編寫方法的要相對低

? 除了編程知識外，還需要一些腳本語言的知識

2.3.5 共享腳本的編寫方法

共享腳本編寫方法是把代表應用程序行為的腳本在其他腳本之間共享。這意味著把被測應用程序的公共的、普遍的功能的測試腳本獨立出來，其他腳本對其進行調用。這使得某些腳本按照普遍功能劃分來標準化、組件化。這種腳本甚至也可以使用在被測系統之外的其他軟件應用系統。共享腳本編寫方法的特點是：

? 腳本是結構化的

? 測試用例在腳本中定義

? 開發成本相對于結構化腳本編寫方法來說，要降低一些，因為減少了很多復制的勞動

? 需要測試員的調整代碼的編程技巧

? 由于腳本需要模塊化，所以需要更多的計劃和設計

? 測試數據也是硬編碼的

? 腳本維護和維護成本要比線性腳本編寫方法的相對低

2.3.6 數據驅動腳本的編寫方法

數據驅動腳本編寫方法把數據從腳本分離出去，存儲在外部的文件中。這樣，腳本就只是包含編程代碼了。這在測試運行時要改變數據的情況下是需要的。這樣，腳本在測試數據改變時也不需要修改代碼。有時候，測試的期待結果值也可以跟測試輸入數據一起存儲在數據文件中。數據驅動腳本編寫方法的特點是：

? 腳本是以結構化的方式編程的

? 測試用例由測試數據或腳本定義

? 由于腳本參數化和編程成本，這種方法的開發成本跟共享腳本編寫方法比較要相對高

? 需要測試員較高的代碼調整方面的編程技巧

? 需要更多的計劃和設計

? 數據獨立存儲在數據表或外部文件

? 腳本維護成本較低

? 推薦在需要測試正反數據的時候使用

2.3.7 關鍵字驅動腳本的編寫方法

關鍵字驅動腳本編寫方法把檢查點和執行操作的控制都維護在外部數據文件。因此，測試數據和測試的操作序列控制都是在外部文件中設計好的，除了常規的腳本外，還需要額外的庫來翻譯數據。關鍵字驅動腳本編寫方法是數據驅動測試方法的擴展，其特點是：

? 綜合了數據驅動腳本編寫方法、共享腳本編寫方法、結構化腳本編寫方法

? 測試用例由數據定義

? 開發成本高，因為需要更多的測試計劃和設計、開發方面的投入

? 要求測試人員有很強的編程能力

? 最初的計劃和設計、管理成本會比較高

? 數據在外部文件存儲

? 維護成本比較低

? 需要額外的框架或庫，因此，測試員需要更多的編程技巧

2.3.8 合理選擇自動化測試腳本開發方法

總結起來看，對于開發的成本來說，隨著腳本編寫方法從線性到關鍵字驅動的改變而不斷地增加；對于維護的成本來說，隨著腳本編寫方法從線性到關鍵字驅動的改變而在降低。對于編程技能要求來說，隨著腳本編寫方法從線性到關鍵字驅動的改變，對一個測試員的編程熟練程度的要求在增加。對于設計和管理的需要來說，隨著腳本編寫方法從線性到關鍵字驅動的改變，設計和管理自動化測試項目的要求在增加。

因此，應該合理地選擇自動化測試腳本開發方法，在適當的時候、適當的地方使用適當的腳本開發方法。

2.4 實用性自動化測試策略

自動化測試永遠是測試人員心中的痛。一方面，測試人員在長期的手工測試中已經不勝其煩，夢想著使用測試工具輕松地實現自動化測試；另一方面，一旦嘗試了自動化測試，又會發現有太多的阻礙，這些阻礙來自工具、管理和人。

2.4.1 自動化測試工具的問題

首先碰到的問題是測試工具的問題，現在很多商業上的工具都存在這樣或那樣的問題。大部分會有這些缺點：

廠商腳本語言

大部分商業測試工具會指定某種語言，例如：WinRunner（TSL），SilkTest （4test），Robot（Test Basic），但是，一些新的工具也開始使用標準語言，例如：QTP（VB Script），XDE Tester（Java）。

所以，在選擇測試工具時要考慮這點。最好選擇支持標準語言的測試工具，而且，盡量與所在項目組的開發人員所使用并熟悉的語言一致。這樣可以充分利用現有的編程知識和語言知識，而不需要花時間去熟悉廠商特定的語言（這些語言只能在這個工具能用上）。并且可以借助開發人員豐富的開發知識來協助進行測試腳本的設計和編寫。

對新平臺、個性化控件的支持不夠好

大部分商業測試工具沒能很好地支持新的平臺和很多的第三方控件、個性化控件。例如，新的.NET版本、操作系統，以及普遍使用的第三方控件，如Component One、Infragistics、Janus等。

如果項目中使用這些較新的平臺或大量使用這些第三方控件的話，就要小心選擇測試工具了，否則會導致后面的腳本編寫難度加大。建議在選用之前，充分評估并在項目的應用程序上試用。

與源代碼控制的結合不好

很多工具沒有與源代碼控制工具集成，使用臨時文件和目錄（WinRunner），有些則把信息存儲在外部的庫中，例如Rational。

源代碼控制對于測試腳本的管理非常重要，除非希望每個測試員使用自己的一套腳本，或者通過原始的拷貝方式來進行共享和管理。

在選用工具時，還會碰到選擇商業工具還是開源工具的問題。在這里，同樣需要考慮項目的上下文，還有成本問題。目前，開源社區的測試工具大部分是單元測試工具，成熟的自動化測試工具還不多，如果選用這些工具的話，需要考慮維護和修改調整工具的成本。

2.4.2 自動化測試的管理規范

當興沖沖地拿到測試工具準備大展拳腳時，先停一停，考慮一下自動化測試如何開展。首先，對測試人員的培訓是必不可少的，培訓需要包括工具的內部培訓、腳本語言的培訓、自動化測試規范的培訓。

選用開源的測試工具一般不會有培訓課程，即使是購買的測試工具也未必會附帶培訓課程。所以對于工具的內部培訓，一般可由前期負責工具選型和試用的人員進行內部培訓。熟悉工具附帶的幫助文檔和Sample文件會對工具的學習，還有腳本語言的學習有很大的幫助。

培訓還包括制定出自動化測試規范，并對參與測試的人員進行培訓。規范可以從以下幾方面進行制定：

（1）測試用例的選擇

并不是所有測試用例都能用自動化的方式執行，自動化測試適合在機械化的執行和比較中使用，讓一個自動化測試對用戶界面規范性進行檢查，那是“不可能完成的任務”。另外，還要注意測試用例自動化實現的順序，優先實現簡單的、主體的，例如，按以下順序來實現測試用例自動化：

遍歷所有界面的冒煙測試→測試用例中的主成功場景→擴展場景、擴展流程→……

（2）腳本命名規范、注釋規范

為了讓測試腳本的維護性、可讀性更強，應該制定出命名規范和注釋規范。例如，要求在每個腳本函數前面注明測試目的，簡要的測試過程描述等；對腳本中的主要步驟、復雜代碼進行注釋。

（3）對公用測試數據的維護

如果測試涉及的數據在不同測試人員編寫的很多腳本都要使用到，則應該制定出相應的數據維護規范，例如，要求測試腳本對數據的操作要考慮數據的備份和恢復等問題。

另外，還要考慮自動化腳本編寫方法，不同的腳本編寫方法對腳本的可維護性、開發成本的影響程度不一樣，對測試員的編程技能要求程度也不一樣。

2.4.3 自動化測試中人的因素

在進行自動化測試時，除了要做好準備，制定好規范和策略外，還少不了對人的管理，項目整體管理流程的配合。

（1）測試人員有時候會不知不覺地陷在測試腳本的編寫中，沒有很好地評估測試的時間要求，沒有選擇合適的測試腳本編寫方法。這其實也是阻礙自動化測試成功進行的因素之一。

例如，對一些測試工具支持不是很好的控件，有時候會出現無法識別的問題，這時候不要花太多的時間去研究為什么不能識別，或嘗試其他很多識別的辦法，而是先用最簡單的方法解決，即使方法看起來比較老土，例如，很多無法識別的控件都可以通過鍵盤操作、TAB鍵定位等方式解決。

（2）造成自動化測試艱難進行的問題，很可能是軟件的可測試性問題，也就是說，軟件提供的可測試性接口不夠強大，或者是在設計時沒有很好地考慮可測試性問題，而這些都是開發人員可以為自動化測試提供的，可以讓開發人員提供對軟件的編程接口、Hook、更換一個等同效果但是測試工具可以識別的控件等。

（3）配置管理。項目的配置管理沒有做好也可能會影響到自動化測試。有些開發人員喜歡時不時調整一下自己的代碼，重構一下設計，如果這些方面沒有控制好的話，可能造成自動化測試的腳本大面積作廢和修改，雖然在開發方面看來這些重構和調整是那么的輕而易舉和微小。例如，對控件的命名的更改就可能導致大部分操作這些控件的測試腳本的修改。

因此，軟件的配置管理工作，對被測試系統的源代碼控制有時候可能成為自動化測試成功的關鍵。應該確保被測系統的更改得到評審和通知，評審要把對自動化測試的影響納入考慮范圍。