最近遇到两个非常有意思的问题,虽然看起来没什么关联,但通过深入的思考,笔者发现它们还是有共性的,一起来看看这两个场景吧。

01

几位测试负责人在聊关于在 CICD 上设置质量门禁的问题。通常情况下,关于设置接口自动化的门禁,我们会设置某个阈值(比如接口测试通过率需达到 90%),来确保质量并决定是否发布这次的代码。

有位负责人提出,是否需要设置一个类似弱门禁的功能,当测试用例执行时间较长,或者面临紧急发版时,可以先跳过质量门禁(先发布,事后出报告,如果设置为不启用门禁,那就没有报告,所以需要提供类似弱门禁的能力),先发布,然后再回看这份报告。

你会如何解决或者思考这个问题呢?是否需要接受这个需求?

在大家充分讨论后,笔者给出了最终的观点:不接受这个需求。为什么呢?我们设置质量门禁的目标是什么?是确保当前代码的质量是经过测试,达到某个要求的。如果有了弱门禁的配置,那么大家都会偏向于使用弱门禁(怎么方便怎么来,是人之常情),但这不是平台的目标,作为平台,我们需要引导测试人员去设置这个质量门禁,去确保质量。

那么,之前提到的两个问题,如何解决呢?

关于用例执行时间长:这个问题分两种情况,如果是用例过多,引起的执行时间长。那么我们需要一起去探讨,作为冒烟测试,或者最低限度的质量保障,我们是否需要这么多的用例?这些用例是否可以被精简?如果确实需要这么多,那么作为平台方,我们是否可以提升执行机的性能?能否分布式去执行?这才是从根本上解决问题,而不是因为执行时间长,就让用户跳过去。

关于紧急发版:如果确认是十万火急的版本,那就联系平台管理员,从后台把质量门禁临时关闭掉,优先发版。但是这个功能只能是作为临时方案,不能作为常规方案。正常来说,越是紧急的版本,我们越容易忙中出错,所以更需要做接口测试来保障质量。平台也提供了临时的解决方案,但这个方案的启动权,不能直接交给用户。否则质量门禁也会流于形式。

02

我们再来看另一个场景。

供应商在发布 SIT 测试环境的代码时,发现有些新配置没有在数据库中生成,导致新功能受到影响。原则上,这些配置应该通过页面来操作,但是因为功能缺失,暂时无法生成这些配置。于是供应商要求甲方技术人员通过数据库操作,把这些配置手动生成,以便于其他流程顺利走下去。

那么,如果你是甲方技术人员,你会去执行么?

如果是我,我是不会私下就直接去生成这些配置的。这个不生成配置,不能成为供应商 SIT 功能无法交付的理由。因为这本来就应该是功能之一,如果没有完成,导致其他功能阻塞无法测试,那也应该通过正式的邮件说明理由、给出解决方案,给出修复时间,得到项目组的认可后,才能去手动执行去生成配置(这也是最终的解决方案)。

有人可能会说,不就是执行生成一些配置吗,你配置下,我其他功能就能验证了,为什么要为难我,走什么流程。

如果大家搭建过测试环境,就会知道,最难的不是把代码发布上去,而是去配置这些服务间的关联关系,哪怕你是通过配置中心统一配置,重新搭建一套环境,也是非常麻烦的。

问题一旦被解决,那么多数情况下,就不会有人再去关注了。那么发布的线上的时候,才发现配置功能还是有问题,难道还是手动处理么?所以,在问题发生的时候,应该去从根本上去解决,把功能做好。

可以手动临时处理,但是这个临时方案一定要得到大家的认可,被大家关注到。而不能让临时方案变成最终的解决方案。

03

我们往往会为了解决当下的问题,采用一些规避的方案,这些方案看似有效,但是并不能从根本上解决问题。

我们在思考问题时,要去关注我们的目标是什么,解决问题的方案是否有利于达成最终的目标,而不是仅仅解决当下的问题

我们需要临时方案,来灵活处理问题,但也要警惕这个临时方案演化成最终方案,以至于我们都忽略了我们的目标是什么

共勉


↙↙↙阅读原文可查看相关链接,并与作者交流