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