[[438855]]

【51CTO.com快譯】隨著對豐富且合規的數據的需求不斷增加，測試數據供應的壓力必須變得更加自動化、自給自足，并對變化作出反應。

如今，任何測試數據解決方案都必須能夠以前所未有的速度滿足更大容量、更多種類和更復雜的數據需求。通常這種緊迫的需求并不總是得到企業的充分理解，可能會產生負面后果，其中包括：

(1)不斷增長的測試瓶頸。

(2)測試失敗的增加。

(3)整體軟件開發生命周期 (SDLC)的生產力損失。

(4)不斷增加的基礎設施成本。

(5)持續不斷的合規風險。

有許多因素導致本已緊張的測試數據服務壓力增加。本文考慮了增加當今測試數據需求的頻率、數量和復雜性的相關趨勢。這些新的和持續的趨勢可以分為五種，而企業在設計強大的測試數據解決方案時必須考慮以下這些因素：

(1)相互關聯的數據類型的復雜性。

(2)系統、環境和生產數據變化的速度和幅度。

(3)測試和開發之間更大程度的并行化。

(4)在測試中采用自動化以及“數據請求者”的性質不斷變化。

(5)不斷變化的合規要求。

這些相關因素對軟件交付速度和質量構成的潛在風險要求超越過時的測試數據“供應”實踐。它需要采用一個自動化的解決方案，能夠即時滿足新的和不斷發展的測試數據請求。這種并行團隊、測試和框架按需自備數據的能力是測試數據管理(TDM)和測試數據自動化(TDA)之間的主要區別。

首先，需要了解一些給已經很緊張的測試數據供應服務增加壓力的因素。

1.相關數據源的復雜性

如今的測試數據解決方案無法將孤立的數據填充到數量有限的數據庫和文件類型中。與其相反，測試和開發需要豐富且合規的數據，這些數據始終涵蓋眾多傳統技術和尖端技術。

這種集成的、相互關聯的數據是集成和端到端測試所必需的，但會顯著地增加測試所需數據的復雜性。企業軟件和IT的一系列趨勢導致當今企業使用的數據類型激增。它們包括：

(1)正在從傳統基礎設施轉向基于網絡和云計算的基礎設施。

(2)大數據和人工智能的出現，以及相關的數據存儲、分析和處理技術。這通常包括開源技術，如Apache Hadoop、Spark、Kafka和Solr。

(3)采用新的數據庫和文件類型。這包括像Neo4j這樣的圖形數據庫，以及采用近年來出現的數據庫，例如MariaDB和Firebird。

(4)API和消息層在當今至關重要。這導致需要創建消息數據，例如XML文件，以及行業特定的格式和標準。

(5)商業智能技術的不斷演進。

(6)微服務的采用。

雖然企業不斷采用新技術，但這些新興數據類型并不能完全替代現有的遺留組件。遷移需要時間，很少有企業能夠一次性替換其技術堆棧的所有元素。

因此，在企業的不同部分中發現混合使用的新舊數據類型是很常見的。例如，企業的不同部分可能使用現代的、基于云計算的技術，而其他部分則使用存儲在大型機和中端系統上的專有數據類型。新舊數據通常必須使用當今可用的接口范圍進行交互和集成：當今的測試需要跨越多種技術的數據的集成組合。

因此，任何測試數據解決方案通常都必須能夠為比以往更加多樣化的技術分析、操作和創建集成數據。它應該配備廣泛且可擴展的連接器，并且必須能夠在不同的文件、數據庫和應用程序之間協同創建集成數據。

數據類型的多樣性和復雜性增加了當今數據請求的復雜性，因為測試人員和開發人員需要跨各種技術無縫鏈接的集成數據。與此同時，數據請求的速度和演變正在增長，提高了當今數據請求的速度和多樣性。

2.迭代交付、敏捷軟件開發和持續集成(CI)/持續交付(CD)

軟件交付的幾個趨勢增加了測試和開發所需數據的變化率，這增加了測試數據供應的壓力。這些趨勢加快了系統、環境和生產行為變化的速度和幅度，需要新的和日益多樣化的測試數據。這些措施包括：

(1)迭代交付的興起，新版本和更新在幾天或幾周內獲得，而不是幾個月或幾年。

(2)采用敏捷軟件開發實踐，強調增量更改和并行化。

(3)在DevOps管道和持續集成(CI)/持續交付(CD)中增加自動化和新技術，使快速變化能夠持續開發并集成到現有系統中。

每次快速更改都會使現有數據經常變得過時。現有數據可能與最新的系統邏輯和數據結構不匹配。與此同時，由于歷史數據缺乏測試新邏輯或更新邏輯所需的數據組合，因此覆蓋范圍出現了差距。雖然測試覆蓋率的差距會導致錯誤，但不一致或無效的組合會導致測試失敗和出現瓶頸。

上面列出的三個措施也增加了數據請求的速度和數量，因為每個措施都強調并行工作方式。測試數據解決方案不能再為有限數量的團隊提供相對靜態的數據集。與其相反，必須向眾多跨職能團隊和自動化框架提供最新數據：如今，測試數據通常必須同時提供給眾多團隊和框架。

