得物致力于打造全球领先的新一代的潮流网购社区。目前境外业务已落地中国香港、意大利、日本等。通过跨境进口，将全球高质量好商品引入中国，通过出口及中国品牌文化输出，帮助国潮品牌走向世界，服务于全球消费者。

2. 挑战

随着公司【国际】业务不断扩展，业务场景和用户需求也在不断壮大。业务形态多样化、复杂性、不确定性增多，质量面临的风险也更加不可预测，同时得物又是一直秉承着提升用户体验，让短板不再短！所以在国际业务不断扩展下如何高质量、高效率的交付是非常关键的，在这样的新形势下，交付高质量的软件面临着更大的挑战，光靠传统的那些质量保障工作无法实现。“质量不是检测出来的”，著名质量管理专家戴明先生的这句名言告诉我们，光靠开发完成后的测试是没法保障质量的，质量需要团队成员一起负责，需要从软件开发的整个生命周期给予关注:

需要左移，关注业务的真正价值，要以业务价值驱动测试；
需要持续测试，需要关注整个交付过程，关注计划安排、团队协作等多个方面，从而实现快速反馈；
需要右移，关注和利用生产环境的数据和信息，对线上反馈问题进行深入分析，以优化和改进上线前的开发和测试工作。

3. 测试左移

测试左移最主要的就是“业务驱动价值测试”，传统的测试是根据需求文档功能进行测试？随便企业对产品质量&用户体验要求不断提高，作为“新时代”的测试人员我们需要转变测试思维从不同的维度进行测试，我们知道“敏捷”这几年在国内非常流行；敏捷交付的是价值，敏捷测试要以业务价值驱动，要以业务价值为目标。接下来我和大家分享下【国际】欧洲测试团队如何通过测试左移进行业务价值驱动测试及其相关落地实践。

3.1 业务背景

“欧洲商品尺码自动转换成标准码”业务需求是通过规则将欧洲商品尺码映射成得物标准化尺码进行管理和销售；减少运营人力成本投入，减少由于尺码原因造成的重复以及误上架和退货。

3.2 业务价值

“业务价值”：指的是不仅仅是关注需求的功能，更重要的是关注业务需求、业务实现的价值，这样才能更好的帮忙我们进行测试。以下是该需求业务价值：

提高商品匹配效率，减少运营人力成本投入，减少由于尺码原因造成的重复以及误上架；
通过尺码规则将欧洲买手店商品尺码映射成得物标准尺码进行管理；
减少由于人工尺码映射错误导致用户退货&换货等操作造成资损。

3.3 用户行为

“用户行为”：指的是在思考、设计测试用例并执行测试的时候，不能简单的套用用例设计方法去机械地进行设计测试用例，而是要考虑用户可能的行为习惯、使用场景等。这样在测试的过程中更能接近用户的行为。以下是该需求的用户行为：

用户新增尺码映射规则；
批量导入尺码映射规则；
修改尺码映射规则；
删除尺码映射规则；
尺码规则生效和失效；

上面的场景是用户行为日常行为，也是我们测试过程不容忽视的，根据这些真实场景去测试，把自己想象成终端用户，就能容易发现用户可能遇到的问题；除此之外，还要考虑终端用户的体验，比如说页面的布局、易操作性、等都是在测试过程中需要考虑的因素。

3.4 业务流程

“业务流程”：指的是测试过程中把系统的质量状况跟业务紧密关联够识别出业务需求给系统带来哪些价值&影响；以下是本需求业务流程：

全量/增量商品 -> 查询尺码映射规则 -> 买手店商品数据处理
新增尺码映射规则 -> 尺码映射规则落库 -> 刷新买手店全量商品数据
尺码映射规则变动 -> 尺码映射规则落库 -> 刷新买手店全量商品数据
类目/品牌/性别映射关系变动 -> 查询尺码映射规则 -> 刷新买手店全量商品数据

