内測和灰階是用戶端版本疊代流程中的兩個重要階段。在這兩個階段，用戶端的新功能會被真實的使用者使用到。通過使用者的回報，我們往往能夠發現在産品設計、開發、測試中沒有發現過或被忽視的各種問題。内測和灰階的使用者回報能夠更有效地幫助我們改善産品設計和提升産品品質。本文将會介紹内測和灰階的一些基本概念，以及我們在知乎是怎麼做内測和灰階的。
什麼是内測和灰階？
内測
在我們開發完某個新功能并通過測試之後，有時需要邀請部分使用者試用，收集一些意見和建議，對産品進行進一步的優化。在某些情況下，内測使用者的回報可能會影響到整個産品的決策。
内測使用者有兩個來源：一是知乎的内部員工，内部員工在研發過程中更容易下載下傳并使用到内測版本，同時會更加積極地使用并進行回報；二是外部使用者，我們會精心挑選回報意願強烈的熱心使用者，發送私信邀請他們進行内測。内測使用者數量不需要太多，能夠有一些有效的回報就達到了我們的目的。在早期，無論是知乎内部員工還是有意願參加内測的使用者，數量都是比較少的。
灰階
随着知乎用戶端功能越來越複雜、疊代周期越來越短、使用者量越來越大，測試難以覆寫到所有使用場景，即使新版本通過測試，直接對所有使用者進行釋出仍然存在一定的品質風險。同時，由于用戶端釋出之後無法像 web 端或後端服務一樣快速復原，品質風險有時是我們無法承受的。這就需要灰階釋出來幫助我們降低相應的風險。
灰階釋出是指在正式上線前，隻給小部分使用者釋出新版本，而剩餘使用者不受影響繼續使用舊版本，如果新版本沒有問題則進行全量釋出，有問題則修複問題并重新灰階。一般來說，灰階釋出的使用者數量相對于内測使用者較大，這些被灰階到的使用者可能對自己所使用的是灰階版本并不知情。
比較
以上介紹了内測和灰階的一些基本概念，二者的一些差異如下表所示：
在知乎我們怎麼做内測和灰階？
無論是内測和灰階，我們都面臨三個問題：如何讓使用者下載下傳内測/灰階版本？如何持續讓使用者使用最新的内測/灰階版本？如何收集使用者回報？
第三個問題将在後文中詳細說明，對于前兩個問題，内測和灰階分别有不同的方案，而在 iOS 和 Android 這兩個平台上，方案也有些差別。
内測
iOS 和 Android 用戶端的内測方式是完全一樣的，在版本新功能開發完成并經過測試後，我們會把安裝包釋出到 知乎内測平台 上供使用者下載下傳（目前僅支援知乎 iOS 的内測版本下載下傳），而未經過充分測試的安裝包隻會釋出在内網，供内部員工試用。
知乎内測平台
在内測使用者的邀請政策上，我們經曆了兩個階段：
- 郵件邀請内部員工 + 私信邀請外部使用者
- App 内邀請内部員工 + 線下活動邀請外部使用者
在剛開始做内測時，我們很容易想到「郵件+私信」的邀請方式，郵件會發給公司全員，收到私信的使用者也是經常通過各種管道向我們送出回報的熱心使用者，即便如此，内測使用者的數量也是很難做上來的，僅靠郵件和私信的轉化率比較低。
在這一階段，内測使用者的流失也是個很令人頭疼的問題，無論是内部員工還是外部使用者，流失率一直都很高，送出回報的意願也在慢慢降低。為此，我們曾組織過一個名為「Bugday」的活動，以月為機關給積極回報的員工發放各種小禮品，在一定程度上提高了大家使用和回報的積極性。我們也想過把「Bugday」推廣到外部使用者，但由于營運和公關上的一些考慮沒能成行。
一波接一波的私信邀請後，可用的目标使用者池越來越小，轉化率也越來越低，内測使用者數到達 1000 人 的峰值之後，拉新的速度開始趕不上流失的速度，内測使用者數慢慢變少了。與此同時，知乎的業務線慢慢擴張，誕生了一批更加細分，使用者基數相對于整個知乎社群較小的業務，郵件+私信擷取到的使用者往往與這些業務的目标使用者不比對。于是這些業務選擇了通過線下活動擷取内測使用者的方式，通過鹽 Club 、Open Day 、使用者沙龍等線下活動形式邀請使用者使用内測版本并收集回報。
那麼對于内部員工呢？随着知乎的壯大，員勞工數也越來越多，逐漸成為一個豐富的内測使用者資源池，我們借鑒了 Facebook 的先進經驗，給辦公室内的市場版 App 彈出下圖所示的彈窗，邀請并鼓勵内部員工參與内測，這樣相比于郵件邀請更為高效，再次強調一下這個彈窗僅限于 辦公室内的市場版 App ，外面的使用者不會受到打擾。其實，這裡所說的内測并不太準确，我們現在本質上是把辦公室使用者作為灰階使用者的補充，嚴格來講目前并不存在員工内測，隻有對内部員工發灰階。
員工内測邀請彈窗
灰階
由于蘋果的限制，iOS 灰階的實作與 Android 有很大的差別，在這裡我們分别介紹。
Android
對于 Android 我們使用 應用内更新 的方式給使用者下發灰階包，當 App 啟動或從背景切換到前台時，用戶端詢問後端是否有可用的灰階版本，若有可用的灰階版本，則用戶端以彈窗的方式提示使用者可以更新。灰階使用者量可以通過後端開關開啟的時間長度來控制，應用内更新的速度很快，很容易就能獲得大量灰階使用者。後端開關開啟時，使用者也可以通過點選「設定 -> 檢查更新」更新到灰階版本。
iOS
由于蘋果隻允許使用者在 App Store 内下載下傳 App ，無法使用應用内更新的方式進行灰階。雖然蘋果官方提供了 Testflight 供開發者用于内測，但在幾年前 Testflight 并不成熟，在使用上也存在諸多限制，是以在早期我們并沒有做 iOS 的灰階，或者說是用内測的方式代替灰階，使用者量最多達到 1000 左右，這是 iOS 灰階的第一個階段。期間我們考慮過擴大内測版的使用者量，繼續将内測當做灰階，但内測包自身其實存在着各種問題：
- 使用者可以同時安裝内測版和市場版：若同時安裝兩個版本的 App ，在内測版中使用 URL Scheme 跳轉會跳到市場版中，給使用者造成困惑，同時存在兩個版本的 App 使用者更容易解除安裝掉内測版；
- 内測版部分功能缺失：由于微網誌方面的限制，我們沒有在内測版支援微網誌登入和分享；
- 政策風險：蘋果理論上不允許開發者将内測版的企業包給到使用者安裝，曾經有其他公司是以被威脅下架。
由于内測包的這些缺陷，我們最終還是嘗試使用 Testflight 作為灰階的方式，邀請方式仍在采用私信邀請，試用期間我們體驗了使用者安裝成本高、稽核時間長、灰階使用者人數限制等問題，而其中最令人頭疼的還是使用者安裝灰階版的成本很高，Testflight 要求接受内測邀請的使用者提供郵箱位址，在使用者收到 Testflight 的邀請郵件後，再到 Testflight 的 App 中輸入邀請碼進而獲得内測資格并安裝灰階版，由于安裝流程過于漫長和複雜，很多使用者在中途就放棄了。在我們改用 Testflight 之後，灰階使用者數量并沒有明顯增加，保持在 1200 人左右，以上是 iOS 灰階第二個階段。
随着時間的推移，蘋果對 Testflight 做了一些優化，同時我們也發現存在一種免郵件的邀請方式，于是形成了第三階段的灰階方案。首先我們會注冊多個郵箱并将這些郵箱注冊到 Testflight 背景，随後 Testflight 背景會自動給這些郵箱發送邀請碼，我們再從郵箱中爬出這些邀請碼，存儲到資料庫中，當市場版的使用者做了收藏、點贊等正向操作時，用戶端會認為該使用者是灰階版本的潛在使用者并請求一個邀請碼，收到邀請碼之後會引導使用者更新到内測版。由于 Testflight 對使用者有數量限制，我們會定期清理過期和無人使用的邀請碼，保證資料庫中有足夠多可用的邀請碼。
下表對 iOS 灰階這三個階段做了一些比較：
另外，App Store 本身也有對于灰階的支援，對于一些風險比較大的版本，我們有時會使用這種釋出方式。
如何收集回報？
使用者開始使用灰階版之後，我們會通過 Fabric 收集使用者遇到崩潰，使用者也可以通過搖一搖将自己遇到的問題送出到我們的回報收集平台。
我們也做了一些周邊工具，如崩潰監控和報警、一鍵送出回報到 jira 等功能，幫助我們提高收集使用者回報的效率。
未來的改進方向？
以上是我們在知乎進行的内測和灰階的實踐，通過幾年的摸索和持續疊代，内測和灰階有效幫助我們提高了知乎用戶端版本品質。同時我們還有一些有待改進的地方希望在今後持續優化，可優化的點包括但不限于：
- 更高品質：提供更高品質的灰階包給到使用者，把灰階當做全量釋出前的一種驗證手段，而不是寄希望于讓使用者在灰階期間發現前期沒有發現的問題
- 更少次數：減少灰階釋出的次數，減少使用者流失
- 更多元度：支援給特定的機型、系統、地區、特征的使用者下發灰階包，使得灰階更加精确
作者:鐘離無糖
出處:https://zhuanlan.zhihu.com/p/39155476