軟件測試中的自動化測試的七個步驟

軟件測試中的自動化測試的七個步驟

【摘要】 我們對自動化測試充滿了希望，然而，自動化測試卻經常帶給我們沮喪和失望。雖然，自動化測試可以把我們從困難的環境中解放出來，在實施自動化測試解決問題的同時，又帶來同樣多的問題。在開展自動化測試的工作中，關鍵問題是遵循軟件開發的基本規則。本文介紹自動化測試的 7 個步驟：改進自動化測試過程，定義需求，驗證概念，支持產品的可測試性，具有可延續性的設計（ design for sustainability ），有計劃的部署和面對成功的挑戰。按照以上 7 個步驟，安排你的人員、工具和制定你的自動化測試項目計劃，你將會通往一條成功之路。

一個故事 :

我在很多軟件公司工作過，公司規模有大有小，也和來自其他公司的人員交流，因此經歷過或者聽說過影響自動化測試效果的各種各樣的的問題。本文將提供若干方法規避可能在自動化測試中出現的問題。我先給大家講一個故事，以便各位了解自動化測試會出現哪些問題。

以前，我們有一個軟件項目，開發小組內所有的人都認為應該在項目中采用自動化測試。軟件項目的經理是 Anita Delegate 。她評估了所有可能采用的自動化測試工具，最后選擇了一種，并且購買了幾份拷貝。她委派一位員工 ——Jerry Overworked 負責自動化測試工作。 Jerry 除了負責自動化測試工作，還有其他的很多任務。他嘗試使用剛剛購買的自動化測試工具。當把測試工具應用到軟件產品測試中的時候，遇到了問題。這個測試工具太復雜，難于配置。他不得不給測試工具的客戶支持熱線打了幾個電話。最后， Jerry 認識到，他需要測試工具的技術支持人員到現場幫助安裝測試工具，并找出其中的問題。在打過幾個電話后，測試工具廠商派過來一位技術專家。技術專家到達后，找出問題所在，測試工具可以正常工作了。這還算是順利了。但是，幾個月后，他們還是沒有真正實現測試自動化， Jerry 拒絕繼續從事這個項目的工作，他害怕自動化測試會一事無成，只是浪費時間而已。

項目經理 Anita 把項目重新指派給 Kevin Shorttimer ，一位剛剛被雇傭來做軟件測試的人員。 Kevin 剛剛獲得計算機科學的學位，希望通過這份工作邁向更有挑戰性的、值得去做的工作。 Anita 送 Kevin 參加工具培訓，避免 Kevin 步 Jerry 的后塵 —— 由于使用測試工具遇到困難而變得沮喪，導致放棄負責的項目。 Kevin 非常興奮。這個項目的測試需要重復測試，有點令人討厭，因此，他非常愿意采用自動化測試。一個主要的版本發布后， Kevin 準備開始全天的自動化測試，他非?？释玫揭粋€機會證明自己可以寫非常復雜的，有難度的代碼。他建立了一個測試庫，使用了一些技巧的方法，可以支持大部分的測試，這比原計劃多花費了很多時間，不過， Kevin 使整個測試工作開展的很順利。他用已有的測試套測試新的產品版本，并且確實發現了 bug 。接下來， Kevin 得到一個從事軟件開發職位的機會，離開了自動化的崗位。

