第10章 軟件測試自動化

1、軟件測試自動化第十章第十章概概 況況 到目前為止我們已經(jīng)討論了多種測試類型和如何開發(fā)測試用例，但是這些測試用例的運行和檢查會花費我們大量的時間和精力。隨著測試的覆蓋率和質(zhì)量的提高，以及缺陷的不斷改正，測試用例的運行還需要額外的時間。要想解決這個問題就是自動運行大部分需要反復運行的測試用例。 通過開發(fā)軟件和使用工具來進行軟件測試叫做軟件測試自動化（Test Automation），也可以稱為軟件自動化測試（或自動測試）。本章我們將談論軟件測試自動化的幾個主要問題。 概概 況況本章內(nèi)容提要本章內(nèi)容提要 自動測試與手工測試的比較自動測試與手工測試的比較 如何開展自動測試如何開展自動測試 自動測試方案

2、的選擇自動測試方案的選擇10.1 手工測試與自動測試手工測試與自動測試l手工測試和自動測試相對，是指不手工測試和自動測試相對，是指不使用工具進行軟件測試。在很多公司使用工具進行軟件測試。在很多公司存在這兩種測試方法，也有不少小公存在這兩種測試方法，也有不少小公司只有手工測試。手工測試和自動測司只有手工測試。手工測試和自動測試孰好孰壞，是否自動測試就比手工試孰好孰壞，是否自動測試就比手工測試優(yōu)越？在回答這些問題之前，首測試優(yōu)越？在回答這些問題之前，首先要對手工測試和自動測試有個清晰先要對手工測試和自動測試有個清晰的認識，知道它們各自的優(yōu)點和缺點。的認識，知道它們各自的優(yōu)點和缺點。10.1.2 自

3、動測試是否比手工測試優(yōu)越自動測試是否比手工測試優(yōu)越 在大多數(shù)軟件開發(fā)模式中，軟件發(fā)布之前都要多次重復編碼在大多數(shù)軟件開發(fā)模式中，軟件發(fā)布之前都要多次重復編碼測試測試修復的過程。如果要測試軟件的某項特征，也許需要不止一修復的過程。如果要測試軟件的某項特征，也許需要不止一次執(zhí)行測試。重復測試的過程也稱為回歸測試。如果一個小型軟件次執(zhí)行測試。重復測試的過程也稱為回歸測試。如果一個小型軟件項目有上千測試用例要執(zhí)行，還要重復執(zhí)行，手工測試會非常單調(diào)項目有上千測試用例要執(zhí)行，還要重復執(zhí)行，手工測試會非常單調(diào)和枯燥。而利用工具進行自動測試就可以把人從這種枯燥單調(diào)的重和枯燥。而利用工具進行自動測試就可以把人從

4、這種枯燥單調(diào)的重復性勞動中解放出來。復性勞動中解放出來。提高了測試執(zhí)行速度，節(jié)省了時間。因此自動測試和手工測試比較起來有以下幾個優(yōu)點提高了測試效率。手工測試存在效率問題，這在軟件產(chǎn)品的研發(fā)后期尤其明顯，因為隨著產(chǎn)品的日趨完善，功能日漸增多，需要測試和檢查的內(nèi)容越來越多，很容易遺漏。加之產(chǎn)品發(fā)布日期日益臨近，人工重復進行回歸測試的難度加大，很難在短時間內(nèi)完成大面積的測試覆蓋。提高了準確度和精確度。測試員嘗試了幾百個測試用例以后，注意力可能會分散，并開始犯錯誤。而測試工具可以重復執(zhí)行同樣的測試，并毫無差錯地檢查測試結果。更好地利用資源。手工測試需要測試人員在場，而自動測試可以一天24小時、一周7天

5、地隨時執(zhí)行。還可使位于全球不同地方、不同時區(qū)的團隊監(jiān)視和控制測試，提供全球時區(qū)的覆蓋。模擬測試條件。有的測試用例的測試條件需要的人數(shù)或設備數(shù)目很大，現(xiàn)實無法實現(xiàn)，測試工具可以模擬真實的情況。 如上所述，既然自動測試有如此多的優(yōu)點，那么它是否比手工測試優(yōu)越，可以完全代勞手工測試的所有工作呢？答案是否定的，自動測試沒有想象中那么優(yōu)越。 手工測試有其不可替代的地方，因為人是具有很強智能判斷能力的動物，而工具是相對機械、缺乏思維能力的東西。手工測試不可替代的地方至少包括以下幾點。測試用例的設計：測試人員的經(jīng)驗和對錯誤的猜測能力是工具不可替代的。界面和用戶體驗測試：人類的審美觀和心理體驗是工具不可模擬的

