首先质量评估的意义主要在于理想情况下在Lab环境运行这些脚本时脚本结果失败是源于测试对象不匹配设计结果，而不是脚本自身的错误，这样能有效节省查看测试结果的人力投入，提升工作效率。

　　于是便产生了对脚本质量的评估需求，需要脚本错误异常抛出直接以节省结果查看人时间、脚本运行稳定等。目前工作中的流程是：Code review（脚本开发人员自己走读代码，可以利用静态代码分析工具分析build出的exe）->Peer review（组员之间做，要有checklist，里面每项pass即为通过）->循环N次运行该脚本（N次结果全pass即为通过）以稳定脚本->放入Lab环境执行->收集Lab环境脚本执行结果，对于脚本自身错误返回脚本所有者修改并从“循环N次运行该脚本”重新开始。

　　有时会发现同步方法无效，要知道，同步方法并不适用于所有测试对象。这里有一个能节省时间的小trick，当无效时，不要首先认为同步方法之后对测试对象的操作无效，而是首先在对该测试对象操作之前加入sleep足够时间的方法判断是否是同步方法的问题。

　　实施这套流程之后，10次执行可能只有1次是由于脚本不稳定造成失败，虽然并未完全达到理想状态，但相比不对质量有所要求还是强了许多。但这套流程同时也带来了副作用：比如一个比QTP更易用的录制回放工具，10+测试用例，1天时间制作脚本，但仍需要2~3天的时间来稳定脚本；一个能通过菜单退出功能的操作，为了脚本稳定不得不采用sendkeys来操作，有点违背非必须不用sendkeys/mouse click等无法验证操作对象的方法。

　　通过前面的简单介绍，大家可能已经发现开发一个足够健壮的自动化界面测试脚本需要耗费不少资源，而且看起来ROI似乎也不高（目前工作中其唯一的作用在于验证测试产品每个build的质量，对于build质量验证是否有效，这里存在两个问题：

　　1.界面自动化技术的局限性，比如出问题的区域自动化无法覆盖、取出的文本无法反馈真正的界面显示等；

　　2.自动化覆盖，比如自动化设计开发时的验证点，如果刚好忽略了bug出现部分的验证会造成跑完的结果并不可信），正如文1:10之惑中所述：“Google工程师认为底层接口测试及单元测试的自动化成本比较低，自动化的程度高、稳定性好。

　　基于界面的自动化测试时最难的”。这里的“难”应该主要体现在脚本质量保障上，对于敏捷团队花费太多资源在界面自动化测试上可能并不可行，所以界面自动化测试可以说是所有测试中投入最高的测试类型。