其实日常工作中CheckList的案例有很多，本篇主要从业务和问题分析两个角度出发，介绍下应该怎么设计并提取基础的Checklist。

首先对于每个宣发推广活动，流程框架基本是账号登录->活动时间/条件限制->完成活动任务->领奖->分享活动->活动结束下线，每个环节作为必测功能点，以及考虑网页类基础测试点，抽取出了【官网活动通用Checklist】。另外对于这些基础信息，也是产品侧每个活动必须考虑的点，如活动时间、活动地址、投放渠道、分享信息等，因此也对应整理了一份标准化需求模板，作为产品侧的【需求基础Checklist】，部分信息如下：

以及比如游戏项目基本都会配套一个微信小程序作为活动宣发载体，每个小程序的基础框架基本一致，角色绑定、banner活动配置、积分商城、消息订阅、分享功能等，可以总结出通用的【小程序Checklist】。

每个游戏项目，在首爆宣发推广期，都会设立配套的官网。对各个游戏官网来说，组成元素基本一致，包括游戏logo、适龄信息、版权信息、官网域名等，在游戏开启公测时，官网还会适时增加游戏下载入口，归类这些一致性，产出了【新官网Checklist】，为后续新官网项目的交付质量提供了有效支撑。

上面这些是基于业务层面，从QA角度需要验证的用例点，但对于一个新官网的建站，还包含域名备案、域名部署、各种合规流程、权限申请等，因此也推动技术侧整理了【新站点配置Checklist】。

对于新游预约、周年庆节点、春节节点等，一般会做一些拉新回流的活动，如成团预约领奖、拉新组队领奖、组队完成小队任务等，这些活动都会有一个组队的概念，那关于队长、队员、以及各类状态限制的考虑，一个【组队功能Checklist】就产生了。

类似的推广活动如【集卡】、【预约领奖】、【竞猜答题】、【数据年报】等，也都可以通过分析提取每个功能的通用性，产出相应的Checklist。

游戏宣发活动的一大特性就是重复度高，QA侧可以提取的Checklist有很多，当然也有一些虽小但重要功能点，诸如表单提交、手机验证码、红点功能、排行榜等，同样可以整理成通用Checklist，以便在各个活动中复用，本文不再注意展开讨论。

最后，关于业务重复性识别，这里再简单提一下另一个负责团队，业务主要是在做雷火研发效能工具以及HR业务的一些系统平台支持，在初期让大家养成整理通用Checklist时，很多同学提出了疑问，认为每个系统都不一样，没有可提取的点，功能都不一样。以通用B端平台看，几乎都会涉及一个流程管理的功能，区别只在于节点的功能含义、审批节点的个数不一致、审批权限等不一致，抽取通用流程：发起审批->多个节点的审批通过/拒绝->流程结束，具体细节点：节点是否逐级审批、是否可以跳级审批、各节点是否可撤回流程、单人/多人审批权等，基于此分析可以产出一份通用【审批流程Checklist】。

综上，针对多样化的业务类型，我们应当深入思考哪些功能是重复使用的、哪些功能具有通用性，可以被抽取整合成一个统一的框架或模块，这种思考方式不仅可以锻炼我们的系统思维能力，更好地拆分理解复杂系统的规律，另一方面通过Checklist用例的灵活复用，可以极大的提升测试质量和效率。

除去前面提到的业务重复功能的Checklist提升效率外，识别并整理业务的核心重点功能Checklist同样至关重要，有助于确保关键业务流程的准确性，以及QA首要任务是保障产品质量，而关键业务是实现业务目标的核心，如果核心业务出错，将直接影响产品的口碑和后续发展。

1. 游戏奖励

对于游戏推广活动，吸引玩家来参加的最大动力是游戏奖励，奖励的丰厚程度，一定程度也影响本次活动的宣发效果，所以奖励是每个活动绝不可以出错的地方，QA需要确保奖励名称、icon、发放数量、限制等正确性，以及更重要的防刷检查，对应产出通用的【奖励Checklist】。

2. 现金红包

