在决定如何解决问题之前，您需要了解这些反复损坏的核心问题是什么。

依靠（更多、改进、更好、更快等）测试可能不是这里最有效的解决方案。它甚至可能根本没有帮助。

• 你有代码合并问题吗？修复是否因此而被撤销？
• 您是否出现了具有类似症状的新错误？
• 这些 UI 功能基本没有完全“熟”吗？也许您在开发过程中太早地浪费时间测试它们？
• 开发人员是否在新代码中犯了同样的错误？他们训练有素吗？
• 是否存在足够的文档？

这里有很多潜在的核心问题——每个都有不同的解决方案。

很难从 StackExchange 中的两段中得出关于组织的可靠结论，但在我看来，您似乎走得太快了。您不断更改产品的事实表明它是相当新的。对于新产品和新公司，当您的大多数用户都是早期采用者时，快速发布可能比高质量发布更重要。如果那真的是你所在的地方，你可能不得不忍受这种情况，直到你有更多的时间。

您在标题中提到了 UI 问题，并且在问题中提到了两次，所以我认为您的质量问题是特定于 UI 的；即软件的其余部分处于更好的状态。如果您有空闲时间，我建议您放慢速度并采取措施确保对 UI 进行更彻底和一致的测试。如果您的测试人员不使用测试计划，那么应该有人为他们编写一个测试计划，至少针对那些特别有问题的 UI 方面。您的测试人员是否使用与您的用户相同种类的环境？例如，如果您有一个基于浏览器的 UI，您的测试人员是否使用相同种类的浏览器和屏幕分辨率？

您可能会调查为什么您的开发人员会创建大量 UI 错误。他们是否意识到质量问题？从他们的角度来看，快速进行还是在签入之前对他们的工作进行单元测试更重要？开发人员是否使用了正确的基础架构？如果一件事的改变在其他地方引起一连串的错误，你可能有一个设计问题。

如果您唯一关心的是 UI 中的布局错误；你可以试试打架布局错误。它是一个用于检查布局错误的开源 Java 库。你可以在这里找到更多信息

http://code.google.com/p/fighting-layout-bugs/

此外，Selenium 可以方便地创建自动回归套件。你提出了这些测试很脆弱的问题；这在一定程度上是正确的。但如果做得好，从长远来看，它们可以证明是一种资产。您需要平衡自动化和手动探索工作，以获得两全其美的效果。

Gojko 对此的描述比我以往任何时候都精美，所以这是链接

http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

简短的回答：开发一个自动回归套件，UI 测试在正确完成时并不脆弱。

更长的答案：

我建议花时间开发一个使用 selenium 的自动化回归测试套件。很多时候人们说 UI 测试很脆弱，但在我看来，只有在没有正确编程的情况下，它们才会变得脆弱。确实很难创建一个运行良好的测试套件，但最终它是值得的。

考虑一下您的测试人员在项目结束之前将花费多少时间来执行重复性任务，并考虑开发一个运行良好/可维护的测试套件以摆脱这些重复性任务需要多少时间。

如果您选择创建一个自动化测试套件，您或您的客户最终会得到一个更容易维护且成本更低的系统。一个开发良好的自动化测试套件值很多钱。而手动测试更像是扔钱。

由于没有自动回归套件，您的团队现在背负着巨大的技术债务。您应该弄清楚现在是否值得努力消除债务，如果是，请继续消除它。尝试让所有相关人员了解开发/维护此类套件的投资回报率，并尝试优先考虑开发此类套件以及其余工作的优先级。

说服管理层使用大量时间来开发测试套件而不是使用这些时间来开发功能可能是一个好主意并不总是那么容易，但我认为你还是应该尝试一下。

聘请 selenium 顾问/培训师一段时间来培训您的测试人员/开发人员如何构建一个开发良好、功能良好的测试套件（如果您的公司没有任何专家的话）也可能是一个好主意。开发一个好的测试套件非常困难，专家可以防止你陷入所有的陷阱。