6、。正確性的檢查：人們對是非的判斷和邏輯推理能力是工具不具備的。 因此，自動測試適宜用在需要重復執(zhí)行機械化的界面操作、計算、數(shù)值比較、搜索等方面。我們應該充分利用自動測試工具的高效率來幫助測試人員完成一些基本的測試用例的執(zhí)行，從而實現(xiàn)更加快速的回歸測試，并且提高測試的覆蓋率。10.2 自動測試的開展 在進行自動測試之前，先要考慮以下5個方面，這5個方面是成功開展自動化測試需要考慮的因素，也可用于衡量目前的項目是否有足夠的條件進行自動測試。（1）測試自動化類似于軟件開發(fā)過程）測試自動化類似于軟件開發(fā)過程錄制錄制/回放的腳本開發(fā)方式是不可能應付所有自動測試的需求的，因此，回放的腳本開發(fā)方式是不可能應

7、付所有自動測試的需求的，因此，需要測試人員掌握必要的開發(fā)知識和編碼技巧。需要測試人員掌握必要的開發(fā)知識和編碼技巧。（2）測試自動化是一個長期的過程）測試自動化是一個長期的過程首先，不能期望自動測試在短期內(nèi)找到很多缺陷，自動測試只有在長期首先，不能期望自動測試在短期內(nèi)找到很多缺陷，自動測試只有在長期的運行后才能體現(xiàn)出它的價值。其次，不要認為只要購買了工具，錄制的運行后才能體現(xiàn)出它的價值。其次，不要認為只要購買了工具，錄制一些腳本，然后，就可以安枕無憂地看著自動測試實現(xiàn)想要的效果。需一些腳本，然后，就可以安枕無憂地看著自動測試實現(xiàn)想要的效果。需要考慮自動測試腳本的維護成本。隨著測試應用程序功能的增

8、加和修改，要考慮自動測試腳本的維護成本。隨著測試應用程序功能的增加和修改，測試腳本的維護工作量會急劇增加。測試腳本的維護工作量會急劇增加。（3）確保測試自動化的資源，包括人員和技能）確保測試自動化的資源，包括人員和技能最好有專門的自動測試工程師來保證測試自動化持續(xù)、順利地進行下去，最好有專門的自動測試工程師來保證測試自動化持續(xù)、順利地進行下去，自動測試工程師需要對項目的測試自動化負責，設計測試框架和解決各自動測試工程師需要對項目的測試自動化負責，設計測試框架和解決各種測試腳本結構，解決測試腳本的開發(fā)問題，確保自動測試得以計劃、種測試腳本結構，解決測試腳本的開發(fā)問題，確保自動測試得以計劃、設計和

9、有序地開發(fā)、維護。設計和有序地開發(fā)、維護。（4）循序漸進地開展自動測試）循序漸進地開展自動測試不要一開始就把自動測試設想得很大，這往往是不可實現(xiàn)的。應該從小不要一開始就把自動測試設想得很大，這往往是不可實現(xiàn)的。應該從小開始，先熟悉工具和自動測試的基本技能，然后，整合資源，開始實現(xiàn)開始，先熟悉工具和自動測試的基本技能，然后，整合資源，開始實現(xiàn)一些基本的自動測試用例，例如，冒煙測試類型的自動測試腳本。先實一些基本的自動測試用例，例如，冒煙測試類型的自動測試腳本。先實現(xiàn)那些容易實現(xiàn)且相對穩(wěn)定的功能模塊的自動測試，然后再考慮逐步擴現(xiàn)那些容易實現(xiàn)且相對穩(wěn)定的功能模塊的自動測試，然后再考慮逐步擴展和補充其

