每次 TiDB 发版本的时候，我一定会被前线业务部门或者客户问到的一句话就是『这个版本质量好不好？』，每次遇到这种问题，我都会非常的无奈，因为我很难给出让人满意的答案。不过这个问题被问的多了，我自然也会思考，到底如何来评估一个版本质量的好坏？
在开始之前，仍然有如下的几个声明：
- 我说的不一定是对的。我也会定期刷新我自己的认知。
- 这仅仅只是我自己关于质量的思考，是我自己在 PingCAP 的经验总结，也并不一定适用于其他公司。
- 我说的也只是 PingCAP 对于质量评估一些方面，实际我们在内部有更多评估维度和指标。
漏出 Bug 数量
我也会跟不少的朋友探讨产品质量问题，有时候我会听到一个很常见的回答，『这个还不简单，就是看在客户那边遇到了多少 bug 就行』。这个不能说没有道理，不过正如我在 关于产品质量的思考 - 我的基本认知 里面提到的，bug 多不一定意味着质量不好。
这里我还想强调另一件事情，通常大家讨论的 bug，属于漏出 bug，也就是已经泄漏到客户那边的 bug，用漏出 bug 数量来评估一个产品质量的好坏，其实已经非常的滞后了，尤其是对于数据库这样的产品来说。根据我这么多年的观察，用户都不怎么倾向升级数据库，甚至在国内一些金融客户，都是按照年为单位来采用发布的新版本，这个反馈周期太长。当然，在云上面提供 TiDB 新版本的服务是能加速这个反馈过程，只不过仍然会有一点滞后性。
当然，这个指标的意义和价值也是非常大的，漏出 bug 对于当前发布的版本属于一个滞后指标，不过它对于下一个要发布的版本是一个实实在在的前置指标。也就是说，我们在下一个要发布的版本里面，是要尽量的去修复上一个版本漏出的 bug 的，如果不做这些事情，质量很容易就失控了。
Bug 收敛
上面我们提到了漏出的 bug 数量，实际在开发版本的时候，我们自己也会自己测试出来非常多的 bug，这些 bug 如果不去修复，仍然会影响我们产品的质量。关于这个，我们通常用 bug 是否收敛来看质量风险。这里稍微解释一下 bug 收敛，关于 bug，一般会有两条曲线，一条是 open 的 bug 数量，另一条是 closed 的 bug 数量，通常对于一个快速迭代的系统来说，open bug 的数量是大于 closed bug 的数量的，随着时间的推移，如果这个差值不断地在增大，没有看到收敛的趋势，或者差值控制在一个很小的范围里面，我们就会认为整个产品的质量有风险。
这里给一个做的很的产品的例子，譬如我们熟悉的 Kubernetes，它在发布几年之后，closed 的 bug 数量已经超过了 open 的 bug 数量。如图：
参考：https://ossinsight.io/analyze/kubernetes/kubernetes#issues
另外一个非常好的例子是 vscode，几乎从一开始，两条曲线的差值就控制在一个很小的范围：
参考：https://ossinsight.io/analyze/microsoft/vscode#issues
对于 TiDB 来说，我们从 7.5 开始，在发布 LTS 版本的时候，会严格控制 bug 的收敛，之前 6.x 的版本，我们需要发布几个 patch 版本，才能保证 closed bug 的曲线超过 open bug 的曲线，而在 7.5 发布的时候，我们就已经能够保证 bug 收敛了。不过这里我仍然想强调，bug 收敛并不意味着没有 bug，只不过能证明质量并没有变得更加糟糕。
后面，对于 TiDB 这个产品来说，我们会开始控制主干版本的 bug 收敛，我们有一个很有野心的目标，就是真的能让 TiDB 做到主干发布，而我们认为，bug 能收敛是主干发布的一个必要条件。
Bug 的聚簇效应
Bug 的聚簇效应是我自己取的一个名字，这么说可能还是会比较让人糊涂，这里举一个能让人印象非常深刻的例子：
通常来说，当我们在家里面见到一只『小强（蟑螂）』的时候，我们已经能预感到，家里面已经有非常多只『小强』了。
注意：因为直接贴实物图恐怕会引起大部分人不适，这里就用 cute 图片代替了。
在我的认知里面，bug 其实也一样。『当我们在一个模块里面测试发现了一个 bug，大概率这个模块还有更多的 bug。』
关于这点认知，我并不确定是否有啥理论依据，我只是根据我多年的经历得到一个很好玩的认知。当然，根据这个认知，我们有时候还能得出一个更好玩的认知：
『当一个研发团队之前开发的 feature bug 比较多的时候，他们开发的下一个 feature 大概率也有不少的 bug』。当然，事情还是会变好的，随着时间的推移，以及研发团队的成长，到最后就是团队开发的 feature 质量有很大的保证。
所以，在发布某一个版本的时候，如果要再次确定这个版本质量可控，在资源有限的情况下，我们就重点放在之前测出来有 bug 的模块，以及一段时间写出比较多 bug 的研发团队开发的 feature 上面。
Feature 的带宽分配和 T-shirt Size
聊完了 bug，我们在聊 feature。在前面 关于产品质量的思考 - 我的基本认知 这篇文章里面已经提到，feature 开发的越多，从某种程度上面就会有更多的 bug，这个并不会以研发工程师的意志为转移。当然，我们又不可能不开发 feature，不然就丢失了长期的竞争力。
所以我们要做的第一件事情就是控制 feature 的数量，尽量做到竞争力和质量的平衡。在 PingCAP，我们的研发 leader 会跟 PM 达成共识，然后评估好这一段时间 team 的带宽投入，譬如投入整个 team 40% 的人力带宽开发新的 feature，40% 的人力带宽去做质量改进和架构重构，剩下的带宽就做 oncall，客户 support，或者个人成长相关的事情等。在 PingCAP，不同的研发团队在不同的阶段，这个带宽分配比例是不一样的。
规划好带宽分配之后，研发 leader 会使用传统 T-shirt Size 来评估开发一个 feature 需要多少人天，譬如一个 feature 的 size 是 XL，那么就是 1 人月这种。
规划好了这些，从大盘来看，包括但不限于有如下情况，就可能会有质量风险：
- Feature 个数多，尤其是 XL size 以上的 feature 个数多
- 一位研发工程师参与了多个 feature，尤其是 XL size 以上的 feature 的开发
- XL size 以上的 feature 负责人是一位比较 junior 的研发工程师
- 一个团队，尤其是做 TiDB 内核的团队，在 feature 开发上面的带宽比例偏高，譬如超过 60%
当然，如果具体到某一个 feature，如果 feature specification 定义的不清晰，test plan 没有，对应的 PR 代码行数变更很多，这些都会是这个 feature 自身的质量隐患，我们也需要注意。关于这一点，后面有空再讨论。
客户场景的测试覆盖
我有一个梦想，就是『我有无限的资源，能写出无限的测试用例，覆盖掉所有的客户场景，那么 TiDB 几乎就没 bug 了』。这个梦想是如此的宏大，以至于让我完全能清醒意识到，我是在痴人说梦。
所以，我们如何能更加高效的通过添加测试用例来覆盖更多的客户场景，从而保证我们发出去的版本在大多数时候都能正常工作，不会给客户带来惊吓？就是一个非常挑战的事情了。
幸运的是，28 原则在这里仍然有效 - 在 PingCAP，20% 的客户几乎贡献了 80% 的问题（这里面的问题不光包括 bug，也包括 oncall 等）。另外我们发现，20% 的这些客户的场景也能复制到其他行业的其他客户上面。
这就给了我们一个很好的指引 - 在资源有限的情况下，只要我们能深入的理解我们 20% 的重要的客户的当前的业务场景，基于这些场景去开发测试用例，我们至少能保证当前阶段大部分场景不会掉链子。20% 的客户的场景测试覆盖率越高，我们对质量就越有信心。当然，如何模拟业务场景，有机会也可以聊聊。当然，当我们觉得 20% 的客户的场景覆盖率不错之后，我们也会逐渐积累更多的场景。
另外一个幸运的发现就是我们当前的不少 bug，来自于新开发的功能直接被重要的客户直接使用，这个在 NA 尤其突出。这其实在某一方面算一个好事情，意味着很多客户竟然愿意直接尝试我们新的版本。所以我们后面在开发新功能的时候，都深入的跟这些客户合作，弄清楚了他们的业务场景，添加测试覆盖，保证新发布功能的质量。
写在最后
上面仅仅只是列举了一些非常直观从我的角度如何评估产品质量的问题，实际在 PingCAP 内部，我们的衡量指标远远不止上面列出来的这一些，毕竟我们做的是一个数据库产品，对于质量的要求是非常高的。
上面我也仅仅只是从测试，bug 等几个角度来讲我如何评估产品质量，并没有涉及到代码，关于代码，我的认知里面，复杂度高的代码质量大概率不好，以及大概率有 bug。这块有机会再聊聊代码的复杂性跟质量的关系。
关于质量，还有一点感悟，即使是同一个 TiDB 版本，我们也可能从不同客户听到不同的声音，甚至同一个客户听到不同的声音，这个不奇怪。不同客户场景可能不一样，或者同一个客户业务场景也不一样，而 TiDB 当前并没有覆盖到所有的场景，我们只能一点一点的补充不同场景的测试用例。
最后在提一个来自 Oracle 的数字，我跟一些来自 Oracle 的同学交流过一个问题，『在 Oracle，你们有多少个客户场景测试？』，大部分的回答都是 200 多个，这个还是非常让我吃惊的，当然数字不一定准确。不过如果真的是这样，大概率 Oracle 的这几百个业务场景测试用例，已经是对客户场景极度的抽象，能覆盖他们绝大部分的客户群体了。这就是当前 TiDB 跟 Oracle 在测试场景上面的一个差距，只能慢慢积累和追赶了。