 |
Ruth Rose是一名數據驗證專家。她擅長預測模型領域的數據質量和數據分析。她曾在耶路撒冷的希伯來大學學過數學，并在各種創業公司和微軟以色列研發中心工作過。目前，她在PayPal/eBay風險部擔任分析驗證主管。 |
在一個數據不斷增長的世界，軟件測試涉及不同的數據驗證程序，這些程序是傳統質量保證方法的一個組成部分。本文旨在為非數據人員提供數據驗證工具，同時也為回歸測試和功能測試提供更多自動且迅速的工具和測試策略。
本文中，我將詳細介紹數據驗證的兩種方法：自下而上法和自上而下法。這兩種方法在不同的應用程序和測試策略中已實現的數據中所起的作用是不一樣的。
自下而上方法中，應用程序是代理器，而數據是反應器。我們通常使用此方法對新功能進行功能測試或把它與自上而下結合方法以覆蓋大量代碼。
另一方面自上而下法中，數據只在畫面里，我們根據外部知識判斷關于數據模式內關系的猜想是真還是假。
后一種方法使我們能夠設計出成本低但功能強大的回歸測試集以及根本原因分析法。
介紹
數據無所不在。它已不再是某些較高等級的應用程序的附帶品，而被視為是有價值的、脆弱的。在信息論中，數據是信息抽象化即知識的低水平。這意味著我們要有一個專家把行業知識原則又稱產品需求和產品規格轉化為一個一致的數據模式。
這實際上解決了這一行中一直以來的一個困境：產品經理和產品架構師對產品規格的見解不一。
事實上，數據的既定邏輯結構及評估它的明確結果可以把一個MRD / PRD轉化成一個比以往更容易的測試計劃。
但是，數據質量保證技術通常很昂貴且需要分析、BI工具和專業知識。
本文不看數據驗證本身，而是建議用一個簡單的、可重復的、不怎么需要資源和外部或技術支持的、且基于數據驗證的測試策略去替代標準質量保證程序。
讓我們考慮考慮一個在線購物市場的簡單案例研究：實現B2C交易并對測試這樣一個應用程序的設計和選項進行檢查。
自下而上的數據驗證法
直接設計包括應用程序和DB。
此方法中，我們有一個傳統的STP ，當自動使用簡單的宏命令時，可用作一個自定義的和高度有效的低成本測試工具。
為簡單起見，我們假設在我們的例子中，基本的測試用例是：
需要注意的是，我們還沒有對這個流程進行任何驗證。
我們不會把這個簡單直接的流程擴展為一個完整的測試過程：“生成用戶> 0 $交易”。
這個程序將使用簡單的Web宏命令調整發送給應用程序的涵蓋購物車、用戶資料等所有可能方案的需求。驗證在后進行以防止斷裂或使用昂貴的基礎設施。
這個例子演示了數據流的另一個強大的優點。數據是事件流的結果。這意味著：例如，如果用戶還沒有注冊賬戶（根據這個具體的例子），那我們不指望在DB中找到交易。這可以被用于負面測試以擴大代碼覆蓋。
回到我們的例子中，另一個過程可能是“用戶退款”（在這里，例如，我們想用負數金額重復（a））等等。 驗證應該在后用任一電子表格（Excel，Zoho）或是像MySQL Workbench的免費SQL工具通過點擊完成。從這個意義上來說Excel非常方便，它不需要專業知識，并具有不受規范限制的比較工具。關于這個我將在下一節做簡要探討。
總結一下這種方法：
1. 做小測試用例。
2. 把它們一起放入10 TC過程。
3. 把過程一起放入一個測試集。
4. 后進行驗證。
自上而下的數據驗證法
這種方法與我們所知道的經典的STP設計完全不同。它對功能測試和根本原因分析都有用。它可以被視作是我們所知道的黑盒測試，并在兩個重要概念上不同于以往的設計：
1. 數據只在圖像中。因此，我們通常會把這個用作測試周期的第二層，用于bug和問題的根本原因分析。
2. 如果先前的方法里我們試圖把測試計劃打破成一個個小流程，那么在這里，我們依靠產品規格、領域知識和很多常識，創造性地創建系統的不同用例之間的依賴關系。例如，對比之前的設計中的退款模塊，讓我們回憶一下我們的交易模塊，。
在那種設計中，我們不得不考慮一個交易，一個我們不得不事先用我們應用于退款和驗證的宏命令建立的交易。
現在的方法中，我們將使用電子表格/ SQL來獲取DB中的所有退款行，將它們連到它們的父事務，并根據產品規格（金額，原因等）驗證不同的數據字段。這種方法是很強大的，往往能揭示產品需求和架構中的問題。
對于負面測試，我們有一個穩贏策略。例如，發現一筆交易里用戶沒有注冊網站（例如，用戶的電子郵件未被記錄）。根本原因分析中，我們能夠直接從DB生成一個執行流–即什么導致失敗，并使用簡單的排序、篩選和條件格式作為Excel不受規范限制的分析工具去評估他們的IF-AND-OR-NOT依賴關系。
這種方法對于使用Excel數據驗證功能來執行簡單的驗證（如無前/后間隔，減少/增加/恰好n位場/十進制值溢出，日期范圍限制等）的簡單現場驗證來說也是很經典的。
自動化與回歸
正如前面提到的，數據驗證對自動化而言很容易。
對于迅速回歸，我們會選擇第二種方法，即根據一個預定義的基線驗證DB數據。
例如對于我們的購物網站，我們將有一組預定義的會產生一個數據集的一系列操作。
我們可以輸出DB到電子表格或上傳基線到MySQL并點擊/查詢以便比較兩個表格。
Excel的VLOOKUP在帶來兩個表間的差異上表現出色，SQL通過采用兩表間簡單的左連接點帶來差異。
總結
如前所述，數據驗證在取代傳統的功能測試和根本原因分析中非常有效。可以用簡單，低成本的方法通過把它的繼承邏輯結構擴展到被明確標示為通過/不通過的功能測試用例來進行數據驗證。使用數據驗證而非傳統功能測試可以通過把產品規格轉化為明確清晰的數據架構內的邏輯關系使編譯出更好的測試用例更容易。
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://m.eqie.com.cn/news/html/2014410134916.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
