性能测试新手误区

作者：薛定谔的破猫发布时间：[ 2012/6/13 9:32:02 ] 推荐标签：

性能测试新手误区（一）：找不到测试点，不知为何而测

有过一些性能测试经验的人很容易进入此状态，他们已经熟悉了性能测试的基本流程，能够比较熟练的使用测试工具开展工作。我大概从事性能测试一年左右时遇到了这个问题，那时我觉得性能测试的过程没有太多挑战，遇到的每一个系统，仿佛都可以用同样的流程完成。半天时间填写测试方案，时间来准备测试环境，时间准备测试脚本，一到两天来完成各种测试用例（基准测试、日常压力测试、峰值压力测试、并发测试、稳定性测试等），然后是调优、问题复测和完成测试报告。在我看来，性能测试好像变成了用一些工具去执行一个个固定的用例。

这样的工作持续了一段时间后，我感到有些不对劲，一定是哪里出了问题。性能测试难道真的这么简单，简单到把任何一个系统套入标准的流程中可以了？于是我开始思考测试的意义，为什么要进行性能测试？是因为性能测试可以提供关于瓶颈、缺陷、效率等等我们认为有价值的信息。那仅仅通过一个工具，或者是一个固定的流程，可以发现不同系统的这些信息么？这显然是不可能的。

我开始尝试尽量深入的去理解被测系统，这个系统的目的是什么，用户是如何使用系统的，用户对哪些业务的性能比较敏感，系统的一些关键业务实现逻辑是怎么样的，从设计实现的角度来看哪些业务的性能可能存在隐患。这些很少是技术层面上的问题，需要做的只是思考，再深入思考。慢慢的我有了些收获，开始了解为什么要测这个系统，针对这个特定的系统哪些内容是重要的，为了获得需要的信息我需要从哪几个方面进行测试，为了实现我的想法又需要哪几种方法或者工具。（现在我的性能测试过程中，用于理解被测系统、理解用户、整理测试思路的时间投入大大增加了。你呢，投入了多大比例？）

要做好这些其实很难，每一个被测系统对我来说，仿佛变成了一个新的挑战。但是逐渐的我发现自己思考问题更全面了、可以更快的抓住系统的重点、找到更重要的BUG、对系统的实际性能有了更准确的评估。这里提一个简单的问题，如何确保你的测试结果和生产环境的性能表现是一致的，也是说测试结果能够真正的反应实际的性能，而不仅仅是代表了你选取的几个测试场景的性能。话说起来比较绕，但是请认真想一想，你有多大的把握呢？

上面只是写了一些个人的感想，我觉得如果在“思想”上没有办法上到一个新的台阶，你的性能测试生涯可能也达到“瓶颈”了。如何突破这个瓶颈，那需要努力改变自身，多思考多学习，核心的能力恐怕不是能培训出来的。一定会有一些人认为性能测试的重点在于“技术”上，于是他们不断的记住各种调优配置参数，以为自己掌握了性能的精髓，仿佛什么系统到了他们手上，只要改几个参数会出现奇迹。我也经历了这个阶段，也有过几次自以为挺高明的调优经历，也为自己会各种中间件数据库的配置调优而有些小得意。但现在想想，那还真是一个比较低的层次，思想上抓不住重点、看不全大局，技术上其实也只是一点皮毛。面对这类人，只要问几个为什么会让他们无法回答，为什么要调优？为什么要调这个参数？如何证明这次调整的效果？

将上文简单的总结成几点，希望能给性能测试新手提供一丁点的帮助吧

性能测试的难点在于对被测系统的理解，在于对测试点的分析。为了实现测试的思想，可以有多种方法，手段永远只是辅助的，只有思想才是根本的。工具（如LR）更不等于性能测试，不要以为会用LR懂了性能测试，那只是低级的测试执行。也不要以为会调几个参数懂了性能测试，那同样是个比较低的层次。

调优等技术不是性能测试的主要目的，好的性能也不是调出来的。测试人员一定要明白自己存在的价值所在，所谓的“技术”只是为了达成自己测试目的的一些手段，同开发人员、DBA相比，你在这些技术上永远是外行。

