&引用；动态构建&quot；测试

你好。又是鹏鹏。 不久前，我写了一篇博客，讨论了Visual C++ IDE作为解析器的安全性测试。IDE绝对不仅仅是一个解析器。除此之外，它还提供了一种集成的软件开发体验，包括浏览、转到定义、转到声明、快速信息、自动完成……用户界面可以做的事情太多了。

作为测试人员，为了保证高质量的优秀特性，我们必须创新，以客户为中心。这意味着我们需要测试大量的端到端用户场景。例如，用户创建一些新的VisualC++项目，定义新类和函数，声明和实例化新对象并进行函数调用。在这个过程中，为了确保正确性，她/他必须使用go to definition、class view、quick info或code definition窗口引用类/函数定义……因此，这使得测试非常复杂，需要在我们的测试基础结构中进行创新。今天，我要谈一个叫做“动态构建（BOTF）”的创新，它改变了我们自动化测试的方式，从一次构建和部署测试二进制文件到，顾名思义，动态构建。

关于我们当前测试执行架构的一点背景知识。它包括驱动程序和测试代码。testcase的测试代码是：测试二进制文件、.dll文件和xml文件中给出的测试元数据。元数据还提供测试执行信息，例如.dll中testcase的入口点。当测试执行时，将以测试xml文件作为参数调用驱动程序。驱动程序读取xml，找到xml文件中指定的.dll测试二进制文件，根据xml文件中的测试数据驱动测试，并适当记录测试结果。

在BOTF时代之前，每天都会生成测试二进制文件，并使用专用的构建机器将其聚合到几个大型msi中。在测试自动化过程中，msi首先被复制到测试机器上，然后安装到测试机器上。因此，所有test.xml文件和.dll文件都是预先生成的。这种方法变得非常痛苦：除了维护构建机之外，通常情况下，测试问题与构建问题是错综复杂的，要想找出测试失败时到底出了什么问题非常复杂。此外，它还带来了大量开销：任何测试问题修复都必须等待每日构建准备就绪并部署，以便进行验证。

BOTF通过按需构建测试二进制文件来解决这个问题。首先，在测试元数据xml文件中，测试被标记为BOTF。在设置阶段，原始测试代码、.vcproj、.h和.cpp文件被复制到测试机器。测试执行过程与之前完全一样：以测试xml文件名作为参数调用驱动程序。在底层，现在驱动程序将首先构建所需的测试二进制文件，然后执行它。有了这个创新，所有的测试都是独立的：构建或测试问题可以很容易地被隔离。所有的测试修复也都是“动态的”，我们不需要再等待构建机器了。

谢谢。

鹏鹏