基线性能测试法的测试目标是测试系统可以达到的最优性能。从产品实现角度来说，一般需要我们从“组件”和“功能”两个层面对系统进行性能分析，确定性能测试条件和数据。
“组件层”从系统内部实现的角度来分析可能影响性能的因子，一般来说，缓存、队列、各种算法都会影响性能。可以用mock的方法来编写测试程序，验证这些关键组件的性能。有时候会使用开源项目，很多开源项目也会提供组件层的性能验证工具。以某开源高速生成树算法进行性能测试为例。
测试项：测试算法的离散规则，建树速度、查询速度和内存占用大小。
测试结果：
功能层从用户视角来分析可能影响性能的因子，某个单运行和多运行的功能。
对于组件层，以高速生成树算法为例，假设系统“策略功能”使用了被测试的组件，那么策略功能就是影响系统性能的因子。
性能影响因子在组件层和功能层中的关系示意
在性能基线测试时，尽管输入的配置、业务负载都是系统层面的，但也需要让这些测试条件尽量符合那些会影响性能的组件的最好情况要求，这样才能测试到系统最优的性能。
从测试标准来说，不同行业的性能测试指标可能会千差万别，但是归根结底都可以分为两大类：
1）系统能够正确处理新业务的最大能力，即新建速率类指标。
2）系统能够同时处理业务的最大能力，即并发类指标。
1. 系统能够正确处理新业务的最大能力
对系统的“新建速率”进行测试，其实测试的是系统能够正常处理一个新业务的效率。例如系统每秒能够允许多少新用户上线登录，系统每秒能够主动发起多少新的连接，这些本质上都是在测试系统可以正常处理一个新业务的效率。以常见的Web服务来说，浏览器和Web服务器在正式进行数据交互之前，TCP会先进行三次握手建立传输通道，然后才能正常传输数据。Web服务器每秒可以最多处理多少个TCP三次握手，就是我们说的新建速率。
影响系统新建速率最直接的因素是建立新业务的处理逻辑，也就是系统的“算力”（可以理解为CPU的处理能力）。每建立一个新的业务，都会消耗一定的系统资源（内存、硬盘、中间件等），所以即便算力充足，资源也会有耗尽时，此时新建性能就上不去了。所以系统资源老化回收的处理能力也会影响新建速率。
新建速率测试需要考虑测试的持续时间。这个持续时间至少能够保证系统完成“资源分配—使用—回收再分配—再使用”这样完整的循环过程。仅测试“前半段”，即“资源分配—使用”，无法完整测试整个处理逻辑。
以Web服务器为例，正常情况下，Web完成业务后，通过TCP四次挥手关闭连接。系统为这个连接分配的资源应该及时回收，让其可以尽快用于建立新的连接。如果资源回收不及时，系统新建能力就无法维持，长此以往还会影响系统的功能和稳定性。这也是DDOS攻击（拒绝服务攻击）的基本原理。
2.系统能够同时正确处理业务的最大能力
并发测试是为了测试系统能够同时正确处理业务的能力，如“系统能够支持的最大同时在线用户数”“系统能够同时发起的最大连接数”等。还是以Web服务器为例，TCP三次握手建好后，浏览器和Web服务器交互数据，这个过程就是定义中所说的“正确处理业务”，测试Web服务器最多可以同时与多少个浏览器交互数据，就是最大并发性能测试。
如果说影响新建指标的主要是“算力”，那么影响并发的因子就比较多了，这是因为并发需要测试的是系统能够同时正确处理业务的能力，而业务涉及用户数据、用户使用习惯等，很难一概而论，但“资源”（如内存）和“算力”（CPU）是两个最核心的因子。以Web服务器为例，系统会为每一个新的访问请求建立一个会话表，每个会话表都会占用一些内存资源，会话表的容量就成了理论上的最大并发值。但是连接建立后，还要交互数据（如浏览器向Web服务器发送页面访问请求），这时会涉及业务处理逻辑、网络传输等，有时可能还会涉及加解密等，这些都需要消耗算力，这些都会影响系统的并发性能。
3.基线性能测试法的关键：控制性能指标之间的互相影响
由于影响新建速率和并发的因子中都有算力和资源，所以新建速率和并发在测试中会互相影响。
图中a）表示系统在30s内，每秒完成150个的新建。假设在这30s内并没有拆除业务，那么系统在这30s内并发连接的数目就是150×30=4500。如果这个系统的最大并发能力只有4000，按照这样的测试负载，到第26s左右，系统就会因为并发能力达到极限而出现新建失败。如果此时判定系统的新建能力不能达到150，那是不正确的。正确的做法是调整测试方法，让连接新建成功后就立即被拆除，即减少并发量，不让并发成为新建速率测试的限制因素。
基线性能测试方法从产品实现的角度去分析哪些组件可能会影响系统性能。在测试某一个性能指标时，其他性能指标不能对测试造成影响。总之是使用最优的测试条件和测试数据来测试系统各种最优的性能指标。这样的性能测试不仅可以帮助我们评估系统基础能力、评估设计是否合理，还可以为后期优化提供参考依据。这也是这个测试方法名中“基线”二字的由来。但是这些性能测试结果往往太过乐观，我们有时候也会称之为“实验室测试理想结果”，通过这种结果无法评估系统在用户真实环境下的使用性能。
怎么评估用户真实环境下的性能呢？我们后面学习。
个人觉得基线性能测试法一般是不是不会实施，太理想没有实际意义，耗费测试人力成本。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
网友评论