性能测试流程概述

  baikapala

1、系统架构了解

对于被测系统,需要参考以下资料:

新老架构图

新改造需求文档

如果有老系统的需求文档也可以适当看看

老系统当前生产环境主机部署情况

改造系统主机预部署情况


2、明确测试目标,编写测试方案

根据对系统的整体了解,与客户和开发人员讨论测试目标;

一般对于这种整体架构改动的情况,可以进行新老业务的比对,并测试能否满足生产业务高峰期TPS来测试得出结果说明新系统的性能情况

比如,选取CRM侧前台端到端业务的TOP10以及调用量最高的CRM服务TOP10等。

确定测试业务之前,一定要先明确该业务是否能在测试环境进行测试(考虑到测试数据、关联外围系统等问题),以及测试业务的编写脚本难度和测试时的难度情况

然后编写测试方案,并联系客户和开发人员进行测试方案评审。

 

在前期新系统环境没有完全搭建完成或者开发完成时,可以先根据客户提出的局部测试目标对子系统或者单元模块进行测试(比如关键接口、新的应用软件、订单系统等)


测试指标的确定

测试指标要在测试业务确定下来之后才能确定。

如果需要做新老系统的性能比对,则需要先将确定要测试的业务或者接口服务在生产中的业务调用量(这个需要找开发人员或者相关人员从业务日志或者数据库中给你统计)

一般的话,可以统计上个月每一天的业务调用量,然后筛选出调用量最高的某一天或者某一天的某一个小时,通过下面的公式计算出此业务或者服务的生产最大处理效率:

最大TPS = 调用量*80% / 时间*20%

说明:此为28原则,指在生产中80%的业务是在20%的时间内完成的。


此外还要确定当前生产机器的数量和本次测试环境的机器数量比例,根据这个比例,真实的测试指标可能需要有所调整。

3、验证测试环境,编写测试脚本

一般来说,编写脚本在功能测试完成之后,根据测试业务的数量,编写脚本的时间控制在3-7天。

 

录制或者编写脚本之前,一定需要与功能测试和开发人员沟通好,自己手工熟悉每个测试业务流程,再开始录制脚本或者编写脚本。

 

脚本做好之后,一定需要保证能够回放成功,不光要看Tree模式下的请求接收数据,还需要查看数据库中的数据是否也对应的有所变更。

脚本完成之后,需要在场景Controller中做2*2的测试:

2个并发每个并发跑两次,必须使用4组不同的数据


脚本以及事务的命名规范

脚本请使用规范的命名方式,以及易查询的文件夹名称存放:

性能测试项目文件系统:

LoadTest2017

项目名称@20170531

          

scripts(脚本存放) cen(场景存放) resresult结果存放) lra(分析结果存放) logs(日志文件存放) 


脚本命名规范:

[项目名称|业务所属标示][协议类型]_[业务名称或者服务名称]_[日期]


例如web/html脚本业务为新版开户,假如开户业务的业务编码为4510则脚本命名为

NGHttp_4510_20170531   或者  NGHttp_XBKH_20170531

 

例如crm的一个webservice接口为getUserInfo,则脚本名称可命名为

CRMWebservice_getUserInfo_20170531


事务名称命名规范

为了在测试中观察TPS和响应时间等数据更加容易,建议脚本的事务也遵循一定的命名规范:

每个脚本必须拥有一个总事务,总事务名称为脚本名(不带日期)加上中文名称,如果没有好的词语能够表达中文名称可以不用加。


例如:上面的两个脚本的总事务可以命名为 NGHttp_4510_新版开户   CRMWebservice_getUserInfo_获取用户信息

 

分事务命名规则为总事务名称加上步骤数和步骤含义:


NGHttp_4510_新版开户_01_打开首页

NGHttp_4510_新版开户_02_点击开户

NGHttp_4510_新版开户_02__点击开户_01_输入业务编码

NGHttp_4510_新版开户_02__点击开户_02_输入工号验证码

NGHttp_4510_新版开户_03_输入信息

 

注意不要忘记事务的结束。


4、准备测试数据,执行测试

一般来说测试数据最好采用真实的生产数据,对于查询业务查询接口需要不同的测试数据至少10W

办理类的业务或者接口由于数据无法重复使用,就需要在测试之前设置好迭代次数:比如某个办理类业务迭代一次的时间大约为10秒,预计压测时间为30分钟,为了保险起见,迭代次数至少为180*120%=220

然后估算最大可启动的并发用户数量,将上面计算出的迭代次数乘以最大并发用户数量则为此办理类业务或者接口服务在一轮测试中需要准备的测试数据。

 

由于测试需要进行多轮,为了防止数据混乱,办理类业务的数据应该提前准备好多轮测试的数量。


执行测试

开始测试之前一定要重新验证环境是否正常,脚本是否有问题。并且测试需要多方人员一起配合,包括开发人员,DBA,网络负责人等。


5、分析结果,编写测试报告

测试报告应该包含以下内容:

测试目的

简要概述本次性能测试的背景和目标


测试环境

测试环境(主机)

表格列出本次测试涉及到的所有服务器主机情况,包含IP、类型、环境归属

主机类型

IP

环境归属

ESB负载

10.243.39.33

/

ESB

10.243.7.188-197

待上线

TUXEDO

152.55.247.38/41

准生产


环境架构图/环境拓扑图



测试策略

测试业务选取

概述本次测试选取的所有业务并做简要说明

测试需求

简要概述本次测试如何确定测试目标和测试方案

测试用例

测试用例包含本次测试的所有的测试场景,并详细介绍每个场景:

测试环境、测试流程、核心数据收集、预期指标等


测试结果

针对每个测试场景出具详细测试结果,利用excel表格展示内容:

测试结果包含:并发数量、TPS、响应时间,可选 事务成功率、吞吐量等

资源消耗包含:各服务主机的CPU、内存消耗情况,可选 网卡流量、TCP连接、磁盘IO


测试分析

根据测试结果分析本次测试是否达到预期目的,是否出现了性能瓶颈等。


其他(测试问题、建议、计划等)

以前,我总以为自己是菜鸟,也总想着早起的鸟儿有虫吃。直到有一天我想飞,才愕然的发现自己没有翅膀和羽毛,我竟然是菜虫!早起的虫儿被鸟吃……原来,百足应该厚积薄发!