第2章 終極數據庫自動化
Henri van de Scheur
Henri van de Scheur講述了一個跨越6年的故事，是有關他和他的同事在開發一款適用于多個環境的測試數據庫工具時所發生的事情。他們為自己的自動化測試設定了良好的目標，并為測試工具搭建了一個良好的架構。他們使很多測試實現了自動化，從而為自動化測試構建了一個完整的生命周期，包括周期性的bug清理。測試是每晚、每周運行的，或者根據特殊的時間表來安排執行。雖然取得了巨大的成功，但他們也遭遇過一系列的問題，Henri都如實地進行了描述。這個數據庫測試工具（現在是開源的）是由一支小團隊短短幾年內在挪威開發的，并且取得了非?？捎^的投資回報率（ROI），如表2-1所示。
表2-1 案例研究特征
2.1 本案例研究的背景
這個案例研究描述了我（指Henri）在一個快速成長的新公司里的經歷：剛開始的時候，大約有50個員工，但僅僅過了五六個月，員工數量就增加到超過100人。由于人員數量增加太迅速，導致后來加入的很多開發人員和測試人員缺乏對產品的基本了解。知識的交流被極大地忽視了。結果，產品和測試的質量都很差。
辦公室里有大約50 ~ 60個開發人員及20個專用測試人員，分別分布在同一辦公大樓的各個樓層。測試人員報告產品中存在的問題，但由于測試質量差以及缺乏對產品的充分了解，以致這些問題往往被忽視。通過改善開發人員和測試人員兩個群體間的交流，開發和測試工作都從中受益并且質量都得到了提高。所以，良好的交流是開始考慮自動化測試的先決條件。
【真知灼見】
不要嘗試對設計很差的測試實施自動化，先完善測試，再進行自動化。
一個包含大約30 ~ 40個測試的典型的發布測試只在一個平臺上運行，這就可能需要15 ~ 20個測試人員花費3 ~ 4周的時間。同時，由于發布測試中有更多的bug修復周期和測試周期（一般是4 ~ 6個周期），因此，在可以發布一個產品的新版本之前，過去需要大量的時間。由此可見，將以上過程實現自動化的需求是非常顯著的：周期必須縮短，人力資源必須減少，并且測試人員必須在多個平臺上運行測試。
一開始，我們使用Java語言開發了一個能夠滿足以上需求的內部工具，隨后再將更多的新功能逐漸添加進去。到目前為止，這個工具的一個更新的版本也已經開發出來了，且又增加了一些新功能。測試也是用Java語言開發的。雖然自動化測試是從GUI自動化開始的，但是基于命令行界面的測試也變得日益重要，因為它可以使團隊更方便地通過已安排的分工協作進行自動化。
雖然當時有一些現成的測試套件可用于測試數據庫，但是我們并不知道使用什么自動化工具來進行數據庫的測試。另外，我們的數據庫有當時市場上還沒出現的一些特殊功能，而這是現有的測試工具無法測試的。雖然當時已經開發出了一款內部測試工具，但是它根本沒法滿足我們的需求。那時，我們突然有一些可用資源來開始這樣的一個項目，基于這些原因，我們進一步開始測試工具的開發。
2.2 測試中的軟件
該項目中要測試的軟件是比較特殊的，因為它僅僅只包含數據庫。雖然有一些現存的測試套件可用于測試數據庫，例如測試多個數據庫API和查詢語言之間兼容性的測試套件，包括JDK（Java Development Kit）、JDBC、ODBC（Open DataBase Connectivity）和SQL，但是這些工具的使用并不廣泛，并且（或者）它們僅僅只是為使用它們的數據庫量身定做的。所以本案例研究中的測試和測試工具都是內部開發的。
我們定義了一個操作系統組合而成的平臺，包括它的品牌和JDK版本。我們后來又將另一項包含進去：平臺是32位還是64位的。
例如，包括以下幾項：
Solaris 10 SPARC, JDK 6, 32位；
Solaris 10×64, JDK 6, 64位；
Solaris 10×64, JDK 6, 32位；
Solaris 10×86, JDK 6, 32位；
Solaris 10×86, JDK 5, 32位；
Windows Vista 64, JDK 6, 64位。
2.3 自動化測試的目標
在《Software Test Automation》（Addison-Wesley，1999）一書中，第8章有一張非常有用的表，列出了自動化測試的不同目標。當我們開始自動化測試時，根據這張表，按照優先級順序，列出下列這些測試目標：
增強在軟件質量方面的信心；
更早進入市場；
減少測試開銷；
保持可重復性測試的一致性；
自動運行測試；
找出回歸測試中的bug；
經常運行測試。
第一階段實施完成之后，又加入了以下測試目標：
質量更好的軟件；
測試更多的軟件；
性能測量；
找出更多的bug；
在不同的操作系統上測試。
【真知灼見】
剛開始不要設定太多目標，最初先重點完成某些目標，再逐步添加新的目標。
另外，在更深入的自動化的全新迭代周期中，我們又制訂了新的目標：
1）收集統計數據來制定度量標準（用以回答以下問題）：
① 在哪個操作系統上找到的bug數量最多？
② 在同一個操作系統上將測試進行分割會不會漏掉一些bug？
③ 哪些bug是在特定操作系統上才出現的？是在哪種操作系統上出現？
④ 哪些測試發現的故障數量最多？
⑤ 哪些測試從來都沒有發現故障？
⑥ 哪些失效是由發布測試發現的，而不是由每晚的測試所發現的？這有利于我們分析為什么這類故障在發布過程中比較晚時才發現。
2）將未使用的硬件用來做其他的事情。
3）盡量達到每周7天、每天24小時不間斷使用硬件。
4）縮短bug從發現到反饋給相關人員的時間間隔（最初從幾周縮短到幾天，然后縮短到只隔一夜，最后縮短到檢查代碼之后就直接完成反饋。）
5）使用我們自己的數據庫來收集統計數據，這樣就可以在真實的產品環境中擁有自己的數據，并且有可能會遇到在其他沒有發現的故障（用你自己的方法來解決）。
6）使測試場景不可能手動運行。
7）使場景維持幾天。
8）使場景具有多個用戶。
9）重新使用預處理任務，并使其自動化。
10）重新使用后續處理任務，并使其自動化。
11）對于測試結果自動生成測試報告。
12）完全的自動化測試。
2.4 開發內部測試工具
該內部測試工具的基本功能是由3 ~ 4位開發人員在6 ~ 9個月的時間內開發出來的，是用Java語言編寫的。第一個版本開發之后，一個人專門負責對其進行維護和進一步的開發，顯然維護和進一步開發的工作量是逐步減少的。
圖2-1是測試的Java引擎（Java Engine for Testing, JET）架構的一個概覽。每個大的矩形都是一臺運行某些軟件的計算機。
我們在圖2-1中的運行機（runner）處開始運行一組測試集合。它使用JETBatch來開始運行測試并收集運行結果。客戶端（client）運行與JETBatch進行交互的Jet代理程序（JET Agent，JAG），即使用JAG來啟動JET運行單個測試。這些JET讀入一個XML文檔，該文檔會給JET提供測試運行的內容，并與服務器的JAG進行交互來啟動我們需要測試的軟件。整套系統還包括一個測試裝置，通過使用不同的機器操作不同的任務，避免了架構本身的資源消耗對被測任務的影響。
因為我們確實投入了大量的時間和精力來設計自動化測試，所以幾乎實現了所有的目標（只有性能測試是由我們的另一款內部開發工具完成的，這不在本案例研究的討論范疇）。幾乎所有的測試都是通過我們的工具自動運行的，其中只有幾個測試，我們認為自動化的價值并不是很大，是由手動完成的。最后，我們有了一款可以在很多不同領域使用的、功能非常強大的工具。
圖2-1 測試工具的架構
2.4.1 配置
測試配置：我們的測試是定義在一個數據庫中的，并且可以單選、成組選擇或者根據特定序列來進行選擇。工具在每次測試之前都會進行一次初始化，避免前面的測試結果影響到后續的測試，工具在每次測試之后也會將測試環境清理干凈。工具還自動將測試件進行收集和歸檔。
【小竅門】
把實施預處理和后續處理作為啟動一個測試套件的一部分。
測試時應用程序的配置：可以對產品版本進行選擇，包括調試版本和來自開發人員“沙箱”（sandbox）的本地版本。
服務器和客戶端平臺的配置：我們使平臺的定義和在運行測試的平臺組的定義變得簡單。根據測試裝置在一個平臺組（例如，Windows Vista，64位，JDK 6）里面是否可用而將其劃分成不同的測試裝置。我們可以用一到兩個平臺為服務器設置一個單獨的配置，通常也可以用一個平臺為客戶端設置一個單獨的配置。對于客戶端和服務器來說，都可以選擇不同的操作系統。
一個標準的測試需要4臺機器：一臺測試機器，一臺客戶機，兩臺包含被測數據庫的服務器。
2.4.2 資源優化
通過添加更多的機器到測試裝置池中，我們可以并行地運行測試。另外，測試具有排隊機制：一個測試裝置上的測試完成之后，候選隊列里面的下一個測試就開始運行。
2.4.3 測試報告
這個內部工具創建了網站來記錄測試報告，所有的結果在一個數據庫中也進行了詳細存檔，這有利于我們建立詳細的度量，比如下面的度量：
1）在哪些平臺上會有一些什么樣的bug及其出現的頻率（可以幫助指定bug的優先級）。
2）每個平臺上的一般信息統計。
3）測試中bug的檢出率。
4）測試的冗余。
一個測試完成之后，會自動發送一個包含測試結果的匯總郵件，同時生成一個XML文件，它包含了用以導入到其他數據庫或者報表生成器的所有必要信息。
該工具也使得從開源測試覆蓋工具（EMMA）中導入信息變得更容易，而且讓我們能觀察到測試的質量——至少從表面上看是這樣的。
2.4.4 故障分析
在測試失效分析達到60% ~ 80%正確率之后，才能對失效進行自動識別。比如，通過定義描述故障的模式和標記來進行識別，在大多數情況下，我們定義一些模式或者簽名對故障進行描述，這些模式或者簽名通常與測試產生的錯誤信息、測試名稱和產生這條實效信息的測試語句直接相關。一個bug可能有多個標記，如果要對新的故障或者已知故障的新癥狀進一步進行人工分析，就需要新的標記信息。
用這個新工具實施的某產品的首次發布測試中，要求不論何種原因，無論是產品原因或者是測試原因，至少75%的測試運行的時候不會出現故障。最后，要求至少96%的測試運行的時候不會出現故障。
2.5 結果
該工具經過3年的開發和使用，在6 ~ 10個平臺上有200個測試的發布測試，可以僅由一個人在3 ~ 4天內運行完成。這等價于（在實施自動化之前）在16天的時間里（16:4）20個人（20:1）在一個平臺上（6:1）運行了40個測試（200:40）。所以自動化測試過程幫助我們提高了至少2400倍的工作效率！
【真知灼見】
用一種最恰當的方式向希望知道結果的人們來表述你的成功（這里的表述是，“將效率提高了2400倍”）。
現在所有的測試人員都可以集中精力進行測試的開發和進一步的工具開發，跟剛開始需要進行重復性的工作相比，他們現在的工作也不會那么枯燥了。我們的產品和測試的質量都得到了極大的提高。開發人員和測試人員都得到了應有的相互尊重，并且他們互相通過挑戰來激勵自己，這樣使他們工作的興趣更濃。
通過實施自動化，維護工作只占測試人員整個工作量的不到1/10，而且比之前的工作量要低很多，部分原因是因為產品進一步開發中的其中一個需求是后向兼容的。這是一個罕見的機會，測試與測試工具本身因為新的功能而需要改變。另一方面，新的功能通常需要新的測試，在某些情形下用以替代舊的測試。
?。ㄎ赐甏m...）
相關鏈接：
自動化測試最佳實踐 連載一
自動化測試最佳實踐 連載二
自動化測試最佳實踐 連載三
自動化測試最佳實踐 連載四