在上一篇文章《 關於產品質量的思考 - 我的基本認知 》中，作者通過親身經歷分享了對產品質量的思考和認知：高質量的產品不僅僅是通過測試來保證的，更是通過在真實場景中不斷打磨和改進得來的。本文爲“關於產品質量的思考”系列的第二篇，將以 TiDB 產品發版爲例，探討如何評估產品的質量。文章指出了僅僅根據漏出的 bug 數量來評估質量的誤區，並介紹了一些有效的評估方法，強調了深入瞭解客戶業務場景的重要性 。
每次 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 在測試場景上面的一個差距， 我們只能逐步積累經驗努力追趕 了。
參考
- 關於產品質量的思考 - 我的基本認知
- OSS Insight ( https://ossinsight.io/ )