性能测试自我总结 ZT

性能测试不同于功能测试，这不仅体现在测试关注点上，更体现在测试方法，环境配置等多方面。

做性能测试时，普遍需要注意以下几个方面：

1。首先做性能测试前，必须跟开发人员确认测试的目的（关注点），由于测试人员对整个系统的
设计不够熟悉，所以很难定位哪些地方容易出现瓶颈，需要关注，哪些地方即使压力再大，也不会
出现问题。（在现在市场的大趋势下，不可能有充足的时间对系统的每个角落都关注，所以性能测试
肯定有关注点，不可能都测。）
    性能关注点有几个层次， 应用层的业务逻辑，服务器方面，数据库方面。但开发人员关注最多的
    还是业务逻辑和数据库（表结构的设计）方面。

2。 性能测试前，还得知道数据量的范围（包括数据的数量，数据的复杂度等），这便是具体的“压力”
来源的一部分，具体的数据量是多少，怎样的一个层次（如1000条，然后10000条，然后100000条），
这都需要与开发人员协商。

3。 并发量， 这一点不仅需要开发人员的建议，也得征求需求人员的建议，具体在真实环境下可能的并发量
谁也说不准，只有靠估计，并发量越接近真实环境，测出的性能就越真实。

4。测试环境，性能测试与功能测试不同，对硬件要求非常高，我们测软件性能前，必须先保证硬件性能，如果
连硬件性能都有问题，软件性能根本测不准。这一点也是与开发人员讨论的重点之一 。

5。数据产生的脚本（可以是一个SQL脚本，也可能会是其他脚本，具体项目具体分析），个人感觉这一部分最难
与开发人员协商，双方都认为这是对方的责任。但，就我个人观点，这还是应该开发人员提供，一来测试人员对
系统设计不熟悉，二来开发人员毕竟熟悉语言，写代码肯定更效率，所以感觉应该他们提供才是。

6。测试方案（整个测试过程分几个层次），这个关系到是否能找到瓶颈的问题，好的测试方案更容易找到。举个例子，
拿公交车说吧，先总是一人在公交车上，测公交车的启动，转弯，刹车的性能，如果一个人在上面都有问题，之后就不用
测了，如一个人没问题，人数增加到10人，异词类推。个人感觉这其实就是数学里的排除法的应用。

7。还有个重点一定要和开发人员沟通，那就是测试指标问题，如响应时间，CPU，内存占用率在什么范围内属于好，什么范围内
属于正常，超出什么范围，属于差。不过实际工作中，问开发人员要这类数据也很难，尤其是第一次做性能测试，以前没有数据
供参考的。

8。最后一个么，就是测试工具的问题，性能测试不比功能测试，可以手动，性能测试无法手动，只有借助工具来完成的，具体情况具体分析。


9。我漏说一个，采用的测试策略也得分析一下，如做压力测试，容量测试，还是需要有其他的种类，也得让开发人员确认一下，这
具体取决于开发人员想得到什么数据了。