![]()
作者：京東科技 王先科、馮雪梅、趙寧、張彤、張環、蔡婷婷
俗話說，“測試是質量的守護者”，但單憑測試本身卻遠遠不夠。大多數情況下，測試像“一面鏡子”，照出系統的面貌，給開發者提供修改代碼的依據，這個“照鏡子”的過程，就是質量評估的過程，或者說，測試的過程更像“量體溫”，雖然可以測量出溫度進而判斷健康狀況，卻不能靠量體溫治病。同時，需求交付的高質量不僅僅體現在結果層面，如功能、性能、可靠性、可用性、可維護性、安全性以及用戶體驗，也應該包括交付的過程層面，如業務需求的高質量、產品文檔的高質量、提測代碼的高質量等等。所以，應該站在更高的維度、更寬的視野來看待質量保證。本文基於C端用戶拉新的業務場景，以質量保證的全視角，總結了質量保證過程中的框架、策略、流程、規範、方法、工具以及實踐，全面闡述了用戶增長質量保證的價值觀、方法論以及我們所理解的內涵，即高質量=質量策略多樣化+質量流程標準化+質量活動規範化+質量工具平臺化+質量運營常態化。限於自身認知、專業能力以及總結能力的侷限，文中有些觀點可能有些偏頗甚至是錯誤的，同時也並不意味着我們的水平足夠高，可以在這兒傳道解惑，更大的意義在於我們在梳理本篇文章的過程，本身就是一個不斷學習、總結、反思及尋找差距的過程，同時也許能給大家帶來一些有用的信息及有價值的思考。
2.1 質量保證的職責
作爲“質量的守護者”，澄清質量保證的職責至關重要。在我們看來，質量保證職責可以總結爲以下幾個方面：
在功能、兼容、體驗、性能、安全等屬性的基礎上，明確業務需求的質量標準，站在用戶及業務的角度，用最小的成本達到業務可接受、用戶體驗有保障的質量要求。
制定質量計劃和策略，明確測試目標、測試範圍、測試方法和測試時間表，以及其他質量保證活動的安排。
進行各種測試活動，包括功能測試、性能測試、安全測試等，以評估產品或服務的質量，及時發現並推動解決潛在問題。
跟蹤和管理缺陷報告，確保問題得到及時解決，並與開發團隊合作進行缺陷修復和驗證。
基於測試結果和質量評估，質量保證人員提供針對改進產品或服務質量的建議和措施，以確保產品或服務的持續提升。
持續監控產品或服務的質量，進行統計和洞察分析，並參與持續集成和持續交付的流程，以確保質量活動的有效性和持續改進。
針對共性的質量問題、安全問題及用戶體驗問題，優化質量保證流程規範，提供相關的培訓和指導，分享最佳實踐。
2.2 質量的挑戰
在京東科技-市場與平臺運營中心的用戶增長領域，其項目整體表現形式是通過活動帶動增加金融APP新、業務新和C端新的用戶數量，進而進一步提升APP的活躍用戶數，提高白條、金條、小金庫、基金等業務的交叉轉化。這些活動大致可分爲三種類型：大促會場、C端拉新活動和營銷工具。大促會場是指我們在618、雙十一、年貨節等大型活動期間推出的會場頁面，通過展示不同的利益點、玩法、商品樓層以及推薦算法，來吸引不同身份的用戶進行轉化；C端拉新活動的表現形式主要包括在金融場、零售場及外場（微信、抖快、其他app）投放拉新各類活動，同時結合節日、社會熱點等進行營銷活動投放，此外還可以通過玩遊戲的方式引導用戶進行實名認證、完成九要素、綁卡、開通金融業務等業務轉化；"一分購"系列是典型的拉新工具，針對新客支付一分錢購買的形式實現業務轉化，包括一分系列工具等項目。若按照拉新的策略分類，可以分爲拉新工具、擴大流量敞口、提升承接效率三類項目，如下圖所示：
針對以上三類項目，我們總結了用增項目的以下幾個特點及質量挑戰：
2.2.1 主打一個快
基於用戶增長項目本身的特殊性和時效性，很多項目本身就是一個不斷試錯的過程，因此，需要快速上線、快速反饋和快速調整。這就要求測試人員能夠快速識別和驗證各種場景，出現線上質量問題需第一時間解決，儘量減少對業務的損失和用戶體驗的損傷。
2.2.2 細節定成敗
很多活動的成功是體現在細節上的，需要不斷琢磨用戶心理，例如一份返現項目，在頁面文案、樣式、交互、利益點等方面反覆調整，通過給不同樣式的活動頁面做分流以及一段時間的運營，找到幻化效率的最有方式，同時爲防止用戶審美疲勞，也要週期性的更換文案和樣式。在此過程中，測試需要準確識別出需要驗證及迴歸的流程和功能點，做到低成本精準測試。
2.2.3 迴歸深似海
用戶增長項目的很多功能是相互影響的，牽一髮而動全身。因此，在進行功能改造和新增時，我們需要對歷史功能進行迴歸測試，這個迴歸測試不僅僅侷限於主流程，還需要關注更多細節。由於項目的快速迭代，要求測試人員具備高效的測試技巧和精準定位迴歸範圍的能力，以確保項目的穩定性和可靠性。通過持續的迴歸測試，我們能夠發現和解決潛在的問題，提高項目的質量和用戶體驗。
2.2.4 體驗要求高
體驗問題也是用戶增長的項目需要重點關注的事項之一。由於項目大多數是直接面向C端用戶的，一些微小的問題，如話術不嚴謹、跳轉異常、字體太大/太小、按鈕位置不居中、提示信息不明確、挽留彈窗太多、熱區太大、關閉按鈕不明顯等都可能會成爲客訴原因，且用戶體驗的友好程度直接關係到用戶增長和業務轉化的效率。因此，測試同學在需求評審、測試用例評審及測試執行時，要把自己當成一個普通用戶來思考交互是否合理、體驗是否有優化的空間。
2.2.5 資損壓力大
用戶增長項目大多都會給用戶發放各類權益，是否會被刷、風控用戶如何處理、如何預防資損風險、如何識別異常流程以及如何做好兜底，是需要思考的重中之重。另外一方面，爲保證項目運營過程中隨時調整運營策略，一般會將文案、彈窗、利益點、人羣策略等全部配置化，如何從系統層面簡化配置、防止配置錯誤也是需要解決的重要課題，一旦配置錯誤，可能會導致鉅額的資損或批量的客訴。
2.2.6 物料準備難
由於C端拉新活動要針對各種類型的新人賬號（未實名、未9要素、未綁卡、C端新、業務新等）實現活動可見、可領，領取利益點之後實現身份轉變，因此測試過程中需要各種類型的賬號針對各種正常和異常場景進行測試驗證。難點主要體現在測試賬號需求量大、賬號不能重複使用、同一賬號在上線前無法完成全流程驗證、上線後需要真實的賬號（C端新、業務新）進行驗收等。雖然內部可以通過賬戶加白名單、申請C端新內部賬號、申請超級賬戶等方式來支持測試，但由於依賴風控、實名、營銷、銀行等多個外部系統，大多數情況下測試賬號很難驗證全流程。
2.3 質量價值觀
針對用戶拉新業務領域，結合該領域的業務特點、質量實踐和我們對質量的理解，我們總結了以下幾個方面作爲對用戶增長質量價值觀的思考，並在團隊內部達成了共識。
2.3.1 全民質量保證
質量不是測試同學的專屬職責，也不是光靠測試同學就能達到高質量，質量需要全員參與，每個人都是質量的守護者。在我們的質量實踐中，在交付全流程中共有7道防線來防範缺陷逃逸到線上，業務/運營、產品、研發、測試及項管雖分工不同，但都是質量防線必不可少的角色。
2.3.2 預防大於發現
質量保證過程中，預防問題的發生比事後發現和糾正問題更爲重要和有效，在問題發生之前採取預防措施，以便在源頭上消除潛在的質量問題，其預防成本往往比缺陷修復的成本更低。在我們的實踐中，預防缺陷的主要舉措包括：強調需求文檔的準確性、清晰性和完整性；提測前嚴格的代碼評審，可以減少代碼中的潛在問題和錯誤；提前介入測試，以確保產品滿足需求，從根本上提升產品質量；推廣質量文化，各個角色都應該意識到缺陷預防的重要性。
2.3.3 質量是免費的
爲了保證交付質量，應該儘量在產品設計、開發和測試環節上投入足夠的時間、資源和精力。雖然短期內產生的投入可能會增加成本，但與質量問題相關的額外成本（客訴、資損、研發修復成本等）可能會更高，而質量的提升最終都會體現在線上質量穩定、性能提升、交付效率提升及用戶體驗的提升。所以，從某種意義上講，質量不是成本，質量不僅是免費的，還會產生額外的利潤。
2.3.4 質量不是測出來的
測試本身不能有效提高質量，就像溫度計並不能降低體溫一樣，質量內建纔是質量保證的核心，需要從需求分析、研發設計、開發、測試、上線、運營等各個環節都關注質量。提高全民質量意識、儘早發現缺陷、落地敏捷DevOps理念、工具和方法，建立並不斷優化研發流程和上線規範，通過質量前置及測試右移等方式建立全流程質量保證體系。通過這些質量內建的方法，可以有效減少缺陷和問題的發生，提高質量和穩定性，同時也能節省後續的測試和修復工作，降低研發成本。
2.3.5 質量不是越高越好
過高的質量水平可能會導致資源浪費和不必要的成本增加，質量應該與業務的實際需求和使用場景相符，過度追求完美的質量可能會導致開發週期延長、成本增加甚至對用戶體驗造成不必要的侷限。簡而言之，質量就是綜合考慮成本、進度、風險等因素前提下的滿足需求，而不是超過需求。
2.3.6 質量不是無形的
質量不僅能被感受到，還可以被度量。在用戶增長領域，我們常用的質量度量指標包括：需求平均缺陷數和研發人均缺陷數，用以度量缺陷的密度；缺陷關閉率和缺陷關閉時長，用以度量缺陷解決完成度和解決效率；回滾率用以度量待交付需求的穩定性和可靠性；線上事故數用以度量缺陷逃逸到線上的數量，說明線上系統的穩定性。通過質量度量可以將質量目標轉化爲具體的可衡量的指標，從而更好地指導和監控質量改進。
3.1 質量保證方法論
結合用戶增長領域長期的質量實踐及我們所認可的質量價值觀，我們對增長領域的質量保證工作進行了梳理，在過程質量、發佈質量和線上質量保證過程中需採取不同的質量活動，應用不同的質量策略並使用不同的質量工具，爲保證質量策略和質量活動的順利進行，需要與各角色共識質量管理的流程，並通過持續的質量運營，讓質量理念深入人心。總結來說，質量=質量策略+質量流程+質量活動+質量運營+質量工具，而在用戶增長領域，高質量=質量策略多樣化+質量流程標準化+質量活動規範化+質量工具平臺化+質量運營常態化，這就是我們認爲的用戶增長質量保證方法論。
3.2 質量保證體系
我們所在的部門，是直接支持業務獲客和業務增長的研發團隊，在京東生態場、京東金融APP中心場及外部私域場（微信、抖快、電銷及其他外部APP）通過高效的拉新工具、活動投放、用戶承接工具等方式，進行用戶拉新、促活及交叉轉化，不斷擴大用戶規模及交易規模，進而推動消金、財富及支付等C端業務的穩定增長。獲取新用戶是業務增長最爲基礎的工作，不僅有助於保持競爭力、促進收入增長，還可以通過在獲取新用戶的過程中不斷優化產品和服務，加強京東金融APP影響力，對於公司來說具有重要的作用和意義。因此，用戶增長質量保證工作至關重要。
上述質量保證方法論給我們提供了整體的目標和方向，我們對方法論進行細化，質量策略、質量流程、質量活動、質量運營及質量工具都拆解成爲可以落地到質量保證的日常工作中的具體事項，結合平臺研發部整體的質量保證體系以及用戶增長質量保證方法論，我們總結了用戶增長領域質量保證體系全景圖，如下圖所示：
下面將從質量策略、質量流程、質量活動、質量工具及質量運營等5個方面分別闡述用戶增長質量保證方法論的內涵和我們的實踐。
用戶增長項目大多以活動投放的形式針對特定用戶進行拉新，需綜合利用各類拉新工具或組件，以擴大流量敞口、提升承接效率以及最終的轉化率爲主要目標，投放渠道、活動場景、適用人羣、前端交互、用戶操作路徑及利益點多種多樣，相應的質量要求及測試過程也有較大差異，需要根據不同的需求類型和業務場景採用不同的質量策略。在用戶增長項目中，以下幾個質量策略被廣泛應用。
4.1 在測試理念方面，綜合運用敏捷測試和傳統測試的實踐
作爲敏捷研發模式的一個環節，敏捷測試注重迭代測試和增量式交付，系統在不斷的迭代中逐步構建和完善，不強調測試用例的全面性及測試覆蓋度，甚至可以利用探索式測試代替完整的測試用例，以支持快速迭代和收集用戶反饋爲主要目標。例如，在一個團隊默契度高、人員穩定的項目組，團隊採用敏捷測試方法，按節奏進行測試活動，快速驗證，快速上線，有時爲確保快速交付，可以容忍功能、性能及體驗的暫時缺失，以換取主功能的快速交付和麪客驗證，並在後續的版本中快速迭代優化。敏捷研發模式提升了協作效率和研發產能，但並不一定適合所有的場景，傳統的瀑布式交付模式，也有其獨特的優勢。傳統測試更加註重完備的測試計劃和詳盡的測試用例，適用於對穩定性、功能完整性、體驗或性能要求較高的項目，通過完備的測試驗證計劃，確保完整的測試覆蓋，非常適用於功能極爲重要、或者提供基礎能力供多方調用的項目團隊，快節奏的迭代和頻繁的上線並不是最優項。總之，敏捷測試與傳統測試沒有好壞之分，需要適配測試的場景，針對同一個項目，在不同階段也要採取不同的策略。例如一分錢拉新的工具，包括一分返現/返券、一分充值、一分秒現、一分抽獎等拉新工具，在前期，爲了快速驗證，採用敏捷研發模式和敏捷測試機制，針對功能和運營策略快速上線，並投放到不同的渠道快速驗證效果，一些小的體驗問題、不影響主流程的功能問題都可以放到後續的版本中優化，但是到了項目成熟階段，項目組成員被大量抽調到其他項目，新人或臨時性支持的人員較多，這時再強調快速迭代，對底層功能進行大量的修改且不經過完整的測試，一定會對線上的質量造成巨大的影響，此時，按部就班地開發、制定完備的測試計劃、準備完整的迴歸用例是非常必要的，此時的慢、穩有可能是第一要務。
3.2 在測試執行方面，綜合採用手工測試和自動化測試
手工測試能夠根據測試人員的經驗和直覺發現一些難以預料的問題。例如，在一個針對運營的配置系統中，測試人員通過手工點擊和輸入的方式測試用戶界面的響應和交互。自動化測試能夠提高測試效率和一致性，測試人員採用自動化測試工具，編寫測試用例並進行自動化測試，以保證軟件的核心功能的穩定性和正確性。手工測試適用於需要嚴格細節和需要摻雜較多人爲因素的測試場景，測試人員可以快速上手，外部依賴較少且可以靈活運用各種測試策略，通常手工測試可以發現比自動化測試更多的缺陷。而自動化測試適用於要求大量重複性、穩定性或大量數據的測試場景，就像流水線一樣，快速執行，但是實現自動化測試用例本身需要需要投入大量的時間和精力，並且由於自動化測試的脆弱性，已經開發完成的用例還必須隨着被測對象的改變而不斷更新，你還需要爲此付出維護測試用例的成本。在用戶增長領域的測試中，針對臨時活動類、新項目及前端交互較爲複雜的項目，以手工測試爲主；針對較爲成熟的拉新工具、運營端功能及測試迴歸時，偏重自動化測試，其自動化用例需要不斷積累並持續更新維護。
3.3 在測試用例方面，綜合使用腳本測試和探索式測試
腳本測試通過編寫測試腳本來進行測試，並可以覆蓋大部分常規場景，通過編寫一系列的測試腳本（包括測試代碼、文字描述的測試用例、操作數據庫和緩存的腳本等），用於驗證各個功能模塊的正確性和可靠性。探索式測試充分發揮測試人員的主觀能動性，通過不斷嘗試和探索來尋找應用未知的測試場景，在測試過程中沒有或者較少使用測試腳本。在京小福GO小程序中的有一個合成寶石小遊戲，在測試過程中，測試同學結合合成類遊戲的特點，通過不斷嘗試不同的操作和遊戲路徑，以發現潛在的問題和優化點。腳本測試適用於對已知場景的覆蓋，而探索式測試作爲敏捷測試的重要實踐，適用於對未知場景和新功能的探索，合理使用探索式測試，可以大幅降低測試成本。在我們的用戶增長的質量實踐中，一貫鼓勵大家積極嘗試不同的測試策略和方法，不管是局部探索式測試、全局探索式測試還是混合探索式測試，都有其在不同測試場景不斷探索和實踐的現實意義。
3.4 在測試範圍方面，綜合利用測試左移和測試右移的實踐
測試左移主要目標是把質量活動前置，通過各種缺陷預防工作，有效減少後期的問題修復成本。在用戶增長的質量實踐中，除了在在需求評審主動識別業務流程斷點、異常流程、分支流程、測試數據和測試物料訴求、驗收標準等常規問題之外，我們對測試用例進行了前置，通過測試用例的梳理和評審，給與研發設計和代碼編寫更多的輸入，提前識別業務流程及需求交付過程中的問題，並及時與產品和開發進行溝通。測試右移指對質量的把控延伸到系統上線之後及日常的運營和運維過程中，通過日常的人工巡檢、自動化巡檢、體驗治理等方式，及時發現和用戶體驗問題。總結來說，測試左移和右移只是一個形象的表述，其核心是質量保證不應該僅僅針對測試執行階段，而應該貫穿於研發質量管理的各階段及需求交付的全生命週期。
![]()
3.5 在測試策略方面，綜合應用金字塔、冰淇淋和橄欖型模型等類型的策略
金字塔模型、冰淇淋模型和橄欖型模型是常用的測試策略模型，它們在測試覆蓋和測試優先級方面有不同的側重點。金字塔模型基於測試用例的優先級和數量來劃分測試層級，金字塔的底部是大量的單元測試或單元組件測試，接着是少量的集成測試，再往上是更少量的系統測試和用戶界面測試等。金字塔模型的目標是將更多的測試重點放在低層級的測試中，通過更細粒度的測試覆蓋來發現和解決問題，最大程度地提高測試效率和準確性。冰淇淋模型強調功能性和非功能性測試，並注重用戶體驗，該模型特別適合用戶驅動的測試，如用戶界面測試、用戶驗收測試等。橄欖型模型綜合了金字塔模型和冰淇淋模型的優點，兼顧了測試覆蓋和用戶需求驗證。金字塔模型適用於快速研發的小型項目或服務端邏輯較爲複雜的項目，冰淇淋模型適用於極致強調用戶體驗的項目，而橄欖型模型在中等規模的項目上適用性更高。以上三類測試策略模型只是一些常見的指導方法，應根據具體的項目和測試需求選擇合適的測試策略，有時可能需要使用多個模型的組合。相較於其他業務場景，用戶增長領域主要與C端用戶及業務運營人員直接交互，迭代速度快，用戶體驗要求高，因此，冰淇淋模型被廣泛應用。我們對於所有的需求都會安排上線前的產品驗證及上線後的運營驗收，從需求提出者、產品方案設計者、終端用戶三個角度驗證系統的功能和用戶體驗。
3.6 在測試協同方面，綜合考慮局部最優和全局最優之間的平衡
在測試與其他角色的協同中，不僅考慮測試單元的獨立性和正確性，還要考慮整個需求開發和交付過程的效率和質量。這種綜合考慮有助於優化團隊合作，提高產品的整體質量和交付速度。舉例來說，在敏捷開發團隊中，測試人員與開發人員、產品負責人等角色進行協同。在局部最優的視角下，測試人員可能會只關注檢查局部功能是否符合需求和規範，而忽略其他角色的需求和期望。然而，從全局最優的視角來看，測試人員應該參與需求討論，並與其他角色密切合作，以確保需求的準確性和全面性。這樣可以避免後續開發過程中的變更和延誤，並提高整個團隊的生產力。同樣的道理，交付過程中我們提倡定期評審、按節奏開發、按客觀工作量評估排期、冒煙准入等實踐都是爲了防止在某個階段或某個角色的局部最優卻導致全局低效或低質量。然而在現實的工作中，有時不得不爲了局部最優犧牲掉全局最優，這跟項目所處的階段、組織環境、內外部業務壓力等因素有很大關係。所以，綜合考慮局部最優和全局最優在測試與其他角色的協同中非常重要，因爲這有助於促進團隊的有效溝通和協作，提高整體工作效率和產品質量。通過綜合考慮局部和全局的需求和期望，測試同學可以在開發和交付過程中發揮更大的作用。
綜上所述，在用戶增長質量保證過程中，需根據不同的業務場景、項目要求和組織環境，綜合運用和組合各種質量策略，採用不同的測試方案和測試方法，提高交付質量，減少潛在問題的發生，增強用戶體驗。需要強調的是，在用戶增長質量保證的實踐中，我們並不會僵化地、機械地使用以上策略，而是把它們應用到日常質量工作中，做到潤物細無聲。
質量不在測試階段產生，更不在測試階段結束，質量貫穿整個產品生命週期中的每個環節，包括方案設計、開發、測試、發佈、運營及下線。在敏捷開發模式中，測試人員會盡早開始測試，包括對需求、研發設計及測試用例的及時評審，更重要的是，能夠及時、持續對產品/項目/需求質量進行反饋，可以總結爲下圖：
針對用戶增長產品交付的特點，測試團隊需要做到“又快又好”的完成工作，需要把質量保障和降本增效貫穿到整個需求交付的各個階段，所以我們在每個階段都制定了相應的質量流程標準化的規範。我們把測試活動概括爲“需求分析”、“用例分析和設計”、“測試執行階段”和“線上質量監控階段”這幾個階段，接下來我們詳細講述在每個階段的具體工作方式。如在需求階段，我們制定需求准入的規範，包括需求文檔內容展示、前端頁面交互等內容，避免在開發過程中因需求細節不清晰導致到測試階段再找產品覈對、研發再修改、測試再驗證；在用例設計階段，測試用例評審前置評審，從功能層面可以對產品的需求細節進行補充，從系統實現層面可以根據研發的實現方式列舉出影響的功能點及迴歸測試點，提升用例的有效性；產品發佈時會根據需求特點制定灰度發佈方案；線上運營中進行線上功能定期巡檢及系統整體動態數據的監控。
Dave Hendricksen在他的著作《軟件架構師的12項修煉》中提出：“系統架構師在考慮軟件架構的真正價值時，不能只關注系統構造的技術，更要對客戶價值和商務價值——你能幫助客戶真正解決怎樣的問題、你怎樣幫助公司賺錢——有深刻的認識” 。即便產品使用的是最先進的開發技術，如果不能滿足用戶的痛點、不能解決業務的訴求，這樣的產品就是無用的產品，不能稱爲成功的產品。在項目啓動階段，測試人員的深度參與至關重要，有助於識別業務價值和商業價值，體現在以下幾個方面：
-
洞察業務
：對業務的洞察是質量保證的基礎，通過深入瞭解業務，測試人員可以更好地實施測試策略、創建準確的測試用例，覆蓋重要的業務場景和流程，以確保業務需求在產研交付後的正確性和完整性。可以說沒有對業務領域的深入理解和洞察，質量保證將成爲無源之水、無本之木。
-
理解需求價值
：瞭解需求的目標和價值，同時基於與業務和產品經理的溝通，搞清楚需求背後所代表的業務涵義、所解決的業務上的問題，而不僅僅是需求文檔中的功能說明。
-
理解需求功能
：深刻理解用戶的使用場景，瞭解業務操作流程，以及該需求所對應的功能及在業務流程中的位置。我們的系統通常具有較高的複雜性，可能涉及一個項目中的多個模塊，或者是多個項目、多個部門的功能協作。因此，在串聯流程時，需要通盤考慮。
-
分析用戶體驗
：深入理解產品的體系、架構和交互關係。從業務流程的角度考慮，確保業務流程的合理性、流暢性和完整性，保證用戶在操作過程中沒有疑惑。以用戶視角思考使用場景和操作流程，讓用戶少操作、少思考。
5.2 系統分析：確定待交付功能能夠滿足業務需求
在設計需求驗證點時，需要考慮“看得見的需求”和“看不見的需求”。“看得見的需求”即爲產品經理需求文檔中描述的需要實現的功能是什麼。“看不見的需求”即爲研發同學在代碼實現過程中運用了什麼技術，這些技術可能需要一些測試用例進行驗證。所以，我們需求分析的輸入不僅包括產品需求，還必須考慮代碼的具體實現，在測試開始前深入瞭解研發詳細設計有助於測試人員制定合適的測試策略。在需求交付過程中可以通過以下方式對研發設計做深入的理解：
-
理解研發設計的實現流程，包括系統架構設計、模塊劃分及各模塊的技術和數據交互。如在數據存儲方面，需詳細瞭解不同數據存儲的特點及相應的實現方案，例如關係型數據庫、NoSQL數據庫、Redis、ES等，以便評估其性能和可用性；數據交互層面，深入瞭解系統中的數據交互方式，包括同步和異步的調用方式、數據格式轉換、數據傳輸的加密與壓縮等方面；瞭解系統的各種異常類型和對應的處理方式，包括錯誤碼定義、異常日誌記錄、告警機制和異常回滾處理等，以確保系統的可靠性和可維護性。
-
系統配置方面，包括配置文件的格式、配置項的分類和命名規則、配置的動態更新和預加載機制等，以確保配置的靈活性和可擴展性；調度任務方面包括任務的調度頻率、調度策略、失敗重試機制、作業優先級管理等方面，以保證任務的可靠執行和高效調度。
-
瞭解與外部系統的依賴和交互。在微信域拉新時，大量需求涉及到與企微、小程序的交互，企微主被動加微、消息羣發、社羣運營等需要詳細瞭解微電、用增
活動、小程序與騰訊側系統的交互，如接口定義、協議規範、數據交換格式和數據校驗、回調方式、重試機制等。
-
代碼改動點及調用鏈路梳理。用戶增長項目一直處於快速迭代過程中，項目涉及的功能點及調用關係都較爲複雜。對於研發實現需進一步梳理每個代碼改動點對其他模塊的調用和影響，分析其可能引發的潛在問題，以確保每個改動點、受影響功能點的穩定性。
5.3 測試執行：確保待交付功能與產品的顯性和隱性需求一致
經過以上需求分析和系統分析後，我們可以根據這些輸入來設計測試用例。總結來講，測試用例可以從業務功能分析、系統實現分析及系統實現的改動點帶來的影響範圍劃定等三方面進行設計，在測試用例評審完畢之後，就是測試執行了。有效的測試執行能夠確保軟件功能的正確性、提高軟件質量，以及減少軟件維護成本，測試過程中的結果和問題反饋能夠幫助開發團隊及時修復問題並改進軟件開發的過程，從而提高整體的交付質量和開發效率，因此，測試執行是確保產品質量的關鍵環節。
測試執行階段除了測試人員本身的質量活動和行爲之外，也是與業務/運營、產品、研發等溝通最爲頻繁的階段，因此 合理規範的測試流程約束和質量問題快速歸因是高質量交付的保障。將測試過程劃分成多個節點並共享，能夠使職責劃分明確，有利於相關人員分析質量卡點原因及進度把控。在測試階段需完成功能測試、非功能測試兩部分，其中功能測試是產品質量顯性的驗證，非功能測試是產品質量的深層次的檢驗。
-
功能測試：功能測試的目標是驗證軟件系統是否實現產品需求文檔中定義的功能要求，進行功能測試的步驟一般爲：設計測試用例、準備測試環境、執行測試用例、驗證測試結果、缺陷跟蹤和復現、缺陷修復和迴歸測試、發送測試報告和總結等，其中爲適應敏捷交付的要求，堅持測試左移原則將部分測試步驟前置，如測試用例設計&評審在編碼之前完成，測試環境搭建以及物料準備在研發提測前完成。堅持測試左移的原則可以在敏捷開發過程中幫助整個團隊更早地發現問題，減少後期修復的成本和風險，同時通過前置測試步驟，可以促進測試與開發的緊密協作，提高需求交付的質量和效率。
-
非功能測試
：經過功能測試的驗證已經實現了業務需求功能部分的檢驗，但質量的檢測只完成了第一階段，第二階段是軟件性能以及潛在風險點驗證，確保需求交付後萬無一失。非功能測試主要測試帶
交付需求的可靠性、可用性、性能、安全性、兼容性等方面。非功能測試通常需要使用專門的測試工具和技術，設計合適的測試場景和測試條件進行測試驗證，比如每年兩次的大促壓測，都是利用Forcebot、泰坦等壓測工具進行性能測試。
此外，有些工作不太好區分是功能測試還是非功能測試，但也是非常重要的質量保證工作，比如關於埋點和數據準確性的驗證。主要工作包括：
在需求階段推動埋點需求評審，識別埋點設計方案的合理性，推動埋點需求質量提升。
包括埋點測試策略設計、手工埋點驗證、自動化埋點驗證等工作。
通過數測平臺校驗數倉數據與應用層數據的一致性和準確性，提升比對範圍和效率；從用戶使用視角提出分析平臺優化建議，提升數據應用平臺用戶體驗。
5.4 上線發佈：執行上線前check與上線後灰度發佈
當需求開發階段接近尾聲時，團隊的工作也進入到了關鍵的上線發佈階段。爲保障已完成質量檢測的產品功能正常上線，在需求上線之前。用戶增長質量團隊協同其他各個角色通常需要在上線階段做以下工作：
-
產品驗收測試
：測試團隊在業務驗收測試過程中，會模擬真實業務場景，在測試環境或預發環境中，測試待交付功能在不同業務流程中的運行情況，並與產品經理、業務方對比驗證，確保軟件的功能能夠正常運行。
-
上線前Checklist執行
：我們梳理了從需求評審到上線驗證過程中各個階段檢查點和關注點，有些是可選動作，有些是必選動作，避免在交付過程中有所遺漏或沒有前置溝通而導致返工或線上問題。Checklist檢查項按角色進行區分，分爲運營檢查點、產品檢查點、研發檢查點和測試檢查點等四個部分。其中研發檢查點主要包括代碼合併情況、編譯打包是否完成、數據庫升級是否成功等。測試檢查點主要包括測試環境是否搭建完備、測試用例是否執行完整、bug修復情況等。測試團隊需要仔細對照這個Checklist，確保每個檢查點都已經完成，以確保軟件上線前的穩定性和可靠性。
-
封版時間把控
：在封版時間之後，除了線上bug，開發團隊將不再接受新的功能需求和修改請求。測試團隊需要把控好封版時間點，並確保在封版之前，所有的測試工作都已經完成。封版時間的把控對於軟件的上線進程非常重要，它能夠保證軟件的穩定性和質量，在上線之後降低問題和風險。目前在微電C端相關的項目，執行上線當天12點前封板，晚上18點開始上線的約定。
-
版本灰度發佈
：在需求上線之前，通常會先進行版本灰度發佈，即將新功能逐步投放給一部分用戶使用，以驗證軟件在真實環境中的穩定性和可靠性。測試團隊參與溝通灰度發佈計劃，協同產品和運營確定灰度的人羣、灰度比例、切量計劃及應急預案，並收集用戶的反饋和問題報告。
總體來說，在需求的上線階段，用增測試團隊需要業務&產品驗收測試、上線前Checklist執行和封板時間把控、版本灰度發佈等一系列的工作。這些工作的完成能夠確保軟件在上線之後能夠穩定運行，並滿足用戶的需求。測試團隊需要與運營、產品及研發團隊緊密合作，保證各項工作的順利進行，確保高質量、按時交付。
5.5 投產運營：收集用戶反饋並沉澱經驗教訓
需求上線之後，用增質量團隊仍需協同各方進行一系列的質量保證工作，主要包括：
-
監控和收集反饋：監控軟件的運行情況，及時瞭解是否存在異常或客訴，確保線上問題可以在第一時間修復。質量團隊還需要主動收集用戶反饋，爲業務規劃和產品優化方案提供更多輸入，不斷改進用戶體驗。
-
Bug跟蹤和修復
：部分缺陷因時間問題可能需要留待上線之後逐步修復，質量團隊協同業務和產品，評估問題的優先級和嚴重程度，並協調開發團隊及時修復。
-
性能監測和優化
：質量團隊需要持續進行性能監測，包括對軟件的響應時間、併發處理能力和資源佔用情況等方面進行評估。如果發現性能問題，需要與開發團隊合作，優化性能和用戶體驗。
-
自動化測試和持續集成
：上線後，質量團隊可以進一步推進自動化線上測試和持續集成的工作。通過自動化巡檢，及時發現線上問題並第一時間通知到項目團隊，同時持續集成可以幫助測試團隊更快地修復問題。
-
產品功能文檔沉澱
：上線後，質量團隊通過結合整個測試流程所遇到的問題和困難進行梳理，將業務理解、測試策略、測試方法、經驗教訓等整理成文字，一方面有助於自我總結和反思，另一方面有助於分享給其他同學，做到共同提升。
總之，質量流程標準化對於保證產品和需求質量有着重要作用，它確保產品能夠符合客戶和業務方的期望，並且提供可靠的性能和持久的價值，通過標準化的質量流程，能夠迅速拉齊團隊內部不同職級、不同能力的測試同學的質量保證工作，確保每一步都經過仔細的審查、測試及驗證，以最大程度地減少缺陷逃逸到線上的機率，同時，通過不斷總結沉澱，不斷優化完善質量流程。
所謂質量活動，是指爲確產品或服務的質量而進行的一系列活動和過程，旨在預防和檢測潛在的質量問題，並採取相應的措施來糾正和改進。用戶增長的運營需要不斷嘗試不同的用戶增長策略，並根據用戶反饋及數據反饋快速調整，同時能夠快速跟進市場熱點，快速迭代產品功能。爲了在滿足快速交付的同時不以犧牲產品質量爲代價，我們制定了用增質量門禁體系，通過規範化的質量活動對需求交付的各個階段進行質量准入和準出，即所謂的七道防線。
6.1 第一道防線：測試前置
TDD（Test-Driven Development）是敏捷測試的重要實踐，它強調在編寫代碼之前先編寫測試代碼，以此驅動代碼質量的提升以及功能的覆蓋。結合當前平臺研發部質量保證的現狀，測試用例絕大部分都是利用XMind編寫的文字描述形式的，若完全按照典型的TDD實踐進行落地，編寫測試代碼的成本較高，短時間內難以看到效果，因此我們第一階段優先實現了測試用例的前置，即測試用例的編寫和評審前置到設計評審或代碼開發之前，通過測試用例進一步明確功能需求、性能要求、異常流程、數據需求及驗收標準，並彌補需求評審環節可能遺漏的功能點和流程有欠缺的地方，提前預防缺陷，減少了在後期測試階段的返工和修復成本。通過在用戶增長、微電等領域多個項目的試點，各方均給與了正向的反饋，目前正在擴大試點範圍，目標是80%的需求實現用例前置。
6.2 第二道防線：單元測試
單元測試是對軟件中的最小可測試單元（即代碼中的函數、方法、類等）進行獨立的測試。它的主要目的是驗證每個單元是否按照預期正確工作。單元測試具有以下幾個好處：
-
提高代碼質量
：通過編寫單元測試，開發人員可以驗證每個單元的行爲是否符合預期，這可以幫助發現潛在的錯誤、邊界情況和異常行爲。
-
確保模塊間的獨立性
：單元測試要求每個單元都能夠獨立地進行測試，有助於構建更加靈活、可擴展和可維護的代碼。
-
支持重構和代碼重用
：可以幫助開發人員驗證重構後的代碼是否仍然能夠正確工作，確保重用的組件在新環境中的行爲符合預期。
-
減少調試時間
：單元測試可以快速發現問題所在，縮小調試的範圍，加快問題排查的速度。
-
建立信心和提供文檔
：通過編寫全面的單元測試，開發人員可以建立對代碼行爲的信心，並且在代碼發生變更時，可以快速運行測試來驗證代碼是否仍然正常工作。
總之，單元測試是一種有效的軟件測試手段，它由開發人員編碼實現並執行，充分體現了全民質量保證的理念。在用戶增長的項目中，研發較爲看中單元測試，在編碼的同時寫了大量的單測代碼，尤其是用戶增長研發團隊接入了ChatGPT，並聯合集團其他部以JoyCoder聯合項目組的形式，不斷迭代優化，目前已經可以快速自動生成較爲規範的單元測試代碼，可以大大降低單元測試的工作量。
6.3 第三道防線：冒煙測試
冒煙測試在產品質量保障中起到了早期篩選問題、初步評估產品質量的作用，是確保產品質量的重要一環。合格的冒煙測試能夠快速篩選問題、幫助團隊優化資源和工作分配，並實現對產品質量的初步評估，能夠促進團隊交付效率的提升。在用戶增長質量保證的實踐中，我們一般通過行一組關鍵功能和核心流程的基本測試用例來驗證系統在最初階段是否適合進行更深入的測試，一般採用冒煙演示的方式，研發認爲具備提測的條件之後，邀請測試同學一起現場進行冒煙用例的演示和走查。在我們的實踐中，一般會把總用例中30%左右的用例標記爲爲冒煙用例，一般都是主流程、核心功能的驗證點。不同的需求冒煙用例的比例可能差別較大，與需求的難易程度、涉及核心主流程的多少等有關係，一般情況下，研發和測試很容易就冒煙用例的內容和比例達成共識。
6.4 第四道防線：測試執行
在用增產品交付流程中，測試的執行是產品質量保障的第四道防線，也是確保軟件質量的最關鍵步驟之一。通過有效的測試執行，能夠將產品缺陷儘早發現，缺陷的類型包括且不限於：功能問題、用戶體驗問題、性能問題、安全漏洞、埋點規範、兼容性、風控防刷等等。測試執行階段是測試同學工作時長最長的階段，也是其他角色最爲熟悉的測試工作內容。通常在該階段發現的需求缺陷能達到95%以上，一般情況下，在測試執行階段的工作量佔比總體研發工作的30%~50%，當然，不同的需求，測試工作量佔比可能差別較大，尤其是迴歸測試的比例，以及自動化測試在迴歸測試中的佔比，都直接影響測試執行階段的工作量和時長。
6.5 第五道防線：產品驗證
產品驗證是確保軟件質量的第五道防線，包括UAT、UI走查以及體驗驗收三部分。在需求準備上線之前，我們會邀請產品經理在預發環境或測試環境對待交付功能進行驗證，此時，測試人員和產品經理一同參與對產品的系統驗證，測試同學進行主流程演示或者產品經理自主驗證功能、性能和用戶體驗是否滿足最初的需求和預期，同時驗證運營配置是否有問題。產品驗證的結果分爲兩種情況：通過和不通過。對於通過的情況，我們可以開始進行最終的發佈和交付工作。對於不通過的情況，我們第一時間反饋給開發團隊，以便及時修復和優化問題。在產品驗收階段，基於產品設計和用戶視角，產品經理可以提出各種觀點和意見，從而進一步完善產品。這種多元化的反饋和意見可以幫助團隊在上線前識別和解決潛在問題，雖然此時已經處於需求交付的後期，但因系統還未面客，仍有一定的時間修復問題，這樣可以儘量避免問題逃逸到線上產生客訴。
另外，若涉及較多前端交互的需求，在產品驗證完需要邀請UI設計師進行UI走查以及用戶體驗同事進行體驗驗收。作爲上線前用戶操作、用戶體驗方面的驗收，若因體驗存在缺陷導致驗收不通過，用戶體驗同事有權決定推遲上線，直至完成了優化，或者各方就體驗問題達成了共識，可以先上線，並在大範圍投放之前完成優化。
6.6 第六道防線：運營驗收
運營驗收主要是在需求上線後，邀請運營同學在線上進行最終的驗收，運營同學站在業務及用戶視角，驗證待交付功能是否與最初的預期一致，運營驗收階段是功能面客前的最後一道防線，基於對用戶的深刻洞察、敏銳的直覺以及對市場上同類功能的深入研究，運營同學在該階段經常能發現一些大家容易忽略的問題或缺陷。同時，更重要的是，可以驗證後臺配置是否有問題、預算是否充足，並決定新舊功能的分流比例、缺陷是否在容忍範圍內、是否需要報備客服，並確定投放後的運營策略、運營節奏及後續的產品迭代規劃。在該階段，偶爾會發生運營意見與產品意見、研發測試意見不一致的情況，因此，該階段也是一個互相說服、拉齊認知的重要階段。
6.7 第七道防線：容災演練
隨着業務發展、微服務架構、分佈式架構和虛擬化容器技術的廣泛普及，軟件架構的複雜度在不斷提升，服務之間的依賴所帶來的不確定性也呈指數級增長，在這樣的服務調用網中，任何一環出現的正常或者異常的變化，都有可能對其他服務造成類似蝴蝶效應一般的影響。隨着用戶增長線上營銷活動、拉新工具、公共組件的不斷增加，整體鏈路增長以及數據流轉複雜，對整個系統的可用性、穩定性挑戰也越來越大，所以非常有必要主動找出系統中的脆弱環節，然後針對性地進行加固、防範，從而避免故障發生時所帶來的嚴重後果，進一步提升業務系統的高可用，提高業務系統應急保障能力。近幾年，國內外已經發生了數次大規模的故障導致對海量用戶的服務長時間中斷，產生了巨大的負面影響。爲有效減少因內外部環境的故障對系統造成的影響，我們在日常工作中模擬各類故障，以檢驗對系統的影響及研測團隊的風險應對能力，我們在用戶增長領域進行了兩類容災演練：
-
一種是應用層面的混沌演練（Chaos Engineering）
混沌演練是一種通過有意引入系統隨機性、不穩定性和故障來測試和改進系統可靠性的實踐方法，它旨在幫助組織識別和解決潛在的系統缺陷和性能問題，以減少系統故障和提高系統的容錯性。混沌演練的關鍵理念是“通過引入故障來發現故障”。通過有節制地引入不穩定因素和故障場景，例如關閉某個服務、模擬網絡延遲、引發硬件故障等，混沌演練可以驗證系統的彈性、容錯能力和恢復能力。它能夠幫助我們發現隱藏的系統弱點，識別性能瓶頸和獨立失敗點，並提供改進系統穩定性和可靠性的機會。
-
第二種是數據存儲的高可用以及機房網絡的斷網容災演練
演練的場景包括運營商網絡斷網、京東雲機房斷網、存儲設備斷網、網絡流量抖動、網絡流量丟包等，影響範圍可能更廣，因此需要提前梳理好演練內容和應急方案，具體包括根據不同場景梳理演練SOP、根據SOP設置演練模板、根據模板評估系統是否達到演練要求、根據演練要求升級改造系統、根據演練模板設計演練流程及checklist，確保不會因演練而影響線上系統。通過對演練過程、演練內容、風險事項、應對方案的梳理，做到萬一發生類似基礎性故障或網絡、數據庫切換的時候，有序執行SOP操作，系統處於風險可控的狀態。截止目前，已經完成了針對用戶增長領域掛獎、發獎、資金組件等三個核心應用的數據庫、緩存切換演練，達到了預期效果。
該章節介紹了用戶增長領域在快速交付產品的同時爲保證交付質量所設置的七道防線，每道防線都像一道門禁，只有滿足了准入要求，才能進入下一個階段，以此來規範各個階段的質量活動，並作爲質量保證全流程的執行標準。需要指出的是，在實際的質量實踐中，不是形而上的、簡單粗暴的執行以上質量活動，我們會根據產品和業務需求的實際情況進行一定範圍的靈活調整或裁剪，在質量和效率之間達到一個動態的、適度的平衡。
根據第一章的描述，在用戶增長質量保證過程中，在交付質量和效率方面存在着諸多的挑戰，這些挑戰不能單純依靠質量策略、方法、流程規範及無休止地加班解決，質量工具在此過程中發揮着重要的作用。質量工具的種類繁多，包括自動化測試工具、性能測試工具、安全測試工具、數據構造工具等等。我們對測試團隊常用的測試工具進行了梳理，發現測試過程中使用了大量的內外部工具。以下是較爲常用的工具：
以上這些工具都是各自獨立的，大部分是爲了解決質量保證過程中的單點問題，而我們一直所倡導的是敏捷DevOps理念，它強調各個團隊各個角色之間的無縫協作、持續交付和自動化，在需求交付過程中追求更快的交付速度、更高的質量和更好的用戶體驗。在我們的實踐中，一般利用基於行雲底座的需求管理、流水線、缺陷管理、分支管理、發佈工具、質量看板、流水線等作爲基礎性質量工具。於此同時，基於我們質量部的特點及多年來的沉澱，利用自研靜篤平臺實現了質量流程管理的線上化，並接入了行雲，實現了與行雲需求管理模塊、缺陷管理模塊的打通，包含質量流程管理、接口/UI自動化、H5性能檢測，指定場景流量回放，大促性能測試工作臺等主要功能模塊，在靜篤平臺內我們可以通過“基礎數據配置”添加業務系統、數據庫信息和接口信息等，通過“數據工廠”幫助測試同學智能造數，通過“自動化測試”實現線上巡檢接口和UI頁面的正確性，通過“自動化任務”定時迴歸測試流程，輸出詳細的測試報告，還能通過“智能助手”幫助解決測試同學知識庫對齊等問題。通過行雲、靜篤等平臺化工具，實現了質量保證全流程的線上化和數字化，降低了協作成本，爲高質量交付提供了基礎性保障。
質量運營聚焦於質量的全方位控制和持續改善，將質量流程、規範、制度、標準、模板、最佳實踐和質量意識貫穿於整個部門、各個角色及需求交付的全生命週期。通過質量治理、質量度量、質量文化建設及推動持續改進等舉措，使質量理念深入人心，質量活動落實到位，並通過各個角色的協同配合，確保交付質量穩定在合理的水平和空間，這一系列舉措成爲質量保證過程中的常規工作。質量運營不僅僅是單一的職能部門或個別員工的責任，而是整個組織的共同責任，通過質量運營可以幫我們實現持續的質量改進和優化。常態化的質量運營包括以下幾個方面：
8.1 質量治理
通過建立一系列的機制、流程和標準，以保證產品質量符合規範和業務期望 ，保證交付質量和效率，主要包括以下幾個內容：
8.1.1 技術質量治理
通過嚴格把控冒煙質量、測試用例前置、完備的研發設計文檔、規範的代碼評審以及提升測試用例評審質量、缺陷定期review、補充自動化巡檢用例等方式，提升提測質量及線上穩定性。
8.1.2 數據質量管理
針對埋點不規範、取數難等痛點，聯合奇點產研、量化分析師等團隊在市場與平臺運營中心內對埋點問題進行了專項治理。主要包括埋點規範升級、埋點上報平臺改造、高代碼埋點流程試點、埋點平臺能力完善等幾個方面。來保障埋點採集數據落入數倉的準確性，推動業務數據在分析洞察平臺展示的及時性和準確性，降低非數據分析師角色使用的門檻。
8.1.3 用戶體驗治理
用戶體驗在用戶增長的產品和服務開發中至關重要，通過關注用戶的需求、提供易用的界面、設計優雅的交互和提供愉悅的使用體驗，可以增強用戶滿意度、競爭優勢和品牌形象，從而實現用戶價值的最大化和獲取新用戶效率的提升。針對用戶體驗問題，主要從以下幾個層面推進體驗治理。
-
體驗問題分類：將體驗問題細分爲不同類別，如活動類體驗、拉新工具體驗、運營體驗、大促體驗等。這樣可以更有針對性地進行問題分析和解決。
-
建立體驗專項：針對每個體驗問題的類別，建立相應的體驗專項團隊或小組，協同各個角色推動監測、分析和優化解決相關的體驗問題，從而提高問題治理的效率和質量。
篩選重點項目的用戶進線問題，對問題進行歸類、分析，以及給出優化建議，例如改進產品功能、優化界面設計、增強用戶引導等。
-
需求評審和測試用例評審：在評審階段，邀請客服部門體驗BP和用研同學參加需求評審和測試用例評審，對用戶體驗問題進行把控，對於有爭議的體驗問題進行裁決。
-
前端測試准入、驗收規範：針對前端樣式不統一、規範不統一等問題，建立前端測試准入和驗收的標準，對按鈕、輸入框、下拉框、表單、菜單等前端組件的樣式、功能進行統一規範，作爲前端提測准入測試階段的標準之一。
-
檢測與監控指標統一：建立一套完整的性能體驗指標體系，統一收集和監控關鍵指標，如加載時間、響應速度、頁面穩定性等，以及時發現體驗問題並進行有針對性的優化。
-
端內H5性能檢測工具：引入端內H5性能檢測工具，對H5頁面的性能進行監測和分析。通過定期檢測，可以發現並修復潛在的性能問題，提升用戶的訪問體驗
-
生產性能定時
巡檢工具：使用定時巡檢工具對生產環境的性能進行監測，及時發現並解決系統的性能瓶頸和問題，這樣可以保證系統的穩定性和良好的用戶體驗。
-
在重大項目上線前預留一定的時間進行缺陷掃除活動，項目組成員全面檢查系統中可能存在的體驗問題和缺陷，並及時修復。通過這種缺陷大掃除活動，可以把絕大部分功能缺陷和體驗問題消滅在功能面客
之前。
通過以上舉措，可以更加全面地治理產品體驗問題，提高產品的質量和用戶滿意度。另一方面，用戶體驗是偏主觀的，不同的角色從不同的角度可能對同一個體驗問題有着不同的結論；同時，用戶體驗也是動態的，在不同的環境下、不同的階段對同一個體驗問題的看法也會不同；第三，體驗問題需要與業務發展保持一定的動態平衡，有時可能不得不做暫時的妥協和犧牲，但妥協和犧牲一定不能突破體驗的底線。因此，用戶體驗與業務發展相伴相生，作爲質量保證的角色，在用戶體驗治理的過程中發揮着至關重要的作用。
8.1.4 質量流程治理
協同PMO、產研，加強質量內建，提升過程質量，主要包括：
通過流程規範及定期覆盤，引導產品提升需求質量，避免一句話需求、口頭需求，以及需求未充分思考便匆忙評審。
按節奏評審和上線，提升交付的節奏感，儘量減少對測試、研發的打擾；研發側避免未經過評審或提前通知測試而私自接受業務或產品的需求等等。
一線開發的代碼質量差異較大，需通過質量度量分析推動研發提升代碼質量，提升開發過程的規範度，如儘早代碼評審、加強自測和單測等。
定期覆盤需求交付過程中的問題，共識改進方向及改進的進度。
8.2 質量度量
通過質量度量體系的建立，制定具體的質量指標和目標，並通過指標衡量結果和改進方向。以平臺研發部爲例，我們選擇了4大類共6個指標作爲質量度量的核心指標。
-
需求平均缺陷數/研發月人均缺陷數：用來衡量體現在每個需求上的以及每個開發人員的缺陷密度。
-
缺陷關閉時長/缺陷關閉率：即研發和測試在缺陷修復和驗證上花費的時間、時間佔比，用以度量解決缺陷的速度和效率。
-
部署回滾率：用以度量項目團隊對系統可靠性和穩定性的把控程度。
-
線上事故數：用以度量生產環境下各個級別線上事故/問題的數量。
通過對這些指標的同環比分析、趨勢分析以及與行業的對比分析，反饋出提測質量以及線上質量等問題，有利於各個部門發現問題並及時調整，保證持續的高質量交付。
8.3 質量文化建設
質量文化建設的意義在於創建和培育一個團隊內部注重質量的價值觀和行爲準則，增強團隊成員在質量方面的參與感和責任感，促進持續質量改進。在質量文化建設過程中，重點是全員參與。在內部，爲了對系統功能進行查缺補漏，並提升用戶體驗度及推動探索式測試理念和思維方式落地，我們開展了“Bug Bash缺陷大掃除“活動。由於報名的團隊和業務線比較多，採取了以業務線爲單位兩兩結對的方式，結對小組內部進行業務串講和評分，每組控制人數四至六人。最終共提報233個Bug，並評選出最能”找茬“的參賽團隊。
-
用戶體驗標準不統一，不同人對於缺陷的認知和認定不一致，導致部分缺陷的認定存在爭議。
-
-
測試環境與預發和線上環境存在較多功能、體驗不一致的地方。
“Bug Bash 缺陷大掃除”結束之後，針對發現的缺陷，已安排測試同學專題跟進並反饋解決進展。除此以外，還圍繞測試用例設計舉辦了“尋找最美測試大師——最美TestCase競技場”的活動。各團隊圍繞近期迭代的較爲複雜的產品功能，撰寫測試用例，並提交至評審處。各評委除依據嚴格的評審標準外，還結合場外觀衆的下注投票進行參考。隨着“最美測試大師”懸念的揭曉，各測試團隊也基於賽程的歷練，實現了自身能力的精進。
在質量治理過程中，我們完善BUG等級和事件提報制度。根據缺陷問題的嚴重程度主要分爲5個等級，即P0、P1、P2、P3、P4，其中P0最嚴重，P4最輕。針對日常出現的線上問題，要求各業務線及時反饋並統一記錄至event事件系統，針對P0、P1、P2的問題組織覆盤會並向上提報。各業務線還需內部覆盤，發掘線上問題出現的原因並總結出改進措施並推動落實。
8.5 總結、沉澱與分享
測試同學既要不斷提升測試專業能力，也要不斷加深對業務的理解，同時還需瞭解一定的開發技術。專業能力、業務知識及開發技術的增長需要通過不斷地學習、總結沉澱與分享來實現。我們團隊定期組織集體學習和專題分享，每次分享需要有影像資料留存，並將分享的內容同步產出文章，方便後續其他同事隨時學習回顧。除此之外，由於項目和需求非常多，各個測試同學之間經常需要穿插支持，除了正常的AB崗之外，還需要對其他的項目有所瞭解。因此，大家共同梳理並持續維護用戶增長測試白皮書，按照項目維度梳理測試相關的內容，包括測試方案、測試用例、迴歸策略、測試數據、經驗教訓等，對部分項目的測試策略和測試方法、數據構造進行深度挖掘，沉澱了數個專利。除此之外，我們定期舉辦測試串講活動，測試同學基於對系統、業務、用戶及技術架構的理解，以自己的語言把業務和系統串聯起來，並對產品和研發同學宣講，同時拋出問題，產研測一起分析並探討解決方案，通過測試串講，測試同學不僅加深了對業務和系統的理解，對產品方案和技術架構的優化改進也提供了很多的輸入，可謂一舉多得。
綜上所述，質量運營對於增強團隊質量意識和落地質量流程規範有重要意義。在我們的工作實踐中，我們一般安排兩名JDS兼任質量運營的職責，一般需要分配10%~20%的時間精力做以上質量運營相關的工作。
本文旨在總結用戶增長質量保證方法論，通過“高質量=質量策略多樣化+質量流程標準化+質量活動規範化+質量工具平臺化+質量運營常態化”質量方法論公式，把部門的質量意識、思維、行爲和目標拉齊，爲部門的質量保證同學提供指導。同時詳細闡述了用戶增長質量保證價值觀及方法論的內涵。首先，質量策略多樣化強調根據不同業務需求和產品特點制定相應的質量策略，確保滿。其次，質量流程標準化旨在建立一套統一的質量管理流程，提高工作效率和質量。第三，質量活動規範化強調對質量保證活動進行全面規劃和管理，通過七道質量門禁對研發活動進行准入和準出。第四，質量工具平臺化主張利用先進的質量管理工具和平臺，提高質量管理水平和效率。最後，質量運營常態化強調將質量管理融入日常工作中，實現全員參與和質量持續改進。
未來，用戶增長質量團隊質量保證發展的方向主要有以下幾點。首先，隨着以ChatGPT爲基礎的AIGC技術的不斷髮展，我們正在探索AIGC在質量保證全流程的應用和落地，包括但不限於業務知識普及、測試策略設計、測試用例設計、測試代碼生成、測試數據構造等方面。其次，以用戶爲中心的質量管理正在爲主流趨勢，我們需要更加註重用戶體驗和反饋，將用戶需求和期望作爲質量管理的重要參考依據，不斷優化產品和服務。最後，敏捷質量管理將進一步推廣落地，通過採用敏捷開發模式和敏捷測試模式，我們可以更快地響應用戶增長的業務需求和用戶反饋，實現快速迭代和持續改進。
本文分享自微信公衆號 - 京東雲開發者（JDT_Developers）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
