思考可维护性
脚本维护的需求不是不需要，而是卖自动化工具的人没有提到这点而已。在二月LAWST会议上我们不停的讨论两件事。
当软件用户界面发生变化的时候，你们要做多少修改测试脚本的工作能让脚本正确适应软件的变化并测试软件？
当软件界面语言发生变化（比如英文版到法文版），修正测试脚本让他正确适应软件的变化并测试软件有多困难？我们需要的是处理版本变化的测试策略。
下边两种策略是不推荐的：
建立测试用例利用扑捉回访工具。最普通的方法是利用自动化测试工具的扑捉特性建立测试用例。这是最苯的。
编程第一课可能学习的不是写程序，例如：
set a=2
set b=3
print a+b
隐藏恒量是很傻的。但那对我们是最有用的。我们建立通过录制输入一定顺序键值，鼠标动作，或者命令的测试脚本。这些恒量如2，3。软件用户界面的细微变化测试脚本都会发生错误。简单朴捉回放的脚本对于维护是不接受的。扑捉回访的脚本的好处是帮助你展示怎么样把手工测试用例用自动化工具执行。他们也不是无用的，但是如果你做的脚本越多风险越大。
在特定基础上编写测试用例：测试团队经常在他们的业余时间创建自动化测试用例。他们的计划类似，“尽可能的创建测试用例“ ---- 没有统一计划和主题。每个测试用例设计编码都是独立的，这些脚本中总会有重复的命令序列。这同扑捉回访一样是不健全的。
成功的策略：
我们不用为使用这些工具的风险而哀叹。我们其中很多人已经在comp.software.testing和另一些出版物上做了很多。我们在这里是因为我们已经意识到在处理这些问题上一些试验建立了很有意义的过程。但是信息共享的还不够。一个实验对于另一个是先进的做法是显而易见的。现在在这个既是挑战的环境也是澄清每个人想法的环境里是收集大家的想法的时候了。
一些开发自动化衰退测试测试略的建议：
重新斟酌对于能从自动化测试中得到好处的期望。
承认自动化测试一种软件开发
利用数据驱动体系
利用基于框架的体系
考虑使用其他类型的测试工具
1.重新斟酌对于能从自动化测试中得到好处的期望
我们认可GUI级别的自动化衰退测试执行n次后的结果，如果继续进行这种测试，可能会发现更多的益处。我们都知道在软件发布N次之后开发GUI级别的自动化衰退测试脚本，才能在软件发布N+1次的执行中得到更多的好处。我想大家都很惊奇有这样的结论，因为我们曾经都听说过（或者经验）投资自动化测试的回报这样的理论。
软件发布n次后意识到的好处，例如：
自动化测试一系列验收测试（冒烟测试）用例有很大的好处。在开发第n版软件的时候你可能要运行这些脚本50到100次.如果开发每个测试用例是手工测试执行的10倍时间,另外花10倍时间维护.这样创建一个自动化测试用例的时间可以节省相当于手工执行测试用例30到80次.
你可以节省时间,减少人为错误,总结怎样很好的跟踪自动化测试配置和兼容性测试所能做的。在这些案例里，你要在不同的环境下和设备下运行同样的测试。如果你和30个印刷工测试程序的兼容性，一周内你就可以重新得到自动执行测试的好处。衰退自动化脚本可以作为处理操作系统和处理不同的开发版本的基准。
当自动化带有短期获利目的的时候，自动化很容易在近期中发生危机。价值证明每一个附加测试用例或者一组测试用例。
如果你正在找寻找长期目标，处理软件版本，那么你要认真思考关于版本n的目标：
倘若在一些特定的阶段（比如冒烟测试和兼容性测试）中测试版本n。我们开发的脚本在软件版本n+1时将更加有效和强壮。
2．承认自动化测试一种软件开发
你不可能在还没有在下个版本还没有弄清楚和现实的计划前开发。
你不可能在还没有弄清楚和现实的计划前扩展测试脚本。
你不可能在没有弄清楚和现实的计划前开发出很多低维护成本的测试脚本。
软件自动化测试像其他软件开发一样需要时间，软件测试工程师需要编写自动化脚本代码。即使自动化脚本语言很难。如果决定用应用程序测试应用程序，那么每一个测试用例都有自己的特点。
从自动化软件测试的观点来看,每一个软件（正在测试的软件）的界面就是数据。我们研究如此多的软件开发工程，软件开发者（在这个例子中，测试工程师）必须 ：
了解需求：
接受一种有效的的开发方式，维护和集成软件的特点和数据。
接受和执行标准。（我们不必选择如iso或者cmm这样的配置管理，只要两个人可以利用命名规定，文档结构，处理错误等方式，在一个项目上合作工作就可以。任何组内成员都要遵守制定的规定和标准）
遵守规定：
所有的人，测试人员必须承认遵守近似于软件开发的方法代替quick-and-dirty的设计和执行方法有多么重要。没有他，我们必须有执行多少越多测试用例失败越多的心理准备。
