该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
测试活动中,对于发现的缺陷(Bug或者Defect)在进行描述时需要包含的要素如下描述: 缺陷ID 唯一的缺陷ID,可以根据该ID追踪缺陷 缺陷状态 一般情况下缺陷状态有:“打开/重新打开”、“待解决”、“不解决(拒绝)”、“已解决”、“已修复”、“延期修复”、“关闭”等。 对应的英文描述:Open/Reopen、un-solved、Won’t Fix、Resolved、Fixed、Deferred、Close。 一般的测试人员识别缺陷,其初始状态是“新建”;Test Leader 分配给合适的开发人员来解决,状态流转为“待解决”;指定的软件工程师来解决缺陷,将其状态跟踪到“已解决”;测试人员进行缺陷验证(Retest,再测试)该缺陷,如果测试通过,状态是“已修复”,如果复核不通过,则打回到“待解决”;对于已经修复的缺陷,经过Test Leader确认之后,状态修改为“关闭”。 缺陷标题 描述缺陷的标题 缺陷的详细描述 对缺陷的详细描述,缺陷如何复现的步骤等等,之所以把这项单独列出来,是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改,描述应该尽可能详细。 缺陷的严重程度 描述缺陷的严重程度,一般分为“致命(Critical)”、“严重(Major)”、“一般(Minior)”、“轻微(Trival)”和“建议修改(Enhancem或者Suggestion)”等五种。 缺陷的紧急程度 描述缺陷的紧急程度,从Low、Middle、High。也有用1-5级来定义,1是优先级最低的等级,5级是优先级最高的等级。 缺陷的紧急程度与严重程度虽然是不一样的,但两者密切相关,往往的越是严重,就越是紧急;但是也存在一些情况,虽然严重等级不高,但是需要紧急修复。 缺陷提交人 缺陷提交人的名字 缺陷提交时间 缺陷提交的时间 缺陷所属项目/模块 缺陷所属的项目和模块,最好能较精确的定位至模块 缺陷指定解决人 缺陷指定的解决人,在缺陷“Open”状态为空,在缺陷“待解决”状态下由Development Leader 指定相关开发人员修改。 缺陷指定解决时间 Development Leader 指定的开发人员修改此缺陷的deadline 缺陷解决人 最终解决缺陷的人 缺陷处理结果描述 对处理结果的描述,如果对代码进行了修改,要求在此处体现出修改 缺陷处理时间 缺陷复核人 对被处理缺陷复核的验证人 缺陷复核结果描述 对复核结果的描述(通过、不通过) 缺陷复核时间 对缺陷复核的时间 测试环境说明 对测试环境的描述 必要的附件 对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的 除上述描述项外,配合不同的统计的角度,还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等属性。