亭子2022-05-25Assert 检查点的失败，是产品错误，其它的失败都属于自动化测试代码健壮性的问题。 个人习惯一般在用例结尾处才去编写Assert断言，那用例执行中出现的如页面加载不出，系统异常等问题，也可能是系统bug，那是不是要每操作一步就写一条断言，那这样会不会造成代码行数太多可读性变差呢作者回复: 理解你说的问题。在实践中，我们可以丰富Automation Failure的分类，不局限于非黑即白“Assert”和“非Assert”的思路, 并对它们进行优先级和重要程度排序，形成自动化测试的评级制度。 以Java代码为例，不管Assert还是Timeout，还是其它错误，都是exception的形式，可以被框架捕捉到的。你可以得到一个列表来驱动不同角度的改进。 1. Failure1 ---->这需要改进么，谁来改进？ 2. Failure2 ----> 这要改进么，谁来改进？ 3. Failure3 ----> 这需要改进么，谁来改进？
3
羊羊2022-08-05 来自日本总结自己在自动化实践中的经验： 有些 assert fail 也是假阳导致的，对于这种情况，就是记录假阳的原因，改进自动化脚本和框架。老师提到的变异测试是个很好的思路。 遇到过的最极端的情况，自动化脚本啥操作没做，结果为pass。导致我们把脚本的默认结果设置为fail，需要检测点去更新最终的测试结果。 非检查的错误都会抛出异常，在异常模块定义了各种级别的异常，而且在定义了异常的处理方法，然后在数据库里面关联了每种异常和处理函数。异常发生后会通过反射机制去调用异常处理函数。 但是当时没有把这些数据统计出来，导致领导都不知道我们小组天天都在忙啥。作者回复: 期待你加入自动化测试高手微信群。在那里有很多分享！