聊聊性能测试开始前的准备工做
以前的博客有介绍过完整的性能测试的流程和性能测试需求分析相关的内容，然而在实际的性能测试工做中，测试开始前也有不少的工做要作。html
这篇博客，就聊聊性能测试的第一步工做：获取测试需求，到底须要哪些东西。。。web
性能测试流程导图docker
1、相关设计文档数据库
一、系统架构图：了解被测系统的技术架构，包括从客户端到DB的周转流程、应用服务器、中间件等；缓存
二、网络拓扑图：和系统架构图相似，这个更多的是体如今不一样层级之间的网络拓扑关系，也能够和系统架构图结合在一块儿，根据项目具体状况而定；服务器
三、需求说明文档：了解被测系统的业务流程，不一样模块间的关系，便于后面的业务场景建模；网络
四、接口设计文档：大多性能测试都是经过调用模块间的API来进行模拟并发，了解业务模型对应的API，包括协议类型、方法、传参类型、入参、出参等信息是很必要的；架构
五、数据库表设计文档：测试过程当中产生的数据会写入哪一个库哪一个表，不一样的API参数会对哪张表甚至哪一个字段产生什么影响，熟悉“数据流”是很必要的一件事情；并发
2、确认性能指标or目的app
一、测试目的
| 测试目的 | 说明 |
| 并发测试 | 测试系统在必定条件下可承受的最大并发数 |
| 容量测试 | 测试系统在必定配置下的最大服务能力 |
| 配置测试 | 验证系统在不一样配置下的性能表现，为性能调优和扩容提供重要参考 |
| 验收测试 | 验证被测系统是否知足实际的业务须要或者验证系统是否具备它说宣称的性能表现 |
| 稳定性测试 | 验证系统在必定的压力下长时间正确处理请求的能力，通常时间越长，系统稳定性越好 |
| 多节点测试 | 验证系统在服务集群下的一个负载均衡能力 |
二、测试指标
| 指标名称 | 指标数值 | 指标说明 |
| TPS | 100 | 每秒事务数，很重要的一个指标，衡量系统的处理能力 |
| RT | 95%、99%、99.99% | 百分比请求的响应时间，即n%之内的RT请求响应时间是多少，百分比越高，RT越低，系统越稳定 |
| error | 0.1%、0.01% | 错误率，便可接受的请求失败的占比 |
| Cache | 90%、95% | 缓存命中率：命中率越高，使用缓存的收益越高，系统的性能越好 |
| CPU | 75%、90% | CPU使用率，通常来讲75%是一个阈值，超过85%就须要重点关注 |
3、性能测试环境
一、被测系统环境：FAT（生产环境）、UAT（验收环境）、预发布环境等；
二、环境类型：docker容器、虚拟机或者其余类型；
三、web/app/service/db等服务器配置，好比nCnG；
四、配置信息
| 配置名称 | 配置信息 |
| JVM堆内存分配 | JVM的堆配置的内存大小 |
| 最大链接数 | 中间件、DB的最大链接数 |
| 线程池配置 | 线程池数量、回收策略等 |
| timeout | 超时时间 |
| 异常/错误重试次数 | 请求异常或错误时的重试策略、次数 |
五、服务器/DB登陆帐号、密码，服务部署路径、日志路径等；
六、挡板/Mock：某些依赖关系较复杂的系统或者模块，是否须要挡板？若是须要挡板，是来提供？
4、预埋数据
一、基础数据：好比电商系统的库存数、SKU、用户信息等；
二、预埋/铺底数据：根据生产实际的数据量对测试环境的DB进行数据预埋，尽可能和生产保持一致或能够等量换算（对应的BD实例名）；
三、测试数据：测试数据如何生成？数据生成规则，好比加解密、随机生成等；
四、垃圾数据：每轮测试产生的垃圾数据如何隔离或者清理；
五、数据脱敏：若是是在生产环境进行压测，如何进行数据脱敏或者数据隔离防污染策略；
5、接口说明
被测系统业务场景对应接口协议类型，好比：
| 协议类型 | 所需提供的信息 |
| HTTP | 方法、参数类型、host、port、path、请求响应报文等 |
| SCOKET | host、port、请求响应报文等 |
| DUBBO | 服务注册类型（zookeeper）、版本、timeout、重试次数、最大链接数、同步/异步、接口名、方法、参数类型、value等 |
6、测试开始前确认
一、容器：镜像克隆成功，服务部署完成，且完成功能性校验；
二、压测机：测试机准备完成，并完成性能测试环境的调试验证；
三、工具：相关监控工具等部署设置完成，好比服务器监控工具、DB监控工具等；
四、网络：网络链接通畅（若是有防火墙策略，运维同事应在测试方案评审开始前准备完成，并告知相关人员调试验证）；
五、数据：基础数据、预埋数据、测试数据准备完成（正确+可用+数据量级达标）；
7、需求变动说明
一、涉及范围：需求变动类型（业务场景、功能变动等）、环境交付日期、服务器地址、配置信息变动等；
二、提早说明：变动致使延期交付或提早交付的具体工时（能够精确到半天或者小时），最晚多久，须要提早通知；
三、应对策略：针对不一样变动类型、影响范围、风险程度、时间等因素评估如何处理，好比：打回、需求顺延排期等；
8、交付日期和deadline
一、交付预期时间：方便性能测试同事根据需求紧急状况、优先级等预估工时，进行工做排期；
二、deadline：即生产发布时间，根据交付时间和生产发布时间，确认具体的工做安排（好比从交付到上线只有一周，如何完成任务拆解和细化，不一样人员安排不一样的工做，里程碑等）；
以上内容，仅供参考，具体的测试需求，还须要根据具体的项目类型、团队人员构成、职责等进行合理灵活的取舍。。。