招投标系统软件测试总结报告

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

招投标系统测试总结报告
招投标系统测试总结报告
目录
1.测试概述 (3)
1.1编写目的 (3)
1.2测试范围 (3)
1.3参考资料 (3)
2.测试计划执行情况 (3)
2.1 测试类型 (3)
2.2 进度偏差 (4)
2.3测试环境与配置 (4)
2.4测试机构和人员 (5)
2.5 测试问题总结 (5)
3.测试总结 (5)
3.1测试用例执行结果 (5)
3.2测试问题解决 (7)
3.3测试结果分析 (7)
3.3.1覆盖分析 (7)
3.3.2缺陷分析 (9)
4.综合评价 (11)
4.1 软件能力 (11)
4.3 建议 (12)
1.测试概述
1.1编写目的
对招投标系统项目中所有的软件测试活动中,包括测试进度、资源、问题、风险以及测试组和其他组间的协调等进行评估,总结测试活动的成功经验与不足,以便今后更好的开展测试工作。

本系统测试总结报告的预期读者是:
➢项目组小组成员
➢测试组人员;
1.2测试范围
测试组主要依据需求与设计说明书,对招投标系统进行功能测试。

主要功能包括:供应商管理
供应商类型管理
供应商信息管理
供应商列表管理
评标专家管理
辅助信息管理
评标小组管理
1.3参考资料
2.测试计划执行情况
2.5 测试问题总结
在整个系统测试执行期间,项目组开发人员高效地及时解决测试组人员提出的各种缺陷,在一定程度上较好地保证了测试执行的效率以及测试最终期限。

但是在整个软件测试活动中还是暴露了一些问题,表现在:
1.测试执行时间相对较少,测试通过标准要求较低;
2.开发人员相关培训未做到位,编码风格各异,细节性错误较多,返工现象存在较多;
3.测试执行人员对管理平台不够熟悉,使用时效率偏低;
4.测试执行人员对系统了解不透彻,测试执行时存在理解偏差,导致提交无效缺陷;
3.测试总结
3.1测试用例执行结果
3.2测试问题解决
3.3测试结果分析
3.3.1覆盖分析
3.3.1.1.测试覆盖分析
测试覆盖率=14/22 ×100%=63.64%
供应商类型管理 1 1 0产生失败数2个,未解

供应商信息管理 1 1 0产生失败数1个,未解

供应商列表管理 1 1 0
评标专家管理 1 1 0产生失败数1个,未解

辅助信息管理 1 1 0
评标小组管理 1 1 0 产生失败数2个,未解

供应商管理9 9 0 产生失败数2个,未解

供应商类型管理 5 5 0 产生失败数3个,未解

本次测试过程中,对该每个模块进行测试,设计的测试用例所占的比例如图11:
图 1 每个模块测试过程所占比例图
测试用例是否通过说明如图2:
图 2 每个模块测试是否通过数据图
图2直观的显示每个模块的测试用例通过与否的数据,经过本次测试,发现游戏的功能不够完善,完成的功能也不够稳定,游戏过程中有很多操作会直接影响用户的使用。

3.3.1.2.需求覆盖分析
本次测试对系统需求的覆盖情况为:
需求覆盖率=Y(P)项/需求项总数×100%= 14/ 22 ×100% = 63.64%; 注:P表示部分通过,N/A表示不可测试或者用例不适用。

3.3.2缺陷分析
严重级别
需求A-严重影响
系统运行的
错误
B-功能方面一般
缺陷,影响系统运

C-不影响
运行但必
须修改
D-合理化
建议
<total>
供应商管理0 0 0 0
供应商类型
管理
0 0 0 0
供应商信息
管理
0 0 1 1 2
本文在测试过程中发现不同的缺陷,划分为四个等级:严重,一般,无影响,合理化建议。

严重级别表示该缺陷影响系统的功能完整性,某些功能无法运行,这样的缺陷在测试之后应该优先修复和改正;一般级别表示该缺陷对于大部分用户来说有一定的影响,但出现的几率较小,这样的缺陷修复优先级次于严重级别缺陷;无影响级别表示该缺陷只是在界面上不美观,用户使用频率极低的功能,不影响用户的使用,这样的缺陷在修复过程中应置于最后。

缺陷严重程度数据分析如图14:
图 3 缺陷严重程度分析图
如图14所示,缺陷严重程度分为无影响、一般和严重三个类别。

其中无影响的缺陷占38%,一般缺陷占33%,严重缺陷占29%。

其中影响用户使用的缺陷高达62%,所以该游戏需要返回修改,不能发布。

测试用例缺陷复现率及优先级如表7所示:
表 1 测试用例缺陷复现率及优先级
用例名称复现率优先级
REG_003 总是中
REG_005 总是中
Play_006 总是高
Play_007 总是中
Play_008 有时中
Play_009 有时高
Play_010 总是中
Play_two_007 有时高
Play_two_010 有时高
Play_two_015 有时高
Play_two_016 总是高
Play_two_017 总是中
Play_two_018 总是中
Play_two_019 总是中
Play_two_020 总是中
4.综合评价
4.1 软件能力
经过对招投标系统的简单的功能测试,我们发现了系统在功能方面还存在很多问题,整体流程还不能够很好的进行。

信息录入与信息管理还存在一些问题。

但流程相对较为完整。

4.2 缺陷和限制
经过对招投标系统的简单的功能测试,我们发现了系统在功能方面还存在很多问题,整体流程还不能够很好的进行。

信息录入与信息管理还存在一些问题。

4.3 建议
需求提出方可以在使用该系统的基础上,继续搜集用户的使用需求反馈,并结合市场同类产品的优势,在今后的版本中不断补充并完善功能。

另外,建议当项目组成员确定后,在项目组内部对一些事项进行约定。

如WEB 开发/测试的通用规范等,将会在一定程度上提高开发和测试的效率。

相关文档
最新文档