涉及金钱类的功能，所有产品线都会列为重点功能，尤其现金红包作为一种流行的游戏推广活动手段，如拉新玩家注册游戏获得x元红包，或者春节期间推广的裂变红包活动等，对QA来说，不仅需要确保红包库存、发放金额、提现方式、黑产用户、保底机制等，还需要关注微信、支付宝等第三方的异常，以及账户余额申请流程等，因此组内对应产出了通用的【红包Checklist】。

这里只讲了两个对于游戏推广活动来说最重要的功能点，除此外类似礼包码兑换、游戏时长兑换、以及舆情风险考虑、游戏体验等也很重要，当然其他各个不同的业务领域也都拥有其独特的核心场景，在实际工作中，我们要深入理解业务，结合业务的核心价值和关键目标，不断提炼和构建一系列有针对性的Checklist。

另一个比较重要的角度，可以从线上/线下暴露的问题出发，从历史经验教训里提取，找出关键的改进措施，并转化为实用的Checklist，以防止类似问题再次发生。下面从几个典型的线上问题和项目过程中遇到的问题来介绍下如何提取：

除去上个章节提到的活动类型重复度高的项目，部门还有一类直接复用的项目，如某个游戏某个活动直接复用到另一个游戏，或者是某个活动复用多个赛季，大致可以归纳为以下几种复用类型：

• 职能间的经验共享

• QA内部的经验共享

04 如何让Checklist发挥最大价值

基础原则需要以“适用有效”为准，不能搞得过于简单或复杂，太简单起不了作用，太复杂推行不了、浪费时间。

1.

确保Checklist是有效的

明确Checklist主要目标，是为了提高效率还是为了减少错误和遗漏，目前团队大多数的Checklist都是为了减少遗漏，降低重复事故的产生。

界定具体的使用场景和范围，明确规范，如在哪个环节使用，什么情况下需要执行。

Checklist内容需要易于理解和执行，使用简洁明了的语言描述每个检查项，避免使用过于复杂或专业的术语，按照合理的逻辑顺序排列检查项，以便执行者能够顺畅地完成整个检查过程。

在引入Checklist的基础上，我们需要根据实际情况灵活调整，不断对其进行优化和完善，以适应不断变化的测试需求和环境，使之更加贴合项目需求。

（1）考虑团队/业务新变化

 以【官网通用Checklist】为例，要求是所有活动都必须执行，用例是在23年整理的，当时团队成员均为半年以上的QA，在24年由于项目量增长，团队涌入了较多新人，在要求新人执行通用用例时，新人疑问会很多，几乎每条用例都要找导师确认是什么意思，应该如何执行。基于此类反馈，开始不断调整Checklist，同时补齐完善新人业务通识文档。

   

（2）踩坑问题的持续迭代

1. 以【新官网Checklist】为例，在某游戏官网开启手机号登录后，未注册过任何网易游戏的纯新手机号，登录活动会提示未注册，但是页面无任何注册入口，排查问题后发现第三方的登录组件本身是区分“登录”和“快速登录”两种模式的，是否开启快捷登录是由组件通过开关控制的，默认是开启状态，区分游戏项目单独配置，但由于组件侧某次将开关关闭后忘记开启，导致官网活动开启手机号登录后不能自动注册网易账号。在新游踩坑后，也是及时补充到了新官网Checklist中，后续作为新游必check点，同时完善了新人通识文档。

2. 每个官网活动业务上都会设置开始和结束时间，但是由于页面上线时间即为活动开始时间，因此之前项目活动是不会单独去做活动开始状态的，页面发布即为活动开始。但是遇到多次需求方提前投放活动页的情况，比如活动二维码放入推广文章，提前一天推文放出，但是由于活动还未上线，导致玩家进入后页面显示404状态。对于热度高的项目会导致大量用户提前进入，新活动推广但是页面访问不了，会对项目造成较大的舆情风险。

最初的改进方案是去沟通需求方的投放时间不可早于官网页面发布，但是由于需求方的不可控，还是会出现提前外放的情况。因此，制定了标准业务流程，所有活动必须设置开始时间，实现未开始状态，从源头拦截问题，完善了【活动通用Checklist】。同时增加了页面404状态监控，在发现页面有404请求后，做好风险评估和需求侧沟通，通过页面提前发布上线，解决问题。

2.

确保Checklist的有效执行

