性能测试过程模型

1. 测试前期准备：
   两方面：保证系统稳定和建立合适的测试团队。
   性能测试一般是软件系统已经开发或者是部署完成后的测试，要求被测对象至少具有一定的稳定性，在功能上基本满足了需求。
   具体包括以下活动：
   （1）系统基础功能验证
   （2）组建测试团队
   （3）测试工具需求确认
   该活动确定测试工具应该具有的功能特性。在这个活动中，需要根据对被测系统的了解和对测试过程的初步规划，给出测试工具
   应该具备的功能列表，如：

操作系统环境 测试工具功能需求建议
操作系统环境 测试工具是否能运行在本操作系统上
测试工具是否支持对本操作系统的监控

应用服务器环境 测试工具能否支持对本应用服务器的监控

数据库环境 测试工具能否支持对本数据库的监控

应用使用的协议 本系统使用了那些协议
那些协议需要在性能测试中通过工具进行录制和产生负载

网络环境 是否需要测试工具支持防火墙
是否需要测试工具支持负载均衡

测试管理支持 测试工具是否能够提供方便的测试结果分析和管理
（4)性能预备测试
即在正式测试之前，通过简单的探索性测试或是其他方法，对系统的性能表现进行初步的了解。
2. 测试工具引入：
测试工具引入阶段包括下列活动：
（1）工具选择。
选择的方法是圈定几种可用的工具，对照"测试前期准备"中的功能列表，为每个工具进行一个功能符合度的评估，选择符合度最高的工具。
如果所有的工具都无法达到所要求的工具符合度，则可以考虑通过创建方式自行构建测试中使用的工具。
（2）工具应用技能培训
该活动为项目组的相关参与者进行测试工具的应用技能培训，使所有测试活动参与者能够具备测试需要的技能。与测试工具相关性最大的是
“测试开发”、“测试执行”、"测试分析"角色。
该活动需要达到一定的目标，最好能够在活动开始前确定各种角色人员的相信技能标准，并根据此给出培训是否达到预定目标的评判准则。
（3）确定工具应用过程
除了工具的应用技能培训外，测试工具引入过程中的另外一个重要活动是确定工具的应用过程。
测试工具引入过程中最容易导致的失败是团队步能达成对测试工具应用范围的一致认可和测试工具应用局限性的一致确认。那么该活动需要确定
性能测试工具在测试中的具体应用范围，工具使用过程中的问题解决方法等内容。具体来说，哪些工作使用工具完成？测试工具在使用过程
中的问题由谁来解决？测试工具的脚本如何管理？

3. 测试计划：
   测试计划阶段用于生成指导整个测试执行的计划。该阶段主要完成测试目标的确定、测试时间的拟定。分解为如下活动：
   （1）性能测试领域分析
   在性能测试中引入领域的概念可以反映性能测试的直接目的。性能测试的应用领域分为"能力验证"、""、""、""

4. 测试设计与开发：
   性能测试的设计与开发阶段包括测试环境设计,测试场景设计,测试用例设计,脚本和辅助工具开发活动.
   (1)测试环境设计
   测试环境设计使测试设计钟不可缺少的环节.性能测试的结果与测试环境之间的关联性非常大,无论是哪种领域内的性能测试,
   都必须首先确定测试的环境.
   对于"能力验证"领域的性能测试来说,测试首先就已明确了是在特定的部署环境下进行,因此不需要特别维性能测试设计环境,
   只需要保证用于测试的环境与今后系统运行的环境一致即可.
   对于"规划能力"领域的性能测试来说,测试环境不特定,但也需要设计一个基准的环境.
   对于"性能调优"领域的性能测试来说,因为调优过程是一个复杂的过程,在每个调优小阶段的末尾,都需要有性能测试来衡量调优
   的效果,因此必须在开始就给出一个用于衡量的环境标准,并在整个调优过程中,保证每次测试时的环境不变.
   在这里所说的测试环境设计包括系统的软/硬件环境\数据环境设计\环境的维护方法.其中,数据环境设计是非常关键但又是
   最容易被忽视的问题,设想一下,系统运行在一个已有50000条数据的数据库和一个几乎为空的数据库环境下,其执行查询,插入和
   删除操作的响应时间显然是不同的.
   (2)测试场景设计
   测试场景设计活动用于设计测试活动需要使用的场景.在"确定测试目标"活动中,描述了如何确定测试目标,以及测试目标的
   一般描述,这个活动需要更详细地将测试目标转化为能够在测试执行中使用的内容.
   测试场景一般模拟的实际业务运行的剖面,其包括业务\业务比例\测试指标的目标以及需要在测试过程中进行监控的性能
   计数器.
   场景名称 场景业务及用户比例分配 测试指标 性能计数器
   用户登陆 登陆业务,100% 响应时间<5s 服务器CPU usage
   总用户数200人 服务器内存 usage

