从自动化测试执行的角度谈自动化脚本维护
自动化脚本在执行完毕后，每一个用例会分为经过或失败两种。对经过的用例，没什么可说的，这里主要谈下失败的用例。
失败的用例须要人去查看是不是脚本稳定性的问题，或是程序更新引发的问题。
对于脚本稳定性的问题又分为：配置环境引发的问题和非配置环境引发的问题。
对于配置环境引发的问题，那么在执行自动化测试前，须要人为地或自动地检查环境并配置好环境。这个如何配置，要预先知道，写成配置规范。
配置环境引发问题，包括：
a、自动化测试脚本的配置。
b、对测试程序进行配置。如:是否还原初始设置、是否删除某些数据。
c、对IE进行配置。
d、对与测试程序有关的程序或影响脚本稳定性的程序进行配置。
针对配置环境问题，对于每一个测试系统，都要进行编写《XX系统自动化脚本配置手册》，以免犯低级的配置错误。
对于非配置环境引发的问题，又分为以下几类：
a、网络延时，识别对象的同步问题。
b、未知因素引发脚本失败。
c、未知因素引发脚本运行中断。
d、自动化脚本自己使用了不稳定的因素。
e、脚本的继承性，上个脚本失败致使了下一个脚本也失败。
网络延时的问题，经过错误时再次从新执行此脚本或在脚本执行前确保网络正常，可解决此类问题。
以上几类中，以e类的最为严重，所以写脚本时最好不要产生依赖的脚本。
以上几类中，以b类和c类的最很差修改，可是能够经过不断重复运行此类引发失败的脚原本进行调试。
对于程序更新引发的问题，分为以下几类：
a、程序更新，致使大量脚本失败。大量脚本失败，缘由又分不少种，状况比较复杂：有整个页面都发生了变化、有业务逻辑发生变化、有控件类型发生变化、有程序修改的是最频繁使用的控件。若是是业务逻辑发生变化，则改起来比较费力。
b、程序更新，致使少许脚本失败。少许脚本失败，通常主要流程没变，修改起来相对容易。
为了优化成本，一般在晚上进行自动化用例的执行。
对于已知的程序更新，通常在自动化测试执行前就先进行维护。
对于不知道程序更新在什么地方，通常在自动化测试执行后才进行维护。
若是执行后，存在大量脚本稳定性问题或大量程序更新引发的问题，那么则须要次日立刻进行分析维护，以便维护后当天晚上进行再次执行。
若是执行后，存在少许脚本稳定性问题或少许程序更新引发的问题，那么依状况决定是否立刻进行维护，是否须要再次执行。
对于目前本身一周的工做，理想状况是：维护脚本时间加起来占1天，执行时间加起来占0.5天，还有3.5天用来进行其余工做。网络