本文内容节选自第六届全球软件案例研究峰会，时任京东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不一致
实践效果
质量上的提升：
在接口处即可拦截问题，有效阻止了上线以后的修复成本。也提高了团队信心。
效率上的提升：
-
零用例设计与编写成本——用例来自于用户真实操作场景，涉及全面且自动生成。
-
零测试环境执行成本——节省掉测试环境的测试时间。
-
零预发对比全自动化——对160万以上用例访问并对比返回的思路。
3
经验总结
本方法重点聚焦于测试方法创新与过程改进。
经验教训：
错误数据太多，无法人工查看每一条错误数据，只能采样抽查。
成功要素：
-
测试要善于发现工作中的乐趣。
-
在工作中善于思考与突破，针对团队遇到的问题，有可落地的定制化解决方案。
-
优良的团队文化，多和研发沟通。
-
有一定的测试开发能力。
-
对现有的业务系统熟悉。
成功经验总结：
-
测试人员做好规则制定。
-
工具开发以及与研发同步的规则。
-
研发配合做相应的改造。
-
尽早上线。
-
团队达成一致，认可。
4
未来展望
-
错误分类智能化，减少此环节人力投入。
-
加入代码覆盖率分析，可以更直观看到执行后新老版本质量提升。
Q&A
Q: 什么是日志打标改造？自动化用例生成时自动化数据是怎么生成的？
A: 日志是知晓系统一切的，包括用户在系统里面的任何操作，但是它没有记录，原因是研发没有打日志。我们可以让研发在调接口的时候让日志按一定的格式把接口、方法入参，按标准的输出。
Q: 用例生成是相对滞后的，那如何保证新内容、新版本上线的质量？
A：用例第一次上线是不能用的，因为存在滞后，在第二次上线就可以用了，因为需要有上线运行的版本帮它收集日志。在第一次上线时，只能人工比对。
以上内容来自杨瑾老师的分享。