Question

1. 前言

本文对如何通过使用阿里云云效-专有云版本的缺陷管理产品，实现软件产品的缺陷管理进行了介绍，供包括产品经理、项目经理、敏捷教练、开发人员、测试人员在内的客户参考使用。

---

2. 最佳实践概述

软件缺陷管理是 DevOps 的重要环节之一，历经了传统瀑布、敏捷研发等多种模式的变革，是一个由来已久的话题。同时，该环节本身也是一个较为复杂的流程，涵盖了缺陷的产生、缺陷流转、缺陷关联需求等环节。

【适用场景】

• WEB 形式的手工用例的管理
• 手机 APP 形式的手工用例的管理

【方案架构】

• 缺陷处理流转流程图如下：

【方案优势】

• 对缺陷全生命周期进行管理，处理流转状态清晰可查，提升软件产品的质量。

---

3. 前置条件

在执行本文操作前，请完成以下准备工作：

• 所在公司已购买并开通云效项目管理、需求管理产品模块。
• 已注册云效账号并完成认证，可以登录云效平台。
• 完成云效产品培训并通过相关考试。
• 加入云效的钉钉答疑群（联系本公司云效接口负责人入群）。
• 产品需求相关方（业务方、PD、UED、PM、技术架构、开发、测试、验收等）已经通过钉钉或企业微信建立实时通信群。

---

4. 工具准备

• 本方案使用 Chrome 浏览器，需提前准备。
• 安装钉钉或企业微信。

---

5. 使用流程

5.1 缺陷等级定义

5.1.1 缺陷严重级别定义

• Blocker：导致运行中断（应用程序崩溃），预期功能未实现，测试工作无法继续进行等。
• Major：非常重要，且需要马上给予关注。
• Normal：重要，但由于解决问题需要花费一定时间，因此可以用较长时间解决。
• Trivial：不重要，可以在时间和资源允许的情况下再解决。

5.1.2 更为详细的划分

• Blocker 类——非常严重的错误，包括：
  • 由于程序所引起的死机，非法退出
  • 死循环
  • 导致数据库发生死锁
  • 数据通讯错误
  • 严重的数值计算错误
• Major 类——较严重的错误，包括：
  • 功能不符
  • 数据流错误
  • 程序接口错误
  • 轻微的数值计算错误
• Normal 类——一般性的错误，包括：
  • 界面错误（详细文档）
  • 打印内容、格式错误
  • 简单的输入限制未放在前台进行控制
  • 删除操作未给出提示
• Trivial 类——较小的错误，包括：
  • 辅助说明描述不清楚
  • 显示格式不规范
  • 长时间操作未给用户进度提示
  • 提示窗口文字未采用行业术语
  • 可输入区域和只读区域没有明显的区分标志
  • 系统处理未优化

5.2 缺陷状态说明

5.2.1 缺陷状态分类说明

类别	状态
待处理	New、Open、Reopen
已处理	Fixed、Won't fix、Later、Worksforme、Duplicate、Invalid、External、ByDesign
已关闭	Closed

5.2.2 缺陷状态详细说明

状态	描述
New	新增加的、需要解决的 BUG
Open	正在定位问题，或正在解决中，或已经解决但未部署生效
Reopen	重新打开、激活，需要再次解决的 BUG
Fixed	BUG 已经解决，并且修改后程序已部署生效
Closed	验证后，此 BUG 可以关闭
Later	此 BUG 不在本项目的工作范围内，在后续版本中修复
Worksforme	不能在当前环境中重现
Duplicate	和其它 BUG 描述现象重复。可以配置选择 Duplicate 状态时必填关联的缺陷 ID
Invalid	属于测试人员对测试需求的理解错误
External	问题是由其他外部的原因引起，需要由外部处理
ByDesign	属于按照产品设计实现，不是问题
Won't fix	问题确实出现过，但是由于产品改动已经修复或者功能废弃，问题目前已不需要解决

5.2.3 缺陷状态流转说明

5.3 新增缺陷 & 指派处理人

