5.15.2 使用 UnitTest 的自动化数据驱动测试[共3页]

183 5.15.2 使用 UnitTest 的自动化数据驱动测试

在5.15.1小节中，初步介绍了UnitTest 做单元测试的方法：声明变量，调用被测试的函数，将返回值与期望值比较，断言是否符合特定关系（如相等）；如果符合，则通过测试，否则测试失败。

测试方法每运行一次，需要一个测试用例。在实际工程中，通过一个测试用例来测试函数功能显然是不充分的。例如，如果测试除法函数，至少就要2类测试用例，除数为0和除数不为0；更复杂一点，例如，图书价格在0～100元以内（不含）时打9折，超过100元打8折，那么测试用例就必须覆盖3个数域及其2个边界，可行的测试用例为−1、0、99、100、200，至少需要5个测试用例。而执行每个测试用例，都需要修改测试方法中的用例数据。如果依靠手工修改，效率就太低了。现代化的测试工具可以根据自定义流程选择不同的用例，执行测试方法，并记录整个过程的测试结果。自定义流程可以是从指定的数据库中按序或随机地读取事先录入的测试用例，然后在测试方法中运行。

自动化数据驱动测试就是通过程序自动地从测试用例库中读取用例，并自动执行测试方法和记录测试结果。在一些敏捷开发中，如极限编程，常常采用测试驱动开发的方法，即在正式编码之前，先建立测试用例数据库和编写测试工程，然后再按照测试方法中定义的函数接口实现函数功能，这样，在编码过程中，每完成一个函数，就能立即通过运行测试发现一些潜在的错误。通过高质量的用例数据库来测试驱动开发，能够以较短的时间代价产生高质量的代码，这也正是测试驱动开发近年来大行其道的原因。而测试驱动开发（Test-Driven Development ，简称TDD ）所带来的好处远非这些，笔者强烈推荐大家去读一些专门介绍TDD 开发的书籍，更建议在以后的开发过程中，无论工程大小，尽可能采用TDD 的方式，它带来的好处之多或许会让你惊讶。

对于用例数据库，有一些是许多项目都会使用的，例如，登录的用户名和密码是否符合长度、中英文等规范。许多公司都有自己的测试用例数据库，甚至有一些设计良好的商业测试用例数据库。采用这些成熟的数据库，不仅省去了一些编写测试用例数据库的时间，而且数据库的质量有一定的保证。毕竟设计一个良好的测试用例数据库对公司来说也是一笔很大的人力资源开销，而其质量常常还比不上久经实践验证的成熟数据库。

对于测试用例数据库的选择，如果用例量非常庞大，则采用速度快的数据库比较合适，如SQL Server 、Oracle 、MySQL 等；如果对速度要求不高，而对通用性要求比较高（例如，参与编写测试用例的人员可能来自业务部门），则采用Excel 格式比较合适（使用门槛低，而且大部分机器上都会支持）。

下面结合SQL Server 介绍UnitTest 的自动化数据驱动测试。

仍然采用前一小节中使用的工程，对Sum 函数进行自动化测

试。首先打开SQL Server 建立UnitTestDB 数据库，并建立SumTest

表，表中数据如图5-44所示。

使用数据库中的数据时，测试用例数据使用TestContext 对象的

DataRow 索引器获取数据行。TestContext 对象属于System.Data 命

名空间，在System.Data.dll 文件中定义。首先在UnitTestProject 中

添加System.Data 引用并声明System.Data 命名空间，然后在测试类

ArithmeticTest 中定义TestContext 对象，如图5-45所示。

图5-44 SumTest 数据表