二、基本路径法
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。基本路径测试法包括以下5个方面：
1. 程序的控制流图：描述程序控制流的一种图示方法。
2. 程序环境复杂性：McCabe复杂性度量；从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
3. 导出测试用例。
4. 准备测试用例，确保基本路径集中的每一条路径的执行。
5. 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。
另外，对于测试用例的选择除了满足所选择的覆盖程度（或覆盖标准）外还需要尽可能的采用边界值分析法、错误推测法等常用地设计方法。采用边界值分析法设计 合理的输入条件与不合理的输入条件；条件边界测试用例应该包括输入参数的边界与条件边界（if，while，for，switch ，SQL Where子句等）。错误推测法，列举出程序中所有可能的错误和容易发生错误的特殊情况，根据它们选择测试用例；在编码、单元测试阶段可以发现很多常见的 错误和疑似错误，对于这些错误应该作重点测试，并设计相应的测试用例。
4.1.3 单元测试计划表格
在设计测试用例时可以参考如下表格，拟定对每个类（或模块或包）的测试计划。表1，是对每个类（或模块或包）作测试计划的表头，它指明本测试计划是针对那个模块及相关文件的。表2是针对表1指定模块测试用例而对应的子表，每个测试用例可以拥有一个子表；单元测试结果子表留作执行测试用例时根据实际结果填写。
子系统名. PackageName. JavaClassName
单元测试计划
标识
格式：
“子系统名. jsp_filename（含目录中间用\分开即可）”
或者
“子系统名. PackageName. JavaClassName”
组件功能项
如：组件完成 “新增贴子”的功能
针对概要/详细设计文件名
如：1.1版本公告部分详细设计说明书
物理文件名
jsp_filename（含目录）；
packageName. JavaClassName
表1
单元测试子项001
下面表格为针对上面表格“子系统名. PackageName. JavaClassName”而对应的子表，每个测试用例用一张子表：
编号
.001 注：“. 编号” 部分要从001编号开始一直到999，个人自行编号
程序设计人员
如：XXX
测试人员
如：XXX
测试目的
如：对错误逻辑输入检验
测试内容描述
如：对于public int fun3（String p1, int p2 ）的输入检验，如果 p1 == null，程序中检验到，应该记录到系统 logfile, return –1;
输入期望
P1 == null
功能处理期望描述
Logfile 多一条历史记录，方法return -1；
输出期望
Return –1
单元测试结果
实际输入数据
P1 = null
实际处理情况描述
程序没有进行p1 == null 的验证，没有及时return –1，而是运行到 p1.aaa( ) 方法时出现 null pointer 异常。
实际输出
没有写 logfile 文件；
测试结论
正常 / 异常
表2
4.2 测试类设计
一个模块或一个方法（Method）并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，用些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：
1. 驱动模块（driver）：相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果。
2. 桩模块（stub）：用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。
所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如图2。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产 品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件，桩模块可能需要模拟 实际子模块的功能，这样桩模块的建立就不是很轻松了。
图2 单元测试的测试环境
编写桩模块是困难费时的，其实也是完全可以避免编写桩模块的；只需在项目进度管理时将实际桩模块的代码编写工作安排在被测模块前编写即可。而且这样可以提 高测试工作的效率，提高实际桩模块的测试频率从而更有效的保证产品的质量。但是，为了保证能够向上一层级提供稳定可靠的实际桩模块，为后续模块测试打下良 好的基础，驱动模块还是必不可少的。
对于每一个包或子系统我们可以根据所编写的测试用例来编写一个测试模块类来做驱动模块，用于测试包中所有的待测试模块。而最好不要在每个类中用一个测试函数的方法，来测试跟踪类中所有的方法。这样的好处在于：
1. 能够同时测试包中所有的方法或模块，也可以方便的测试跟踪指定的模块或方法。
2. 能够联合使用所有测试用例对同一段代码执行测试，发现问题。
3. 便以回归测试，当某个模块作了修改之后，只要执行测试类就可以执行所有被测的模块或方法。这样不但能够方便得检查、跟踪所修改的代码，而且能够检查出修改对包内相关模块或方法所造成的影响，使修改引进的错误得以及时发现。
4. 复用测试方法，使测试单元保持持久性，并可以用既有的测试来编写相关测试。
5. 将测试代码与产品代码分开，使代码更清晰、简洁；提高测试代码与被测代码的可维护性。
4.3 跟踪调试
跟踪调试不但是深入测试代码的最佳方法，而且也是程序调试发现错误根源的有利工具。
测试类设计完成后，最好能借助代码排错工具来跟踪调试待测代码段以深入的检查代码的逻辑错误。现有的代码开发工具（如：JBuilder）一般都集成了这 类排错工具。排错工具一般由执行控制程序、执行状态查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、条件执行等功能。 执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各种状态信息的查询。跟踪程序用以跟踪程序执行过程中所经历的事件序列（如：分支、子程 序调用等）。程序员可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。
对于模块的单元跟踪调试，最好能够做到对被测模块的每次修改，都对每个测试用例进行跟踪执行一遍以排除所有可能出现或引进的错误。在时间有限的情况下也必须调用驱动模块对所有的测试用例执行一次，并对出现错误或异常的测试用例跟踪执行一次，以发现问题的根源。
排错过程往往是一个艰苦的过程，特别是那种算法复杂、调用子模块较多的模块，对于错误的定位来说并不是一件容易的事情。尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但还是有若干行之有效的方法和策略，下面介绍几种排错时应该采用的方法策略。
1. 断点设置，设置断点对源程序实行断点跟踪将能够大大提高排错的效率。通常断点的设置除了根据经验与错误信息来设置外，还应重点考虑以下几种类行的语句。
1） 函数调用语句。子函数的调用语句是测试的重点，一方面由于在调用子函数时可能引起接口引用错误，另一方面可能是子函数本身的错误。
2） 判定转移/循环语句。判定语句常常会由于边界值与比较优先级等问题引起错误或失效而作出错误的转移。因此，对于判定转移/循环语句也是一个重要的测试点。
3） SQL语句。对于数据库的应用程序来说，SQL语句常常会在模块中占比较重要的业务逻辑，而且比较复杂。因此，它也属于比较容易出现错误的语句。
4） 复杂算法段。出错的概率常与算法的复杂度成正比。所以越复杂的算法越需要作重点跟踪，如递归、回朔等算法。
2. 可疑变量查看，在跟踪执行状态下当程序停止在某条语句时可以查看变量的当前值和对象的当前属性。通过对比这些变量当前值与预期值可以轻松的定位程序问题根源。
3. SQL语句执行检查，在跟踪执行或运行状态下将疑似错误的SQL语句打印出来，重新在数据库SQL查询分析器（如：Oracle SQL Plus）中跟踪执行可以较高效的检查纠正SQL语句错误。
4. 注意群集现象，经验表明测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提 高测试投资的效益。如果发现某一代码段似乎比其他程序模块更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。[/img]..
社区：
