酷家樂大型專案質量保障反思

以雲圖為例，回顧反思一下超大專案的質量保障該如何做。

背景

雲圖專案是設計工具一次大升級，涉及敏捷組20+，專案參與者100+，專案歷時11個月；其中啟動到釋出歷史6個月；使用者遷移歷時5個月。

核心難點:

難點1 涉及核心底層改造，影響面廣測試覆蓋難度大。

之前設計工具是各個業務獨立各自的前端模組，在頁面上，各模組有不同的入口。這樣好處是模組間沒有耦合，研發不需要考慮太多不同業務間可能產生的相互影響；但壞處是，不同模組業務互動有越來越多的相似之處，比如都允許撤銷恢復，都有選中、拖動等基礎互動功能；不同模組分別獨立維護這些功能，研發資源投入呈線性增長，同時還可能出現同樣的功能但互動視覺體驗不一致的現象。

為了降低整體開發成本，提升基礎公共互動的可複用性和一致性，前端開發了一套基礎應用框架。由框架層提供統一的資料管理機制，標準元件庫（比如導航、訊息框等），公共基礎庫（http，throttle，repromise）等。各模組都在該框架提供的基礎能力之上擴充套件業務功能。

隨之而來不得不考慮的是: 基礎框架提供的能力邊界是否明確?如何保證框架的升級擴充套件對業務保持透明？如何保證資料在不同模組間傳遞的正確性和完整性？如何評估框架升級的影響面？這些問題都需要有相應測試手段做兜底保障。架構、設計、開發環節的任何疏漏都需要在測試階段最終反映出來。

難點2 不同工具模組入口和功能融合，對使用者機器資源的消耗也大幅增加，如何保障效能體驗不衰退？
既然帶來機器效能消耗增加，為什麼要做這樣的互動和功能變化？ 因為裝修設計工具本身是一個複雜體系，設計師使用工具完成一個完整裝修方案的設計，少則需要數小時，多則需要幾天。設計工具本身的互動使用便利性，對設計師的工作效率有至關重要的影響。通過融合工具的各個模組，降低設計師在不同模組下的切換次數和互動次數，可以大大提升設計師工作效率和設計體驗。克服隨之而來的效能問題自然是研發當之無愧的職責之一。畢竟網際網路技術也是伴隨使用者流量的增長和體驗要求的提升，而變革升級！

難點3 整體互動體驗和佈局上的改進，難以避免會帶來使用者習慣的改變，如何平衡使用者體驗和使用者習慣的關係？
在功能和互動變化決策上，產品都是經過深思熟慮和多輪討論的。但是當變化的點比較多的時候，我們仍然很難準確評估到使用者的反應；事實上我們原計劃3月份完成設計師使用者遷移，直到9月份才最終完成。這個過程中既有產品各種不完美，不斷迭代；也有在運營手段策略上不斷調整幫助使用者儘快適應。

解決方案

在這樣的專案中，QA需要擔當怎樣的職責？這麼多敏捷組如何高效協同？有哪些關鍵抓手? 最終要達成怎樣的目標？如何量化目標是否達成？
首先，關於測試的職責，看起來似乎是個挺簡單的問題；但是細節邊界值得追究，比如：各個模組測試是不是隻保證自己負責的模組質量就可以了？是不是產品定義過的問題測試都不需要再關注？歷史存在未解決的問題是否需要測試關注？符合質量紅線就可以高枕無憂的釋出了麼？測試是不是隻彙報問題就好，能否改或者改成怎樣產品決策就好？

在不同角度，對這些問題可能有不一樣的答案，作為整體專案質量負責人有必要把這些問題和大家澄清，確保大家達成一致，並且有一致的執行方案。這是作為一個職能團隊的基本專業性體現。

其次，大專案涉及人多，網際網路公司一般沒有特別嚴格細化的流程要求，資訊不對稱協作不順暢是常有的事情，如何最大限度降低這類問題對產品交付質量的影響？

1. 由測試負責整體部署和釋出。負責部署和釋出，其實是一件比較繁瑣的事情，涉及細節問題和跨組溝通較多。但是同時，部署和釋出也直接決定了最終交付到使用者的產品質量。所以掌控釋出，是測試重要關鍵抓手之一。這一環節的可控性保障了交付質量的可控性。除此之外，掌控部署和釋出，使得我們可以更流暢的把質量卡點和持續整合融入到釋出流程中，不斷優化系統流程，降低協作成本。在雲圖專案中，我們掌控釋出的同時，和前端協作推廣新的前端釋出系統，並將自動化用例和基礎配置檢測納入部署前自動檢測流程；結合企業微信機器人在各個關鍵整合點和灰髮點做自動提醒和紅線檢測，這些手段都有效的保障了各組的有序高效協同。
   

