一个答案——正如菲尔暗示的那样，你把你能找到的每一个录音和回放工具都拿走，然后在绝望的火坑里烧掉它们。

我可能对此投了反对票，所以我会努力争取回来。

优秀的敏捷团队不断测试——不仅仅是在最后。如果您将测试设计作为功能设计的一部分（并考虑在设计时如何测试功能），您将不必编写 GUI 自动化 - 您可以在控制器级别或通过其他抽象实现自动化。

直接自动化 GUI 很少是一个好主意——即使在“最后测试”的团队中也是如此。而是专注于功能的“质量”，并作为一个团队来实施所有必要的任务以“完成”。

这实际上取决于您尝试通过自动化测试实现的目标。答案应该推动你的方法。您是否尝试：

• 减少回归？
• 减少测试人员必须执行的重复性手动检查量？（这可能与减少回归相同。）
• 请有一些神奇数字的经理？

一些想法：

• 先测试。让您的自动化测试推动开发，而不是相反。（考虑编写会告诉您何时完成的测试，而不是在完成后检查您所做的测试。）
• 更改您对完成的定义以包括测试的存在（或某种程度的测试覆盖率，或任何适合您或您的经理的指标）。

一般来说，如果可能的话，我会尽量避免使用记录和回放风格的工具（我假设你在这里谈论的是 Selenium IDE 之类的东西。）根据我的经验，它们往往既慢又脆弱。我从来没有从这些类型的工具中获得太多的投资回报。

假设“敏捷是迭代的，许多最后测试的工具是记录和回放风格的”是不正确的

• 开发/采用了用于管理重复测试、可重用测试的工具
• 开发的功能可能处于迭代阶段，在这种情况下，需要开发自动化以获得稳定的功能
• 自动化有自己的资源分配、规划和执行。自动化优势通常体现在多个​​周期中。不要将手动测试工作与自动化资源分配混为一谈
• 自动化战略需要根据项目资源、时间线进行规划。您强调的观点是感知，它们并不代表自动化领域的成熟度

这听起来很像你有典型的“敏捷但......”实现。

有一些方法可以避免基于 GUI 的自动化带来的开销和问题（可以在没有记录/播放的情况下完成 - 我现在使用 Microsoft 的 CodedUI 所做的事情在他们设计该工具时可能从未考虑过） .

这里有一些想法：

• 单元测试——这是作为开发的一部分发生的吗？良好的单元测试可以减少需要在更高级别发生的自动化量（您不需要详尽地测试处理逻辑，但可以专注于集成问题和遗漏的场景）。
• 有 API 可以使用吗？如果有，您可以使用新字段的占位符构建自动化，直到您明确知道它们将是什么（如果您真的很幸运，有一个一致的命名约定可以让您在大多数情况下获得正确的字段名称时间。到目前为止，我还没有走运，但也许有一天......）。
• 您现有的自动化对插入新功能的支持程度如何？是否处理 GUI 自动化并不重要：如果您有结构良好的自动化代码，则可以很容易地添加新功能。
• 您的 GUI 自动化是否允许您轻松地围绕现有功能添加新测试？正如 Alan 所说，如果可以的话，最好避免 GUI 自动化，但这并不总是可行的。
• 开发人员也可以处理功能/GUI自动化吗？这需要自动化完成作为完成定义的一部分，但如果可以完成有助于防止未来出现问题。

对于您在最后实现自动化并且没有时间处理它的问题，我建议使用“技术债务”一词。我认为代码完成后的自动化部分是由于 GUI 的变化，部分是因为自动化正在进入回归套件。如果对该自动化有任何吝啬，您会发现客户报告的错误聚集在没有良好自动化覆盖的应用程序区域中。

我在这方面的经历可能很典型——一个大型、复杂的企业对企业应用程序，其中的开发速度和长期人手不足的测试团队在自动回归中留下了巨大的漏洞。大多数回归必须是基于 GUI 的，并且在面向对象的编码成为任何人眼中的曙光之前，应用程序的大部分内容都是祖父辈的。它们没有经过单元测试，因为它们不可单元测试。大多数客户错误报告都在没有针对它们运行自动回归的领域。其余的都是边缘情况——有时在边缘情况下不值得自动化它们（“如果操作系统在此操作期间崩溃，则数据已损坏，

=======