前言

隨著網際網路紅利的逐漸消失，網際網路公司獲取新客戶的難度和成本越來越高，使用者增長的運營同學需要不斷嘗試不同的拉新策略，並根據使用者反饋及資料反饋快速調整，同時能夠快速跟進市場熱點，快速迭代產品功能。我們所在部門承接大量的金融業務（金白條、支付、小金庫、基金等）拉新獲客的訴求。為了在滿足快速交付業務需求不以犧牲產品質量為代價，我們制定了使用者增長質量門禁體系，通過規範化的質量活動對需求交付的各個階段進行質量准入和準出，步步為營，形成使用者增長產品需求交付質量保證「七重門」。

一重門：用例前置-未雨綢繆，把缺陷消滅在萌芽階段

TDD（Test-Driven Development）是敏捷測試的重要實踐，它強調在編寫程式碼之前先編寫測試程式碼，以此驅動程式碼質量的提升以及功能的覆蓋。結合當前平臺研發部質量保證的現狀，測試用例絕大部分都是利用XMind編寫的文字描述形式的，若完全按照典型的TDD實踐進行落地，編寫測試程式碼的成本較高，短時間內難以看到效果，因此我們第一階段優先實現了測試用例的前置，即測試用例的編寫和評審前置到設計評審或程式碼開發之前，通過測試用例進一步明確功能需求、效能要求、異常流程、資料需求及驗收標準，並彌補需求評審環節可能遺漏的功能點和流程有欠缺的地方，提前預防缺陷，減少了在後期測試階段的返工和修復成本。通過在使用者增長、微電等領域多個專案的試點，各方均給與了正向的反饋，目前正在擴大試點範圍，目標是80%的需求實現用例前置。

二重門：單元測試-分而治之，確保每個最小功能單元的正確性

單元測試是對軟體中的最小可測試單元（即程式碼中的函數、方法、類等）進行獨立的測試。它的主要目的是驗證每個單元是否按照預期正確工作。單元測試具有以下幾個好處：

• 提高程式碼質量：通過編寫單元測試，開發人員可以驗證每個單元的行為是否符合預期，這可以幫助發現潛在的錯誤、邊界情況和異常行為。
• 確保模組間的獨立性：單元測試要求每個單元都能夠獨立地進行測試，有助於構建更加靈活、可延伸和可維護的程式碼。
• 支援重構和程式碼重用：可以幫助開發人員驗證重構後的程式碼是否仍然能夠正確工作，確保重用的元件在新環境中的行為符合預期。
• 減少偵錯時間：單元測試可以快速發現問題所在，縮小偵錯的範圍，加快問題排查的速度。
• 建立信心和提供檔案：通過編寫全面的單元測試，開發人員可以建立對程式碼行為的信心，並且在程式碼發生變更時，可以快速執行測試來驗證程式碼是否仍然正常工作。

總之，單元測試是一種有效的軟體測試手段，它由開發人員編碼實現並執行，充分體現了全民質量保證的理念。在使用者增長的專案中，研發較為看中單元測試，在編碼的同時寫了大量的單測程式碼，尤其是使用者增長研發團隊接入了ChatGPT，並聯合集團其他部以JoyCoder聯合專案組的形式，不斷迭代優化，目前已經可以快速自動生成較為規範的單元測試程式碼，可以大大降低單元測試的工作量。

三重門：冒煙演示-嚴格把關，確保基本功能正常

冒煙測試在產品質量保障中起到了早期篩選問題、初步評估待交付需求質量的作用。合格的冒煙測試能夠快速篩選問題、幫助團隊優化資源和工作分配，並實現對產品質量的初步評估，能夠促進團隊交付效率的提升。在使用者增長質量保證的實踐中，我們一般通過行一組關鍵功能和核心流程的基本測試用例來驗證系統在最初階段是否適合進行更深入的測試，一般採用冒煙演示的方式，研發認為具備提測的條件之後，邀請測試同學一起現場進行冒煙用例的演示和走查。在我們的實踐中，一般會把總用例中30%左右的用例標記為為冒煙用例，一般都是主流程、核心功能的驗證點。不同的需求冒煙用例的比例可能差別較大，與需求的難易程度、涉及核心主流程的多少等有關係，一般情況下，研發和測試很容易就冒煙用例的內容和比例達成共識。

四重門：測試執行-明察秋毫，將缺陷一一捕獲

在產品、專案和需求交付流程中，測試的執行是產品質量保障的第四道防線，也是確保軟體質量的最關鍵步驟之一。通過有效的測試執行，能夠將產品缺陷儘早發現，缺陷的型別包括且不限於：功能問題、使用者體驗問題、效能問題、安全漏洞、埋點規範、相容性、風控防刷等等。測試執行階段是測試同學工作時長最長的階段，也是其他角色最為熟悉的測試工作內容。通常在該階段發現的需求缺陷能達到95%以上，一般情況下，在測試執行階段的工作量佔比總體研發工作的30%~50%，當然，不同的需求，測試工作量佔比可能差別較大，尤其是迴歸測試的比例，以及自動化測試在迴歸測試中的佔比，都直接影響測試執行階段的工作量和時長。

五重門：產品驗證-精益求精，功能、效能、體驗一個不能少