當今的任何測試數據解決方案通常都必須能夠以并行化開發團隊開發復雜系統的速度提供最新和完整的數據。而測試和開發需要不斷變化的數據集，這些數據集可以并行和動態地使用。此外，按需數據必須完全版本化，能夠測試版本化系統組件的不同組合。

3.容器化、源代碼控制和易于重用的代碼

如今對復雜系統改變的幅度可能比以往任何時候都大。這對緩慢和過度的數據供應提出了挑戰，因為大量數據可能需要根據快速的系統變化進行更新或替換。

開發中的一系列實踐增加了系統更改的速度和規模。容器化、源代碼控制和易于重用的代碼庫的采用使開發人員能夠以閃電般的速度翻錄和替換代碼。他們可以輕松部署新的工具和技術，開發出由快速變化的組件構成的錯綜復雜的系統。

當今的測試數據解決方案必須能夠根據這些變化對相關系統組件的巨大影響提供一致的測試數據的旅程。數據分配必須按照開發人員對可重用和容器化組件進行細分和更改的速度進行。

這通常需要更緊密地耦合系統需求、測試和代碼，根據整個軟件開發生命周期 (SDLC)的變化快速確定需要哪些數據。否則，由于測試人員和開發人員缺乏在迭代中交付的經過嚴格測試軟件所需的最新數據，就會出現測試瓶頸和錯誤。

4.測試自動化

測試自動化是另一個關鍵發展，它增加了測試和開發中對最新數據的持續需求。

測試執行自動化和持續集成(CI)/持續交付(CD)顯著地提高了數據請求的速度和數量。數據處理的框架比測試人員更快地讀取數據，通常在夜間和周末運行大型測試套件。此外，相同的測試通常是并行化的，從而增加了對數據的需求。

除了提高需要測試數據的速度之外，自動化測試進一步加劇了與不準確數據供應相關的挑戰。而腳本測試不如測試人員寬容，如果數據不完整、無效或丟失，他們可以調整測試。如果數據無效、過時或丟失，自動化測試可能會終止。這增加了測試和開發的瓶頸，因為在自動化測試期間bug識別的錯誤需要調查。

測試自動化已經改變了當今測試數據請求者的性質​​。當今有效的測試數據解決方案通常應該為測試人員和開發人員以及測試自動化框架和持續集成(CI)/持續交付(CD)管道等技術提供按需訪問的功能。人員和程序都應該能夠即時參數化和觸發測試數據作業。這是傳統測試數據管理和測試數據自動化之間的另一個主要區別。

5.不斷發展的數據隱私要求

使測試數據“最佳實踐”變得復雜并要求修訂的發展在于數據隱私要求和法規。

歐盟GDPR法規已經引導企業禁止在測試中使用原始生產數據，因為他們必須遵守更嚴格的數據處理規則。這些規則通常會限制數據的使用方式、使用對象以及使用時間。

歐盟GDPR等立法也對傳統測試數據優秀實踐提出了特殊的挑戰。如今的企業可能需要立即定位、復制和刪除個人數據的每個副本。這通常需要對數據在測試和開發中的使用方式進行更嚴格的控制和監督，以及實施在非生產環境中定位數據的快速可靠機制。通常情況下，一種更安全、更簡單的方法是避免將敏感信息復制到安全性較低、控制較少的測試和開發環境中。

雖然歐盟GDPR法規在許多方面是數據隱私的分水嶺，但它并不是孤立的發展。它反映了更廣泛的全球法規發展方向，許多國家已經批準了與歐盟GDPR類似的法規。這些國家的法規可能會對測試中的數據使用產生類似的影響。其中包括英國GDPR、加拿大CCPA、印度PDPB和巴西LGPD等法規。

不斷變化的數據隱私要求會增加管理測試數據的復雜性，以及對非生產環境中數據所需的總體控制程度。已經在努力向測試人員和開發人員提供足夠種類和數量的數據的企業可能并不會接受無法提供數據的想法，更不用說必須刪除和限制現有測試數據。然而，違規的后果可能非常嚴重。

測試數據自動化和人工智能的前景

許多新的和持續的趨勢意味著當今在測試和開發中需要更多數量和更多種類的數據。本文只確定了其中一些因素，其中包括：

(1)相互關聯的數據源和目標的出現，需要一致且錯綜復雜的數據。

(2)系統、環境和生產變化的速度和幅度加大，需要新的和不斷發展的數據用于測試和開發。

(3)跨測試和開發的更大程度的并行化，需要按需和并行地提供大量數據。

(4)在測試中采用自動化技術，改變了“數據請求者”的性質，需要更多數量和種類的準確數據。

(5)不斷發展的數據隱私法規，要求加強對敏感數據在非生產環境中使用的方式和時間進行管理。

這些趨勢增加了本已緊張的測試數據供應服務的壓力，增加了延遲，并降低了測試和開發的質量。因此，這需要修訂測試數據的優秀實踐。

原文標題：5 Trends Increasing the Pressure on Test Data Provisioning，作者：Thomas Pryce

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】