10、他相對難實現(xiàn)，或者是比較不穩(wěn)定的功能模塊。展和補充其他相對難實現(xiàn)，或者是比較不穩(wěn)定的功能模塊。（5）確保測試過程的成熟度）確保測試過程的成熟度如果軟件企業(yè)的測試過程和項目管理過程的能力成熟度比較低，則實現(xiàn)如果軟件企業(yè)的測試過程和項目管理過程的能力成熟度比較低，則實現(xiàn)自動測試的成功率也比較低。在展開自動測試之前，先考察一下軟件企自動測試的成功率也比較低。在展開自動測試之前，先考察一下軟件企業(yè)各方面的管理能力，例如，測試是否獨立進行？有無配置管理？進度業(yè)各方面的管理能力，例如，測試是否獨立進行？有無配置管理？進度控制能力如何？如果各方面的能力成熟度都比較差的話，則不要盲目引控制能力如何？如果各方面

11、的能力成熟度都比較差的話，則不要盲目引入測試自動化。入測試自動化。10.2.1 自動測試的周期 自動測試什么時候啟動、什么時候結束并沒有硬性規(guī)則。自動測試工作可以與產(chǎn)品開發(fā)同時進行，并且可以與產(chǎn)品的多個發(fā)布版本重疊。與多產(chǎn)品發(fā)布一樣，自動測試也有多個發(fā)布版本。對自動測試的一個整體需求就是，自動測試的交付應該在測試執(zhí)行階段之前，以便自動測試可交付產(chǎn)品能夠在測試被測產(chǎn)品的當前發(fā)布版本時使用。自動測試的需求跨多個發(fā)布版本的多個階段，這與產(chǎn)品需求一樣。測試執(zhí)行可以在發(fā)布產(chǎn)品后不久結束，但是自動測試工作卻在產(chǎn)品發(fā)布后仍然持續(xù)。 由于產(chǎn)品開發(fā)和自動測試開發(fā)具有以上的相似性，因此，自動測試遵循的過程和生存周

12、期模型與產(chǎn)品開發(fā)的也非常類似。在絕大多數(shù)情況下，自動測試也遵循產(chǎn)品的軟件開發(fā)生存周期（SDLC）模型。本節(jié)集中介紹V字模型及其擴展，以介紹測試自動測試的過程。首先研究產(chǎn)品開發(fā)所包含的階段和自動測試階段如圖10-1所示，并理解兩者之間的相似性。樁模塊樁模塊3產(chǎn)品需求產(chǎn)品策劃產(chǎn)品設計產(chǎn)品編輯自動測試需求自動測試策劃自動測試設計自動測試編碼圖10-1 產(chǎn)品開發(fā)與自動測試間的相似性 本章已經(jīng)介紹過，自動測試生存周期活動與產(chǎn)品開發(fā)活動有很強的相似性。就像產(chǎn)品需要采集產(chǎn)品需求一樣，自動測試也需要采集自動測試需求。類似地，就像產(chǎn)品策劃、設計和編碼一樣，在測試自動測試過程中也有自動測試策劃、設計和編碼。 在測

13、試產(chǎn)品時檢驗測試包很重要。測試包是被自動化的一組測試用例和與這些用例相關聯(lián)的場景（Scenario）。如果測試包中有缺陷，就要花很大的精力搞清楚缺陷是來自產(chǎn)品還是來自測試包。自動測試包在用于測試產(chǎn)品之前，首先要進行測試。如果測試包報告了錯誤的缺陷，就會嚴重影響測試自動測試的信譽，影響下一步的自動測試工作。因此，自動測試包必須具有值得信任的質(zhì)量。為了創(chuàng)建具有值得信任的質(zhì)量的測試包，與產(chǎn)品開發(fā)一樣，一些測試階段也是很重要的。圖10-2擴展了圖10-1，引入了產(chǎn)品和自動測試包的測試階段。樁模塊樁模塊3產(chǎn)品需求產(chǎn)品策劃產(chǎn)品設計自動測試需求自動測試策劃自動測試編碼圖10-2 W字模型自動測試周期包含的階

