自动化脚本执行失败原因分析

时间:2021-06-14 20:20:08
自动化脚本在执行完毕后,每个用例会分为通过或失败两种。对通过的用例,没什么可说的,这里主要谈下失败的用例。


失败的用例需要人去查看是否是脚本稳定性的问题,或是程序更新引起的问题。


对于脚本稳定性的问题又分为:配置环境引起的问题和非配置环境引起的问题。


对于配置环境引起的问题,那么在执行自动化测试前,需要人为地或自动地检查环境并配置好环境。这个如何配置,要预先知道,写成配置规范。
配置环境引起问题,包括:
a、自动化测试脚本的配置。
b、对测试程序进行配置。如:是否还原初始设置、是否删除某些数据。
c、对浏览器进行配置。
d、对与测试程序有关的程序或影响脚本稳定性的程序进行配置。


针对配置环境问题,对于每个测试系统,都要进行编写《XX系统自动化脚本配置手册》,以避免犯低级的配置错误。


对于非配置环境引起的问题,又分为如下几类:
a、网络延时,识别对象的同步问题。
b、未知因素引起脚本失败。
c、未知因素引起脚本运行中断。
d、自动化脚本本身使用了不稳定的因素。
e、脚本的继承性,上个脚本失败导致了下一个脚本也失败。


网络延时的问题,通过错误时再次重新执行此脚本或在脚本执行前确保网络正常,可解决此类问题。
以上几类中,以e类的最为严重,因此写脚本时最好不要产生依赖的脚本。
以上几类中,以b类和c类的最不好修改,但是可以通过不断重复运行此类引起失败的脚本来进行调试。




对于程序更新引起的问题,分为如下几类:
a、程序更新,导致大量脚本失败。大量脚本失败,原因又分很多种,情况比较复杂:有整个页面都发生了变化、有业务逻辑发生变化、有控件类型发生变化、有程序修改的是最频繁使用的控件。如果是业务逻辑发生变化,则改起来比较费力。
b、程序更新,导致少量脚本失败。少量脚本失败,一般主要流程没变,修改起来相对容易。


为了优化成本,通常在晚上进行自动化用例的执行。
对于已知的程序更新,一般在自动化测试执行前就先进行维护。
对于不知道程序更新在什么地方,一般在自动化测试执行后才进行维护。
如果执行后,存在大量脚本稳定性问题或大量程序更新引起的问题,那么则需要第二天马上进行分析维护,以便维护后当天晚上进行再次执行。
如果执行后,存在少量脚本稳定性问题或少量程序更新引起的问题,那么依情况决定是否马上进行维护,是否需要再次执行。


对于目前自己一周的工作,理想情况是:维护脚本时间加起来占1天,执行时间加起来占0.5天,还有3.5天用来进行其他工作。