软件测试报告参考模板汇总共13页.docx

1、软件测试报告参考模板汇总共13页计算机科学与技术（1）班星月外卖网上订餐系统软件测试报告小组名称： 第五组 小组成员： 项目组成员：组长： 班级学号： 姓名： 负责工作： 比如引言、 测试结论 评语： 小组成员：1. 班级学号： 姓名： 负责工作： 评语： 2. 班级学号： 姓名： 负责工作： 评语： 3. 班级学号： 姓名： 负责工作： 评语： 4. 班级学号： 姓名： 负责工作： 评语： 文档变更记录版本编号修订日期修订内容修订人备注012019-12-1完善测试用例1 引言1.1 编写目的本文档根据西南交通大学希望学院网上订餐系统的测试计划，为对本程序测试进行总结而编写。 本测试报告为在

2、线订餐系统项目的测试报告，网上订餐，具有方便、高效、快捷的特点，而且与传统的快餐店经营模式相比网上订餐可以节省餐馆的座位占用，加速餐馆顾客周转，增加餐馆的营业额，提高经济收益。对于在网上订餐的顾客来说，可以为其节省更多的时间和精力，以便投入到学习和工作中。1.2 项目背景及系统简介随着电子商务的普及，越来越多的人接受了电子商务这种便捷、快速的交易形式，网上订餐系统的顺势而出很快受到了大家的欢迎。互联网的应用已普及千家万户,这为网络订餐提供了良好的发展空间。同时，网上订餐服务的直观、有效、便捷等优点是传统的电话订餐业务无法比拟的。调查数据显示，白领更乐于选择网上订餐服务, 网上订餐将是白领一族捕

3、获餐店信息、进行订餐的发展趋势。网络订餐随着互联网的成长会逐渐被人们所喜爱，正如几年前手机移动的短信一样，为企业带来的几百个亿的业务收入。在互联网世界里面，谁早一步在应用上创新，谁就掌握了未来的方向。针对现在林大食堂数目过少，难以应付日益增长的学生用餐需求，与林大万人大校的规模极不相称，解决此问题迫在眉睫。北京林业大学网上订餐速递系统是一个专门为解决此矛盾量身定做的订餐服务平台，它将极大地方便校园内部同学的就餐，缓解食堂人流过度集中的压力，营造一个和谐的校园就餐环境。 1.3 用户群主要读者：项目管理人员，项目测试经理，业主相关人员；其他读者：项目其他相关人员。1.4 基本定义五类测试错误类型

4、。A类：严重错误，包括以下各种错误： 由于程序所引起的死机,非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误B类：较严重错误，包括以下各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件C类：一般性错误，包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段D类：较小错误，包括以下各种错误： 界面不规范 辅助说明描述不清楚 输入输出不规范 错误操作未给用户提示 提示窗口文字未采用行业术语 可输入

5、区域和只读区域没有明显的区分标志1.5术语和缩写词列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。1.6 参考资料项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说明书；用户操作手册；测试计划；2 测试概要本报告是北京林业大学网上订餐速递系统测试活动的总结，该测试活动所依据的测试计划和测试用例文档如下表：参考文档文档名称版本/修订详细设计西南交通大学希望学院星月外卖详细设计0.12.1 测试环境名称类型和说明数量CPUIntel i51内存2GB1硬盘可用空间大小100GB1操作系统Win7、W

6、in8或XP1应用软件Myeclipse及MySQL1网络要求2M以上12.2 测试计划版本/时间计划开始实际开始计划完成实际完成加班增加资源：（不够的可以在增加）。表2.1 测试计划（1）版本/时间计划开始时间实际开始时间计划结束时间实际结束时间加班增加资源登陆模块注册模块购物车模块订单模块表2.1 测试计划（2）任务（子功能）开始时间结束时间总 计（天）登陆模块注册模块购物车模块订单模块2.3测试方法(和工具)简要介绍测试中采用的方法(和工具)。提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试

7、工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。2.4 测试用例设计说明 简要介绍测试中采用的方法(和工具)。提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。2.4.1 功能性系统实现了哪些功能，分类列出。2.4.2 性能性 系统预期达到哪些性能，系统目前的性能达到了什么程度。2.5 覆盖分析2.5.1 需求覆盖需求覆盖率是指经过测试的

8、需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100的目标。需求/功能（或编号） 测试类型 是否通过 备注YPNN/A 根据测试结果 ，按编号给出每一测试需求的通过与否结论。P表示部分通过，N/A表示不可测试或者用例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。需求覆盖率计算 Y项/需求总数 100 例如 表2.5.1覆盖测试需求需求 /功能测试类型是否通过备注商品浏览功能测试Y注册功能测试Y登陆功能测试Y购物车功能测试Y订单功能测试Y表格中“是否通过”的四种状态：Y：全部通过P：部分通过N：不通过N/A ：不可

9、测试或者用例不适用2.5.2 测试覆盖需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因。实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。测试覆盖率计算 执行数/用例总数 100。3 测试用例3.1 功能测试3.1.1 XXX子功能测试（1）模块描述测试编号模块名称建立日期建立人员修改日期状态 草稿 正在修改 正式发布被测模块功能的简单描述（2）确立测试用例（参考模板） 注意给测试用例编号。如下所示：输入条件有效等价类无效等价类地区码(1

10、) 空白(2) 3位数字(5) 有非数字字符(6) 少于3位数字前缀(3) 大于等于5开头的4位数字后缀(4) 4位数字（3）测试用例给出具体的测试数据。测试数据期望结果实际结果测试结果（通过/未通过） 4 测试结果4.1缺陷汇总按严重程度严重 一般 微小按缺陷类型用户界面 一致性 功能 算法 接口 文档 用户界面 其他按功能分布功能一 功能二 功能三 功能四 功能五 功能六 功能七最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。4.2残留缺陷与未解决问题残留缺陷编号：BUG号缺陷概要：该缺陷描述的事实原因分

11、析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因预防和改进措施：弥补手段和长期策略未解决问题功能/测试类型：测试结果：与预期结果的偏差缺陷：具体描述评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响4 测试结论与建议报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。5 测试结论1 测试执行是否充分（可以增加对安全性、可靠性和功能性等描述）2 对测试风险的控制措施和成效3 测试目标是否完成4 测试是否通过5.1 功能 系统的各个功能是否能按照规格说明说上的正常实现。有没有什么缺陷等等。5.2 易用性现有系统实现了如下易用性：现有系统存在如下易用性缺陷：5.3 可靠性现有系统的可靠性控制是否严密， 现有系统的容错性如何，如果系统出现错误，出错描述是否清楚。是否能根据出错描述容易地找到错误恢复到正常状态。 5.4 兼容性5.5安全性现有系统实现了哪些安全性问题；现有系统未实现哪些安全性问题。