1.性能测试需求分析
需求调研：为了合理评估与制定系统的性能指标，需求调研是必备的过程，需求调研主要包含一下几个方面内容
测试目的调研>系统信息调研>业务信息调研>文档资料调研>被测应用的环境调研
- 目的调研：调研开始后，首先了解本次测试的目的，常见的有：
- 概念验证测试
- 选型测试
- 并发测试
- 性能验证及验收测试
- 性能诊断及调优测试
- 稳定性测试
- 高可用测试...等等很多
- 系统信息调研
- 系统类型：系统的基本特性区分，偏向那种资源消耗型，例如cpu消耗型系统，IO消耗型系统
- 架构部署：系统的整体架构，技术架构，服务器部署方式
- 技术信息：系统运行的平台，数据库产品，使用的中间件，协议及通讯方式等。
- 系统版本信息：了解系统主要版本的变化内容，当前的生产版本及最新版本，重点关注本次待测版本以及与其他相关系统的版本状态。
- 业务信息：支持的业务类型，业务范围与功能，与其他系统的业务关系等。
- 系统历史运行的情况：目标TPS，RT，用户数，PV等
- 系统数据的规模：将来的系统使用规模，历史系统数据规模。
- 采集硬件指标：例如cpu利用率，内存利用率和可用内存等。
- 系统架构：（物理架构与逻辑架构，包括中间件产品与配置，数据库配置）物理架构规定了组成软件系统的物理元素（各种硬件设备），这些物理元素之间的关系，以及他们部署到硬件上的策略。
- 系统架构（物理架构与逻辑架构，包括中间件产品与配置，数据库配置）物理架构规定了组成软件系统的物理元素（各种硬件设备），这些物理元素之间的关系，以及他们部署到硬件上的策略。
- 逻辑架构让我对系统的逻辑组成进行有所了解，进行测试的时候能够清楚划分问题出现区域。逻辑架构展示软件系统中元件之间的关系，比如用户界面，数据库，外部接口等等。
- 了解系统是否有归档机制？大家都知道数据库中数据量大时对性能是有影响的，如果有归档机制，可以把一些无用或者过时的数据移到归档库，这样就减少了当前库中的数据，有利于提高系统性能。
- 系统是否与第三方系统有关联关系？这决定在测试时我们要做档板。
- 业务信息调研
- 基本业务功能：系统的基本业务概念以及系统的与具体功能业务种类。
- 关键业务逻辑处理流程：关键业务的业务流程，交易路径，交易数据，交易流程与时序图。
- 交易列表：调查业务系统全部交易清单，了解交易的组合关系，执行顺序等。
- 交易量信息：在不同时间粒度下统计单个交易处理量以及总交易量信息，业务量分布。
- 业务目标/业务拓展计划（采集业务并量化业务）：目前的生产业务量和用户数以及系统预期业务目标（生产业务量，用户数，tps，响应时间）和本次测试预期业务指标。
- 采集业务性能指标，例如RT，TPS等。
- 重点关注内容：
- 典型交易的处理逻辑与交易路径，了解系统典型交易的处理逻辑和交易路径，其中典型交易是指具有一定的重要交易，主要包括几个方面：
- 业务功能的代表性
- 交易典型的代表性
- 交易量的代表性
- 交易路径的代表性
- 处理逻辑的代表性
- 开发挑选的交易
- 了解业务扩展趋势，比如业务年增长率是多少？未来的业务量是多少？比如系统的需求中说到要满足未来三年业务增长需求，我们在测试的时就可能需求生产三年的存量业务数据，对于关系型数据库来说，数据量大时对性能的影响还是比较明显的。
- 采集业务发生时段，比如一天产生20000订单，而高峰1小时就能完成10000订单，而不是平均每小时，主要是在估算tps与并发用户数时用到。
- 采集在线用户，活动用户，业务分布，有些系统用户量特别大，会对系统造出瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。
- 文档资料调研 (前期系统测试资料)
- 功能规格说明书
- 系统设计文档
- 生成运用文档
- 当前系统测试资料
- 当月日报
- 月交易统计
- 日交易量统计（正常日/高峰日/特殊日）
- 业务调用涉及到角色包括：业务，开发，客户，产品，运维，dba等；
- 环境调研
- 环境调研主要针对生产环境的硬件，软件，网络进行调研，并完成《性能测试环境需求表》填写
- 在条件允许的情况下，尽量采用与生产环境同等相同的软硬件及网络环境，非关键配置中，可以适当降低要求；
- 当测试与生产软硬件环境配置存在差异时，须在后续工作中对差异部分进行分析；
- 业务调研（模版自行准备）
通过以下方向，可以产出：需求调研报告，性能测试需求调研表，性能测试环境需求表，测试护士节需求表
- 项目背景
- 系统架构说明
- 系统拓扑说明
- 测试范围说明
- 交易路径说明
- 需要测试的特性
- 不需要测试的特性
- 性能测试环境需求表
2.性能测试需求评估
在实施性能测试之前，需要对被测试项目做相应评估，主要目的是明确是否需要做性能测试和确立性能点，明确该测什么，期望值是什么？测试期望也会根据情况评估，要求被测系统能否满足将来一定时间段的压力。
判断是否可进行性能测试可以从几个方面考虑
a，从业务角度分析，如果一个项目上架后用户量操作比较大，频率较高，就有做性能测试必要，反之，则，，，无论系统多大，设计如何复杂，并发性能测试是没有必要做的，前期可以否则；
b，从系统架构角度分析，如果系统采用框架是较老的系统框架，只是在此框架增加一个应用或功能，其实没有必要做性能测试，反之新框架，可以考虑负载测试；
c，从实时性角度分析，如果项目要求某个功能响应时间必要在指定范围内，这个有并发测试的可能性，在大并发量场景下，查看这个功能的响应时间；
c，从数据库角度分析，很多情况下，性能测试是大数据量的并发访问，修改数据库，而瓶颈在于数据库连接池的数量，而非数据库本身的负载，吞吐力。这时可以结合dba的建议来决定是否做性能测试；
e，交易处理做了时间隔离限制，不需要进行性能测试；
性能测试业务评估范围：
明确相应的性能点，可以从5个纬度进行确认：
关键业务
日请求量
逻辑复杂度
运营推广计划
其他
3.性能测试测试指标
4.压力与容量预估