背景
  隨著當代電商行業的快速發展，網購用戶數量也快速增長。在過去常常線下出現的各類促銷活動也逐漸轉移至線上，并且伴隨著線上用戶消費能力不斷升級，一年一次的電商大促也已經日?；?。各類購物軟件為了吸引用戶消費，各類促銷玩法的層出不窮并且規則復雜多變，在任一個鏈路出現問題，都將會給商家和普通消費者帶來巨大的經濟損失，如何保障業務在一個快速迭代的節奏下穩定、安全的發展，對于技術質量團隊來說是一個不小的挑戰?；谟脩趔w驗，通過設計全面、穩定、敏捷的軟件質量保障體系，提高軟件質量，回避軟件發布后由于潛在的軟件缺陷和錯誤造成的隱患所帶來的商業風險，是測試團隊的重要任務和目標。
  本文基于軟件工程中軟件測試的基本流程，由簡至微的介紹一套全面、易學的會場類大促測試方案。本文首先會介紹日常通用的軟件測試方案，再闡述大促類項目用到的測試方案及其具體的實踐，同大家分享一下新人如何快速熟悉并完成一場電商大促質量保障項目。
  日常通用方案
  軟件測試的基本流程是希望通過規范化、標準化的流程，讓軟件測試可以變得高效，我們的日常需求一般包含：產品需求、技術改造、線上問題修復，需求復雜度通常比較低，一般都需要快速上線。日常需求測試流程一般包含需求分析、制定測試計劃、設計并評審測試用例、測試執行、測試報告。但需要聲明一點，測試的過程并非一成不變，固定的，它只是一種規范，一種基本要求。
  需求分析及評審
  需求分析是整個測試過程的基礎，因為需求文檔是業務驗收的標準，為了避免由于理解不一致而導致的信息差,每一位項目相關人員都要參與，開發同學必須按照評審后所確定的需求詳情進行開發。
  參與需求評審可以幫助我們了解業務相關知識、對文檔中未涉及的異常邏輯和風險前置、用戶體驗不好的地方提前優化。
  這一階段我們需要將產品需求轉換為功能需求，對該需求的數據、易用性、參數、性能等方面進行確定，并配合場景分析，將可能調用的內外部模塊和系統調用進行覆蓋，再根據經驗挖掘出隱形需求，例如部分極限、異常條件。
  策略制定
  參考需求文檔，技術方案、視覺交互等文檔，有計劃的分出產品功能以及設計合理的測試用例，用例編寫完成之后考慮每個功能域或階段分別采用什么樣的測試方法，可以更全面、高效的完成，例如：功能測試、兼容測試、性能測試，部分用例可以沉淀為自動化測試用例，設計用例后需要和產品、開發同學一起進行用例評審，用例的覆蓋程度達到預期，避免因為漏測而導致線上問題。
  計劃制定
  由于產品的復雜度越來越高，各類測試項目也逐漸多樣化，測試計劃的是為了讓我們更好的提前應對風險，根據項目迭代計劃，進行進度、測試資源的分配，進行風險評估和兜底策略的制定，同時明確測試完成后需要產出的測試資產（測試文檔、測試用例、自動化工具）等。
  編寫測試計劃時，需要充滿考慮實際測試階段涉及的各類因素，包含：項目排期、測試資源、測試目標、測試標準、測試風險等。例如測試風險，一般需要包含項目開發延期、測試人員不足、測試時間不足導致用例無法全部執行、BUG無法及時修改導致無法驗證、測試環境不穩定等問題。因此，一份完備的測試計劃可以讓我們事半功倍。
  測試執行
  在開發同學提測前，我們可以先準備測試環境，在冒煙測試通過后，再正式執行測試用例，記錄結果并進行bug跟蹤直至bug修復完成，我們每個人在測試過程中都會遇到幾種類型的測試，常見的功能測試包含:單元測試、冒煙測試、接口測試、回歸測試、Beta/驗收測試等。非功能測試包含，性能測試、負載測試、壓力測試、容量測試、安全測試、相容性測試等，必要時還可以進行交叉測試，根據需求的特性，防止測試人員工作粗心導致漏測。選擇合適的方法，可以幫助我們更敏捷的完成測試任務。
  測試報告階段
  在實際測試執行階段會因為各種主觀、客觀原因導致需求測試結果和測試計劃有所出入，在測試報告中我們需數據真實、全面。并且將測試中產生的問題進行分析，給出下次規避的方案，測試報告通過后需求發布上線。
  大促的挑戰
  我們日常需求迭代的一套流程已經非常成熟，并且也有許多對應的測試項目管理工具，但是隨著電商業務越來越豐富、玩法越來越復雜，參與者也越來越多，我們對會場的要求不僅是質量和穩定性，保障重點也逐漸轉移至算法、體驗、資損、數據等方面，普通的軟件測試流程對于多線并行的大促項目而言，存在許多局限性和痛點，以下三類問題比較突出：
  日常需求增多：大促期間，產品會根據往年的會場效果，提出各類新增需求，大部分都無法通過自動化測試覆蓋，需要手工驗證。
  會場變更頻繁：活動預熱期間，業務方會根據投放效果不斷優化會場內容和投放策略，所有會場變更發布后都需要測試驗證，效率較低且容易出現線上問題；
  業務鏈路復雜：每場活動的玩法、規則鏈路都不同，
  同時，由于業務不斷更新，保障體系往往是在大促完成后根據業務需求而新增的，所以對技術質量保障的同學也帶來很多挑戰：
  測試效率較低：之前的測試資產無法復用，新增需求通過手工回歸，工作量巨大；
  變更流程不嚴謹：會場配置多且復雜，新手很容易因為對配置項的理解產生歧義而導致配置錯誤或無效引發問題；
  自動化體系不夠完備：會場發布、驗收環節基本靠人工保障，自動化卡點及頁面巡檢體系不夠完善，許多線上問題無法及時發現；
  如何破局
  眾所周知，任何事物都有其生命周期，而時間軸就是依據時間順序，把一方面或多方面的事件串聯起來，形成相對完整的記錄體系，將事物系統化、完整化、精確化。在測試過程中對產品現階段的功能進行覆蓋只是基礎能力，將項目按照時間的抽象為：過去、現在、將來三種階段，并根據不同階段的特性進行的分析，有助于我們形成更完善的測試思維。簡而言之，過去即是將之前的項目總結的經驗和有效資源進行復用，現在就是根據已有的需求文檔，對需求進行合理分析和拆解，制定對應的測試方案，而未來就是將產品上線后可能要擴展的功能、可能觸發的風險提前預測并提出對應的解決方案，幫助業務時間處理，甚至規避問題。因此，在會場測試的實踐過程中，我們也可以將整個流程按照時間軸分為三個階段：會場發布前、會場發布階段、會場發布后，我們的保障策略也是圍繞著三個階段去設計。
  組件設計：可擴展可復用
  我們的產品同學根據每年大促會場的需要，提出需求，新增會場會場組件模塊。由于很多組件在日常使用頻率比較低，我們需要注意組建的可擴展性以及支持展示的
  商品類型（圖片、視頻、直播）等，盡量覆蓋各類場景，避免后期二次開發，降低效率。
  會場搭建：“搭招選投”體系
  即各個業務方根據其業務特性和目標，搭建符合需求的大促商品會場，進行商品利益點、優惠信息、互動玩法的透出，一般分為主會場、分會場兩個部分。為了保障用戶體驗，我們需要關注各個會場的標題、文案、視覺、選品是否符合要求、互動及裂變能力的支持，是否可以讓用戶回流。
  會場測試：自動化代替手工
  會場測試是我們需要重點關注的階段了（重要的事情說三遍），雖然測試方法、測試分析和測試策略非常重要，但是為了保障產品需求的快速迭代，質量保障需要和研發效能相輔相成，普通的手工測試早已無法滿足現狀，自然而然，各類自動化專項測試成為了“當紅炸子雞”，在會場測試時我們主要用到：UI自動化、接口自動化、巡檢自動化以及線上實時監控，盡量用機器的自動化代替人工，將質量問題前置。
  會場驗收：體驗
  在會場搭建完成并通過基本測試后，我們基本可以看到會場外投時的視覺效果，但是實際上，我們項目參與的同學對會場的真實體感已經沒有那么強烈了，關注點也更偏向于功能而非真實體驗，導致我們還缺乏一道體驗保障防線。因此，項目整體上線面向我們的用（衣食）戶（父母）前，我們需要提前預留一個緩沖期，內部組織一次基于用戶體驗的全鏈路驗收，一般分為兩個階段：
  招募用戶體驗官，一般為非項目組相關成員，從不同用戶視角對整個會場進行體驗，并集中提出問題，評估后盡快優化；
  邀請業務方（甲方爸爸）進行整體驗收，確定我們的會場效果符合預期，如果有歧義，評估影響范圍和排期時間后，盡快修復；
  非常后，你以為這就結束了？？？Too young too naive!我們還需要關注遺留問題和新增體驗問題的排期修復情況，盡量效果非常優化！給客戶超出預期的體驗！
  會場發布：巡檢、管控、監控缺一不可
  會場正式上線后，我們的質量保障并沒有結束，另外還有三個重點節點需要關注：分別是頁面巡檢、變更管控、接口監控。
  首先需要通過測試平臺中的自動化巡檢功能，對會場的頁面進行UI自動化巡檢配置，主要包含頁面的死檢測、非法字符、空坑、元素異常，將風險快速上報，避免因為頁面數量過多造成的漏測，出現問題及時通知頁面負責人。
  其次，當業務需要變更線上配置時，為防止擁有權限的人員誤操作修改配置導致線上故障，要將頁面發布權限回收至對應的技術小二或頁面負責人，明確緊急發布（新增變更）的流程規范。當線上頁面需要緊急變更時，需要向頁面負責人提交變更流程，在測試通過后，進行審批并正式發布上線。
  當頁面正式發布后還需要及時關注各類接口的監控，務必確認各類監控的閾值設置的合理性。在必要時，還可以編寫安全作戰手冊，指定各類線上問題處理和響應人，并提前給出做好解決方案，問題出現后時間止血！
  實踐：新人如何快速上手
  初次接觸接觸大促會場，我們如何結合各類測試方法更全面的保障我們的頁面質量及穩定性呢？其實答案很簡單——角色轉換，將自己從測試視角轉換到普通消費者。
  拿出手機，打開任一個電商類APP，我們可以發現用戶的行動鏈路基本都是圍繞我們的營銷會場進行的，一般包含這三類行為：瀏覽會場、精準搜索、商品交易，這三種行為分別對應質量保障三類內容：會場質量、會場個性化、資損防控。
  用戶的“瀏覽”行為
  以上圖中阿里拍賣520大促為例，當用戶拿起手機進入主會場后，在瀏覽過程中基本覆蓋了每一個鏈路，其中主會場的視覺效果、商品組件排列方式、商品投放內容的對用戶的購物體驗和消費意愿有著重要的影響，所以在保障過程中我們需要格外注意會場的交互體驗流程、組件雙端兼容、頁面性能。在時間充裕的情況下，甚至可以將組件提前進行AB試驗，選取投放效果非常好的組件以及爆品作為首屏內容，從而提高頁面轉換率。
  用戶的“搜索”行為
  首先我們需要搜索結果的準確性，并且根據搜索歷史快速補充用戶畫像，對個性化的時效性要求非常高，以此來會場內容精準推送、無空坑異常、無錯誤敏感文案；
  用戶的“交易”行為
  交易是所有行為中非常復雜的，它除了會場頁面、詳情頁外，還涉及許多外部應用，例如收銀臺、支付換端等場景。也是非常容易出現線上問題的鏈路之一，例如：圖片利益點透出，各類優惠針對人群投放、各入口優惠券透出、優惠券配置校驗，商家資損。
  為了保障這些行為所覆蓋的鏈路，我們需要不同的測試方法，一般每類方案都會設立不同的專項，一般分為以下幾類：
  頁面測試：頁面基礎適配、交互流暢、互動等功能；
  容災測試：模擬組件發生限流、降級、容災等異常情況時，數據是否可以進行兜底、首屏正常展示；
  性能測試：驗證大促場景涉及應用的性能、投放、推薦接口的性能表現，評估鏈路中的性能瓶頸，推動優化；
  算法測試：選品投放、商品個性化、地域推薦的精準性和時效性；
  弱網測試：用戶在實際使用時，因網絡擁堵、信號波動而造成頁面體感交差，需要對通用的弱網場景進行覆蓋，測試弱網提示及兜底頁面的友好性；
  資損測試：梳理各類可能導致資損的鏈路，補充并驗證資損警報的有效性；
  預案驗證：各類已有預案的有效性，確保部分預案執行后，不會造成主鏈路體驗嚴重降級；
  用戶體驗：通過模擬用戶使用產品功能的操作，收集不同視角的體驗問題，對產品進行再次優化；
  常見問題及解決方案
  會場構成的內容大部分都依賴于后臺配置，在會場運營和活動過程中整體變更風險和內容風險逐步從代碼變更向配置變更轉移。由于部分資金相關的配置的不可逆性，配置的準確性和效率是大促期間的一個痛點，尤其是流程對接時的信息GAP產生的問題每年都在復盤，但幾乎每年都會復現。
  常見配置類問題
  缺乏配置模板：新手很容易因為對配置項的理解產生歧義而導致配置錯誤或無效；
  變更流程管控：信息不同步及發布權限開放，由變更導致的線上問題頻發；
  安全作戰手冊：出現問題無法快速定位、找到相關人員，沒有應急方案；
  配置變更流程管控
  “為什么改動頁面一個非常小的點還要審批還要回收權限？快一點不好嗎？”在大促期間常常被各個業務方同學問到這個問題。其實，所有的流程都是為了將變更后的風險點前置，沒有無緣無故就增加的流程，一定是因為之前出過問題，所以才會多一道防線。我們的目的都是為了將風險前置。
  因此，當線上出現緊急問題需要執行緊急變更時，申請人需要嚴格按照變更流程進行操作首先需要按照流程管理平臺中的模板提交變更內容，經過審批人核查通過后，流程流轉至頁面或配置負責人，進行變更風險評估。評估通過后，申請人需要在測試環境下進行配置和執行，配合測試同學進行驗證和review。確定變更滿足預期且不會引起線上問題后，才可以正式發布上線。發布后，需要配合自動化巡檢，及時觀察監控及警報。
  總結
  我們線上的頁面是用戶非常直觀、非?？焖倭私馕覀儺a品和業務的途徑，作為測試開發同學，需要更好的采用技術的手段助力我們業務更快、更穩的發展，確保交付時的非常高滿意度，并為用戶提供非常佳體驗。在此引用一句話：“凡善怕者,必身有所正,言有所規,行有所止,偶有逾矩,亦不出大格?！睖y試同學作為需求發布上線的非常后一道防線，也一定要將基礎質量保障和用戶體驗作為我們的核心，心存敬畏,才能隨時時繃緊“質量”這根弦不越雷池半步。