关于White框架在项目中的使用分析

white地址：http://www.codeplex.com/white 我只能说这是一个不错的UI测试框架。这个框架的实施必须要客户认可，因为这个测试框架的实施，需要花不少的时间。
我目前在思考单元测试在UI层上的适用范围，当我看完来之white的例子代码后，我发现white框架的价值观同样在这个思考范围之内。 在没有这个white框架之前，我们可以通过类似MVC的方式来部分实现界面层的测试，之所以是部分，这完全取决于我们如何来完成对V的定义。
有了这个框架之后，我们可以获得一个完整的View的定义和对View的驱动，所以可以获得获得一个完整的UI测试平台。这是我读这个框架时，在第一 次分析时，得到的结论。通过进一步分析，一个完整的View定义可以使我们对View上的UI元素进行赋值操作，这个操作可以代替我们在界面上输入和 鼠标事件；一个完整的View驱动可以使我们利用代码来代替界面上由用户操作触发的事件。而这些操作实际上都是基于真实的运行环境（具体的数据环境）。我认为这正是这个框架的局限性。从当前的分析中，我们暂时可以得出，white提供的是基于界面层的测试平台。 基于这个平台，写基于界面元素事件的驱动代码，例如：用户输入了一个用户名，然后点击查找按钮，得到了查找的数据。这个过程可以以两种方式存在，一、作为测试人员测试过程的一部分；二、作为white框架的一段代码（通常被包装到一个带有[Test]的函数中）。很显然，我们可以用white框架，将测试人员的测试过程通过代码用自动化过程来实现。那么，摆在我们面前的就存在一个问题，white框架上的测试代码 ?= 测试人员的测试过程吗？这个问题我一时还不能够做出回答，因为我既没有对white框架深入的使用经验，也没有测试人员的专业经验，但是我们可以很明确得出这样一个结论，“white框架上的测试代码”与“测试人员的测试过程”在很大程度上是重叠的。那么我们至少可以再得出两个问题，一、有了white框架上的测试代码，我们是不是可以不用专业的测试人员了；二、如果我们还要用测试人员，那么white框架上的代码是由开发人员来维护还是由测试人员（在UISpy的帮助下）来维护。 分析到这里，我想你们和我至少明白了一点，“white提供的是基于界面层的测试平台”，我认为对它的使用，取决于客户的价值判断。 而在我们内部，“white提供的是基于界面层的测试平台”，我想这是white设计者的意图，至于“操作实际上都是基于真实的运行环境（具体的数据环境）”这个所谓的局限性，其实不是white设计者的错。一个系统的设计会包含多方面的目标，white设计者只是成功的实现了其中一个而已。如果从开发人员的角度，要将测试的界面层从真实的运行环境中独立出来，还要做很多额外的工作。其工作量和我们对代码中“设备（我在这里将设备定义为一中概念，从测试的角度来看，我们用这种概念来界定代码中不可测试因素）”的界定有关。如果我们在设计中，解决了“操作实际上都是基于真实的运行环境（具体的数据环境）”问题，例如，测试一个需要调用webservice的窗体，由于我们已经将web service定义成了一种设备，那么我们在运行white平台上的测试代码时，就可以不需要真实的web service了。在以前，基于OA代码，如果要让一个窗体可以单元测试，那么我们至少要定义两个设备，一个设备是界面层元素，一个设备是webservice，那么在使用了white框架之后，我们至少要定义一个设备，webservice来实现测试。另外还需要考虑，如何消化掉界面层上的动态因素，例如：权限和按钮可用性的关系；tapechart上的订单和时间的关系，这些都是我们下一步考虑的内容。
Technorati 标签: White,View,测试