如何做性能测试之二

1 测算系统的性能指标
 1.1 综述
  测算系统的性能指标是其它性能测试的基础，因为无论任何测试目的，都必须通过某些性能指标来说明问题。
 1.2 测试方法
  测算系统的性能指标在做法上比较简单，关键是找到相应的计算公式，并根据这些公式确定所需要的原始数据，然后在测试实施中获得这些原始数据。
 1.3 术语
  测试时间：一轮测试从开始到结束所使用的时间
  并发线程数：测试时同时访问被测系统的线程数。注意，由于测试过程中，每个线程都是以尽可能快的速度发请求，与实际用户的使用有极大差别，所以，此数据不等同于实际使用时的并发用户数。
  每次时间间隔：测试线程发出一个请求，并得到被测系统的响应后，间隔多少时间发出下一次请求。
  平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
  处理能力：在某一特定环境下，系统处理请求的速度。
  cache影响系数：测试数据未必如实际使用时分散，cache在测试过程中会比实际使用时发挥更大作用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。
  用户习惯操作频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次数。通常以一天内某段固定的高峰使用时间来统计，如果一天内没有哪段时间是固定的高峰使用时间，则以一天的工作时间来统计。
  预期平均响应时间：用户实际使用时，系统将在多长时间内响应。注意，这个值并不是某一次访问的时间，而是一段时间多次访问后的平均值。
  最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就是实际可以同时使用系统的用户数。
 1.4 计算公式
  成功率＝成功次数÷（成功次数＋失败次数）
  处理能力＝成功次数÷测试时间
  最短平均响应时间＝MIN（平均响应时间）
  最高处理能力＝MAX（处理能力）×（1－cache影响系数）
  最大并发用户数＝（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高处理能力）））÷用户习惯操作频率，此公式要注意各时间单位的不同和转换
 1.5 测试过程
  1 设计方案
   见范例《范例1（web系统性能测试报告）.doc》。关键点是术语、计算公式、需收集的原始数据三部分
  2 测试实施
   根据成功、失败次数确定本组数据是否有效（成功率大于95%，成功次数大于20）
   根据成功、失败次数确定是否需要调整一组数据的测试时长
   根据数据的发散情况确定本组数据是否有效
   根据前后数据的对比确定本组数据是否有效（10%以内）
   根据前后数据的对比确定是否需要在同样情况下再次测试
   根据CPU占用率确定下一步的负荷
   ……
  3 数据分析
   基本上不需要分析，因为根据计算公式和测试实施中得到的原始数据，就可以直接得出所需要的性能指标
  4 测试报告
   见范例《范例1（web系统性能测试报告）.doc》。一般情况下，测试报告与测试方案基本一样，只是把测试出的原始数据和计算出的性能指标添加进去
 1.6 注意事项
  预期平均响应时间与最大并发用户数之间存在公式计算的关系，只有预先确定了其中之一，才能计算出另外一个
  除非在测试脚本中使用随机函数来模拟用户的访问，否则，测试脚本对被测系统的访问将存在一定的规律，从而导致平均响应时间与用户使用时出现较大差异。因此，一般都不可以把测试出的平均响应时间作为用户使用时的预期平均响应时间来对待

2 检验硬件配置能否满足客户要求
 2.1 综述
  客户在购买机器的前后，往往需要确定该机器是否满足其性能要求，这就需要进行这种目的的性能测试。由于提供给客户的配置方案基本上都是经过验证，或者根据以往经验能确定是没有问题的，所以要做的更多只是重复测算系统的性能指标，并形成一份测试报告交给客户。
 2.2 测试方法
  与测算系统的性能指标一样
 2.3 测试过程
  1 设计方案
   与测算系统的性能指标一样
  2 测试实施
   与测算系统的性能指标一样
  3 数据分析
   与测算系统的性能指标一样
  4 测试报告
   见范例《范例2（检验硬件配置能否满足客户要求）.doc》。报告的重点是说明系统在怎样的配置下能满足客户的要求，且给出数据来证明。由于测试报告是要交给客户看的，所以，测试报告的内容只需说明系统能满足客户要求即可，不需要写其它更多的东西。
 2.4 注意事项
  这里的整个过程和做法都类似于测算系统的性能指标，不同的只是最后形成的报告。

