开发自动化测试脚本的技巧和心得(2)

　　作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。 SMEs， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。

　　录制、回放隐藏的对象

　　脚本可能被录制为增加或是双击表格中一个字段或字段位置没有被固定的一个数组的值。如果表格或数组中字段的位置从开始录制时就不断地变化，脚本可能在回放时会失败。测试脚本经常在回放中失败就是因为那些没有显示或在屏幕中可见的对象的位置发生了改变。

　　为了回放那些位置敏感或位置受变更影响的脚本，有必要用功能性增强脚本，例如“向下滚屏”，“下一页”或“查找”。包含这些实用性功能可以确保需要回放的隐藏对象将可以被识别，增加或是双击而不顾其在矩阵，表格，显示的屏幕上的位置。

　　举个例子，我曾经录制果一个脚本，在最初录制时它需要向下滚屏两次来查找一个可以在表格中输入的空字段。当我在几个星期之后回放它时，我不得不向下滚屏四次来查找空字段，而不是相之前录制的两次。接着脚本失败了，因此我在脚本中嵌入了逻辑判断以指导脚本向下滚屏需要的次数来查找一个空字段。我通过在一个 “while”循环中放置一个“下一页”("next page")功能实现了这个目的，它可以驱动脚本不停的“下一页”(page down)直到找到空字段。

　　安排重运行脚本/储存执行日志

　　为了绕过测试工具不能在安排测试脚本重运行的局限，测试人员可以通过可以支持多种命令行选项的NT的scheduler安排测试脚本。测试百年应该将执行日志存储在一个共享的驱动盘或针对审核的测试结果的测试管理工具中。

　　为关键的脚本创建自动的消息通知

　　可以用错误处理程序逻辑增强测试脚本，当错误发生时它可以不断的发送错误信息给无限设备或email地址。一些测试脚本是关键性的业务并且可能在午夜批量地运行。正确并成功运行这些关键性业务的测试脚本会作为其他自动化任务的一个依赖或者前提条件。

　　通常也包括在关键业务脚本中一旦出现失败时自动发送消息通知的逻辑。

　　编制文档

　　为了使测试脚本可重用并且更容易维护，文档化所有和执行测试脚本，测试脚本的头文件，任何执行测试脚本的特殊条件相关的信息，例如：

　　为了关闭书本调整所测试应用程序中的日期

　　更新任何需要唯一数据的字段

　　为了环境判断模式(context sensitive)/ 模拟模式(analog) /位图录制，调整显示器设置

　　列出所有有依赖的测试脚本

　　指出为了执行脚本需要的权限级别或用户的角色

　　在什么条件下脚本会失败，以及重新运行脚本的绕行方法

　　需要在脚本运行过程中打开或关闭的应用程序

　　指明数据的格式，例如，欧洲日期格式VS美国日期格式，等等

　　此外，脚本中需要包含一个描述(例如，它是干什么用的)和特别用途(例如，回归测试)的文件头。脚本的文件头应该包括脚本的作者，所有者，创建和修改日期，脚本可以追溯到的需求识别符，脚本所支持的业务范围，脚本中的变量和参数数量。在测试脚本中提供这些信息使以后的测试工作中的脚本的执行，修改和维护更容易些。

　　实行测试脚本的版本控制

　　许多公司花好几万英镑购买测试工具，但是却忽略了测试工具的副产品-录制好的测试脚本。为了公司构建中的自动化测试脚本的库和存储库，强烈建议对自动化测试脚本实行版本控制。版本控制帮助追踪测试脚本中的变更，并可维护同一测试脚本的多个版本。

　　坚持测试脚本命名标准和存储

　　测试脚本应当遵循项目公认的命名标准，并且应该存储在指定的库中，例如一个共享的驱动盘或测试管理工具中。

　　测试经理应当指明包括如下方面的测试脚本命名标准：

　　项目的名称(例如，GSI代表着Global SAP Implementation)

　　版本号(例如，即将发布或部署的版本号)

　　主题或测试种类(例如，SC代表安全测试，LT代表负载测试)

　　有序的测试用例编号

　　标题或将要测试的功能(例如，来自外部供应商的采购业务)

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