计算机模块化软件系统中实现自动化单元测试的方法.pdf

本发明涉及一种计算机模块化软件系统中实现自动化单元测试的方法，其中包括：新建测试项目方案、添加第一测试程序集命名及第一测试类、在第一测试程序集中添加引用及动态链接库、添加第二测试程序集命名及第二测试类、在第二测试程序集中添加引用、添加持久化类、添加第三测试程序集命名及映射文件、在配置文件中加入测试配置信息、添加引用并将数据库驱动程序加入第二测试程序集和第一测试程序集中、产生测试用例、在第二测试程序集中添加测试用例所对应的类代码、编译测试项目方案并运行得到测试结果。采用该种自动化单元测试的方法，使得功能更完善、保证代码质量、可维护性和可扩展性，操作过程快捷方便，性能稳定可靠，适用范围较为广泛。

权利要求书一种计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的方法包括以下步骤：
(1)系统新建测试项目方案；
(2)系统在该测试项目方案中添加新的第一测试程序集命名，并添加相应的第一测试类；
(3)系统在该第一测试程序集中添加引用，加入动态链接库；
(4)系统在该测试项目方案中添加新的第二测试程序集命名，并添加相应的第二测试类；
(5)系统在该第二测试程序集中添加引用；
(6)系统添加持久化类；
(7)系统在该测试项目方案中添加新的第三测试程序集命名，并添加所映射的文件；
(8)系统在该测试项目方案的配置文件中加入测试配置信息；
(9)系统在该测试项目方案中添加引用，并将数据库驱动程序加入第二测试程序集和第一测试程序集中；
(10)系统产生测试用例；
(11)系统在第二测试程序集中添加测试用例所对应的类代码；
(12)系统编译该测试项目方案，并进行运行，得到测试结果。
根据权利要求1所述的计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的动态链接库为NUnit.Framework.dll动态链接库。
根据权利要求1所述的计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的第二测试程序集为会话管理器SessionManage。
根据权利要求3所述的计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的第二测试类为会话工厂SessionFactory。
根据权利要求1所述的计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的添加持久化类，包括以下步骤：
(61)在数据库中定义表结构和相应的字段名称和字段类型；
(62)系统将该表结构生成相应的映射类。
根据权利要求1至5中任一项所述的计算机模块化软件系统中实现自动化单元测试的方法，其特征在于，所述的模块化软件系统为交通管理平台软件系统。