2. 對專案關鍵里程碑設定保障策略，質量目標和check機制。這裡容易出現的是，只設定一個最終質量目標，不關注階段策略和目標，這樣很容易導致要麼過程質量問題沒有及時得到關注，導致最終結果無法達成預期；要麼過程該做的事情沒做到位，資料結果看起來很好但上線後問題頻發。在這個專案中，我們分三個階段：模組測試階段，整合測試階段，灰髮階段都制定了相應的測試範圍和階段質量目標。對應的測試內容和目標都要經過大家充分討論一致認同。實際執行中，出現階段目標未能達成也是不可避免的事情，但是有了前期的標準，使得我們可以針對問題現狀開展討論，引起大家對質量風險的關注並制定相應的解決措施。測試本身保持對質量的嚴謹和前後一致的態度，才能逐步把這種態度感染到整個團隊；而一個有高度質量意識的研發團隊才能是一個靠譜高效的團隊。這裡討論的設定目標，範圍和保障機制看起來是蠻簡單的事情，但是特別容易出現關鍵細節遺漏，以及過程變化帶來的風險遺漏。所以這裡需要經過嚴謹的評審，和對變化的時刻關注。在雲圖專案中，我們的效能測試方案雖然各個模組都經過了評審，但是仍然忽略了資料融合情況下效能表現。這一關鍵細節，導致上線後卡頓的反饋遠超我們預期。

3. 關注模組間的邊界和耦合部分。組織結構上，不同組負責各自模組，模組間耦合的部分往往邊界不清職責不明，容易出現問題且不易被發現，即使發現了排查成本也相對更高。而測試作為交付使用者的最後一道防線，需要特別關注這類問題。測試手段上，除了整合階段規劃專門的模組整合測試用例外，為了避免bug修復和版本迭代引入新的問題，我們對模組基礎功能做了自動化指令碼，保障A模組改動不會導致關聯的B模組不可用。但仍然需要探索更有效的保障手段儘早發現模組耦合導致的功能衰退。

4. 盡一切可能用技術手段協助發現問題。這是作為一名有追求的測試的需要不斷突破的。在雲圖專案中，我們建立了效能基線自動化；完成了核心業務的監控看板和告警；開發了多個企信機器人實時通報質量資料；推進了多語言檢測工具支援國際版翻譯完整性檢測...目前隨著對線上暴露問題的不斷分析，開始著手做chrome外掛工具，在測試應用工具過程中自動檢測並上報重複請求，異常日誌，低幀率場景等各類問題。
   最後，釋出上線不是終點，順利穩定交付到使用者才算走完專案全程。

雲圖從釋出上線，到完成使用者遷移歷經5個月；這中間經歷了一輪又一輪的引流，蒐集反饋，優化改進。值得驕傲的是我們制定的引流策略，結合運營策略很好的控制了使用者流量；使得儘快蒐集到問題的同時不至於問題的影響面過大，也為後端擴容預留了一定空間。而云圖專案釋出後最大的問題還是效能體驗問題。我們老版中缺乏有效的效能資料度量，在雲圖上線初期也沒有效能資料度量。導致我們單純依賴測試結果認為效能符合預期。直到收到大量反饋效能體驗不如老版本，才意識到需要儘快建立數字化線上效能度量，單靠測試階段小樣本的評估資料是遠遠不夠的。（這裡也有前面提到的效能測試方案本身存在關鍵細節遺漏）.

所以吸取經驗，不能單純依賴測試階段的結果作為能否交付使用者的評估依據。一方面需要健全度量機制，結合引流階段的使用者反饋和產品資料（比如使用者主動退回老版本比例），做出更準確的判斷。另一方面，需要提前制定資料蒐集響應機制，在蒐集到資料和反饋後儘快速制定策略，優化後再做新一輪的引流評估。

關注我們

酷家樂質量效能團隊熱衷於技術的成長和分享，幾乎每個月都會舉辦技術分享活動（海星日），每半年舉辦一次技術專題競賽分享（火星日），並將優秀內容寫成技術文章。

我們儘可能保障分享到社群的內容，是我們用心編寫、精心挑選的優質文章。如果您想更全面地閱讀我們的文章，請您關注我們的微信公眾號"酷家樂技術質量"。

如果您有興趣瞭解我們的職位和團隊情況，請參考最新職位招聘，並聯系caibao@qunhemail.com。感謝您的閱讀！