测试报告餐饮服务抽验管理系统.doc
《测试报告餐饮服务抽验管理系统.doc》由会员分享，可在线阅读，更多相关《测试报告餐饮服务抽验管理系统.doc（35页珍藏版）》请在冰点文库上搜索。
广州市食品药品监督管理局信息中心
“食得放心”饮食安全智能化工程项目（一期）、“食得放心”食品检验检测分析暨LIMS信息管理系统工程（一期）和廉洁广州建设项目——子项目1：
“食得放心”饮食安全智能化工程项目（一期）及廉洁广州建设项目
测试报告
（餐饮服务抽验管理系统）
建设单位：
广州市食品药品监督管理局信息中心
监理单位：
广州市信佰信息技术咨询有限公司
承建单位：
浪潮软件股份有限公司
餐饮服务抽验管理系统测试报告
文档信息
主题词
餐饮服务抽验管理系统_测试报告
文档编号
CY_CS_测试报告
原作者
林忠晓
文档类别
测试文件
审核
王启章
文档性质
发布
批准
张欣
发布日期
2015年3月28日
文档变更纪录
版本号
说明
变更人
日期
V1.0
编制
林忠晓
2015年3月26日
餐饮服务抽验管理系统测试报告
目录
第1章引言 2
1.1目的 2
1.2定义 2
1.3参考资料 3
第2章系统测试报告 3
2.1基本信息 3
2.2测试记录 4
2.2.1功能测试 4
2.2.2性能测试 8
2.3分析与建议 28
2.3.1缺陷类别 28
2.3.2缺陷来源 28
2.3.3Subject 29
2.3.4测试用例关联 29
2.3.5测试需求与用例的关联 29
2.3.6建议 30
2.4测试结果统计 30
2.5测试结论 33
浪潮软件股份有限公司II
第1章引言
1.1目的
编写该测试总结报告主要有以下几个目的：
1．通过对测试结果的分析，得到对软件质量的评价。
2．分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考。
3．评估测试过程和测试计划是否符合。
4．分析系统存在的缺陷，为修复和预防bug提供建议。
本文档的读者对象包括：
建设单位技术及管理人员、承建单位系统设计、开发人员、监理单位。
1.2定义
序号
术语名称
术语定义
1
J2EE
Java2平台企业版，是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化、规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
3
XML
XML是扩展标记语言，这种标记语言通过自行定义的标记来说明数据，从而达到不要另外的解释就可以让别人明白数据内容的描述标准。
4
API
应用程序接口，在本文档中专指业务平台提供的应用程序接口。
5
Webservice
WebService平台是一套标准，是建立可互操作的分布式应用程序，能够通过Web进行调用的API。
7
数据视图
由一个或几个基本表中根据用户需要而做成的一个虚表，存储的是视图的定义,而没有存储对应的数据。
10
移动设备
移动通讯设备，比如利用手机智能机、平板电脑等设备，在3G、WIFI或无线网络下实现日常办公、业务支撑等应用功能。
1.3参考资料
序号
文档名称
版本号/日期
1
《项目招标文件》
2013-07-08
2
软件需求规格说明书
2014-11-11
3
《计算机软件保护条例》
2002-01-01
5
《GB.T8567-2006计算机软件文档编规范》
2006-03-14
6
《GB.T8566-2007—信息技术软件生存周期过程》
2007-04-30
7
《电子政务安全与技术手册》
2003-05-01
第2章系统测试报告
2.1基本信息
测试计划的来源
《测试计划》V2.0／2015-03-04
测试用例的来源
《餐饮服务抽验管理系统测试用例》V1.0／2015-03-8
测试对象描述
餐饮服务抽验管理系统
测试环境描述
1、硬件配置：
CPU>=XEON2.0G；内存>=16G；磁盘空间 >=2T；网络控制器100M/1000M/以太网网卡；
软件配置：
操作系统：
WindowsXP；WebServer ：
Tomcat6.0；数据库系统 Oracle11g；浏览器 InternetExplorer6.0或以上
2、性能测试工具：
使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的系统进行脚本录制、测试回放、逐步加压和跟踪记录。
测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。
3、性能测试网络带宽：
6M。
4、功能测试方法：
黑盒测试、手工测试
测试人员
张欣（组长）：
为测试项目提供总体方向，制定测试计划、申请系统资源，控制和跟踪测试进度；
王启章（副组长）：
对整个项目的质量把关，搭建测试环境，并且负责性能测试；
林忠晓（助理）：
编写测试用例，征集并监督测试人员，跟踪测试进度；
伍国飞（测试员）：
对分配好的模块进行测试，跟踪Bug解决情况，汇报工作进程及测试结果；
徐颖（测试员）：
对分配好的模块进行测试，跟踪Bug解决情况，汇报工作进程及测试结果。
测试时间
2015-3-8：
根据需求说明书，概要设计说明书，编写出测试用例；
2015-3-10：
搭建测试环境，包括：
硬件环境，BUG管理工具，项目安装；
2015-3-10：
测试系统在特定硬件环境中的功能、性能等指标是否达到要求；
2015-3-28：
根据项目进度计划，编写阶段性的测试报告。
2.2测试记录
2.2.1功能测试
截至3月26日，所有子模块基本上进行了四轮测试，其中第二轮、第三轮、第四轮测试是在根据用户意见修改系统后进行的回归测试，测试记录如下：
一级功能
二级功能
Bug描述
是否通过测试
备注
抽验基础信息管理
抽验类别
检品品种
检验项目
检验项目与检验产品对应，形成检验库；出现重复的检验项目。
检验标准
抽样人员
抽样单位
抽样机构
被抽样单位
生产企业
地区分类
方案管理
计划信息管理
1）未对任务做数据过滤，用户可以看到其他局的信息；2）任务来源统一改为：
任务来源。
任务分配管理
任务计划中承检单位任务展开后无法返回查看总览
任务下发管理
下计划时，删掉承检机构后保存，删除不成功。
任务进度管理
批次管理
现场录入管理
被抽样单位登记
任务类别需从单选到多选。
样品登记
1）模板下载窗口太小；2）wps表格不能导入；3）样品名称需与商标关联。
生产者信息
抽样单位信息
被抽样单位信息
选择单位时，需将经营种类列出了，以防相同名称相同企业会选错。
抽样单导入
需实现检验单复制功能，提高工作效率；IE8的抽样单复制功能不兼容。
抽样单打印
抽样离线管理
录入查询
检验结果管理
检验报告查询
承检机构间不可互看检验记录。
新增检验报告
不合格项目与检测报告编号应为必填项。
修改检验结果
移送检验报告
1）新增检验报告无法保存“检验结论”；2）检验项目明细查询时出错；
检验报告批量上传
1）检验报告导入过多时提示error2038,；2）导入数据时如果存在多条数据导入失败的不能逐条显示，待导入完成后统一提示。
检验结果查询
1）检验结果中未上传PDF附件时应提醒；2）检验项目明细的查询功能出错。
不合格品管理
不合格品汇总表
不合格率计算出错。
不合格品抽验单关联
不合格品检验报告关联
不合格品查询
不合格品品种类汇总
提示：
数据库中读取不到合法的XML内容。
不合格品项目统计表
不合格品地区分布
处罚管理
新增处罚
处罚查询
处罚统计
综合查询
任务执行情况查询
查询耗时长。
抽验单查询
不能是可编辑状态。
检验结果查询
1）无法根据环节类别进行筛选；2）不能是可编辑状态。
检验项目查询
抽验标准查询
统计分析
检验标准统计
生产企业统计
检验结果统计
抽样数统计
处罚统计
合格品统计关联
统计合格率时按检测报告上传后的时间为统计线。
被抽样单位统计管理
抽样单位统计管理
抽样人员统计管理
抽样任务汇总表
需提高页面友好性。
抽样检验信息汇总表
需提高页面友好性。
机构品种分布表
需提高页面友好性。
数据交换与共享
数据交换共享
交换监控
查询等待时间过长。
交换日志
系统管理
权限定义管理
用户通过pt登录后，导致权限及任务筛选出错。
用户账号管理
模板管理
权限分配
日志管理
统一门户管理
（与CAS对接）
无法取到用户所属的部门，导致筛选代办任务出错。
2.2.2性能测试
在本次测试中，将针对典型的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，主要参考依据为《餐饮服务抽验管理系统需求需求说明书》。
2.2.2.1性能测试指标
1.系统事务的响应能力：
即在各种负载压力情况下，系统的响应时间，包括网络传输时间和服务器处理时间。
2.应用系统的负载能力：
即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
3.性能需求：
Ø并发业务处理用户数为20人；
Ø在线访问用户数为50人；
Ø进入系统时间（成功登录后到主窗口完全显示）<=10秒。
Ø进入各功能时间（选择功能后到该窗口完全显示）<=10秒，复杂功能不超过30秒。
Ø一般查询响应时间<=10秒（包括查询）；当用户并发访问数达50个或以上时，多条件复杂查询不应超过60秒。
Ø系统平均响应时间：
<=15秒
2.2.2.2测试方法及记录
由于餐饮服务抽验系统约有50个用户，而平时系统实际的同时在线人数多为20人左右，考虑到这一实际情况，分别设置压力测试的场景为20或50人同是并发访问：
本次测试采用软件测试工具LoadRunner8.1对餐饮服务抽验管理系统的性能情况进行测试。
根据餐饮服务抽验管理系统运行的实际情况，选择常用操作进行测试脚本录制和场景模拟，分别对系统登陆、任务下发、承检机构细化任务、抽样单管理、检验结果管理、综合查询模块进行压力测试，性能测试用例如下表所示：
场景1：
采用渐增的方式，以每10秒增加2个用户，直到20个用户加载完毕，然后通过设置集合点来模拟并发，迭代次数为1次，满足并发数要求。
场景2：
采用渐增的方式，以每10秒增加4个用户，直到50个用户加载完毕，然后通过设置集合点来模拟并发，迭代次数为1次，满足并发数要求。
详细测试记录如下。
2.2.2.2.1系统登陆
（1）场景1测试结果
在测试中模拟20个虚拟并发用户进行系统登陆操作，测试结果如图2.2.2.3-1、图2.2.2.3-2、图2.2.2.3-3所示：
图2.2.2.3-1分析摘要图
图2.2.2.3-2运行Vuser图
图2.2.2.3-3平均事务响应时间图
（2）场景2测试结果
在测试中模拟50个虚拟并发用户进行系统登陆操作，测试结果如图2.2.2.3-4、图2.2.2.3-5、图2.2.2.3-6所示：
图2.2.2.3-4分析摘要图
4.4225.6958.3750.8556.734
图2.2.2.3-5运行Vuser图
图2.2.2.3-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
系统登陆
20
0
0
0.906
0.004
0.004
50
0
0
2.297
0.015
0.004
2.2.2.2.2任务下发
（1）场景1测试结果
在测试中模拟20个虚拟并发市局业务处室用户对承检机构进行任务下发操作，测试结果如图2.2.2.4-1、图2.2.2.4-2、图2.2.2.4-3所示：
图2.2.2.4-1分析摘要图
图2.2.2.4-2运行Vuser图
图2.2.2.4-3平均事务响应时间图
（2）场景2测试结果
在测试中模拟50个虚拟并发市局业务处室用户对承检机构进行任务下发操作，测试结果如图2.2.2.4-4、图2.2.2.4-5、图2.2.2.4-6所示：
图2.2.2.4-4分析摘要图
图2.2.2.4-5运行Vuser图
图2.2.2.4-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
任务下发
（模拟下发全流程）
20
25.835
26.679
45.42
2.643
26.724
50
25.517
26.528
31.186
1.04
28.185
2.2.2.2.3承检机构细化任务
（1）场景1测试结果
在测试中模拟20个虚拟并发承检机构用户对市局下发的任务进行细化操作，测试结果如图2.2.2.5-1、图2.2.2.5-2、图2.2.2.5-3所示：
图2.2.2.5-1分析摘要图
图2.2.2.5-2运行Vuser图
图2.2.2.5-3平均事务响应时间图
（2）场景2测试结果
在测试中模拟50个虚拟并发承检机构用户对市局下发的任务进行细化操作，测试结果如图2.2.2.5-4、图2.2.2.5-5、图2.2.2.5-6所示：
图2.2.2.5-4分析摘要图
图2.2.2.5-5运行Vuser图
图2.2.2.5-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
承检机构细化任务
（模拟登陆系统-细化流程）
20
19.889
21.585
40.975
2.352
23.586
50
19.09
22.762
42.205
4.323
26.026
2.2.2.2.4抽样单管理
（1）场景1测试结果
在测试中模拟20个虚拟并发承检机构用户进行抽样单录入操作，，测试结果如图2.2.2.6-1、图2.2.2.6-2、图2.2.2.6-3所示：
图2.2.2.6-1分析摘要图
图2.2.2.6-2运行Vuser图
图2.2.2.6-3平均事务响应时间图
（2）场景2测试结果
在测试中模拟50个虚拟并发承检机构用户进行抽样单录入操作，测试结果如图2.2.2.6-4、图2.2.2.6-5、图2.2.2.6-6所示：
图2.2.2.6-4分析摘要图
图2.2.2.6-5运行Vuser图
图2.2.2.6-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
模拟抽样单录入
20
11.250
11.967
12.969
0.5
12.371
50
11.266
12.758
14.391
0.976
14.172
2.2.2.2.5检验结果管理
（1）场景1测试结果
在测试中模拟20个虚拟并发用户对检验结果进行录入操作，测试结果如图2.2.2.7-1、图2.2.2.7-2、图2.2.2.7-3所示：
图2.2.2.7-1分析摘要图
图2.2.2.7-2运行Vuser图
图2.2.2.7-3平均事务响应时间图
（2）场景2测试结果
在测试中模拟50个虚拟并发用户对检验结果进行录入操作，测试结果如图2.2.2.7-4、图2.2.2.7-5、图2.2.2.7-6所示：
图2.2.2.7-4分析摘要图
图2.2.2.7-5运行Vuser图
图2.2.2.7-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
模拟进行检验结果录入
20
11.2
11.71
20.28
1.967
11.404
50
11.249
11.388
12.076
0.106
11.413
2.2.2.2.6综合查询
（1）场景1测试结果
在测试中模拟20个虚拟并发用户对综合查询功能进行操作，测试结果如图2.2.2.8-1、图2.2.2.8-2、图2.2.2.8-3所示：
图2.2.2.8-1分析摘要图
图2.2.2.8-2运行Vuser图
图2.2.2.8-3平均事务响应时间图
（2）场景2测试结果
图2.2.2.8-4分析摘要图
图2.2.2.8-5运行Vuser图
图2.2.2.8-6平均事务响应时间图
上述性能测试结论如下：
脚本
并发用户数（个）
最小值（秒）
平均值（秒）
最大值（秒）
标准偏差
90％
（秒）
综合查询
（模拟进行一般查询与高级查询）
20
18.145
18.845
25.798
1.398
19.897
50
18.148
18.83
27.294
1.284
20.864
2.3分析与建议
2.3.1缺陷类别
缺陷
版本
功能
方面
界面
方面
易用性方面
性能
方面
建议性
方面
兼容性
方面
可用性
方面
合计
V1.0
25
3
12
1
2
4
3
50
V1.2
18
3
9
0
1
3
2
36
V1.5
11
2
7
0
1
1
1
23
V1.9
1
1
1
0
0
1
0
4
合计
55
9
29
1
4
9
6
113
2.3.2缺陷来源
通过4轮的测试，通过测试对缺陷的来源分析如下图所示：
通过测试发现系统的缺陷来源主要集中分布在功能方面及易用性方面，分别占到48.67%，25.66%。
2.3.3Subject
第一轮测试的BUG数量为50个，其中等级严重的占25个，一般占15个，轻微占10个，在经过修改后，第二轮回归测试发现问题数为32个，其中严重占13个，一般占11个，轻微占8个，随着测试的进行，等级为严重的BUG比重为下降趋势，不过轻微的BUG比重呈上升趋势，原因是第一轮测试重点放在了严重等级BUG的测试。
第三轮回归测试发现的BUG数量为23个。
第四轮回归测试发现的BUG数量为4个，都是轻微问题。
目前已对所有问题解决并关闭。
到此该测试全部结束，综合分析该测试是有效的，BUG数量随着测试的进行，而呈下降趋势，知到最后到达关闭测试的要求水平。
2.3.4测试用例关联
版本号
测试用例总数
发现缺陷的测试用例数
缺陷总数
通过测试用例发现的缺陷数
V1.0
80
50
50
50
V1.2
80
36
36
36
V1.5
80
23
23
23
V1.9
80
4
4
4
汇总
320
113
113
113
2.3.5测试需求与用例的关联
根据测试需求进行了4轮的系统，测试过程中严格执行测试用例的基本方法，采用黑盒测试，发现测试需求与用例的关联情况如下：
（1）需求定义不明确
需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。
使得开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。
（2）功能性错误
功能没实现或实现错误。
（3）页面设计和需求不一致
页面设计没有根据需求进行，输入，输出字段，导航文字错误，表格设计不美观，用户无法理解有些字段含义，页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误，这个问题存在普遍性。
（4）页面设计不太友好
系统中很多页面的输入字段无明确的输入提示，用户无法理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。
（5）开发人员疏忽引起的缺陷
因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。
2.3.6建议
因时间的关系，在系统开发的过程中，难免有因“2.3.2缺陷来源”导致的问题，建议系统承建单位与系统开方做好项目沟通，对于一些新升级的包尽量不影响原有的功能的基础上进行升级，系统在使用过程中要定期进行数据备份，以减少不必要的麻烦。
在测试过程可能仍有部分缺陷没有发现，尤其是易用性方面，希望建设单位及用户能够及时有效地提出。
2.4测试结果统计
全部测试用例一共为80个，执行80个，测试用例覆盖率为100％，按严重等级分布结果汇总如下：
版本号
严重
一般
轻微
V1.0
25
15
10
V1.2
13
11
12
V1.5
5
8
10
V1.9
0
0
4
汇总
43
34
36
各轮测试的项目结果如下：
第一轮测试
子模块名称
严重等级
总数
严重
一般
轻微
抽验基础信息管理
0
3
1
4
方案管理
2
0
1
3
现场录入管理
3
0
1
4
检验结果管理
1
0
1
2
不合格品管理
2
1
1
4
处罚管理
3
4
2
9
综合查询
4
3
1
8
统计分析
4
2
2
8
数据交换与共
升级会员 