软件项目测试过程和缺陷报告及相关面试题

一、软件项目的测试过程

• 熟悉需求
• 编写、阅读《测试计划》
  • 说明： 编写《测试计划》一般由测试组长或者经理完成
  • 测试人员要阅读并且执行《测试计划》
• 设计测试（编写《测试用例》）
• 执行测试（执行测试用例）,并且要记录执行结果
• 记录缺陷结果（缺陷报告），跟踪、缺陷管理
• 测试总结（总结报告）

二、缺陷报告

2.1 什么是缺陷报告

测试人员发现缺陷，通过缺陷报告记录缺陷，将缺陷报告提交给开发方，并跟踪 和管理缺陷 。缺陷报告是测试人员和开发人员之间重要的沟通工具。

2.2 缺陷报告如何编写

说明：在企业中为了提高缺陷的管理效率和质量通常会使用管理工具，例如：qc，禅道，bugzilla等，不同企业使用工具不同，缺陷管理可能会有差异，但是大同小异。

2.3 缺陷报告的主要组成：

测试报告要素	描述
缺陷编号（defect id）	记录发现缺陷的顺序号，可以通过编号唯一标识每条缺陷。；缺陷的编号是以项目为单位进行的。在测试管理中，缺陷编号通常是自动生成的。
缺陷标题（summary）	简明扼要的描述该缺陷。（概括）
缺陷发现者（detected by）	就是发现缺陷的测试人员自己。 通常在测试管理工具中会默认当前系统的登录用户
指派给谁（assigned to）	首先测试人员将缺陷报告指派给开发方的负责人（开发经理）。 然后再由开发经理将缺陷报告指派给相应的开发人员负责解决缺陷。
提交缺陷的日期（detected on date）	发现缺陷，确认之后，要及时的将缺陷提交给开发方。在测试管理工具中通常会自动将系统时间默认填入该项。
发现缺陷的功能模块（subject）	方便开发经理确认该缺陷由哪个开发人员负责。可以协助开发人员定位缺陷
缺陷所属的版本（detected in release/version）	说明：这里所指的版本不仅是最终发布的版本，也包括在软件开发过程中形成的临时版本。版本的制定不是由测试人员完成的。（通常公司里是产品部门完成）
缺陷的状态（status）	描述缺陷当前的情况。
缺陷的严重程度（severity）	指明缺陷有多糟糕或对程序的影响有多大
缺陷的优先级（priority）	希望或建议开发方在什么时候或什么版本解决该缺陷
缺陷描述（description）	说明：将发现缺陷的过程、数据记录下来，让开发人员能够再现该缺陷（就是让开发人员能知道并再现这个缺陷

说明：

这里所指的版本不仅是最终发布的版本，也包括在软件开发过程中形成的临时版本。版本的制定不是由测试人员完成的。（通常公司里是产品部门完成）

回归测试： 在新版本中对上一个版本中测过的功能重新再测试一遍。

为什么要做回归测试：

1）修改的缺陷有可能会对原有功能带来新的问题

2）新增加的功能有可能会给原有功能带来新的缺陷

在企业中，往往会使用自动化工具来完成回归测试，提高测试效率。

2.4 常见面试题：缺陷的处理过程（重点）

• 步骤1：测试人员填写缺陷报告，提交给开发经理，此时状态为：new（新的缺陷）

• 步骤2：开发经理要验证缺陷,

  • 情况1：缺陷验证通过，开发经理会激活缺陷，并将缺陷指派给相应的开发人员。此时状态为：open（打开/激活的缺陷，被开发方承认的缺陷）
  • 情况2：缺陷验证没有通过，开发方会拒绝该缺陷。此时缺陷状态为：rejected（被拒绝的缺陷）

