测试缺陷模板

问题描述

Bug0001【缺陷类型】【优先级】【测试环境】【测试模块】【测试用例】【发生频率】【测试步骤】【预期结果】【测试结果】【备注】

解决方案

解决方案二:
测试文档发布约定目录1缺陷优先级标准22缺陷状态33案例状态44案例级别55缺陷频率6缺陷优先级标准致命缺陷Fatal(40)----将会导致服务或产品主要功能的完全丧失。缺陷可再现且丧失系统工作平台。必须是需求列表或需求规范说明中定义的主要功能的完全丧失。危急缺陷Critical(30)----将导致服务和产品主要功能的间歇丧失或外观缺陷。此功能的工作平台无效,但在一定的条件下可继续操作。此缺陷必须是用户经常使用的、需求列表中的功能,且多次出现。重要缺陷Major(20)----将导致服务或产品功能的丧失,但并不严重影响产品的操作,或是极少出现。此功能的工作平台有效。次要缺陷Minor(10)----按常规确认的缺陷。设计建议DesignSuggestion(5)----按照原始说明能运行,但测试人员认为设计不够完善,或有更好的设计代替目前的设计。缺陷状态未修改缺陷OutstandingBug(由测试人员记录)----对开发人员标注的缺陷初始状态重现缺陷Re-openedBug(由测试人员记录)----对开发人员标注的旧缺陷重现状态已修改缺陷FixedBug(由开发人员记录)-----开发人员发现缺陷原因,并在下一开发阶段中修改后的缺陷。测试人员须在下一阶段中核实并确认此缺陷。关闭缺陷ClosedBug(由测试人员记录)----缺陷已被修改并通过测试人员检验需提供附加信息AdditionalInfoRequired(开发人员记录)----缺陷描述不够清楚和全面。当测试人员收到此电邮通知时,须立即提供必要且正确的资料给开发人员,重开缺陷让开发人员修改,并标注意见。重复缺陷DuplicatedBug(由开发人员记录)----与另外缺陷完全相同的缺陷。测试人员须复核两份相同的缺陷报告。如果缺陷确实重复,请关闭此缺陷并保留已经存在的缺陷。否则,重开缺陷并提交正确的意见。不可重现缺陷NonrepeatableBug(由开发人员记录)----不能按所示步骤重现的缺陷。测试人员须复核测试报告,如果缺陷能重现,重开缺陷并注上意见;如果不能重现,测试人员須查明原因并正确处理缺陷。错误缺陷FalseBug(由开发人员记录)----缺陷错误。开发人员认为不是缺陷。保留Held(由开发人员记录)----已知的技术原因导致缺陷产生或在现阶段不能解决的缺陷。测试人员须复核已知问题并确认此缺陷符合已知问题的标准。系统局限性Limitation(由产品经理决定并由测试人员记录)----此为产品的局限性,无须修改。已知缺陷KnownBug(由产品经理决定并由测试人员记录)----程序中的已知缺陷,无须修改。设计建议DesignSuggestion(由测试人员记录)----设计原因导致缺陷产生。案例状态原始案例(C)----案例的原始状态。结束案例(CF)----测试已经包括的案例。无效案例(CN)----到目前为止,由于某些原因没有测试的案例。案例级别首要Foremost(40)----此项目最为重要的案例。关键Crucial(30)----此项目的关键功能的案例。重要Important(20)----此项目的必要功能的案例。基本Basic(10)----可实现的基本功能的案例。缺陷频率每次EveryTime----按照步骤此缺陷每次都会出现。经常Often----出现的频率多于50%,且并不是每次出现。罕有Seldom----在测试中此缺陷出现过几次但很难碰到。一次Once----在测试中此缺陷只出现过一次。

时间: 2024-10-29 20:49:49

测试缺陷模板的相关文章

测试周报模板

模板下载:http://download.csdn.net/detail/kaka1121/9562176 本周总结(项目负责人必填,成员选填) 此处填写本周总结,包括但不限于以下内容:    本周团队内bug的简要分析总结: 除项目工作外,其他事宜的汇报,比如测试环境.新人培养.自动化工作开展等: 自己或团队遇到的问题.困惑等: 意见和建议: 要点 本周工作亮点: 此处填写本周做得好的地方 本周没做好的工作: 此处填写本周未做好的工作,比如项目延期.线上问题及其总结等: 风险提示: 此处填写目

测试问题分析和测试规范

问题1:用需.软需文档不够完整,需求不够明确,功能细节描述不足. 解决: 需求维护:Jira上的产品建议.运维反馈的产品建议. 需求文档维护.(系统的主要功能.流程在文档中都需描述,功能实现细节可在需求评审补充或用例设计时加入) 需求评审(召开版本迭代会讨论明确需求) 版本迭代会:项目经理规划版本之时,召开版本迭代会,对需求进行说明,开发和测试人员有问题可共同探讨,避免需求理解歧义.(其他组的经验) 问题2:完善需求OR完善用例? 讨论: 严格意义测试应该从需求开始抓起,参与需求的评审,对详细设

