自動化測試的7個步驟(2)

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

問題

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

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

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

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

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

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

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

遵守軟件開發的規則

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

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

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

1、改進軟件測試過程

2、定義需求

3、驗證概念

4、支持產品的可測試性

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

原文轉自：http://www.uml.org.cn/Test/201312093.asp