最近遇到两个非常有意思的问题，虽然看起来没什么关联，但通过深入的思考，笔者发现它们还是有共性的，一起来看看这两个场景吧。
几位测试负责人在聊关于在 CICD 上设置质量门禁的问题。通常情况下，关于设置接口自动化的门禁，我们会设置某个阈值（比如接口测试通过率需达到 90%），来确保质量并决定是否发布这次的代码。
有位负责人提出，是否需要设置一个类似弱门禁的功能，当测试用例执行时间较长，或者面临紧急发版时，可以先跳过质量门禁（先发布，事后出报告，如果设置为不启用门禁，那就没有报告，所以需要提供类似弱门禁的能力），先发布，然后再回看这份报告。
你会如何解决或者思考这个问题呢？是否需要接受这个需求？
在大家充分讨论后，笔者给出了最终的观点：不接受这个需求。为什么呢？我们设置质量门禁的目标是什么？是确保当前代码的质量是经过测试，达到某个要求的。如果有了弱门禁的配置，那么大家都会偏向于使用弱门禁（怎么方便怎么来，是人之常情），但这不是平台的目标，作为平台，我们需要引导测试人员去设置这个质量门禁，去确保质量。
那么，之前提到的两个问题，如何解决呢？
关于用例执行时间长：这个问题分两种情况，如果是用例过多，引起的执行时间长。那么我们需要一起去探讨，作为冒烟测试，或者最低限度的质量保障，我们是否需要这么多的用例？这些用例是否可以被精简？如果确实需要这么多，那么作为平台方，我们是否可以提升执行机的性能？能否分布式去执行？这才是从根本上解决问题，而不是因为执行时间长，就让用户跳过去。
关于紧急发版：如果确认是十万火急的版本，那就联系平台管理员，从后台把质量门禁临时关闭掉，优先发版。但是这个功能只能是作为临时方案，不能作为常规方案。正常来说，越是紧急的版本，我们越容易忙中出错，所以更需要做接口测试来保障质量。平台也提供了临时的解决方案，但这个方案的启动权，不能直接交给用户。否则质量门禁也会流于形式。
我们再来看另一个场景。
供应商在发布 SIT 测试环境的代码时，发现有些新配置没有在数据库中生成，导致新功能受到影响。原则上，这些配置应该通过页面来操作，但是因为功能缺失，暂时无法生成这些配置。于是供应商要求甲方技术人员通过数据库操作，把这些配置手动生成，以便于其他流程顺利走下去。
那么，如果你是甲方技术人员，你会去执行么？
如果是我，我是不会私下就直接去生成这些配置的。这个不生成配置，不能成为供应商 SIT 功能无法交付的理由。因为这本来就应该是功能之一，如果没有完成，导致其他功能阻塞无法测试，那也应该通过正式的邮件说明理由、给出解决方案，给出修复时间，得到项目组的认可后，才能去手动执行去生成配置（这也是最终的解决方案）。
有人可能会说，不就是执行生成一些配置吗，你配置下，我其他功能就能验证了，为什么要为难我，走什么流程。
如果大家搭建过测试环境，就会知道，最难的不是把代码发布上去，而是去配置这些服务间的关联关系，哪怕你是通过配置中心统一配置，重新搭建一套环境，也是非常麻烦的。
问题一旦被解决，那么多数情况下，就不会有人再去关注了。那么发布的线上的时候，才发现配置功能还是有问题，难道还是手动处理么？所以，在问题发生的时候，应该去从根本上去解决，把功能做好。
可以手动临时处理，但是这个临时方案一定要得到大家的认可，被大家关注到。而不能让临时方案变成最终的解决方案。
我们往往会为了解决当下的问题，采用一些规避的方案，这些方案看似有效，但是并不能从根本上解决问题。
我们在思考问题时，要去关注我们的目标是什么，解决问题的方案是否有利于达成最终的目标，而不是仅仅解决当下的问题。
我们需要临时方案，来灵活处理问题，但也要警惕这个临时方案演化成最终方案，以至于我们都忽略了我们的目标是什么。
共勉。
