当前位置:主页 > 技术交流 >
参加“CNAS T0776软件效率测试”能力验证总结

参加“CNAS T0776软件效率测试”能力验证总结

肖洒

(北京市电子产品质量检测中心)

0 引言

能力验证有助于检验各实验室对相应领域基本技术的掌握能力,提高相应领域检测结果的准确性和可比性,为相应领域的实验室管理和认可提供技术依据。实验室的用户、监督和管理机构、评价机构等可以利用CNAS能力验证结果,判断实验室是否具有从事检测活动的能力。

CNAS T0776“软件效率测试”验证计划,旨在检验实验室在其效率检测领域内的检测能力。本次能力验证计划由国家应用软件产品质量监督检验中心组织实施,参加本次计划的实验室共96家,其中74家结果为满意,21家结果为不满意,1家未反馈。

我中心在本次能力验证中的结果为满意,分数为100分。

测试实施前我们首先成立了能力验证计划项目小组,对效率测试相关的标准、技术进行学习和交流,进一步熟悉测试工具的使用。项目开始后,首先根据本次能力验证计划的作业指导书和需求规格说明书进行了需求分析,并上机熟悉被测系统的情况。然后,编写测试计划、测试用例并实施测试。录制并调试测试脚本是性能测试中的关键步骤,我们对脚本进行了反复的修改、调试,使之能正确执行并满足测试的需要。测试场景的部署是测试成功与否的关键,我们通过对测试需求的认真分析,对测试工具功能的准确运用,很好地完成了场景的部署并完成测试。最后,根据对测试结果的数据采集和分析,生成测试报告和相关文档,提交到本次能力验证计划的组织机构。

下面对我中心参加本次能力验证计划的整个测试过程,以及测试过程中遇到的一些问题和关键点进行一下总结。

1需求分析

1.1测试内容

本次能力验证计划根据GB/T25000.51-2010《软件工程 软件产品质量要求和评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则》中5.3.4 效率条款对样品进行测试,对其他特性不做测试。软件效率测试共设计了“用户登录”、“创建报送信息”、“信息查询”和“信息审核”4个被测功能点,测试项包括单用户测试、100用户并发测试及吞吐率测试三项内容。效率要求包括主要功能的单点操作在10秒钟内完成;系统支持100用户并发,响应时间在20秒以内; “创建报送信息”操作在报送内容为128KB的纯文本信息时,吞吐率(TPS)达到10事务/秒。(注:单点操作指单用户对单一功能点的操作。)

1.2需求理解

1.2.1主要功能的单点操作在 10 秒钟内完成

根据软件需求规格说明书,本次测试涉及的主要单点操作包括:系统登录、创建报送信息(包括“保存”为草稿和“报送”到政工处审核两个操作)、信息审核、信息查询。

单点操作响应时间定义如下:

1)系统登录:输入用户名、口令、验证码后,从点击登录,到登录成功,并返回第一个用户页面之间的时间。

2)创建报送信息-保存:编辑完成报送信息后,从点击“保存”到保存成功并返回下一页面之间的时间。

3)创建报送信息-报送:编辑完成报送信息后,从点击“报送”到报送成功并返回下一页面之间的时间。

4)信息审核:对提交的信息执行“审核”操作,从点击“确认”到审核完成并返回下一页面之间的时间。

5)信息查询:输入查询条件后,从点击“查询”到返回查询结果之间的时间,查询前需准备一定数量的数据(测试系统中已预置)。

以上单点操作的响应时间定义均不含思考时间,要求在10秒钟内完成,并且服务器不发生死机、服务中断及资源占用率持续过大的现象。

1.2.2系统支持100用户并发,响应时间在20秒以内

系统的主要功能在100用户并发访问下得到预期的正确响应,响应时间在20秒以内,并且服务器不发生死机、服务中断及资源占用率持续过大的现象。

可分别测试系统登录、创建报送信息-保存、创建报送信息-报送、信息审核、信息查询5个操作的100用户并发。

并发测试需在测试工具中设置集合点,并开启缓存。

1.2.3创建报送信息”操作在报送内容为128KB的纯文本信息时,吞吐率(TPS)达到10事务/秒

该效率要求适用于面向目标的场景设计方式进行测试,首先确定事务的吞吐率指标,并设置最小和最大用户数(模拟日常使用时的用户数范围),由测试工具尝试对系统逐步加压,考察事务的吞吐率是否能达到指标要求,并且服务器不发生死机、服务中断及资源占用率持续过大的现象。

2编写测试用例

根据需求分析,我们将每一个测试点按照效率要求分别编写了测试用例,如图1:

图1 测试用例

