录制测试脚本，和其他的软件开发成果一样，会变得非常大。为了可以成功的回放，需要调试几百行的代码，为了参数化的数据驱动测试脚本，它可能包含了几个数据集。常见的调试测试脚本方法是首先录制所有的业务流程和需求，然后测试人员回放测试脚本以验证并纠正问题。测试人员继续调试脚本直到它和可以一（或多）组数据集一起成功地回放。
当测试脚本有成百的代码行，验证点，分支的逻辑，错误处理，参数和数据在多个已录制的业务流程之间的相关性时，调试并且解决测试脚本中的问题变得特别的乏味和难以处理。对于调试那些复杂且又冗长的测试脚本，一个更加容易管理的方法是录制脚本的一部分并且在录制测试脚本的其他部分之前分开调试他们。在测试单个的部分后，你可以决定测试脚本的一部分如何和另一部分工作和数据如何从一个已录制的流程流向其他的流程。在测试脚本的所有部分都录制后，测试人员就可以回放整个测试脚本，并确保脚本同一个或多个数据集一起从头到尾被正确地回放了。
举个例子，我录制并自动化了一个执行了以下业务流程的复杂的测试脚本： 检查在货仓中的库存 执行一次MRP运行 补充库存 挑出一些要发送的货物并且进行发货 确定交货需要移交的订单 验证发送的货物到达了它们的目的地。这个测试脚本有一些代码行，参数，验证点和需要象一个整体一样工作的数据相关性。首先我录制了每一个单独的流程并且验证了他们分别可以成功的回放。然后我将所有录制好的流程集成尾一个大的测试脚本并且验证它同多个数据集一起能够成功的回放。如前面所述，一个关键的目的是确信在继续录制整个测试脚本的剩余部分之前每一个已录制的流程可以成功的回放。我没有录制所有提及的流程（从1到6）并把它们排列一起回放，而不首先验证所有的流程可以作为单独的流程成功的回放。
这部分是为了避免等待调试脚本，直到整个测试脚本录制好。
测试脚本的同步
测试工具会用比终端用户手工按键快的多的速度回放已录制的测试脚本。接着由于应用程序可能不够快地显示数据或从数据库取出数值以允许测试脚本正确地回放，这可能会击垮所测试的应用程序。当测试地应用程序不能响应测试脚本时，脚本执行会突然中断，然后需要用户干涉。为了同步所测试应用程序和回放中地测试脚本，测试小组在已录制的测试脚本中引入了人为的等待时间。为了放慢测试脚本的执行，嵌入在测试脚本中的等待时间是最任意的且通过试验和错误最佳估计。等待时间主要的问题是它们要不是等的太长就是不够长时间。
例如，测试人员或许注意到对于所测试的应用程序测试脚本回放得太快。他可能打算放慢它几次直到测试脚本执行和测试的应用程序相同步。这个技巧可以会造成相反的结果－甚至失败－如果在测试执行时，由于外部的因素（例如网络有延迟或系统维护）导致应用程序运行比新引入的等待时间更慢。在这种情况下，每次测试人员将不得不不断的猜测一个新的合理的等待时间。用等待时间放慢脚本不是十分科学的，并且对于创建强健的，在没有用户干涉情况下能够成功运行的自动化测试脚本没有什么帮助。
如果有可能的化，测试人员应该避免引入人为的等待时间或任意的sleep变量以使测试脚本和应用程序同步。
"While"语句或嵌套的"loops"语句是用于同步需要同步点的测试脚本且不管所测试程序的响应时间都可以成功回放的正确的技术。在测试脚本种插入嵌套的loops或“while”语句也可以减少在测试脚本回放时用户的干涉。例如，我插入"while"语句在录制好的测试脚本里，不断按Enter键直到创建了一个计划中的协议，不管所测试应用程序要花多长时间产生协议。测试脚本不依赖所测试应用程序的响应时间工作。
已签核，通过了同行评审
作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。SMEs， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。
录制、回放隐藏的对象脚本可能被录制为增加或是双击表格中一个字段或字段位置没有被固定的一个数组的值。如果表格或数组中字段的位置从开始录制时就不断地变化，脚本可能在回放时会失败。测试脚本经常在回放中失败就是因为那些没有显示或在屏幕中可见的对象的位置发生了改变。
为了回放那些位置敏感或位置受变更影响的脚本，有必要用功能性增强脚本，例如“向下滚屏”，“下一页”或“查找”。包含这些实用性功能可以确保需要回放的隐藏对象将可以被识别，增加或是双击而不顾其在矩阵，表格，显示的屏幕上的位置。
举个例子，我曾经录制果一个脚本，在最初录制时它需要向下滚屏两次来查找一个可以在表格中输入的空字段。当我在几个星期之后回放它时，我不得不向下滚屏四次来查找空字段，而不是相之前录制的两次。接着脚本失败了，因此我在脚本中嵌入了逻辑判断以指导脚本向下滚屏需要的次数来查找一个空字段。我通过在一个“while”循环中放置一个“下一页”（"next page"）功能实现了这个目的，它可以驱动脚本不停的“下一页”（page down）直到找到空字段。
安排重运行脚本/储存执行日志
为了绕过测试工具不能在安排测试脚本重运行的局限，测试人员可以通过可以支持多种命令行选项的NT的scheduler安排测试脚本。测试百年应该将执行日志存储在一个共享的驱动盘或针对审核的测试结果的测试管理工具中。
为关键的脚本创建自动的消息通知
可以用错误处理程序逻辑增强测试脚本，当错误发生时它可以不断的发送错误信息给无限设备或email地址。一些测试脚本是关键性的业务并且可能在午夜批量地运行。正确并成功运行这些关键性业务的测试脚本会作为其他自动化任务的一个依赖或者前提条件。
通常也包括在关键业务脚本中一旦出现失败时自动发送消息通知的逻辑。
编制文档
为了使测试脚本可重用并且更容易维护，文档化所有和执行测试脚本，测试脚本的头文件，任何执行测试脚本的特殊条件相关的信息，例如： 为了关闭书本调整所测试应用程序中的日期 更新任何需要唯一数据的字段 为了环境判断模式（context sensitive）/ 模拟模式（analog） /位图录制，调整显示器设置 列出所有有依赖的测试脚本 指出为了执行脚本需要的权限级别或用户的角色 在什么条件下脚本会失败，以及重新运行脚本的绕行方法 需要在脚本运行过程中打开或关闭的应用程序 指明数据的格式，例如，欧洲日期格式VS美国日期格式，等等此外，脚本中需要包含一个描述（例如，它是干什么用的）和特别用途（例如，回归测试）的文件头。脚本的文件头应该包括脚本的作者，所有者，创建和修改日期，脚本可以追溯到的需求识别符，脚本所支持的业务范围，脚本中的变量和参数数量。在测试脚本中提供这些信息使以后的测试工作中的脚本的执行，修改和维护更容易些。
实行测试脚本的版本控制
许多公司花好几万英镑购买软件测试工具，但是却忽略了测试工具的副产品－录制好的测试脚本。为了公司构建中的自动化测试脚本的库和存储库，强烈建议对自动化测试脚本实行版本控制。版本控制帮助追踪测试脚本中的变更，并可维护同一测试脚本的多个版本。
坚持测试脚本命名标准和存储
测试脚本应当遵循项目公认的命名标准，并且应该存储在指定的库中，例如一个共享的驱动盘或测试管理工具中。
测试经理应当指明包括如下方面的测试脚本命名标准： 项目的名称（例如，GSI代表着Global SAP Implementation） 版本号（例如，即将发布或部署的版本号） 主题或测试种类（例如，SC代表安全测试，LT代表负载测试） 有序的测试用例编号 标题或将要测试的功能（例如，来自外部供应商的采购业务） 遵循这些技巧使测试人员能够为他们的组织构建更强健的测试脚本。当然，开发可维护的测试脚本最大化自动化测试工具的效益。当自动化测试脚本用在以后的测试工作中，减少了完成一个测试循环所需要的时间时，公司就可以意识到自动化测试工具带来的投资回报（ROI）。以上的技术将帮助公司构建符合这些目标的测试脚本。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/