1、熟悉需求
2、编写、阅读《测试计划》
说明：编写《测试计划》一般由测试组长或经理完成
3、设计测试（编写《测试用例》）
4、执行测试（执行测试用例），并且还要记录执行结果
5、记录缺陷结果（缺陷报告），跟踪、管理缺陷
6、测试结果(总结报告
二、缺陷报告（每个公司的要求不一样，我写的是大多数公司缺陷报告的情况）
1、什么是缺陷报告？
测试人员发现缺陷，通过缺陷报告记录缺陷—>将缺陷报告提交给开发，并跟踪管理缺陷。
缺陷报告是测试人员和开发人员之间重要的沟通工具。
2、缺陷报告如何编写？
说明：在企业中为了提高缺陷的管理效率和质量通常会使用管理工具，例如：QC，禅道，bugzilia等，不同
企业使用的工具不同。缺陷管理可能会有差异，打算大同小异。
1）缺陷报告的主要组成：
（1）缺陷编号（defect id）记录发现缺陷的顺序，可以通过编号唯一标识每条缺陷。
缺陷编号是一项目为单位进行的。
在测试管理中，缺陷编号通常是自动生成的。
（2）缺陷标题（summary）
简单的描述该缺陷。（概括）
（3）缺陷发现者（detected by）
就是发现缺陷的测试人员自己。
通常在测试管理工具中默认当前系统的登录用户
（4）指派给谁（assigned to）
首先测试人员将缺陷报给指派给开发方的负责人
（5）提交缺陷的日期（detected on date）
发现缺陷及时的提交给开发人员。
在测试管理工具中通常会将系统时间默认填入
（6）发现缺陷的功能模块（subject）
方便开发经理确认该模块缺陷有哪个开发人员负责
可以协助开发人员定位缺陷
（7）缺陷所属的版本（detected in release/version）
说明：这里所指的版本不仅是最终发布的版本，也包括在软件开发过程中 形成的临时版本。
回归测试：在新版本中对上一个版本中测过的功能重新再测试一遍。
为什么要做回归测试：
1）修改的缺陷有可能会对原有的功能带来新的问题
2）新增加的功能有可能会给原有功能到来新的缺陷
在企业中，往往会使用自动化工具来完成回归测试，提高测试效率。
（8）缺陷的状态（status）
描述缺陷当前的情况。
缺陷的处理过程
步骤1：测试人员填写报告，提交给开发经理，此时状态为：new （新的缺陷）
步骤2：开发经理要验证缺陷
情况1：缺陷验证通过，开发经理会激活缺陷，并将缺陷指派给相应的开
发人员。此时状态为:open
情况2：缺陷验证不通过，开发经理会拒绝该缺陷。此时状态为:rejected
扩展：被拒绝后测试人员首先要确认是否是有操作或配置错误造成的假缺陷，
然后如果是由于对于需求理解不同造成的可以跟产品部门沟通确认，
最后，如果双方不能重现该缺陷，要尽量沟通，配合重现。如果还不能
确定再去跟测试部门领导沟通反馈问题。经过上述过程如果最终确认是
假缺陷，那么有测试人员关闭该缺陷。如果是缺陷，就有谁关闭的谁激
活，继续完成缺陷处理流程。
步骤3：开发人员负责解决指派给他缺陷。解决之后将缺陷状态设置为：fixed（解决缺陷，等待返测的缺陷）
步骤4：测试人员负责返测这个缺陷
情况1：如果返测通过，测试人员将缺陷关闭。此时状态为：close（关闭的缺陷，可归档的缺陷）
情况2：如果返测没有通过，测试人员要将缺陷重新激活，此时设置缺陷状态为：reopen
（重新激活缺陷），开发人员继续修改缺陷，修改后再次将缺陷状态设置为：fixed，测试人员
再次返测，直到缺陷解决被关闭为止。
1、缺陷的基本处理过程
new->open->fixed->close
2、带返测失败（1次）的缺陷处理过程
new->open->fixed->reopen->fixed->close
3、被拒绝的缺陷的处理过程
new->rejected->close
new ->rejected->open->fixed->close
(9)缺陷的严重程度（severity）
指明缺陷有多糟糕或对程序的影响有多大
缺陷的严重级别的分级定义（以qc为例）：
Urgent：致命的缺陷 （造成计算机死机，系统崩溃等）
Very high：非常严重的缺陷
High： 严重缺陷
Medium：一般的缺陷
Low：提示、建议类的缺陷
（10）缺陷的优先级（priority）
希望或建议开发方在什么时候或什么版本解决该缺陷
优先级的级别定义：
Urgent：需要开发人员放下手头的开发任务立即解决的缺陷（通常不解决会影响整个开发和测试的进度）
Very high：在当前版本内解决
High：在下个版本中解决（常用）
Medium：在软件发布之前解决
Low:尽量在软件发布之前解决（有可能在软件发布时带有没有解决的bug）
(11) 缺陷描述（description）
说明：将发现缺陷的过程、数据记录下来，让开发人员能够再现该缺陷（就是让开发人员能知道并再现这个缺陷）
扩展：在缺陷报告中要附带证迹（截图，视频）
关于缺陷的严重程度和优先级
1）影响缺项优先级定义的因素有哪些？
（1）缺陷的严重程度，一般情况下越严重的缺陷的优先级越高
（2）缺陷影响的范围，影响范围越大，优先级越高
（3）开发人员的开发压力，开发压力越小，优先级越高
（4）解决缺陷的成本，（时间）--成本越低，优先级越高
2）缺陷的严重程度和优先级是严格的正比关系吗？
不是 例如：界面错别字
3）缺陷的严重程度和优先级确定后可以修改吗？
缺陷的严重程度确定后一般不改，优先级可以修改。
4）是否有为解决的缺陷在软件发布版本中存在？
存在 企业可以通过打补丁或者升级版本。
扩展:
不可重现的缺陷：也叫随机缺陷，按照相同的操作过程时有时无得缺陷。
如何处理：
1、首先在提交缺陷时要说明这是一个不可重现的缺陷。
2、尽量详尽的描述发现不可重现的过程，尽量配合附加证迹（截图、视频）
3、如果需要，要将发现的测试环境和配置保留，配合开发人员定位缺陷。
4、如果必要还可以配合白合测试，从程序内部定位不可重现的缺陷。
原文地址：http://blog.51cto.com/13539417/2051561
