软件测试执行

者分别独立工作。这是可行的，因为数据驱动测试脚本。而设计和建立脚本是为了产生一般的测试过程引擎，该引擎并不关心测试数据的内容。

    如果编写脚本的工作需要几个脚本编写者合作完成，那么有正在使用的测试脚本编写协定就显得非常重要了。将合适的人分配到合适的工作中也同样很重要。我们发现，测试设计师并不喜欢编写测试脚本，而测试实现者不喜欢设计和构建测试条件和测试数据。实际上，当他们的角色互换时，他们的工作将会变得毫无价值。

    这里说到的脚本编写是指测试脚本的编码，它可以使用测试工具自带的测试脚本语言；也可以使用现有的一些应用编程语言，比如Java或vlsllaI Basic：；或者使用标准的脚本语言比如Perl、cGI或vB scnpt；或者使用操作系统的命令过程语言(比如，编写unix shdl脚本来执行测试过程)。至于测试脚本的编写，确实需要热爱编程的人来做这项工作。Bmce就是这样一位工程师，他在成为测试脚本编写者以前是作为程序员进入到软件行业中的。程序员的经历可以使人成为天生的测试脚本编写者。测试脚本的编写要么需要已有的编程经验，要么需要在编程概念(比如逻辑、语法和语义)的不断训练。它同样还需要关注不断发展的复杂逻辑结构。因为有这些要求，所以不要期望非技术性的测试者能够写出测试脚本．更也不要期望他们能够使用大多数工具套件提供的捕获／回放功能创建有效的测试脚本。使用那种方法开发出的测试脚本对维护来说就如同噩梦。

    测试执行可以手工进行，也可以自动化进行，或者半自动化半手工进行。在测试业中有这么一条至理名言：手工测试和自动化测试各会发现不同类型的错误。所以专家认为应该两种测试都要做。我们也同意这种观点，先做成熟的手工系统测试，然后通过自动化回归测试来进一步测试，但这个想法过于单纯，因为，大多数测试往往由于资源的不足而只能做其中一种测试。因此我们建议，在手工测试与测试用例的设计和构建并行发生的地方结合两者。

    当测试设计师设计和构建测试数据时，应该能够运行被测应用程序，并能够执行测试数据，而该测试数据是设计用于测试该应用程序各种特征的。这样就完成了两件事情。第一，完成了对数据有效性的确认，该数据最终将用于自动化回归测试中；第二，在自动化回归测试之前完成了对每一个应用特征的手工功能(系统级)测试。当执行这个过程时，很多的错误能在测试用例设计和创建期间被发现。我们已经成功应用了这个方法。

原文转自：http://www.ltesting.net