Simone性能测试需求调研方案编写+测试准备
的有关信息介绍如下：
大家好，我是阿沐，我来了啊~
01.性能测试流程介绍
02.性能测试需求调研
03.性能测试计划
04.性能测试方案编写
05.性能测试准备
01.性能测试流程介绍
性能测试流程
1：性能需求分析确定（确定测试指标值，对象模型，环境，项目组人员等）
2：测试方案确定（方案评审确定测试场景覆盖，指标值，模型转换，环境，计划，风险等）
3：测试准备阶段 （环境数据准备，性能脚本准备，监控准备）
4：测试执行阶段 （场景执行指标不达标时可定位具体瓶颈然后调优）
5：测试报告编写 （编写测试报告，记录测试结果，优化对象等，需要进行评审）
6：测试总结 （总结调优手段，经验等）
02.性能测试需求调研
需求调研之前，我们需要了解不同人眼中的性能表现（性能角度）。
通过不同角度看到系统的性能表现，我们应该明白，不同的角色看待问题的点不一样，作为专业的性能测试，就需要将各角度都考虑到位，并且能够沟通到位。从而设计出合理的性能测试方案。
换句话说，我们需求调研也是为了能够设计出合适的方案。
在进行性能测试之前，还需要明白测试的目标背景是什么。
主要可分为以下三种：
新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到一定值。
性能需求提出者：
1：客户即使用该系统的负责人
2：产品经理
3：项目组领导
针对不同的性能提出者，我们都需沟通清楚。并且对于不合理性可以提出建议。 比如：
1、只有2000人使用的OA系统，客户要求并发用户2000。
2、对于公司业务每月新增20%，而性能指标还按照旧版本设定。
3、新开发系统部署生产单台服务器，要求能支撑10000并发等。
如何进行性能需求调研呢？
需求确认中首先需要确定需求合理性。跟据公司项目的具体去定标准，而不是漫无根据的说要达到多少的指标。
下面着重举例分析下需求场景。
比如产品经理要达到10万个并发
需求合理性提问： 假如说是凭空想的，那么肯定让他说出个跟据来。假如说是因为生产服务器有10万个用户在使用，那么也不需要并发10万个，而只要测试能容纳10万个用户操作。 这就是在线用户和并发用户的区别了。
性能需求调研场景一
产品经理说的要达到10万个并发。
通常按照性能测试来讲，如果涉及到并发的话，通常业务最常见的就是抢购，我们可以配合集合点。那么如何满足验证产品经理说的10万个并发尼？ 这就需要从环境说起，首先这个10万并发要求是怎么来的？ 首先需求就需要分析，不可能让产品经理毫无跟据的在提需求。 假如10万用户并发是从生产上统计出来的，比如运维可以统计后台，在某一天最高峰时期某业务有10万个用户并发请求了。 那么就需要跟据业务实际来，是10万个并发一直请求持续多长时间，还是10万个并发就完事，生产服务器的配置是如何的，机器数量是多少。这都需要统计。 最后跟据测试环境机器进行折算。
需求折算： 假如说生产是10台服务器，8核cpu32G内存，最高达到了10万并发。并且持续5分钟。 而测试环境机器就1台，8核cpu32G内存。生产平均一台支撑了1万并发，而测试环境机器只有一台，按理来讲测试就需要满足1万并发，但是我们不能忽略集群带来的消耗，所以需要再设置2对，4台查看支撑的并发是否可以成倍。
环境是影响测试结果的重要因素。比如说你生产机器和测试的机器型号品牌什么的完全不一致，那么就无法通过测试结果去计算生产的支撑。只能说可以继续优化被测对象。
注意：在性能测试环境中，需要与项目组确定，尽量将性能测试的服务器和生产机器型号保持一致。可以的话，和生产完全一致最好，避免折算的差异太大。
性能需求调研场景二
客户提出使用该系统的人有将近10万个人。
分析：
1：10万个人使用系统，它的时间是怎样的，是每天工作8小时，还是说10万个人不分日夜24小时使用，如果只是这一点测试目标的话，那么其实按照服务器的配比查看单台的在线用户量能否达到即可。这也是通常所说的容量测试 备注：通常这种情况，我们应该提醒需求，除了这个容量测试之外，还应该统计出每天完成的业务量，比如说系统每天要完成1000万笔业务，那么系统应该达到怎样的处理能力？
计算 ：
系统运行8小时，按照二八原则，高峰期20%的时间完成80%的量 8*3600*0.2=5760秒高峰时间 1000*0.8=800万的量。 那么TPS需要达到：8000000/5760=1389笔/秒 （这就是咱们需要达到的TPS）
性能需求调研场景三
需求提出10万个人使用系统，但是响应时间需要在3秒之内的要求。
分析：
一定要记的，10万个人使用系统，只是在线用户，这是一个容量。只要能容纳这么多用户即可。以上需求其实就是能容纳10万个人使用系统，然后操作起来可以3秒响应。但是这种需求，其实是不清晰的，因为3秒响应是在怎样的压力下的响应，没有说明。只是说10万个在线用户。那么在线用户操作的频率是怎样的，也就是我们要设置的思考时间是多少。所以需要确定一下思考时间。
性能需求调研场景四
产品经理更新了系统版本，有需要性能测试时，提出与上个版本保持一致。
分析： 在这种情况下，我们应该确定更新版本后用户是否有增长，如果业务增长了，那么压力肯定大了，直接和上个版本一样的性能，很有可能就满足不了增长后的业务需求，所以可以提出需要优化性能，在上个版本的基础上优化。
性能需求调研场景五
项目组领导提出新系统上线能否满足线上支撑
分析：
对于新系统能否满足上线，这就需要知道上线后系统有多大的量。比如说一天要处理多少笔业务可以预估一下。 得到了每天处理的业务数量那么就可以进行性能tps折算。
性能需求调研场景六
项目组领导提出系统能否满足3年后的性能
分析：
可以让运维支撑一下，统计每一年，每一月的业务量的增长趋势，大概算出3年后每天的业务量。同时还需要将3年后的数据量批量插到环境中进行测试。将性能测试服务器上的环境全部按照3年后的搭建即可。
性能需求调研场景总结
通过以上的性能需求场景示例，我们可以看出做性能，我们先要确定目标，然后确定环境，确定铺底数据，然后我们才可以按照要求设计出不同的场景。在需求沟通中一定要与项目组人员对专业名词理解一致，比如并发用户，在线用户，注册用户等。
不过在确定需求的合理性，以及达到的目标，环境后，我们还需要确定被测业务。 也就是系统业务非常多，不可能全部测试。需要按照一定原则进行抽取。
性能需求业务抽取
根据业务量大小选取典型交易，一般通过统计生产系统TOP10 、TOP20确定；
重要系统选取占总交易量60%的交易，做为基础业务模型；
核心系统选取占总交易量80%的交易，做为基础业务模型；
选取生产系统中消耗资源最多，或者耗时最长的业务交易；
选取生产系统中交易路径最长的业务交易；
选取生产系统容易发生故障的业务交易；
为满足其他特殊测试目标需要选取的业务交易；
性能需求业务模型
在抽取了需要测试的业务或者接口后，那么我们需要确定比例，也就是业务模型，这个业务模型运维可以统计出来，比如跟据一天的生产日志，统计出各业务的比例，或者由产品经理给出。 假如说得到以下模型：
性能测试计划
编写测试计划可将性能测试中涉及到的工作按照流程全部写上，并且给个大概的完成时间。跟据不同的被测对象时间周期也会有差异。可以整个表格具体标明。
03.性能测试方案编写
性能测试方案定义
方案中需要跟据需求确定测试对象，术语定义，业务比例，指标值，系统架构，环境配置，准入准出，风险评估，测试场景等。 注意：性能测试方案必须经过评审！
04.性能测试执行准备
性能测试准备
在执行性能测试之前一定要检查环境是否和方案中环境一致。包括机器的硬件配置，软件版本，网络环境，数据量。
文章首发于微信公众号：程序员阿沐，转载请注明出处！