Ahmed Hardluck 接手 Kevin 的工作，從事自動化測試執行工作。他發現 Kevin 留下的文檔不僅少，并且沒有太多的價值。 Ahmed 花費不少時間去弄清楚已有的測試設計和研究如何開展測試執行工作。這個過程中， Ahmed 經歷了很多失敗，并且不能確信測試執行的方法是否正確。測試執行中，執行失敗后的錯誤的提示信息也沒有太多的參考價值，他不得不更深的鉆研。一些測試執行看起來仿佛永遠沒有結束。另外一些測試執行需要一些特定的測試環境搭建要求，他更新測試環境搭建文檔，堅持不懈地工作。后來，在自動化測試執行中，它發現幾個執行失敗的結果，經過分析，是回歸測試的軟件版本中有 BUG ，導致測試執行失敗，發現產品的 BUG 后，每個人都很高興。接下來，他仔細分析測試套中的內容，希望通過優化測試套使測試變得更可靠，但是，這個工作一直沒有完成，預期的優化結果也沒有達到。按照計劃，產品的下一個發布版本有幾個主要的改動， Ahmed 立刻意識到產品的改動會破壞已有的自動化測試設計。接下來，在測試產品的新版本中，絕大多數測試用例執行失敗了， Ahmed 對執行失敗的測試研究了很長時間，然后，從其他人那里尋求幫助。經過商討，自動化測試應該根據產品的新接口做修改，自動化測試才能運轉起來。最后，大家根據新接口修改自動化測試，測試都通過了。產品發布到了市場上。接下來，用戶立刻打來投訴電話，投訴軟件無法工作。大家才發現自己改寫了一些自動化測試腳本，導致一些錯誤提示信息被忽略了。雖然，實際上測試執行是失敗的，但是，由于改寫腳本時的一個編程錯誤導致失敗的測試執行結果被忽略了。這個產品終于失敗了。

這是我的故事?；蛟S您曾經親身經歷了故事當中某些情節。不過，我希望你沒有這樣的相似結局。本文將給出一些建議，避免出現這樣的結局。

問題

這個故事闡明了幾個使自動化測試項目陷入困境的原因：

自動化測試時間不充足：根據項目計劃的安排，測試人員往往被安排利用自己的個人時間或者項目后期介入自動化測試。這使得自動化測試無法得到充分的時間，無法得到真正的關注。

缺乏清晰的目標：有很多好的理由去開展自動化測試工作，諸如自動化測試可以節省時間，使測試更加簡單，提高測試的覆蓋率，可以讓測試人員保持更好的測試主動性。但是，自動化測試不可能同時滿足上述的目標。不同的人員對自動化測試有不同的希望，這些希望應該提出來，否則很可能面對的是失望。

缺乏經驗：嘗試測試自己的程序的初級的程序員經常采用自動化自動化測試。由于缺乏經驗，很難保證自動化測試的順利開展。

更新換代頻繁（ High turnover ）：測試自動化往往需要花費很多時間學習的，當自動化測試更新換代頻繁的時候，你就喪失了剛剛學習到的自動化測試經驗。

對于絕望的反應：在測試還遠沒有開始的時候，問題就已經潛伏在軟件中了。軟件測試不過是發現了這些潛伏的問題而已。就測試本身而言，測試是一件很困難的工作。當在修改過的軟件上一遍接一遍的測試時，測試人員變得疲勞起來。測試什么時候后結束？當按照計劃的安排，軟件應該交付的時候，測試人員的絕望變得尤其強烈。如果不需要測試，那該有多好呀！在這種環境中，自動化測試可能是個可以選擇的解決方法。但是，自動化測試卻未必是最好的選擇，他不是一個現實的解決方法，更像是一個希望。

不愿思考軟件測試：很多人發現實現產品的自動化測試比測試本身更有趣。在很多軟件項目發生這樣的情況，自動化工程師不參與到軟件測試的具體活動中。由于測試的自動化與測試的人為割裂，導致很多自動化對軟件測試并沒有太大的幫助。

關注于技術：如何實現軟件的自動化測試是一個很吸引人的技術問題。不過，過多的關注如何實現自動化測試，導致忽略了自動化測試方案是否符合測試需要。

遵守軟件開發的規則

你可能了解 SEI （軟件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分為 5 個界別，該模型用來對軟件開發組織劃分等級。 Jerry Weinberg （美國著名軟件工程專家）也創建了自己的一套軟件組織模型，在他的組織模型中增加了一個額外的級別，他稱之為零級別。很顯然，一個零模式的組織實際上也是開發軟件；零模式組織中，在開發人員和用戶之間沒有差別 [Weinberg 1992] 。恰恰在這類組織環境中，經常采用自動化測試方法。因此，把資源用于自動化測試，并且把自動化測試當作一個軟件開發活動對待，把軟件測試自動化提升到一級。這是解決測試自動化的核心的方案。我們應該像運作其他的開發項目一樣來運作軟件自動化測試項目。

像其他軟件開發項目一樣，我們需要軟件開發人員專注于測試自動化的開發任務；像其他軟件開發項目一樣，自動化測試可以自動完成具體的測試任務，對于具體的測試任務來說，自動化開發人員可能不是這方面的專家，因此，軟件測試專家應該提供具體測試任務相關的咨詢，并且提供測試自動化的需求；像其他軟件開發項目一樣，如果在開發編碼之前，對測試自動化作了整體設計有助于測試自動化開發的順利開展。像其他軟件開發項目一樣，自動化測試代碼需要跟蹤和維護，因此，需要采用源代碼管理。像其他軟件開發項目一樣，測試自動化也會出現 BUG ，因此，需要有計劃的跟蹤 BUG ，并且對修改后的 BUG 進行測試。像其他軟件開發項目一樣，用戶需要知道如何使用軟件，因此，需要提供用戶使用手冊。

本文中不對軟件開發做過多講述。我假定您屬于某個軟件組織，該組織已經知道采用何種合理的、有效的方法開發軟件。我僅僅是推動您在自動化測試開發過程中遵守已經建立的軟件開發規則而已。本文按照在軟件開發項目中采用的標準步驟組織的，重點關注測試自動化相關的事宜和挑戰。

•  改進軟件測試過程

•  定義需求

•  驗證概念

•  支持產品的可測試性

•  可延續性的設計（ design for sustainability ）

•  有計劃的部署

•  面對成功的挑戰

步驟一：改進軟件測試過程

如果你負責提高一個商業交易操作的效率，首先，你應該確認已經很好的定義了這個操作的具體過程。然后，在你投入時間和金錢采用計算機提供一套自動化的商業交易操作系統之前，你想知道是否可以采用更簡單、成本更低的的方法。同樣的，上述過程也是用于自動化測試。我更愿意把 “ 測試自動化 ” 這個詞解釋成能夠使測試過程簡單并有效率，使測試過程更為快捷，沒有延誤。運行在計算機上的自動化測試腳本只是自動化測試的一個方面而已。

例如，很多測試小組都是在回歸測試環節開始采用測試自動化的方法?；貧w測試需要頻繁的執行，再執行，去檢查曾經執行過的有效的測試用例沒有因為軟件的變動而執行失敗?；貧w測試需要反復執行，并且單調乏味。怎樣才能做好回歸測試文檔化的工作呢？通常的做法是采用列有產品特性的列表，然后對照列表檢查。這是個很好的開始，回歸測試檢查列表可以告訴你應該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產品，并且知道需要采用哪種測試方法的人。

在你開始測試自動化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經采用了確定的的測試方法，指明測試中需要什么樣的數據，并給出設計數據的完整方法。如果測試掌握了基本的產品知識，這會更好。確認可以提供上面提到的文檔后，需要明確測試設計的細節描述，還應該描述測試的預期結果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們缺少什么，并且由于害怕尷尬而不敢去求助。這樣一份詳細的文檔給測試小組帶來立竿見影的效果，因為，現在任何一個具有基本產品知識的人根據文檔可以開展測試執行工作了。在開始更為完全意義上的測試自動化之前，必須已經完成了測試設計文檔。測試設計是測試自動化最主要的測試需求說明。不過，這時候千萬不要走極端去過分細致地說明測試執行的每一個步驟，只要確保那些有軟件基本操作常識的人員可以根據文檔完成測試執行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執行的想法，把這些測試設計的思路描述清楚就可以了。