新加入一个团体,如何能尽快的展开测试工作(转载)

作为一名测试新人加入团队,大多数情况下,项目组成员都是一种热情欢迎的态度,并且主动提供力所能及的支持和帮助,如何快速熟悉项目业务和测试环境,尽快投入到实际工作中去,我谈谈个人的经验和一些看法,供同行参考: 1.寻找新公司的团队元老:      一般来说,一个新人进入新公司,都要指定一个师傅带一段时间,这也就是我们说的测试前辈.很多时候,测试前辈都是经验非常丰富的测试高人,如何您和他相处融洽,关系不错,凭他个人丰富的业务经验,给您指点迷津,也许会比你自己摸索10倍的时间效果还好.很多的测试新手,刚

Tiny模板引擎(Velocity Plus)应用示例

把TinyTemplate当成是Velocity的升级版其实也是可以的,毕竟它的语法是基到Veloccity扩展而来的,兼容度在80%以上. 至于TinyTemplate的实例是怎样的,且看下面: 宏的可变参数 在Java中的可变参数使用起来非常方便,Tiny模板也对可变参有一定支持. ? 1 2 3 4 5 6 7 8 #macro hello() ParameterList: ${helloParameterList.size()}     #for(para:helloParameterL

yii,CI,yaf框架+smarty模板使用方法_php实例

本文实例讲述了yii,CI,yaf框架+smarty模板使用方法.分享给大家供大家参考,具体如下: 最近折腾了框架的性能测试,其中需要测试各个模板跟smarty配合的性能,所以折腾了一桶,现总结一下.之前已经写过kohana框架+smarty模板,这里不再重复了. 一.yii框架+smarty模板 yii是覆盖了viewRenderer组件. 1.1,下载yii框架并解压,下载smarty框架并解压,将smarty/libs文件夹拷到yii框架application/protected/vend

软件探索性测试 笔记四

*建立起一个全局目标后,再开始测试 探索式测试的几个目标: 1.理解应用程序如何工作.它的接口看起来怎样.它实现了哪些功能 2.强迫软件展示全部能力: *目的是让软件努力运行,证明软件确实实现了设计时所要求达到的功能 3.找到缺陷,并有目的的使缺陷数量降为零 把软件特性划分成几个相互重叠的"区域",具体区域和测试方法如下: 商业区: *含义:用户所要使用的软件特性和功能,你的软件包装盒上描述的特性和掩饰的特性及代码 测试方法: 1.指南测试法:根据用户说明书来测试 2.卖点测试法:观摩

浅谈通过缺陷分析进行项目质量分析

本篇文章浅谈如何进行测试缺陷分析和质量报告分析. 背景 如同代码是程序员的成果之一,测试报告和质量报告是测试人员的主要成果之一.对于一个测试,在测试项目结束时需要对测试过程中的典型bug.常出现bug进行bugreview:对bug修复周期.bug趋势进行总结分析:通过以上bug的分析以及测试过程中出现的任何问题进行总结形成质量报告,不仅仅对过去项目产品质量进行准确的评估,还需要对未来项目在质量方面的改进点和方向提出建议,以对产品质量进行不断改进和完善 缺陷分析 1.bugreview:代码引入

软件测试中的黑天鹅系列(一) 认识软件测试中的黑天鹅

1. 软件测试中的"黑天鹅" 几年前,我带领的一个测试小组遗漏了一个严重的bug到网上,当用户反馈这个bug后, 我们对它进行了深入的分析和重现,最终所有人一致认为,这个bug能够发生实在是机缘巧合,因为它需要多个条件同时发 生才有可能触发,比如"XX算法开关必须打开.XX算法开关又必须关闭.XX参数必须取某个特定值.用户的使用环境必须是 XX个场景.硬件必须是使用XX接口板.软件必须是XX版本.XX的带宽恰巧又不够...",在用户那里,这些条件有一条不 满足,就不

JUnit反模式

JUnit 的出现为开发人员带来了福音.遗憾的是,许多人仍然认为学会 JUnit API,编写几个测试,最后得到一个测试良好的应用程序就足够了.这种想法比不进行任何测试还要糟,因为这会导致对代码健康状态的误解.学习 JUnit 是测试中最容易的一部分.编写优秀的测试则是较困难的一个环节.本文将介绍一些常见的 JUnit 反模式,并说明如何解决它们. 两个月前,我和妻子决定在厨房里装上木镶板.这是我第一次装修房子,我带着一股盲目乐观主义精神,使用铁锤和钉子干起了装修.但这样做几乎是一场灾难,因为我