者分别独立工作。这是可行的,因为数据驱动测试脚本。而设计和建立脚本是为了产生一般的测试过程引擎,该引擎并不关心测试数据的内容。
如果编写脚本的工作需要几个脚本编写者合作完成,那么有正在使用的测试脚本编写协定就显得非常重要了。将合适的人分配到合适的工作中也同样很重要。我们发现,测试设计师并不喜欢编写测试脚本,而测试实现者不喜欢设计和构建测试条件和测试数据。实际上,当他们的角色互换时,他们的工作将会变得毫无价值。
这里说到的脚本编写是指测试脚本的编码,它可以使用测试工具自带的测试脚本语言;也可以使用现有的一些应用编程语言,比如Java或vlsllaI Basic:;或者使用标准的脚本语言比如Perl、cGI或vB scnpt;或者使用操作系统的命令过程语言(比如,编写unix shdl脚本来执行测试过程)。至于测试脚本的编写,确实需要热爱编程的人来做这项工作。Bmce就是这样一位工程师,他在成为测试脚本编写者以前是作为程序员进入到软件行业中的。程序员的经历可以使人成为天生的测试脚本编写者。测试脚本的编写要么需要已有的编程经验,要么需要在编程概念(比如逻辑、语法和语义)的不断训练。它同样还需要关注不断发展的复杂逻辑结构。因为有这些要求,所以不要期望非技术性的测试者能够写出测试脚本.更也不要期望他们能够使用大多数工具套件提供的捕获/回放功能创建有效的测试脚本。使用那种方法开发出的测试脚本对维护来说就如同噩梦。
测试执行可以手工进行,也可以自动化进行,或者半自动化半手工进行。在测试业中有这么一条至理名言:手工测试和自动化测试各会发现不同类型的错误。所以专家认为应该两种测试都要做。我们也同意这种观点,先做成熟的手工系统测试,然后通过自动化回归测试来进一步测试,但这个想法过于单纯,因为,大多数测试往往由于资源的不足而只能做其中一种测试。因此我们建议,在手工测试与测试用例的设计和构建并行发生的地方结合两者。
当测试设计师设计和构建测试数据时,应该能够运行被测应用程序,并能够执行测试数据,而该测试数据是设计用于测试该应用程序各种特征的。这样就完成了两件事情。第一,完成了对数据有效性的确认,该数据最终将用于自动化回归测试中;第二,在自动化回归测试之前完成了对每一个应用特征的手工功能(系统级)测试。当执行这个过程时,很多的错误能在测试用例设计和创建期间被发现。我们已经成功应用了这个方法。
文章来源于领测软件测试网 https://www.ltesting.net/