说明书计算机模块化软件系统中实现自动化单元测试的方法
技术领域
本发明涉及计算机软件领域，特别涉及模块化软件系统测试技术领域，具体是指一种计算机模块化软件系统中实现自动化单元测试的方法。
背景技术
城市交通管理平台如今越来越强大，功能也越来越多，并且给城市道路交通带来了方便和快捷，在城市交通管理平台中单元测试起了重大的作用，测试质量的提高，平台的实用性，可靠性，准确性就有了保障。
同样在测试质量中单元测试起到了地基性的作用，有了坚固地基，才能盖起高质量的高楼大厦，单元测试就是在交通管理平台最初开发编写时进行测试的一个阶段，就好比我们在建造一所高楼时，已经打好地基，我们要进行反复测试该地基是否可以使用，并没有安全隐患，并且盖好后是否可以支撑一定高度的楼层，同样，单元测试在平台开发编写时反复测试一个编写好的模块，是否有Bug，并保证这个模块能支撑起城市交通管理平台的大厦。
在没有单元测试的时代，开发者大多数的错误都是通过操作交通管理平台页面的时候发现的。当发现一个错误的时候，会根据异常抛出的地点来确定是哪段代码出现了问题。但是大多数时候，开发者不会所有方法中都使用Try块去处理异常(这一也是低效的)。因此一旦发现一个异常通常都是最顶层代码抛出的，但是错误往往又是在底层很深层次的某个对象中出现的。当开发者找到了这个最初抛出异常的方法的时候，可能无法得知这段代码到底是哪里出了问题。只能逐行代码的去查找，一旦这个方法中使用的某个对象在外部有注册事件或者有其他的操作正在与当前方法同步进行，那么就更难发现错误真正的原因了。
发明内容
本发明的目的是克服了上述现有技术中的缺点，提供一种能够有效验证代码的行为和开发者所期望的一致、保证代码质量和可维护性及可扩展性、操作过程快捷方便、工作性能稳定可靠、适用范围较为广泛的计算机模块化软件系统中实现自动化单元测试的方法。
为了实现上述的目的，本发明的计算机模块化软件系统中实现自动化单元测试的方法如下：
该计算机模块化软件系统中实现自动化单元测试的方法，其主要特点是，所述的方法包括以下步骤：
(1)系统新建测试项目方案；
(2)系统在该测试项目方案中添加新的第一测试程序集命名，并添加相应的第一测试类；
(3)系统在该第一测试程序集中添加引用，加入动态链接库；
(4)系统在该测试项目方案中添加新的第二测试程序集命名，并添加相应的第二测试类；
(5)系统在该第二测试程序集中添加引用；
(6)系统添加持久化类；
(7)系统在该测试项目方案中添加新的第三测试程序集命名，并添加所映射的文件；
(8)系统在该测试项目方案的配置文件中加入测试配置信息；
(9)系统在该测试项目方案中添加引用，并将数据库驱动程序加入第二测试程序集和第一测试程序集中；
(10)系统产生测试用例；
(11)系统在第二测试程序集中添加测试用例所对应的类代码；
(12)系统编译该测试项目方案，并进行运行，得到测试结果。
该计算机模块化软件系统中实现自动化单元测试的方法中的动态链接库为NUnit.Framework.dll动态链接库。
该计算机模块化软件系统中实现自动化单元测试的方法中的第二测试程序集为会话管理器SessionManage。
该计算机模块化软件系统中实现自动化单元测试的方法中的第二测试类为会话工厂SessionFactory。
该计算机模块化软件系统中实现自动化单元测试的方法中的添加持久化类，包括以下步骤：
(61)在数据库中定义表结构和相应的字段名称和字段类型；
(62)系统将该表结构生成相应的映射类。
该计算机模块化软件系统中实现自动化单元测试的方法中的模块化软件系统为交通管理平台软件系统。
采用了该发明的计算机模块化软件系统中实现自动化单元测试的方法，由于单元测试在整个的模块化软件系统测试过程中是最基本的测试，而且单元测试是相对廉价而简单的技术，从而能够证明某段代码的行为和开发者所期望的一致，而且使得代码更加完美、功能更完善、保证代码质量、保证代码的可维护性和可扩展性，使得操作过程快捷方便，工作性能稳定可靠，适用范围较为广泛。
附图说明
图1为本发明的计算机模块化软件系统中实现自动化单元测试的方法的流程示意图。
图2为本发明的计算机模块化软件系统中实现自动化单元测试的方法的测试缺陷结果示意图。
图3为本发明的计算机模块化软件系统中实现自动化单元测试的方法的测试通过结果示意图。
图4为本发明的计算机模块化软件系统中实现自动化单元测试的方法中没有添加程序集Model时出错结果示意图。
图5为本发明的计算机模块化软件系统中实现自动化单元测试的方法中没有添加Npgsql驱动程序时出错结果示意图。
具体实施方式
为了能够更清楚地理解本发明的技术内容，特举以下实施例详细说明。
单元测试是代码正确性验证的最重要的工具，也是交通管理平台测试当中最重要的环节。也是唯一需要编写代码才能进行测试的一种测试方法。在标准的开发过程中，单元测试的代码与实际程序的代码具有同等的重要性。每一个单元测试，都是用来定向测试其所对应的一个单元的数据是否正确。
请参阅图1至图5所示，该计算机模块化软件系统中实现自动化单元测试的方法，其主要特点是，所述的方法包括以下步骤：
(1)系统新建测试项目方案；
(2)系统在该测试项目方案中添加新的第一测试程序集命名，并添加相应的第一测试类；
(3)系统在该第一测试程序集中添加引用，加入动态链接库；该动态链接库为NUnit.Framework.dll动态链接库；
(4)系统在该测试项目方案中添加新的第二测试程序集命名，并添加相应的第二测试类；该第二测试程序集为会话管理器SessionManage，该第二测试类为会话工厂SessionFactory；
(5)系统在该第二测试程序集中添加引用；
(6)系统添加持久化类，包括以下步骤：
(a)在数据库中定义表结构和相应的字段名称和字段类型；
(b)系统将该表结构生成相应的映射类；
(7)系统在该测试项目方案中添加新的第三测试程序集命名，并添加所映射的文件；
(8)系统在该测试项目方案的配置文件中加入测试配置信息；
(9)系统在该测试项目方案中添加引用，并将数据库驱动程序加入第二测试程序集和第一测试程序集中；
(10)系统产生测试用例；
(11)系统在第二测试程序集中添加测试用例所对应的类代码；
(12)系统编译该测试项目方案，并进行运行，得到测试结果。
同时，该计算机模块化软件系统中实现自动化单元测试的方法中的模块化软件系统为交通管理平台软件系统。
在实际使用当中，在一个城市交通管理平台中，本发明可以做许多各式各样的测试，而且这些测试也是必须的。其中的某些测试需要用户大量参与；而某些则需要有专门的质量保证小组来进行；或者需要其他的一些昂贵资源。
单元测试在整个的交通管理平台测试过程中是最基本的测试，它是交通管理平台的成功，个人成功的一个不可或缺的部分，但对它，人们却又存在各式各样的误解。单元测试其实是相对廉价而简单的技术，但它能让你更高效地写出质量更好的代码。
应用单元测试方法的好与坏直接影响到交通管理平台的质量，可能就是由于代码中的某一个小错误就导致了整个平台的质量降低一个指标，或者导致更严重的后果，如果我们应用好单元测试方法这种情况是可以完全避免的。
运行单元测试方法，是为了证明某段代码的行为和开发者所期望的一致。
所以单元测试方法的最终目的是令代码更加完美，功能更完善。保证代码质量。保证代码的可维护。保证代码的可扩展。
利用NHibernate进行数据库的增删改操作为例，本发明刚开始新建了一个程序集用来编写测试用例，在此程序集中建了一个类，具体如下：
(1)新建解决方案，命名为：NHibernateTest。
(2)在这个解决方案中添加新的程序集命名为DateUpdateTest并添加类DataTest。
(3)在这个程序集中添加引用，将NUnit.Framework.dll添加进来。并写入如下代码：


