3.1.5 性能测试实践方案
当测试工程师接到一个系统需要性能测试的需求时，一般情况下需求描述只有一句话，很少会有具体可供利用的信息，如系统要承载的并发用户数、系统支持的TPS等。而要开始性能测试，需要的输入却远远多于这些信息。在开始性能测试之前，需要的相关信息主要分为三大类——业务类、指标类及环境类。
1．开始前需要收集的数据
1）业务类
对于性能测试而言，测试工程师的重中之重就是要识别被测业务是不是一个有并发访问行为的业务，被测系统中是否有类似于并发行为的业务逻辑，以及业务流程中是否有并发访问行为。
为什么要先识别是否存在并发访问业务呢？这是因为在测试工程师的眼中，并发访问就是有瞬时增长的访问业务，但是在很多业务人员眼中，并发访问指的是系统访问人数众多。如果被测系统中受众用户数量多，而不存在并发访问行为，那么在性能测试过程中就可以同步减少用户数量，增加访问时长和多种业务逻辑，模拟系统长期被多人使用的场景，重点查看系统中是否存在资源被占用但不释放的情况。如果存在并发业务流程，那么就需要详细考查并发业务逻辑，同时预估并发的用户数量。
用户数估算是目前性能测试中的一个难题，虽然有类似于泊松分布、二八原则等众多模型与算法可以使用，但是目前这些模型不是理论计算，就是前置条件太过于理想，很难完全与实际工作中遇见的业务模型相一致，也就很难用到实际工程中。因此在进行性能测试并发数估算时不要唯并发用户数论，能够估算出来固然是一件好事，估算出不来也没关系，后续可以通过其他指标来补充并发用户数的缺失。
在这一部分，测试工程师还有一个重要工作，就是要甄别性能测试需求是不是一个真性能需求。这是因为现今很多人为了避责，无论是否有并发访问行为的业务都让测试工程师进行性能测试，测试工程师有责任拒绝不是并发访问业务逻辑的性能测试需求。这并不是对工作的推诿，而是因为性能测试是一项高投入的测试工作，需要投入大量的硬件资源，无论开发工程师、测试工程师还是运维工程师都要为性能测试做大量的准备工作。如果测试的业务不是有并发访问行为的业务，就会对公司资源造成极大的浪费。因此测试工程师要审视测试的业务是不是一个并发访问业务，以避免资源浪费。
2）指标类
性能测试的指标类包含并发访问量、响应时间、TPS（Transactions Per Second，每秒事务数）、服务器资源利用率等。这些指标是测试工程师事先和产品经理、开发工程师沟通协商的结果。抛开并发访问量，响应时间普遍的2s、5s、8s的设计可以指导很多指标的确定，但这只是一种经验值，也要与具体业务逻辑相结合，在此基础上确定一个可以满足用户需求的响应时间指标。
TPS是一个常用指标，但是直接以它为标准估计会让合作增加一个级别的难度，因此一般并不指定该指标要满足的具体要求，而是在测试过程中收集该指标，从而评价系统的性能。这里的事务可以是一个页面，也可以是一个操作，因此每个公司、每个团队乃至每个测试工程师对TPS的理解都可能存在一些差异。在内部使用TPS时，建议约束好事务的范围。
对于服务器资源利用率，一般会定义一条红线，超过红线后性能测试终止。这是为了防止被测系统因为压力过载而出现一些非预知问题。性能测试的重点是测试出系统的水位，而不是找出系统压力过大后的异常表现。当然，如果只需要验证该类表现，也可以进行一些类似的压力模拟。常规服务器资源特性定义CPU利用率为85%，可用内存占全部内存的85%等，但是这些都是团队内部协商的结果，并非由测试工程师个人决定。
3）环境类
众所周知，一个系统的性能表现既与它的代码实现有关，也和它的部署环节有关。这里所说的部署环节既包含服务器资源也包含基础服务。如果要开始性能测试，测试工程师需要完全了解性能测试环境，这里面既包含被测服务的部署拓扑，也包含服务器的账号和密码，同时还需要知道压力机和服务器之间的网络带宽。在性能测试开始之前，要将所有需要的工具都部署完毕，并验证可用性。
性能测试推荐在实际对外提供服务的对等环境下完成，这是因为性能测试结果与进行性能测试的环境强相关。如果在一套服务器配置、网络环境、基础软件和生产环境都不一致的测试环境下完成性能测试，那么并不能通过同步放大测试结果估算生产环境能够提供的性能。
2．性能测试的执行
在前面的工作完成后，我们就可以开始性能测试了。如果这时已知系统的预计并发量，就用产品或者业务提供的并发进行测试，看看系统是否满足预定要求。如果不满足，测试工程师就需要和开发工程师一起，利用前面介绍的服务器监控工具、JVM监控工具及MySQL监控工具分析系统瓶颈。这里有如下系统瓶颈修改原则。
当存在多个优化方案时，每优化一个技术点，就要做一次性能场景的回归测试，而非将所有怀疑的问题都修复完成后再做性能回归，否则无法评估哪一项修改解决了对应的性能问题。
但是大多数情况下，没有人能给出一个完全可靠的并发量。所以本书推荐使用计算单元性能评估方法来完成性能测试。那么什么是计算单元呢？假设服务A对外提供服务，需要门户，以及服务A1、服务A2，那么通过不断地执行性能测试来发现一个计算单元包括一个门户、两个服务A1、4个服务A2能够达到最优的性能配比，如图3-16所示。
这就是一个计算单元，这个组合刚好在有100个并发用户的情况下，满足响应时间、服务器资源的需求，而且所有服务器的资源利用率最高。在系统上线后，若出现并发用户急剧增加的情况，可以同步建立一个计算单元，从而快速按照服务器最优比扩容，这也快速提升了整体技术解决方案的吞吐量。在性能测试输入项不完善的情况下这是最好的一种系统性能评估方法。但是这种方法耗时费力，对项目中性能测试的时间有很高的要求。
图3-16 计算单元
3．性能测试的总结
在完成性能测试后，测试工程师要对性能测试进行总结。除将测试结论以及所有工具的实际数据整理完并写到测试报告中，在结束性能测试之前，还需要为测试业务场景建立本次性能测试和调优后的基准，这样当系统生产环境中访问量剧增的时候，可以促进系统快速扩容。作为一名合格的测试工程师，要牢记所有过程数据、过程文档要留痕，尤其测试工具产生的原始数据都要归档。
