一、测试背景和目的
在需求调研开始，测试人员需要明确的测试目的，那么首先得清楚项目本身情况，针对不同的项目情况也会有不同的目的，根据项目情况一般可以分为以下六种情况：
1、完全新建系统
完全新建系统意味着被测试系统没有业务数据作为参考，也没有业务人员能进行有效的进行预估业务量，就不能转换出业务指标值（TPS/QPS）,那么我们通常的测试目的如下：
- 测试应用系统最佳处理能力和极限处理能力,供需求方和开发进行评估。
- 测试应用系统是否稳定
- 测试应用系统是否可靠
- 测试应用系统瓶颈，并提供扩容意见等
2、改造新系统
改造新系统一般可以通过老系统业务量进行分析，再结合业务人员根据业务发展情况进行评估。通常的测试目的如下：
- 测试应用系统是否满足当前业务量需求。
- 测试应用系统是否满足N年后业务量需求
- 测试应用系统是否稳定
- 测试应用系统是否可靠
- 测试应用系统瓶颈，并提供扩容意见等
3、版本升级系统
版本升级系统有可能是针对缺陷修复升级，也有可能是针对业务需求变更升级。如之前未做过性能测试，按照改造新系统方式目的设置。如已做过性能测试通常测试目的如下：
- 测试应用系统最佳或极限处理能力与之前测试结果对比分析。
- 测试应用系统是否稳定
4、线上运行系统
线上运行系统要求进行非功能测试，一般是线上遇到非功能测试缺陷，很难复现。通常测试目的如下：
- 模拟生产环境运行情况，找出非功能测试缺陷配合开发进行优化复测。
5、采购型系统
采购型系统要求进行非功能测试，一般是对多家厂商的产品进行测试，给出对比测试结果，通常测试目的如下：
获取固定并发用户数下，各厂商的指标对比情况（TPS，响应时间，CPU使用率，错误率等）
6、软硬件选取
软硬件选取进行非功能测试，主要式在保持其他情况一致的情况下，性能情况对比。
获取在不同软硬件处理能力，根据业务情况，选择性价比最高的软硬件。
二、测试范围的确认
测试范围主要是在调研过程中，确认被测系统与周边系统关系以图形的方式展现，并以明显的标记标注被测系统和文字的方式说明被测交易具体与哪些系统进行交互。
三、被测系统架构分析
架构分析的目的主要是需要确认被测试系统使用的开发语言/开发框架、通信机制/协议、中间件、数据库、是否采用应用集群、是否采用数据库集群、是否存在备份机制（热备/冷备）、负载均衡机制等。为后续设置具体的测试策略，环境部署，监控手段做铺垫。
四、业务模型分析
业务模型分析主要是为了得到更加真实模拟线上运行场景，保证测试的覆盖率。通过根据系统情况分为有业务数据参考（生产运行日志）和无业务数据参考两种情况
五、有业务数据参考
有业务数据参考系统可按照如下方式进行分析提取业务模型：
实例
| 案例编号 | 接口名称 |
交易占比 |
| 1 |
create_instant_trade（即时到账） |
6% |
| 2 |
create_ensure_trade（担保交易） |
5% |
| 3 |
create_split_trade（分账） |
3% |
| 4 |
create_settle（结算） |
5% |
| 5 |
create_refund（退款） |
0.5% |
| 6 | query_trade（交易查询） | 80.5% |
六、无业务数据
通过与业务人员或者开发人员沟通，引导业务人员根据业务使用情况，进行业务模型的大概预估。具体方法如下
- 确认被测业务交易，业务交易选取规则如下：
- 使用比较频繁的交易（业务人员根据使用情况提供）
- 使用不是特别频繁但是交易涉及数据量比较大的交易（业务人员根据使用情况配合开发人员提供）
- 交易逻辑复杂比较高的交易（开发人员根据代码逻辑提供）
- 确认各业务交易占比：
- 业务人员根据使用情况进行各选取交易比例预估
- 如果没有业务使用的话，可以参考同行（非功能测试人员根据相关进行建议并让业务确认）
七、用户分析
| 需求类别 | 需求要点 | 性能需求描述规范说明 |
| 用户分析 |
用户数量需求 | 本系统各类别用户的数量分析 |
| 用户类别需求 | ||
| 系统支持并发操作最大用户数量 | 并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。 | |
| 系统支持的最大用户连接数量 | 系统能够同时接入（或登录）的最大连接用户数。 一般而言，并不是所有接入（或登录）的真实用户都在实时进行操作，部分用户接入（或登录）系统后，暂时不做业务操作，这样的用户操作习惯要求被测系统提供额外的系统并发接入能力。 |
八、 测试指标
性能测试常用指标确认如下：
| 大类 |
指标项 |
指标量值 |
备注 |
| 业务类 |
系统处理能力(TPS) |
二八法则 |
高峰期TPS |
| 一般交易响应时间 |
<3秒 |
端到端的响应时间 |
|
| 复杂交易响应时间 |
<5秒 |
针对大表查询交易 |
|
| 交易成功率 |
>=99.9% |
|
|
| 系统资源 |
CPU使用率 |
<=80% |
|
| 内存使用率 |
|
无明显上升趋势。 |
|
| 稳定性 |
运行时间 |
24小时 |
CPU使用率、内存使用率、磁盘繁忙率等比较平稳，无明显波动。 |
- 系统处理能力（TPS分析）分析方法：
沟通并估算出高峰日交易量为S1（单位：笔），获取到高峰时间段S2(单位：小时)，如果需要满足N年后业务处理能力，需要给出业务递增百分百S3。
满足当前时间业务处理能力T1（单位：笔/秒）=(S1*0.8)/（S2*0.2*36000）；
满足N年后业务处理能力T2（单位：笔/秒）=T1*(1+S3)^N；
- 响应时间获取：
响应时间指标通常根据系统方式分为接口类、客户端访问类，具体时间指标客户端访问类和是由业务人员根据业务情况，指定响应时间，
通常标准为：1-3秒可以通过；3-5秒谨慎通过；5秒以上不能通过。接口类响应时间通常标准为：记账类：200毫秒 单笔查询：500毫秒
九、预埋数据量分析
预埋数据量的目的是根据生产业务量情况和数据库表数据存储方式进行预埋数据，验证在一定数据量情况下，数据库性能对本身业务交易性能的影响。一般分为从生产导入数据和自己构造数据。
生产导数主要是把生产数据脱敏导入测试库中，这样的数据更加真实。
自己构造数主要是根据每天交易量乘以该表存储的时间或者统计线上数据量的方式（需要了解该交易涉及表数据存储）， 基础数据构造，应满足数据类型以及量级的要求，避免数据热点
query_balance
| 能 | 服务 | 数据库 | 数据表 | 操作 | 线上数据量 | 当前测试环境 |
| 下单 |
mag | |||||
| ma-web | member库 | m_member_identity 会员查询 member_account 会员账户信息表 |
query | 5320w | 3053w | |
| dpm | dpm库 | dpm_outer_account 外部户 |
query | 10450w | 5735w | |
| vouch | vouch库 | trade_vouch 交易凭证 | insert | 11559w | 2722w | |
| tss | tss库 | trade_order 交易订单 acq_trade_order_ext 收单交易扩展 split_party分账信息表 |
insert | 9152w 10670w 3181w |
2491W 3200W 3260w |