显而易见，QA测试是指在对应的场景下测试业务规则。在最坏的情况下，用户可以手动生成测试用例，以确保规则产生正确的结果。话虽如此，使用具有预期结果的测试用例会更有效率。对于Joe的申请来说，你知道Joe会在某些条款下被批准。你现在可以自动执行规则，并检查它们是否与预期结果相匹配。

如果你有数周或数月的历史交易数据用来测试的话，会很理想。你拥有的交易数据越多，你的测试就能覆盖越全面。尽管在收集和准备数据方面会有一些投入，但获得的收益是显著的。

但是，如果你现在还没有任何数据，也不要放弃。你可以手动生成数据，也可以使用Mockaroo等工具生成数据。我们的许多客户都喜欢尽可能利用Excel，他们只需复制一个测试用例并为每个相关属性（年龄，状态......）创建一些数据。与拥有历史数据的幸运者不同，你必须思考一下你期望的结果。虽然它增加了一些工作量，但是这些黄金测试用例可以保存以供将来使用，并且重复利用于测试决策逻辑中的每一次变化。

这部分实际上倒是微不足道的。上传数据后，你只需添加一个计算，将实际交易状态与预期状态进行比较。 你有几个选择。 你可以创建：

· 对于你的决策的每个输出结果，都有一个单独的QA标志

· 对于你的决策的每个输出结果，都有一个单独的QA标志，另外还有一个检查所有单独标志是否良好的全局标志

· QA标志仅用于你要确认一组的字段，然后同样有一个用于检查所有单独标志是否良好的全局标志

无论你有多少QA标志，你现在已经准备好让魔法发生。为你的QA标志创建一个报告，你会立刻获得满意，因为图表会告诉你有多少差异。

在我的项目中，我喜欢创建过滤器，专门关注“坏样本”测试用例。 它不会查看完整的数据集，而只会显示未通过QA测试的数据集。 在有些情况下，我在审核测试用例后会修复规则。 而在有些情况下，我会修改测试用例本身。 你会惊讶地发现在很多时候，测试数据不会像期待的那么完美。

一旦完成修改，就可以继续进行下一个“坏样本”的测试用例，直到我们结束。QA测试从未如此简单！

使用数据工作的好处在于你可以专注于实际的交易。如果你正在查看可能不是你亲自编写的旧规则，我强烈建议你使用RedPen。 这将帮助您通过将规则（或测试用例）叠加在一起来帮助您查明规则（或测试用例）中的问题。 你可以查看规则所执行的测试对应的数据。 你可以看到规则中的哪个语句是正确的，哪个不是。 对于大体量的模型来说，可以节省很多时间。

你可以看到我开始激动起来了。 我向你保证，我对QA测试不是一窍不通的。虽然我喜欢编写规则而不是测试，但是使用RedPen和仪表板，这种不同的测试方法改变了我的观点。 我真的很喜欢用这套工具去探究规则。我敢说，利用这些工具来工作，几乎是一种乐趣！