增量式调试脚本
录制测试脚本，和其他的软件开发成果一样，会变得非常大。为了可以成功的回放，需要调试几百行的代码，为了参数化的数据驱动测试脚本，它可能包含了几个数据集。常见的调试测试脚本方法是首先录制所有的业务流程和需求，然后测试人员回放测试脚本以验证并纠正问题。测试人员继续调试脚本直到它和可以一(或多)组数据集一起成功地回放。
当测试脚本有成百的代码行，验证点，分支的逻辑，错误处理，参数和数据在多个已录制的业务流程之间的相关性时，调试并且解决测试脚本中的问题变得特别的乏味和难以处理。对于调试那些复杂且又冗长的测试脚本，一个更加容易管理的方法是录制脚本的一部分并且在录制测试脚本的其他部分之前分开调试他们。在测试单个的部分后，你可以决定测试脚本的一部分如何和另一部分工作和数据如何从一个已录制的流程流向其他的流程。在测试脚本的所有部分都录制后，测试人员就可以回放整个测试脚本，并确保脚本同一个或多个数据集一起从头到尾被正确地回放了。
举个例子，我录制并自动化了一个执行了以下业务流程的复杂的测试脚本：
检查在货仓中的库存
执行一次MRP运行
补充库存
挑出一些要发送的货物并且进行发货
确定交货需要移交的订单
验证发送的货物到达了它们的目的地。
这个测试脚本有一些代码行，参数，验证点和需要象一个整体一样工作的数据相关性。首先我录制了每一个单独的流程并且验证了他们分别可以成功的回放。然后我将所有录制好的流程集成尾一个大的测试脚本并且验证它同多个数据集一起能够成功的回放。如前面所述，一个关键的目的是确信在继续录制整个测试脚本的剩余部分之前每一个已录制的流程可以成功的回放。我没有录制所有提及的流程(从1到6)并把它们排列一起回放，而不首先验证所有的流程可以作为单独的流程成功的回放。
这部分是为了避免等待调试脚本，直到整个测试脚本录制好。
测试脚本的同步
测试工具会用比终端用户手工按键快的多的速度回放已录制的测试脚本。接着由于应用程序可能不够快地显示数据或从数据库取出数值以允许测试脚本正确地回放，这可能会击垮所测试的应用程序。当测试地应用程序不能响应测试脚本时，脚本执行会突然中断，然后需要用户干涉。为了同步所测试应用程序和回放中地测试脚本，测试小组在已录制的测试脚本中引入了人为的等待时间。为了放慢测试脚本的执行，嵌入在测试脚本中的等待时间是最任意的且通过试验和错误最佳估计。等待时间主要的问题是它们要不是等的太长就是不够长时间。
例如，测试人员或许注意到对于所测试的应用程序测试脚本回放得太快。他可能打算放慢它几次直到测试脚本执行和测试的应用程序相同步。这个技巧可以会造成相反的结果-甚至失败-如果在测试执行时，由于外部的因素(例如网络有延迟或系统维护)导致应用程序运行比新引入的等待时间更慢。在这种情况下，每次测试人员将不得不不断的猜测一个新的合理的等待时间。用等待时间放慢脚本不是十分科学的，并且对于创建强健的，在没有用户干涉情况下能够成功运行的自动化测试脚本没有什么帮助。
如果有可能的化，测试人员应该避免引入人为的等待时间或任意的sleep变量以使测试脚本和应用程序同步。
"While"语句或嵌套的"loops"语句是用于同步需要同步点的测试脚本且不管所测试程序的响应时间都可以成功回放的正确的技术。在测试脚本种插入嵌套的loops或“while”语句也可以减少在测试脚本回放时用户的干涉。例如，我插入"while"语句在录制好的测试脚本里，不断按Enter键直到创建了一个计划中的协议，不管所测试应用程序要花多长时间产生协议。测试脚本不依赖所测试应用程序的响应时间工作。
已签核，通过了同行评审
作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。SMEs， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。
录制、回放隐藏的对象
文章来源于领测软件测试网 https://www.ltesting.net/