3 查找系统的性能瓶颈
 3.1 综述
  通常来说，在测算系统的性能指标之后，发现某些指标不满足要求，于是就要进一步去查找系统的哪部分是性能瓶颈，作为之后进行系统调优的基础。
  查找系统的性能瓶颈，一定是首先发现了系统存在性能问题，如果不能确定系统是否存在性能问题，那就应该只是测算系统的性能指标。
 3.2 测试方法
  由于已经确定了系统存在性能问题，所以，只需重复相同的软硬件配置，重复测试不能满足要求的性能指标，并在此过程中记录系统各部分的CPU占用率、物理内存、虚拟内存、磁盘IO等信息，有条件的还可以使用测试工具去统计各函数和方法的执行时间，综合分析出性能瓶颈的位置。
 3.3 测试过程
  1 设计方案
   见范例《范例3（查找系统的性能瓶颈）.doc》。
  2 测试实施
   与测算系统的性能指标的测试实施一样
  3 数据分析
   CPU占用率远大于其它部分的就是瓶颈，占用物理内存、虚拟内存远大于其它部分的可能是瓶颈，磁盘IO远多于其它部分的可能是瓶颈
   执行时间（不包含调用函数的时间）远多于其它部分的就是瓶颈
  4 测试报告
   见范例《范例3（查找系统的性能瓶颈）.doc》。报告的重点是判断性能瓶颈的依据和说明。
 3.4 注意事项
  如果没有发现明显的性能瓶颈，而系统的响应又经常超时，有可能是系统的并发处理机制出现问题，例如死锁

4 系统调优
 4.1 综述
  查找出系统的性能瓶颈后，下一步的工作就是系统调优（性能调优）。由于系统的性能是由软件和硬件两方面共同决定的，所以，系统调优分为软件调优和硬件调优。
  软件调优通常由开发人员完成，一般包括程序调优和数据库调优两方面。程序调优就是修改性能瓶颈部分的程序，提高其运行效率。数据库调优通常是增加或减少索引、增加cache等等，对数据库的各种参数进行调整。
  硬件调优通常由测试人员完成，一般是调整系统各部分的分布、增加机器、增加物理内存、调整虚拟内存、更换硬盘等等。
 4.2 测试方法
  系统调优是查找系统的性能瓶颈的延续，所以，前半部分的工作就是查找系统的性能瓶颈。之后，针对发现的瓶颈，与开发人员交流协商调优的方法，调整后再重复前面的工作。
 4.3 测试过程
  1 设计方案
   见范例《范例4（系统调优）.doc》。
  2 测试实施与数据分析
   查找出系统的性能瓶颈
   与开发人员交流协商系统调优的方法
   调整系统后再次测试
  3 测试报告
   见范例《范例4（系统调优）.doc》。报告的重点是系统的调整方法，以及在各种状态下的性能。
 4.4 系统调优结束的判定
  系统通过一定的调整，能达到各方都满意的性能
  项目经理以及高层确定系统不需要达到如此高的性能，从而修改需求
 4.5 注意事项
  需要经过各方的认同，系统调优才能结束

5 给出较适合的软硬件配置方案
 5.1 综述
  系统的性能与软硬件配置相关，不同的配置之下，系统将表现出不同的性能。性能要求较高的客户，需要较高的配置方案；性能要求较低的客户，需要较低的配置方案。什么样的配置能达到什么样的性能，从而能满足什么样的客户，这信息对于售前人员非常重要。
  通常，做这种目的的性能测试基本上能确定软件方面的系统调优不需要再进行，接下来做的只是，确定系统在不同档次的硬件上面所表现出的性能差异。
 5.2 测试方法
  首先需要确定判断是否“较适合”的标准，通常就是确定某些性能指标及其相应的数值范围，当这些性能指标在该范围之内时，就是“较适合”。通常都是取系统的处理能力作为标准。
  然后，选择不同的软硬件配置，在这些配置下测算那些性能指标。
  最后把各个结果汇总，确定几种较适合的方案。
 5.3 测试过程
  1 设计方案
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。
  2 测试实施与数据分析
   把硬件进行不同的搭配，测算系统的性能指标
   筛选出一系列满足“较适合”标准的配置方案
  3 测试报告
   见范例《范例5（给出较适合的软硬件配置方案）.doc》。测试报告需要把测试过的软硬件配置及其相应的性能指标列出来，并列出推荐使用的若干种配置方案
 5.4 注意事项
  对于每种配置方案，都需要经过实际测试才能说那是较适合的配置方案，不可以通过类似的配置来推测