系统|不懂性能测试,被面试官挂了……( 二 )


选定测试工具后,我们需要为关键业务创建脚本,并在 10-15 个虚拟用户中执行,这就是所谓的(POC—— Proof Of Concept,这是在有限范畴内,对用户实时活动的一种演示)。
性能测试计划&设计
根据第一个阶段收集的寻求信息,我们需要对性能测试进行整体计划和设计。测试计划旨在明确性能测试该如何进行,即性能测试环境、工作负载场景的设计、相关硬件配置等等。
这个阶段的输入是测试需求分析,输出是测试策略文档(包含了整个性能测试计划,设计),关于测试策略文档,在下文中将会以实例呈现。
性能测试用例研发
【 系统|不懂性能测试,被面试官挂了……】基于 POC 的测试用例研发:根据上述测试计划中确定的测试范畴及核心业务功能,开始着手设计编写性能测试用例;这些初始的测试用例通常是在 POC 期间基于所选的性能测试工具来记录被测试业务的步骤。
基于 POC 的测试用例评审:性能测试用例的评审最好能将客户代表纳入以获得他们的认可,确保被测业务每个步骤的准确性。
测试用例优化:基于 POC 的测试用例一旦通过评审,我们就可以逐步优化测试用例,例如参数化,等待,集合点等的设置。
环境同步:在创建优化性能测试用例脚本的同时,需要设置测试环境(软件和硬件),从而确保性能测试脚本在特定环境下执行(尽可能模拟真实的线上环境)。
真实用户 VS 虚拟用户:如果性能测试在真实的客户环境下执行,性能团队还需要考虑如何避免实时用户及虚拟用户同时在线的情况,一般而言这类情况可以选择避开实时用户大量在线且活跃度相当高的情况。
性能测试建模
为测试执行创建性能负载场景模型, 该阶段主要目的是验证给定的性能指标(来自性能需求)在测试期间是否达到。
性能测试执行
在指定的场景下执行性能测试脚本,性能测试场景是根据上述负载模型设计的,测试执行通过虚拟用户数递增模式进行。
例如,如果用户的最大数量是 100,那么场景首先会运行 10、25、50 个用户,以此类推,最终会运行 100 个用户。
性能测试结果分析
测试结果是性能测试人员最重要的交付内容,也是可以证明 ROI(投资回报率)以及性能测试工作真正体现价值的地方。
由于性能测试通常需要进行多次执行才能得出正确的结论,无论通过工具自动生成还是自己汇总测试结果。
有效的性能测试结果分析需要注意这几点:
分析并记录测试失败的原因。
与前一次测试执行相比,应用程序的性能是否有变化。
为了执行性能测试用例,从应用程序构建到测试环境都做过哪些设置更改。
对每个性能场景执行的测试用例,及时进行性能测试结果分析,避免最终呈现完整性能测试报告时,出现任何数据指标的遗漏。
在总结中需要说明每场测试的目的、对应的虚拟用户数、测试持续时间、响应时间、吞吐量、不同负载情况下性能指标对比图、测试过程中出现的错误,以及后续改进的建议。
完整报告


推荐阅读