性能测试技术笔记 (一)：如何快速上手压测工作

新年第一个工作日，继续整理之前的技术笔记。

前面通过三篇的内容，将自动化测试相关的技术笔记做了整理汇总。

这篇内容，主要是我刚开始做性能测试时的一些记录，对新手或者刚进入一个新项目的同学，应该有所帮助。

一般我们在刚介入一个项目时，我认为可以从如下几个方面来快速的上手压测工作。

熟悉业务特性

无论是做什么类型的测试工作，都脱离不了业务。

我们的被测对象，也是基于系统架构的用代码实现的高度具象的业务系统。

如果是专职做性能测试，或者刚介入一个全新的系统进行压测，想要短时间内了解业务细节是几乎不可能的。

但为了更好的快速开展工作，我个人的经验是快速熟悉业务特性，结合自己的经验对系统有个大致的了解。

什么是业务特性呢？可以参照下面几个例子：

1. 电商下单业务：典型的先读后写类型，要考虑库存、事务的一致性，还有响应时间的范围；

2. 大数据 &报表业务：典型的读场景，可能会涉及到缓存或者消息队列，甚至是批处理；

3. 金融风控信审业务：这种业务对响应时间没有太高的要求，但业务链路较长，不同系统间的交互要考虑；

4. 语音识别搜索业务：涉及到语音文字的识别转换、准确率和命中率，计算密集型业务要更关注内存资源；

上述几个例子只是参考，其实最核心的思路在于：了解业务有什么特点，对响应时间、事务一致性的要求，可能的技术实现方式是什么，用到了什么技术组件，压测时要关注哪些指标。

了解系统架构

聊完业务特性后，被测系统的系统架构是一定要了解的。

因为我们的工作对象是具体的系统，而且压测要关注技术指标，关注请求处理的过程以及耗时等情况。

一般来说要了解被测系统的系统架构，可以通过如下几种方式：

1. 系统架构图 &网络拓扑图；

2. 模拟几个请求，借助链路追踪工具来绘制请求链路；

3. 如果都没有，通过监控观察请求的变化，挨个摸底；

4. 看业务需求的 prd，了解业务之间的关系，然后映射到具体的服务和接口；

上述几种方式是我常用的几种方式，在具体工作中要灵活变通，而且这种对系统架构摸底和请求链路的了解过程，也是个人快速学习和成长的过程。

下面是一个请求被处理的过程，也是一个较为完整的常见微服务架构，供参考。

团队工作方式

团队工作方式，不仅限于性能测试团队或者测试团队，而是从需求到发布整个软件研发过程各个团队是如何协同配合的。

刚进入一个新的团队或者介入一个新项目时，可以从下面几个方面去熟悉，主要包括：

1. 流程：包含需求评审、提测、UAT、灰度和生产发布等主要流程以及时间节点；

2. 环境：开发环境、测试环境、UAT 环境以及生产环境，主要涉及域名、权限、负责人等；

3. 基础工具：配置中心、注册中心、需求 &缺陷管理平台、CICD 流水线工具、监控分析工具等；

4. 测试工具：包含压测工具、抓包工具、造数工具、mock 工具、文档管理工具、协作办公沟通工具等；

5. 测试方法：之前怎么做压测？对指标有没有标准或定义？测试方案测试报告的撰写要求等；

6. 协作人员：不同业务域或者业务系统的研发/运维/DBA 是谁，跨团队的沟通协作方式等；

以上几点是我个人看来比较重要的一些点，快速了解这些之后，也会有助于工作更好的开展。

以上内容来源于我之前做性能测试工作时的笔记内容，稍加提炼和修改。

下一篇我会聊聊做性能测试前期的一些准备工作如何开展。