摘自【http://www.51testing.com/html/10/n-843410-3.html】
Q4、性能测试有哪些类型
● 基准测试
比如单用户的测试或者在无数据条件下的测试，目的是提供一个标准供后续测试比对。
● 负载测试
向系统施加一定的压力，一般最大压力的20％或者日常使用压力即可，确保系统可正常运转。
● 压力测试
向系统施加预期最大压力，测试系统在繁忙状态下的性能表现。
● 容量测试
不断的增大对系统的压力，直至出现瓶颈。用于探测系统的瓶颈，为系统的发展提供重要信息。
● 稳定性测试
长时间运行的稳定情况。
还有很多其他类型的测试，这里只是列出了几种最常用到的，术语的定义可能也和其他资料有些差别，比如负载和压力，不过无关紧要。
这里需要注意的一点，在负载、压力和容量测试中，测试的依据都是用户模型，只有用户模型准确，测试的结果才会有意义。
稳定性测试需要运行多长时间？
之所以会有这个疑问，其实是因为测试人员提供的结果数据没有说服力，不是证明了系统可以长期稳定运行，而只是下了个系统稳定的结论。
我也总和性能测试人员强调，测试的结果是要用数据来证明的，不是说测完了下一个通过的结论就可以了，这样自然要被测试经理、开发经理怀疑（尤其是你是一个新人）。
如果能够提供各种详尽的数据，比如测试运行12小时内，操作系统的资源利用情况、应用中间件内部的资源利用情况、甚至是程序内部的一些性能指标等等，如果这些指标足够代表系统的性能，且它们的表现是非常平稳的，那么完全可以从这个趋势推断出，即使系统运行更长的时间也将是稳定的。
反之，如果不提供数据，而只是描述测试运行了3天，那么自然会有“3天够不够长”的疑问，只有通过“足够长”的运行时间才能减少人们的顾虑。
Q7、性能测试（不）能做什么
web系统性能测试
最常见的目的是模拟用户的实际行为，获取用户的感受。
如何模拟用户的实际行为
建立用户模型。即用户做什么操作、操作路径是什么、操作频率……
如何建立用户模型
● 常用业务
● 性能敏感业务
● 关键业务
● 特殊关注
这里只是用户模型覆盖度的问题，实际使用的用户模型还需要很多其他信息才能建立起来。
测试负责人需要重点关注和确认用户模型的建立。
性能测试的覆盖率
由上可知，性能测试只能覆盖系统的一部分功能。不要指望所有和性能相关的问题都由性能测试来发现。
性能测试最最想发现的是瓶颈，而不是缺陷。
我比较害怕听到这样的话，“生产环境的一个操作很慢，去做下性能测试吧”。
Q8、如何检验性能测试的质量
执行过程
● 建立执行规范
明确定义执行过程各检查点需要的输出物
● 指派检查人员
根据执行规范进行检查
● 输出执行记录
测试人员都知道，设计的用例和实际的执行总是不一样的。性能测试更是如此，调整参数重新运行脚本也是一次执行，这些信息必须有清晰的记录。
● 持续交互确认