測試數(shù)據(jù)管理是個復雜的任務且當試著滿足測試數(shù)據(jù)需求時可以想出許多不同的測試數(shù)據(jù)策略。制定一個關于與手頭（測試）項目相關的每個（測試）數(shù)據(jù)需求的單獨測試數(shù)據(jù)策略大概太耗時了。因此，我們希望能夠為更大的（測試）數(shù)據(jù)組選擇測試數(shù)據(jù)策略。這樣我們需要一個機制來定義可以以同樣方式對待的（測試）數(shù)據(jù)組。定義框架或測試數(shù)據(jù)分類系統(tǒng)提供了這個機制且是建立在以下三方面上的：
　　▪測試數(shù)據(jù)特性（例如測試數(shù)據(jù)類型，生產(chǎn)相似性，一致性，統(tǒng)一性，數(shù)量）
　　▪測試目標（組件測試，系統(tǒng)測試，驗收測試）
　　▪測試環(huán)境（DTAP模式）

　　借用“銷售渠道”說明
　　對于一個單元測試，開發(fā)人員只需要一些來自每個表格的記錄（比如：10名員工，100次機會，100名客戶）以充分覆蓋代碼。但是對于測試性能，環(huán)境必須是類似生產(chǎn)的，這意味著在一個專門環(huán)境中照搬所有表格。對驗收測試業(yè)務，測試數(shù)據(jù)（如：外國客戶，不同狀態(tài)下的機會（打開的/關閉的），不同的員工）中包含所有不同種類的情況也很重要。無論哪個測試環(huán)境，有一致的測試數(shù)據(jù)意味著你不能只選一個表格獲取數(shù)據(jù)的。在我們的例子里，客戶和員工都與機會相關聯(lián)，所以所有這些表格中的記錄都要被挑選。后，在每個（測試）項目里建立測試數(shù)據(jù)是一項很重要的活動。沒有恰當?shù)臏y試數(shù)據(jù)，無法執(zhí)行一個單獨的測試用例。
　　但是接下來又有問題了。什么是恰當?shù)臏y試數(shù)據(jù)？什么時候我們用的測試數(shù)據(jù)質(zhì)量夠了？質(zhì)量框架來回答。框架里，當測試數(shù)據(jù)滿足以下需求時，我們覺得測試數(shù)據(jù)適合測試目的（且是高質(zhì)量的）：
　　▪測試數(shù)據(jù)符合適用于你公司內(nèi)的通用數(shù)據(jù)質(zhì)量屬性（如：準確性，完整性，可達性等）
　　▪測試數(shù)據(jù)覆蓋測試需求
　　▪測試數(shù)據(jù)反映真實生活數(shù)據(jù)
　　每個公司都要處理他們以安全方式處理的數(shù)據(jù)。根據(jù)法律，個人數(shù)據(jù)必須受到保護而不被無意使用，被認為機密的非個人數(shù)據(jù)不該泄漏出去。無論這個責任初目的是什么（國際立法或僅僅是出于自身利益），公司受到的來自暴露出去的敏感數(shù)據(jù)的傷害都相當大。規(guī)章框架解答了該如何管理測試數(shù)據(jù)（和測試環(huán)境）以滿足相關測試數(shù)據(jù)安全需求。理想情況是，該政策可以成為公司安全政策，測試政策或質(zhì)量政策的一部分。

　　借用“銷售渠道”說明
　　可以用三種方法按要求隱藏客戶數(shù)據(jù)：
　　▪搞亂基于模式的公司名（比如用Ｘ或Ｙ代替特性）
　　▪用不亂但虛構(gòu)的數(shù)據(jù)（如John Tester， Teststreet 10 in 1000 Testland）替代敏感數(shù)據(jù)
　　▪在像東大街一樣的地方加入任意數(shù)量
　　▪基于計算程序用自己的數(shù)據(jù)代替現(xiàn)存數(shù)量

　　測試數(shù)據(jù)管理需求
　　測試數(shù)據(jù)管理需求子框架解釋該如何管理測試數(shù)據(jù)。其結(jié)構(gòu)與測試數(shù)據(jù)需求子框架很相似。它也包含四個子框架。需求框架相似地列出了一些通用測試數(shù)據(jù)管理需求。流程框架，組織框架和基礎設施框架各自提供關于專門用于測試數(shù)據(jù)管理背景的典型管理方面（流程，人，技術）的更深入信息。他們提供解釋需求框架中通用測試數(shù)據(jù)管理需求所需的背景信息。

圖4.　測試數(shù)據(jù)管理需求子框架