测试报告餐饮服务抽验管理系统

1、广州市食品药品监督管理局信息中心“食得放心”饮食安全智能化工程项目（一期）、“食得放心”食品检验检测分析暨LIMS信息管理系统工程（一期）和廉洁广州建设项目子项目1：“食得放心”饮食安全智能化工程项目（一期）及廉洁广州建设项目测试报告（餐饮服务抽验管理系统） 建设单位：广州市食品药品监督管理局信息中心监理单位：广州市信佰信息技术咨询有限公司承建单位：浪潮软件股份有限公司文档信息主题词餐饮服务抽验管理系统_测试报告文档编号CY_CS_测试报告原作者林忠晓文档类别测试文件审 核王启章文档性质发布批 准张欣发布日期2015年3月28日文档变更纪录版本号说明变更人日期V1.0编制林忠晓2015年3月2

2、6 日目录第1章 引言21.1 目的21.2 定义21.3 参考资料3第2章 系统测试报告32.1 基本信息32.2 测试记录4 功能测试4 性能测试82.3 分析与建议28 缺陷类别28 缺陷来源282.3.3 Subject29 测试用例关联29 测试需求与用例的关联29 建议302.4 测试结果统计302.5 测试结论33第1章 引言1.1 目的编写该测试总结报告主要有以下几个目的：1 通过对测试结果的分析，得到对软件质量的评价。2 分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考。3 评估测试过程和测试计划是否符合。4 分析系统存在的缺陷，为修复和预防bug提供建议。本文档

3、的读者对象包括：建设单位技术及管理人员、承建单位系统设计、开发人员、监理单位。1.2 定义序号术语名称术语定义1J2EEJava2平台企业版，是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化、规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。3XMLXML是扩展标记语言，这种标记语言通过自行定义的标记来说明数据，从而达到不要另外的解释就可以让别人明白数据内容的描述标准。4API应用程序接口，在本文档中专指业务平台提供的应用程序接口。5WebserviceWeb Service平台是一套标准，是建立可互操作的分布式应用程序，能够通过Web进行调用的API。7数据视图由一

4、个或几个基本表中根据用户需要而做成的一个虚表，存储的是视图的定义,而没有存储对应的数据。10移动设备移动通讯设备，比如利用手机智能机、平板电脑等设备，在3G、WIFI或无线网络下实现日常办公、业务支撑等应用功能。1.3 参考资料序号文档名称版本号/日期1项目招标文件2013-07-082软件需求规格说明书2014-11-113计算机软件保护条例2002-01-015GB.T 8567-2006计算机软件文档编规范2006-03-146GB.T 8566-2007信息技术 软件生存周期过程2007-04-307电子政务安全与技术手册2003-05-01第2章 系统测试报告2.1 基本信息测试计划

5、的来源测试计划V2.02015-03-04测试用例的来源餐饮服务抽验管理系统测试用例V1.02015-03-8测试对象描述餐饮服务抽验管理系统测试环境描述1、硬件配置：CPU>=XEON 2.0G；内存>= 16G；磁盘空间>= 2T；网络控制器100M/1000M/以太网网卡；软件配置：操作系统：Windows XP；Web Server：Tomcat6.0；数据库系统Oracle 11g；浏览器Internet Explorer 6.0或以上2、性能测试工具：使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的系统进行脚本录制、测试回放、逐步加压和

6、跟踪记录。测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。3、性能测试网络带宽：6M。4、功能测试方法：黑盒测试、手工测试测试人员张欣（组长）：为测试项目提供总体方向，制定测试计划、申请系统资源，控制和跟踪测试进度；王启章（副组长）：对整个项目的质量把关，搭建测试环境，并且负责性能测试；林忠晓（助理）：编写测试用例，征集并监督测试人员，跟踪测试进度；伍国飞（测试员）：对分配好的模块进行测试，跟踪Bug解决情况，汇报工作进程及测试结果；徐颖（测试员）：对分配好的模块进行测试，跟踪Bug解决情况，汇报工作进程及

