软件测试报告参考模板汇总共13页.docx
《软件测试报告参考模板汇总共13页.docx》由会员分享，可在线阅读，更多相关《软件测试报告参考模板汇总共13页.docx（11页珍藏版）》请在冰豆网上搜索。
软件测试报告参考模板汇总共13页
计算机科学与技术
（1）班
星月外卖网上订餐系统
软件测试报告
小组名称：
第五组
小组成员：
项目组成员：
组长：
班级学号：
姓名：
负责工作：
比如引言、测试结论
评语：
小组成员：
1.班级学号：
姓名：
负责工作：
评语：
2.班级学号：
姓名：
负责工作：
评语：
3.班级学号：
姓名：
负责工作：
评语：
4.班级学号：
姓名：
负责工作：
评语：
文档变更记录
版本编号
修订日期
修订内容
修订人
备注
01
2019-12-1
完善测试用例
1引言
1.1编写目的
本文档根据西南交通大学希望学院网上订餐系统的测试计划，为对本程序测试进行总结而编写。
本测试报告为在线订餐系统项目的测试报告，网上订餐，具有方便、高效、快捷的特点，而且与传统的快餐店经营模式相比网上订餐可以节省餐馆的座位占用，加速餐馆顾客周转，增加餐馆的营业额，提高经济收益。
对于在网上订餐的顾客来说，可以为其节省更多的时间和精力，以便投入到学习和工作中。
1.2项目背景及系统简介
随着电子商务的普及，越来越多的人接受了电子商务这种便捷、快速的交易形式，网上订餐系统的顺势而出很快受到了大家的欢迎。
互联网的应用已普及千家万户,这为网络订餐提供了良好的发展空间。
同时，网上订餐服务的直观、有效、便捷等优点是传统的电话订餐业务无法比拟的。
调查数据显示，白领更乐于选择网上订餐服务,网上订餐将是白领一族捕获餐店信息、进行订餐的发展趋势。
网络订餐随着互联网的成长会逐渐被人们所喜爱，正如几年前手机移动的短信一样，为企业带来的几百个亿的业务收入。
在互联网世界里面，谁早一步在应用上创新，谁就掌握了未来的方向。
针对现在林大食堂数目过少，难以应付日益增长的学生用餐需求，与林大万人大校的规模极不相称，解决此问题迫在眉睫。
北京林业大学网上订餐速递系统是一个专门为解决此矛盾量身定做的订餐服务平台，它将极大地方便校园内部同学的就餐，缓解食堂人流过度集中的压力，营造一个和谐的校园就餐环境。
1.3用户群
主要读者：
项目管理人员，项目测试经理，业主相关人员；
其他读者：
项目其他相关人员。
1.4基本定义
五类测试错误类型。
A类：
严重错误，包括以下各种错误：
⏹由于程序所引起的死机,非法退出
⏹死循环
⏹数据库发生死锁
⏹因错误操作导致的程序中断
⏹功能错误
⏹与数据库连接错误
⏹数据通讯错误
B类：
较严重错误，包括以下各种错误：
⏹程序错误
⏹程序接口错误
⏹数据库的表、业务规则、缺省值未加完整性等约束条件
C类：
一般性错误，包括以下各种错误：
⏹操作界面错误（包括数据窗口内列名定义、含义是否一致）
⏹打印内容、格式错误
⏹简单的输入限制未放在前台进行控制
⏹删除操作未给出提示
⏹数据库表中有过多的空字段
D类：
较小错误，包括以下各种错误：
⏹界面不规范
⏹辅助说明描述不清楚
⏹输入输出不规范
⏹错误操作未给用户提示
⏹提示窗口文字未采用行业术语
⏹可输入区域和只读区域没有明显的区分标志
1.5术语和缩写词
列出设计本系统/项目的专用术语和缩写语约定。
对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
1.6参考资料
项目的计划任务书、合同或批文；
项目开发计划；
需求规格说明书；
概要设计说明书；
详细设计说明书；
用户操作手册；
测试计划；
2测试概要
本报告是北京林业大学网上订餐速递系统测试活动的总结，该测试活动所依据的测试计划和测试用例文档如下表：
参考文档
文档名称
版本/修订
详细设计
《西南交通大学希望学院星月外卖详细设计》
0.1
2.1测试环境
名称
类型和说明
数量
CPU
Inteli5
1
内存
2GB
1
硬盘
可用空间大小100GB
1
操作系统
Win7、Win8或XP
1
应用软件
Myeclipse及MySQL
1
网络要求
2M以上
1
2.2测试计划
版本/时间计划开始实际开始计划完成实际完成加班增加资源：
（不够的可以在增加）。
表2.1测试计划
（1）
版本/时间
计划开始时间
实际开始时间
计划结束时间
实际结束时间
加班
增加资源
登陆模块
注册模块
购物车模块
订单模块
表2.1测试计划
（2）
任务（子功能）
开始时间
结束时间
总计（天）
登陆模块
注册模块
购物车模块
订单模块
2.3测试方法（和工具）
简要介绍测试中采用的方法（和工具）。
提示：
主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。
工具为可选项，当使用到测试工具和相关工具时，要说明。
注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
2.4测试用例设计说明
简要介绍测试中采用的方法（和工具）。
提示：
主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。
工具为可选项，当使用到测试工具和相关工具时，要说明。
注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
2.4.1功能性
系统实现了哪些功能，分类列出。
2.4.2性能性
系统预期达到哪些性能，系统目前的性能达到了什么程度。
2.5覆盖分析
2.5.1需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
需求/功能（或编号）测试类型是否通过备注
[Y][P][N][N/A]
根据测试结果，按编号给出每一测试需求的通过与否结论。
P表示部分通过，N/A表示不可测试或者用例不适用。
实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
需求覆盖率计算Y项/需求总数×100％
例如
表2.5.1覆盖测试需求
需求/功能
测试类型
是否通过
备注
商品浏览
功能测试
Y
注册
功能测试
Y
登陆
功能测试
Y
购物车
功能测试
Y
订单
功能测试
Y
表格中“是否通过”的四种状态：
[Y]：
全部通过
[P]：
部分通过
[N]：
不通过
[N/A]：
不可测试或者用例不适用
2.5.2测试覆盖
需求/功能（或编号）用例个数执行总数未执行未/漏测分析和原因。
实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
测试覆盖率计算执行数/用例总数×100％。
3测试用例
3.1功能测试
3.1.1XXX子功能测试
（1）模块描述
测试编号
模块名称
建立日期
建立人员
修改日期
状态
[]草稿[]正在修改[]正式发布
被测模块功能的简单描述
（2）确立测试用例（参考模板）
注意给测试用例编号。
如下所示：
输入条件
有效等价类
无效等价类
地区码
（1）空白
（2）3位数字
（5）有非数字字符
（6）少于3位数字
前缀
（3）大于等于‘5’开头
的4位数字
后缀
（4）4位数字
（3）测试用例
给出具体的测试数据。
测试数据
期望结果
实际结果
测试结果（通过/未通过）
4测试结果
4.1缺陷汇总
按严重程度
严重一般微小
按缺陷类型
用户界面一致性功能算法接口文档用户界面其他
按功能分布
功能一功能二功能三功能四功能五功能六功能七
最好给出缺陷的饼状图和柱状图以便直观查看。
俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。
4.2残留缺陷与未解决问题
残留缺陷
编号：
BUG号
缺陷概要：
该缺陷描述的事实
原因分析：
如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：
弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：
与预期结果的偏差
缺陷：
具体描述
评价：
对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
4测试结论与建议
报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
5测试结论
1．测试执行是否充分（可以增加对安全性、可靠性和功能性等描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5.1功能
系统的各个功能是否能按照规格说明说上的正常实现。
有没有什么缺陷等等。
5.2易用性
现有系统实现了如下易用性：
现有系统存在如下易用性缺陷：
5.3可靠性
现有系统的可靠性控制是否严密，
现有系统的容错性如何，如果系统出现错误，出错描述是否清楚。
是否能根据出错描述容易地找到错误恢复到正常状态。
5.4兼容性
5.5安全性
现有系统实现了哪些安全性问题；
现有系统未实现哪些安全性问题。
升级会员 