因此，我正在认真考虑使用Visual Studio编码的UI测试进行自动回归。
由于这是一个相对较新的产品，因此我无法找到有关编码UI测试限制的大量信息。
VS编码的UI测试方法的主要局限性是什么？特别是，Visual Studio编码的UI测试在哪些方面比TestComplete，QTP，Selenium等更传统的脚本化GUI自动化工具更有效（或更少）？
#1 楼
首先，让我完全透明，并声明我确实在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＃社区似乎都提供了很好的支持。提供了编码UI的支持，如果这是您决定走的方向并有疑问，我将非常乐意与您联系。
可扩展性。使用家用包装器，P / Invoking Win32 API或新的WinRT api扩展测试和测试功能的能力。
当然，还有其他长期和短期成本需要考虑（即时培训成本等）。但是，简而言之，我不建议您仅比较现有工具集中特定功能的优点和局限性。我建议您扩展到考虑其他环境因素，这些因素将提高整个团队和整个业务的效率。
评论
谢谢-这里的所有答案都很好。您对其他效率的提醒对我来说至关重要。无缝集成是一个很大的集成，我的雇主朝着C＃迈进，并且将多个不同的代码库统一为一个库也是如此。非常感谢您抽出宝贵的时间与您认识的人联系：自从我上一次使用解释性脚本语言以来，我花了太长时间了，所以我自己与C＃的交流很艰难。
–凯特·保罗（Kate Paulk）
13 Mar 26 '13 at 12:09
没关系，凯特。让我知道我是否可以帮忙。
– Bj Rollison
13年3月26日在23:59
#2 楼
我已经使用了编码的UI测试，但是更广泛地使用了Selenium Webdriver。在我的回答中，我将完全忽略两者的记录和回放功能，因为除了熟悉该工具之外，我不会主张使用两者。另外，我不会评论一个功能与另一个功能的差异，因为它们几乎完全相同。用一种工具可以做的任何事情，用某种方式可以用另一种工具完成，而用另一种工具可以用几乎相同的工作量完成。我使用Selenium是因为它是免费的，并且因为直到最近，编码UI测试默认情况下仅支持IE。最近，他们增加了对Chrome和Firefox的支持，这使我想重新评估它。与Selenium WebDriver的API相比，我实际上更喜欢编码的UI API。
以下是我偏爱编码的UI API的一些原因：链接是一个HtmlHyperLink对象。在硒中，一切都是一个IWebElement，这意味着每个元素都具有相同的属性和方法，无论它们实际上是有用的还是可用的。强类型化的元素使intellisense更加有用，因为您知道如果公开了方法或属性，那么您可以实际使用它而不会出现运行时“不支持”错误。
我更喜欢HtmlHyperLink myLink = new HtmlHyperLink（...） IWebElement上的语法myLink = webdriver.FindElement（By.CssSelector（...））这是我的偏爱，对我来说似乎更直观，并且遵循标准的面向对象的编码惯例。
我真的很喜欢GetChildren，GetParent， GetDesendants方法。
可能还有更多，但通常就是这样。如果您正在寻找“缺少什么会使我的生活痛苦的编码UI测试？”的答案，我想说的是它并没有真正丢失任何东西，所有标准内容都在那里。要指出的一件事是，我在Selenium之上构建了一个抽象层，并使该API与Coded UI的API非常相似，因此有可能拥有所有这些并且仍然使用Selenium，只是更多的前期工作。 >
评论
谢谢-这些都是很不错的点。出于您给出的原因，我将选择编码UI，并且正如Bruce和Michael所述，它与编程团队已经使用的工具进行了无缝集成。
–凯特·保罗（Kate Paulk）
13年3月26日在12:11
#3 楼
良好编码的UI测试并不是“新”的，尽管当我早开始使用它们时，作为框架我才刚刚使用它们。我将它们归类为“记录和回放”类别，但具有扩展性，一旦您能够在测试中获得一些抽象并且能够将脚本修改为更像具有重复性的适当编码和编程框架，它们的确会增加更多内容和可编程功能。如果您已经在使用Team Foundation Server（TFS），那么您将获得额外的好处，即能够将测试用例附加到特定的测试，以及与修补程序的某些集成；如果使用它，则可以使用敏捷测试模板来链接用例经过测试。尽管我从没有使用过它，但是由于我们没有使用TFS，并且我发现编码的UI仅限于我自己的用途，所以它确实为您提供了一个与开发人员使用的环境集成在一起的环境以及他们熟悉的工具需要代码或测试用例复审。我对编码UI的局限性在于，难以对脚本进行多次更改而难以维护，而无需（对我）进行大量的前期工作就可以使框架达到最佳状态。我可以将自动化工具带到我想要的地方的地方。我认为使用Visual Studio工具对SharePoint进行测试会更简单，但这对我而言不是，我最终采用了不同的过程，但是对于某些熟悉该产品并且对产品有广泛了解的人来说，它肯定看起来很有用。比我需要做的更多的整合工作。我最终得到的是C＃中的WebDriver的组合，利用了许多跨浏览器的附加组件以及SpecFlow作为我的高级测试驱动程序，因为这使我具有可扩展性，从而可以用业务上可以理解的语言生成许多测试用例拥有者;这对我来说是一个驱动需求。
在某些方面，工具的选择还取决于您的受众群体，并且由于您似乎已经与Visual Studio进行了大量集成，因此您可以按照以下说明进行操作，并且可以使开发人员通过以下方法对测试进行深入了解他们熟悉的工具。
评论
谢谢-正如我在其他地方评论的那样，由于集成，我将使用编码UI。我会从头开始构建一个框架，并更多地使用记录/播放作为获取我需要访问项目的映射的方法（我使用的每个工具都是记录/播放的工作方式功能）。
–凯特·保罗（Kate Paulk）
13年3月26日在12:14
#4 楼
以我为例，我从事Code UI已有2年了，发现与其他产品相比，Code UI在后台为您做的更多。我还使用了QTP和Rational Robot以及一些免费工具。默认的对象和步骤存储库有点麻烦，我建议将其抽象出来，主要是因为它试图识别对象太难了，最终
使用IE时，需要大量的搜索和过滤器属性，这很费力。 />编码的UI，我认为不仅可以查看DOM，还可以像通过点，单击和键入的使用方式与GUI进行交互，而不是更改控件的属性以实现与用户相同的操作。
但是，无论您选择哪种工具，都有一个专门的开发部门非常重要，该部门将在所有控件上放置唯一的ID，而不在控件上放置不可见的控件，并愿意编写带有GUI的控件。考虑自动化。我不能强调这一点，否则您可以花更多的时间来研究如何解决实际编码测试的各种问题。
评论
凯特（Kate），您可能想重新措辞，这样可以减少争论？诸如...“ Visual Studio编码的UI测试的功能是什么，其他工具中没有这些功能？”谢谢，布鲁斯。我一直在努力寻找足够的信息来进行公平的比较，但到目前为止我还没有取得太大的成就。