[精华] 性能测试需求沟通方法
接触过性能测试的都知道，只有对被测系统充分了解后，才能有针对性的选择被测对象，进行方案和用例的设计。这会使刚开始从事性能测试的新手茫然，不知从何下手。
从去年开始我就想把分析思路总结成方法贡献出来，但是由于能力有限，很多点是发散的，只有在实际过程中才能逐一进行阐述，进而无法上升为通用的方法论。最近带了徒弟，徒弟会经常问到一些问题，我会反反复复跟他讲解。讲得多了，思路也清晰了。
分享给大家，希望借此提高沟通效率和测试方案的质量。
沟通矩阵
|
重点 |
明细 |
成果 |
|
了解背景 |
项目开发进度或重构优化的重点；测试最早开始日期，测试最晚完成日期；技术负责人 |
确定测试时间周期，项目干系人 |
|
需求搜集与定义 |
被测对象，测试类型，性能预期 |
用专业术语定义原始需求（对方的需求） |
|
被测对象分析 |
被测模块在系统中的部署，组件类型，业务逻辑，与IO有关的操作 |
确定测试对象和测试类型（根据对系统的了解对对方的需求进行补充或裁减） |
|
了解协议 |
测试接入点与被测服务通讯的协议 |
确定测试工具。 |
|
选择用例 |
根据被测对象的特性和测试类型列举用例，考虑时间成本和重要程度优先级选择用例 |
确定用例。明确每个参数在测试时具体值，固定值或随机值范围 |
|
模拟测试环境 |
可测性，测试数据准备，机器数量 |
确定机器到位和测试环境搭建期限，环境准备事项列表 |
这几部分不是严格按照流程排序的，可以穿插进行。随着对被测系统的了解加深，逐步修正沟通成果，达成测试方案，根据测试方案制定测试计划。
沟通完毕后，根据沟通结果整理出接下来需要开发配合进行的环境准备事项列表。
如下是针对沟通重点的一些具体分析方法：
为什么要了解背景？
了解这个测试任务的紧急程度，为了合理安排测试时间。
了解被测模块的开发进度，性能测试需要在代码开发完成、功能测试与回归测试结束后，测试环境无其它人使用的情况下进行。不允许边开发边测试。
了解优化的重点，可以有针对性的设计用例。
了解干系人，知道什么事情跟什么人沟通，报告提交给谁。
如何进行需求分析和需求定义？
往往提需求的人对需求的描述是他自己的语言，我们需要用专业的指标来定义他的需求。原始需求常出现的关键字有：“并发量，日PV，并发用户数，性能测试，压力测试”，等。首先我们要清楚测试类型的定义及与其相关的指标，继而引导提需求的人定义需求。
日PV可以计算出平均每秒的处理请求数，得出平均吞吐量取值，其两倍值为峰值；并发用户数，对应测试请求中携带的用户标识个数，数据库或内存中保存的用户记录数，并发连接数；并发量，一般可以理解为吞吐量。
最常见的性能测试类型（或方法）有五种：容量测试，可靠性测试，稳定性测试，基准测试，并发测试。
l 容量测试：使用负载测试方法，通过逐步提高对被测系统负载，用峰值吞吐量和90%响应时间来评估系统容量。这个过程包括对系统性能瓶颈的定位，性能调优，使资源利用率最大化，给出系统最优情况下能承载的最佳性能指标。
l 可靠性测试：通常使系统达到稳定的高负载后，持续压测10分钟以上。评估点主要有：失败率、掉线率、丢包率、超时率，业务是否异常。
l 稳定性测试：通常使系统达到稳定的高负载后，持续压测10分钟以上，观察吞吐量曲线稳定性。
l 基准测试：获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据。与容量测试不同的是，这个值不是系统容量。
l 并发测试：根据手段可以分为几种。【基准测试】：大量并发连接，看服务处理的响应时间是否正常；【稳定性测试】：被测系统在频繁建立和释放连接情况下系统是否能持续提供服务；【可靠性测试】：并发用户在一定高负载下同时访问临界数据，暴露系统缺陷；【暴力测试】：获取导致系统暴露缺陷的并发连接数。
这个几个测试类型执行的顺序：一般先做可靠性测试、稳定性测试、并发测试等，保证系统运行没有功能性缺陷后才进行容量测试和基准测试。
如何进行被测对象分析？
这是水最深的地方。
最关键的是要抓住一切与IO有关的操作。因为CPU的运算速度跟IO的存储速度不是一个数量级的。只要有严重的IO耗时都需要纳入到被测试对象的路径中被覆盖到。
文件读写
日志是同步还是异步的。日志级别需要设置成与正式环境一致。对账日志需要进行稳定性测试确保无误。
数据库读写
数据库类型：MYSQL，TDB，TAF DB。数据规模：数据长度与总记录数。查插删改操作的比例。查询需要准备一定规模的数据量和建索引，不能重复查询同样的数据。插入操作可以不准备测试数据，不能重复插入同样的数据。修改的性能直接由数据量和索引的多少决定。删除操作单独测试的很少。
网络调用
分布式服务以及测试客户端必须部署在同一网段内，避免网速成为瓶颈或导致结果不稳定。
缓存
缓存类型：MMAP，TAF DCache。增量或全量加载频率，回写策略。数据长度和数据量。数据访问算法。关注缓存的机制主要是为了判断是否要作为测试对象。如果有缺陷风险，需要测试稳定性。否则一般进行容量测试，测试全命中、不命中，或者指定命中率的容量。如果有全量加载的操作，可以考虑做基准测试，给出全量加载时用户的体验。
协议的长短连接
长连接要考虑一般情况下的并发连接数；短连接要考虑并发测试，测试大量连接建立和释放的稳定性，拒绝服务攻击等。
另外，还要注意有没有大内存排序等操作。
如果是成熟的组件，可以不作为重点测试对象。
如何选择用例？
根据测试类型的不同来选择测试用例。
容量测试一般在如下三种类型中只选择1个用例来测试：
1. 覆盖业务逻辑最多性能最差的；
2. 业务被调用频率最高的；
3. 性能最优的。
这样可以根据测出来的基准值区间，接口调用比例，估算业务模型下的性能情况。
记住：不是所有接口都需要测试容量！容量测试的用例选择只跟性能有关系，一切与性能无关的东西都可以不考虑。
如何模拟测试环境？
做性能测试的理想环境就是与正式运营环境一摸一样。可惜的是，我们很少能够做到。唯一能做的就是尽可能的接近真实，以最小的代价来模拟。
环境检查表
|
测试数据准备完毕，数据库结构与正式环境一致，并建立了相关索引（可选） |
|
被测接口经过自测且功能正常 |
|
测试环境没有连接到运营环境 |
|
测试环境连到网管系统（可选） |
|
日志级别正确：测试环境日志级别须与正式环境一致 |
|
测试环境部署的服务版本及其配置必须与正式环境发布的一致 |
|
被测模块已经完成开发，且通过了功能测试 |
|
测试环境没有别人使用 |
|
客户机和服务器在同一网段内 |
|
容量测试必须准备与正式运营服务器硬件配置相同的测试机器 |
|
被测服务没有设置流控，最大并发数或其它影响性能的阀值限制 |
服务器与客户机台数
正常情况下同样的硬件配置部署服务的性能应该比部署压测工具的性能要好，最经常出现的是客户机压不满服务器的情况。因此当有多台对等的服务器通过负载均衡提供服务的时候，我们只需要在系统中部署一台同样功能的服务器即可。后期可以通过测试N台服务器的扩展性规律与基准值来预估系统扩容可以达到的容量。
可测性
在一个请求的处理链路中，途经的模块都可能成为瓶颈。容量测试时，我们需要让瓶颈出现在被测对象身上，而非被其调用的其它模块上，只有这样才能把被测对象“压满”。这种情况下，可以根据需要对其它模块进行模拟。容量测试时为了尽可能接近真实的系统，被模拟的模块往往只是一次空操作的调用；而可靠性测试时，可能需要模拟该模块的处理延时，以发现更多的问题。屏蔽与模拟一次空操作的区别就在于一次调用的开销，屏蔽实现起来简单，但需要直接修改被测模块的逻辑，如果被屏蔽的模块实际开销很大，不建议采用。
有时候为了使系统可测，必须对某些业务逻辑进行修改，比如强制不缓存。修改这部分逻辑来达到系统的可测性。
流控
很多服务框架都可以设置流控，在容量测试时，需要取消这个限制，否则测试结果可以直接根据流控参数计算出来，根本不需要多此一举。
测试数据准备
尽量与实际运营环境一致。主要考虑的是数据量对性能的影响。
沟通过程中，始终铭记在心的一点：提需求的人，必然是贪婪的。而我们只能在有限的时间内把最重要的事做好。