14、段測試設計測試包的測試設計自動測試設計測試策劃測試需求測試包測試需求測試包測試計劃產(chǎn)品編碼產(chǎn)品測試就緒測試包就緒測試包的測試產(chǎn)品測試執(zhí)行 產(chǎn)品和自動測試開發(fā)的每個階段可以執(zhí)行一組活動，具體包括四項。產(chǎn)品在需求階段采集開發(fā)需求時，同時完成針對測試產(chǎn)品的測試需求、針對自動測試開發(fā)的需求和針對自動測試的需求。類似地，在策劃和設計階段也可以執(zhí)行一組活動，具體也包括四項。針對產(chǎn)品和自動測試的編碼構成這種W字模型的編碼階段，這個階段要交付產(chǎn)品和測試包。產(chǎn)品和自動測試就像鐵路的兩條鋼軌，沿同一方向并行鋪開，并具有類似的預期。 測試包構成自動測試的一種可交付產(chǎn)品。此外，測試框架也可看作自動測試的一種可交付產(chǎn)品

15、，上一段討論的測試階段只針對測試包，因為測試包需要徹底測試，以便用于產(chǎn)品測試。 在產(chǎn)品和自動測試中引入測試活動后，生命周期模型圖中就包含了并行的兩組開發(fā)活動和并行的兩組測試活動。把這些活動合在一起就構成W字模型。因此，對于包含自動測試的產(chǎn)品開發(fā)，遵循W字模型，既保證產(chǎn)品的質(zhì)量，又保證所開發(fā)的測試包達到預期的質(zhì)量要求，是一種很好的選擇。 在討論W字模型時，不能將其解釋為出現(xiàn)在特定階段內(nèi)的所有活動都應該同時開始和結束。例如，圖10-2中的“設計”、“測試設計”、“自動測試設計”和“針對測試包的測試設計都出現(xiàn)在同一個階段(在圖中并排給出)。針對產(chǎn)品和自動測試的這些活動可以在不同時間開始和結束。W字模

16、型只是保證活動的流程，并沒有限定起止時間。產(chǎn)品開發(fā)和自動測試可以有獨立的進度計劃，并作為兩個不同的項目進行處理。 不需要同時開始和結束的另一個理由是，在很多公司中，要由同一個測試團隊測試產(chǎn)品和開發(fā)測試包。在這種情況下，顯然進度是不同的，活動的起止時間取決于由可用的資源和其他依賴關系決定的項目進度。 對于公司內(nèi)有專門的自動測試團隊的情況，自動測試進度可以獨立于產(chǎn)品的發(fā)布。每次產(chǎn)品發(fā)布對應一些(經(jīng)過測試的)可交付產(chǎn)品。這樣，可以使用最新開發(fā)的測試包測試產(chǎn)品的當前發(fā)布版本。10.2.2 自動測試的成本自動測試的成本 成功開展自動化測試必須考慮自動測試的成本問題。成本包括測試人員、測試設備、測試工具等

17、。（1）應該能抽出專職的測試人員進行自動測試腳本的開發(fā)，并且抽調(diào)的測試人員不會對已有的手工測試人員造成影響，需要保證自動測試的開展不會影響到手工測試的正常進行。（2）自動測試可能需要額外的測試設備，例如，測試執(zhí)行的機器、文件服務器、數(shù)據(jù)庫等。應該能為自動測試準備專門的測試設備。（3）有引入測試工具或開發(fā)測試工具的成本預算。缺乏工具的自動測試是不可能實現(xiàn)的。在上馬一個項目的自動測試之前應該進行測試工具的引入準備、開展測試工具的培訓工作開展等。（4）某些項目選用了很多第三方控件或自定義的控件，而這些控件的可測試性非常差，那么對這個項目進行自動測試的成本會非常高，不適宜進行自動測試。10.2.3 合

18、理選擇自動測試的導入時機合理選擇自動測試的導入時機 自動測試只有在多次運行后，才能體現(xiàn)出自動化的優(yōu)勢，只有不斷地運行自動測試，才能有效預防缺陷，減輕測試人員手工的回歸測試的工作量。如果一個項目是短期的，并且是一次性的項目，則不適合開展自動測試，因為這種項目得不到自動測試的應有效果和價值體現(xiàn)。 另外，不宜在一個進度非常緊迫的項且中開展自動測試。有些項目經(jīng)理期待在一個進度嚴重拖延的項目中引入自動測試來解決測試的效率問題，結果適得其反。這是因為，自動測試需要測試人員投入測試腳本的開發(fā)，同時，需要開發(fā)人員的配合，提供更好的可測試的程序，還有可能需要對被測試的軟件進行改造，以適應自動測試的基本要求。如果

