測試數據管理是個復雜的任務且當試著滿足測試數據需求時可以想出許多不同的測試數據策略。制定一個關于與手頭（測試）項目相關的每個（測試）數據需求的單獨測試數據策略大概太耗時了。因此，我們希望能夠為更大的（測試）數據組選擇測試數據策略。這樣我們需要一個機制來定義可以以同樣方式對待的（測試）數據組。定義框架或測試數據分類系統提供了這個機制且是建立在以下三方面上的：
▪測試數據特性（例如測試數據類型，生產相似性，一致性，統一性，數量）
▪測試目標（組件測試，系統測試，驗收測試）
▪測試環境（DTAP模式）
借用“銷售渠道”說明
對于一個單元測試，開發人員只需要一些來自每個表格的記錄（比如：10名員工，100次機會，100名客戶）以充分覆蓋代碼。但是對于測試性能，環境必須是類似生產的，這意味著在一個專門環境中照搬所有表格。對驗收測試業務，測試數據（如：外國客戶，不同狀態下的機會（打開的/關閉的），不同的員工）中包含所有不同種類的情況也很重要。無論哪個測試環境，有一致的測試數據意味著你不能只選一個表格獲取數據的。在我們的例子里，客戶和員工都與機會相關聯，所以所有這些表格中的記錄都要被挑選。后，在每個（測試）項目里建立測試數據是一項很重要的活動。沒有恰當的測試數據，無法執行一個單獨的測試用例。
但是接下來又有問題了。什么是恰當的測試數據？什么時候我們用的測試數據質量夠了？質量框架來回答。框架里，當測試數據滿足以下需求時，我們覺得測試數據適合測試目的（且是高質量的）：
▪測試數據符合適用于你公司內的通用數據質量屬性（如：準確性，完整性，可達性等）
▪測試數據覆蓋測試需求
▪測試數據反映真實生活數據
每個公司都要處理他們以安全方式處理的數據。根據法律，個人數據必須受到保護而不被無意使用，被認為機密的非個人數據不該泄漏出去。無論這個責任初目的是什么（國際立法或僅僅是出于自身利益），公司受到的來自暴露出去的敏感數據的傷害都相當大。規章框架解答了該如何管理測試數據（和測試環境）以滿足相關測試數據安全需求。理想情況是，該政策可以成為公司安全政策，測試政策或質量政策的一部分。
借用“銷售渠道”說明
可以用三種方法按要求隱藏客戶數據：
▪搞亂基于模式的公司名（比如用Ｘ或Ｙ代替特性）
▪用不亂但虛構的數據（如John Tester， Teststreet 10 in 1000 Testland）替代敏感數據
▪在像東大街一樣的地方加入任意數量
▪基于計算程序用自己的數據代替現存數量
測試數據管理需求
測試數據管理需求子框架解釋該如何管理測試數據。其結構與測試數據需求子框架很相似。它也包含四個子框架。需求框架相似地列出了一些通用測試數據管理需求。流程框架，組織框架和基礎設施框架各自提供關于專門用于測試數據管理背景的典型管理方面（流程，人，技術）的更深入信息。他們提供解釋需求框架中通用測試數據管理需求所需的背景信息。
圖4. 測試數據管理需求子框架
