关于性能测试的个人经验

关于性能测试的个人经验

1、性能测试用例的执行策略

做过功能测试的人都知道，用例都有一个广度覆盖和深度覆盖之说，所以我们就有了大量的用例设计方法的支撑。比如：等价类，边界值，正交表诸如此类。那么我们在设计和执行性能测试用例的时候是不是也要做到这样呢?比如：我做负载测试，我需要做500、501、499这样的三种虚拟用户加载的测试场景吗?答案显然是没有必要的。

在此，我们可以一开始选择一个较大的数值。例如：直接选择500，进行场景的虚拟用户的设置，在场景的执行过程中查看系统的性能指标是否符合用户的性能需求(做负载测试的情况下)，如果此时，系统的性能指标是符合用户既定的性能需求的，那么我们可以适当的增加用户，比如增加到600，那么同样，监测其状态下相应的性能指标。若超出用户所能接受的性能需求，则大致可设定550的一个用户数再次执行场景。从很大程度上避免了相应的性能测试用例的一个冗余，一定程度上的提高了我们用例的执行效率。

2、同样的脚本，同样的场景，执行完之后结果不一样。

我们都知道，性能测试在很大程度上与我们的环境是相关的，在环境。如：操作系统，相关的硬件设施，同样的操作系统，硬件设置但启动的服务不同从而导致内部环境不同的情况下。那么我们执行同样的脚本，同样的场景得出的结果肯定是有差异的。

3、缓慢加压的策略

前面提到了性能测试的相关用例数据的选取和执行策略，这里我再来总结下自己在此次中的一个加压策略。我们选定了相关的用户数之后，如何去设定相关的场景呢?换言之也就是我们的加压策略是什么呢?

这个时候我们需要后台日志的支撑，帮助我们去分析。从日志中分析出一天的哪个时间段在线用户数最多，哪个时间段我们的在线用户数最少，从而设定出我们的场景执行策略。例如：从我们的后台日志分析得出，上午9：00～11：30这一时间段系统的在线用户数最多，为整个数值的80%，那么我们在设定场景执行的策略的时候，我们就需要在这一时间段加载完成系统总日使用人数的80%，使其80%的在线用户数在该时间段对系统产生负载。

4、性能测试用例如何设计?

这个玩意我个人认为是整个测试界一直在讨论的一个话题，这个话题就是“用例的设计粒度该多细”的问题。上次跟HP的测试部两位主管也谈到这个问题，HP在很大(应该说很多公司)程度上重视这个UAT，只要用户接受了系统，那么这个就是个好系统。呵呵那么换言之，我认为还是对被测系统所属行业的业务了解，再结合我们的加压策略分析，从而设计出比较合宜的测试用例。

5、报告的实质性

最后我谈下对于性能测试报告的一个理解。自己之前也看过一些性能测试报告，除了N多的设计的场景是怎么样的一个阐述，剩下的就是最终执行之后是一个什么状态的数字反映。但其实性能测试报告最需要体现的就是，在这样的环境下，这样的场景，那么我们的系统的支持还是不支持。