招投标系统软件测试总结报告Word文件下载.docx
《招投标系统软件测试总结报告Word文件下载.docx》由会员分享，可在线阅读，更多相关《招投标系统软件测试总结报告Word文件下载.docx（12页珍藏版）》请在冰豆网上搜索。
测试组主要依据需求与设计说明书，对招投标系统进行功能测试。
主要功能包括：
供应商管理
供应商类型管理
供应商信息管理
供应商列表管理
评标专家管理
辅助信息管理
评标小组管理
1.3参考资料
资料名称
作 者
是否经过评审
备注
《招投标系统-需求规格说明书》
---
《招投标系统-数据库设计说明书》
《招投标系统-测试计划》
1.0
2.测试计划执行情况
2.1测试类型
测试类型
测试内容
测试目的
所用的测试工具和方法
功能测试
核实所有功能均已正常实现，即可按每个用户的需求选择内容，完成操作。
1．业务流程检验：
各个业务流程符合常规逻辑，用户使用时不会产生疑问。
2、数据精确：
各数据类型的输入输出时统计精确。
采用黑盒测试，使用边界值测试、等价类划分、数据驱动等测试方法，进行手工测试；
2.2进度偏差
测试活动
计划起止日期
实际起止日期
进度偏差
制定测试计划
测试计划评审
分解测试需求
测试需求Review
选定测试范围
编写测试方案
测试方案评审
设计测试用例
测试用例评审
测试总结迟交一天
测试执行
测试移交延迟一天
测试总结
2.3测试环境与配置
资源名称/类型
配置
测试PC机（1台）
DELL，硬盘300G，内存2G。
数据库管理系统
SQLServer
应用软件
MICROSOFTOFFICE、VISIO;
客户端前端展示
IE8
2.4测试机构和人员
测试阶段
测试机构名称
负责人
参与人员
所充当角色
系统测试
测试组
2.5测试问题总结
在整个系统测试执行期间，项目组开发人员高效地及时解决测试组人员提出的各种缺陷，在一定程度上较好地保证了测试执行的效率以及测试最终期限。
但是在整个软件测试活动中还是暴露了一些问题，表现在：
1．测试执行时间相对较少，测试通过标准要求较低；
2．开发人员相关培训未做到位，编码风格各异，细节性错误较多，返工现象存在较多；
3．测试执行人员对管理平台不够熟悉，使用时效率偏低；
4．测试执行人员对系统了解不透彻，测试执行时存在理解偏差，导致提交无效缺陷；
3.测试总结
3.1测试用例执行结果
测试用例标识号
测试用例名称
用例状态
测试结果
前台功能
ES-IA-001
用户登录
已执行
测试通过
ES-IA-002
用户注册
ES-IA-003
用户注销
ES-IA-004
测试不通过
ES-IA-005
ES-IA-006
后台功能
HT-CD-1001
HT-CD-1002
HT-CD-1003
HT-CD-2001
HT-CD-2002
HT-CD-3001
HT-CD-3002
HT-CD-3003
HT-CD-4001
HT-LY-1001
HT-LY-1002
HT-LY-1003
HT-LY-1004
HT-LY-1005
002
003
3.2测试问题解决
下表中描述测试中发现的、没有满足需求或其它方面要求的部分。
错误或问题描述
错误或问题状态
用户中心：
点击【提交】没有弹出“提示”；
不能进入页面
未解决
在【我的餐车】中，无法看到已顶的订单
输入框中的数据和图片的url清空，但预览图片并未消失
●
弹出相应的删除确认框，无法点击取消删除操作
无法进行管理员的注销，页面停留在后台管理页面
没有弹出警告提示，可以重复登录
如果有多条回复，最新一次的回复内容会覆盖以前的回复，只会显示一条回复
【添加一分】该操作后此用户信息消失，
【扣掉两分】该操作后此用户信息消失
3.3测试结果分析
3.3.1覆盖分析
3.3.1.1.测试覆盖分析
测试覆盖率＝14/22×
100％=63.64％
需求/功能
用例个数
执行总数
未执行
未/漏测分析和原因
2
1
产生失败数2个，未解决
产生失败数1个，未解决
9
5
产生失败数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>
4
3
6
7
13
本文在测试过程中发现不同的缺陷，划分为四个等级：
严重，一般，无影响，合理化建议。
严重级别表示该缺陷影响系统的功能完整性，某些功能无法运行，这样的缺陷在测试之后应该优先修复和改正；
一般级别表示该缺陷对于大部分用户来说有一定的影响，但出现的几率较小，这样的缺陷修复优先级次于严重级别缺陷；
无影响级别表示该缺陷只是在界面上不美观，用户使用频率极低的功能，不影响用户的使用，这样的缺陷在修复过程中应置于最后。
缺陷严重程度数据分析如图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开发/测试的通用规范等，将会在一定程度上提高开发和测试的效率。
升级会员 