3.4.2 测试用例的详细程度
在对于测试用例详细程度的控制方面，根据统计过程控制（SPC，Statistical Process Control）[10]的相关原理，决定使用极差控制图来进行控制。
首先，我们使用“系统的总测试用例数/系统的总功能点数”的到每个功能点的测试用例数数据，用X表示。
5.3 单元测试
在代码审查通过之后就要进行单元测试了，单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用“白盒测试”[12]技术，系统内多个模块可以并行地进行测试。
5.3.1 单元测试任务
单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。
5.3.2 单元测试过程
一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。
下面针对图中缺陷的各个状态做出解释：
提交状态：录入一个缺陷，既一个缺陷被发现后的初始状态，这时候缺陷只是被按照严重等级进行了分级，还没有进行其他的操作，这时候缺陷的责任人为该缺陷的发现者。
指派状态：提交状态的缺陷，经过指派以后就变成了指派状态，该状态是由提交状态的责任人指定了缺陷的修改人以后变化而来。
修改状态：当在指派状态进行修改了对缺陷的修改之后，就变成了修改状态。
不是缺陷状态：指派状态的缺陷，如果责任人发现该录入的缺陷不是真实的缺陷，可以将其变为该状态。 | 
