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

  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