Web 产品中，通常存在大量数据的引用，而这些数据都有其源头，所有的引用和延伸都是来自于数据的源头。利用一致性检查的思想，无论数据在 Web 产品的数据流中如何呈现、变化、处理，它的本源是要一致的。因此，我们可以通过在 Web 产品中找到数据的源头，并找到该数据直接或间接的引用，从而从各个角度去交叉验证该相同部分数据的一致性。这种多角度、多维度的一致性检查，将有力的保证 Web 产品的正确性。
一致性检查（Consistency Check）介绍通俗的讲，一致性检查是根据对同一事物、系统的观察，不管从哪一个角度，都应该保持一致性。利用该原理，一致性检查被广泛的应用于实验数据点的筛选过程。而在软件测试过程中，我们同样可以借鉴该原理。基本思路是：在软件产品中，数据的流动过程中应保持一致性。任何不一致的现象，都是我们需要去考察的点，看是否存在处理错误，是否存在产品缺陷。
下面举一个简单的示例来说明一致性检查的工作原理：
在某公司，2012 年，用户甲的税前月收入是 1.3 万元，每月实际到账流水金额为 0.95 万元，每月纳税 1600 元，每月公积金个人缴纳 1500 元。基于这样一组基础数据，某金融系统可以多个维度来获取和显示该数据：
维度 1：用户甲本人可以查询自己的月收入详单，包括以上所有数据，此为原始数据维度的直接呈现。
维度 2：用户甲可以查询自己 2012 年 12 个月税前总收入金额、总纳税额、公积金个人缴纳总额。
维度 3：用户甲可以查询自己公积金账户 2012 年 12 个月增加的总额（包括个人缴纳部分和单位缴纳部分：1500*12*2）。
维度 4：用户甲可以查询自己银行账户中 2012 年 12 个月总共实际收入总额，此为税后收入全年总额，也就是拿到手的钱。
该示例中，维度 1-4 可以在产品的不同页面和功能模块中实现和显示，但是必须保持严格的一致性。比如单月的公积金个人缴纳额 1500 元，与此对应的是每年个人缴纳公积金总额必须为 1500*12 元，同时全年公积金增加总额为 1500*12*2（含个人和单位缴纳部分）。如果这期间的数据出现不一致的情况，说明产品在处理过程中出现错误，必须改正，这也是本文希望发现的产品潜在问题所在。
源数据的追根溯源在 Web 产品的测试过程中，我们观测到一个数据显示，这时如果想实施一致性检查，我们首先需要定位该数据的源头，从而获取该数据的真实值。
举例来看，如下图 1 所示是我们 Web 产品中看到的一条报告，我们希望针对该报告开展一致性检查测试。因为我们事先知道该数据来源是大型机上的系统，我们可以通过 ISPF 接口访问该系统并获取其原始数据，如图 2 所示。
图 1. Web 产品报告实例 图 2. 实例报告源数据 源数据的间接引用现在我们有了当前网页的显示数据，以及源数据，我们可以开始对其进行验证。这里网页显示数据取自于源数据，但是对源数据进行了提炼和抽取。如下图 3 所示的是网页上显示的该报告其他属性值，与源数据对比我们可以看到相应数据是一致的。比如，数据库的名称在网页报告和源数据中均为 CUSTD1，满足一致性。这就验证了源数据的间接引用的一致性。
图 3. 源数据对比验证当前数据 |