我以前負責過一個軟件模塊的自動化測試工作。這個模塊的一些特性導致實現自動化非常困難。當我了解到這項工作無需在很短的時間內完成后，決定制定一個詳細回歸測試設計方案。我仔細地檢查了缺陷跟蹤庫中與該模塊相關的每個已經關閉的缺陷，針對每個缺陷，我寫了一個能夠發現該問題的測試執行操作。我計劃采用這種方法提供一個詳細的自動化需求列表，這可以告訴我模塊的那一部分最適合自動化測試。在完成上述工作后，我沒有機會完成測試自動化的實現工作。不過，當我們需要對這個模塊做完整回歸測試的時候，我將上面提到的文檔提供給若干只了解被測試產品但是沒有測試經驗的測試人員。依照文檔的指導，幾乎不需要任何指導的情況下，各自完成了回歸測試，并且發現了 BUG 。從某種角度看，這實際上是一次很成功的自動化測試。在這個項目中，我們與其開發自動化測試腳本，還不如把測試執行步驟文檔化。后來，在其它項目中，我們開發了自動化測試腳本，發現相關人員只有接受相關培訓才能理解并執行自動化測試腳本，如果測試自動化設計的很好，可能會好一些。不過，經過實踐我們總結出完成一份設計的比較好的測試文檔，比完成一份設計良好的測試腳本簡單的多。

另外一個提高測試效率的簡單方法是采用更多的計算機。很多測試人員動輒動用幾臺計算機，這一點顯而易見。我之所以強調采用更多的計算機是因為，我曾經看到一些測試人員被誤導在單機上努力的完成某些大容量的自動化測試執行工作，這種情況下由于錯誤的使用了測試設備、測試環境，導致測試沒有效果。因此，自動化測試需要集中考慮所需要的支撐設備。

針對改進軟件測試過程，我的最后一個建議是改進被測試的產品，使它更容易被測試，有很多改進措施既可以幫助用戶更好的使用產品，也可以幫助測試人員更好的測試產品。稍后，我將討論自動化測試的可測試需求。這里，我只是建議給出產品的改進點，這樣對手工測試大有幫助。

一些產品非常難安裝，測試人員在安裝和卸載軟件上花費大量的時間。這種情況下，與其實現產品安裝的自動化測試，還不如改進產品的安裝功能。采用這種解決辦法，最終的用戶會受益的。另外的一個處理方法是考慮開發一套自動安裝程序，該程序可以和產品一同發布。事實上，現在有很多專門制作安裝程序的商用工具。

另一些產品改進需要利用工具在測試執行的日志中查找錯誤。采用人工方法，在日志中一頁一頁的查詢報錯信息很容易會讓人感到乏味。那么，趕快采用自動化方法吧。如果你了解日志中記錄的錯誤信息格式，寫出一個錯誤掃描程序是很容易的事情。如果，你不能確定日志中的錯誤信息格式，就開始動手寫錯誤掃描程序，很可能面臨的是一場災難。不要忘記本文開篇講的那個故事中提到的測試套無法判斷測試用例是否執行失敗的例子。最終用戶也不愿意采用通過搜索日志的方法查找錯誤信息。修改錯誤信息的格式，使其適合日志掃描程序，便于掃描工具能夠準確的掃描到所有的錯誤信息。這樣，在測試中就可以使用掃描工具了。

通過改進產品的性能對測試也是大有幫助的。很顯然的，如果產品的性能影響了測試速度，鑒別出性能比較差的產品功能，并度量該產品功能的性能，把它作為影響測試進度的缺陷，提交缺陷報告。

上面所述的幾個方面可以在無需構建自動化測試系統的情況下，大幅度的提高測試效率。改進軟件測試過程會花費你構建自動化測試系統的時間，不過改進測試過程無疑可以使你的自動化測試項目更為順利開展起來。

步驟二：定義需求

在前面的故事中，自動化工程師和自動化測試的發起者的目標存在偏差。為了避免這種情況，需要在自動化測試需求上保持一致。應該有一份自動化測試需求，用來描述需要測試什么。測試需求應該在測試設計階段詳細描述出來，自動化測試需求描述了自動化測試的目標。很多人認為自動化測試顯然是一件好事情，但是，他們不愿意對自動化測試的目標給出清晰的描述。下面是人們選用自動化測試的幾個原因：

