进行任何性能测试之前,都需要制定一份详尽的测试计划,从业务角度到技术角度详细地说明性能测试将如何进行。一份性能测试计划应该至少包含以下方面: - 总体方法
- 依据与基本假定
- 性能测试前的操作
- 性能测试方法
- 性能测试操作
- 业务范围内的过程
- 业务范围外的过程
- 性能测试方案
- 性能测试的执行
- 性能测试指标
和任何测试计划一样,这份性能测试计划的文字要做到尽量精简,可以使用列表清晰明确地将信息表达出来。这将减少因为沟通问题产生的误解。 总体方法 这一部分是指用非技术性术语将性能测试的总体方法描述出来。目标受众是管理部门与业务部门。样例如下: “此性能测试方法主要用来对新部署的系统所支持的业务过程进行测试。通过部署这次性能测试,我们将: 以减少这次新部署所带来的性能问题为主要目的。 做出基本的运行假定,确定部署中需要进行性能测试的部分。 就这些假定取得一致意见,决定性能与压力测试的适当等级,并在有限的任务时间内完成。 这份文件是即时更新的。随着我们收集到越来越多的信息,并就适当的性能测试方法达成一致协议时,将再次更新这份文件。” 依据与基本假定 在这一部分中,要清晰地描述测试前必须满足的依据(必须完成的任务)与基本假定(测试时假定为真)。样例如下:
“继续部署任何性能测试之前,必须满足以下条件: 要进行性能测试的组件必须能完全正常运行。 要进行性能测试的组件要安装在可以代表(或按比例可调的)预期的生产系统的硬件或固件中。 数据存储库要能代表(或按比例可调)预期的生产系统。 有确定的性能测试目标,包括运行情况的假定与测试方案。 安装好性能测试工具并提供所需的技术支持。” 性能测试前的操作 这部分要清楚地说明在正式进行性能测试之前为确定系统已经就绪而进行的预测试操作。相当于功能测试中的烟雾测试(smoke testing)。样例如:
“为减少性能测试中的风险,可以进行几项预测试操作: 在质量保证测试环境下利用‘桩(stub)’或‘实用程序(utilities)’测试事务处理能力,即投影最大负载(projected peak loads)。 用‘桩’或‘实用程序’代替无需测试或只需进行有限测试的B2B类事务。这将取消任何关于B2B事务的依据。 用‘桩’或‘实用程序’代替性能测试中无法使用的内部组件。这将移除所有关于此类组件的依据。 在所有大规模服务器上部署合适的性能监控器。” 性能测试方法 这一部分是前面总体方法的扩展,但考虑到了业务与技术两个方面。样例如: “本性能测试方法主要用来测试新部署的系统的逻辑。通过部署这次性能测试,我们将: 以减少这次新部署所带来的性能问题为主要目的。 做出基本的运行假定,确定部署中需要进行性能测试的部分。 就这些假定取得一致意见,确定即将完成的性能的适当等级。 使用可以模拟预期生产规模的一流的性能测试工具。 模拟需要进行性能测试的组件(将在生产中使用的组件)构成测试环境,检测所有异常。 在性能测试期间同时使用生产与非生产(测试)监控器器检测系统的性能。” 性能测试操作 这一部分详细说明了性能测试中所进行的操作。样例如: “性能测试中将进行以下操作: 根据既定方案对系统进行合适的负载测试。方案包括: - 用户操作(业务流程)
- 既定负载(每分钟的事务处理次数)
- 既定指标(响应时间)
性能测试期间将进行手工测试和自动化的功能测试,保证在当前负载下用户操作不会受到影响。 将使用系统监控器监测测试涉及的所有服务器的性能,保证其达到预期的性能要求。 部署后支持团队将在性能测试现场观察性能测试结果并提供支持。” 业务范围内的过程 这一部分指定系统的哪些方面属于业务范围内(基于标准)。样例如:
“性能测试时将以下过程视为业务范围内的过程: 用户注册 登录/访问 用户对内容进行浏览 销售条款与执行 账目计算 业务过程目录与以下人员商议制定:业务分析员、市场分析员、基础组织和业主。” 业务范围外的过程 这一部分指定系统的哪些方面属于业务范围外(基于标准)。样例如:
“性能测试时将以下过程视为业务范围外的过程: 信用检查 > 前提:信用检查将委托第三方进行――因此不会对性能产生明显的影响。 所有在当前未被列为业务范围内或范围外的业务功能。 > 前提:所有未在本文件中列出的范围内或范围外的业务都不会对业务产生明显的性能影响。” |