前段时间做了一个性能测试的小项目，自己总结了些个人经验，放于此处，便于以后回归学习和分析：

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

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

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

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

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

　　3、缓慢加压的策略

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

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

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

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

　　5、报告的实质性

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

　　一、数据

　　二、环境

　　三、场景

　　四、这样的环境下，用这样的数据执行这样的场景系统是支持还是不支持。

版权声明：本文出自yzylion的51Testing软件测试博客：http://www.51testing.com/?206966