下面表格为针对上面表格“子系统名. PackageName. JavaClassName”而对应的子表,每个测试用例用一张子表:

表2

  4.2 测试类设计
  一个模块或一个方法(Method)并不是一个独立的程序,在考虑测试它时要同时考虑它和外界的联系,用些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种:
  1. 驱动模块(driver):相当于所测模块的主程序。它接收测试数据,把这些数据传送给所测模块,后再输出实际测试结果。
  2. 桩模块(stub):用于代替所测模块调用的子模块。桩模块可以做少量的数据操作,不需要把子模块所有功能都带进来,但不容许什么事情也不做。
  所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”,如图2。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产 品的一部分一同交付,而且它们的编写需要一定的工作量。特别是桩模块,不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件,桩模块可能需要模拟 实际子模块的功能,这样桩模块的建立不是很轻松了。


  图2 单元测试的测试环境

  编写桩模块是困难费时的,其实也是完全可以避免编写桩模块的;只需在项目进度管理时将实际桩模块的代码编写工作安排在被测模块前编写即可。而且这样可以提 高测试工作的效率,提高实际桩模块的测试频率从而更有效的保证产品的质量。但是,为了保证能够向上一层级提供稳定可靠的实际桩模块,为后续模块测试打下良 好的基础,驱动模块还是必不可少的。
  对于每一个包或子系统我们可以根据所编写的测试用例来编写一个测试模块类来做驱动模块,用于测试包中所有的待测试模块。而好不要在每个类中用一个测试函数的方法,来测试跟踪类中所有的方法。这样的好处在于:
  1. 能够同时测试包中所有的方法或模块,也可以方便的测试跟踪指定的模块或方法。
  2. 能够联合使用所有测试用例对同一段代码执行测试,发现问题。
  3. 便以回归测试,当某个模块作了修改之后,只要执行测试类可以执行所有被测的模块或方法。这样不但能够方便得检查、跟踪所修改的代码,而且能够检查出修改对包内相关模块或方法所造成的影响,使修改引进的错误得以及时发现。
  4. 复用测试方法,使测试单元保持持久性,并可以用既有的测试来编写相关测试。
  5. 将测试代码与产品代码分开,使代码更清晰、简洁;提高测试代码与被测代码的可维护性。
  4.3 跟踪调试
  跟踪调试不但是深入测试代码的佳方法,而且也是程序调试发现错误根源的有利工具。
  测试类设计完成后,好能借助代码排错工具来跟踪调试待测代码段以深入的检查代码的逻辑错误。现有的代码开发工具(如:JBuilder)一般都集成了这 类排错工具。排错工具一般由执行控制程序、执行状态查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、条件执行等功能。 执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各种状态信息的查询。跟踪程序用以跟踪程序执行过程中所经历的事件序列(如:分支、子程 序调用等)。程序员可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。
  对于模块的单元跟踪调试,好能够做到对被测模块的每次修改,都对每个测试用例进行跟踪执行一遍以排除所有可能出现或引进的错误。在时间有限的情况下也必须调用驱动模块对所有的测试用例执行一次,并对出现错误或异常的测试用例跟踪执行一次,以发现问题的根源。