项目上线前夕，测试人手不够，我们开发过去帮忙。我跑一个test case，跑了一个多星期！你信不信？我的问题就在于测试的这个数据做不出来。测试文档是一步步写清楚了的，但你这样做不下去：权限不够、数据已有变化、文档模糊……到处找人问。找到懂这事的人，中途又发现，程序（页面）发生了更改，有些功能跑不起来……最后一个workaround，得改数据库，数据库又得找DBA啊……总之，这个test case搞得鸡飞狗跳，好在最后还是跑出来了——但以后（下一次）怎么办， 我就不知道了。
本质上，这种做法，测试数据是要测试人员自己“做”，或者“找”的，有很多问题。所以，从那时开始，我就在想：能不能把测试用的数据“固化”下来？让测试人员就基本上不用“做”，或者很方便的就能“找”打测试数据。比如：“用户名不能重复”的文档就直接写成：
最多加一个说明：test-1112是已有用户名，用户名不能重复。
这个诱惑一直吸引着我，最后我在solution中就引入了一个BuildDatatase项目，专门为开发测试准备数据。毫无疑问，这个决定也遭到了开发人员的抵制。因为这个数据也不是那么好做的，具体我们将在项目详解里谈。
我铁腕推行，大概经过了两件事，他们慢慢的就习惯/认同了这种做法。
第一件事，是任务列表页面。开发代码之前是写好了的，而且已经跑了一段时间了。我让他为该页面重新创建测试数据，他一脸不可置信：这种筛选排序，天？要准备多少数据？！怎么准备？代码都写好了，跑得好好的，有必要吗？
我让他先冷静一下。然后有以下对话：
“如果你不准备这些数据，你怎么保证你代码的正确性？”我问。
“就直接在页面上建几个任务啊，然后跑一下。”他想了想。
“要建几个呢？”我继续追问。
“……”，他一时答不出来。
“随便做几个数据，随便的跑一跑，然后就不管了，是吧？你以前就是这样做的？”，我接着说，“所以我们的代码没有质量。然后如果没有专门的测试呢，就让用户当免费测试员；有测试呢，我们就把这些脏活累活扔给他们。他们一遍遍的报bug跑不过，我们还不服气还有怨气……为什么我们不一开始就把它做好呢？”
首先确定要做，然后再想办法！很快我们就想到了一个办法，反过来做：满足所有筛选条件的任务就一条，然后逐个的减少筛选条件，每少一个筛选条件，就增加一个适格任务。这样理下来，共计25条数据就够了，并没有我们想象的多。从构思到文档再到最后“造”完所有任务，差不多花了一个下午的时间而已。最后，戏剧性的是：出效果了！跑一遍，我们立马发现了代码里面的两个bug。因为这种query查询写代码的时候都“复制粘贴”的，十几个条件，难免出错。如果不是这样跑一次，这些bug不知道什么时候能冒出来——因为我们自己用的筛选条件比较固定的，某些筛选条件从来没用过。所以我问他：你之前说“跑得好好的”？他只能呵呵了。
第二件事，是在任务编辑页面，我们要测试父子任务关系之间的自动化功能，这就需要比较复杂的一个“任务树”做开发测试数据，好在我们是做了的。代码review的时候，我在我这边一跑，不对，就直接打回去了；过了一会，他跑过来，代码没问题啊？当时我们脑子都短路，没想到其他，就先去看代码去了，折腾了好久。在他电脑上跑，然后又在我电脑上跑，又是设断点，又是看逻辑。
后来我突然灵光一闪，“是不是数据的问题？”
“嗯，有可能。但怎么确定呢？”
“你重新BuildDatabase再跑！”
果不其然，原来他自己跑的时候改动了数据，然后就忘了呀，一直就在已变动的数据上跑，当然没问题了。亏得我们有BuildDatabase，可以随时重建“基准”数据，否则，这种问题是相当花冤枉时间的！
这类似的情况其实很多很多，测试人员报bug之后，我估计开发人员最常用的一句台词就是：“我这里都能跑啊？！”所以问题80%都出在数据上——那为什么我们的数据就不能规范统一起来呢？
通过BuildDatabase，建立一个有序的可控的数据库，我们才能够在此基础上进行一系列的（测试驱动的）文档编写、开发和测试活动。所以说，BuildDatabase是“测试驱动”的基石和保障。除此以外，BuildDatabase还可以在项目发布、模拟展示等方面发挥重要作用。
（我以前公司的集成测试环境这些，数据库都是从生产环境中copy或截取的，我们需要的数据都是“自己造”，或者“自己找”的。这样做能基本满足开发测试需要，但中间总是很容易“出篓子”——正如我前面所说，一个test case可以跑一周。而且随着数据增加，这个copy也越来越难啊，一次导几百个G终究很累，所以好像是到了一定时候，还是得自行维护测试数据库——但维护主要是数据结构上的，比如增减列之类的，数据本身是无法维护的。
我很好奇，除了我的builddatabase以外，有没有其他比较可行的办法？欢迎大家踊跃交流！）
相关文章
精彩导读
热门资讯
关注我们