上面业务流程都是我们测试的重点，业务流程的改动是否涉及到历史逻辑变更、已经业务上面后是否都其他需求造成影响、影响面有多广都是我们测试的重点。

3.5 业务影响

“业务影响”：指的是与业务流程不一样的是，业务影响是具体落到业务的功能点上，区分优先级，能够识别哪些是关键业务测试点和外围业务测试点。以下是该需求业务影响：

全量/增量拉取商品查找尺码规则，按照该尺码映射规则映射商品尺码信息
新增尺码映射规则历史数据处理

商品已出价
人工修改尺码
spu/sku推荐匹配

映射关系变动

‍类目映射
品牌映射
性别映射

‍3.6 业务指标

“业务指标”：指的是在度量项目、产品质量的时候，不能仅局限于项目、产品范围，要跟企业的业务指标相关联、跟踪、量化、测试活动对业务指标的影响，这个维度是非常重要的。在得物【国际】域测试团队版本发布非常关注的业务指标有：

冒烟通过率
准时提测率
bug日清率
......

3.7 小结

传统测试主要集中在软件开发周期的最后，即提测后进行集中测试，测试左移的目的就是为了更早的澄清和理解需求，确保团队清晰一致的理解需求的业务价值，做正确的事情。同时左移的目的也是为了实现测试、产品、研发并行减少等待。

4. 业务质量保障实践&持续测试

持续测试（或者敏捷测试）要求测试作为基础活动贯穿于软件交付的整个过程中。相比传统测试模式，持续测试通过尽早定义测试、测试与开发并行、在研发过程中保持紧密协作，从而实现快速反馈业务风险的目的：

测试分析&测试策略
高效的自动化测试
覆盖率分析，精准化测试

4.1 测试分析&测试策略

测试分析&测试策略和软件测试方法不同，软件测试方法指的是一种具体的对软件进行检验的手段，而测试分析&测试策略则是针对不同需求、不同阶段应该关注什么，或者应该如何合理制定不同测试方案和计划。

4.1.1 涉及的库表&MQ

在微服务和分布式系统中程序中的数据交互主要是靠数据和消息队列，从另外一个角度来说数据库&MQ的分析对测试也是至关重要的；下面是我们提到的“欧洲商品尺码自动转换成标准码”数据库&MQ分析：

从表的表新增&和表字段的修改可以识别对业务的影响以及测试关键点；

新增表：merchant_xxxx_xxxx、merchant_xxxx_xxxx_rule

尺码映射规则处理

表字段变更：modified_size、modified

全量商品页面搜索
Elasticsearch全量数据同步

```
【MQ】# 无MQ新增&变更
```

4.1.2 研发设计方案

冰山理论：实际上是一个隐喻，它指一个人的“自我”就像一座冰山一样，我们能看到的只是表面很少的一部分行为，而更大一部分的内在世界却藏在更深层次；研发过程中也是一样的，如果我们不去了解研发是如何设计方案是很难全面的进行测试，在测试分析阶段对研发方案进行分析可以提前识别方案的是否合理以及如何进行测试以及测试数据准备工作。测试分析阶段我们不仅仅要和研发设计方案对齐同时还要熟悉接口定义、测试数据准备、自动化测试脚本准备等。

研发设计方案对齐
测试用例设计
测试数据准备
自动化测试脚本开发

4.2 高效自动化测试

越来越快的交付速度，带来的最直接的影响是代码质量和产品质量的影响。更令人尴尬的是，其中超过30%的关键生产问题首先由最终用户或客户报告。步入高效时代，开发团队要如何在提升速度的同时保证软件质量，从而保证用户体验和产品质量？答案就是高效自动化测试。

4.2.1 自动化测试VS手工测试优势

更快的反馈循环

当测试团队成员同时负责多个需求执行功能测试回归测试，如何快速向开发人员提供反馈，以及开发人员提交bug修复的代码测试人员快速验证，这是手动测试无法完成的。

