这边介绍比较正式的Bug处理方式。 一、Bug 分级：何时该修，何时可以不修 二、相关配套 补充：每间公司的文化不同，常见叫法有 Issue / Case / Defect(偏硬体厂商) ======================= 一、Bug分级 不是所有Bug都一样严重，所以发现问题时，需要进行分级，来决定解决的优先顺序。 类似医院急诊会需要先分级，有生命危险的优先处理，而不是先来先服务 (First come, first served) 当发现问题後，会需要回报以下资讯 。问题主旨 。问题描述 。优先处理性 Priority 。严重性 Severity / 影响 Impact 。频率 Frequency 。相关资讯 - 发生版本 。重现步骤 Reproduce step 。相关Debug资讯 - Log - Screenshot/照片 ========== 。严重性 Severity / 影响 Impact 问题发生会造成的影响，包括 对产品造成的影响、对商誉造成的影响 通常会分4或5级 Critical (1)、Major(2)、Minor(3)、Improvement(4)、Suggestion(5) 简单概念是 Critical： 造成产品/服务无法使用 ex: Crash/闪退，无法正常启动使用 / 主要功能无法运作，影响後续测试进行(blocker) Major: 主要功能无法使用 ex: 某功能/function 操作结果与预期不同 Minor: 功能无法使用/不如预期，但使用者可以自己找到解决方法，或不影响操作 ex: UI 没有对齐 Improvement： 既有功能可以更好，有空就做。 ex: 不到feature等级的改动。 or 决定这版本不修，放到下个版本处理 Suggestion： Nice to have 很少用到，甚至会跟improvement混在一起 ========== 。频率 Frequency 问题发生的频率、多久发生一次。通常无法量化表示，会用抽象的形容词 比较常见的状况是 Always(100%)、Often(>50%)、Sometimes(<50%)、Rarely(只发生一次) 上面的频率只是抓个感觉，不必计较明确的百分比 例如在reproduce过程中 发现问题後，可以直接做出来 => Always 发现问题後，再尝试了1次、没有，第二次尝试才做出来 => Often (2/3) 发现问题後，经过多次尝试可以做出一次 => Sometimes (2/N) 只发生一次，不知道或者找不到明确触发原因 => Rarely (1/N) =========== 。优先处理性 Priority 实际上决定bug要不要修，以及修的优先顺续关键。 一般而言，都是直接按照 Priority做排序，由高到低来修 通常也是分4级 Priotiry 1~4 (P1~P4) P1：当天优先处理 P2：特定milestone前一定要修完/close P3：release前一定要修完/close P4：可修可不修 / 下个版本再修 如何决定Priority？ 由 严重性Severity x 频率Frequency 决定 下表提供参考。实际上还是要看每间公司/组织自己定义 严重性 频率 Critical Major Minor Improvement Always P1 P2 P3 P4 Often P1 P2 P3 P4 Sometimes P1 P2 P3 P4 Rarely P2 P3 P4 P4 例如： 程式crash/闪退，即使频率很低，但影响很大，一定处理到底 (Critical x Sometimes => P1) UI没对齐，很丑，100%会遇到但是不影响使用者操作，就会是 (Minor x Always => P3) ========== 二、相关配套 1. 通常会有一套issue tracking system来辅助。 如果还是用Email/Excel做纪录的团队，表示还有很多进步的空间， 可能也不会遇到上面的概念。 通常系统除了完整记录资讯外，还有一些特殊功能 不同版本之间的串联，这个bug发生後，回过头可以去找到哪些版本/branch有一样问题 可以把fixing直接导过去 (平行版本、客制版、不同语言版) 或者回头去修上一版 (传统on premise软体、韧体) 掌握整个软体品质状况 (Manager/Leader level) 透过issue抓到的数量，导成S curve後，可以分辨出软体中bug大约找出的数量与状况 来判断测试周期是否足够，可否结束。 例如：在同样的测试能量下，单位时间内被找的Bug数量是呈现往上还是收敛的趋势 2. Issue Review 每天会Review当天找到的bug，针对Priority进行调整。 (Priority一开始是由发现者填写) 除了调整顺序外，会让整个团队清楚目前品质状况。 参与者通常是Manager/Leader (Dev、QA、PM 至少各一) 先这样，欢迎其他版友补充。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.169.208.120 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1654173453.A.C23.html ※ 编辑: wt (118.169.208.120 台湾), 06/04/2022 00:34:49