首先录制各个操作的脚本,在录制过程中添加事务,脚本录制成功后对脚本进行调试,包括参数化设置、添加集合点等操作,然后试运行脚本,验证脚本正确性。在场景部署中设置脚本运行时间,设置每秒增加多少用户,监控CPU占用率、内存占用率、磁盘I/O占用率等资源,运行脚本,脚本运行结束后统计并记录测试结果。如果测试结果不符合测试需求,需要重复脚本调试和脚本试运行过程,直到测试结果符合。

3编写脚本

我们使用Loadrunner测试工具对测试点分别录制脚本,过程如下:

3.1主要功能的单点操作在 10 秒钟内完成

1)脚本参数化(创建报送信息、信息审核、信息查询),如图2和图3;

2)每个脚本需要设置事务点;

3)“信息审核”脚本需要设置关联,如图4;

4)“信息查询”脚本进行组合条件查询(至少设置两个查询条件执行查询操作)。

图2 脚本参数化

图3参数化内容

图4 关联

关键点分析:我们认为这部分脚本编写需要注意的是脚本参数化。

录制“创建报送信息”和“信息审核”脚本时,我们使用了一个技巧,将“创建报送信息”中的报送主题录制为“第+编号+固定字母”,我们信息审核的步骤是对查询出的主题进行审核,所以将“信息审核”中的查询内容录制为“第+编号+固定字母”,对两个脚本中的“编号”分别进行参数化,“创建报送信息”脚本中编号参数化类型选择Unique Number,block size为10000,“信息审核”脚本中编号参数化内容为数字“1-100”,Select next row选择Unique,这样可以保证每次都能审核到不同的未被审核的信息。

信息查询即按照主题、受理状态、受理结果等各项进行组合查询,而受理状态、受理结果下拉框又有多个选择条件,我们分别录制了选择不同受理状态和受理结果组合查询的脚本,并查看在脚本中他们的代码,在对“信息查询”脚本进行参数化时,我们将受理状态和受理结果值分别参数化,并且选择随机排列,以实现组合查询。

3.2系统支持 100 用户并发,响应时间在20 秒以内

1)脚本参数化(用户登录、创建报送信息、保存信息、信息审核、信息查询);

2)每个脚本需要设置事务点;

3)事务前添加集合点,如图5;

4)“信息审核”脚本需要设置关联;

5)“信息查询”脚本进行组合条件查询(至少设置两个查询条件执行查询操作)。

图5 设置集合点

关键点分析:我们认为这部分脚本编写需要注意在事务前添加集合点,从而实现并发的操作。

3.3“创建报送信息”操作在报送内容为128KB 的纯文本信息时,吞吐率(TPS)达到10 事务/

1)脚本参数化

2)设置事务点;

3)发送的报文为128KB;

关键点分析:我们认为这部分脚本编写需要注意的是发送128KB的报文,需要事先在记事本中准备128KB大小的内容,将内容复制到脚本中,以保证文本大小符合128KB。

4场景部署

在场景部署时,我们对几个主要功能的单点操作及并发操作采用手工场景(如图6),设计用户人数、每秒增加用户数,并监控响应时间和CPU占用率、内存占用率、磁盘I/O占用率等资源,持续运行5分钟,在运行过程中观察是否由于压力过大产生错误,并及时调整场景设计;我们对吞吐率的测试采用目标场景(如图7),设置吞吐率为10事务/秒,设置最小用户5人,最大用户50人,由测试工具尝试对系统逐步加压,考察事务的吞吐率是否能达到指标要求,并且服务器不发生死机、服务中断及资源占用率持续过大的现象,达到目标值后稳定运行一段时间。

图6 手工场景

图7 目标场景

关键点分析:根据需求“‘创建报送信息’操作在报送内容为128KB 的纯文本信息时,吞吐率(TPS)达到10 事务/秒”,我们经过分析认为目标场景能够更好地实现需求,在目标场景中将吞吐率设置为10事务/秒,用户数根据我们多次实验设置为5-50人,执行脚本查看事务的吞吐率是否能达到指标要求。

5结果分析和报告编制

我们使用Analysis工具对测试结果进行分析,重点关注平均响应时间、成功率以及服务器资源监控情况,若是测试吞吐率还需关注吞吐率值。通过运行各功能场景得出的响应时间,均在要求范围内,对测试结果进行最终确认,生成检测报告(如图8),提交到本次能力验证计划的组织机构。

图8 检测报告

6典型问题技术分析

根据组织、实施机构反馈的结果报告,本次能力验证计划中反应的主要问题包括:

6.1需求理解的问题

1)并发测试未分别针对单一功能点进行。在被测软件的《软件需求规格说明》中规定“系统支持100用户并发,响应时间在20秒以内”,且在需求说明中规定了“用户登录”、“创建报送信息”、“信息查询”和“信息审核”四个基本功能点,应分别对这四个功能点进行100用户并发测试,能得出相应的测试结果。

