猪小花1号

个人签名

282篇博客

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

猪小花1号2018-08-29 09:12

一: 项目的背景

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

二: 项目难点分析

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

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

三. 项目过程

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

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

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

1. 制定的项目流程一览

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

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

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

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

  测试手段分析:

3. 接口提前实施

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

用例类型

功能测试用例

平均单个用例执行时间

测试时间总计

自动化用例数

回归执行节约的时间

前端用例

42

5分钟

3.5h

0

0

下单计算用例

99

15分钟

24h

83

21h

回归用例

40

10分钟

6h

40

6h

优点:
  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位, 当活动税费减免出现四位小数时,两边不完全想等导致校验不通过。
实际中我们的用例中已包含该类场景,但是商品数据不够丰富,没有

Bug规避措施总结:1. 创建竟可能多的数据去模拟线上可能存在的场景, 通过自动化用例去模拟。当然该方法实际上比较需要时间去积累。
2. 通过逆推校验公式去创建合适的测试数据:即针对程序中存在的金额校验公式,在脱离场景的情况下,模拟各种下单金额。
五. 项目总结
相对的之前的跨组大项目,红包的线上、线下bug数量较少,测试周期短(包含上线8个工作日),整体质量好, 总结下来主要是因为以下几个方面:
流程控制:
  • 签字单:明确各阶段的产出、明确责任人,开发、产品、QA更加重要阶段的质量。
  • 冒烟质量控制:选取恰当的冒烟用例,开发在自测过程已排除掉大部分的主流程问题。 提测后测试过程流畅,节省大量的以往反复修改bug的过程。
  • 发布预演:提前在预发布进行上线演练, 排除上线过程中可能出现的报警、报错。
新测试方法:
  • 接口提前完成:接口在回归测试前全部完成, 节省了近80%的回归测试时间。
  • 测试覆盖统计:对于评估代码的测试范围覆盖有着非常显著的作用,通过覆盖结果可以评估到测试的遗漏点。
  • 接口健壮性测试:对接口做异常数据测试, 本项目中就通过接口测试法发现一个并发的bug。
  • 随机性测试: 使用随机数据对下单流程做复测,
还有重要的一点就是, 考虑最坏的情况,做好应对方案。红包项目上线后就出现DDB数据库短暂不可用的情况,通过兜底方案,实际对业务并无影响。

可以看到每个工程的代码变更大小,如 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

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