背景
為什麼是基於交付用戶滿意的產品？
任何一家公司，都應該以使用戶滿意作為企業的宗旨。向用戶交付滿意的產品，也是一種價值觀的體現。
如何定義用戶是滿意的？
校寶在線是一家ToB，提供SaaS服務為主的公司。在同類產品滿意度調查問卷常見的問題中發現，出現頻率比較多的幾個問題包括：系統可操作性，系統對業務的幫助，系統穩定性，對培訓是否滿意，問題處理速度，需要優化的模塊，實施服務，售後服務等。從中提煉了跟質量相關的幾個：可操作性即易用性，系統穩定性，問題處理速度。其中還有一個不那麼明顯，但實際上與質量息息相關的：系統對業務的幫助。測試人員經常會說要站在用戶的視角，這個視角不單是用戶的行為習慣、交互，還有用戶所屬的行業特性。
基於以上背景，制定出了包含需求質量，持續測試體系以及穩定性的質量體系，下面會逐一展開介紹
需求管理
需求的質量從業務正確性和設計合理性兩個方向出發。
業務正確性
既然前面提到了用戶非常關心繫統對業務的幫助，那就不得不提客戶訴求。我們的態度是重視客戶訴求，但不能一味的、不假思索的無腦實現，畢竟校寶是放眼整個教育行業、推動教育服務整體加速進步，因此利於行業標準化、利益化的客戶訴求是我們優先考慮的。其次，不能只看訴求，還要看客戶的目標，短期或中長期的目標，從而幫助用戶尋找實現目標的路徑，這部分就是需求背後的價值以及潛在價值。需求即時性比較好解釋，比如客戶需要一套夏招季的招生方案，你不能在夏招過了才交付招生功能。
設計合理性
教育是一個相對離散的行業，信息化程度低，直到目前依然有很多機構使用手工賬本或excel做教務。而不同門類的培訓領域又高度專業化，比如語言類培訓、藝術類培訓、樂器類培訓等，都有各自領域的專業化，這使得教育服務的標準化面臨巨大挑戰。流程、邏輯、交互都要足夠貼近實際業務場景，所以此時測試人員常說的站在用戶角度決不能是一個互聯網用戶的視角，而是一個教育服務從業者的視角。
如果說業務正確性決定了客戶（老闆）是否願意買單，那麼設計合理性就決定了用戶（實際使用者）是否願意使用。
持續測試
CI/CD/CT
持續測試不是什麼新鮮概念，這裡也不想重新定義，只希望說明我對於持續測試與持續集成和持續交付之間關係的理解，以及我們的路徑。
其實持續集成中明確提到了要通過自動化測試保證質量，從而達到提效的目的。只是往往實踐過程中自動化測試相關的部分容易被忽視或難以實現。那是不是寫好了自動化測試代碼就可以了呢？很顯然，只有它真正執行來才能發揮作用。那什麼時候執行呢。引用註明博主shaonbean的一句話：
“持續集成使項目團隊能夠在需要時執行測試，而不是儘可能多地執行測試”
通過下圖CT部分能夠更清晰的看出在哪些階段用什麼方法測試。
編碼階段通過單元測試和代碼檢查來實現代碼測試；在提測和功能測試階段，部署測試環境通過接口和UI自動化確保歷史功能正確性，這兩項測試通過後才算環境部署完成；系統測試階段主要還是通過手工的功能測試和性能測試來完成；接口和UI自動化用例經過編排後同樣可以在項目發佈時做線上迴歸，以及日常巡檢。
這樣就實現了自動化+手工測試貫穿項目始終。
度量
把需求響應週期分割為開發週期和交付週期兩個階段。
開發階段關注三個核心維度的數據：bug創建時間、bug修復時間以及bug庫存量走勢，從而幫助我們判斷：各階段bug被發現的數量，以及該階段測試用例的有效性；不同階段bug修復的成本；從而進一步評價開發過程的質量。
發佈階段關注發佈頻率、發佈前置週期等數據，進而提現團隊持續發佈的能力。
項目交付後，還要繼續跟蹤現象問題的數量、類型以及修復時常等數據。
規範
度量數據只能間接的提醒我們項目中還存在哪些問題，需要有一個工具來承接這些問題，從而推動改進，規範承接了這個使命。
分別制定了開發規範、測試規範和交付規範，具體規範內容就不一一列舉
圖中橫向提現了研發 - 測試 - 發佈的項目完整流程。縱向提現的是一套包括CI/CD - CT - 度量 - 規範在內的可持續改進的閉環。
穩定性
穩定性方面包括兩大塊，一是主動維穩，類似汽車的主動安全系統，例如車身穩定、剎車防抱死等，其作用是避免發生交通事故，同樣主動維穩也是為了避免發生線上故障。考核指標為故障次數。
在覆盤以往的線上故障時發現，有79%的故障由變更引起，包括代碼變更、配置變更、數據變更等等。而項目發佈佔變更的絕大多數。此外，用戶對核心業務故障的容忍度非常低，因為這些模塊的不可用很大程度上會造成整體業務流程阻斷的風險。因此，根據業務的核心程度、造成阻斷的可能性等維度，將故障嚴重等級從高到低劃分為P0到P3四個等級。在穩定性建設初期，我們主要聚焦於預防項目交付可能引起的P0級故障。在穩定性小組識別到項目的變更可能存在P0故障可能的時候，會走指定的項目流程，該流程的核心是灰度和穩定性測試。
灰度用於驗證發佈過程和功能迭代可能導致的線上故障。穩定性測試包括高可用驗證和性能測試，用於驗證系統在高壓或資源吃緊時系統的表現。過去的一年裡，主動維穩多次避免了線上P0級故障。
二是被動維穩，類似汽車的被動安全系統，例如安全帶、安全氣囊等，能夠在發生事故的時候保護乘客，只是被動維穩更關心一旦出現故障，怎樣儘快恢復系統可用。考核指標為故障時長。
被動維穩包括監控、定位和恢復三個部分。線上故障面臨一大挑戰是如何先於用戶發現它並恢復它，無論如何都不能接受由用戶來告知我們出了線上故障的事情持續發生。
這時候監控和恢復就起到了決定性測作用。根據預期閥值設定不同維度的監控告警，包括基礎基礎資源層面的資源監控，像CPU、內存、磁盤使用率等；基礎組件的監控告警，像CDN告警、ECK異常監控、事件消費監控等。加上重新編排的用於線上業務巡檢的UI自動化和接口自動化測試用例，基本實現了有效預警和及時發現線上故障的目標。一旦確認出現線上故障，要第一時間進入恢復流程。此時的值班人員就像救火隊，規章制度絕對不能少。而回滾和重啟大部分情況下是恢復過程中首要考慮的步驟，希望可以在操作上足夠的簡單，都做到了一鍵化。而自動擴/縮容、高壓自動隔離/恢復等K8S自動化的實踐，使得在某些特定情況下，系統出現了預警時做到無人介入即可自動恢復的可能。
定位，是在面臨線上故障時，最希望跳過的環節。一來，定位本身需要很長時間，會造成用戶更大的損失。二來，定位後的修復、發佈會給生產環境帶來更大的變更風險。因此，在故障處理過程中更多是先恢復後定位的策略。主要在數據層、容器層、流量控制層和鏈路訪問層面上添加了日誌，用於協助事後定位問題。