15.10 会诊（Triage）
15.10.1会诊Bug
在这一阶段，移山团队开始了每日会诊。目的是要尽快减少bug 的数量，以保证按期交货。
第一步：提交参加会诊的bug。
bug的各个字段都要提供详尽的信息。每个测试人员和PM要努力使得提交的bug不会出现下面的情况：
重复（Duplicated）：已经有人报告了同一个小强。
无效（Obsolete）：报告的情况是关于无效的软件功能的（如已经被砍掉的功能）。
无法重现（Unable to reproduce）：没办法重现犯罪现场。这个小强还是有价值的，因为有些小强就是随机发生的，但是测试人员要和开发人员一起找到bug发生的原因。
第二步：决定bug的命运。
如果决定修改，我们要设置优先级，并把它分派给团队成员。
如果同意可以不修改，则有下面的选择：
a. 设计（As Designed）：程序就是这么设计的；
b. 推迟（Deferred）：推迟到下一阶段，再处理。
第三步：会诊设置 bug 的优先级Priority，然后设置bug的会诊（Triage） 字段为yes。表明已经经过了会诊。
二柱：优先级还要规定？这些都是要在RTM 之前完成的，都是优先级1。
阿超：首先，我们从来没有规定RTM 之前要完成多少bug，事先假设我们必须全部完成是不对的。注意，如果所有的事都是最高优先级，那就等于没有优先级。决定一件事是一个较低的优先级，需要很多勇气。
15.10.2会诊修改方案（BugFix）
在稳定阶段的初期，团队只要决定哪些缺陷需要修复，然后团队成员就会进行必要的设计—实现—测试工作，把修改签入。但是随着项目进展和发布日期的临近，团队还要保证修改方案不会给产品带来负面的影响。这时，要对修改方案也进行会诊。这也有三个方面：
第一步：开发者提交参加会诊的bug和修改方案。
第二步：会议决定是否同意修改方案。
第三步：执行。
下面详细说明：
第一步：开发者提交参加会诊的bug 和修改方案，伙伴测试（Buddy Test）结果。
开发者必须报告与会者：
（1）bug是什么。
（2）危害是什么，如果不修复，有何后果。
（3）用户会有什么变通办法。
（4）是否经过代码复审，是否经过伙伴测试。
第二步：会议决定是否同意修改方案。
决定哪些缺陷必须现在就进行，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列的处理方式。
（1）Must ——必须修复，缺陷很严重，修复方案可行，相关的测试都通过。
（2）MoreInfo ——需要更多的信息，可能的原因有：
a. 缺陷的影响不明确，例如，这个缺陷是在任何情况下都发生，还是只在某一特定情况下才出现，因此不能做出决定；
b. 相关的测试不完备；
c. 解决方案有缺陷（会诊会议成员可以复审解决方案和代码的改动）。
（3）No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求。
（4）Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“must”，那么处于待命状态的“like”修复就可以一起集成到代码库中。如果没有“must”级别的修复，那么“like”级别的修复就只能处于“待命”状态，直到以后出现了“must”级别的修复为止。
如果再也没有“must”的修复，咋办？这些“like”的修复只好等到下一个里程碑了。这样做的好处是最终发布的版本不会因为一些小的修复而不断地更新，而消耗过多的测试资源。
对于管理团队来说，重要的是要通过每天的会诊让团队了解must/no的标准，帮助团队的成员了解目前整个项目所处的位置。举例说明，在每一次会诊之后，列出下面的两个极端情况：
（1）刚刚超过门槛的修复（The lowest“must”）——意味着这个修复可以集成到Release代码库中。
（2）刚刚达不到门槛的修复（The hardest“no”）——意味着这个修复不能集成到Release代码库中。
在项目接近尾声的时候，要保证门槛越来越高。今天的“must”（超过门槛的修复）必须比昨天及以前的“no”严重性要高，这样才能不断提高系统的稳定性。
荔荔：但是我们好不容易准备了充足的材料，然后会诊说“no”，我们的努力就白费了？
阿超：你做的所有这些准备工作，都是必要的，只不过是在最后阶段比较关键，要求提供完整的材料，并不是说以前就可以随意签入修改。另外，有些修改，可以签入到另外的源代码分支中。比如我们有beta-release分支，有main分支，一个修改可能没必要签入到beta-release中，但是可以签入到main分支中。
15.10.1会诊Bug
在这一阶段，移山团队开始了每日会诊。目的是要尽快减少bug 的数量，以保证按期交货。
第一步：提交参加会诊的bug。
bug的各个字段都要提供详尽的信息。每个测试人员和PM要努力使得提交的bug不会出现下面的情况：
重复（Duplicated）：已经有人报告了同一个小强。
无效（Obsolete）：报告的情况是关于无效的软件功能的（如已经被砍掉的功能）。
无法重现（Unable to reproduce）：没办法重现犯罪现场。这个小强还是有价值的，因为有些小强就是随机发生的，但是测试人员要和开发人员一起找到bug发生的原因。
第二步：决定bug的命运。
如果决定修改，我们要设置优先级，并把它分派给团队成员。
如果同意可以不修改，则有下面的选择：
a. 设计（As Designed）：程序就是这么设计的；
b. 推迟（Deferred）：推迟到下一阶段，再处理。
第三步：会诊设置 bug 的优先级Priority，然后设置bug的会诊（Triage） 字段为yes。表明已经经过了会诊。
二柱：优先级还要规定？这些都是要在RTM 之前完成的，都是优先级1。
阿超：首先，我们从来没有规定RTM 之前要完成多少bug，事先假设我们必须全部完成是不对的。注意，如果所有的事都是最高优先级，那就等于没有优先级。决定一件事是一个较低的优先级，需要很多勇气。
15.10.2会诊修改方案（BugFix）
在稳定阶段的初期，团队只要决定哪些缺陷需要修复，然后团队成员就会进行必要的设计—实现—测试工作，把修改签入。但是随着项目进展和发布日期的临近，团队还要保证修改方案不会给产品带来负面的影响。这时，要对修改方案也进行会诊。这也有三个方面：
第一步：开发者提交参加会诊的bug和修改方案。
第二步：会议决定是否同意修改方案。
第三步：执行。
下面详细说明：
第一步：开发者提交参加会诊的bug 和修改方案，伙伴测试（Buddy Test）结果。
开发者必须报告与会者：
（1）bug是什么。
（2）危害是什么，如果不修复，有何后果。
（3）用户会有什么变通办法。
（4）是否经过代码复审，是否经过伙伴测试。
第二步：会议决定是否同意修改方案。
决定哪些缺陷必须现在就进行，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列的处理方式。
（1）Must ——必须修复，缺陷很严重，修复方案可行，相关的测试都通过。
（2）MoreInfo ——需要更多的信息，可能的原因有：
a. 缺陷的影响不明确，例如，这个缺陷是在任何情况下都发生，还是只在某一特定情况下才出现，因此不能做出决定；
b. 相关的测试不完备；
c. 解决方案有缺陷（会诊会议成员可以复审解决方案和代码的改动）。
（3）No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求。
（4）Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“must”，那么处于待命状态的“like”修复就可以一起集成到代码库中。如果没有“must”级别的修复，那么“like”级别的修复就只能处于“待命”状态，直到以后出现了“must”级别的修复为止。
如果再也没有“must”的修复，咋办？这些“like”的修复只好等到下一个里程碑了。这样做的好处是最终发布的版本不会因为一些小的修复而不断地更新，而消耗过多的测试资源。
对于管理团队来说，重要的是要通过每天的会诊让团队了解must/no的标准，帮助团队的成员了解目前整个项目所处的位置。举例说明，在每一次会诊之后，列出下面的两个极端情况：
（1）刚刚超过门槛的修复（The lowest“must”）——意味着这个修复可以集成到Release代码库中。
（2）刚刚达不到门槛的修复（The hardest“no”）——意味着这个修复不能集成到Release代码库中。
在项目接近尾声的时候，要保证门槛越来越高。今天的“must”（超过门槛的修复）必须比昨天及以前的“no”严重性要高，这样才能不断提高系统的稳定性。
荔荔：但是我们好不容易准备了充足的材料，然后会诊说“no”，我们的努力就白费了？
阿超：你做的所有这些准备工作，都是必要的，只不过是在最后阶段比较关键，要求提供完整的材料，并不是说以前就可以随意签入修改。另外，有些修改，可以签入到另外的源代码分支中。比如我们有beta-release分支，有main分支，一个修改可能没必要签入到beta-release中，但是可以签入到main分支中。
鄂公网安备 42010302001612号