2 构件测试自动化框架设计
为了实现构件测试自动化，本文沿用现有的软件测试自动化技术。由于构件是二进制复用，使用方常得不到构件的源代码，构件对使用方而言是黑盒，无法进行代码分析。若采用捕获/回放方法，将会拥有大量测试脚本，并且当构件版本升级时，相应的测试脚本也必须重新录制。
因此，测试自动化将采用前面提到的测试脚本技术。这可以分为测试脚本的自动生成与自动运行。前者建立在构件及其元数据的基础上，后者应当能够自动读取独立的测试用例数据。要实现构件测试的自动化，必须使测试驱动程序能够直接读取测试用例文件，并自动执行。
XML 语言强大的数据描述能力和方便快捷的解析手段，使之成为构件测试的最佳用例描述语言。在测试用例XML 文件中，一个构件对应一个Test Suites，一个CoClass 对应一个Test Suite，每个待测试的方法对应多个测试用例。
每个测试用例给出一组输入参数和预期输出参数，每个参数指出其名字和类型。测试驱动程序读取测试用例到测试脚本中时可以使用XML 文档读写的API，简单方便。
2.1 构件混合测试自动化框架
本文的构件测试自动化框架主要基于xUnit 框架。对构件中方法的测试通常有相同的测试逻辑和稍有不同的系统输入，因此，考虑将测试逻辑与测试用例分离，这样既能获得较好的测试覆盖，又能最小化需要编写与维护的测试代码量。
因此，不能简单地依赖xUnit 框架。本文设计的构件测试自动化框架将对xUnit 框架进行改进，把它与数据驱动测试的策略结合起来。xUnit 框架是单元测试框架，而数据驱动的测试框架适合于用户测试。很多第三方构件则需要用户对其进行黑盒单元测试，因此，将两者结合切实可行。
为了应用数据驱动的测试策略，本框架设计了单独的测试用例XML 文件用来存储输入和期望值。这些数据将被传递到测试脚本中。这样，原先的测试就成为参数化测试，由测试驱动担当数据驱动测试解释器的角色，向测试脚本传递参数，包括输入值和期望值。而共同的测试逻辑包括测试方法的调用和断言的调用。
在具体实现两者的结合时，最简单的方法是在测试方法中包含一个循环来从测试用例文件中读取输入数据值和期望结果的集合。但这将导致一个单独的测试用例对象带有许多断言。由此而来的结果是：
(1)执行的所有测试用例将被视作一个测试，这样将减少执行的测试的计数。
(2)测试将在第一个失败处停止，接下来的测试用例将不再运行。这正是xUnit 框架对于用户测试存在的不足。这样测试的充分性将大幅降低，将错过后面可能也引起断言失败的测试用例，从而减少了缺陷的暴露，丢失很多错误定位。
(3)不能告诉测试者失败发生时哪个子测试正被执行。这些问题正是测试的独立性问题。尤其是在构件测试中，构件是有状态的，因此，按上述方法测试，各次测试之间很可能有较紧密的耦合关系。
这样必然造成测试的不准确。为了保证每次测试都是独立的，本框架将继续对xUnit 框架进行改进：对于每个测试用例都实例化，都进行测试固定设施的初始化和清理工作。这样每个测试用例都能运行于自己的测试上下文中。
文章来源于领测软件测试网 https://www.ltesting.net/
