測試人員不僅從現有的源收集/維護數據，而且還生成大量的測試數據，以確保它們在為實際使用的產品交付方面做出了巨大的貢獻。

因此，作為測試人員，我們必須不斷探索、學習和應用最有效的數據收集、生成、維護、自動化和全面數據管理方法，用於任何類型的功能測試和非功能測試。

Test data tutorial

在本教程中，我將提供提示如何準備測試數據，這樣任何重要的測試用例都不會被不正確的數據和不完整的測試環境設置所遺漏。

什麽是測試數據？為什麽它是重要的？
參照IBM在2016年進行的一項研究，搜索、管理、維護和生成測試數據的時間占測試人員時間的30%-60%。數據準備是軟件測試的一個耗時階段，這是一個不可否認的證據。

圖1：測試人員平均花費在TDM上的時間

盡管如此，大多數數據科學家將其模型開發時間的50%-80%用於組織數據，這是許多不同學科的事實。現在，考慮到立法以及個人可識別信息(PII)，測試人員在測試過程中的參與度是相當不錯的。

今天，測試數據的可信度和可靠性被認為是企業主不可妥協的因素。產品所有者將測試數據的幽靈副本視為最大的挑戰，這降低了在客戶對質量保證的需求/要求的獨特時刻任何應用程序的可靠性。

考慮到測試數據的重要性，大多數軟件所有者在安全措施方面不接受假數據或更少的測試應用程序。

在這一點上，我們為什麽不回憶一下什麽是測試數據？當我們開始編寫測試用例來驗證和驗證測試下的應用程序的給定特性和開發場景時，我們需要用於執行測試以識別和定位缺陷的信息。

我們知道，這些信息必須是精確和完整的，以消除錯誤。這就是我們所說的測試數據。為了使它準確，它可以是名稱、國家等…，不敏感，涉及聯系信息、SSN、病史和信用卡信息的數據在本質上是敏感的。

數據可以是任何形式，如：

系統測試數據
SQL測試數據
性能測試數據
XML測試數據
如果您正在編寫測試用例，那麽您需要為任何類型的測試輸入數據。測試人員可以在執行測試用例時提供此輸入數據，或者應用程序可以從預定義的數據位置選擇所需的輸入數據。

數據可以是對應用程序的任何類型的輸入，也可以是由應用程序加載的任何類型的文件，也可以是從數據庫表中讀取的條目。

準備適當的輸入數據是測試設置的一部分。一般來說，測試人員稱它為試驗臺準備。在測試平臺上，所有的軟硬件需求都是使用預定義的數據值來設置的。

如果您沒有系統的方法來構建數據編寫和執行測試用例然後就有可能錯過一些重要的測試用例。測試人員可以根據測試需求創建自己的數據。

不要依賴其他測試人員創建的數據或標準生產數據。始終根據您的需求創建一組新的數據。

有時，不可能為每個構建創建一個全新的數據集。在這種情況下，您可以使用標準生產數據。但是，請記住在這個現有的數據庫中添加/插入您自己的數據集。創建數據的一種最佳方法是使用現有的示例數據或測試床，並在每次獲得用於測試的相同模塊時追加新的測試用例數據。這樣，您就可以在此期間構建全面的數據集。

測試數據來源挑戰
測試人員考慮的測試數據生成領域之一是子集的數據來源需求。例如，你有超過一百萬的客戶，你需要他們中的一千人進行測試。這些樣本數據應該是一致的，並且在統計上代表目標群體的適當分布。換句話說，我們應該找到合適的測試對象，這是測試用例最有用的方法之一。

這些樣本數據應該是一致的，並且在統計上代表目標群體的適當分布。換句話說，我們應該找到合適的測試對象，這是測試用例最有用的方法之一。

此外，在這一過程中還存在一些環境制約因素。其中之一是映射PII策略。由於隱私是一個重要的障礙，測試人員需要對PII數據進行分類。

測試數據管理工具都是為解決上述問題而設計的。這些工具根據它們所擁有的標準/目錄來建議策略。不過，這並不是很安全的鍛煉。它仍然提供了對一個人正在做的事情進行審計的機會。

為了跟上當前甚至未來的挑戰，我們應該總是問這樣的問題：我們應該從什麽時候/從哪裏開始進行TDM？什麽應該是自動化的？公司應該在人力資源、持續技能開發和使用較新的TDM工具等領域投入多少資金用於測試？我們應該開始使用功能性測試還是非功能性測試？更有可能像他們一樣提出問題。

