自动化软件测试概述.docVIP

自动化软件测试概述自动化软件测试的实际情况 　　自动化软件测试（Automated Software Testing，AST）这个术语从软件开发和测试社区成员那儿汲取了许多不同的含义。对于有些人来说，这个术语也许是测试驱动开发或单元测试的意思，但是对于其他人也许意味着使用捕获/记录/回放工具进行自动化软件测试。这个术语的意思也有可能是使用诸如Perl、Python、Ruby等脚本语言来定制开发测试脚本。对于另一些人，自动化软件测试也许只涉及性能测试和压力测试，或全部关注于功能测试或安全性测试。在本书中，AST指代所有这些含义。 　　在进一步深入细节之前，明确地定义AST，以及就这个术语与读者达成一致的含义和理解很重要。我们将根据过去的工作和经验来定义AST，这同样是它的真实含义。另外，本章将讨论成功的AST工作需要什么，以及一些AST方法。在这里我们将讨论如何精简一些自动化测试工作的建议，还会讨论在整个软件测试生命周期中应用AST。 　　1.1 自动化测试定义 　　自动化软件测试的定义包括了所有测试阶段，它是跨平台兼容的，并且是进程无关的。一般来讲，当前作为手动测试程序部分的各种测试（如功能、性能、并发、压力等测试）都可以自动化。大家经常问这个问题：“手动测试和自动化测试有什么不同呢？”答案如下： 　　自动化测试可以完成手动测试难以完成的工作，可以提高手动测试的工作效率。 　　自动化测试也是软件开发。 　　自动化测试不是要取代手动测试人员所需要的分析技能、测试策略知识和对测试技术的理解。手动测试人员的经验会作为AST的蓝图。 　　自动化测试不可能完全和手动测试分开。相反，自动化测试和手动测试是相辅相成的。 　　尽管开发软件将今天已有的手动软件测试全部转换成自动化测试是有可能的，然而我们的经验表明，为了适应自动化，大多数手动测试都必须经过修改。手动测试技术、实践和知识与AST是相互交织的，所以也会在本书中对其进行讨论，以对AST技术提供支持。而自动化是否可以产生合理的ROI（Return On Investment，投资回报率）是另外一个问题，这需要通过评估。经验表明，即使可以将所有测试自动化，但并不是所有测试都值得自动化。当决定是否要自动化时，我们需要考虑各种准则。如何确定哪些测试应该自动化会在第6章进一步探讨。要将ROI铭记在心，我们对AST的高层次定义是： 　　以改进软件测试生命周期（Software testing lifecycle，STL）的效率和有效性为目标，贯穿整个STL的应用程序和软件技术的实施。 　　AST是指跨越整个STL中的自动化工作，以及关注自动化集成测试和系统测试的工作。AST的总体目标是设计、开发和交付自动化测试，并通过重复测试来提高测试效率。若成功实施，那么它可以大幅度减少针对软件密集型系统的传统测试和评估方法、过程相关的成本、时间和资源。 　　1.2 自动化测试的方法 　　当有效地实施了AST时，它不完全是对图形用户界面（GUI）的捕捉和回放（但是许多人是这样理解的），也不局限于某一特定阶段的测试，同时也不是专门针对任何特定厂商的产品，它适应AUT（Application Under Test，被测试的应用）使用的特定架构或语言。 　　本书描述的AST是过程无关的、技术无关的，并且环境无关的。遵循本书描述的实施建议，就可以实施AST，而不管是使用瀑布模型、测试驱动开发模型、Scrum或任何其他类型的软件开发模型，而且不管是测试Web应用或面向服务架构的方案，也不论你的应用运行在Linux上、Mac上或Windows上，它与环境、OS和平台都无关。 　　如果有效地实施了AST，则可以支持下面环境的应用： 　　在多台计算机上运行。 　　使用不同的编程语言。 　　在不同类型的操作系统或平台上运行。 　　无论是否有GUI（例如，消息接口的测试，没有GUI）。 　　运行任何网络协议，如TCP / IP、DDS协议等。 　　在开发自动化测试框架时，以下几点应该铭记在心。它应该： 对多个商业测试工具的集成提供支持，无论是开源的、自主开发的，还是来自不同的供应商（即使是市场上出现的最新的和更好的可以使用的产品）。支持无须在与SUT相同计算机上安装框架就可以进行测试。 　　同时支持正在开发的新应用和遗留应用。 　　支持整个测试生命周期（但并不是为了使用AST，就需要在整个测试生命周期中应用）。 　　支持在跨多台计算机上和各种系统工程环境中进行分布式测试。 　　如果适用，则支持在多个程序之间复用AST框架和组件。 　　AST的实现需要一个小型的开发生命周期，包括测试需求、自动化框架的设计和构建、自动化测试的实施/验证以及执行。如果做得正确，AST将产生可重用且可扩展的框架和组件。应该应用并遵守软件开发中的最佳实践。