编码UI的唯一目的是执行自动化功能测试，而不需要人工交互。我们可以在TFS中管理一个测试用例列表，并且我们可以在使用MTM（Microsoft测试管理器）运行测试用例时记录用户操作。这些自动记录的操作也可以在我们发现构建中的更改后多次重复。
我引用了几篇文章，建议从Testcase的Recorded操作生成一个编码的UI TestMethod，或者将它们链接到Testcase。例如：
http://msdn.microsoft.com/en-us/library/dd286652.aspx
我无法理解拥有自动编码的UI测试和同一个TestCase的记录操作的优势？我一定错过了一个目标，那就是在我进一步行动之前，我必须知道。
我知道在将断言转换为CodedUI测试方法之后，我们可以进一步添加断言的数量。但这是编码UI相对于动作录制的唯一优势吗？
有什么建议吗？
问候Sumeet
MTM执行的测试对屏幕上显示的内容进行手动验证检查。将有一些测试步骤，如"期望看到…"或"The value…should be showing…."。要使用MTM正确执行测试，应执行每个验证步骤。MTM无法实现这些检查的自动化。
转换为编码的UI测试不会直接添加检查，但编码的UI允许将自动检查添加到测试中。在将MTM测试转换为编码UI测试后，编码UI的十字线工具（也称为断言工具和类似术语）可以用于添加断言，即屏幕上的值包含期望值。
转换的另一个原因是C#或VB的完整编程功能可以用来为测试添加额外的功能。