19、在一個已經(jīng)處于進度拖延狀態(tài)的項目中開展自動測試，則很可能帶來反效果。 過早的自動化會帶來維護成本的增加，因為早期的程序界面一般不夠穩(wěn)定，處于頻繁更改的狀態(tài)，這時候進行自動測試往往得不償失，疲于應付“動蕩”的界面。 那么，什么時候開始自動測試項目呢？自動測試不應該在界面尚未穩(wěn)定的時候開始，而是需要適當?shù)挠媱澓蜏蕚涔ぷ鳌Ｔ诮缑骐r形時期，可以基于界面原型提供的控件來嘗試自動測試工具的適用性，因為有些控件是自動測試工具不能識別和測試的。這時候，就要考慮工具的選擇問題。 在開發(fā)人員著手開發(fā)一些核心的代碼時，可能會同時開發(fā)出一些核心可重用的控件，而且是那種自定義的個性化控件，那么就需要在這個階段取到這些控

20、件，并且嘗試使用自動化工具來測試這些控件。如果發(fā)現(xiàn)有不適用的地方，則要考慮讓開發(fā)人員重新設計控件，或者提供更多的測試接口。10.2.4 自動測試的人員要求自動測試的人員要求 另外，自動測試工程師與手工測試的工程師一樣，需要具備設計測試用例的基本方法和能力，具備軟件涉及的基本業(yè)務的理解能力。而且，應該有把測試用例轉換成自動測試用例的能力。了解各種編程語言、編程工具以及各種標準控件、第三方控件，則會對自動測試腳本的編寫大有裨益。 自動測試工程師應該具備一定的自動測試基礎，包括自動測試工具的基礎、自動測試腳本的開發(fā)基礎知識等；還需要了解各種測試腳本的編寫和設計方法，知道在什么時候選取怎樣的測試腳本開

21、發(fā)方式，知道如何維護測試腳本；需要具備一定的編程技巧，熟悉某些測試腳本語言的基本語法和使用方法。10.3 自動測試的方案選擇自動測試的方案選擇 在選擇自動測試方案之前我們先要確定自動在選擇自動測試方案之前我們先要確定自動化的對象和范圍，然后決定采用什么樣的自動測化的對象和范圍，然后決定采用什么樣的自動測試方案，采用什么樣的指導測試腳本開發(fā)方法。試方案，采用什么樣的指導測試腳本開發(fā)方法。 10.3.1 確定自動化的對象和范圍確定自動化的對象和范圍 在產(chǎn)品開發(fā)過程中，需求的變更是很常見的。對于這種情在產(chǎn)品開發(fā)過程中，需求的變更是很常見的。對于這種情況，要自動化的對象是很容易確定的。自動化應該考慮需

22、求不變況，要自動化的對象是很容易確定的。自動化應該考慮需求不變或沒有變更的部分。需求變更一般會影響場景和新特性，不會影或沒有變更的部分。需求變更一般會影響場景和新特性，不會影響產(chǎn)品的基本功能。在自動化時，要首先考慮產(chǎn)品的這類基本功響產(chǎn)品的基本功能。在自動化時，要首先考慮產(chǎn)品的這類基本功能，以便用做能，以便用做“回歸測試回歸測試”和和“冒煙測試冒煙測試”的基礎的基礎 。 有些類型的測試本身自動進行自動化。例如：壓力、可靠性、可伸縮性和性能測試這些類型的測試要求在大量不同的計算機上以一定的持續(xù)時間運行測試用例，比如48小時等。讓數(shù)百個用戶天天使用產(chǎn)品簡直就是不可能的，他們既不愿意承擔重復性工作，也

