首先，让我完全透明并声明我确实在 Microsoft 工作。然而，在我的角色中，我和我的团队都使用编码 UI，但我确实在我的一些课程中教授编码 UI 的基础知识。

我建议不要比较每个工具集的功能，而是在您的决定中包括其他因素，例如：

• 作为一般经验法则，我们尽量减少测试代码和产品代码之间的抽象层。例如，我的团队主要测试用 C++ 编写的 API，而我们的测试代码是用 C++ 编写的。在我们有 UI 或 WinRT API 的情况下，我们确实使用 C#。
• 使用您的开发人员熟悉的语言。我们的开发人员对测试代码进行代码审查并运行我们的测试以帮助调试问题。
• 与现有工具集成。听起来您的团队已经在使用 TFS 和 Visual Studio，并且使用 Visual Studio 中的测试工具可以实现更加无缝的持续集成周期。
• 兼容性。虽然 Selenium 可以很好地用于您的基于 Web 的项目，但它不是您的 Windows 项目的选择。编码的 UI（和 C#）可用于测试两者。听起来 QTP 也可以用于测试 Web 和 windows 项目，但它是基于 VBScript 构建的，与 C# 相比，它有其自身的局限性。
• 考虑支持。Selenium 似乎得到了很好的支持，C# 社区也是如此。Coded UI 支持可用，如果这是您决定去的方向并有疑问，我很乐意让您与一些人联系。
• 可扩展性。使用自制包装器、P/Invoking Win32 API 或新的 WinRT api 扩展测试和测试功能的能力。

当然还有其他长期和短期成本需要考虑（即时培训成本等）。但是，简而言之，我建议不要只比较现有工具集中特定功能的优势和局限性。我建议扩大范围以考虑其他环境因素，这些因素将提高整个团队和整体业务的效率。

我使用了 Coded UI Tests，但更广泛地使用了 Selenium Webdriver。在我的回答中，我将完全忽略两者的记录和播放功能，因为除了让自己熟悉该工具外，我不提倡使用任何一种。此外，我不会评论一个与另一个的功能，因为它们几乎相同。任何你可以用一种工具做的事情，你都可以用几乎相同的努力以某种方式用另一种工具做。

我使用 Selenium 是因为它是免费的，而且直到最近 Coded UI Tests 默认只支持 IE。最近他们增加了对 Chrome 和 Firefox 的开箱即用支持，这让我想重新评估它。

我将重点回答 API 的易用性。实际上，我更喜欢 Coded UI API 而不是 Selenium WebDriver 的 API。

以下是我更喜欢 Coded UI API 的一些原因：

1. 元素是强类型的，即 Link 是一个 HtmlHyperLink 对象。在 selenium 中，一切都是 IWebElement，这意味着每个元素都具有相同的属性和方法，无论它们是否真正有用，甚至是否可用。强类型元素使智能感知更加有用，因为您知道是否公开了方法或属性，您可以在没有运行时“不支持”错误的情况下实际使用它。
2. 我更喜欢 HtmlHyperLink myLink = new HtmlHyperLink(...) 语法而不是 IWebElement myLink = webdriver.FindElement(By.CssSelector(...)) 这是我的偏好，它对我来说似乎更直观，并遵循标准的面向对象的编码实践。
3. 我真的很喜欢 GetChildren、GetParent、GetDesendants 方法。

可能还有一些，但通常就是这样。如果您正在寻找“缺少什么会让我的生活痛苦的编码 UI 测试？”的答案，我会说它并没有真正遗漏任何东西，所有标准的东西都在那里。

需要指出的一点是，我在 Selenium 之上构建了一个抽象层，并使 API 与 Coded UI 的 API 非常相似，因此可以拥有所有这些并且仍然使用 selenium，只是更多的前期工作。

编码良好的 UI 测试几乎不是“新的”，尽管当我很早就开始使用它们时，它们作为一个框架对我来说是新的。我将它们归为“记录和回放”类别，但是一旦您能够在测试中获得一些抽象并且能够修改脚本以变得更像具有可重复性的适当编码和编程框架，它们确实会增加更多的可扩展性和可编程功能。如果您已经在使用 Team Foundation Server (TFS)，那么您可以获得额外的好处，即能够将测试用例附加到特定测试，以及与修复的一些集成，如果您使用它，则可以使用敏捷测试模板，以便您可以链接用例直到测试。虽然我从来没有那样使用它，因为我们没有使用 TFS，而且我发现编码的 UI 对我自己的使用非常有限，

我对 Coded UI 的限制是脚本很难通过多次更改来维护，而无需（对我而言）大量的前期工作来使框架达到我可以将自动化带到我想要的地方的程度。针对 SharePoint 进行测试我认为使用 Visual Studio 工具会更简单，但这不适合我，我最终采用了不同的流程，但它绝对看起来对熟悉该产品且有远见的人有用对不同的部分做更多的整合比我有。我最终得到的是 C# 中 WebDriver 的组合，利用许多跨浏览器插件以及 SpecFlow 作为我的高级测试驱动程序，因为这使我能够以业务可以理解的语言生成许多测试用例的可扩展性拥有者;

在某些方面，工具的选择还取决于您的受众群体，并且由于您似乎已经有很多 Visual Studio 集成，因此您遵循这一点并能够让您的开发人员深入了解测试可能是一个加分项他们熟悉的工具。

在我的例子中，我已经做了大约 2 年的 Coded UI，并且发现 Coded UI 在后台为您做的事情比其他一些产品要多。我还使用了 QTP 和 Rational Robot 以及一些免费工具。默认的对象和步骤存储库有点麻烦，我建议将其抽象出来，主要是因为它太努力地识别对象，最终您会花费大量的搜索和过滤属性，而这在您刚开始时很费力。将它与 IE 一起使用，等待线程状态和动态对象搜索“等待”非常有用。

编码的 UI，我认为不仅仅是查看 DOM，因此您可以与 GUI 交互，就像通过点、单击和键入一样使用，而不是更改控件的属性以实现与用户相同的操作。

但是，无论您选择哪种工具，拥有一个综合开发部门非常重要，该部门将在您的所有控件上放置唯一的 Id，而不是在控件上放置不可见的控件，并且愿意在编写 GUI 时考虑到自动化。我不能强调这一点，否则您可以花更多时间研究如何解决实际编码测试的问题。