下面介紹了測試數據來源中最常見的一些挑戰：

團隊可能沒有足夠的測試數據生成器工具、知識和技能。
測試數據覆蓋率通常是不完整的。
在收集階段，涵蓋卷規格的數據要求不那麽清晰
測試團隊無法訪問數據源。
開發人員延遲向測試人員提供生產數據訪問
基於開發的業務場景，生產環境數據可能不能完全用於測試。
在給定的時間內，可能需要大量的數據。
測試某些業務場景的數據依賴關系/組合
測試人員花更多的時間與架構師、數據庫管理員進行通信，並在收集數據方面花費更多的時間。
大多數數據是在測試執行過程中創建或準備的。
多個應用程序和數據版本
跨幾個應用程序的連續發布周期
照顧個人身分證明資料的法例(PII)
在數據測試的白盒端，開發人員準備生產數據。這就是QA需要與開發人員接觸的地方，以進一步擴大AUT的測試覆蓋範圍。最大的挑戰之一是將所有可能的場景(100%的測試用例)與每一個可能的負面案例結合起來。

在本節中，我們討論了測試數據挑戰。您可以添加更多的挑戰，因為您已經相應地解決了它們。隨後，讓我們探討處理測試數據設計和管理的不同方法。

測試數據準備策略
通過日常實踐我們知道，測試行業的參與者不斷地經歷著不同的方式和方法來加強測試工作，最重要的是它的成本效益。在信息和技術發展的短短的過程中，我們已經看到，當工具被整合到生產/測試環境中時，產出的水平就有了很大的提高。

當我們談到測試的完整性和覆蓋度時，主要取決於數據的質量。測試是軟件質量的支柱，測試數據是測試過程中的核心要素。

圖2：測試數據管理策略

基於映射規則創建平面文件。從開發人員設計和編碼應用程序的生產環境中創建所需數據的子集總是切實可行的。實際上，這種方法減少了測試人員編制數據的努力，最大限度地利用現有資源避免進一步支出。

通常，我們需要創建數據，或者至少根據每個項目剛開始時的需求類型來確定它。

我們可以應用以下策略來處理TDM過程：

來自生產環境的數據
檢索從客戶端現有數據庫提取數據的SQL查詢
自動數據生成工具
測試人員應該通過考慮圖3所示的元素來用完整的數據備份他們的測試，敏捷開發團隊中的測試人員為執行他們的測試用例生成必要的數據。當我們談到測試用例時，我們指的是各種類型測試的用例，如白盒、黑匣子、性能和安全性。

在這一點上，我們知道用於性能測試的數據應該能夠確定系統在給定工作負載下的響應速度，以非常接近真實的或實時的、覆蓋範圍很大的大量數據。

對於白盒測試，開發人員準備所需的數據，以覆蓋盡可能多的分支、程序源代碼中的所有路徑和負應用程序接口(API)。

圖3：測試數據生成活動

最後，我們可以說，在軟件開發生命周期中工作的每個人(SDLC)和BAS一樣，開發人員和產品所有者應該很好地參與測試數據的準備過程。這可以是一種共同努力。現在讓我們來討論一下測試數據損壞的問題。

損壞測試數據
在對現有數據執行任何測試用例之前，我們應該確保數據沒有損壞/過時，並且測試下的應用程序可以讀取數據源。通常，當測試人員同時在測試環境中處理AUT的不同模塊時，數據損壞的幾率很高。

在同一環境中，測試人員根據測試用例的需要/需求修改現有數據。大多數情況下，當測試人員完成數據處理時，他們會保留數據的原樣。一旦下一個測試人員獲得修改後的數據，並執行另一次測試，就有可能發生特定的測試失敗，而不是代碼錯誤或缺陷。

在大多數情況下，這會導致數據損壞和/或過時，從而導致失敗。為了避免和盡量減少數據不一致的可能性，我們可以按下面的方式應用解決方案。當然，您可以在本教程的末尾在註釋部分添加更多的解決方案。

備份數據
將修改後的數據返回到原始狀態。
測試人員之間的數據劃分
讓數據倉庫管理員隨時更新數據更改/修改。
如何在任何測試環境中保持數據完整？

