自动化用例的尺度到底怎么拿捏，每个测试团队或者每个人都有自己的想法和方法论，今天看到一篇文章以处理弹框为例比较详细的讨论了这个问题，觉得跟我的思路很接近，这里拿出来分享一下。原文地址：https://responsibleautomation.wordpress.com/2023/01/31/should-test-automation-just-handle-it/

在文章里作者列举了几个场景

• 有时我们收到这个弹出窗口，所以我们检查一下它是否在那里。如果有，我们就点击 "取消"，然后继续。
• 有时我们得到一个网页，上面写着 "系统不可用"，所以我们就点击F5，然后继续，因为这只发生在QA环境中。
• 有时，应用程序让我们在支付过程中二次登录。

碰到这些情况，自动化脚本应该如何处理？

从技术上讲我们始终是可以用代码处理这些情况的，不过核心的问题是，遇到这些突发情况，我们是要断言用例成功与否，还是写代码去pass这些细枝末节？有时候这类问题确实很困扰。

作者把这些问题分为两类

• 对业务没影响的，可以容忍的问题
• 不可容忍的问题

可容忍的问题

作者举了个例子，他们的ios app在进入的时候会弹框，要求用户授权定位和通知权限。遇到这种情况，脚本是直接点掉还是返回错误呢？作者表示他们也不能做决定，最后通过跟客户讨论，客户认为这种问题可以忽略，所以他们最终的策略是点掉，继续后面的流程，这就是可容忍问题的例子。

不可容忍的问题

还是上面那个app，一些情况下用户没有配置签名会弹出提示框，要求提供签名后继续，这种问题直接影响到了业务流程，就是不可容忍的问题，在这种情况下进行断言会比较好，因为没有签名后面的业务流程都走不通了，应该当做一个异常用例来进行专门的测试。

总结

作者给的例子都是弹框的，确实很少见到有人专门写东西来讨论弹窗的处理，简而言之一些弹框跟业务无关，那么就直接点掉或者不让它弹。比如之前我在写wordpress用例的时候，打开编辑器后总会出现全屏的用户引导教程，页面上所有文本框都没办法进行输入，我这时候认为新手教程不影响业务的核心流程，所以用了一些js代码直接让引导教程没办法弹出来。另一方面，如果出现的弹框是与业务强相关，那么弹与不弹就是两个用例，分别进行测试就好。

另外除了弹框，还有一些处理也可以分类来探讨。比如测试环境下超时时间调长一点，加载不出来就刷新一下，这种问题再测试环境是可以容忍的，不影响主业务和流程。