为了确定系统中的关键路径和动态路径，我们可以对系统进行分层抽象，明确各层的职责，各层之间相互独立，每一层只依赖于其下一层的特定接口，并为其上一层提供特定的接口。这样，将各层之间进行交互的所有接口串联起来构成了系统的关键路径。当然，如果一个系统的代码执行路径比较简单清晰，轻易可以确定出关键路径，那无须进行明确的层次分割了。

　　关键路径是代码在层与层之间流转的路线，而动态路径一般是某一层内部的代码执行路线。当代码执行到某一层时，该层接收其下一层传递的数据，然后根据一定的逻辑选择执行其内部的某条代码分支，这样的分支是一条动态路径。

　　实际上，单元测试对系统的设计间接提出了更高的要求。一个结构良好、分层清晰的系统更易于实行单元测试；相反，对结构混乱、层次混杂的系统很难写出高效的单元测试程序。并不是所有的系统都是易于测试的。

　　5.3.3    输出

　　系统分析说明，包括：系统结构图（标明程序运转路线）、关键路径与动态路径说明。

　　5.4    判断单元测试的必要性

　　5.4.1    目的

　　明确测试目标范围，对目标进行详细的系统分析，确定是否有必要对目标进行单元测试，或者确定目标的哪些部分需要单元测试，哪些部分不需要单元测试。

　　5.4.2    活动描述

　　可以从如下几个方面来评判单元测试的必要性：

　　目标代码的复杂程度

　　参考规模大体相当的历史项目的各项度量数据，分析没有经过单元测试的Bug数量和经过充分单元测试的Bug数量、分析项目投入的人员成本、时间成本等

　　其它方面

　　5.4.3    输出

　　单元测试必要性的判断结果及说明

　　5.5    研究测试方法

　　5.5.1    目的

　　在对测试目标详细的系统分析基础上，研究实施单元测试的具体方法，建立单元测试程序框架。

　　5.5.2    活动描述

　　针对系统的每条动态路径，研究对其实施单元测试的具体方法。

　　对各种测试方法进行归纳和抽象，建立编写单元测试程序的基础框架。

　　在基础框架的基础上，细化每种具体测试方法。

　　5.5.3    输出

　　单元测试程序基础框架及其接口说明、针对每条动态路径的测试方法说明。

　　5.6    执行测试

　　5.6.1    目的

　　制定测试计划，编写执行测试用例、修改发现的缺陷、总结测试结果。

　　5.6.2    活动描述

　　确定了对测试目标的测试方法后，需要根据项目进度、人力资源等方面的情况制定详细的单元测试计划，开发人员进入编码阶段，同时编写执行单元测试用例，根据单元测试暴露出的问题修改程序代码，如此不断迭代，终完成项目开发。

　　项目开发完成后应该进行总结，将在开发过程中做单元测试的好的实践总结记录下来，形成持续的积累，不断完善我们的单元测试方法论。

　　5.6.3    输出

　　测试计划说明、测试用例代码、测试总结

　　5.7    过程输出结果

　　将上述各过程活动的输出结果进行归纳整理，形成相应的文档和单元测试代码库。

　　可以将测试目标说明、系统分析结果、测试必要性研判说明、测试方法说明、分析总结说明单独写在一份文档中，将测试计划说明、测试用例列表、用例结果记录单独写在一份文档中，也可将所有内容全部形成一份文档，根据实际情况操作即可。

　　我的天哪，不能不说JE的可视化编辑器让人受不了，用得超级难受，特别难以做格式。。。