性能测试需求调研分析方法

1、测试背景和目的

    在需求调研开始，测试人员须要明确的测试目的，那么首先得清楚项目自己状况，针对不一样的项目状况也会有不一样的目的，根据项目状况通常能够分为如下六种状况：

一、彻底新建系统

     彻底新建系统意味着被测试系统没有业务数据做为参考，也没有业务人员能进行有效的进行预估业务量，就不能转换出业务指标值（TPS/QPS）,那么咱们一般的测试目的以下：

1. 测试应用系统最佳处理能力和极限处理能力,供需求方和开发进行评估。
2. 测试应用系统是否稳定
3. 测试应用系统是否可靠
4. 测试应用系统瓶颈，并提供扩容意见等

 二、改造新系统

　　改造新系统通常能够经过老系统业务量进行分析，再结合业务人员根据业务发展状况进行评估。一般的测试目的以下：

1. 测试应用系统是否知足当前业务量需求。
2. 测试应用系统是否知足N年后业务量需求
3. 测试应用系统是否稳定
4. 测试应用系统是否可靠
5. 测试应用系统瓶颈，并提供扩容意见等

三、版本升级系统

　  版本升级系统有多是针对缺陷修复升级，也有多是针对业务需求变动升级。如以前未作过性能测试，按照改造新系统方式目的设置。如已作过性能测试一般测试目的以下：

1. 测试应用系统最佳或极限处理能力与以前测试结果对比分析。
2. 测试应用系统是否稳定

四、线上运行系统

     线上运行系统要求进行非功能测试，通常是线上遇到非功能测试缺陷，很难复现。一般测试目的以下：

1. 模拟生产环境运行状况，找出非功能测试缺陷配合开发进行优化复测。

五、采购型系统

     采购型系统要求进行非功能测试，通常是对多家厂商的产品进行测试，给出对比测试结果，一般测试目的以下：

     获取固定并发用户数下，各厂商的指标对比状况（TPS，响应时间，CPU使用率，错误率等）

六、软硬件选取

     软硬件选取进行非功能测试，主要式在保持其余状况一致的状况下，性能状况对比。

     获取在不一样软硬件处理能力，根据业务状况，选择性价比最高的软硬件。

 

2、测试范围的确认

　　测试范围主要是在调研过程当中，确认被测系统与周边系统关系以图形的方式展示，并以明显的标记标注被测系统和文字的方式说明被测交易具体与哪些系统进行交互。

 

3、被测系统架构分析

       架构分析的目的主要是须要确认被测试系统使用的开发语言/开发框架、通讯机制/协议、中间件、数据库、是否采用应用集群、是否采用数据库集群、是否存在备份机制（热备/冷备）、负载均衡机制等。为后续设置具体的测试策略，环境部署，监控手段作铺垫。

 

4、业务模型分析

       业务模型分析主要是为了获得更加真实模拟线上运行场景，保证测试的覆盖率。经过根据系统状况分为有业务数据参考（生产运行日志）和无业务数据参考两种状况

 

 5、有业务数据参考

        有业务数据参考系统可按照以下方式进行分析提取业务模型：

 

实例

案例编号	接口名称	交易占比
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%

 

6、无业务数据

       经过与业务人员或者开发人员沟通，引导业务人员根据业务使用状况，进行业务模型的大概预估。具体方法以下

• 确认被测业务交易，业务交易选取规则以下：

1. 使用比较频繁的交易（业务人员根据使用状况提供）
2. 使用不是特别频繁可是交易涉及数据量比较大的交易（业务人员根据使用状况配合开发人员提供）
3. 交易逻辑复杂比较高的交易（开发人员根据代码逻辑提供）

•  确认各业务交易占比：

1. 业务人员根据使用状况进行各选取交易比例预估
2. 若是没有业务使用的话，能够参考同行（非功能测试人员根据相关进行建议并让业务确认）

 

7、用户分析

需求类别	需求要点	性能需求描述规范说明
用户分析	用户数量需求	本系统各种别用户的数量分析
	用户类别需求
	系统支持并发操做最大用户数量	并发用户数指在同一时刻内，登陆系统并进行业务操做的用户数量。
	系统支持的最大用户链接数量	系统可以同时接入（或登陆）的最大链接用户数。 通常而言，并非全部接入（或登陆）的真实用户都在实时进行操做，部分用户接入（或登陆）系统后，暂时不作业务操做，这样的用户操做习惯要求被测系统提供额外的系统并发接入能力。

 

8、 测试指标

        性能测试经常使用指标确认以下：

大类	指标项	指标量值	备注
业务类	系统处理能力(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毫秒 

 

 9、预埋数据量分析

  预埋数据量的目的是根据生产业务量状况和数据库表数据存储方式进行预埋数据，验证在必定数据量状况下，数据库性能对自己业务交易性能的影响。通常分为从生产导入数据和本身构造数据。

  生产导数主要是把生产数据脱敏导入测试库中，这样的数据更加真实。

  本身构造数主要是根据天天交易量乘以该表存储的时间或者统计线上数据量的方式（须要了解该交易涉及表数据存储），  基础数据构造，应知足数据类型以及量级的要求，避免数据热点

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