51Testing软件测试论坛

标题: 想学习性能测试？就从规范技术开始吧（下） [打印本页]

作者: lsekfe 时间: 2021-12-23 14:20
标题: 想学习性能测试？就从规范技术开始吧（下）
串联链路
　　分析
　　串联链路是指一组含有某种业务含义的压测API的有序集合（类似事务），串联链路是用来模拟用户侧的业务操作，模拟的正确与否直接影响着系统的性能，模拟业务操作的时候，需要参数化数据。

　　风险
　　业务没有做成功或业务逻辑与实际生产环境差距太大将会导致测试结果没有参考价值。

　　规范
　　跟生产上业务规则一致编排串联链路。
　　在关键地方校验服务器返回值，为压测API（指一条由用户行为触发的端上请求）添加检查点即断言。
　　数据尽量参数化、数据量尽可能的多。

　　场景
　　分析　　（压测）场景是若干个基于HTTP/HTTPS的URL/API的组合，用于模拟现实生产环境中业务场景，包括施压模式、压力递增方式、运行时间等。
　　场景模拟需要跟生产上场景相一致，特别是在一段时间内，测试出来的各业务TPS占比跟生产上高峰时候业务占比一致。
　　风险
　　场景的风险主要体现在测试出来的业务TPS占比需跟生产上业务占比一致，在业务比例偏离严重的情况下，将会导致测试结果不真实或者无效，不能反映生产上的业务场景。

　　规范
　　测试结果中各业务TPS占比需跟生产上业务占比（业务模型）相一致，可以使用PTS特有的RPS模式（Request Per Second，直接测试吞吐能力）来保证一致。
　　例如：A和B两笔业务，占比为1：4，响应时间分别为1ms、100ms，那么只需要通过PTS给A和B两个接口按照1：4比例设置请求数（TPS）施压即可。
　　如果使用传统的并发模式，A和B的并发需要经过换算确保比例是1：400，使得最终与生产上保持一致的业务模型。

　　监控
　　分析
　　监控的目的主要是为进行性能测试分析服务的，完善的对系统进行监控，针对瓶颈定位起到”事半功倍”的效果。
　　一般来说，需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量指标全面。

　　风险
　　没有完善的系统监控，将会导致性能分析无从下手，定位不出系统瓶颈，根本不知道从哪进行调优。

　　规范
　　操作系统：CPU（User、Sys、Wait、Idle）利用率、内存利用率（包括Swap）、磁盘I/O、网络I/O、内核参数等。
　　中间件：线程池、JDBC连接池、JVM（GC/FULL GC/堆大小）。
　　数据库：效率低下SQL、锁、缓存、会话、进程数等。
　　应用：方法耗时、同步与异步、缓冲、缓存。

　　瓶颈定位
　　分析
　　瓶颈定位的目的是对系统中存在的瓶颈点进行分析，为调优做准备，系统的性能瓶颈点主要分布在操
　　作系统资源、中间件参数配置、数据库问题以及应用算法上，对于有针对性的进行调优，有利于系统性能的提升。

　　风险
　　当系统的瓶颈点不能被分析出来以后，新业务上线或者核心业务就存在风险，这种风险有可能导致业务高峰的时候，系统性能体验差，甚至“崩溃”。

　　规范
　　分析系统的瓶颈点遵循的规则如下：
　　操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O。
　　中间件指标：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。
　　数据库指标：效率低下SQL、锁等待/死锁、缓存命中率、会话、进程等。
　　应用：方法耗时、算法、同步和异步、缓存、缓冲。
　　压力机：压力机资源消耗，一般情况下，压力机成为瓶颈的可能性非常低。PTS压力机有保护和调度机制不用单独关注。

　　调优
　　分析
　　调优的目的是提升系统的性能，针对系统的“瓶颈点”对症“下药”，通过测试验证系统的性能有多大的提升。

　　风险
　　未进行调优的系统，系统上线后，可能会出现客户体验差的效果，甚至导致系统“崩溃”的风险。

　　规范
　　系统调优遵循的规则如下：
　　中间件调优：线程池、数据库连接池、JVM。
　　数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。
　　应用调优：方法耗时、算法、同步和异步、缓存、缓冲。
　　系统资源：一般情况下，系统资源（例如CPU等）大部分是由应用和参数设置不合理导致的，并非系统资源真的不够”用”。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)