一、测试人员的主要职责

编写测试计划

编写测试用例

执行测试，发现缺陷提交缺陷报告

验证所发现的缺陷是否得到修改

编写测试总结报告

二、缺陷报告的组成

缺陷编号(Defect ID)：提交缺陷的顺序；

缺陷标题(summary)：简明扼要的描述一下缺陷；

缺陷的发现者(Detected By)： 测试人员自己；

发现缺陷的日期(Detected date)：一般为当天；

缺陷所属的模块(subjecy):在测试哪个功能模块的时候发现的bug，开发组可以据此决定由谁负责修改该bug;

发现缺陷版本(Detected in release)：在测试哪个版本的时候发现的bug;

指派给谁处理(Assigned to):测试人员指派给开发经理，开发经理根据缺陷所在的模块，需再次指派具体的开发人员；

缺陷的状态(status)：缺陷此时所处的处理阶段或处理情况；

测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为：new (新发现的bug);

开发经理验证新提交的 bug ,如果是 bug ,把状态改为 open (打开的bug,开发组承认的bug)，指派给具体的开发人员解决；如果不是bug,把状态改为rejected(拒绝的bug);

开发人员看到指派给自己解决的bug，进行 bug 修复，修改完后，把状态改为：fixed(已经修复的 bug ,可以返测得 bug )

测试人员对修复得 bug 进行返测，返测成功，把状态改为closed(关闭得缺陷，归档得 bug)；如果返测不成功，把状态改为：reopen (重新打开得 bug);

缺陷的严重程度(severity)：bug 对软件的影响有多大

Urgent：造成系统死机、重启、崩溃的缺陷；

Very High：非常严重的缺陷；

High：严重的缺陷；

Medium：中等程度的缺陷；

Low：小的缺陷；

每一个等级到底包括哪些缺陷，最好在专门的文档中进行详细说明，这样可以使开发和测试人员达成共识。

Bug Level （等级、级别）

Definition （定义）

性能 Performance

缺陷的优先级(priority)

测试人员希望该缺陷程序员在什么时间内或在哪个版本中解决

Urgent：立刻修改（影响开发或者测试的进度）

Very High：本版本修改；

High：下版本修改；

Medium：发布之前修改；

Low：允许在发布中存在的

缺陷描述 (description)

把发现 bug 的步骤、使用的数据等记录下来，是程序员通过该描述清楚所发生的事情；

测试报告是对BUG的统计、计划的实施、后面测试计划的安排、测试工具测试人员的统计、以及测试结束后的建议性报告。
缺陷报告基本就是对BUG的统计和归纳等。
范围用途不一致。
这个不需要什么模板，尽量细节化去写，方方面面都要想到，就没有问题。

缺陷的标题；

缺陷的基本信息；

测试的软件和硬件环境；

测试的软件版本；

缺陷的类型；

缺陷的严重程度；

缺陷的处理优先级。

复现缺陷的操作步骤；

缺陷的实际结果描述；

期望的正确结果描述；

注释文字和截取的缺陷图像

缺陷标题

缺陷标题是对缺陷的概况性描述，通常采用在什么情况下发生了什么问题的模式。

缺陷概述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。

缺陷影响

缺陷影响描述的是缺陷引起的问题对用户或者对业务的影响范围以及严重程度。

环境配置

环境配置用于详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。

前置条件

前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述，合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰。

缺陷重现步骤

缺陷重现步骤是正格缺陷报告中最核心的内容，其目的在于用简洁的语言向开发展示缺陷重现的具体操作步骤。缺陷重现步骤应该尽量避免以下几个常见问题：

笼统的描述，缺乏可操作的具体步骤出现与缺陷重现不相关的具体步骤缺乏对测试数据的相关描述

期望结果与实际结果

描述期望结果时，需要说明应该发生什么；描述实际结果时，应该说明发生了什么。

优先级和严重程度

严重程度是缺陷的本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。

缺陷越严重，优先级就越高缺陷影响的范围越大，优先级也会越高有限缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者自动化测试的执行，这类缺陷的严重程度低，但是优先级高有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，同时存在变通方案的，也会出现优先级低的情况。

变通方案

变通方案是提供一种临时绕开当前缺陷而不影响产品功能的解决问题方式。

根原因分析

在发现缺陷的同时，定位出问题的根本原因，清楚的描述缺陷产生的原因并发聩给开发。

附件

附件通常为缺陷的存在提供必要的证据支持，常见的附件有界面截图、服务器端日志等

常规的软件缺陷报告，应该包括缺陷标题、缺陷描述、缺陷影响情况、环境配置内容、前置条件、缺陷重现的步骤、期望结果和测试结果、优先级和严重程度、变通方案、bug原因分析，以及附件几个大部分。

:软件名称、测试版本号、缺陷编号ID、日期、提交人、处理人、所在模块、软件平台、操作系统 主要属性:严重程度、优先级、缺陷状态

XXX子系统/子功能实际开始时间－实际结束时间总工时/总工作日任务开始时间结束时间总计合计对于大系统/项目来说最终要统计资源的总投入，必要时要增加成本一栏，以便管理者清楚的知道究竟花费了多少人力去完成测试

1、缺陷描述
把发现缺陷的过程、步骤、使用的数据等记录下来使程序员通过该描述能够再现该bug

2、缺陷的严重程度severity
表明该bug有多糟糕或者对软件影响的大小

• urgent——致命的、造成系统死机、崩溃的bug

• VeryHigh——非常严重的bug

• High——严重的bug

• Medium——中等程度的bug

• Low——小的bug

说明：在实际工作中每个单词代表的具体情况会有所不同。为了避免争议应该在相关文档中把每个级别的具体情形列举出来供
测试人员和开发人员参考，如Bug Level Definition.xls

3、缺陷的优先级priority

希望程序员什么时间内或在程序的哪个版本中解决该bug

• Urgent——立即修改否则影响测试/开发进度

• VeryHigh——本版本修改

• High——下版本修改

• Medium——发布之前修改

• Low——允许在发布中存在的bug

优先级制定时主要考虑因素

• 1严重程度—— 一般严重程度越高优先级越高

• 2影响范围—— 一般影响范围越广优先级越高

• 3参考开发组的当前任务压力——开发任务越轻优先级越高

• 4解决bug的成本——成本越低优先级越高