•  加快測試進度從而加快產品發布進度

•  更多的測試

•  通過減少手工測試降低測試成本

•  提高測試覆蓋率

•  保證一致性

•  提高測試的可靠性

•  測試工作可以由技術能力不強測試人員完成

•  定義測試過程，避免過分依賴個人

•  測試變得更加有趣

•  提高了編程技能

開發管理、測試管理和測試人員實現自動化測試的目標常常是有差別的。除非三者之間達成一致，否則很難定義什么是成功的自動化測試。

當然，不同的情況下，有的自動化測試目標比較容易達到，有的則比較難以達到。測試自動化往往對測試人員的技術水平要求很高，測試人員必須能理解充分的理解自動化測試，從而通過自動化測試不斷發現軟件的缺陷。不過，自動化測試不利于測試人員不斷的積累測試經驗。不管怎么樣，在開始自動化測試之前應該確定自動化測試成功的標準。

手工測試人員在測試執行過程中的一些操作能夠發現不引人注意的問題。他們計劃并獲取必要的測試資源，建立測試環境，執行測試用例。測試過程中，如果有什么異常的情況發生，手工測試人員立刻可以關注到。他們對比實際測試結果和預期測試結果，記錄測試結果，復位被測試的軟件系統，準備下一個軟件測試用例的環境。他們分析各種測試用例執行失敗的情況，研究測試過程可疑的現象，尋找測試用例執行失敗的過程，設計并執行其他的測試用例幫助定位軟件缺陷。接下來，他們寫作缺陷報告單，保證缺陷被修改，并且總結所有的缺陷報告單，以便其他人能夠了解測試的執行情況。

千萬不要強行在測試的每個部分都采用自動化方式。尋找能夠帶來最大回報的部分，部分的采用自動化測試是最好的方法?；蛟S你可能發現采用自動化執行和手動確認測試執行結果的方式是個很好的選擇，或許你可以采用自動化確認測試結果和手工測試執行相結合和方式。我聽到有人講，除非測試的各個環節都采用自動化方式，否則不是真正意義上的自動化測試，這真是胡言亂語。如果僅僅是為了尋找挑戰，可以嘗試在測試的每個環節都采用自動化方法。但是，如果尋找成功測試的方法，請關注那些可以快速建立的，可以反復利用的自動化測試。

定義自動化測試項目的需求要求我們全面地、清楚地考慮各種情況，然后給出權衡后的需求，并且可以使測試相關人員更加合理的提出自己對自動化測試的期望。通過定義自動化測試需求，距離成功的自動化測試近了一步。

步驟三：驗證概念

在前面的故事當中，那個自動化測試人員在對測試方向一片茫然的情況下一頭扎進了自動化測試項目中。不過，在項目的進行中，他得到了來自各個方面的支持。

你可能還沒有認識到這一點，不過，你必須驗證自動化測試項目的可行性。驗證過程花費的時間往往比人們預期的要長，并且需要來自你身邊的各種人的幫助。

很多年前，我從事一個測試自動化項目的工作，參加項目的人員有各種各樣的好點子。我們設計了一個復雜的自動化測試系統，并且非常努力工作去實現系統的每個模塊。我們定期的介紹測試自動化的設計思路和工作進度，甚至演示已經完成的部分功能。但是，我們沒有演示如何利用該套測試自動化系統如何開展實際的測試工作。最后，整個項目被取消了，此后，我再也沒有犯這個錯誤。

你需要盡可能快地驗證你采用的測試工具和測試方法的可行性，站在產品的角度驗證你所測試的產品采用自動化測試的可行性。這通常是很困難的，需要盡快地找出可行性問題的答案，需要確定你的測試工具和測試方法對于被測試的產品和測試人員是否合適。你需要做是驗證概念 —— 一個快速、有說服力的測試套可以證明你選在測試工具和測試方法的正確性，從而驗證了你的測試概念。你選擇的用來驗證概念的測試套是評估測試工具的最好的方式。