2)未在规定的数据量下执行查询操作。

3)“信息查询”未进行组合条件查询。《软件需求规格说明》中规定“信息查询即按照主题、受理状态、受理结果和报送时间各项进行组合查询”,因此在进行查询测试时,应考虑各项条件的组合。

6.2吞吐率测试的问题

《软件需求规格说明》中要求“‘创建报送信息’操作在报送内容为128KB的纯文本信息时,吞吐率(TPS)达到10事务/秒”,吞吐率测试主要指系统在一段时间内处理事务的能力,本次能力验证计划吞吐率测试可采用两种场景进行,一是采用LoadRunner中自带的目标吞吐率达到场景,目标设置为10事务/秒,用户数为系统自动增加,吞吐率达到10事务/秒后,稳定运行一段时间,吞吐率不出现明显的变化,即认为符合要求;或者手动设置多个用户在线执行一段时间,逐渐增加用户数,观察吞吐率能否达到要求。

6.3脚本编写的问题

1)“创建报送信息”脚本未正确设置数据池。《软件需求规格说明》中规定“报送主题唯一”,因此在多用户执行“创建报送信息”脚本时,应对报送主题进行参数化,并保证主题唯一。

2)“信息审核”脚本未正确设置关联。“信息审核”是本次测试中脚本难度较大的考点,客户端提交请求后,服务器返回动态字符串,需对录制的脚本进行编辑,确保脚本每次执行时动态获取该字符串,并在后续的代码中使用该字符串。

3)未正确设置事务点或集合点。《作业指导书》中规定“并发测试应在测试工具中设置集合点,并开启缓存”。

6.4文档编写的问题

1)文档中提供的测试结果数据不一致,包括测试报告结论中的数据与报告详细结果不一致,或测试报告中的数据与原始数据不一致。

2)测试报告中未说明与测试结果有关的测试条件,如数据库已有的数据量,测试查询时设置的查询条件等等。

3)测试报告可读性有待加强,如报告缺少目录,报告中的内容与测试用例、原始记录的对应关系不明确,缺少可追溯的标记。

4)测试报告结论部分未对《软件需求规格说明》规定的效率测试要求做出明确的结论,仅提供了响应时间、吞吐率等数值,未明确说明是否满足了测试需求。

对本次能力验证计划中反应的主要问题,我中心均未出现。

在需求理解方面,我们能够正确理解需求,并发测试时单独针对某功能点执行并发测试;吞吐率目标测试时使用了LoadRunner中自带的目标吞吐率达到场景测试,符合要求。

在脚本编写方面,我们能够正确设置事务点和集合点;“创建报送信息”脚本正确设置数据池;“信息查询”脚本进行组合条件查询;“信息审核”脚本正确设置关联;吞吐率测试“创建报送信息”发送的报文为128K。

在测试结果方面,我们能够保证测试报告结论中的数据与报告详细结果一致,测试报告中的数据与原始数据一致;吞吐率测试报告详细数据中提供了每秒事物数,结论中做出说明,报告中也给出了明确的测试结论。

7总结

我中心在本次能力验证计划中能够取得满分的好成绩,主要得益于以下几个方面:

1)认真的组织实施:中心领导和软件检测部对本次能力验证高度重视,选择了对效率测试具有经验的人员组成项目组,制定了较为详细地实施计划,倒排进度,保证能够按时完成。

2)细致的需求分析:测试实施的开始阶段,我们对需求文档和作业指导书进行了细致的分析,并对被测系统进行了初步的了解,通过讨论达成一致意见,最终形成具体的测试方案,保证了需求理解的正确性。

3)对测试工具和测试方法的深入研究:本次能力验证采用的测试工具是实施方统一提供的,与我们日常使用的工具一致,我们比较熟悉,虽然如此,我们在实施开始前还是组织项目组人员认真学习了测试工具的使用,对一些关键参数的设置和关键方法的使用进行了深入研究,同时通过从互联网查找相关资料、与其它测试机构交流的方法进一步提高对测试工具和测试方法的理解。

4)规范的实施:实施期间严格遵守中心质量体系文件的要求,按照相关标准和实施细则进行,保证了我们测试过程记录和测试报告编写的规范性。

8展望

通过参加这次软件效率测试能力验证,既验证了我们在软件效率测试方面的能力水平,也是对我们今后工作的一个促进。本次测试完成后,我们进行了认真的总结,并编写了使用Loadrunner测试工具进行效率测试的作业指导书,对本部门所有检测人员进行了培训,让每位同事在软件效率测试方面都有所提高,争取在以后的性能测试中更好的完成测试需求。

总部:北京东城区安定门东大街1号(邮编:100007) 电话:010-64102999 传真:010-64102997

全国软件测评机构联盟 © 版权所有 沪ICP备14033306号-24