一、测试工程师的主要工作职责
1、理解、熟悉《需求文档》
2、阅读和编写《测试计划》
说明：一般由测试负责人编写测试计划。普通测试工程师主要是阅读、理解清楚项目的测试计划。
3、编写《测试用例》指导测试工作
4、执行测试用例，发现缺陷--编写《缺陷报告》
5、跟踪、管理缺陷
6、编写《测试总结报告》
测试总结报告实际是由客观的测试数据组成，例如：缺陷总数，解决的缺陷数，未解决的缺陷数等。
二、缺陷报告
1、定义
缺陷报告定义：发现缺陷后用缺陷报告记录缺陷→通过缺陷报告将缺陷告知给开发人员，以使开发方解决缺陷。缺陷报告是测试人员和开发人员之间沟通的重要工具。
2、缺陷报告的主要组成
说明：不同公司可能使用不同的测试管理工具（如QC，禅道等），所以缺陷报告的组成部分不完全一致。缺陷报告的主要组成部分：
1）缺陷编号
记录发现缺陷的顺序号。在测试管理工具中，缺陷编号都是自动生成的。缺陷编号的生成是以项目为单位的（记录的是整个项目所有缺陷的统一编号）。
2）缺陷标题/描述
说明：简明扼要的描述该缺陷。
3）缺陷发现者
发现该缺陷的测试人员，一般就是测试人员自己（测试工具会自动填写当前登录的测试人员账号）。
4）指派给谁
测试人员将缺陷指派给开发方的负责人，开发方负责人再根据产生缺陷的功能模块去找到对应的开发人员（程序员）。
5）缺陷提交的日期
说明：发现缺陷要及时的提交缺陷。通常会将系统时间自动填写。
6）发现缺陷的版本
版本不一定指的是最终版本，有可能是开发过程中的临时版本。
回归测试：在新版本中对上一个测过的内容再次测试。
为了提高回归测试的效率，现在的趋势是用自动化测试替代手工做回归测试。
7）缺陷所属功能模块
说明：在哪个功能模块中发现的该缺陷。
8）缺陷的状态【重点】
描述缺陷此时所处的状态。
例如：
新提交的缺陷——new
打开的缺陷——open
被拒绝的缺陷——rejected
已经被修改完的缺陷——fixed
重新打开的缺陷——reopen
关闭的缺陷——closed
9）缺陷的严重程度（severity）
指明该缺陷对软件造成的影响程度有多大。
例如：
造成死机或影响开发、测试进度的问题——Urgent。
非常严重的功能问题——Very High
大的功能问题——High
中等程度的功能问题——Medium
小的功能问题——Low
注意：每个单词代表的具体含义每个公司可能不一样，应该在测试计划或是在专门的文档中定义好，以便测试人员和开发人员达成一致。
10）缺陷的优先级（Priority）
希望该缺陷在什么时间内或者哪个版本程序员可以解决。
例如：
Urgent——立即修复
Very High——本版本修复
High——下一个版本修复
Medium——发布之前修复
Low——允许在发布产品中存在
注意：同样，每个单词代表的具体含义每个公司可能不一样，应该在测试计划或是在专门的文档中定义好。
11）缺陷的描述
把发现这个缺陷的具体步骤记录下来，以使开发人员通过你的描述可以看到这个缺陷，以便他去解决这个缺陷。
要求：描述清晰、准确、易读，使开发人员容易读懂，并可以重现缺陷——重点、难点
说明：
1、缺陷的严重程度和优先级是不是成正比例关系？
例如：
界面问题的严重程度一般比较低，但优先级可能最高——立即修复。
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低——发布之前修复。
2、缺陷的严重程度和优先级确定好以后，还会改吗？
例如：
测试人员确定一个缺陷为“立即修复”，但开发组认为这个缺陷不太好解决，而这个缺陷又不影响其他功能，这时可能要求在”下一个版本修改”或“发布之前修改”。
3、是不是所有已发现的缺陷都会被修复？
有些缺陷修复的成本太高，或者由于进度压力可能在发布之前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户造成重大的影响及法律纠纷。后面再通过升级软件或打补丁的方式修复缺陷或弥补缺陷。
3、缺陷报告的用途
- 记录软件缺陷
- 对缺陷进行分类
- 跟踪软件缺陷
- 用于缺陷的分析、总结
三、软件缺陷的识别
- 通过用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过和开发人员、需求人员、用户沟通进行识别
写缺陷报告时注意的问题：
- 一个报告只提交一个缺陷
- 缺陷描述清晰、准确、易读，使用最少、必须的步骤保证缺陷可以再现
- 对缺陷的严重性、优先级的划分准确、客观
- 在缺陷报告提交之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确造成的 “假缺陷”
- 不要为了引起开发人员的重视而夸大缺陷
- 小的缺陷也要报告
- 及时报告缺陷
- 对于不可重现的缺陷也要报告
- 不做任何评价