大多數情況下，許多測試人員負責測試相同的構建。在這種情況下，不止一個測試人員將能夠訪問公共數據，並且他們將根據自己的需要嘗試操作公共數據集。

如果您已經為某些特定模塊準備了數據，那麽保持數據集完整的最佳方法是保留數據集的備份副本。

性能測試用例的測試數據
性能測試需要非常大的數據集。有時候，手動創建數據不會檢測到一些微妙的錯誤，這些漏洞可能只會被測試的應用程序創建的實際數據捕獲。如果您想要實時數據，這是不可能手動創建的，那麽請您的領導/經理將其從活動環境中提供。

這些數據將有助於確保所有有效輸入的應用程序的順利運行。

什麽是理想的測試數據？

數據可以說是理想的，如果對數據集的最小大小，所有的應用程序錯誤得到識別。嘗試準備包含所有應用程序功能的數據，但不要超過準備數據和運行測試的成本和時間限制。

如何準備數據以確保最大限度的測試覆蓋率？
設計數據時考慮以下類別：

1)無數據：在空白或默認數據上運行測試用例。查看是否生成了正確的錯誤消息。

2)有效數據集：創建它以檢查應用程序是否按照要求工作，並且有效的輸入數據是否正確地保存在數據庫或文件中。

3)無效數據集：準備無效的數據集以檢查應用程序的負值、字母數字字符串輸入的行為。

4)非法數據格式：制作一個非法數據格式的數據集。系統不應接受無效或非法格式的數據。此外，檢查正確的錯誤消息是生成的。

5)邊界條件數據集：包含範圍以外數據的數據集。識別應用程序邊界案例，並準備涵蓋較低和較高邊界條件的數據集。

6)性能、載荷和壓力測試數據集：這個數據集的容量應該很大。

這樣，為每個測試條件創建單獨的數據集將確保完整的測試覆蓋率。

黑箱測試數據
質量保證測試人員執行集成測試、系統測試和驗收測試，這稱為黑箱測試。在這種測試方法中，測試人員在測試下的應用程序的內部結構、設計和代碼方面沒有任何工作。

測試人員的主要目的是識別和定位錯誤。通過這樣做，我們使用不同的黑匣子測試技術，應用功能測試或非功能測試。

圖4：黑匣子數據設計方法

此時，測試人員需要測試數據作為執行和實現黑匣子測試技術的輸入。測試人員應該準備數據，以便在不超過給定成本和時間的情況下檢查所有應用程序功能。

我們可以為我們的測試用例設計數據，考慮數據集類別，如無數據、有效數據、無效數據、非法數據格式、邊界條件數據、等價劃分、決策數據表、狀態轉換數據和用例數據。在進入數據集類別之前，測試人員開始在測試人員(AUT)下對應用程序的現有資源進行數據收集和分析。

根據前面提到的保持數據倉庫始終更新的要點，您應該在測試用例級別記錄數據需求，並在編寫測試用例腳本時標記它們可使用或不可重用。它幫助您測試所需的數據從一開始就得到了很好的澄清和記錄，您可以在以後的進一步使用中參考這些數據。

結語
根據行業標準、法規和項目的基準文件創建完整的軟件測試數據是測試人員的核心職責之一。我們越有效地管理測試數據，我們就越能為現實世界的用戶部署合理的無bug產品。

測試數據管理(TDM)是基於對挑戰的分析和引入，並應用最好的工具和方法來很好地解決已確定的問題，同時又不影響最終輸出(產品)的可靠性和覆蓋範圍的過程。

在分析和選擇測試方法時，我們總是需要提出一些問題，以尋找創新的、更符合成本效益的方法，包括使用生成數據的工具。被廣泛證明的是，設計良好的數據使我們能夠在多階段SDLC的每個階段識別測試下的應用程序的缺陷。

我們需要與敏捷團隊內外的所有成員一起創新和參與，請分享您的反饋、經驗、問題和意見，以便我們能夠繼續我們的技術討論-通過管理數據來最大限度地發揮我們對AUT的積極影響。

準備合適的測試數據是“項目測試環境設置”的核心部分。我們不能簡單地錯過測試用例，說沒有完整的數據可供測試。測試人員應該在現有標準生產數據之外創建自己的測試數據。您的數據集在成本和時間方面應該是理想的。

要有創造力，用自己的技能和判斷來創建不同的數據集，而不是依賴標準的生產數據。

測試數據管理：什麽是測試數據以及如何設計它