23、不可能找到那么多有所需技能的人群。屬于這些類型測試的測試用例是自動化的第一候選者。 回歸測試是重復性的。這些測試用例在產(chǎn)品開發(fā)各個階段要執(zhí)行多次。由于這些測試用例具有重復性，因此自動化從長遠看會顯著節(jié)省時間和工作量。此外，正如本章已經(jīng)提到過的，所節(jié)省的時間可以有效地用于即興測試和其他更具創(chuàng)造性的測試。 功能測試這類測試可能需要復雜的設置，因此可能需要當前還沒有普遍具備的特殊技能。利用專家的技能一次性自動化這些測試用例，使技能不那么高的員工也可以馬上運行這些測試用例。 在產(chǎn)品開發(fā)場景中，很多測試需要重復，如果考慮了定期增強和維護發(fā)布版本，好的產(chǎn)品會有很長的生命期。這就提供了自動化測試用例在發(fā)布周

24、期內(nèi)多次執(zhí)行的機會。根據(jù)一般經(jīng)驗，如果測試用例在不久的將來，比方說一年內(nèi)需要執(zhí)行至少10次，如果自動化工作量不超過執(zhí)行這些測試用例的10倍，那么就可以考慮自動化這些測試用例。當然，這只是根據(jù)經(jīng)驗，具體選擇哪些測試用例還有很多因素需要考慮，例如是否具備所需的技能、在強大的發(fā)布日期壓力下是否有設計自動化測試腳本的時間、工具的成本、是否有所需的支持等。 作為自動化范圍的總結，就是要選擇自動化那些能夠以最少的時間延遲換得最大投回人報的工作。 在開始自動化前，需要花很大的精力取得管理層的承諾。自動化一般要耗費大量工作量，也并非一次性活動。自動化的測試用例還需要維護，直到產(chǎn)品退出市場。由于開發(fā)和維護自動化

25、工具需要大量的工作量，因此取得管理層的承諾是一項很重要的活動。由于自動化在很長時間內(nèi)都需要投入，因此管理層的批準是按階段按部分進行的。所以，自動化工作應該集中于已經(jīng)存在管理層承諾的區(qū)域。 投入回報也是需要認真考慮的一個方面。自動化工作量估計要向管理層提供預期投入回報的明確結論。在啟動自動化時，關注點應該放在好的排列組合區(qū)域上。這使自動化能夠用較少的代碼覆蓋較多的測試用例。另外，自動化應該首先考慮需要較短時間，易于自動化的測試用例。有些測試用例沒有能夠預先確定的預期結果，這類測試用例需要很長時間自動化，應該放在自動化的后期階段。這可以滿足管理層尋求自動化快速投入回報的要求。 為了符合“重要事情優(yōu)

26、先做”的原則，重要的是要首先自動化產(chǎn)品的關鍵和基本功能。為此，所有測試用例都要根據(jù)客戶預期分為高、中、低優(yōu)先級，自動化要從高優(yōu)先級的測試用例入手，然后覆蓋中、低優(yōu)先級需求的測試用例。10.3.2 選擇自動測試的方案和腳本編寫方法選擇自動測試的方案和腳本編寫方法 采用什么樣的自動化測試方采用什么樣的自動化測試方案，需要考慮以下幾個方面案，需要考慮以下幾個方面的因素：的因素：項目的影響：自動化測試能否對項目進度、項目的影響：自動化測試能否對項目進度、覆蓋率、風險有積極的作用，或者讓開發(fā)更覆蓋率、風險有積極的作用，或者讓開發(fā)更敏捷？敏捷？復雜度：自動化是否容易實現(xiàn)（包括數(shù)據(jù)復雜度：自動化是否容易實現(xiàn)

27、（包括數(shù)據(jù)和其他環(huán)境的影響）？和其他環(huán)境的影響）？時間：自動化測試的實現(xiàn)需要多少時間？時間：自動化測試的實現(xiàn)需要多少時間？早期需求和代碼的穩(wěn)定性：需求或早期的早期需求和代碼的穩(wěn)定性：需求或早期的代碼是否能證明是在一定范圍內(nèi)變化的？代碼是否能證明是在一定范圍內(nèi)變化的？維護工作量：代碼是否能長期保持相對穩(wěn)維護工作量：代碼是否能長期保持相對穩(wěn)定？功能特性是否會進化？定？功能特性是否會進化？覆蓋率：自動化測試能否覆蓋程序的關鍵覆蓋率：自動化測試能否覆蓋程序的關鍵特性和功能？特性和功能？資源：測試組是否擁有足夠的人力資源、資源：測試組是否擁有足夠的人力資源、硬件資源和數(shù)據(jù)資源來運行自動測試？硬件資源和數(shù)