對于很多人來說，自動化測試意味著 GUI 自動化測試，我不同意這種觀點。我曾經做過 GUI 和非 GUI 自動化測試，并驚奇的發現這兩類測試的測試計劃有很大的互補性。不過， GUI 測試工具很昂貴、并且過分講究。選擇合適的 GUI 測試工具是很重要的，因為，如果沒有選擇合適的測試工具，你會遇到很多不可預測的困難。 Elisabeth Hendrickson 曾經寫過一篇關于選擇測試的工具的指導性文章 [Hendrickson 1999] 。我建議在評估測試工具中，找出能夠驗證你的想法的證據是很重要的環節。這需要測試工具至少有一個月試用期，你可能打算現在購買一份測試工具，然后直到評估完成后再購買更多份。你需要在付出大筆金錢購買測試工具的之前，找出工具存在的問題。這樣，你可以從測試工具供應商得到更好的幫助，當你打算更換工具的時候，你不會感覺很為難。

下面是一些候選的驗證概念的試驗：

回歸測試：你準備在每個版本運行同樣的測試用例嗎？回歸測試是最宜采用自動化測試的環節。

配置測試：你的軟件支持多少種不同的平臺？你打算在所有支持的平臺上測試執行所有的測試用例嗎？如果是的，那么采用自動化測試是有幫助的。

測試環境建立：對于大量不同的測試用例，可能需要相同的測試環境搭建過程。在開展自動化測試執行之前，先把測試環境搭建實現自動化。

非 GUI 測試：實現命令行和 API 的測試自動化比 GUI 自動化測試容易的多。

無論采用什么測試方法，定義一個看得見的目標，然后集中在這個目標上。驗證你自動化測試概念可以使自動化更進一步邁向成功之路。

步驟四：支持產品的可測試性

軟件產品一般會用到下面三種不同類別的接口：命令行接口（ command line interfaces ，縮寫 CLIs) 、應用程序接口（ API ）、圖形用戶接口（ GUI ）。有些產品會用到所有三類接口，有些產品只用到一類或者兩類接口，這些是測試中所需要的接口。從本質上看， API 接口和命令行接口比 GUI 接口容易實現自動化，去找一找你的被測產品是否包括 API 接口或者命令行接口。有些時候，這兩類接口隱藏在產品的內部，如果確實沒有，需要鼓勵開發人員在產品中提供命令行接口或者 API 接口，從而支持產品的可測試性。

下面，更多多的講解 GUI 自動化測試相關內容。這里有幾個原因導致 GUI 自動化測試比預期的要困難。第一個原因是需要手工完成部分腳本。絕大多數自動化測試工具都有 “ 錄制回放 ” 或者 “ 捕捉回放 ” 功能，這確實是個很好的方法?？梢允止绦袦y試用例，測試工具在后臺記住你的所有操作，然后產生可以用來重復執行的測試用例腳本。這是一個很好的方法，但是很多時候卻不能奏效。很多軟件測試文章的作者得出結論 “ 錄制回放 ” 雖然可以生成部分測試腳本，但是有很多問題導致 “ 錄制回放 ” 不能應用到整個測試執行過程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 結果， GUI 測試還是主要由手工完成。

第二個原因，把 GUI 自動化測試工和被測試的產品有機的結合在一起需要面臨技術上的挑戰。經常要在采用眾多專家意見和最新的 GUI 接口技術才能使 GUI 測試工具正常工作。這個主要的困難也是 GUI 自動化測試工具價格昂貴的主要原因之一。非標準的、定制的控件會增加測試的困難，解決方法總是有的，可以采用修改產品源代碼的方式，也可以從測試工具供應商處升級測試工具。另外，還需要分析測試工具中的 BUG ，并且給工具打補丁。也可能測試工具需要做相當的定制，以便能有效地測試產品界面上的定制控件。 GUI 測試中，困難總是意外出現，讓人驚奇。你也可能需要重新設計你的測試以規避那些存在問題的界面控件。

原文轉自：http://www.kjueaiud.com