(4)本发明进行编译，会出错说：当前上下文中不存在名称”SessionFactory”，因为并没有建SessionFactory类。添加新程序集命名为SessionManage，并添加新类命名为SessionFactory。代码如下：


并添加NHibernate的引用。
(5)我们重新生成然后打开单元测试方法测试工具，打开文件‑‑‑打开项目，将我们刚刚生成的DateUpdateTest.dll添加进来点击运行按钮。发现错误，请参阅图4所示，出错原因是我们还没有添加程序集Model即持久化类。
(6)添加持久化类，我在数据库定义了一个Student表，字段为id，name，sex.其中id为int型，name和sex为varchar类型。将这个表用工具生成映射类。
(7)新添加一个程序集命名为Model.将映射成的文件添加进来。

选择Student.hbm.xml的属性中生成操作改为嵌入的资源。
(8)重新生成解决方案，并用单元测试方法重新测试发现得到了红色的条，发现出错了。原来还没有加入NHibernate的配置信息(当使用NHibernate时，需要在项目的配置文件中加入NHibernate的配置信息)。

本发明将配置信息命名为App.config添加到程序集SessionManage中和程序集DateUpdateTest中，在进行测试。出现了相应的错误，具体请参阅图5所示。
其原因是没有添加Npgsql驱动因为用的是Postgres数据库所以添加引用将Npgsql驱动加入SessionManage程序集中和DateUpdateTest程序集中。
(9)重新生成解决方案，打开单元测试方法测试工具点击运行，已经变绿了，表明通过了，这就说明本发明中所编写的NHibernate没有问题了，但还得编写几个测试用例测试一下。
(10)编写插入数据测试用例，删除测试用例和更新测试用例。本发明在DataTest类中继续写入一下测试用例：


重新生成解决方案编译没有通过，提示：当前上下文中没有存在NHibernateUtils。原来我们还没有编写NHibernateUtils类，在SessionManage程序集中添加新建类命名为NHibernateUtils，下面是NHibernateUtils类的代码：



