背景
随着当代电商行业的快速发展，网购用户数量也快速增长。在过去常常线下出现的各类促销活动也逐渐转移至线上，并且伴随着线上用户消费能力不断升级，一年一次的电商大促也已经日常化。各类购物软件为了吸引用户消费，各类促销玩法的层出不穷并且规则复杂多变，在任一个链路出现问题，都将会给商家和普通消费者带来巨大的经济损失，如何保障业务在一个快速迭代的节奏下稳定、安全的发展，对于技术质量团队来说是一个不小的挑战。基于用户体验，通过设计全面、稳定、敏捷的软件质量保障体系，提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险，是测试团队的重要任务和目标。
本文基于软件工程中软件测试的基本流程，由简至微的介绍一套全面、易学的会场类大促测试方案。本文首先会介绍日常通用的软件测试方案，再阐述大促类项目用到的测试方案及其具体的实践，同大家分享一下新人如何快速熟悉并完成一场电商大促质量保障项目。
日常通用方案
软件测试的基本流程是希望通过规范化、标准化的流程，让软件测试可以变得高效，我们的日常需求一般*含：产品需求、技术改造、线上问题修复，需求复杂度通常比较低，一般都需要快速上线。日常需求测试流程一般*含需求分析、制定测试计划、设计并评审测试用例、测试执行、测试报告。但需要声明一点，测试的过程并非一成不变，固定的，它只是一种规范，一种基本要求。
需求分析及评审
需求分析是整个测试过程的基础，因为需求文档是业务验收的标准，为了避免由于理解不一致而导致的信息差,每一位项目相关人员都要参与，开发同学必须按照评审后所确定的需求详情进行开发。
参与需求评审可以帮助我们了解业务相关知识、对文档中未涉及的异常逻辑和风险前置、用户体验不好的地方提前优化。
这一阶段我们需要将产品需求转换为功能需求，对该需求的数据、易用性、参数、性能等方面进行确定，并配合场景分析，将可能调用的内外部模块和系统调用进行覆盖，再根据经验挖掘出隐形需求，例如部分极限、异常条件。
策略制定
参考需求文档，技术方案、视觉交互等文档，有计划的分出产品功能以及设计合理的测试用例，用例编写完成之后考虑每个功能域或阶段分别采用什么样的测试方法，可以更全面、高效的完成，例如：功能测试、兼容测试、性能测试，部分用例可以沉淀为自动化测试用例，设计用例后需要和产品、开发同学一起进行用例评审，*用例的覆盖程度达到预期，避免因为漏测而导致线上问题。
计划制定
由于产品的复杂度越来越高，各类测试项目也逐渐多样化，测试计划的是为了让我们更好的提前应对风险，根据项目迭代计划，进行进度、测试资源的分配，进行风险评估和兜底策略的制定，同时明确测试完成后需要产出的测试资产（测试文档、测试用例、自动化工具）等。
编写测试计划时，需要充满考虑实际测试阶段涉及的各类因素，*含：项目排期、测试资源、测试目标、测试标准、测试风险等。例如测试风险，一般需要*含项目开发延期、测试人员不足、测试时间不足导致用例无法全部执行、BUG无法及时修改导致无法验证、测试环境不稳定等问题。因此，一份完备的测试计划可以让我们事半功倍。
测试执行
在开发同学提测前，我们可以先准备测试环境，在冒烟测试通过后，再正式执行测试用例，记录结果并进行bug跟踪直至bug修复完成，我们每个人在测试过程中都会遇到几种类型的测试，常见的功能测试*含:单元测试、冒烟测试、接口测试、回归测试、Beta/验收测试等。非功能测试*含，性能测试、负载测试、压力测试、容量测试、安全测试、相容性测试等，必要时还可以进行交叉测试，根据需求的特性，防止测试人员*粗心导致漏测。选择合适的方法，可以帮助我们更敏捷的完成测试任务。
测试报告阶段
在实际测试执行阶段会因为各种主观、客观原因导致需求测试结果和测试计划有所出入，在测试报告中我们需*数据真实、全面。并且将测试中产生的问题进行分析，给出下次规避的方案，测试报告通过后需求发布上线。
大促的挑战
我们日常需求迭代的一套流程已经非常成熟，并且也有许多对应的测试项目管理工具，但是随着电商业务越来越丰富、玩法越来越复杂，参与者也越来越多，我们对会场的要求不仅是质量和稳定性，保障重点也逐渐转移至算法、体验、资损、数据等方面，普通的软件测试流程对于多线并行的大促项目而言，存在许多局限性和痛点，以下三类问题比较突出：
日常需求增多：大促期间，产品会根据往年的会场效果，提出各类新增需求，大部分都无法通过自动化测试覆盖，需要手工验证。
会场变更频繁：活动预热期间，业务方会根据投放效果不断优化会场内容和投放策略，所有会场变更发布后都需要测试验证，效率较低且容易出现线上问题；
业务链路复杂：每场活动的玩法、规则链路都不同，
同时，由于业务不断更新，保障体系往往是在大促完成后根据业务需求而新增的，所以对技术质量保障的同学也带来很多挑战：
测试效率较低：之前的测试资产无法复用，新增需求通过手工回归，*量巨大；
变更流程不严谨：会场配置多且复杂，新手很容易因为对配置项的理解产生歧义而导致配置错误或无效引发问题；
自动化体系不够完备：会场发布、验收环节基本靠人工保障，自动化卡点及页面巡检体系不够完善，许多线上问题无法及时发现；
如何破局
众所周知，任何事物都有其生命周期，而时间轴就是依据时间顺序，把一方面或多方面的事件串联起来，形成相对完整的记录体系，将事物系统化、完整化、精确化。在测试过程中对产品现阶段的功能进行覆盖只是基础能力，将项目按照时间的抽象为：过去、现在、将来三种阶段，并根据不同阶段的特性进行的分析，有助于我们形成更完善的测试思维。简而言之，过去即是将之前的项目总结的经验和有效资源进行复用，现在就是根据已有的需求文档，对需求进行合理分析和拆解，制定对应的测试方案，而未来就是将产品上线后可能要扩展的功能、可能触发的风险提前预测并提出对应的解决方案，帮助业务*时间处理，甚至规避问题。因此，在会场测试的实践过程中，我们也可以将整个流程按照时间轴分为三个阶段：会场发布前、会场发布阶段、会场发布后，我们的保障策略也是围绕着三个阶段去设计。
组件设计：可扩展可复用
我们的产品同学根据每年大促会场的需要，提出需求，新增会场会场组件模块。由于很多组件在日常使用频率比较低，我们需要注意组建的可扩展性以及支持展示的
商品类型（图片、视频、直播）等，尽量覆盖各类场景，避免后期二次开发，降低效率。
会场搭建：“搭招选投”体系
即各个业务方根据其业务特性和目标，搭建符合需求的大促商品会场，进行商品利益点、优惠信息、互动玩法的透出，一般分为主会场、分会场两个部分。为了保障用户体验，我们需要关注各个会场的标题、文案、视觉、选品是否符合要求、互动及裂变能力的支持，是否可以让用户回流。
会场测试：自动化代替手工
会场测试是我们需要重点关注的阶段了（重要的事情说三遍），虽然测试方法、测试分析和测试策略非常重要，但是为了保障产品需求的快速迭代，质量保障需要和研发效能相辅相成，普通的手工测试早已无法满足现状，自然而然，各类自动化专项测试成为了“当红炸子鸡”，在会场测试时我们主要用到：UI自动化、接口自动化、巡检自动化以及线上实时监控，尽量用机器的自动化代替人工，将质量问题前置。
会场验收：体验*
在会场搭建完成并通过基本测试后，我们基本可以看到会场外投时的视觉效果，但是实际上，我们项目参与的同学对会场的真实体感已经没有那么强烈了，关注点也更偏向于功能而非真实体验，导致我们还缺乏一道体验保障防线。因此，项目整体上线面向我们的用（衣食）户（父母）前，我们需要提前预留一个缓冲期，内部组织一次基于用户体验的全链路验收，一般分为两个阶段：
招募用户体验官，一般为非项目组相关成员，从不同用户视角对整个会场进行体验，并集中提出问题，评估后尽快优化；
邀请业务方（甲方爸爸）进行整体验收，确定我们的会场效果符合预期，如果有歧义，评估影响范围和排期时间后，尽快修复；
非常后，你以为这就结束了？？？Too young too naive!我们还需要关注遗留问题和新增体验问题的排期修复情况，尽量*效果非常优化！给客户超出预期的体验！
会场发布：巡检、管控、监控缺一不可
会场正式上线后，我们的质量保障并没有结束，另外还有三个重点节点需要关注：分别是页面巡检、变更管控、接口监控。
首先需要通过测试平台中的自动化巡检功能，对会场的页面进行UI自动化巡检配置，主要*含页面的死检测、非法字符、空坑、元素异常，将风险快速上报，避免因为页面数量过多造成的漏测，出现问题及时通知页面*负责人。
其次，当业务需要变更线上配置时，为防止拥有权限的人员误操作修改配置导致线上故障，要将页面发布权限回收至对应的技术小二或页面*负责人，明确紧急发布（新增变更）的流程规范。当线上页面需要紧急变更时，需要向页面负责人提交变更流程，在测试通过后，进行审批并正式发布上线。
当页面正式发布后还需要及时关注各类接口的监控，务必确认各类监控的阈值设置的合理性。在必要时，还可以编写安全作战手册，指定各类线上问题*处理和响应人，并提前给出做好解决方案，问题出现后*时间止血！
实践：新人如何快速上手
初次接触接触大促会场，我们如何结合各类测试方法更全面的保障我们的页面质量及稳定性呢？其实答案很简单——角色转换，将自己从测试视角转换到普通消费者。
拿出手机，打开任一个电商类APP，我们可以发现用户的行动链路基本都是围绕我们的营销会场进行的，一般*含这三类行为：浏览会场、精准搜索、商品交易，这三种行为分别对应质量保障三类内容：会场质量、会场个性化、资损防控。
用户的“浏览”行为
以上图中阿里拍卖520大促为例，当用户拿起手机进入主会场后，在浏览过程中基本覆盖了每一个链路，其中主会场的视觉效果、商品组件排列方式、商品投放内容的对用户的购物体验和消费意愿有着重要的影响，所以在保障过程中我们需要格外注意会场的交互体验流程、组件双端兼容、页面性能。在时间充裕的情况下，甚至可以将组件提前进行AB试验，选取投放效果非常好的组件以及爆品作为首屏内容，从而提高页面转换率。
用户的“搜索”行为
首先我们需要*搜索结果的准确性，并且根据搜索历史快速补充用户画像，对个性化的时效性要求非常高，以此来*会场内容精准推送、无空坑异常、无错误敏感文案；
用户的“交易”行为
交易是所有行为中非常复杂的，它除了会场页面、详情页外，还涉及许多外部应用，例如收银台、支付换端等场景。也是非常容易出现线上问题的链路之一，例如：图片利益点透出，各类优惠针对人群投放、各入口优惠券透出、优惠券配置校验，商家资损。
为了保障这些行为所覆盖的链路，我们需要不同的测试方法，一般每类方案都会设立不同的专项，一般分为以下几类：
页面测试：页面基础适配、交互流畅、互动等功能；
容灾测试：模拟组件发生限流、降级、容灾等异常情况时，数据是否可以进行兜底、首屏正常展示；
性能测试：验证大促场景涉及应用的性能、投放、推荐接口的性能表现，评估链路中的性能瓶颈，推动优化；
算法测试：选品投放、商品个性化、地域推荐的精准性和时效性；
弱网测试：用户在实际使用时，因网络拥堵、信号波动而造成页面体感交差，需要对通用的弱网场景进行覆盖，测试弱网提示及兜底页面的友好性；
资损测试：梳理各类可能导致资损的链路，补充并验证资损警报的有效性；
预案验证：各类已有预案的有效性，确保部分预案执行后，不会造成主链路体验严重降级；
用户体验：通过模拟用户使用产品功能的操作，收集不同视角的体验问题，对产品进行再次优化；
常见问题及解决方案
会场构成的内容大部分都依赖于后台配置，在会场运营和活动过程中整体变更风险和内容风险逐步从代码变更向配置变更转移。由于部分资金相关的配置的不可逆性，配置的准确性和效率是大促期间的一个痛点，尤其是流程对接时的信息GAP产生的问题每年都在复盘，但几乎每年都会复现。
常见配置类问题
缺乏配置模板：新手很容易因为对配置项的理解产生歧义而导致配置错误或无效；
变更流程管控：信息不同步及发布权限开放，由变更导致的线上问题频发；
安全作战手册：出现问题无法快速定位、找到相关人员，没有应急方案；
配置变更流程管控
“为什么改动页面一个非常小的点还要审批还要回收权限？快一点不好吗？”在大促期间常常被各个业务方同学问到这个问题。其实，所有的流程都是为了将变更后的风险点前置，没有无缘无故就增加的流程，一定是因为之前出过问题，所以才会多一道防线。我们的目的都是为了将风险前置。
因此，当线上出现紧急问题需要执行紧急变更时，申请人需要严格按照变更流程进行操作首先需要按照流程管理平台中的模板提交变更内容，经过审批人核查通过后，流程流转至页面或配置负责人，进行变更风险评估。评估通过后，申请人需要在测试环境下进行配置和执行，配合测试同学进行验证和review。确定变更满足预期且不会引起线上问题后，才可以正式发布上线。发布后，需要配合自动化巡检，及时观察监控及警报。
总结
我们线上的页面是用户非常直观、非常快速了解我们产品和业务的途径，作为测试开发同学，需要更好的采用技术的手段助力我们业务更快、更稳的发展，确保交付时的非常高满意度，并为用户提供非常佳体验。在此引用一句话：“凡善怕者,必身有所正,言有所规,行有所止,偶有逾矩,亦不出大格。”测试同学作为需求发布上线的非常后一道防线，也一定要将基础质量保障和用户体验作为我们的核心，心存敬畏,才能随时时绷紧“质量”这根弦不越雷池半步。
