|
性能测试总结:
性能测试不同于功能测试,这不仅体现在测试关注点上,更体现在测试方法,环境配置等多方面。
做性能测试时,普遍需要注意以下几个方面:
1。首先做性能测试前,必须跟开发人员确认测试的目的(关注点),由于测试人员对整个系统的
设计不够熟悉,所以很难定位哪些地方容易出现瓶颈,需要关注,哪些地方即使压力再大,也不会
出现问题。(在现在市场的大趋势下,不可能有充足的时间对系统的每个角落都关注,所以性能测试
肯定有关注点,不可能都测。)
性能关注点有几个层次, 应用层的业务逻辑,服务器方面,数据库方面。但开发人员关注最多的
还是业务逻辑和数据库(表结构的设计)方面。
2。 性能测试前,还得知道数据量的范围(包括数据的数量,数据的复杂度等),这便是具体的“压力”
来源的一部分,具体的数据量是多少,怎样的一个层次(如1000条,然后10000条,然后100000条),
这都需要与开发人员协商。
3。 并发量, 这一点不仅需要开发人员的建议,也得征求需求人员的建议,具体在真实环境下可能的并发量
谁也说不准,只有靠估计,并发量越接近真实环境,测出的性能就越真实。
4。测试环境,性能测试与功能测试不同,对硬件要求非常高,我们测软件性能前,必须先保证硬件性能,如果
连硬件性能都有问题,软件性能根本测不准。这一点也是与开发人员讨论的重点之一 。
5。数据产生的脚本(可以是一个SQL脚本,也可能会是其他脚本,具体项目具体分析),个人感觉这一部分最难
与开发人员协商,双方都认为这是对方的责任。但,就我个人观点,这还是应该开发人员提供,一来测试人员对
系统设计不熟悉,二来开发人员毕竟熟悉语言,写代码肯定更效率,所以感觉应该他们提供才是。
6。测试方案(整个测试过程分几个层次),这个关系到是否能找到瓶颈的问题,好的测试方案更容易找到。举个例子,
拿公交车说吧,先总是一人在公交车上,测公交车的启动,转弯,刹车的性能,如果一个人在上面都有问题,之后就不用
测了,如一个人没问题,人数增加到10人,异词类推。个人感觉这其实就是数学里的排除法的应用。
7。还有个重点一定要和开发人员沟通,那就是测试指标问题,如响应时间,CPU,内存占用率在什么范围内属于好,什么范围内
属于正常,超出什么范围,属于差。不过实际工作中,问开发人员要这类数据也很难,尤其是第一次做性能测试,以前没有数据
供参考的。
8。最后一个么,就是测试工具的问题,性能测试不比功能测试,可以手动,性能测试无法手动,只有借助工具来完成的,具体情况具体分析。
9。我漏说一个,采用的测试策略也得分析一下,如做压力测试,容量测试,还是需要有其他的种类,也得让开发人员确认一下,这
具体取决于开发人员想得到什么数据了。 |
|