恐怕我无法提供参考资料或统计数据，但我很确定您会发现测试自动化项目的失败（以及失败的原因）分为以下几大类：

• 严重依赖记录/播放——这是出了名的脆弱，但通常由自动化工具供应商大量销售。由于使用了记录/播放而失败的自动化项目通常会快速产生大量的“自动化”，但由于对 AUT 进行了一些更改后，它们不再起作用，因此被终止。
• 不可预见的复杂性——我处理的大多数自动化项目花费的时间比计划的要长，因为关键的 AUT 元数据比合理的预期更难找到。
• 移动球门柱 - 任何自动化不稳定 AUT 的尝试 - 特别是 GUI 尚未稳定的尝试 - 可能会失败或至少消耗比预期更多的时间。如果 AUT 快速变化，即使是精心设计的自动化框架的维护成本也会变得难以承受。
• 资源紧缩 - 根本没有足够的测试自动化专家来维护自动化软件和数据并增加自动化代码库。

我不能代表其他任何人，但我工作的大多数自动化项目最终都完成并得到积极维护。已弃用的主要是针对不再受支持的功能/特性，或者已被测试自动化应用程序框架的更好迭代所取代。（在我工作的地方，我们将自动化工具 (TestComplete) 的能力发挥到了极限，并构建了一个面向对象的框架，该框架运行 AUT 并利用基于文件的数据库来确定要运行的测试和不同的文件基于数据库的数据。我们主要使用它的记录/播放功能来寻找访问屏幕对象以进行编程操作的方法。结果是我所做的大部分维护都发生在旧脚本上，这些脚本几乎是美化的记录/播放没有'

有许多不活跃的脚本项目，大部分是没有时间完成它们的项目。

我知道这并不是您真正想要的，但我希望它可以帮助您指向您所追求的目标。

将测试自动化视为任何其他软件项目。失败的原因是一样的。

请考虑以下文章：

http://adante.ca/hardp/?p=57

不清楚您到底在看什么：自动化测试框架本身或特定框架的工具？

我认为测试框架Fitnesse有很好的 wiki 系统和漂亮的报告。但我个人更喜欢使用 Selenium + JUnit。失败的方法可以用任何你想要的方式来描述。只需要要求开发人员实现prettyLog方法。以您的方式处理和记录所有错误/异常的方法。对于我自己，我将我的测试分成小的功能部分，如果一个部分失败，我很容易找出问题所在。如果有必要，我可以根据捕获的错误/异常编写自定义消息。

我找不到任何专门用于测试自动化项目的数据。对于一般的软件项目，CHAOS 报告 2009给出了这些数字。