一個故事 :
我在很多軟件公司工作過，公司規模有大有小，也和來自其他公司的人員交流，因此經歷過或者聽說過影響自動化測試效果的各種各樣的的問題。本文將提供若干方法規避可能在自動化測試中出現的問題。我先給大家講一個故事，以便各位了解自動化測試會出現哪些問題。
以前，我們有一個軟件項目，開發小組內所有的人都認為應該在項目中采用自動化測試。軟件項目的經理是 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測試需要反復執行，并且單調乏味。怎樣才能做好回歸測試文檔化的工作呢?通常的做法是采用列有產品特性的列表，然后對照列表檢查。這是個很好的開始，回歸測試檢查列表可以告訴你應該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產品，并且知道需要采用哪種測試方法的人。
在你開始測試自動化之前，你需要完善上面提到的回歸測試檢查表，并且，確保你已經采用了確定的的測試方法，指明測試中需要什么樣的數據，并給出設計數據的完整方法。如果測試掌握了基本的產品知識，這會更好。確認可以提供上面提到的文檔后，需要明確測試設計的細節描述，還應該描述測試的預期結果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們缺少什么，并且由于害怕尷尬而不敢去求助。這樣一份詳細的文檔給測試小組帶來立竿見影的效果，因為，現在任何一個具有基本產品知識的人根據文檔可以開展測試執行工作了。在開始更為完全意義上的測試自動化之前，必須已經完成了測試設計文檔。測試設計是測試自動化最主要的測試需求說明。不過，這時候千萬不要走極端去過分細致地說明測試執行的每一個步驟，只要確保那些有軟件基本操作常識的人員可以根據文檔完成測試執行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟件測試執行的想法，把這些測試設計的思路描述清楚就可以了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