7、测试结果。测试时间2015-3-8：根据需求说明书，概要设计说明书，编写出测试用例；2015-3-10：搭建测试环境，包括：硬件环境，BUG管理工具，项目安装；2015-3-10：测试系统在特定硬件环境中的功能、性能等指标是否达到要求；2015-3-28：根据项目进度计划，编写阶段性的测试报告。2.2 测试记录2.2.1 功能测试截至3月26日，所有子模块基本上进行了四轮测试，其中第二轮、第三轮、第四轮测试是在根据用户意见修改系统后进行的回归测试，测试记录如下 ：一级功能二级功能Bug描述是否通过测试备注抽验基础信息管理抽验类别检品品种检验项目检验项目与检验产品对应，形成检验库；出现重复的检验

8、项目。检验标准抽样人员抽样单位抽样机构被抽样单位生产企业地区分类方案管理计划信息管理1）未对任务做数据过滤，用户可以看到其他局的信息；2）任务来源统一改为：任务来源。任务分配管理任务计划中承检单位任务展开后无法返回查看总览任务下发管理下计划时，删掉承检机构后保存，删除不成功。任务进度管理批次管理现场录入管理被抽样单位登记任务类别需从单选到多选。样品登记 1）模板下载窗口太小；2）wps表格不能导入；3)样品名称需与商标关联。生产者信息抽样单位信息被抽样单位信息选择单位时，需将经营种类列出了，以防相同名称相同企业会选错。抽样单导入需实现检验单复制功能，提高工作效率；IE8 的抽样单复制功能不兼容

9、。抽样单打印抽样离线管理录入查询检验结果管理检验报告查询承检机构间不可互看检验记录。新增检验报告不合格项目与检测报告编号应为必填项。修改检验结果移送检验报告1）新增检验报告无法保存“检验结论”；2）检验项目明细查询时出错； 检验报告批量上传1）检验报告导入过多时提示error2038,；2）导入数据时如果存在多条数据导入失败的不能逐条显示，待导入完成后统一提示。检验结果查询1）检验结果中未上传PDF附件时应提醒；2）检验项目明细的查询功能出错。不合格品管理不合格品汇总表不合格率计算出错。不合格品抽验单关联不合格品检验报告关联不合格品查询不合格品品种类汇总提示：数据库中读取不到合法的XML内容。

10、不合格品项目统计表不合格品地区分布处罚管理新增处罚处罚查询处罚统计综合查询任务执行情况查询查询耗时长。抽验单查询不能是可编辑状态。检验结果查询1）无法根据环节类别进行筛选；2）不能是可编辑状态。检验项目查询抽验标准查询统计分析检验标准统计生产企业统计检验结果统计抽样数统计处罚统计合格品统计关联统计合格率时按检测报告上传后的时间为统计线。被抽样单位统计管理抽样单位统计管理抽样人员统计管理抽样任务汇总表需提高页面友好性。抽样检验信息汇总表需提高页面友好性。机构品种分布表需提高页面友好性。数据交换与共享数据交换共享交换监控查询等待时间过长。交换日志系统管理权限定义管理用户通过pt登录后，导致权限及任

11、务筛选出错。用户账号管理模板管理权限分配日志管理统一门户管理（与CAS对接）无法取到用户所属的部门，导致筛选代办任务出错。2.2.2 性能测试在本次测试中，将针对典型的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，主要参考依据为餐饮服务抽验管理系统需求需求说明书。2.2.2.1 性能测试指标1. 系统事务的响应能力：即在各种负载压力情况下，系统的响应时间，包括网络传输时间和服务器处理时间。2. 应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够