產品驗證是確保軟體質量的第五道防線，包括UAT、UI走查以及體驗驗收三部分。在需求準備上線之前，我們會邀請產品經理在預發環境或測試環境對待交付功能進行驗證，此時，測試人員和產品經理一同參與對產品的系統驗證，測試同學進行主流程演示或者產品經理自主驗證功能、效能和使用者體驗是否滿足最初的需求和預期，同時驗證運營設定是否有問題。產品驗證的結果分為兩種情況：通過和不通過。對於通過的情況，我們可以開始進行最終的釋出和交付工作。對於不通過的情況，我們第一時間反饋給開發團隊，以便及時修復和優化問題。在產品驗收階段，基於產品設計和使用者視角，產品經理可以提出各種觀點和意見，從而進一步完善產品。這種多元化的反饋和意見可以幫助團隊在上線前識別和解決潛在問題，雖然此時已經處於需求交付的後期，但因系統還未面客，仍有一定的時間修復問題，這樣可以儘量避免問題逃逸到線上產生客訴。

另外，若涉及較多前端互動的需求，在產品驗證完需要邀請UI設計師進行UI走查以及使用者體驗同事進行體驗驗收。作為上線前使用者操作、使用者體驗方面的驗收，若因體驗存在缺陷導致驗收不通過，使用者體驗同事有權決定推遲上線，直至完成了優化，或者各方就體驗問題達成了共識，可以先上線，並在大範圍投放之前完成優化。

六重門：運營驗收-結果導向，以使用者和運營雙視角審視待投放功能

運營驗收主要是在需求上線後，邀請運營同學線上上進行最終的驗收，運營同學站在業務及使用者視角，驗證待交付功能是否與最初的預期一致，運營驗收階段是功能面客前的最後一道防線，基於對使用者的深刻洞察、敏銳的直覺以及對市場上同類功能的深入研究，運營同學在該階段經常能發現一些大家容易忽略的問題或缺陷。同時，更重要的是，可以驗證後臺設定是否有問題、預算是否充足，並決定新舊功能的分流比例、缺陷是否在容忍範圍內、是否需要報備客服，並確定投放後的運營策略、運營節奏及後續的產品迭代規劃。在該階段，偶爾會發生運營意見與產品意見、研發測試意見不一致的情況，因此，該階段也是一個互相說服、拉齊認知的重要階段。

七重門：容災演練-防患未然，極端情況下仍能保持業務連續性

隨著業務發展、微服務架構、分散式架構和虛擬化容器技術的廣泛普及，軟體架構的複雜度在不斷提升，服務之間的依賴所帶來的不確定性也成指數級增長，在這樣的服務呼叫網中，任何一環出現的正常或者異常的變化，都有可能對其他服務造成類似蝴蝶效應一般的影響。隨著使用者增長線上行銷活動、拉新工具、公共元件的不斷增加，整體鏈路增長以及資料流轉複雜，對整個系統的可用性、穩定性挑戰也越來越大，所以非常有必要主動找出系統中的脆弱環節，然後針對性地進行加固、防範，從而避免故障發生時所帶來的嚴重後果，進一步提升業務系統的高可用，提高業務系統應急保障能力。近幾年，國內外已經發生了數次大規模的故障導致對海量使用者的服務長時間中斷，產生了巨大的負面影響。為有效減少因內外部環境的故障對系統造成的影響，我們在日常工作中模擬各類故障，以檢驗對系統的影響及研測團隊的風險應對能力，我們在使用者增長領域進行了兩類容災演練：

• 一種是應用層面的混沌演練（Chaos Engineering）

混沌演練是一種通過有意引入系統隨機性、不穩定性和故障來測試和改進系統可靠性的實踐方法，它旨在幫助組織識別和解決潛在的系統缺陷和效能問題，以減少系統故障和提高系統的容錯性。混沌演練的關鍵理念是「通過引入故障來發現故障」。通過有節制地引入不穩定因素和故障場景，例如關閉某個服務、模擬網路延遲、引發硬體故障等，混沌演練可以驗證系統的彈性、容錯能力和恢復能力。它能夠幫助我們發現隱藏的系統弱點，識別效能瓶頸和獨立失敗點，並提供改進系統穩定性和可靠性的機會。

• 第二種是資料儲存的高可用以及機房網路的斷網容災演練

演練的場景包括運營商網路斷網、京東雲機房斷網、儲存裝置斷網、網路流量抖動、網路流量丟包等，影響範圍可能更廣，因此需要提前梳理好演練內容和應急方案，具體包括根據不同場景梳理演練SOP、根據SOP設定演練模板、根據模板評估系統是否達到演練要求、根據演練要求升級改造系統、根據演練模板設計演練流程及checklist，確保不會因演練而影響線上系統。通過對演練過程、演練內容、風險事項、應對方案的梳理，做到萬一發生類似基礎性故障或網路、資料庫切換的時候，有序執行SOP操作，系統處於風險可控的狀態。截止目前，已經完成了針對使用者增長領域掛獎、發獎、資金元件等三個核心應用的資料庫、快取切換演練，達到了預期效果。

總結

本文介紹了使用者增長領域在快速交付產品的同時為保證交付質量所設定的七道防線，每道防線都像一道門禁，只有滿足了准入要求，才能進入下一個階段，以此來規範各個階段的質量活動，並作為質量保證全流程的執行標準。需要指出的是，在實際的質量實踐中，不是形而上的、簡單粗暴的執行以上質量活動，我們會根據產品和業務需求的實際情況進行一定範圍的靈活調整或裁剪，在質量和效率之間達到一個動態的、適度的平衡。

作者：京東科技 王先科

來源：京東雲開發者社群 轉載請註明來源