在一个数据不断增长的世界，软件测试涉及不同的数据验证程序，这些程序是传统质量保证方法的一个组成部分。本文旨在为非数据人员提供数据验证工具，同时也为回归测试和功能测试提供更多自动且迅速的工具和测试策略。
本文中，我将详细介绍数据验证的两种方法：自下而上法和自上而下法。这两种方法在不同的应用程序和测试策略中已实现的数据中所起的作用是不一样的。
自下而上方法中，应用程序是代理器，而数据是反应器。我们通常使用此方法对新功能进行功能测试或把它与自上而下结合方法以覆盖大量代码。
另一方面自上而下法中，数据只在画面里，我们根据外部知识判断关于数据模式内关系的猜想是真还是假。
后一种方法使我们能够设计出成本低但功能强大的回归测试集以及根本原因分析法。
介绍
数据无所不在。它已不再是某些较高等级的应用程序的附带品，而被视为是有价值的、脆弱的。在信息论中，数据是信息抽象化即知识的最低水平。这意味着我们要有一个专家把行业知识原则又称产品需求和产品规格转化为一个一致的数据模式。
这实际上解决了这一行中一直以来的一个困境：产品经理和产品架构师对产品规格的见解不一。
事实上，数据的既定逻辑结构及评估它的明确结果可以把一个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通过采用两表间简单的左连接点带来差异。
总结
如前所述，数据验证在取代传统的功能测试和根本原因分析中非常有效。可以用简单，低成本的方法通过把它的继承逻辑结构扩展到被明确标示为通过/不通过的功能测试用例来进行数据验证。使用数据验证而非传统功能测试可以通过把产品规格转化为明确清晰的数据架构内的逻辑关系使编译出更好的测试用例更容易。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |