考拉红包-一个典型项目的测试过程

一： 项目的背景

为满足市场部运营需求（拉新、拉活），针对考拉全场，生成考拉红包。可以丰富红包种类，和优惠券可叠加使用，利于转化，可应用到S级大促、元宵晚会及3档综艺节目等多个场景。

二: 项目难点分析

在项目排期完成、技术方案确认后，我们总结了该项目中可能遇到的难点：

• 红包全新业务逻辑， 整个下单链路需要重构， 相对测试需要做全链路回归
• 测试开发时间短：相比预期， 整个开发和测试时间被压缩了1/3
• 红包项目是是第一个使用DDB的项目，可能存在不可预料的异常问题
• 上线时间固定、无法延期
• 涉及的模块多，测试环境搭建复杂
• 项目时间长，项目期间上线版本影响大

三. 项目过程

有困难我们就需要一一对针对并制定方案解决：

总结起来我们做了以下几个方面：

• 制定可靠的质量控制流程
• 额外的测试手段保证质量
• 充分考虑潜在的风险并制定兜底方案

1. 制定的项目流程一览

相对一般的项目流程，我们增加了签字单流程，既在每一个阶段中，相关负责人都需要对进度输出做验收、并签字确认。

2. 选取合理的冒烟用例， 保证提测时的质量

冒烟用例的目的还是还是提供主流程用例给开发，让开发在自测过程中评估代买质量，提早发现问题。以保证提测后QA介入测试时主流程流畅，不需要重复打回，浪费双方时间，无法保证上线时间。

提测时单元测试覆盖比例要求至少50%

  测试手段分析：

3. 接口提前实施

在项目开始的时候未解决时间不足的问题， 我们在项目开始、开发未提测的时候开始做接口。接口在回归测试接口大大减少了

1. 在回归阶段整体上节约了80%的时间
2. 一次性工作， 之后可以将接口用例集成到持续回归集中。

缺点：

1. 初始的投入较大，所需时间较多。暂时难以满足目前敏捷项目的快速流程。
2. 部分场景还无法用接口替代，类似涉及UI、涉及人机交互的场景
3. 需要特定的测试数据， 并保持测试数据的问题。 因此在项目开始时期就需要创建稳定的数据。

4. 代码覆盖分析

可以看到每个工程的代码变更大小，如 buy 修改了 136 个文件 1619行代码，predelivery只修改了183行代码

同时我们也可以从这个页面看出buy工程单元测试覆盖变更代码的55% 也就是说有890行代码已经被单元测试覆盖到。

然后buy工程部署在hst_testall 环境被冒烟测试、多伦功能测试后的代码覆盖率是 83%,剩下的两百多行未覆盖的代码，经过排查是有一些测试遗漏点

四. 线上线下bug分析

线下bug：从分类上看，多数还是属于功能缺陷，且数量和严重程度并不高， 整体质量控制较好

	trivial	minor	normal	major
功能缺陷			16	6
需求变更		2
安全漏洞		1
UI缺陷	1

线上bug：项目上线时有一个线上
优惠券均摊导致的订单实付金额相比应付金额少了一分钱而无法支付
Bug原因：直接原因是在下单重构时，对活动减免金额精度处理存在问题。下单的精度保存4位，支付存2位， 当活动税费减免出现四位小数时，两边不完全想等导致校验不通过。
实际中我们的用例中已包含该类场景，但是商品数据不够丰富，没有

可以看到每个工程的代码变更大小，如 buy 修改了 136 个文件 1619行代码，predelivery只修改了183行代码

同时我们也可以从这个页面看出buy工程单元测试覆盖变更代码的55% 也就是说有890行代码已经被单元测试覆盖到。

然后buy工程部署在hst_testall 环境被冒烟测试、多轮功能测试后的代码覆盖率是 83%,剩下的两百多行未覆盖的代码，经过排查是有一些测试遗漏点。

以buy举例未覆盖的场景：

 1. 这段代码的是判断当在提交订单时，若订单中商品为虚拟单品时， 则无需开具发票。实际上我们测试的时候，下单虚拟商品是在订单提交中检查了金额、红包是否正确， 但未去提交订单， 因此代码没有走到这步。确认为测试时遗漏。

2. 以下代码是异常情况下的错误捕捉，测试中未模拟该异常场景。该类异常场景适用于单元测试覆盖。 

第一次尝试使用集成测试覆盖的方法总结的一些东西

1. 在实际功能测试中我们对于测试场景中的异常数据覆盖还不足，很多异常是开发在代码中覆盖而我们的功能测试中未覆盖， 那么开发未覆盖而我们也未覆盖测试的场景也会存在。
2. 反合之后同一个类的其他需求改动会使覆盖率统计产生较大的误差
3. Dev分支暂时还无法统计到代码改动的覆盖率，对于回归时是否回归到了代码改动点的还无法做判断。

5. 随机性测试情况

在一轮测试之后我们做了一些随机性测试，使用一些在测试用例之外的商品和场景下单，整个过程发现一个精度问题（KJDS-87170）。

6. 考虑潜在的风险并制定兜底方案：

红包项目中最大的一个风险是红包首次使用了DDB数据。 在测试的时候我们就针对可能存在的问题做了较充分的测试，包括SQ重启，数据库切换的演练。而且针对最坏的情况， 即数据库完全不可用的情况下，我们也制定了兜底方案：禁用红包，确保下单流程无恙。 实际项目上线后，在红包活动未正式使用前， DDB确实出现过短暂的故障，而兜底方案也在这时排上了用场。所以，无论可能性多小，都需要确保做好应对的方案。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者李丽品授权发布。