重新生成解决方案，打开单元测试方法测试工具点击树状节点DataSaveTest运行结果如图3所示。
依次点击DataUpdateTest节点，DataDeleteTest节点效果和上图一样，证明我们编写的NHibernate没有问题。
上面的这个测试只是一个最基层的测试，它测试了NHibernate持久化的操作，最基层的测试通过后，我们可以一层一层往上加测试用例，同时我们可以加模块代码，测试通过后我们可以进行下一个模块的开发，直到把交通管理平台开发出来，这样不仅节省了开发时间而且还提高了代码质量。
单元测试是保证平台质量最基本的手段，下面讲讲怎么样的单元测试才是好的单元测试。
单元测试应该准确、快速地保证平台基本模块的正确性。下面是验证单元测试好坏的一系列标准：
(1)单元测试应该在最低的功能/参数上验证平台的正确性；
单元测试应该测试平台中最基本的单元——如类，在此基础上，可以测试一些系统中最基本的功能点(这些功能点由几个基本类组成)，从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。
(2)单元测试必须由最熟悉代码的人(平台开发的作者)来写；
平台开发的作者最了解平台的目的、特点和实现的局限性。所以没有比作者更合适的人选。
就算作者没有时间写测试方法，也应该对此单元测试进行负责。
(3)单元测试过后，机器状态保持不变；
如果单元测试创建了临时的文件或者目录，在数据库中创建或修改了记录，都要删除临时数据。保证单元测试可以重复快速进行；
(4)单元测试要快(一个测试运行时间是几秒钟，而不是几分钟)；
快，才能保证效率。一个平台中有几十个基本模块(类)，每个模块又有几个方法，基本上要求一个类的测试在几秒钟内完成。如果平台有相互独立的几个层次，那么在测试组中进行分类，分类进行测试。比如我只修改了“用户界面”的功能，我只需要运行“用户界面”的单元测试。
(5)单元测试应该产生可重复，一致的结果；
如果单元测试的结果是错的，那一定是平台出了问题，而且这个错误一定是可以重复的。一般情况下不要使用随机数以增加测试的真实性。
(6)独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据以保持单元测试的独立性；
平台中的各个模块都是相互依赖的，一般情况下，单元测试中的模块可以直接引用其它的模块，并期待其它的模块能返回正确的结果。如果其它模块很不稳定、未完成，或者运行比较费时，这是可以人为地构造数据以保证这个单元测试的独立性。
(7)单元测试应该覆盖所有的方法路径，包括错误处理路径，为了保证单元测试的方法覆盖率，单元测试必须测试公开的和私有的函数/方法；
如果你的功能中某个错误处理路径很难到达，那你要想想是否可以把这个错误处理拿掉。要注意一点：100％的功能覆盖率并不等同于100％的正确性。
(8)单元测试应该集成到自动测试的框架中；
一个重要的措施是要把测试自动化，这样每个人都能很容易地运行单元测试。团队一般在每日构建(在敏捷开发中要求每天都能够提供一个可以运行的版本进行构建)中运行单元测试，这样每个单元测试的错误就能及时发现并得到修改。
(9)单元测试必须和产品一起保存和维护。
单元测试必须和平台一起进行版本维护。如果不是这样，过一阵平台和单元测试就会出现不一致，而且所有平台的作者要花时间来确认那些是程序出现的错误，那些是由于单元测试更新滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试是一件很费时费力的事。
使用本发明的单元测试所产生的技术效果如下：
1、时间方面：如果认真的应用好单元测试方法，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不应用单元测试方法或随便做做的则在集成时总会遇到那些本应该用单元测试方法就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间。
2、测试效果：根据以往的测试经验来看，应用单元测试方法的效果是非常明显的，首先它是测试阶段的基础，应用好了单元测试方法，在做后期的集成测试和系统测试时就很顺利。其次在应用单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次应用单元测试方法关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。
3、测试成本：在应用单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在应用单元测试方法时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。
4、团队协作：在分层开发当中如果使用单元测试方法将会多方便，开发人员不用再去等其他层开发人员的接口，直接利用应用单元测试方法进行测试，单元测试方法为我们提供了丰富的断言可以弥补这一缺陷，还有在连接数据库测试时你可以不必关心服务器的状态，而直接测试，单元测试方法中的替身可以为我们做到模拟的数据库，方便开发人员迅速开发。
综上所述，应用单元测试方法是构筑产品质量的基石。
采用了上述的计算机模块化软件系统中实现自动化单元测试的方法，由于单元测试在整个的模块化软件系统测试过程中是最基本的测试，而且单元测试是相对廉价而简单的技术，从而能够证明某段代码的行为和开发者所期望的一致，而且使得代码更加完美、功能更完善、保证代码质量、保证代码的可维护性和可扩展性，使得操作过程快捷方便，工作性能稳定可靠，适用范围较为广泛。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。