28、據(jù)資源來運行自動測試？自動測試執(zhí)行：負責執(zhí)行自動測試的小組自動測試執(zhí)行：負責執(zhí)行自動測試的小組是否擁有足夠的技能和時間去運行自動測試？是否擁有足夠的技能和時間去運行自動測試？自動測試項目也像普通的軟件開發(fā)項目樣有編碼階段。自動測試的編碼階段主要是通過編寫測試腳本實現(xiàn)所設計的自動測試用例。自動功能測試的腳本開發(fā)主要有以下幾種方法:（1）錄制與回放使用簡單的錄制回放的方法，測試工程師使用這種方法來自動地測試系統(tǒng)的流程或某些系統(tǒng)測試用例。它可能包含某些多余的，有時候并不需要的函數(shù)腳本，但錄制與回放可避免重復執(zhí)行測試用例。市場上幾乎所有的測試工具都具有錄制與回放特性。測試工程師錄制鍵盤字符或鼠標點擊的

29、行動序列，并在以后按照錄制的順序回放這些所錄制的腳本。由于所錄制的腳本可以回放很多次，所以可以減少測試工作。除了可以避免重復工作，錄制和保存腳本也很簡單。但是這一代工具也有一些缺點。腳本中可能包含一些硬編碼的取值，因此很難執(zhí)行一般類型的測試。例如，如果報告必須使用當前的日期和時間，那么就很難使用已錄制的腳本。錯誤條件的處理留給測試人員，這樣回放腳本就可能需要很多人工介入來檢測和更正錯誤條件。當應用程序變更后，所有腳本都必須重新錄制，因此增加了測試維護的成本。所以，如果頻繁出現(xiàn)變更，或沒有多少機會重用或重新運行測試用例，那么這一代測試自動化工具的有效性就可能很低。6.8 6.8 單元測試的過程單

30、元測試的過程（2）結構化結構化腳本編寫方法在腳本中使用結構控制。結構控制讓測試人員可以控制測試腳本，或測試用例的流程。在腳本中，典型的結構控制是使用“if-else”，“switch”，“for”，“while”等條件狀態(tài)語句來幫助實現(xiàn)判定，實現(xiàn)某些循環(huán)任務，調(diào)用其他覆蓋普遍功能的函數(shù)。下面是結構化腳本編寫方法的特點:測試用例在腳本中定義。編程的成本要比錄制回放編寫方法略高一點。需要測試員的調(diào)整編碼技巧。需要某種程度上的計劃、設計。測試數(shù)據(jù)也是在腳本中被硬編碼。因為相對穩(wěn)定一點，所以需要相對少的腳本維護，維護成本比錄制回放腳本編寫方法的要相對低。除了編程知識外，還需要一些腳本語言的知識。（3）

31、數(shù)據(jù)驅動數(shù)據(jù)驅動腳本編寫方法把數(shù)據(jù)從腳本分離出去，存儲在外部的文件中。這樣，腳本就只是包含編程代碼了。這在測試運行時要改變數(shù)據(jù)的情況下是需要的。這樣，腳本在測試數(shù)據(jù)改變時也不需要修改代碼。有時候，測試的期待結果值也可以跟測試輸入數(shù)據(jù)一起存儲在數(shù)據(jù)文件中。下面是數(shù)據(jù)驅動腳本編寫方法的特點:腳本是以結構化的方式編程的。測試用例由測試數(shù)據(jù)或腳本定義。由于腳本參數(shù)化和編程成本，這種方法的開發(fā)成本跟結構化腳本編寫方法比較要相對高。需要測試員較高的代碼調(diào)整方面的編程技巧。需要更多的計劃和設計。數(shù)據(jù)獨立存儲在數(shù)據(jù)表或外部文件。腳本維護成本較低。推薦在需要測試正反數(shù)據(jù)的時候使用。（4）關鍵字驅動關鍵字驅動腳本編寫方法把檢查點和執(zhí)行操作的控制都維護在外部數(shù)據(jù)文件。