|
|
|
单元测试是通过对每个最小的软件模块进行测试，对源代码的每一个程序单元实行测试，检查各个程序模块是否正确地实现了规定的功能，确保其能正常工作。
|
|
|
|
单元测试由开发人员执行，一般由模块单元开发者设计测试用例并修改缺陷。单元测试具有如下三种行为：
|
|
|
|
（1）单元测试是一种验证行为。验证程序中的每项功能的正确性为代码的重构提供了保障。
|
|
|
|
（2）单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等，而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计，而不仅仅定位于代码的实现。
|
|
|
|
（3）单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（4）单元测试确定变动后的代码对原代码的功能未做修改。
|
|
|
|
|
|
|
|
|
|
（8）单元测试支持变化，任何变化导致的失败情况均会被反映出来。
|
|
|
|
（9）单元测试准确地反映了代码设计，便于后期维护。
|
|
|
|
|
|
（1）单元测试是全部规范。单元测试本质上是种特定的测试方式，是系统的实现方法规范的补充，而不是整个规范。
|
|
|
|
（2）单元测试浪费时间。单元测试不会浪费太多的时间，反而会节省项目时间。
|
|
|
|
（3）单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖，必须进行人工检查。
|
|
|
|
（4）单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例，不仅仅只是对代码的测试。
|
|
|
|
|
|
|
|
（1）单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档，根据详细设计编写单元测试用例，而不能根据代码编写单元测试用例。
|
|
|
|
（2）单元测试执行前先检查单元测试入口条件是否全部满足。
|
|
|
|
（3）单元测试必须满足一定的覆盖率，重要的接口函数必须做单元测试。
|
|
|
|
（4）单元测试在修改代码后修改测试用例，将全部单元测试用例进行回归测试。
|
|
|
|
|
|
（6）在单元测试完成后，记录《单元测试报告》，分析问题的种类和原因。
|
|
|
|
（7）单元测试始终在配置管理控制下进行，软件问题的修改必须符合变动规程的要求。
|
|
|
|
（8）单元测试文档、测试用例、测试记录和被测程序等齐全，符合规范。
|
|
|
|
|
|
单元测试主要针对程序模块进行测试，主要有5个任务：模块接口、局部数据结构、执行路径、出错处理和边界条件。
|
|
|
|
|
|
通过对被测模块的数据流进行测试，检查进出模块的数据是否正确。因此，必须对模块接口，包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容：
|
|
|
|
.模块接受输入的实际参数个数与模块的形式参数个数是否一致。
|
|
|
|
|
|
.输入的实际参数与模块的形式参数所使用的单位是否一致。
|
|
|
|
.调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
|
|
|
|
.调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。
|
|
|
|
.调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位是否一致。
|
|
|
|
.调用内部函数时，参数的个数、属性和次序是否正确。
|
|
|
|
.在模块有多个入口的情况下，是否引用有与当前入口无关的参数。
|
|
|
|
|
|
.全局变量是否在所有引用它们的模块中都有相同的定义。
|
|
|
|
|
|
测试用例检查局部数据结构的完整性，如数据类型说明、初始化、默认值等方面的问题，并测试全局数据对模块的影响。
|
|
|
|
在模块的工作过程中，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
|
|
|
|
局部数据结构应注意以下几类错误：不正确或不一致的类型说明；错误的初始化或默认值；错误的变量名，如拼写错误或书写错误；下溢、上溢或者地址错误。
|
|
|
|
|
|
测试用例对模块中重要的执行路径进行测试，其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
|
|
|
|
常见的错误有误解或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。
|
|
|
|
针对判定和条件覆盖，测试用例能够发现的错误有：不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。
|
|
|
|
|
|
测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
边界条件测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处，测试模块是否能够正常工作。
|
|
|
|
一些与边界有关的数据类型，如数值、字符、位置、数量、尺寸等，以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
|
|
|
|
|
|
|
|
|
|
.数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
|
|
|
|
|
|
通常，单元测试在编码阶段进行，在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，开始设计单元测试用例。
|
|
|
|
由于模块并不是一个独立的程序，在考虑测试模块时，同时要考虑与其有关的外界联系，因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种：
|
|
|
|
（1）驱动（Drive）模块。用于模拟被测试模块的上一级模块，相当于被测模块的主程序，用于接收测试数据，并把这些数据传送给被测模块，启动被测模块，最后输出实测结果。
|
|
|
|
（2）桩（Stub）模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理，不需要把子模块的所有功能都带进来，但不允许什么事情也不做。
|
|
|
|
|
|
|
|
|
|
|
|
（3）达到了测试计划中关于单元测试所规定的覆盖率的要求。
|
|
|
|
（4）被测试的单元每千行代码必须发现至少3个错误。
|
|
|
|
|
|
（6）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
|
|
|
