执行的输出，当然是缺陷。这里先介绍下缺陷的状态，这个项目中一共分八类。
1、New Defect 初始状态
2、Open IT开始进行修改
3、Fixed IT修改完毕并上传测试环境
4、Closed 回归测试通过
5、Reopen 回归测试失败
6、Duplicate 与已经提交的Defect重复，填写该状态时，必须在Descrīption中给出与其重复的BUG ID号码
7、Abandon 被Reject和Duplicate的Defect，Tester确认后的确不是问题，将Defect置为此状态
8、Rejected 拒绝修改
缺陷的提交又是依靠缺陷报告来提交的。具体如：
Defect内容
Defect ID：系统自动生成
Summary：Defect摘要信息，用简短的语言描述Defect现象
Descrīption：Defect详细描述
Version：发现版本
Category：缺陷种类（功能、性能、约束、界面、改进）
Subject：Defect被发现模块名称
Reproducible：再现性（默认为“是”，可修改）
Miss phase：引入阶段
Detected By：Defect提交者，默认当前登录用户
Detected on Date：Defect提交日期，默认当前系统时间
Status：Defect状态（默认提交状态为“New”）
Assign to：BUG的负责人，该字段值随着缺陷的流程进展需要修改，为该bug当前的负责人
Severity：严重级别
Priority：优先级
Type：引入原因（逻辑错误，语法错误，接口错误，设计错误，功能实现错误，其他）（开发人员填写）
Comments：Defect注释，记录Defect处理过程中的信息（开发人员填写）
Attachment：附件
Browser：Defect被发现的浏览器环境
Planed fixed date：计划的修复时间，当将Defect状态置为Open时强制填写（开发经理填写）
Actual fixed date：实际修复时间，当将Defect状态置为Fixed时强制填写（开发经理填写）
Defect描述
Defect描述原则：
能够根据描述重现Defect；
IT能够根据描述，找出出现错误的数据以进行调试；
必须对故障现象进行详细描述；
Defect内容描述：
如果执行Test case过程中发现的问题，直接提交Defect；
如果不是通过执行Test Case发现的，则需要描述清楚导致错误的操作步骤；
必须记录出现错误数据；
如果页面抛错，必须拷屏并作为附件附在Defect上；
如果是数据库数据错误，必须Select出错误数据并拷屏附加在Defect上；
Defect记录原则
所有发现的问题必须录入TD；
紧急的问题可以先电话或者Mail通知相关人员后，再记录TD；
当对提交的defect有疑问，但是提交进入TD以便于跟踪时，请先将defect Assign to自己，待确认后再Assign to对应的IT，否则会出现不必要的工作量；
任何影响测试执行的问题，均作为Bug记录TD，坚决避免出现，口头说有问题但是TD中找不到记录的情况；
说明：这类问题主要特点为不是通过执行Test Case发现的，而是Test Case的要求的条件不满足导致无法执行Test Case。如IAC没有设置、缺少特定权限的用户、缺少特定的产品等等。所有这些问题均作为bug录入TD中，进行跟踪。
Severity级别定义
Name | Descrīption | Remark |
Urgent | 1、影响主流程； 2、导致数据错误； 3、影响五个以上Test Case执行； | |
High | 影响一般流程的错误 | |
Medium | Warning、Error message等错误 | |
Low | UI错误 | |
