写数据库测试工具的一点心得

概述

写一个好用，持续可用的测试工具，需要满足如下几个特征：

完备、封闭

自调度

结果可评价

易回归

完备、封闭

case 所需要的数据都来自测试工具本身，不需要外部人工准备。例如做一个大查询测试工具，大查询的数据应该由工具本身插入。

违反这个要求时，部署测试就会十分麻烦，容易出错。

自调度

一个复杂的测试可能需要多个逻辑相关的先后步骤，例如：准备数据阶段、A测试阶段、B测试阶段、校验结果阶段、清理环境阶段，其中，准备数据阶段、B测试阶段还会并行执行。这样一个先后顺序，不应该依赖外部人工帮助调度，必须测试工具自身控制调度顺序。

违反这个要求，由外部工具来做调度，调度顺序很难保证。

结果可评价

就算是随机测试，或者纯粹的压力测试，结果也必须是可评价的。评价的粒度、角度可以不同，但指标必须明确定义。例如，常见指标包括：数据正确，结果正确，没有 core，没有 ERROR 日志，性能符合预期，测试程序可终止，测试过程中无异常，中间状态符合预期，等等。

这个要求看起来很自然，但在实践中会遇到很多问题，需要努力去逐一解决。例如，RandomQueryGenerator（RQG） 测试结果对比中，AB两个系统本就在某些地方不完全兼容，结果必然不等，但这种不等是符合预期的，评价测试的时候就需要将这种情况过滤出来；再比如，测试程序不够健壮导致测试结果难以评价；再比如，测试系统热点，怎样才算遇到了热点，遇到热点后的表现是怎样的，如何程序量化？

个人认为，结果可评价，是设计数据库测试工具中最难的。

易回归

自动回归是测试的灵魂，任何一个测试系统都必须具备可自动回归的特征。回归成本越低，可能创造的价值越高。上面第一点、第二点特征，很大程度上都是为 “易回归”服务的。如果不需要回归，手工完成准备数据，调度 case 的步骤，也未尝不可。