关于BUG的说明

来龙去脉，轻重缓急，定位能力

---

以上3点是我对BUG要素的简单概括。

• 来龙去脉：BUG产生的

  • 环境：内网、预发布、外网 及相应的环境配置
  • 时间
  • 模块
  • 人员：组内对应的SDE、PM，组外其他相关人员
  • 状态：open, closed, reopen; fixed, rejected, 二次优化;
  • 类型：兼容性，与需求不符，开发漏需求，需求设计缺陷，偶发性，BUG回魂，等...
  • 步骤：复现步骤、截图、日志、系统资源占用情况等

• 轻重缓急：

  • 轻重Severity，一般分为从S0到S5，我们简单采用3段制，严重，一般，轻微，分别对应S1,S3,S5。
  • 缓急Priority，一般分为从P0到P5，我们简单采用2段制，紧急，不紧急,分别对应P2,P4。
    这两点通常合为一个指标，严重性高低

• 定位能力：定位BUG的能力

  • 前端/移动端
  • 服务器

---

bug记录环节越详细，越有助于bug分析、预测趋势、数据统计等工作。但是，目前只需要严格尊守其中一些即可。以上内容从基本的知识层面了解，在工作中灵活应对。

第1点，

(之前已经强调过)我们需要遵守好“状态”这个环节。发现BUG及时做好详细的收录、反馈、跟踪、更新等，要体现一个BUG从发现到关闭中间的各种状态，留下工作操作痕迹和记录，便于总结回顾，同时也作为工作评估参考。
切记：不要事情发生以后再补录bug，提issue，及时发现，及时执行。

第2点，

标准统一的难点是 认知上的统一 。组内所有成员在评估BUG的时候，意见能够高度的统一为一个意见。如，认定这个BUG是严重的BUG，那肯定就是毋庸置疑一致认为的是严重的BUG。但是，这个统一的认知需要通过不断磨合完成，需要对BUG作定向的解读:

1. 确定BUG的真实性
2. 明确BUG的轻重缓急，达成统一的意见
3. 从发现/复现BUG，定位BUG，到提出修改意见(to PM，to SDE)
4. 最后定性(由测试经理决定)
5. 定期对BUG库进行分析(如绘出曲线图等)，报告现状、预测趋势
6. 精彩的BUG进行分享

紧急与否(由测试经理决定)根据项目进展进度来实时评估，项目的重要性，测试完成时间(产品上线时间，自我规定完成时间)

以上两点的都是基本能力，测试工程师STE需要有能力进行区分。

第3点，

也是最难的一点，如何定位BUG，并提出修改意见的能力。 这要求我们测试工程师STE必须要有开发工程师SDE的能力，内功要求特别深厚。例如，前端，至少要懂一些JS，CSS；后台，首先要能看懂大致问题出现在什么地方，逻辑问题，还是设计缺陷。这大概可以分为3个层次

1. 有理有据：知道来龙去脉，能够提供“来龙去脉”中的内容，包括截图、日志等，通知SDE去解决BUG。
2. 经验丰富：知道问题大概出自哪里，以前也遇到过这样的问题，可能是某配置出错，某机器内存满了导致异常。
3. 定位精准：对SDE说，你某分支的某个模块下某个函数调用出错，某个if的逻辑判断出错，这样改改应该就OK了。

努力从经验丰富到定位精准转变
美好愿景：测试对开发说，你改这个文件中的这几行代码。

---

关于gitlab 中BUG的说明

BUG记录的格式和要素：标题格式，严重程度，label，优先级等（优先级，不作为 bug 考核维度标准）

• 标题格式为[项目版本]-(性能/安全)提交测试任务详情

例：

例：

BUG的筛选工具

详见【testing-group/pull-buglist】

BUGLIST 列表定期更新，详细请点击

1. BUG由测试人员创建，BUG指向最终fix的成员，当BUG指回自己时，认为此BUG无效
   • 有效BUG：开发/产品人员可以assign to其他开发/产品人员，fix BUG后，不要Assign to 测试人员，只需等待测试人员验证后关闭。
   • 无效BUG：若开发/产品人员认为此BUG无效，才Assign to测试人员。
2. 所有BUG的Label为bug，注意是小写bug
3. 所有的BUG只能由测试人员关闭，不能由其他人员关闭

---

Gitlab 中 bug 标记规则

为保证统一，系统中的 bug label 均按照以下规则添加
H M L 由测试人员添加， A B C 由 leader 评定

规则略

若需要 批量给 project 添加 label 可找在此处调用脚本处理，需要提前申请权限才能添加。