• 扩展：

  • 被拒绝后测试人员首先要确认是否是由于操作或配置错误造成的假缺陷，
  • 然后如果是由于对于需求理解不同造成的可以跟产品部门沟通确认，
  • 最后如果是开发方不能重现该缺陷，要尽量沟通、配合重现。
  • 如果还不能确定再去跟测试部门领导沟通反馈问题。
  • 经过上述过程如果最终确认是假缺陷，那么由测试人员或组长关闭该假缺陷；
  • 如果最终确认是缺陷，那么谁拒绝的谁负责激活，继续完成缺陷处理流程。

• 步骤3：开发人员负责解决指派给他的缺陷。解决后将缺陷状态设置为：fixed（解决的缺陷，待返测的缺陷）

• 步骤4：测试人员返测解决的缺陷，

  • 情况1：如果返测通过，测试人员将缺陷关闭。此时状态为：closed（关闭的缺陷，可归档的缺陷）
  • 情况2：如果返测没有通过，测试人员要将缺陷重新激活，此时设置缺陷状态为：reopen（重新激活的缺陷），开发人员继续修改缺陷，修改后再次将缺陷状态设置为：fixed，测试人员再次返测，直到缺陷解决被关闭为止。

问题：（用状态变化表示）

• 缺陷的基本处理过程 New -> open -> fixed -> closed

• 带有返测失败（1次）的缺陷处理过程 New -> open -> fixed -> reopen -> fixed -> closed

• 被拒绝的缺陷的处理过程

  • 假缺陷 New—>rejected -> closed
  • 是缺陷 New -> rejected -> open -> fixed -> closed

2.5 缺陷的严重级别的分级定义（以qc为例）：

• Urgent：致命的缺陷，例如造成计算机死机，系统崩溃等

• Very high：非常严重的缺陷

• High：严重的缺陷

• Medium：一般的（中等的）缺陷

• Low：提示、建议类的缺陷（小问题）

发现问题：缺陷的严重级别的定义是笼统的，在实践中容易造成冲突，所以企业针对每个严重级别制定了详细的说明。工作中要注意参考。（不同公司或者不同项目使用的缺陷严重级别定义文档都会不同）

2.6 优先级的级别定义

• Urgent：需要开发人员放下手头的开发任务立即解决的缺陷（通常是不解决会影响整个开发和测试进度的）

• Very high：在当前版本内解决

• High：在下一个版本中解决（常用）

• Medium：在软件发布之前解决

• Low：尽量在软件发布之前解决（有可能在软件发布时带有没有解决的bug）

说明：不同企业，不同项目组对于软件优先级的定义会不同，工作中要注意参考。

2.7 关于缺陷的严重程度和优先级的常见面试题：

• 影响缺陷优先级定义的因素有哪些？

  • 缺陷的严重程度—一般越严重缺陷的优先级越高（有时也会有严重程度低而优先级高的情况）

  • 缺陷影响的范围—影响范围越大，优先级越高

  • 开发人员的开发压力—开发压力越小，解决缺陷的优先级越高

  • 解决缺陷的成本（时间）–成本越低，解决缺陷的优先级越高

• 缺陷的严重程度和优先级是严格的正比关系吗？

  • 不是严格的成正比关系，例如：界面的错误别字，严重程度低，但是优先级高

• 缺陷的严重程度和优先级确定之后可以修改吗？

  缺陷的严重程度确定好后一般不改

  缺陷的优先级可以修改，而且常常是拖延处理（delay）

• 是否有未解决的缺陷在软件发布版本中存在?

  ​ 有可能会有发现的但没有解决的缺陷在发布的软件版本中存在。

  这类缺陷需要开bug讨论会，讨论投入和风险，权衡利弊后，才能决定。

  企业可以通过打补丁或者升级版本的方式在后续将此类缺陷解决。

2.8 缺陷描述（description）

• 说明：将发现缺陷的过程、数据记录下来，让开发人员能够再现该缺陷（就是让开发人员能知道并再现这个缺陷）

• 扩展：在缺陷报告中要求附带证迹（截图、视频）