不要照着文档模板，填入测试方案。每一个系统都是不同的，要真正的认识到这一点，为每个系统设计出有针对性的测试方案。思考你每一步工作的意义和目的。

如何证明测试结果的有效性，其实是个很难的问题，值得花费时间去认真思考。这个过程涉及到一些很重要的内容，如用户模型的建立，后续会有专门的文章。

性能测试是一个需要不断改进的过程，每一次只需尽量的做到更好，多做一点点以前没有想到的东西。经过不断的积累，你会发现自己对性能测试有了更深的认识。

性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？

测试环境的重要性无需多说，大家都知道测试环境要尽量的模拟生产环境，当然也包括数据。这样测试的结果才会更加准确的反应真实的性能。连开发过程，都已经开始在大数据量下加压开发了。那么，关于测试数据，你了解多少呢？

通常说的测试数据可以分为两类：

一是为了测试性能而准备的数据，这是用来模拟“压力”的数据。也是常说的数据量、历史数据等。一般都会根据需求或者经验很容易估算出来，比如案件年增长量为5%，去年数据量为100W，测试需要保证3年后系统仍可正常运行，那么需要计算并模拟出3年后的总数据量，在这个基础上进行测试。
二是用来辅助测试使用的数据。比如有一个对案件进行打分的功能，只有符合一定条件的案件才会出现在打分列表中。那么我们要测这个打分的操作，首先要保证有可用的案件，这需要去生成测试数据，该数据可能一经使用失效了（已经打过分不能再打了）。这样，每次测试这个功能，需要准备这样一批数据。这里的测试数据，更多的是和测试流程有关，是为了能够正常的进行测试，而不是涉及到性能的。

我们这里要说的是第一类，对性能测试结果产生直接影响的数据。

先看两个小案例，涉及到了案件表（T_AJ）和法院编号列（N_FY）、立案日期列（D_LARQ）。案件表中模拟了一百万测试数据，测试简单的查询操作，根据经验，预期响应时间在2秒之内。

案例1. 查询本院案件列表，相应的SQL如下：

select * from T_AJ

where N_FY=10

order by D_LARQ desc

执行这个操作耗时近10s，显然达不到正常预期。

经排查，生成的100W测试数据中，所有的N_FY列值都为10。这样，明显的问题是，查询的结果集数量完全偏离了正常范围。如果实际有100家法院，正常分布下，每家法院只有1W的案件，但测试数据的FY只有一个值，通过这个查询，查出了原来100家法院的数据。无论是在数据库处理中（如本例的排序），还是在程序的处理中（如展现或者是对数据做进一步处理），两者的性能差异都是很显著的。所以这个测试结果是无效的。

有人说，这个例子太弱了，结果集差了100倍，性能当然不一样了。那是不是数据总量和结果集大小都一致，测试结果是有效了呢？

案例2. 查询本院一个月内收的案件，相应SQL如下：

select * from T_AJ

where N_FY=10 and D_LARQ between ‘20110101‘ and ‘20110201‘

这个操作，查出来的结果只有一千条数据，属于正常范围。但查询的时间还是超过5秒，依然超出了我们的预期。

查看数据发现，N_FY=10的数据有近50万，占了总数据量的一半，D_LARQ在一月份的数据也占了差不多一半。但是同时符合两个条件的数据还是一千条左右。那么这里的问题不在于结果集了，而是是否能利用索引进行查询，看如下两个图能很好理解了。

在正常数据中，每家法院的数据可能占总数据量的1％，一个月时间段内的数据可能占总数据量更少，假设是0.5％。那么这时我们通过N_FY和D_LARQ两个条件进行查询，数据库会进行估算：符合D_LARQ查询条件的数据大概有5000条，符合N_FY查询条件的数据大概有1万条，那么用D_LARQ上的索引进行查询是快的，可以迅速的将查询范围缩小到5000条，然后在这5000条中去检查N_FY是否也符合条件。

过程如图一所示（手绘草图^_^）。