1、背景

随着业务的不断发展成熟，商业业务逐渐向重运营、重策略的模式发展，提出的需求中运营活动类需求数量也不断增多。而通过项目的积累、与其他业务的讨论共创，我们也积累了一批对运营活动类项目的测试点和对应的测试方案。下面我将从设计思路和具体内容出发介绍面对一个运营活动类项目时，如何进行测试方案设计。

2、测试方案设计

2.1 设计思路

测试方案是在需求评审后，qa从前期准备、测试手段、特殊测试点等方面出发进行的测试设计梳理。通过测试方案设计和评审，能够让项目参与各方了解项目整体节奏、保证测试范围完整、准确评估测试工作内容、捋清测试思路、提前进行准备。

2.2 具体内容

测试方案的具体内容可以从项目的需求阶段、开发联调阶段、测试阶段和上线阶段出发进行设计，运营活动类项目的每个阶段有一些特殊的关注点。

2.2.1 需求阶段

在需求阶段，pm将prd发出后，我们首先从以下几方面进行梳理，列出关注点在需求评审上进行讨论：

（1）梳理出该活动的目的，运营类活动一般都是以拉新、口碑、促单、留存等为目的。

（2）结合需求目的，我们可以去关注需求内容与目的是否对得上。

以拉新为目的的需求，需要关注拉新方式（push、短信、站内信等）。一方面关注文案是否有吸引力、是否包含跳转链接能让用户快速进入活动页面，另一方面关注拉新方式的频次限制、是否会被限流等；
以口碑为目的的需求，需要重视用户体验，例如关注活动页面的用户友好性、参与活动的难易程度、活动给用户带来的福利、售后流程的完整性等；
以促单为目的的需求，例如618、双11活动等，需要关注活动页面是否有节日氛围、最终是否能达到吸引人下单的效果；
以留存为目的的需求，需要关注活动是否真的能为用户带来好处、能否吸引用户持续参与等。

（3）关注流程完整性，活动流程逻辑是否闭环。活动流程包括用户由入口 → 活动页面 → 参与活动 → 获得奖励 → 售后流程。而结合项目迭代过程中的数据漏斗和收入曲线可以发现，流程中的每一步都会有不同程度的人员流失，而通过不断迭代可以提升转化率和收入。一方面我们需要从入口入手，通过颜色、大小、动效等使入口更加醒目，并在收入达到一定程度后争取到更好的入口位置，从而吸引更多用户进入活动页面。而另一方面我们要从活动的各个环节提升用户体验，例如增加进入页面后的指引、简化活动的参与难度、提升用户参与活动成功后对中奖效果的感知、并吸引用户持续参与活动等，从而提升各个环节的转化率。

（4）提前考虑一些常见测试点例如考虑到需求对用户登录态的要求，包括用户已登录和未登录的区别、在什么节点吊起登录等；需求的影响范围，活动流程是否可以用开关控制等。

2.2.2 开发、联调阶段

（1）接口测试在技术评审后我们可以根据开发给出的技术设计文档梳理出主流程涉及的接口，在联调阶段就可以在接口测试平台设计接口case进行前置测试。而对运营活动类项目来说，活动页面交互多、用户行为不可完全预测，因此我们也可以通过接口平台进行异常情况测试，例如对登录态异常、请求时间异常、参数异常、幂等、边界值等情况。

（2）数据构造准备如果测试过程中涉及到已有工具的使用，在提测前需验证好工具的可用性。如果是没有能使用的工具而时间充裕的情况，可以提前开发可用的数据构造，方便开发自测和qa测试使用。

2.2.3 测试阶段

（1）前提条件

1）活动时间关注活动未开始/进行中/倒计时结束等时间节点下的不同效果/文案：

活动未开始：展示开始时间，固定文案；
活动进行中：到活动开始时间，相关文案是否有变化（mock/apollo配置活动开始时间）；
倒计时结束：倒计时清零后，页面恢复；

2）用户身份

构造能/不能参加活动的用户：修改对应的表构造相应用户身份/apollo配置白名单

3）频次限制运营类活动有次数限制，每人每日参加活动的次数有限。测试时需关注不足/等于/大于限制次数的情况，对大于限制次数的情况，一般前端页面参与活动的入口会关闭，也可以单独对后端接口进行接口测试来观察此时的判断逻辑是否符合预期。

（2）活动页面

1）签到功能签到功能一般会涉及到当日签到/补签/连签一周奖励升级的场景，对于连签一周奖励升级的场景，可以通过修改库表/缓存来覆盖。

2）分享功能分享出去的页面在不同平台上能否打开：微信聊天（打开是小程序）、朋友圈、qq聊天、空间、微博、浏览器（打开是m页）；分享出去的页面如果打开没有登录信息，需要清空cookie，可以让fe提供注入工具；分享出去后通常需要新用户也进行一些操作才能算邀请其他人成功，可以直接mock邀请接口返回成功状态，看能否获得对应的奖励；

3）活动中奖