(转载)阿里蚂蚁2022GBA背后的测试技术发展
阿里蚂蚁2022GBA背后的测试技术发展
[编者注：这篇文章很长（8998个字），但作者用心良苦，基于44个GBA Bug的分析，几乎让我们获得了软件测试工程师一生职业生涯中所需的经验、找Bug所需的技能，值得慢慢阅读和体会，然后记录下对自己有用的要点。]
前言
这个文章也是欠了大半年了，现在想要出来还账了。熟悉我的测试同仁们，应该都记得我在12年前分析过淘宝GBA的近100个优秀提名bug，从中分析总结出互联网测试模型（《探索式测试实践之路》里面有详细的内容），指导测试工程师在某些特定场景下进行异常场景的测试设计，发现那些隐藏深处的bug。
GBA活动在阿里和蚂蚁运转了10多年了，这个GBA奖项是测试工程师返璞归真寻找测试价值的荣耀，背后代表的是测试工程师的在测试过程中体现的测试技术深度和广度。如今10多年过去了，测试技术和测试平台都有了非常大的发展，那么从GBA的优秀bug也同样看出来阿里蚂蚁的测试技术发展以及当前的核心测试技术。
GBA 概括
GBA 全称是 Golden Bug Award，简称 “金 BUG” 奖。由淘宝测试团队开创，后推广至阿里和蚂蚁。众所周知，发现产品项目的缺陷是我们测试工程师所从事最频繁的日常工作，如何发现定位缺陷也是我们测试工程师的基本技能，所谓技能自然就有高低优劣。如果你能够发现别人发现不了的 BUG，或者在挖掘 BUG 的方法策略上更加有效，那就证明你的能力更胜一筹。设立 GBA 这一奖项的目的，正是为了体现测试工程师的这一核心价值能力。我们一贯认为，GBA 是测试人员的个人最高荣誉，重要的 BUG 价值堪比黄金，GBA 大奖也的的确确就是纯金制作的奖品。
2011 GBA回顾
简单回顾下从2011年GBA提名bug分享总结的一些关键点，发现优秀bug 聚焦在异常测试场景的设计和测试执行上（多并发场景、功能安全、数据库异常等），绝大多数是靠手工测试发现的；5%的bug是靠某些工具平台支撑发现的；整体上来看，这些优秀bug 是站在测试工程师优秀的异常场景设计和坚韧不拔的测试执行上（非必现但是测试执行过程复杂）。
2022 GBA基本情况
由于阿里蚂蚁的BU特别多，各个业务线也特别多，所以2022 GBA 按照每个BU维度进行了GBA评选，阿里蚂蚁44个BU，产出了44个GBA Bug，覆盖了所有不同的业务和产品，这44个GBA bug代表的是阿里蚂蚁是如何判断优秀bug的，代表的是阿里蚂蚁测试工程师是如何发现优秀bug的，代表的是阿里蚂蚁测试技术的关键点和方向。由于这些bug背后的业务和产品都很复杂，笔者个人也并没有做过多的深入了解和分析，期待能找到一些共同点以及启发（虽然很难，尽力而为）。
2022 GBA 揭秘
2022 GBA揭秘之一 - 流量录制回放技术大放异彩
44个BU级别GBA bug中，有14个Bug （其实比例是非常高的，笔者在分析过程中也有点惊讶）是利用流量录制回放或数据对比的方法发现的，为什么是通过这个方法发现的呢，通过这个方法发现的bug基本上是在系统重构类或数据迁移类的项目类型中的。做过业务测试的同仁们应该知道这两类项目的测试难点和重点在哪里，很多时候靠经验靠人肉去解决，现在有了流量录制回放或数据对比的方法后，测试执行效率提升了很多，发现bug的效率和bug的深度也会提升很大。
那么，这里面的测试技术的难点到底是什么呢？测试工程师需要开发相应的流量对比或数据对比的工具（通用的接口流量对比能力除外），同时还需要在白盒角度来分析出可能隐藏的bug，还要不断的重现这个bug，和开发讨论这个bug情况和存在的原因等。
那么，如果是单纯的利用工具发现bug的，那么针对其他测试工程师来说启发是什么呢？这些bug往往是通过某一种测试方案来发现的，可以发现很多类似的隐藏bug的，这里总结几个要点，比如：发布类、迁移类，不可穷尽的测试场景下提供了一种尽可能提升测试覆盖率的方案；比如：新引擎上线后的迭代开发的灰度验证中；新老接口的正确性最好的方案就是新老对比等。
总结来说，基于对历史线上问题、故障的review分析，可以发现：问题都是暴露在一些复杂组合甚至极端的场景中，也就是常规分析测试手段较难命中的；测试场景均为场景量大不可穷举或很难全部验证覆盖或数据构造难执行难的场景，场景case量大不可穷举、难以完全执行验证、难验证难构造、且有历史流量/数据、有比对基线，在这些背景下，都可以采用基于线上数据仿真造流回放来完善测试验证。
基于线上数据仿真造流回放，有以下几点核心优势：
- 效率高：借助仿真基建，在测试阶段成功回放完成X亿流水数据，重现了线上用户已有操作场景和链路。
- 可复用：仿真造流，可沉淀可复用为常态化测试验证能力，后续将沉淀为数金仿真造流平台的测试资产，来丰富并完善全流程全阶段的测试验证及回归能力。
- 通用性：在某些分布式架构体系或多主体多架构部署体系下，通过造流、引流进行仿真回放可完善为常态化质量验证手段。
大家都知道流量录制回放在阿里蚂蚁是应用最广的测试技术，也是传统自动化测试的升级版，那么是不是说传统自动化测试就没有任何价值和使用了呢，并不是。在44个GBA bug中，我们发现有3-4个自动化测试发现的优秀bug，这些bug从发现角度来看难度并不大，但是从问题复现和问题确认的角度来看难道比较大，涉及到很多开发技术的了解（引擎、Blink、灰度切流、多线程实例），同时也需要强调的是这些自动化测试场景并不是独立的单接口的自动化测试case，而是全链路级别的自动化测试case。
另外需要强调的是针对多线程并发角度总结出更多的经验，研发同学在开发过程中，如果使用到ThreadLocal必须及时remove清理，最好能在框架层面afterExecute中执行remove，避免遗漏。但是更加建议的方案是，在每次使用ThreadLocal前，还是要再评估下，是否这才是更好的实现方案，尽量不要把坑留给后面的人。所以测试工程师要把全链路自动化用例做全做厚，所谓做全，就是产品和场景的覆盖度要做到核心100%覆盖，所谓做厚，就是场景的校验点要做到全分支覆盖校验，校验点的细度要精确到每条落库的数据。
2022 GBA揭秘之二 - 专业领域测试工具精准出击
阿里蚂蚁的业务特别多，不同的业务会有自己业务特点的测试工具，这次44个GBA bug中，我们发现有11个bug是通过专业领域的测试工具发现的。这些bug涉及到的业务领域包括视频直播、安全、算法、搜索、大数据等，涉及到的开发技术包括Dataworks、ODPS SQL、Hologres SQL以及PyODPS 3种数据开发形态；同步调用受理+异步回调通知；分布式锁组件，并发锁、幂等、状态锁表、语音识别、HTTP2.0等。
那么，这里面的测试技术的难点到底是什么呢？和使用流量录制回放工具类似的，测试工程师需要开发针对这些业务特点的测试提效工具，同时还需要在白盒角度来分析出可能隐藏的bug，还要不断的重现这个bug，和开发讨论这个bug情况和存在的原因等。
那么，如果是单纯的利用专业测试工具发现bug的，那么针对其他测试工程师来说启发是什么呢？同样的，这些bug往往是通过某一种测试方案来发现的，可以发现很多类似的隐藏bug的，这里总结几个要点：
1）在支付业务中，无论领域内模块交互或与外部交互上，“同步调用受理+异步回调通知”是典型；更优的验证方式是对上锁事务做延时模拟或异常抛送，后续也考虑对该类验证做常态化和工具化。
2）直播专项测试设计和评测能力，开发测试工具模拟高码率的推流场景，发现卡顿问题。
3）一些大型项目中的一些可测性问题，提前思考测试思路，指定好测试方案，提前沉淀自动化工具，方便测试进行时及时发现问题，提高测试效率 。
4）当业务存在表a数据状态强依赖表b数据状态推进时，单表加锁处理逻辑复杂且影响性能时，可以采用下述普适解决方案，使业务并发异常逻辑处理更简单高效。
普适解决方案：前提：当业务中a流水状态推进强依赖b流水状态推进至终态；b流水业务逻辑有系统重试逻辑；a、b表加行锁影响业务功能或性能时解决问题：a、b流水并发幂等锁逻辑如何处理解决方案：新增一张逻辑单一且数据简单具备幂等能力的锁表，标记a流水状态推进的状态。当锁表数据为非终态时，认为业务请求或系统重试请求为重试逻辑；当锁表数据为终态时，认为业务请求为幂等请求做合理的拦截处理（性能要求高时，锁表可加缓存）
这里可以看出来的是为什么阿里蚂蚁需要的是测试开发工程师了，在做这些业务测试过程中，必须要掌握开发的能力，同时需要有熟悉该业务对应的开发技术的能力，熟悉该业务测试难点和重点的能力，笔者在分析这类型的GBA bug时，惊讶于阿里蚂蚁的测试工程师的技术能力和分析能力、通过技术手段解决测试难点的能力。
2022 GBA揭秘之三 - 性能测试问题脱颖而出
回顾下11年时的GBA bug没有一个是性能测试bug，但是这次44个GBA bug中，我们发现有8个bug是通过性能测试发现的（包括专业领域的性能测试工具）。这里也可以看出，这十几年来，业务的变化和架构的变化，至于哪些变化，可以参考《互联网测试转型之乐与悲》，针对性能测试的要求以及稳定性要求也有很大的变化。
那么，这里面的测试技术的难点到底是什么呢？一方面是专业领域的性能测试工具开发，另外一个是关联的开发技术更多，要了解的深度也更深，包括Service Mesh，Golang，time.Sleep；混合云、飞腾2500芯片、底座元数据库；网关接口协议；云原生底座、Redis的mset刷缓存、Redis 配置；ArrayList，LinkedList等。
那么，如果是单纯的做性能测试发现bug的，那么针对其他测试工程师来说启发是什么呢？这些bug往往是通过建立业务特点需要的性能测试方案来发现的，这里总结几个要点：
1）性能测试中，可以使用全链路排查能力对压测流量接口服务链路数据的采集，最大程度的保留压测期间的流量响应数据，快速定位到某个场景存在性能瓶颈；容量评估过程的建立一套可沉淀、可复制的资源计算方法，建立业务压测容量模型。
2）测试在压测过程中需要进行核心链路和功能回归来验证功能的稳定性；在特定场景且系统达到一定水位后才能爆发的问题，发现问题需要具备一定的探索性能力。
3）性能测试常态化运行，日常自动地把镜像交付、压测场景执行、报告整理、问题追踪等环节流水线化；代码评审环节下，需要定期地分享典型案例，因为专家也需要成长积累，不断补充代码扫描规则是沉淀专家经验一种手段。
4）压测问题定位前建立“施压端-服务端”的全链路可观测机制，尤其是自研施压平台，分库分表规则不可以有热点不均衡数据（字段避免使用xx账号），避免因流量不均衡诱发业务性能或者稳定性问题，关注网络IO瓶颈，如带宽占用、TCP发送/接受缓冲区是否堆积等等。
性能测试在阿里蚂蚁是测试开发工程师的必备技能，特别是在系统重构类的项目测试过程中，在开发技术、业务场景、编码能力的驱动下做好性能测试并不是一件很难的事情，笔者在分析这类型的GBA bug时，再次惊讶于阿里蚂蚁的测试工程师的技术能力和分析能力、通过技术手段解决测试难点的能力。
2022 GBA揭秘之四 - 测试攻击手段百花齐放
笔者在分析44个GBA bug过程中，由于个人情感，一直想看到是因为超高的测试设计技巧然后通过手工探索式测试发现的优秀bug，也想看到通过其他测试手段发现的优秀bug，也想看到需求阶段或设计阶段发现的优秀bug。幸运的是，我看到了这些bug，这些bug代表的是测试工程师另一个角度的软能力，包括批判性思维能力和错误推测能力。由于这些bug 非常宝贵，接下来会花更多篇幅来详细说说这些bug。
通过探索式测试发现域名跳转和跨站跟踪bug
这个bug是通过不同的浏览器来测试某个业务场景在域名跳转和跨站跟踪的链接是否正常时发现的，发现过程：使用safari 浏览器进行测试，pc和手机上的浏览器 都有问题（最新版的iphone系统默认开启了safari的阻止跨店cookie），发现 safari、chrome浏览器具备可屏蔽跨站跟踪能力，其中safari13.1版本之后默认开启屏蔽，chrome目前非自动开启。
在浏览器兼容性测试时候，测试工程师需要熟悉浏览器安全特性的默认配置；跟浏览器安全隐私策略有关，可以手动打开和关闭；这个bug是在浏览器安全隐私机制升级导致的。从该bug发现和确认问题过程中，bug发现者通过多个浏览器版本和不同配置探索出隐藏的问题，同时总结一些测试执行过程中需要具备的品质：
- 发现问题时：对任何疑点绝不放过，要有怀疑精神。
- 定位问题时：不怕困难，对出现的问题追查到底，抱着解决问题的态度找外部合作的开发一起排查。
- 解决问题后：契而不舍，精益求精，推动合作的开发寻找最优解法，思考出可复用的测试能力。
通过代码故障注入发现多线程并发bug
这个bug是出现在系统重构类的项目中，bug发现者在项目上线前，梳理系统核心流程，评估内部实现隐藏风险；对代码行进行故障注入，使得updateOnlineTouch方法超时，未执行方法逻辑，从而发现bug。
从这里可以看出，bug发现人非常熟悉系统代码实现，也善于从代码角度来测试和验证异常逻辑，给我们的启发就是：对系统核心流程做风险评估和异常测试，必须是详细设计，甚至是代码都熟悉；利用故障注入来验证自己的猜测；数据一致性问题值得关注，系统要有自恢复能力。
通过异常模拟发现多线程并发bug
这里有2个GBA bug都是这个类型的（多线程并发的问题是互联网产品场景下常见的隐藏bug），也是彻彻底底的手工功能测试发现的bug，非常类似于12年前的GBA优秀bug，发现过程是bug发现人设计异常场景，类似于多账号同时登录或操作，多线程并发情况，发现功能安全问题或多线程超时异常问题。
这个bug可以成为GBA bug的原因是这个安全性的问题具有隐蔽性和比较难发现。给我们的启发就是：测试工程师要敢于从不同的角度去尝试，比如站在异常用户的角度，怎么让卖票的时候出现同一张票超卖的情况，一张票能变成2张票，从而找到问题的突破点。
安全场景监控和覆盖，因此质量保障同学除了常规的功能测试，也需要从安全方面入手，用例设计阶段需要考虑到安全场景。
另外就是针对并发场景下子线程数据独立存储的技术方案，可以进行数据一致性的风险评估，包括如下几个点：测试前进行正常场景和异常场景的分析，尽可能全的覆盖业务；测试阶段能够借助工具模拟各类异常场景的复现，达成测试预期；独立分析业务上可能的资损场景，推进行开发建设线上资损核对监控，以防测试遗漏。
通过bug fix code分析发现更多bug
这个bug是在某个业务的常规迭代过程中，最初bug发现者的测试场景是新人首单下单后并取消订单，这时发现用户依然是老客，定位发现没做取消订单的人群移除逻辑，于是提交bug，研发增加了取消订单的老客人群移除逻辑，并验证通过。
接下来bug发现者通过了解开发fix bug的逻辑，和看代码，了解可能存在的问题场景，然后测试执行，发现另外两个问题。给我们的启发就是：在修复了一个正向bug的时候，要考虑是否引入了其他方向的隐藏问题，使原本的小问题变成了更大的问题；除了发现功能问题外，也要发现性能稳定性的问题，例如下单场景的无效查询，查库改缓存查询等。
熟悉我的同仁们应该看过我很早就提过的测试经验之一就是多看bug fix后的code change，看不懂也要看，看不懂你就问开发，总有一天你会看懂的，你会发现code背后隐藏的bug的，那个时候开发给你竖起大拇指的时候，就是你的测试价值体现更完美的时候，这个时候，你还担心测试没有未来吗，你还担心你不涨工资吗，你还担心你不能年薪百万吗：）。
通过技术方案设计异常场景发现一致性bug
测试左移的重要性和实践之一就是能从技术方案中找到可能存在的问题和风险，然后设计测试场景证实系统这样实现是否存在问题。这个bug发现者必须熟悉重试、dubbo远程调用、分布式锁、幂等 等技术原理，同时结合业务场景发现了这个隐藏bug，给我们的启发就是：
1）首先需要关注设计的合理性，其次是这种改造可能带来的问题是什么，以及对应的解决方案， 上游业务批量操作时，需要了解下游的分布式琐机制，更要避免由于分布式琐导致的数据不一致问题。
2）从测试设计来看，需要从技术方案识别的问题去设计测试方案和用例，这个问题里需要关注最终一致性和性能。面对数据不一致，需要加强资损对账校验；对于幂等问题，需要了解应用间的幂等处理结果，是返回成功，还是返回异常。
3）在提测前，先评估是否会会存在并发场景，确定并发的技术实现方案是缓存系统分布式锁还是数据库乐观锁，再根据不同锁实现方式check可能存在的问题，最后通过并发测试执行来确定问题。如下是来自于bug发现者的总结思考：
针对大多数测试工程师来说，测试左移的实践在需求阶段通过RBT可以得到一些比较好的结果，但是在设计阶段的实践和效果必须有开发技术能力的支撑，这也是测试工程师需要思考怎么才能在业务知识和开发技术做到平衡，在测试左移中发挥应有的价值（尽管这些价值和开发测试工具比起来相差甚远，但是TA会更加贴合你的测试初心）。
通过技术方案评审发现设计bug
大家都知道，不同的阶段发现的bug带来的修复成本是不一样的；我们鼓励在测试执行之前发现更多问题，测试工程师通过分析技术方案的实现逻辑发现设计上的问题是很赞的。这个bug发现者在参加常规迭代过程中某个需求的技术方案时，并没有完全信任开发人员选择的实现逻辑，而是主动去分析和技术调研，提出了另外一种更好的实现逻辑方式，且更适合当前业务的特点，最终开发采纳和认可了这个方案，降低了开发实现成本、系统的复杂度和维护成本；做测试的成就感和幸福感满满的：）。
这个bug发现者也思考了更多问题，比如：
- 需求分析过程能不能抽象出来？这样就可以让大家都可以复用这个模型发现这类问题？更进一步的话是不是需求调研阶段就可以排除掉这类bug？
- 研发流程规范上有没有什么可以优化、改进或者借鉴的地方？优化后如何落地？落地后如何通过数字化的方式度量？
- 测试工具也好，研发流程也好，都是为了回归到业务上，那么我们应该如何去思考和看到我们的业务？
这三个问题，本文就不给具体的答案，也期待大家自己的思考；针对测试左移的具体做法，不同业务会有不同的执行策略，该bug发现者也总结了电商业务下自己的评估模型，经bug发现者同意，本文分享这个模型给到大家做一个参考。
这个模型适用于哪些用户和场景呢？
1）刚入职的开发同学对变更比较随意，场景举例：别的域的同学说“你只要实现123就可以满足需求了”，开发同学照做；（这个时候别的域的同学的身份相对来说是专家视角，让专家熟悉咨询者的业务是不现实的，因此就需要咨询者结合自己业务实际情况来充分调研，而不是给什么就用什么）
2）刚入职的测试同学不太了解业务，场景举例：开发说“这个我只改了这几个改动点，你只要测试123这三个场景就可以了”，测试照做；
3）熟悉业务的开发和测试同学担心有疏漏，可以借用这个模型来double check 下需要重点关注的点思考过程中是否有遗漏。
4）身经百战的研发和测试大佬们，目前我提出的这个模型更多的还仅仅止步于一个概念模型，如果能将它的每一个节点能够产品化、可度量的话，这样的测试左移产品一定是非常有意义和价值的，感兴趣的话大家可以一起探讨和推进下。
这个bug案例也说明了在研发流程中测试工程师参与的必要性，虽然这是一个日常的小需求，但开发同学在需求评审阶段就拉了测试同学来评估，遵循了所有需求无论大小在需求评审阶段一定要过测试同学，让测试左移发挥作用，将问题很好的控制在了开发之前，减少了开发资源的投入和返工。
在很多互联网企业，特别是开放测试比很高的公司，很多看似低风险的小需求开发人员直接自己评估，直接发布上线的，这种情况就是绕过了测试在需求评审阶段的测试左移作用，直接投入开发，如果有问题很容易导致返工，更为严重的是如果发布的时候正好没有测试卡点审批的话，很容易产生线上故障。
2022 GBA 总结
阿里蚂蚁的所有测试工程师每年至少发现数十万个bug，这44个GBA bug只是其中的一些典型代表，TA能说明一些关键点，也不能说明一些结论；从以上的揭秘章节，再结合2011 GBA的bug特征，相信大家能体会到阿里蚂蚁的测试技术发展的几个关键点，包括如下：
1）利用工具发现的优秀bug更多了。2011 GBA的bug 基本上只有手工测试发现95%，工具发现5%的比例；而到2022 GBA，手工测试发现10%，工具发现90%的比例（当然2022 GBA的bug基数只有44个，充分性不足）；大家从这里看出测试技术的发展和开发技术的发展的融合了吧。
2）自动化测试一直是主旋律。互联网敏捷研发和敏捷测试、云原生作为大的背景，都对自动化测试提出了更高的要求，自动化测试框架也经过了一代又一代的迭代和更新，当前主流互联网产品业务是流量录制回放为主要手段、再辅助全链路接口测试，当然了，还包括各种端上的自动化测试。
3）性能压测和分析能力是标配。业务的发展、技术架构的演进都需要测试工程师具备性能压测和性能分析的能力，特别是在复杂业务复杂架构下，利用性能压测工具或专业领域开发性能压测工具进行性能压测和性能分析。能做到这些背后的支撑就是开发技术和系统架构的理解。
4）bug分析能力大幅提升。大家都知道测试的核心职责是发现bug，确认bug；定位bug和分析bug原因、甚至给出bug解决方案都是开发的活。道理是这么个道理，但是如果测试工程师想在技术上有更多积累，想发挥更大的价值，想多发现更多隐藏的bug，强烈建议多做定位bug和分析bug原因、给bug解决方案。笔者在看2022 GBA bug时候，发现很多bug发现者在定位bug和分析bug原因、给bug解决方案都做到了非常多，很多技术细节都清楚，甚是惊讶。
5）测试左移效果会更加明显。测试左移和测试右移都不是什么新鲜的话题了，很多公司都在实践这两块内容，但是在实践过程中能踏踏实实的做的，做的效果好的，得到了产品和开发的认可的，真的不多。从2022 GBA 可以看出阿里蚂蚁测试工程师在技术方案评审和分析中发现了很多风险和问题点，且通过自己的技术能力证明自己的猜测，做到这些真的是不容易的，也相信阿里蚂蚁的很多测试工程师都具备这样的能力和case。
总体来说，测试技术发展是驱动质量保障体系发展的重要因素，这里面还有质量门禁体系、全流程质量保障、各种服务化工具和智能化工具。
后记
最近几年大环境不好，各个业务单元都在走经营责任制，测试部门相应的拆分到业务研发团队，测试团队相对于开发团队来说就是彻彻底底的成本部门，是优化成本的第一优先级，所以测试工程师的前途和发展前景都堪忧，在这种大背景下，测试工程师在业务测试的打磨上，会更加聚焦业务价值本身、产品用户体验本身（业务竞对分析、体验优化、长尾问题挖掘）、产品质量本身、测试执行效率本身。而这些工作让测试工程师找到自己的核心价值，找到自己的生存之本，找到自己的测试初心，找到自己的未来方向。
熟悉我的人都知道我最近两年离开了测试领域，在SRE领域学习和成长了较多，但是我还是不断的关注测试业界的动态，阿里蚂蚁的测试发展，测试同仁的困惑和发展，我很多时候都在想我是不是就不能离开测试领域（向国外一样，做20/30年的软件测试专家），我是真的太爱软件测试了，对于任何软件测试的理论和实践我都热衷于学习，我感觉我快回来了，回来继续思考软件测试如何更好的做，如何更好更快的建立自己的质量保障体系和质量策略，但道阻且长，请珍惜眼前。
