減少軟件測試的時間和成本（二）
接上一篇
要求具備測試數據，以確保每個系統層次的需求都得以測試和驗證。審查測試數據需求可以解決許多數據關注的事情，如下面所列舉的，而且以手動方式進行這些審查都是不可行的。這就是自動化測試數據生成的回報。
深度
測試團隊必須考慮為了支持測試所需的數據庫記錄的量或規模。他們需要確定一個數據庫或特定表格中的10條記錄是否足夠，或是否有必要使用10 000條記錄。在生命周期早期的測試，如單元測試或構建驗證測試，應該使用手動創建的小數據庫，這樣可以提供最大的控制粒度和最小的干擾。在不同測試階段和不同類型測試過程中，數據庫應該增長到一定規模，以適合特定的測試。比如，當產品環境數據庫會包含1 000 000條記錄時，針對只包含100條記錄的數據庫進行性能及容量測試是沒有意義的。
廣度
測試工程師需要考察數據值的變體（比如，10 000個不同的賬戶和大量不同類型的賬戶）。設計良好的測試將包括各種測試數據的變體，而且對所有類似的數據進行的測試生成有限的結果。例如，測試時可能需要考慮賬戶余額為負的賬戶、余額非常低的（$100）、中等范圍的（ $1 000）、大范圍的（$100 000），以及非常大范圍（$10 000 000）的賬戶。同時測試還應該反映平均水平的數據。對于銀行賬戶來說，客戶賬戶可以按不同方式歸類，包括按儲蓄、支票、貸款、學生、聯名和商業。所有數據類別都需要考慮。
范圍
測試團隊需要調查數據的相關性。測試數據的范圍與數據的準確性、相關性和完整性相關。比如，當測試用于確定各種類型的銀行賬戶的查詢（根據賬戶余額是否多于100美元）時，不僅要考慮到滿足這一標準的賬戶數量，而且該測試還應反映出額外的數據，例如原因代碼、聯系歷史和賬戶所有者的人口統計數據。完整的測試數據集包括的東西能使測試程序充分驗證和使用系統，支持對結果的評估。測試工程師同樣需要驗證，作為一個查詢的結果返回的記錄對特定目的仍然有效（如超過90天逾期），且該記錄不是遺失或不適當的價值的結果。另一個關鍵是，對業務邏輯或最終用戶的權利和特權，需要不同類型的數據不同路徑模擬。
測試執行數據完整性
測試團隊需要考慮測試數據的另一方面是在執行測試時需要維護數據的完整性。測試團隊需要能夠分開數據，修改所選擇的數據，并在測試操作后將數據庫恢復到初始狀態。測試團隊需要確保當多個測試工程師同時執行測試時，一個測試不會對其他測試需要的數據產生不利的影響。比如，當測試團隊的某個成員正在運行一個查詢時，另一個成員修改了數據值，這樣查詢的結果可能不是期望的，因為記錄被其他測試人員修改了。為避免一個測試人員的測試過程影響其他測試人員的測試結果，應給測試人員分配不同的測試任務，要求每個測試人員關注功能的特定方面，不與其他測試人員的工作重疊。使用自動測試腳本可以簡化這一過程并使得數據自動保持完整。
條件
應該創建能反映應用領域的特定“條件”的數據集，意思是數據的某種模式只能通過單次執行或隨時間推移多次執行后才能獲得。例如，金融系統通常執行年終處理（year-end closeout）。以年終條件方式存儲數據，使得測試小組可以測試系統的年終狀態，而不需要進入全年的數據。有了這些已創建的數據，并準備投入測試，可簡化測試工作，因為這種情況下只是簡單地載入測試數據，而不是執行許多操作來獲得數據的年終狀態。同樣，自動測試工具可以在這里發揮作用。
作為確定測試數據需求過程的一部分，開發一個包含一列測試過程列表和一列測試需求列表的矩陣是非常有益的。前面已經提到過，小的數據子集對于功能測試足夠了，而性能測試則需要一個產品規模的數據庫。如果手動建立數據庫很可能要幾個月的時間。自動化測試則能快速填充測試數據庫。
一旦提出了測試數據的需求，測試團隊還需要對獲取、生成、開發測試數據和刷新測試數據庫到原始狀態的方法做出計劃，以便進行所有測試活動，包括回歸測試。這個時候就需要自動化的方法。
測試之前通常需要提前準備好數據。數據準備包括原始數據或文本文件的處理、一致性檢查以及對數據元素的深度分析（其中包括根據測試用例標準定義數據，解釋數據元素的定義，確定主鍵，以及定義可用的數據參數）。測試團隊需要獲得并修改任何測試數據庫，這一數據庫是執行軟件應用程序和開發環境安裝腳本和測試臺腳本中所必需的。
理想情況下，可利用已有的客戶或系統數據，這些數據包括了實際的數據場景的組合和變體（假設數據已經清理過，移除了所有私有的或個人的信息）。客戶數據同樣包括測試團隊沒有考慮到的有些組合或使用模式，因此，測試過程中使用已有的真實客戶數據對于應用來說是一個非常有用的實際檢驗。
手動生成測試數據將很繁瑣、費時且易出錯。
【編輯推薦】