标准日常工作 入帐业务,40% 响应时间<6s 服务器CPU usage
查询业务,30% 响应时间<5s 服务器内存 usage
统计业务,30% 响应时间<10s
总用户数200

(3)测试用例设计
在设计完成测试场景之后,为了能够把场景通过测试工具体现出来,并能用测试工具顺利进行测试执行,因此有必要针对每个测试场景规划
出相应的工具部署\应用部署\测试方法和步骤,这个过程就是测试用例设计活动.
测试用例是对测试场景的进一步细化,细化内容包括场景中涉及业务的操作序列描述\场景需要的环境部署等内容.
以场景"用户登陆"为例,将其细化为用例,就需要描述"登陆业务"的具体步骤,例如:
"登陆业务"描述:
1.用户进入登陆页面(访问http://…);
2.用户输入正确的用户名和口令;
3.用户单击"登陆"按钮;
4.等待直到出现登陆成功的页面,判断该页面成功显示的方法是HTML页面内容中的"欢迎"文本.
从描述中可以看到,在用例中,一个业务描述会被描述成操作的序列,并且在该序列中,一定会给出判断业务是否执行成功的准则.
一个较为复杂的性能测试用例设计内容如下:
模拟200个用户进程,该模型用于产生测试的负载,根据测试用例描述,需要保持200个并发用户的操作维护负载,因此在本模型中,
在[负载机1]上启动了200个模拟设备的进程,在[负载机2]上启动了200个模拟并发操作的客户线程,每个线程以每分钟1条命令的
频度发送命令.
测试方案:
(1)时间同步方法:鉴于本测试的模拟设备\模拟OMC和OMC都运行在不同的机器上,本次测试的结果又是和时间精确相关的,因此需要一个精
确的时间同步机制保证各台参与测试的机器时间一致;在此方案中,选择了一台UNIX主机(XXX.XXX.XXX.XXX)作为时间同步的服务器,在其他
UNIX主机上通过ntp进行时间同步;在Windows终端上通过开源的network time 程序进行时间同步.
(2)设置和用户模拟方法:用模拟程序[M1]模拟200个网元,[M1]程序能接收用户下发的命令[CMD1][CMD2]并发送回应;用模拟程序[M2]
模拟200个客户端进行连接,充当负载;[M2]程序以每分钟一条命令的频率随机发送[CMD1]和[CMD2]命令.
(3)执行方法:实际运行一个被测应用,在被测应用中由用户手工输入命令,程序记录下用户输入命令时间等关键时间点.

5. 测试执行与管理：
   测试和执行过程用于建立合适的测试环境，部署测试脚本和测试场景，执行测试并记录测试结果
   (1)建立测试环境
   该活动用于搭建需要的测试环境。在设计完成用例之后就会开始该活动，该活动是一个持续性的活动，在测试过程中，可能
   会根据测试需求进行环境上的调整。
   建立测试环境活动需要多个团队角色的参与，环境由测试设计人员设计完成，建立测试环境的活动由实施人员按照设计的要求
   组织建立，团队中的支持角色负责协助测试实施人员。
   建立测试环境一般包括硬件、软件系统环境的搭建，数据库环境建立，应用系统的部署，系统设置参数的调整，以及数据环境
   准备几方面的工作内容。

测试环境建立过程中，会遇到测试环境的各台设备之间的时间同步问题，方法：
1.通过Windows的域方式实现时间同步：将所有机器加入一个域，可以利用Windows的域机制实现时间同步；
2.通过ntp协议实现UNIX主机之间的时间同步：UNIX主机可以通过ntp协议实现互相间的时间同步，具体操作方式可以查看
map ntp;
3.通过开源工具NetTime（http://nettime.sourceforge.net）实现时间同步。NetTime是一个可以运行在Windows环境
下的时间同步工具，该工具使用ntp协议，因此可以用该工具实现UNIX和Windows混和网络的时间同步.
测试环境的维护问题：
性能测试中使用的数据量巨大，每次运行测试都可能会产生大量的测试数据，而且性能测试可能需要部署
大量的测试辅助工具和程序。为了测试结果的可比性，一般都需要在每次运行测试结束后恢复初始的测试环境。
方法：
使用检查列表(Checklist),在每次测试运行完成时，准备进行下一轮的测试运行之前用这个Checklist检查环境的可用性，

硬件环境 硬件环境是否与拓扑描述一致 硬件拓扑结构图

软件环境 软件环境是否与团结环境列表中 软件环境列表
描述的一致，应用不是是否成功 应用部署检查
测试辅助工具是否部署成功 测试辅助工具部署检查
软件参数设置是否符合要求 软件参数设置表

数据环境 数据是否与数据要求描述表中 数据要求描述表
描述一致 数据维护脚本或是录入方式
上次测试是否引入了额外的数据
而没有清除
(2)部署测试脚本和测试场景
部署测试脚本和测试场景活动通过测试工具本身提供的功能来实现。
对脚本和场景的部署需要熟悉测试工具的人员来完成，在过程模型中，该活动由测试实施人员进行。在场景部署完成后
一般需要一个确认步骤（测试设计人员确认场景部署与预期的设计一致）保证需要监控的计数器都已经部署好了相应
的监控手段.
(3)执行测试和记录结果
在测试工具的协助下，测试执行是非常简单的操作，一般只需要使用菜单或是按钮就可以完成；记录结果也可依靠测试
工具完成，通过测试工具的监控Monitor模块，可以获取并记录需要关注的性能计数器的值

6. 测试分析：
   测试分析过程用于对测试结果进行分析，根据测试的目的和目标给出测试结论。
   性能测试的挑战性在很大程度上体现在对测试结果的分析上，可以说，每次性能测试结果的分析都促要测试分析
   人员具有相当程度的对软件性能、软件架构和各种性能指标的了解。
   性能测试的分析需要借助各种图表，一般的性能测试工具都提供了报表模块来生成不同的图表，报表模块还
   允许用户通过叠加、关联等方式处理和生成新图表。
   方法：拐点分析法
   性能分析的通用方法之一是"拐点分析"的方法。“拐点分析"方法是一种利用性能计数器曲线图上的拐点
   进行性能分析的方法，该方法的基本思想是基于事实：性能产生瓶颈是由于某个资源的使用达到了极限，此时
   的表现是随着压力增大，系统性能表现急剧下降，因此，只要关注性能表现上的"拐点”，获得"拐点"附近
   的资源使用情况。就能够定位出系统的性能瓶颈。
   其不足只能定位到资源上的制约，而不能直接定位到引起制约的原因，因此该方法还须配合其他方法
   使用。可用于进行"拐点分析"的图表包括"负载－响应时间曲线"、"负载－吞吐量曲线"等