Top
首页 > 正文

【it技术宅】性能测试需求不完善,看我怎么搞定测试方案

技术竞争是和平竞争,也是持续竞争,无论你是开路者还是铺路者,我们都在路上结伴而行。【IT技术宅】是一片技术的芳草地,攻城狮们在这里耕耘和收获,聚能一线实践,互动助力提升。
发布时间:2020-06-29 11:04        来源:中国软件评测中心        作者:马会丽 王晓芹

技术竞争是和平竞争,也是持续竞争,无论你是开路者还是铺路者,我们都在路上结伴而行。【IT技术宅】是一片技术的芳草地,攻城狮们在这里耕耘和收获,聚能一线实践,互动助力提升。

摘要

性能测试需求分析,是进行性能测试工作的前提,需要对原始性能测试需求指标进行分析、引导及确定,本文以某系统为例,从原始测试指标的可测试性、可实施性和描述是否明确三个方面对测试需求进行了分析。

背景

性能测试需求分析,是进行性能测试工作的前提,特别是在进行第三方测试时,性能测试人员经常犯的错误就是在未明确客户的真实需求之前,就根据以往的测试经验,选取测试点,直接对软件系统进行加压测试。其实性能测试需要从实际系统的情况出发,在充分挖掘及明确客户的真实需求基础上,做好相应的测试设计工作,这样才能更好地为客户进行服务。那么性能测试的需求从哪里来?如何才能将客户对性能的测试需求转变为可以落地的、具备可实施性的测试需求呢?怎么判断出用户提出的性能测试需求是否过于理想化 ?

答案是性能测试与其他类型测试一样,都需要对测试的需求进行分析、引导及确定。性能测试的指标可以从需求文档、招标文档、以及与客户交流的信息中进行获取,从客户提供的信息中挖掘隐含的性能测试指标,然后分析这些性能测试指标在技术上是否具备可测性,考虑测试组是否具备相应的测试环境、是否有合适的测试方法、测试工具是否具备及掌握等情况来判断性能测试指标是否具备可实施性。

下面以某质量安全追溯管理信息平台为例,进行性能测试需求分析。

被测系统的建设目标是打造信息采集、信息查询、质量监测、执法监管和分析决策于一体的质量安全监管综合服务系统,形成从生产、收购、贮藏、运输、检测、执法等全链条追溯管理模式,提升监管部门的监管能力和风险预警能力。

客户提供的原始性能测试需求:

1)能够支撑2000用户并发访问下正常完成产品信息采集;

2)信息查询时可支撑1000万人次/小时高峰网络访问压力,具有持续正常运行的能力;

3)服务器平均响应时间小于等于3秒。

系统情况

1、系统介绍

被测系统采用B/S架构,由信息采集子系统、分析决策子系统、信息查询子系统等构成,各子系统具体情况如下:

1)信息采集子系统:该子系统主要实现了产品生产流通信息采集、生产经营主体备案管理,监管机构管理、监督检查任务下发、检测机构管理、监测任务执行与填报、执法机构管理、监督抽查任务管理与填报等功能。该子系统充当数据入口的作用,用户的群体数量较大,使用频率高。

2)分析决策子系统:该子系统基于数据中心的数据资源,提供数据统计分析、基于GIS地图的区域分析、风险预警、指挥调度等决策支持功能。主要提供给各级监管机构和检测机构的决策部门使用。

3)信息查询子系统:该子系统为社会公众、生产经营者、检测机构、监管机构提供信息查询服务。面向的用户主要为公众和管理人员,公众用户的群体数量较多;监管、检测机构的管理人员用户,使用频率较低,使用人数较少。

2、系统运行环境

网络带宽:1Gbps网络带宽且未进行流量限制;网络拓扑图主要划分为互联网区、网管区、终端区、政务外网区和存储区,各区域进行物理隔离。

数据库服务器:采用6台物理机,操作系统为中标麒麟NeoKylin-AS V6.0 ;数据库管理系统为Oracle 11g,采用RAC和Data Guard方案实现分布式存储;CPU为 Intel Xeon CPU E7-8860 v3 2.20GHz,物理内存252GB;采用磁盘阵列方式存储,可用磁盘空间1TB。

应用服务器:采用40台虚拟机,操作系统采用中标麒麟NeoKylin-AS V6.0 ;中间件采用金蝶Apusic应用服务软件企业版AAS V9.0,通过硬件深信服AD7050实现负载均衡;CPU为Intel Xeon CPU E7-8860 v3 2.20GHz;物理内存36GB;硬盘100GB。

3、系统业务量

信息采集子系统业务量:《初设方案》通过对产品生产经营主体的测算得出主体用户大约143万个,全国每年需要采集的产品数量大约1000万个,产品生产流通信息大约1亿条,风险监测信息大约138万条,监管信息140万条。

分析决策子系统业务量:《初设方案》通过对产品行业及区域数据测算得出每年需要生成大约2万个统计报表,通过对监测信息测算得出每年需要统计分析3960次,指挥调度信息预计每年1500条。

信息查询子系统业务量:《初设方案》通过对公众查询业务量测算得出全国目前约4亿个家庭,采购次数约1亿次/周,全年共52亿次,平均1500万次/天。其中每天早7:00-10:00,晚17:00—19:00为高峰时段,查询量约为500万次/小时,最高峰在周末早7:00-10:00,查询量应满足1000万次/小时的要求;收购、贮藏和运输经营主体共50万家,按每天查询一次测算,生产经营主体查询全年共查询约1825万次;监管机构查询每个月约14万次。

