是的。在过去的几年里，我为许多事情构建、重建和发展了测试工具：

• 基于 UIAutomation 的 Windows 自动化库
• 建立在 Watin 和 UIAutomation 库之上的完整的基于 C# 的测试堆栈
• 控制发电机
• 测试用例管理系统
• 缺陷跟踪系统
• 可根据需要与 TFS、JIRA 或 Quality Center 配合使用的各种集成工具

其中大部分是开源的（testingstax.codeplex.com。我们发现，虽然我们需要的整体技术经验更高，但由于我们现在可以控制自己的命运，我们可以真正解决我们的问题，而不是试图适应某人其他的解决方案。

我们还发现，支持自己实际上更好，因为在让供应商派遣开发人员到现场使用他们的自动化工具解决问题后，他们仍然无法使用他们专有的闭源解决方案解决问题。

通过开源/内部组合，您实际上可以接触到更广泛的人才库，如果您有技术挑战或需要，这是解决它们的巨大动力。

但是，我们从来没有为我们工作过的是尝试构建一个很棒的工具来执行 X，如果没有迫切需要“愤怒”地实际使用它的话。建造一些很酷的东西，或者一个很好的东西，从来没有完成过。

我想说的另一个关键点是，当涉及到这类事情时，它与工具无关，而与人有关。如果您没有具备开发和维护工具技能的人员，那么就不要尝试构建它们。

我已经完成了很多使用不同语言和平台构建的内部工具，虽然我同意之前所说的一切，但我认为缺少的一点是确定您不仅需要该工具，而且要支持它。要么你需要能够安排工具的维护，要么让工具匠来处理它，否则你会得到一个满足 X 需求的工具，但它永远不会进步，也不会更新。此外，它需要文档，因为该工具可能不仅已经到位并且现在可以使用，而且几年后可能需要新的人来处理它，并且您希望确保未来的人知道该工具是什么设计或制造。注释代码很好。

另外不要忘记测试该工具，我发现了一些工具在 X 上运行良好但在 Y 上导致问题并在 Z 上完全失败的情况，通常在开发内部工具时，测试并不像它那样完整可能。

在我工作的地方，我们几乎所有的工具都是内部构建的。有些非常有帮助，而另一些则非常浪费时间。

但是，IME，如果您花时间根据您想首先解决的最大问题确定您将要构建的内容的优先级，然后以您在开发面向客户的应用程序时所投入的同样关注开发工具 - 并迭代开发您知道您是否朝着正确的方向前进，并与产品规划进行沟通以确保您构建的任何东西在下一个版本中都不会过时，您就有很大的机会获得积极的投资回报率。

否则（再次，根据我的经验），你可能不会做得那么好。

我工作的团队使用开源软件和本土软件的组合，但其中大部分是本土软件。我们使用可用的解决方案进行持续集成和自动化测试的运行，但围绕此的框架的其余部分是从头开始构建的；我们负责测试的每项技术的需求都过于具体，以至于任何通用工具都无法正确支持。我们依靠外部解决方案来完成非常具体的任务，然后在我们的产品工作方式范围内构建我们需要通用的系统。回报非常高；代码库很有趣，并且该框架多年来一直可靠地为我们服务，并且可以轻松扩展以支持新项目。