性能测试方案需包含测试测试需求分析、测试资源准备、测试风险、测试执行策略、测试报告输出这几个关键点测试需求分析测试中涉及的测试目的、测试指标、测试对象的分析定义。测试资源准备测试中涉及的测试环境、测试工具、测试数据、测试桩、测试人员周期的分析准备。测试风险分析测试中涉及的环境风险、人力风险、技术风险的分析定义。测试执行策略测试中涉及的测试类型、测试用例、测试轮次的分析定义。性能测试报告测试中涉及的测试结果分析并输出测试进度报告和测试结论报告的规范定义。1. 测试需求分析1测试目标测试目标需要清晰明确没有歧义主要分为业务或系统两方面的促进/改善业务改善新业务上线验证能够满足上线指标验证改进后的业务性能效果需与以往测试结果进行比对系统改善验证系统是否存在明显的性能瓶颈验证系统稳定性验证改进后的系统性能效果需与以往测试结果进行比对至于如何界定性能测试的结果满足预定的目标一般有如下几个标准新上线的测试系统没有明确的数字标准比对情况下被测试系统已经被测试到了系统极限系统的某些资源已经耗尽cpu、句柄、内存、数据库出现大量的slow query系统有些处理已经变慢并且系统被证明是可以水平扩展的则可以上线。有以往测试结果进行比对只要证明类似的测试条件下此次的结果比以往的测试结果更好即可每秒处理个数更多、单次请求的处理速度更快。没有可以比较的测试结果但是产品已经上线一段时间至少3个月有一些运营数据则需要分析运营的数据来作为比对的基准只要被测系统达到3个月内系统并发峰值的 4 倍经验值则认为是可以接受的如果是以接口为测试对象则需要混合主要的接口来进行性能测试。运营、开发人员提供经验值作为比对的基准则被测对象只要证明满足开发人员提出的经验值即可。2测试指标分析关键指标性能测试指标要可测量定量指标给出具体数值定性指标给出具体描述。一般分为业务指标和系统指标两方面业务指标TPS被测接口能达到的吞吐量每秒能支撑多少业务或每天能支撑多少业务事务响应时间每个事务的平均响应时间或 90% 响应时间并发数我们期望被测接口能支持多少并发事务成功率接口、单业务、组合业务的处理成功率...系统指标主要指对系统资源的使用程度CPU 使用率内存使用率磁盘 IO网络带宽使用率...指标来源需求文档1客户明确需求通常情况客户有明确的需求定义一些性能测试指标例每秒用户登录页面刷新多少、每秒登录用户量多少用户在线总量多少我们明确性能测试指标。2客户隐形需求基于客户明确指标下会有一些隐性指标例100 万在线用户的查询在 5 秒响应我们也许纳入性能测试指标内。3用户模型确定有了以下的性能测试指标后我们可以创建我们的用户模型如下用户指标用户登录 TPS 需达到 50用户总量总用户量 100 万用户模型系统每天用户在线量在 100 万左右平均在早晨 08:00-11:00 期间登录其中登录与查询的比例为 5:1。市场调研1客户无明确需求也有特殊的情况客户只会提供一些基础数据例2000 个机构下500 万的用户总量我们需要根据这些基础数据提炼出我们的性能指标。2市场调研需求有了基础数据后还需要对我们所关心的性能指标做市场调研最终得出我们的性能指标。例对其中 1 个机构 1 个月的用户登录数进行数据采集每天早晨 8-9 点是登录高峰期每天大约是 1 小时内登录 100 人次平均到每秒 100÷3600 约为 0.027 次/秒然后在推算 2000 个机构下用户每秒登录 0.027*2000 约 50 次在根据后台日志推算出登录与查询的比例为 1:5那么查询的TPS为 250。3用户模型确定确定性能指标后我们可以创建我们的用户模型如下用户指标用户登录 TPS 需达到 50用户总量根据用户指标推算出用户总量或者由相关系统推算出用户总量用户模型系统每天用户在线量在 100 万左右平均在早晨 08:00-11:00 点期间登录其中登录与查询的比例为 5:1。3测试对象分析测试范围哪些接口要进行性能测试和稳定性测试哪些页面业务逻辑要进行性能测试和稳定性测试关注重点针对继承模块进行回归验证即可不做探索性的性能测试。针对重构或新增模块测试进行全面的测试优先覆盖典型场景。典型场景如下示例是否是核心功能是否是用户频繁使用的功能发生过性能问题的功能产生 IO 操作较多的功能产生密集计算的功能代码优化过的功能...2. 测试资源准备1测试环境建模内容测试环境的建模主要分为网络拓扑图、硬件、软件、参数配置。描述清楚几个要点几台测试服务器每台服务都有什么服务前台 web 服务、memcache、数据库等各服务器间的连接关系...建模思路分析系统真实运行的网络拓扑环境明确公司可对性能测试进行投入的软硬件资源最好的性能测试环境就是待发布的生产环境次好的性能测试环境就是 1:1 复制的生产环境对于软硬件资源不足情况下同比例缩小系统每一层结构中的机器数量。注意系统中的每一层必须要有机器至少可验证分库、分布式的处理正确性测试环境的搭建最好让运维人员负责即使硬件不同但在软件版本和配置上也可以尽可能跟生产环境保持一致。思考低配测试环境的性能测试意义即使测试环境较 low但性能测试还是能起到意义的至少能够验证系统业务流程的处理正确性。验证程序没有明显的性能问题。验证单台机器的处理能力。2测试工具3测试数据根据前面的用户模型里涉及到的数据测试前期进行准备。需关注冷启动和数据满载这两种场景下的性能表现。缓存数据如 HTTP 请求中的 cookies 贯穿整个业务交互过程在测试脚本中应该缓存 cookies保证业务正常同时后台考虑 cookies 的存取方式保证大并发下 cookies 不会出现丢失或者写满的情况。数据库数据如被测试系统中的数据库的每个表有多少数据以及数据的类型和大小分布的说明。4测试桩测试桩作用用于性能瓶颈定位、用于规避测试中一些非主要的流程通常由研发人员提供。模块之间的测试桩流程中包含 AB 模块性能定位 AB 模块性能瓶颈时需在AB模块之间做桩让其支持单压 A或者单压 B 模块。辅助测试桩测试流程中的一些非主要流程且测试脚本不易实现。例登录时安全校验输入验证可适当地让研发人员进行前段安全校验的屏蔽。5测试周期6人力周期人员组成无遗漏职责描述清楚系统架构师核心开发人员运维工程师DBA性能测试方案设计人员可以1人同时承担此角色性能测试工具和脚本开发工程师可以1人同时承担此角色性能测试执行人员可以1人同时承担此角色测试环境维护人员测试人员运维人员开发人员测试周期阶段划分按划分的阶段汇报性能测试结果。完成时间在性能测试总体完成后输出测试结论报告。3. 测试风险分析测试风险及应对方案测试环境风险找不到合适的软硬件等资源需测试前期识别出来并使用相近配置进行验证后期需在测试风险中提出。测试人力风险由于测试周期紧张需要多名测试人员同时进行测试但具备性能测试的人员不足前期提出风险并考虑延长测试周期或在前期培训相应人员。测试技术风险根据业务与后端系统选取合适的性能测试工具例LoadRunner、Jemter 等。4. 测试执行策略1测试类型执行顺序基准测试获得各个典型交易在无压力条件下性能表现。如一个用户迭代操作 100 次关注其响应时间事务成功率 100%。负载测试单场景负载测试获得各个典型场景在各个负载条件下的性能表现。混合场景序列负载测试按照场景序列一次获得各场景在各个负载条件下的性能表现。如初始启动 20 个并发用户每隔 5 分钟加载 20 个并发用户加载到 80 个并发并执行5分钟后停止全部压力线程。容量最大处理能力即使满足了测试目标指标也继续增加并发数加压直到达到系统最大的处理能力即性能瓶颈。稳定性测试稳定性测试主要验证系统在长时间负载下的表现是否正常。1若测试时间有余则按照负载场景指标的 60% 对系统进行 7*24 小时的长时间负载测试观察系统长时间运行下是否满足负载指标的 60%在业务波峰时系统后台资源CPU、内存、磁盘IO消耗不高于系统的 80%在业务波谷时系统后台资源恢复到正常的 20% 到 40% 左右是否发生内存、句柄、连接泄露是否发生程序死锁是否正常触发 fullgcgc 时间、gc 频率、 fullgc 时间、fullgc 频率JVM 调优就是为了减少 fullgc 频率数据库的容量问题。2若测试时间紧张则采取最优容量的 80% 作为压力持续运行 24 小时观察系统运行时的上述性能表现。2测试用例分组执行顺序首先需要对每个接口进行压测验证每个接口是否有明显的性能瓶颈。并需要把所有的单一接口全部优化完毕后再做场景级别的性能测试。3测试用例包含元素需要设计好每条用例应包含的元素及其方法用例名称接口/场景并发数运行时间参数化关联断言内容监控方法日志分析...4测试执行轮次测试执行轮次的最低要求是两轮第一轮主要是发现性能瓶颈第二轮主要是验证优化后的性能效果。5. 性能测试报告在性能测试执行完成后需要进行测试结果分析并输出测试报告。1测试结果分析2报告输出测试结论报告需要在开头就指明是否满足本次性能测试的目标以及本次性能测试的局限性与生产环境、实际业务场景的差异。剩余报告内容与测试进度报告基本一致。