【说明】：当测试出现失败时，需要将失败信息录入缺陷并指定处理人，方便后续缺陷的跟踪与统计。

【操作步骤】：

1. 在云效中创建了某个项目或者项目集：参考项目管理最佳实践，进入该项目或项目集。
2. 左侧导航栏点击缺陷。
3. 点击新建缺陷按钮进入缺陷编辑页面。
4. 在缺陷编辑页面中输入缺陷标题、缺陷描述、重现步骤、期望结果、实际结果、原因定位、修复建议，设置缺陷优先级并指派给缺陷处理人，若有截图或录屏，则上传到附件。缺陷描述信息说明：
   • 缺陷标题：需要录入比较清晰明确的缺陷标题，格式为【模块名】标题，方便后续根据模块查找。
   • 缺陷描述：描述出缺陷的具体问题，一般为操作场景加上错误信息。
   • 重现步骤：缺陷的操作步骤。
   • 期望结果：按照上述操作步骤，希望出现的结果。
   • 实际结果：按照上述操作步骤，实际中出现的结果。
   • 原因定位：该缺陷的产生的原因（一般为测试人员排查后找到具体原因，开发人员排查后可针对此原因进行补充）。
   • 修复建议：针对该缺陷应该如何修复，测试人员提出建议。
5. 在缺陷保存后，需要将缺陷关联到相关需求，方便跟踪。
   • 点击关联后在弹出窗口中选择更多。
   • 在输入框中输入需求标题，系统模糊查询出需求，选中关联的需求。
   • 关联需求后的示例。

     5.4 处理缺陷

【说明】：处理人接收到处理缺陷的提醒，进行问题处理，更改缺陷状态后进行相应的处理，处理完毕后更改状态。

【操作步骤】：

1. 打开对应缺陷，将处理意见写入评论中，并更改缺陷状态。

2. 处理结果有以下几种情况（缺陷状态流转说明请参考 5.2.3 章节）：

   • 处理人员修复缺陷后，在评论中输入修改描述，并将状态更改为 Fixed 后转交给验证人员。验证人员验证通过则将状态更改为 Close；若验证不通过，则在评论中录入不通过的原因，将状态更改为 Reopen，再次转给处理人员处理。
   • 处理人员认为此缺陷是基于某种不可再发生的操作场景，认为此缺陷将来不会再出现，则在评论中录入判断依据，并将状态更改为 Won’t Fix 后打回给验证人员。验证人员与产品经理共同商议，决定选择 Close 或 Reopen。
   • 处理人员根据缺陷操作步骤无法重现错误，则在评论中录入描述，并将状态更改为 Worksforme 后转给验证人员。验证人员确认操作步骤后，决定选择 Close 或 Reopen。

   • 处理人员认为此缺陷与历史未解决的某缺陷属于同一问题，则在评论中录入描述，并将状态更改为 Duplicate，同时设置关联重复的缺陷，并转给验证人员，验证人员等关联缺陷修复后一起验证。

   • 处理人员认为此缺陷是由测试人员的操作错误导致，则在评论中录入判断依据，并将状态更改为 Invalid 后打回给验证人员。验证人员确认操作后，决定选择 Close 或 Reopen。

   • 处理人员认为此缺陷是由外部原因导致，则在评论中录入具体原因说明，并将状态更改为 External 后转给验证人员，验证人员后续跟进外部原因的解决情况。
   • 处理人员认为此缺陷属于产品设计，则在评论中录入具体说明，并将状态更改为 ByDesign 后打回给验证人员。验证人员与产品人员沟通后，决定选择 Close 或 Reopen。

5.5 验证处理结果 & 关闭缺陷

【说明】：当缺陷被修复后，验证者会收到提醒，验证者对该缺陷重新验证，验证不通过则在评论中录入错误信息并将状态更改为 Reopen 后打回给处理人，验证通过则修改缺陷状态为 Closed 关闭缺陷。

【操作步骤】：

1. 若验证不通过，则在评论中录入错误信息并将状态更改为 Reopen 后打回给处理人。
2. 若验证通过，则修改缺陷状态为 Closed 关闭缺陷。