本文摘要：
1：测试要求
2：在VS中运行自动化测试
3：脱离VS进行自动化测试
在上一文中《C#借助API实现黑盒自动化测试工具的编写》（http://www.cnblogs.com/luminji/archive/2010/11/03/1867730.html），我们使用WINDOWS API来实现自动化测试工具的编写。但是，这种办法在大型软件测试的时候，需要很细致和繁杂的工作。在VS2010出来以后，我们不妨看看Code UI Automation这个好东西。关于Code UI Automation已经有人介绍过很多，本文要说明的重点如下：
1：使用Code UI Automation来录制手工操作UI的动作，让VS根据这些操作自动生成测试代码；
2：新建WINFORM项目（也即黑盒工具），在这个WINFORM项目调用这些自动生成的代码；
上文提到的1，之所以要让VS自动生成代码，是为了免去我们手动编写测试代码的繁杂工作。上文提到的2，是为了可以让我们的测试工具脱离VS。
一：测试要求
测试的要求仍旧如下，假设存在这样一个应用程序：
1：提供一个WINFORM窗体，上面存在一个TextBox，以及一个Button；
2：点击Button，会弹出提示框，提示框内容为TextBox的值；
现在，测试要求如下：
1：在300台机器上运行上面的程序；
2：到这300台机器上去点击这个Button，看看上文中的功能2有没有实现；
二：在VS中运行自动化测试
为了说明这个例子，我们创建了解决方案WindowsFormsApplicationTest，该解决方案共分为三个项目：
- WindowsFormsToBeTest，被测试的应用程序；
- TestProject1，VS2010的测试项目（使用.NET FRAMEWORK4）；
-
WindowsFormsTester，要编写的黑盒工具，也是一个WINFORM；
假设WindowsFormsToBeTest已经编写完毕，运行之。现在使用TestProject1中的Code UI Automation（新建"编码的UI测试"）来录制操作（操作过程为：在WindowsFormsToBeTest的文本框中输入"ABC"，点击Button，弹出提示，点击确定），然后生成代码，如下图：
找到生成的代码中公开的测试方法：
[TestMethod]
public void CodedUITestMethod1()
{
this.UIMap.RecordedMethod1();
}
其实，通过查看this.UIMap.RecordedMethod1()这个方法，VS也是调用WINDOWS API来实现获取各类控件的句柄。这个时候，如果我们在VS的测试列表编辑器中运行这个选中的测试CASE，
就会发现VS自动为我们复现了一个完整的录制过程中的操作。如下：
三：脱离VS运行自动化测试
接下来的工作是需要在我们自己的应用程序WindowsFormsTester中运行这个测试。
3.1：首先，我们需要在WindowsFormsTester中引用这些DLL：
它们应该是在一个类似如下的文件夹下，D:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies。如果不引用这些文件，编译会通过，但是运行时会报类似如下的错误：未能加载文件或程序集"Microsoft.VisualStudio.TestTools.UITest.Extension.IE.Communication.Interop, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"或它的某一个依赖项。系统找不到指定的文件。
3.2：在TestProject1中提供一个类来提供一个静态方法，如下：
public class TestInit
{
public static void Init()
{
Playback.Initialize();
}
public static void CleanUP()
{
Playback.Cleanup();
}
}
要注意，这点很重要，必须运行Playback.Initialize()，不然你自己的应用程序获取的句柄全部都是无效的。 另外，需要注意Cleanup这个函数。在每一次退出测试的时候，我们需要执行Cleanup（）。
3.3：现在，可以在WindowsFormsTester调用TestProject1中的公开方法了，如下：
TestInit.Init();
CodedUITest1 c = new CodedUITest1();
c.CodedUITestMethod1();
TestInit.Cleanup();
这样，我们便完成了一个脱离了VS的黑盒自动化测试工具WindowsFormsTester。
借助Code UI Automation的自动生成代码，使我们繁杂而细致的测试代码编写工作交给VS的测试引擎去实现，我们可以更多的将细节放在测试的业务逻辑上，而不是努力地去获取各种控件的句柄并操作他们。
参考：
http://blog.csdn.net/quicknet/archive/2010/11/21/6025824.aspx
http://blog.csdn.net/quicknet/archive/2010/11/24/6032674.aspx
理论上讲，在VS集成环境中能够执行的测试代码，在一般的程序代码中也是可以执行的，这里问题的关键在于，是否在你自己的程序中配置好了CUIT测试执行的环境， 即CUIT回放执行引擎是否正确启动了。当使用VS的CUIT工程时，每个测试类都被标识了[CodedUITest]，当VS的Mstest测试引擎在执行每个测试用例的时候，它会自动读取测试所配置的属性，以判断测试的类型，当它看到是CodedUITest后，它会自动初始化CUIT的底层回放(Playback)执行引擎，让后执行该测试用例。
在你的程序中是没有办法直接使用CodedUIAttribute和Mstest，这就需要Playback.Initialize()/Playback.Cleanup()这两个函数来帮助你完成启动初始化CUIT的底层回放执行引擎的工作，否则你的程序中无法直接应用CUIT类库中函数的。其实，不只是在非VS CUIT测试环境中调用CUIT函数需要显式调用Playback.Initilize/Cleanup，在CUIT的TestMethod外部调用任何Microsoft.VisualStudio.TeamTest.UITesting名字空间下的任何函数时，都需要这样显式地进行一下初始化和清理工作。VS Test Team的Gautam在的博文 How To : Get UITesting methods working outside the TestMethod of Coded UI Test进行了介绍。
除了上面的函数，CUIT还有其它一些很有用的函数，例如：UITestControl.DrawHighlight() ，它可以在控件的边界上画出一个蓝色的边框并保持7秒钟 (这是时间长度是不可配置的)，这在调试或者诊断问题的时候可以帮你判断所要的找的控件是否被成功地定位到了。
还有UITestControl.CaptureImage() 和 UITestControl.Desktop.CaptureImage() ，它们可以用来获取控件和整个屏幕的截屏，这些截屏在测试失败的时候是非常有用的，可以帮助快速分析和定位测试失败的原因，特别是在问题出现具有一定随机性不易Repro的情况下，错误现场的图片对于分析问题至关重要。
本文转自最课程陆敏技博客园博客，原文链接：http://www.cnblogs.com/luminji/archive/2010/11/18/1880452.html，如需转载请自行联系原作者