12、支持的最多的客户端的数量。3. 性能需求：Ø 并发业务处理用户数为20人；Ø 在线访问用户数为50人；Ø 进入系统时间（成功登录后到主窗口完全显示）<=10 秒。Ø 进入各功能时间（选择功能后到该窗口完全显示） <=10 秒，复杂功能不超过30秒。Ø 一般查询响应时间 <=10 秒 （包括查询）；当用户并发访问数达50个或以上时，多条件复杂查询不应超过60秒。Ø 系统平均响应时间：<=15秒2.2.2.2 测试方法及记录由于餐饮服务抽验系统约有50个用户，而平时系统实际的同时在线人数多为20人左右，考虑到这一实

13、际情况，分别设置压力测试的场景为20或50人同是并发访问：本次测试采用软件测试工具 LoadRunner 8.1 对餐饮服务抽验管理系统的性能情况进行测试。根据餐饮服务抽验管理系统运行的实际情况，选择常用操作进行测试脚本录制和场景模拟，分别对系统登陆、任务下发、承检机构细化任务、抽样单管理、检验结果管理、综合查询模块进行压力测试，性能测试用例如下表所示： 场景1：采用渐增的方式，以每10秒增加2个用户，直到20个用户加载完毕，然后通过设置集合点来模拟并发，迭代次数为1次，满足并发数要求。场景2：采用渐增的方式，以每10秒增加4个用户，直到50个用户加载完毕，然后通过设置集合点来模拟并发，迭代次

14、数为1次，满足并发数要求。详细测试记录如下。2.2.2.2.1 系统登陆（1）场景1测试结果在测试中模拟 20 个虚拟并发用户进行系统登陆操作，测试结果如图-1、图-2、图-3所示：图-1 分析摘要图 图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果在测试中模拟 50 个虚拟并发用户进行系统登陆操作，测试结果如图-4、图2.2.2.3-5、图-6所示：图-4 分析摘要图4.422 5.695 8.375 0.855 6.734图-5 运行Vuser图图-6平均事务响应时间图上述性能测试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒）系统登

15、陆20000.9060.0040.00450002.2970.0150.0042.2.2.2.2 任务下发（1）场景1测试结果在测试中模拟 20 个虚拟并发市局业务处室用户对承检机构进行任务下发操作，测试结果如图-1、图-2、图-3所示：图-1 分析摘要图图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果在测试中模拟 50 个虚拟并发市局业务处室用户对承检机构进行任务下发操作，测试结果如图-4、图-5、图-6所示：图-4 分析摘要图图2.-5 运行Vuser图图-6平均事务响应时间图上述性能测试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒

16、）任务下发（模拟下发全流程）2025.83526.67945.422.64326.7245025.51726.52831.1861.0428.1852.2.2.2.3 承检机构细化任务（1）场景1测试结果在测试中模拟 20 个虚拟并发承检机构用户对市局下发的任务进行细化操作，测试结果如图2.2.2.5-1、图-2、图-3所示：图-1 分析摘要图图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果在测试中模拟 50 个虚拟并发承检机构用户对市局下发的任务进行细化操作，测试结果如图-4、图-5、图-6所示：图-4 分析摘要图图-5 运行Vuser图图-6平均事务响应时间图上述性能测

17、试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒）承检机构细化任务（模拟登陆系统-细化流程）2019.88921.58540.9752.35223.5865019.0922.76242.2054.32326.0262.2.2.2.4 抽样单管理（1）场景1测试结果在测试中模拟 20 个虚拟并发承检机构用户进行抽样单录入操作，测试结果如图-1、图-2、图-3所示：图-1 分析摘要图图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果在测试中模拟 50 个虚拟并发承检机构用户进行抽样单录入操作，测试结果如图-4、图-5、图-6所示：图-4 分析摘

18、要图图-5 运行Vuser图图-6平均事务响应时间图上述性能测试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒）模拟抽样单录入2011.25011.96712.9690.512.3715011.26612.75814.3910.97614.1722.2.2.2.5 检验结果管理（1）场景1测试结果在测试中模拟 20 个虚拟并发用户对检验结果进行录入操作，测试结果如图-1、图-2、图-3所示：图-1 分析摘要图图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果在测试中模拟 50 个虚拟并发用户对检验结果进行录入操作，测试结果如图-4、图-5、