确保Checklist有效执行，重点需要做好监督，检查执行情况，可以通过制定一些流程卡点以及结合一些工具的使用，来更方便的管理和跟踪任务执行。

（1）借助流程管控

通过增加流程卡点作为Checklist检查的强制流程，可以加强对执行情况的监督，进一步提升执行效果，进而确保项目的顺利进行和高质量完成。下面我们将简单阐述几个在实际项目中增设的流程卡点：

1. 某游戏推广活动，上线后临时修改切图问题，由于前端携带了其他调试代码到正式环境，导致发布后页面空白，为解决此类临时修改发布问题，团队制定了相应的流程Checklist，上线当日若需进行二次发布，技术和QA导师需要进行代码review确认，结合项目发布系统，我们在发布流程中增加了卡点，卡点判断是二次发布，则必须导师执行review通过后，才能进行发布。

2. 前文所提到的奖励规范Checklist，要求导师二次review，为确保导师有认真执行审核流程，同样也是在发布系统中增加了卡点，通过项目单增设字段，发布系统项目关联单子，若检测到项目关联的任务单是涉及奖励功能的，则必须导师确认奖励信息核对无误后，才可以继续执行发布操作。

另外要求QA在测试报告增加奖励信息记录，便于导师快速review。

（2）借助工具

 为了确保项目过程中Checklist的有效执行，我们也可以借助一系列的工具，通过工具来辅助监督或者完成Checklist的执行，同样下面通过几个简单的项目事例来具体说明。

正如前面所述，我们已经整理了很多Checklist，但是初期效果并不明显，重复问题还在发生，分析根因主要在于缺乏有效的监督机制。鉴于此，我们考虑在组内现有的测试用例平台基础上进行优化，在创建需求测试用例时，增设一项强制性要求，即必须勾选与项目相关的通用Checklist。

此外，有一些Checklist是针对文案的检查，为了确保执行到位，我们可以借助项目代码做信息提取，在发布正式时，再做一次重点文案信息的核对check，以确保内容的准确无误。

 目前组里借助到的工具主要是用例平台和发布系统，实际测试工作中，可以灵活使用各类小工具去适配自己的业务需求，学会借助工具来辅助确保Checklist的有效执行。

05 Checklist进阶和后续规划

如前面讲述，目前我们借助工具和流程管控做的其实比较少，如何将Checklist的价值扩大化，需要持续不断实践，目前考虑后续主要方向：

• 加强数据分析与挖掘做好数据统计，基于数据分析Checklist的效果和改进方向。
• 短期需要做好监督，确保大家不是无脑点通过。
• 长期将探索Checklist与自动化测试的结合，利用CICD流水线融合，降低人工执行成本，通过脚本或者现有工具的方式，将Checklist中的测试点转化为自动化测试用例，实现自动执行和结果分析。
• 以Checklist为纽带，加强与其他职能的沟通和协作。
• 推动Checklist落地成为研发提测流程的一部分，形成质量门禁。

 Checklist的进阶应用和后续规划，需要团队成员共同努力和持续改进。在未来的工作中，我们将继续以Checklist为核心工具，不断优化测试流程和方法，不断探索和实践新的测试方法和技术，为业务的持续优化和改进提供有力的支持。同时，我们也会加强团队协作和沟通，共同应对更加复杂多变的测试挑战。

06 结语

文章里提到的各类问题，当然也可以通过质量门禁、各类工具、或者自动化等方式去改善，但是这些措施需要投入大量的时间和资源，在部门人力有限、基建能力有限的情况下，短期内难以成效。而解决研发质量问题，有时候最简单的才是最快见效的，Checklist刚好是一个简单、有效且成本低，可以快速见效的方法。以及长期来看，只有先控制好质量风险，深入分析到问题根因，后续的自动化、工具等才能顺利往下推进。那如何把各种踩坑问题凝聚在一条条Checklist中，整合在开发测试流程中，明确各环节的质量控制点，是一个不断学习、总结、反思的过程，鼓励所有QA同学都能够持续去做思考分析，当然最重要的还是需要不断思考如何因地制宜。

 以上内容，就是笔者对于CheckList策略在测试过程中落地实践的理解和一些经验之谈，仅供参考，希望能给大家带来一些有用的信息及有价值的思考。