2.6 管理自動化測試
我們的測試過程在持續改進，并且我們為測試設計了一個可記錄的生命周期，如圖2-2所示。
測試被開發出來之后，會進行評審，如果審查通過，這個測試就會被包含到候選隊列中（一個測試集合用來嘗試是否應該包含到整個自動化套件中）。如果一個候選測試在一行中有4天都失敗了，那么它會被提取出來重新進行開發。在測試本身沒有任何失效一周之后，這個測試會設置為“有效”狀態，并可以包含到每晚的或者每周的測試套件中。
圖2-2 測試的生命周期
如果產品的功能改變了但是其測試沒有更新，測試可以“掛起”。根據掛起的原因，測試將來可能會成為“有效”狀態或者候選測試狀態（故障的原因被修復之后）。
不同測試套件的內容會進行周期性分析。度量指標用來衡量運行這些特定測試的收益。根據這一過程的結果，一個測試可以從一個測試套件移到另一個測試套件（依據測試的運行頻率），或者在某些情況下轉移到“退出”狀態。如果某一個測試可能不會再用到了，團隊就會考慮刪除它。
我們制定了很多度量標準，都使管理層非常滿意，而且非常關注我們，并提高了團隊的優先級。毫無疑問，相比于之前，他們對產品審批過程的信任有了大幅提升。
2.7 測試套件和類型
最后，我們用這個工具批準開發人員代碼檢入：在允許提交新的或者修改后的代碼之前，他們必須在三個不同平臺上運行一個最小的驗收測試套件（Minimum Acceptance Test Suite, MATS）來測試其代碼。通過實驗，我們選擇這些平臺來發現特定的或者罕見的故障。這一步驟有利于在變更被引入源代碼之前，減少回歸測試和失效的數量。這些測試的運行時間被控制在最短時間內，所以這些測試是有用的，在時間上并沒有成為影響進一步開發的障礙。
【真知灼見】
提供及時的反饋，并且將日常開支減少到最小，為開發人員提供最好的支持。
該工具用作夜間的回歸測試，這樣開發人員白天一上班就能獲得關于他們代碼變更的反饋信息。這個測試套件包括大部分運行時間稍短的回歸測試，并運行在有限選擇的平臺上：一般是在3 ~ 5個平臺，并且運行時間為將近12小時。
我們通常還在3個不同的平臺上進行每周測試，每一個測試套件運行4 ~ 5天。
這些回歸測試具有很高的優先級，并獲得了管理層的大力支持。這里出現的故障必須盡快修復。
除了這些回歸測試外，其他測試是在候選批次中運行的。這些測試，是對新版本中新功能或者已變更功能的典型測試，具有更低的優先級，因為它們往往是由負責的開發人員和測試開發人員進行監控的。候選批次也包括夜間和每周運行的批次。項目團隊可以根據需要定義更適合自己團隊需求的測試套件。
這些測試在我們的內部測試工具上運行，性能測試與它們并行運行，并且與基準線進行對比。由于它們對測試和結果的特殊需求，它們都有自己的框架。這些測試通常僅在一個平臺上運行?！“l布測試一般包含以上描述的所有類型的測試，但是在至多22個不同的平臺上運行。如圖2-3所示。
此外，發布測試還包括在測試工具上運行的其他非功能性測試，比如：
長時間測試：不同的場景下運行時間至少為10天的測試。
擴展性測試：通過增加硬件來減輕負荷的測試，一般采用24臺服務器和12臺客戶機來運行測試。
圖2-3 發布測試的內容
2.8 現狀
該工具已經用于不同的數據庫產品的測試當中，而且現在是一個開源工具，請參閱http: //kenai.com/projects/jet。
2.9 在經過一段很艱難的時光后才得到的經驗教訓
在過去的三四年里，我們遇到了無數的困難：
軟件測試變得非常成熟，有時反而會使我們忽略一些最簡單的測試。比如，我們往往測試了復雜的SQL查詢語句，卻忽略了對在用戶組之外創建新用戶這類簡單操作的測試。事實上，這種語句是不允許出現的，因為可能會由于在用戶組的權限設置中沒有考慮到這種情況而導致重大的錯誤。
我們過于關注大規模的自動化測試中的變化，導致有些非功能性測試有時并未得到足夠的重視。比如，用戶可能會獲得只有專業人員才能看懂的錯誤提示消息，軟件產品中經常缺少幫助功能，這些都是軟件設計和測試中存在的問題。
使用隨機生成的輸入數據來進行測試時，有時雖然發現了嚴重的缺陷，但是因為測試人員能力有限，不能再重新生成導致故障的數據，所以并不能對調試過程產生任何幫助。經常討論上述這種測試，一般是從經濟的角度：它們通常需要額外的資源來輔助進行分析，并且在大多數情況下，并不能通過它們找到產生bug的原因，因此，也不可能通過它們找到產生軟件缺陷的根本原因。
對自動化投入的評估主要看ROI的效果。如果不在比較的過程中引入其他因素，很有可能得出錯誤的故障報告。比如，我們要仔細地對結果進行比較，考慮到地域因素，有時要先進行轉換再進行比較等。例如，當你在比較一臺位于挪威境內的PC上的日期和一臺位于美國境內的PC上的日期的時候，不同的時間格式（挪威為“日/月”而美國境內為“月/日”）導致時間顯示的結果也會不同。
有時候通過軟件來模擬物理故障并不是很容易，并且要模擬這些故障在多臺電腦上幾乎同時發生也是很困難的。此外，通過軟件來模擬的斷電和斷網情形與實際發生的斷電和斷網也可能并不一樣。
有時候可能會發生結果誤報問題，因為測試時，即便遇到一個或多個失效也可能報告正確的結果。對于那些長期使用都未出現過故障的測試用例，往往更容易忽略對其正確性的檢查。但隨著時間的流逝，這些測試可能會不斷積累許多錯誤，因此在報告中要不定期地對其正確性進行檢查。 如果一些優先級比較低的次要bug沒有立即修復，那么它們可能會掩蓋一些主要bug，而這些主要bug由于引入的時間太長，往往更難對其進行分析。
必須要插入和修改等待時間來保證在測試繼續運行之前，前面的強制性過程已經完成了。用更新的硬件取代現有硬件通常意味著要對這一過程再一次進行同步。
【真知灼見】
預測可能會發生改變的事物，并使它們在必要的時候更容易改變（例如，保存同步時間的核心列表）。
在測試套件的某些部分中，期望結果模板用來與實際結果進行比較。由于這類模板需要大量的維護工作，因此我們試圖將這些基于模板的測試改為基于斷言的測試。
引入新的平臺有時會產生一些問題，并需要大量的資源來解決這些問題。同時，對操作系統的監控力度也要加大。
對于基于Windows的測試，要關閉自動更新，并將更新放在等待隊列中，在測試可以中斷的那個時段之前，再運行這些更新。
我們要清楚正在運行測試的網絡中所發生的一切。比如，每隔一個月午夜時候出現一些無法解釋的故障，最后發現，故障是由前雇員的一臺電腦上的夜間執行工作所導致的：這臺電腦沒有關閉，而是仍然非常活躍地向本地網絡發送查詢請求的垃圾郵件。
【小竅門】
回頭看有些錯誤是非常顯而易見的，但你如果沒有想到，它們可能就會困擾你。
建議定期做探索性測試，你將會對所發現的問題感到非常驚奇，同時，有時候你還可以將這些經驗用于新的自動化測試中。
2.10 如何使用自動化測試書中的建議
在開發自動化測試過程中，我們運用了《Software Test Automation》一書中許多有用的知識點：
在進行自動化測試工具開發之前，首先對工具進行需求分析并列出需求清單，我們對需求清單中的每一個需求進行討論和評審，結果表明這是整個開發取得成功的堅實基礎。在評審過程中，參與人員中有代表不同需求的關鍵人物：經理、IT運營商、發布工程師、測試經理、開發人員和測試人員。
測試自動化只是從以下幾個方面來對測試進行自動化：測試的準備、執行、核對、清空、存檔、生成報告和度量。而測試執行之前的過程，例如，測試用例的設計等，是沒有進行自動化的。
我們得到了管理層的大力支持來實施這項自動化工作，并且他們有著切實的期望。
【真知灼見】
管理層的支持是至關重要的，但是他們的期望必須要符合實際。
如果沒有來自不同領域的杰出專家，我們就不可能取得成功。整個實現過程和解決方案都很復雜并具有挑戰性。
幸運的是，在大部分產品中都沒有要求進行GUI測試，這使整個自動化過程不會顯得很冗長。
數據庫中的GUI測試屬于可用性測試，識別這種測試類型使我們取得了很多重大的改進，并使可用性測試延期。到今天為止，可用性測試還沒有完成，但是因為考慮到這點我們受益匪淺！
測試工具的大部分開發是集中在GUI部分的開發。然而，在后面，GUI幾乎不會用到，因為所有的自動化都是通過命令行界面進行的。我們前期之所以會集中精力進行GUI的開發，可能是因為我們大腦中還存在進行手動測試的定勢思維?！ 拘「[門】
工具中良好的用戶界面可能在自動化項目的前期最有用。
經過本次自動化項目的實踐，測試人員也學會了別的技術并在他們感興趣的領域變得更加專業。有些測試人員更精通測試開發，有些則在測試的執行和生成報告方面更精通。
只有心中牢記不斷取得進步這一目標，才能讓我們大步前進。通過小組討論來分析現有問題以及如何對其進行自動化，最終就會找到解決方案。
讓所有的測試人員參加國際軟件測試認證委員會（International Software Testiing Qualifications Board， ISTQB）的基礎認證課程，這樣有助于術語的統一使用和理解，從而有助于增進測試人員間的交流。
有時候項目中人員數量突然減少從某種程度上也可以促進自動化過程——使用更少人力資源的需求變得更為突出。
能詳細地向整個項目中的其他成員介紹每一步是怎么實施的，很有用，因為相比于將它們整合到產品之后再進行測試，顯然單個部分的測試更容易執行。
【真知灼見】
在走向成功時，步子要快，但也要穩。
通過自動化進行的測試是整個項目的核心過程，無論什么時候出現了故障，它們都會盡力地報告給整個部門的每個人。這可能會對開發產生負面影響，因為看到這些失效之后，開發人員在修改代碼時會格外小心，雖然這種格外留心有助于提高產品質量，但他們可能要為此花費過多的精力和時間。對于軟件產品來說，對于“怎樣的質量才算足夠好”是沒有明確定義的，這可能會導致在開發中投入過多的精力。這僅僅只是我個人毫無根據的假設，并沒有事實能證明這一觀點，但是開發人員太關注質量這在軟件行業里是不尋常的！
2.11 總結
剛開始的時候數據庫產品和測試的質量都很差，但是在自動化測試開始之前都得到了顯著提高。
接著開始了自動化測試工具的開發過程。首先，成立一個包含信息傳遞人員、專家和利益相關者的團隊，進行需求定義。然后，用最專業的人員完成了開發，自動化測試也逐步實施，在這一過程中，每個參與人員都起到了非常重要的作用：工具開發人員、促變者、管理層、工具管理人員以及整個實施團隊。
早期我們達到了開發這個工具的第一目標，然后隨著時間的推移，完成了越來越多的目標。我們的效率至少提高了2400倍，并為公司開發了一款非常好的工具。在實施小的修復或者增強功能的時候，需要的維護工作量非常少，這也為我們的成功幫了不少忙。我們的硬件資源都達到了最合理的使用：大部分機器除了短暫的休息以外，都是24小時/天，7天/周地工作。
對我們來說，這就是最終的自動化測試。
2.12 致謝
首先，要感謝Yngve Svendsen和 J?rgen Austvik在我寫這篇案例研究時提供了非常有用的建議和反饋信息。此外，還要感謝所有為這個項目的成功而努力的人們，尤其是William Franklin，感謝他對我們自動化測試的大力支持和鼓勵。同時，也要感謝本書的兩位作者，感謝他們給了我公布這個案例研究故事的機會。
?。ㄎ赐甏m...）
相關鏈接：
自動化測試最佳實踐 連載一
自動化測試最佳實踐 連載二
自動化測試最佳實踐 連載三
自動化測試最佳實踐 連載四
自動化測試最佳實踐 連載五