被测系统主要面向全国某类产品的生产经营主体、监管机构、检测机构、执法机构和管理人员,提供产品相关信息的采集、统计分析、查询等核心功能。生产经营主体最关心产品生产、收购等各追溯环节信息的录入功能,交易对象信息、产品追溯信息、交易历史信息查询等功能;监管及检测机构最关心监督检查、风险监测信息录入功能,管理人员比较关心查询统计报表等功能;公众最关心产品生产、收购各追溯环节的信息查询功能。

原始性能测试需求分析

被测系统的《初设方案》中列明了性能测试的指标,对这些指标梳理后,得到了比较原始的性能测试需求。然后需要从指标是否具备可测试性、指标是否具备测试的可实施性和指标描述是否明确三个方面对每个指标进行分析。

1、指标可测试性分析

系统可支撑2000用户并发访问下完成产品追溯信息采集:《初设方案》要求信息采集业务操作的系统并发人数应满足2000人的要求。该指标要求选取信息采集业务,并发人数为2000,具备可测试性。

服务器平均响应时间≤3秒:《初设方案》要求单个用户提交请求到平台并得到提交请求确认反馈的时间应该在3秒以内,对于图片数据上传和下载的响应时间可以适当放宽,这个指标属于单个用户的响应时间测试,具备可测试性。

系统提供信息查询功能时可支撑1000万人次/小时高峰网络访问压力,具有持续正常运行的能力:《初设方案》要求查询量应满足1000万人次/小时,系统具有持续正常运行的能力,该指标要求进行1000万人次/小时的并发测试,具备可测试性,但是“系统具有持续正常运行的能力”不具备可测试性,需要确定被测系统在什么情况下,属于“具有持续正常运行的能力”?通过与客户进一步沟通,最终达成一致意见,被测系统在实施测试的一小时内服务器无宕机情况发生且事务通过率大于90%,认为系统“具有持续正常运行的能力”,该指标具备可测试性。

2、测试可实施性分析

系统可支撑2000用户并发访问下完成产品追溯信息采集:《初设方案》要求信息采集业务操作的系统并发人数应满足2000人的要求。该指标要求选取信息采集业务,并发人数为2000。该指标属于较大并发量的测试,通过对系统采用的架构,涉及的服务器种类及数量、负载均衡、网络带宽等测试环境的情况进行了解,确定测试工具可以选择使用Jmeter 5.0,该指标具备可实施性。

服务器平均响应时间≤3秒:《初设方案》要求单个用户提交请求到被测系统并得到确认反馈的时间应该在3秒以内,对于图片数据上传和下载的响应时间可以适当放宽,该指标属于单个用户的响应时间测试,确定测试工具可以选择使用Jmeter 5.0,该指标具备可实施性。

系统提供信息查询功能时可支撑1000万人次/小时高峰网络访问压力,具有持续正常运行的能力:《初设方案》要求查询量应满足1000万人次/小时,系统具有持续正常运行的能力,通过对系统采用的架构,涉及的服务器种类及数量、负载均衡、网络带宽等测试环境的情况进行了解,将1000万人次/小时的压力换算成每秒并发2780用户,持续1个小时,确定测试工具可以选择使用Jmeter 5.0,该指标具备可实施性。

3、分析指标描述是否明确

系统可支撑2000用户并发访问下完成产,品追溯信息采集:《初设方案》要求信息采集业务操作的系统并发人数应满足2000人的要求,这个指标描述比较明确。

服务器平均响应时间≤3秒:《初设方案》要求单个用户提交请求到被测系统并得到提交请求确认反馈的时间应该在3秒以内,对于图片数据上传和下载的响应时间可以适当放宽。与该指标相对应的上下文场景的描述不是很明确,没有指明针对哪类业务,通过查看初设方案测算的数据、了解被测系统实际使用情况,并与客户进行沟通,确定新增监督检查任务、监测模型配置、指挥调度、数据统计分析等管理人员关心的功能,使用人数少且常用,将其作为服务器平均响应时间的测试点。

系统提供信息查询功能时可支撑1000万人次/小时高峰网络访问压力,具有持续正常运行的能力:《初设方案》要求查询量应满足1000万人次/小时,该要求是针对公众查询功能提出的,指标的描述比较明确。

性能测试场景分析

被测系统的性能测试需求已经明确,但是这些需求不应该是孤立存在的,需要将测试指标与测试场景结合起来。具体的测试场景为:

1、负载压力测试

分别模拟2000用户并发执行信息采集子系统登录操作和扫码销售操作;模拟每秒2780用户并发执行公众查询操作,验证被测系统是否可以支撑1000万人次/小时的访问压力。

1

2、响应时间测试

选取平台事务处理类、查询类、统计类、自动任务类的常用功能,进行访问,记录服务器响应时间,并计算服务器平均响应时间,验证服务器平均响应时间是否小于等于3秒。

2

案例总结

被测系统在研发工作开始前已根据业务实际情况对用户使用规模、系统处理能力等进行了分析和测算,在《初设方案》中描述了系统所要完成的内容及要达到的性能水平,为性能测试时的需求分析奠定了基础。因此在性能测试需求分析时,比较容易明确测试指标;通过对系统架构、实际业务使用情况分析,确定了性能测试工具、方法和测试场景。

合作站点
stat