增加测试覆盖率

在迭代测试过程中如何精准有效的评估测试，其中最重的手段就是覆盖率，通过自动化测试能够快速提升代码覆盖率。

减少测试疲劳

减少重复执行。

更快发现错误

自动化测试允许将测试转移到开发周和开发并行，能快速发现问题，这可以帮助做出更好的决策，以减少时间和成本投入，而不是在软件开发后期才发现问题，那将会付出高昂的代价。

测试更加高效

测试和开发能够并行，减少等待；
回归阶段能够快速进行验证。

给手动测试留出时间

可以给手动测试留出更多的时间，去做探索性测试和业务价值驱动测试。

4.2.2 实现方案

自动化测试一直是敏捷迭代和敏捷测试的重要基石，也是 DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同，以及各种不同的限制，导致需要的自动化测试框架和工具也不同。得物【国际】欧洲测试团队自动化采用Java+SpringBoot+Junit5框架融合而成。

（1）设计思想

（2）创建脚本

自动化编写的过程中为了降低自动化用例的维护成本，通过Java反射和注解特性统一制定编写规范。

（3）测试执行

（4）测试报告

（5）缺陷跟踪

4.2.3 全流程自动化

4.3 代码覆盖率分析

代码测试覆盖率是一种度量，它描述了对程序源代码的测试程度，是白盒测试的一种手段，能够直观暴露测试用例无法覆盖到的代码块。作为提升代码质量的利器，得物【国际】团队在迭代测试过程中如何结合手工测试&自动化测试等充分结合代码覆盖方面做了一些探索性的尝试与实践。

4.3.1 冒烟测试

我们常常在讲测试左移，不仅仅是关注需求的业务价值，在研发阶段我们需要和开发实现并行，传统的测试一般是版本提测后测试才介入测试、了解研发设计、收集接口信息等测试左移在研发阶段就是要提前介入测试，对齐研发设计、编写自动化用例等，因此冒烟测试阶段通过自动化的方式能够快速验证版本提测质量：

开发周编写冒烟自动化用例
版本提测执行冒烟自动化用例

在执行冒烟自动化用例后，可以快速查看到冒烟用例的通过率和代码覆盖率。

4.3.2 一轮测试

在冒烟测试通过后一般会进入一轮测试，一轮测试需要针对需求更加全面测试，在一轮测试过程中常常会重复执行功能测试用例和验证bug以及部署，部署后台由于研发修改了代码，对代码覆盖率有要求的项目就会要重新覆盖代码，这对迭代人力投入是非常大的挑战。那如何在迭代测试中减少人力投入，自动化是必不可少的手段。

（1）手工测试

在经历冒烟测试&一轮测试后，整体代码覆盖率达到50%。

（2）缺陷修复

在一轮测试过程中研发bug修复后，代码覆盖会急剧下降，这时候需要重新研发bug和覆盖代码，这样就会导致很多重复性操作和投入更多的人力，其实这块完全可以用自动化替代掉。

（3）自动化测试

在缺陷修复后，可以通过自动化的方法快速验证缺陷是否修复，同时对代码进行覆盖。

（4）探索式测试与测试自动化

自动化测试在目前得到了越来越普遍的应用，自动化测试的优势也越来越明显。然而，自动化测试毕竟考虑时间有限，并且受到了一定的测试思想的制约，不可能在一次的测试设计中就能够就能够设计得很全面。而对于异常流程往往考虑得不是十分的充分。对于一个有经验的测试工程师来说，bug往往在处理异常流程的时候被经常发现。

所以如何全面的设计用例就需要结合研发代码覆盖率进行分析，再以自动化测试脚本作为支撑进行探索性测试。保证一个产品好的质量，既要依赖自动化测试工具，另外人工为主的探索性测试也不可以遗漏，这样软件的质量才可真正得到保障。如下所示结合代码覆盖率和自动化测试，不仅覆盖达到了要求同时质量也得到了保障。