19、图-6所示：图-4 分析摘要图图-5 运行Vuser图图-6平均事务响应时间图上述性能测试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒）模拟进行检验结果录入2011.211.7120.281.96711.4045011.24911.38812.0760.10611.4132.2.2.2.6 综合查询（1）场景1测试结果在测试中模拟 20 个虚拟并发用户对综合查询功能进行操作，测试结果如图-1、图-2、图-3所示：图-1 分析摘要图图-2 运行Vuser图图-3平均事务响应时间图（2）场景2测试结果图-4 分析摘要图图-5 运行Vuser图图-6平均事务响应

20、时间图上述性能测试结论如下：脚本并发用户数（个）最小值（秒）平均值（秒）最大值（秒）标准偏差90（秒）综合查询（模拟进行一般查询与高级查询）2018.14518.84525.7981.39819.8975018.14818.8327.2941.28420.8642.3 分析与建议2.3.1 缺陷类别缺陷版本功能方面界面方面易用性方面性能方面建议性方面兼容性方面可用性方面合计V1.025312124350V1.21839013236V1.51127011123V1.911100104合计5592914961132.3.2 缺陷来源通过4轮的测试，通过测试对缺陷的来源分析如下图所示：通过测试发现系

21、统的缺陷来源主要集中分布在功能方面及易用性方面，分别占到48.67%，25.66%。2.3.3 Subject第一轮测试的BUG数量为50个，其中等级严重的占25个，一般占15个，轻微占10个，在经过修改后，第二轮回归测试发现问题数为32个，其中严重占13个，一般占11个，轻微占8个，随着测试的进行，等级为严重的BUG比重为下降趋势，不过轻微的BUG比重呈上升趋势，原因是第一轮测试重点放在了严重等级BUG的测试。第三轮回归测试发现的BUG数量为23个。第四轮回归测试发现的BUG数量为4个，都是轻微问题。目前已对所有问题解决并关闭。到此该测试全部结束，综合分析该测试是有效的，BUG数量随着测试的

22、进行，而呈下降趋势，知到最后到达关闭测试的要求水平。2.3.4 测试用例关联版本号测试用例总数发现缺陷的测试用例数缺陷总数通过测试用例发现的缺陷数V1.080505050V1.280363636V1.580232323V1.980444汇总3201131131132.3.5 测试需求与用例的关联根据测试需求进行了4轮的系统，测试过程中严格执行测试用例的基本方法，采用黑盒测试，发现测试需求与用例的关联情况如下：（1） 需求定义不明确需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的

23、关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。（2） 功能性错误功能没实现或实现错误。（3） 页面设计和需求不一致页面设计没有根据需求进行，输入，输出字段，导航文字错误，表格设计不美观，用户无法理解有些字段含义，页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误，这个问题存在普遍性。（4） 页面设计不太友好系统中很多页面的输入字段无明确的输入提示，用户无法理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。（5） 开发人员疏忽引起的缺陷因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系

24、统需要进行输入控制的地方没有进行相应的控制。2.3.6 建议因时间的关系，在系统开发的过程中，难免有因“2.3.2 缺陷来源”导致的问题，建议系统承建单位与系统开方做好项目沟通，对于一些新升级的包尽量不影响原有的功能的基础上进行升级，系统在使用过程中要定期进行数据备份，以减少不必要的麻烦。在测试过程可能仍有部分缺陷没有发现，尤其是易用性方面，希望建设单位及用户能够及时有效地提出。2.4 测试结果统计全部测试用例一共为80个，执行80个，测试用例覆盖率为100，按严重等级分布结果汇总如下：版本号严重一般轻微V1.0251510V1.2131112V1.55810V1.9004汇总433436各轮测试的项目结果如下：第一轮测试子模块名称严重等级总数严重一般轻微抽验基础信息管理0314方案管理20