软件测试捕获回放失败

最流行的测试工具包括各种记录器。这些记录器看起来提供一种不用编程创建自动化测试的方法。在测试时只需要打开记录器，记录器会捕获所有用户事件，包括所有击键、鼠标移动和鼠标点击事件，并将这些事件存储在可供以后回放发脚本中。测试员还必须指示检查点。这些就是点击热键以通过脚本保存屏幕信息的测试步骤。在回放期间，脚本将当前屏幕（或与当前屏幕有关的某种设计好的属性）与所保存的信息比较。如果两者不同，则测试失败。

关键问题是，这种脚本与用户界面和系统配置的微小细节捆绑得太紧。在实践中，测试常常因为有意实现的产品设计变更，或由于无意产品回归程序错误而失败。测试员发现，他们花在分析测试失效和重新记录测试上的时间，要比以前手工执行测试所需的时间还多。

假设有 100 个涉及创建账户的测试脚本，并且产品被修改，现在账户创建工作流程要通过一个额外的对话框。所有这些测试都会失败，必须重新记录测试。再假设屏幕上的一个标签从“登录名”改为“用户名”。包含这个屏幕检查点的所有测试现在都会失败。

如果测试失败，会给分析带来更大的困难。是设置程序错误，自动化测试中的程序错误，还是产品程序错误呢？从计算机动态生成的脚本很难区分这些程序错误。如果不读脚本，怎么知道测试怎样运行呢？

更结构化的测试自动化策略使用同样的工具，但需要更长时间编码并要求程序设计技能。当用户界面变更后，更新所产生的测试要容易的多。

根据我们和大多数测试自动化设计人员的经验，捕获回放自动化测试是覆盖着冰的下面有砖墙的坡地。有太多的小组花费大量时间记录自动化测试脚本，发现程序只修改几次这些测试就不能用了，需要全部重新记录。

需在构建能够持久或手工测试结合的自动化测试的技能和规划上投入。与捕获回放相比，这两种测试通常更高效、更有效。

搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核