顺利通过考核后，Lucy正式成为了性能测试团队的一员。不久后，公司对外招聘了两名有经验的高级性能测试工程师，团队进入了真正的实战阶段。本章将以某电子商务软件的性能测试为主线，在指定环境下通过需求分析、脚本设计、测试分析等诸多环节，展示完整的性能测试过程。
本章主要包括以下内容：
●项目规划；
●测试设计；
●测试实现；
●测试执行；
●结果分析；
●本章小结。
9.1 项目规划
9.1.1 项目背景简介
组件性能测试团队后不久，很快就接到了各项目组性能测试任务的邀请。按照王经理的安排，Lucy和Peter负责某电子商务网站的性能测试工作。以下是Peter工程师的基本信息。
个人基本资料 姓名：Peter 性别：男 年龄：30岁 毕业院校：××大学计算机专业 工作年限：8年（含性能测试3年） 就职公司：A技术有限公司（主要从事外包业务） 当前职位：技术部 / 性能组 / 高级性能测试工程师 |
本次项目性能测试工作将由两位全程参与，项目已进入编码阶段。项目团队的负责人PM张恰好是Lucy的原上级，因此团队成员也相对熟悉，也算是一个不错的开始。
据PM张介绍，项目是为某家公司打造一个Web端的电子商务平台，平台以自有产品为销售对象，总工期控制在4个月以内，本次除功能测试外客户方还提出了性能要求，性能测试要求如下所述。
（1）系统业务要求
本次性能测试只针对核心业务模块，包括“首页访问”、“用户登录”、“浏览商品”、“信息检索”以及“用户订单”模块。主要关注系统在60万/天业务量下的性能表现，业务占比以同类电子商务网站为依据。
（2）系统环境要求
本次测试环境同生产环境1:1建模，请提前准备测试数据，测试完成后及时恢复测试数据。所有设备资源使用率应保持在相对较低的水准。
（3）测试通过标准
如果系统能够达到以上要求则测试通过，通过后可持续增加压力，找出系统每天最大业务量的峰值，为后续系统升级提供参考。
【特别说明】：因篇幅有限，本书仅针对核心业务的性能需求进行详细说明。
接到需求后Peter和Lucy进行了一系列讨论，介于Peter性能测试的经验和Lucy业务上的熟悉程度，彼此进行了基本的分工。本次项目由Peter主导，负责安排性能测试计划、性能场景设计，协助定位性能问题；而Lucy主要负责脚本编写、测试环境搭建、测试数据准备、测试执行与回归。
【特别说明】：为了让读者可以同Lucy一起完成性能测试项目，本次将使用网上开源电商项目ECSHOP2.7.3代替项目组原有的小型电商项目。从性能测试角度两个项目有诸多相同之处，除银行交互部分的性能测试无法演示外（仅测试货到付款和余额付款两种付款方式），其余业务场景均可完整测试。后续测试实战将基于ECSHOP2.7.3版本进行模拟规划。
学习笔记
性能测试刚开始的工作主要集中在脚本和数据上，包括数据的准备、脚本的录制与回放、脚本的执行等。随着经验的日积月累，场景分析和瓶颈定位才能水到渠成。本质上和功能测试是相似的，前期以执行为主，后期以思考为主。
9.1.5 性能测试计划
性能测试计划的写作方式有两种，一种是生成独立的性能测试计划，另外一种是作为系统测试计划的附属，无需单独成文。
独立性能测试计划主要包括如下内容。
文档目的：文档的主要受众群体有哪些，例如开发人员、测试人员在阅读此文档中所扮演的角色。
项目背景：项目的基本特点，主要来源于需求和业务分析。
相关术语：业务专业术语描述，部分公司也会列出常用性能测试术语。
输入文档：性能测试计划的参考文档，主要包括软件需求规格说明书、用户原始需求、项目计划书等相关文档。
运行环境：描述当前系统所支持的软硬件环境，也包括网络环境。
测试内容：对被测对象进行分析得到的被测内容范围并描述原因。
角色安排：包括角色分工，如性能测试工程师、IT运维、开发代表、需求分析、架构设计、DBA、PM、测试经理等。
工具选择：对工具的选择进行可行性分析，例如成本、技术难度，工具本身是否支持，测试人员对该工具的掌握程度等。
进度安排：依据项目整体测试计划的时间要求，对性能部分的计划进行细分。
输出内容：性能测试的最终产物，例如《性能测试计划》《性能测试脚本》《性能测试环境搭建手册》《性能测试报告》等。
【特别说明】：多数公司会采用第二种方式，将性能测试计划作为系统测试计划的一部分，而不是单独编写性能测试计划。
鉴于性能测试时间并不充分，PM张建议Peter将性能测试计划作为系统测试计划的附属，目前离项目结束还有2个月左右的时间，但真正给到性能脚本运行和调优的时间预计只有一周左右。
以下是Peter同PM张讨论后的“性能测试人力进度计划”，如表9-1所示。
从时间安排上我们可以看出性能测试预估所需的执行时间是48小时，测试执行前需确保功能测试成功，测试数据、测试脚本和测试环境准备妥当。
学习笔记
性能计划时间的估算同性能工程师的经验有着密切的联系，但即使是有经验的工程师在估算上也会受到诸多因素的影响，例如，功能测试占用了性能执行的时间，测试设备执行期间出现故障，性能测试问题定位出现偏差等。所以在现实工作中我们往往会舍弃部分性能测试任务，尽量保证核心业务的性能稳定。
9.2 测试设计
9.2.1 测试工具选型
关于工具的选择自然是大家所熟悉的HP LoadRunner 12，Peter对于该工具的选型做出了如下评价。
（1）该工具支持HTTP协议的并发用户行为。
（3）可监控CentOS 7操作系统、Apache 2.0应用服务器、MySQL 5.5数据库服务器。
（4）性能测试团队成员对LR12较为熟悉，无需额外培训。
【特别说明】：如果想了解其他性能测试工具，请参考本书3.1章节“市面上的性能测试工具”。想了解工具选型的判断依据，请参考本书3.2章节“如何选择最合适的工具”。
9.2.2 测试策略拟定
鉴于前期对需求的理解，以及对系统和业务调研分析，Peter很快明确了本次的业务目标，如表9-2所示。
业务目标明确后Peter着手考虑测试场景设计问题，按照性能测试设计原则：优先考虑独立业务场景，再考虑组合场景的综合应用。
Lucy对Peter场景设计的想法并不是很理解，于是有了如下对话。 Lucy：Peter，关于测试策略我想了解更多细节，能解释一下什么叫作独立业务场景吗？ Peter：好的，独立业务场景你可以理解成单脚本运行场景，例如只运行登录脚本，或者只运行浏览商品的脚本。 Lucy：这样做的目的是什么？ Peter：很简单，如果独立业务场景运行成功，那么组合场景才有意义。这就好比走方阵，如果一个人有问题，那么整个方阵都会不协调。 Lucy：这个比喻我懂了，那么独立业务场景是否需要考虑多个用户并发的情况？ Peter：当然是要考虑的，不仅仅要考虑多个用户并发情况，还需要考虑负载的极限呢。 |
经过一番斟酌，Peter决定首先对“首页访问”“用户登录”“浏览商品”“信息检索”以及“用户订单”模块进行基准测试，获取基础数据；下一步则是针对每个模块多用户并发操作得到性能测试拐点（最大并发用户数）；最后考虑在较大并发量下进行稳定性验证。
如果各项指标能够达到预期标准则表示测试通过，反之则需要进行性能调优。
Lucy：你是打算先对单脚本进行基准测试、负载测试和压力测试？ Peter：聪明，是这样打算的。 Lucy：基准测试和压力测试我都可以理解，做负载测试的目的是什么？毕竟系统有上限，只要达到60万/天的业务量就算是测试通过。 Peter：是的，只要达到60万/天的业务量，并且符合其他预期指标就算是测试通过了，但需求中还希望知道系统有多大能耐，我需要找出系统每天最大业务量的峰值，为后续系统升级提供参考。 Lucy：明白了，那组合业务场景我们也要考虑这三种类型的测试吗？ Peter：不完全相同，组合有组合的测试要求，下面我就给你介绍。 |
单场景业务测试也叫独立业务性能测试，以找出基准和负载为主要目标，而多场景组合业务则更侧重系统压力、稳定和容量方面的综合表现。
本次项目组合业务场景Peter决定以既定目标60万/天作为压力测试指标，然后考虑系统容量方面的测试，最后以慢增长方式对系统施加压力，看系统可靠性的性能表现。
经过Peter的介绍，Lucy总结了本次性能测试的策略选型。
独立业务性能测试：基准测试->负载测试->压力测试（均以慢增长方式加压，持续运行指定时间后结束）。
组合业务性能测试：压力测试->容量测试->可靠性测试（均以慢增长方式加压，持续运行指定时间后结束）。
学习笔记
任何项目的性能测试策略都是依据实际需求确定的，并没有万能公式或者统一标准。在实际测试工作中往往是多种测试类型融合在一起使用，测试类型的选择和测试人员的经验有着密不可分的关系。
本书读者交流QQ群：425860640，欢迎加入~~
本文选自《性能测试学习笔记之 LoadRunner实战》第九章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
