平台化测试难度大？京东教你如何用无人测试实现产品质量效率双提升

Posted 2020-12-28 msup

本文内容节选自第六届全球软件案例研究峰会，时任京东B2B产品质量团队负责人杨瑾老师分享的《无人测试如何助力京东提升产品测试效率与质量》实录，重点分享：无人测试，创新测试方法论，接口测试案例。（PPT+文稿）。

杨瑾老师拥有10年以上互联网及传统行业测试经验，擅长自动化测试、业务质量测试、性能测试以及持续集成等多领域；行业内资深测试专家，京东测试技术开放日发起人。

编者按：2017年11月9-12日，第六届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读2017年「壹佰案例榜单」。时任京东B2B产品质量团队负责人杨瑾老师分享的《无人测试如何助力京东提升产品测试效率与质量》实录的案例分享。

 

【内容简介】随着业务的发展，系统平台化势在必行，但每一个改动都代表着大量的回归工作，在这样巨大的工作量下，人工测试不能够保证测试百分百的成功。京东团队通过创新测试方法论，实现了质量与效率的双双提升，直接省略测试环境的接口测试成本；通过自动化预发环境完成测试，预计提升测试效率60%以上。

 

1

实践背景

 

随着京东B2B业务发展进入高峰期，开发与维护成本也相应的提高了许多。需求的增长迫使研发团队必须改变以前的系统架构，提高效率。

 

所以，平台化势在必行。

 

平台化测试痛点

 

1.巨大回归量 

平台化之前的系统架构简单，每个系统有自己完整的交易流程。而现在要把十几个B2B业务线的共性抽离出来重构。在这样的变动后，回归量无疑是十分巨大的。

 

而且出于成本控制和业务压力两个方面，团队必须要做到在有限的资源下既支持平时业务需求测试，还要更好的保障平台化的工作量。

 

2.牵一发动全身

以交易平台为例，从下图可以看出，交易平台基础服务众多。测试前，我们首先要做策略设计。交易平台的基础服务，像MID、OC，分别做了查询、下单、封装、校验、数据同步、搜索、分页，如果测试重点放错，就会变得十分复杂。

 

 

对上的业务系统和对下相同，都是以接口的方式反馈数据。我们在与研发沟通读写接口的关系时，发现在整个交易平台接口的比例中，写接口比例很少，且测试简单。但读接口测试步骤十分繁琐，不仅数量大且必须要和以前的接口反馈的结果做对比。

 

3.牵涉细节太多

如下图，上面为老系统测试接口，下面为新系统逻辑。

 

在新老系统重构时，老系统存钱单位是分，取时单位是元，重构时虽然将单位统一成了元，但是由于数据迁移过程中，接口层逻辑处理出了问题，导致新系统中取出的钱比实际高了10倍。

 

 

这样的例子在平台化过程中还有许多。大多是因为参与的人多，半途中临时加进来的资源也很多，很难从头到尾，方方面面的了解研发在每个过程中做了什么事情。

 

这是团队测试中遇到的一个难点。

 

 

2

解决方案

 

之前存在的问题总结下来为：

• 功能回归耗时过长，有漏测的可能。

• 依赖人设计，编写，维护以及过程间驱动。

 

解决方案前后

解决方案前：

 

1.团队会先梳理平台化过程中有多少个接口需要被测，明确测试对象。

 

2.测试人员开始做不同场景下的用例测试，设计不同参数保证场景反馈数据是正常的。

 

3.在工程里用页面测试工具，以设计好的用例来做接口测试，激活反馈结果。

 

4.将结果与老系统数据作对比，结果一样可认为重构是成功的。

 

评价：

• 对人的依赖太强，有漏测可能性：例如在重构过程中大量的业务线融合在一起，对于团队来说比较陌生容易漏测，在用例设计时也会产生一定的风险。

• 测试效率低，测试成本高：人工对比容易产生误差且耗时长。

 

 

解决方案后：

 

1.团队梳理平台待测接口。

 

2.记录用户行为，日志打标改造——可以减少由于测试人员业务不熟带来的漏测可能性。

 

3.上线运行，产生大量数据。

 

4.从日志中提取需要数据，如接口方法，入参等，作为测试用例——在这一步里脱离了对测试人员的依赖，提升了用例质量和生成效率。

 

5.在工具里进行对比。

 

6.人工复检——因为机器检查时可能会反馈出时间戳和无用的参数。

 

评价：质量与效率双双提升。

 

读接口自动对比方案

1.研发日志打标。

2.将数据放入京东大数据平台。

3.工具在大数据平台内按一定规则筛选数据。

4.将数据变成用例，入库。

5.测试人员进行配置。

 

 

解决方案中关键点

 

 

1.对比的基准——还原系统线上的真实场景

研发在日志里面按一定规则生成来提供测试需要的数据，这样做不仅可以提高测试效率，还可以激励研发工作动力。

 

2.减少人工干预

无人测试关键在于没有人的干预，但这并不会以牺牲质量或牺牲其他做为代价。

 

 

团队会在多业务线应用内，做一些配置，配置后根据要求将数据同步到大数据平台，随后日志会按照一定规则去提取相应的数据，打造测试用例。

 

3.自动对比

 

测试人员在这其中做了几件简单的事：开发比较简单的平台，实现了配置；应用的配置；环境的配置，规则跳过的配置。

 

 

典型问题 

• Value不一致

  

• 缺少Key

  

• 小数位差别影响对外 API

  

• KEY-VALUE不一致

  

 

 

实践效果

质量上的提升：

在接口处即可拦截问题，有效阻止了上线以后的修复成本。也提高了团队信心。

 

效率上的提升：

1. 零用例设计与编写成本——用例来自于用户真实操作场景，涉及全面且自动生成。

2. 零测试环境执行成本——节省掉测试环境的测试时间。

3. 零预发对比全自动化——对160万以上用例访问并对比返回的思路。

    

 

3

经验总结

 

本方法重点聚焦于测试方法创新与过程改进。

 

 

经验教训：

错误数据太多，无法人工查看每一条错误数据，只能采样抽查。

 

成功要素：

• 测试要善于发现工作中的乐趣。

• 在工作中善于思考与突破，针对团队遇到的问题，有可落地的定制化解决方案。

• 优良的团队文化，多和研发沟通。

• 有一定的测试开发能力。

• 对现有的业务系统熟悉。

 

成功经验总结：

• 测试人员做好规则制定。

• 工具开发以及与研发同步的规则。

• 研发配合做相应的改造。

• 尽早上线。

• 团队达成一致，认可。

 

4

未来展望

 

1. 错误分类智能化，减少此环节人力投入。

2. 加入代码覆盖率分析，可以更直观看到执行后新老版本质量提升。

 

Q&A

 

Q: 什么是日志打标改造？自动化用例生成时自动化数据是怎么生成的？

A: 日志是知晓系统一切的，包括用户在系统里面的任何操作，但是它没有记录，原因是研发没有打日志。我们可以让研发在调接口的时候让日志按一定的格式把接口、方法入参，按标准的输出。

 

Q: 用例生成是相对滞后的，那如何保证新内容、新版本上线的质量？

 A：用例第一次上线是不能用的，因为存在滞后，在第二次上线就可以用了，因为需要有上线运行的版本帮它收集日志。在第一次上线时，只能人工比对。

 

以上内容来自杨瑾老师的分享。