并不是所有手动测试都需要改为自动化测试才认为AST工作是成功的。有时这个是否应该自动化的问题应该基于ROI的计算，确定有些测试不能自动化有某些理由，比如，通过对ROI的评估，也许会证明（自动化该测试）不合算。

　　尽管AST通常是基于对手动软件测试工作的改进，但（自动化）测试已开发的软件，需要软件开发。我们开发软件来测试软件，因为当前没有更好的方法。

　　人们已经在这个方向上作出了努力，如IBM的自主计算（autonomic computing）项目，这有可能在不久的将来提供自我测试（self-testable）组件，虽然已经取得了一些进展，然而截止撰写本书的时候只有少数几家公司已经实施并应用了自主计算这个概念。

　　鉴于目前AST的状态和需要开发软件来测试软件的要求，有效的自动化测试应包括减少人工的参与，尽可能地自动化工作。开发软件测试软件的工作需要有效地改进。使用自动化来实现软件测试自动化是一种有效的方式，可以消除对人工交互的需求和由于手动而造成的错误。改进自动化测试的部分目标就是自动化进行测试自动化。

　　例如，很多公司经常花费时间从零开始开发测试框架，虽然已经有很多框架提供了这些功能，但还是为批处理测试、分布式测试或E-mail提醒创建功能。为了复用和简化功能集成，节约时间和资金，就应该充分利用提供所需功能的开源组件或自由/共享软件。在开发测试框架的新功能之前，查看开源社区，那里往往有许多我们所需要的已经开发好并可以直接下载的东西。我建议，任何自动化测试工作都应该考虑使用开源组件来设计和开发测试自动化框架。当考虑使用开源工具时，请记住开源许可的有效性。一些被认可的开源许可可以在http:// opensource.org/ licenses网页上进行核实。

　　自动化测试人员都知道，自动化测试需要有自己的开发生命周期，所以我们借用软件开发社区已经研究出的方法：使用工具帮助自动化生命周期的所有阶段，从需求到设计、实现、测试和缺陷跟踪。作为测试框架的一部分，对于测试过程的开发，可以遵循模型驱动设计（Model-Driven Design，MDD）。Telelogic/ IBM公司是最有前途的解决方案提供商，它们提供了自动化测试生成器（Automated Test Generator，ATG）和测试构建器（Test Conductor，TC）。ATG和TC一起生成“测试脚手架（test harness）/平台”，可用于生成为完成测试开发平台（即目标平台）上的模型所需的测试用例和测试代码。与供应商提供的方案相对的是开源的AndroMDA：“现在，你可以创建和使用自己的基于EMF的元模型，编写模型-模型转换，从PIM（Platform-Independent Model，平台无关模型）（抽象的最高层次）穿过一叠中间的PSM（Platform-Specific Model，平台相关模型）（使用容易理解的转换步骤），直到最后达到最低层次的PSM，这样使用简单的模型-文本转换就可以很容易生成代码了”。

　　对于自动化测试过程的生成还有些其他建议。比如，如果所有测试过程都是用MOF（Meta-Object Facility）模型到文本转换语言（Text Transformation）编写的（见OMG（Object Management Group，对象管理组织）的网站www.omg.org/cgi-bin/docad/04-04-07），那么就可以从手动测试过程生成自动化测试代码。

　　测试人员经常面对核查巨大的测试数据排列组合的挑战，如果使用Excel电子表格，手动操作这类数据集很容易出错，而且很乏味。但是，在许多测试“作坊”中，手动的测试数据创建过程仍然很普遍。为什么不在众多的测试数据生成器中选一个能为我们提供自动化的组合数据输出呢？例如，NIST（National Institute for Standards and Technology，美国国家标准和技术研究所）已经开发出了一款有用的工具，称为FireEye（或ACTS）就支持这种测试数据的自动生成，该工具可从http://csrc.nist.gov/groups/SNS/acts/download/下载（联系NIST获得登录ID和密码）。NIST在http://csrc.nist.gov/groups/SNS/acts/documents/comparison-report.html上将FireEye与其他已有的工具做了对比。