自动化脚本在执行完毕后，每个用例会分为通过或失败两种。对通过的用例，没什么可说的，这里主要谈下失败的用例。


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


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


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


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


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


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




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


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


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