最厉害的测试工程师，可以在研发设计评审时发现潜在的bug，提出风险点，而不是等研发已经把代码写好了，部署完了，再用测试的方式去发现这个bug。举两个真实例子。

　　我们为上层业务提供算法算子，算子本身可能有版本；算子则是在下层算子平台部署运行的。

　　原本我们对上层各业务的算子运行资源，是不隔离的；现在要做一定的隔离，避免某一个业务的突发用量把其他人的资源用光。

　　研发的设计稍微有些偷懒，他想要用原本算子平台的版本号能力，例如算子版本1，有5个业务在用，就实用算子平台的版本号，占位1到5。如果算子升级版本到2，就去算子平台占用6到10。

　　我当时就指出，对一个业务来说，想要升级到新版本的算子，首先要等目前流量结束，才能全面使用新版本；想要一次性升级所有业务的算子版本到新版本，肯定不可能。

　　所以必然会出现，你已经提供新版本算子，占位了6-10，但新版算子还不能算是成熟的，老版本算子还是主力的情况。此时如果，一个新的业务线出现，来用老版本算子，怎么办呢？

　　逻辑上要占用6号位，但是6号位已经被新版本占用了，那这里必然就是个bug。

　　第二个例子是个早期的中心化缓存模块。

　　原理上来说，中心化缓存是用redis实现的，但当时redis还没有很多高级功能，很多都是自己实现的。

　　当时的设计是，中心redis对缓存维护过期时间，接受外部其他集群的使用（读写）。

　　此时我们遇到一个问题，就是写缓存操作可能因为网络问题而失败。于是研发设计了一个机制，就是在本地写失败之后，存入本地暂存区，等服务重启再次尝试写入，或者间隔一段时间异步写入（这里没法做同步写入，是因为那个业务线程不能等你的缓存写入成功，网络失败的情况下，重试写入是阻塞性的）。

　　看起来很美好，但实际上问题很大，因为你过了几个小时之后的异步写入，对同一个key来说可能是旧数据，等于是你可能用旧数据覆盖新数据。所以我们必须要维护一个版本号的概念，低版本号的写入无法覆盖高版本号，才能保障一致性。

　　除此之外，厉害的测试会进行一定的自我排查，以及让bug复现路径更具备可排查性。

　　例如，当发现页面报错时，我们可以先看网络请求中哪个接口有问题。我可以先从日志当中排查出这可能是哪里的问题。

　　举个真实的例子，最近一次，忽然发现某个存储空间无法上传图片了，这是个p0的问题。但是我关注到其他空间没有这个问题，所以此时我们要提供这个空间与其他空间的差异。

　　对比发现，这个空间其实是本周内新建的。所以，bug应该是本周以内的代码引起的，影响的是新建的空间。（后续排查发现，是下游新建逻辑改动了）

　　最厉害的测试工程师可能还包括其他素质。但是绝对不包括：

　　· 自动化测试搞了半天，但是业务测的稀烂

　　· 框架和技术工具使用得天花乱坠，但是漏测率居高不下

　　· 说自己技术很强，但是研发技术评审从来不去，去了也提不出问题和看法

　　忙于写代码，但是流水线上测试环节的失败从来不去看，搞得研发不信任你，每次看到测试失败只想点跳过。