性能测试之数据准备  《转载》

不知道大家在做性能测试的时候，测试数据是如何准备的，笔者在实际工作中发现测试数据的准备会遇到以下几个问题：

　　其一，由于性能测试需要具备一定的并发量，尤其在实际系统所能承受最大并发量未知的情况下，测试数据的量也必须满足预期业务并发量的一个量的需求，如何准备这些量的数据是第一个问题；

　　其二，除了量的需求，数据也必须是符合业务逻辑的，是可用或者可测试用的数据，不是脏数据或无效数据。比如表与表之间是具备一定的关联关系，记录之间也有关联关系，所有的测试数据要符合这些规则，如何完全了解掌握这些规则，并且根据规则来生成测试数据是第二个问题；

　　其三，性能测试往往是安排在功能测试完成之后，在项目进度非常紧张的情况下，时间资源甚至是人力资源非常有限的情况下，如何快速掌握业务，准备有效的并且符合量的需求的测试数据是一个比较大的挑战。

　　针对以上问题，笔者工作中用到以下几种数据准备的方法：

　　一是用SQL脚本方式，插入测试数据，但是有几个前提条件，首先需要对该业务下所有关联的表结构非常熟悉，其次对整个业务也需要非常熟悉，而这些条件只有开发或者功能测试人员会具备。在以这种方式准备数据的时候，需要密切与开发或者功能测试人员进行沟通了解学习，并且在信息来源不全的情况，需要不断尝试，不断调试才能够准备出符合要求的测试数据。但是仍然会存在风险，即便数据准备完毕，也不能完全确保这些数据是真正合法的，可能这些数据符合被测业务的需求，但是却不符合其他业务或者实际生产环境的需求，也就是说不能完全代表真实数据；并且也存在遗漏其他数据但是业务却跑通的情况。通常情况下，SQL脚本批量导入数据的方式仍然是非常直接有效的方法，比较灵活，量和业务需求都是可控的；缺点就是需要搞清表间关系，精通业务流程，脚本也需要经常维护。

　　二是通过业务的方式去产生测试数据，当然不是手工去一个一个添加，如果量很大，势必需要依靠自动化工具来实现。这种情况下，测试人员只需要了解业务的操作流程，然后采用自动化工具比如LoadRunner，QTP之类就能通过业务大量生成数据，这样的数据一般都是合法可用的，能够确保之后的性能测试的质量。然而缺点也很明显，需要开发额外的测试脚本，要花费额外的时间和人力。

　　三是直接采用生产数据，在有现成数据并且数据保密性要求不高的情况下，可以采用这种方法，毕竟生产数据是原原本本的用户行为所产生的数据。但是有这样几个缺点，量不可能控，可能某些业务的数据量少了，不符合性能测试的需求；生产数据也会有脏数据的产生，会因为系统架构的调整，表结构的变化等等诸多因素产生脏数据，而这些数据是不具备业务意义的；多数情况下，生产数据一般不会被用于测试。

　　在没有开发的支持下，第一种方法会略显困难，但第一种方法也是非常直接有效的。

　　最后讲一下，我所设想的最后一种方法，可以节省很多时间和精力，从而把重点放在性能的调优上。在性能测试的初期分析阶段，可以先确立被测的模块，尽量缩小模块的范围，针对这个小模块的业务来准备数据，让开发配合去掉不必要的业务限制，比如说验证码、资格码之类就用相同的码就能验证通过，尽量减少数据之间的关联和限制。这样在准备数据的时候就非常轻松，可能只是简单的插入操作而已。从而把主要的精力放在了性能调优或者用户模型以及场景的设计上。

　　如果各位看客有自己的想法或者经验，非常欢迎畅所欲言，感激不尽！