3.3    不写单元测试的理由

　　为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度。

　　单元测试的价值不高，完全是浪费时间。

　　业务逻辑比较简单，不值得编写单元测试。

　　不知道怎么编写单元测试。

　　项目没有要求，所以不编写。

　　在项目的前期还是尽量去编写单元测试，但是越到项目的后期就越失控。

　　3.4    总结

　　在现代软件开发过程中，测试不再作为一个独立的生命周期。单元测试成为与编写代码同步进行的开发活动。单元测试能够提高程序员对程序的信心，保证程序的质量，加快软件开发速度，使程序易于维护。不管测试先行还是测试后行，没有单元测试那是绝对不行的。

　　注：3.3和3.4节参考袁光东的文章《程序员为什么不写单元测试？》

　　4、单元测试过程定义

　　5、单元测试过程活动描述

　　5.1    过程进入条件

　　实施单元测试的最佳时机是在编码阶段，若编码阶段没有进行单元测试，则也可以在后期单独开发单元测试程序。

　　5.2    确定目标范围

　　5.2.1    目的

　　明确进行单元测试的需求边界，确定测试目标的外延边界和内部结构。

　　5.2.2    活动描述

　　确定要进行单元测试的目标的外延边界。

　　若目标本身比较庞大，可能需要对目标进行分解，确定哪些部分需要进行单元测试，哪些部分无须单元测试。

　　5.2.3    输出

　　对单元测试需求的说明。

　　对目标边界的说明。

　　5.3    进行系统分析

　　5.3.1    目的

　　理解测试目标采用的技术架构，理清程序运转流程，将目标拆分成可测试的单元逻辑。

　　5.3.2    活动描述

　　理解掌握测试目标的平台架构、技术路线。

　　理清程序的运转流程，得出代码执行的路线图、数据流程图等。

　　将测试目标拆分成可测试的单元逻辑：这一步至关重要，因为只有将测试目标分解成多个相对独立的单元逻辑并确定哪些单元需要进行测试，然后才能针对具体的单元逻辑研究相应的测试方法。

　　推荐使用“路径法”来拆分测试目标。所谓路径法，就是在测试目标运行期间，以代码执行的路径作为单元逻辑来拆分框架的方法。我们可以数据流程图为指导，研究数据在测试目标内的流转路线，数据在测试目标内流转的路线也可以认为是程序代码的执行路径。

　　有些路径在系统运行期间必然会被执行到，这些路径称为“关键路径”。我们需要分析确定系统中的关键路径，即程序运行必然要调用或执行的代码，其质量必须得到确切保证，因为这部分代码一旦出错则系统必然无法运转，一般应通过严格的代码评审和代码Review的方法确保其正确性和稳定性，对其进行单元测试的优先级可以调低，无须立即着手进行。

　　有些路径在系统运行期间不一定总是被执行到，这些路径是在系统运行期间由系统根据实际情况动态选择执行的，因此我们把这类代码路径称为“动态路径”。动态路径是在运行期间被动态选择执行的，有些路径可能只会在特定情况下才能得到执行的机会，可能在很长时间内、多数情况下都不会执行，因此其中存在的错误或潜在的缺陷可能在很长时期内都不会直接暴露出来，即使这种错误或缺陷十分明显。如果对这些代码实行合理的单元测试，则可以及时的发现代码中存在的问题，将其消灭于初始状态，从而使我们的代码质量得到提高，并为我们后来可能对其进行的重构提供一定程度上的质量保证。因此系统中的动态路径是我们进行单元测试需要重点关注的目标，单元测试正是由于系统中动态路径的存在方能发挥其显著作用彰显其显著意义。

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

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

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

　　5.3.3    输出

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