软件单元测试（静态、动态测试）设计
1测试范围
本文档针对XXXXX软件单元测试。
单元指单个函数或几个函数构成的功能模块。
2测试目的
单元测试是针对软件设计的最小单位——程序模块（函数或功能模块），进行正确性检验的测试工作。
单元测试的依据是详细设计。
在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
其目的在于发现每个程序模块内部可能存在的差错。
单元测试是软件测试的基础，如果不进行单元测试，那么缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。
最糟糕的是无法估计测试与改错的工作量，使进度失去控制。
单元测试工作主要分为两个步骤静态测试和动态测试。
静态测试：静态测试包括代码检查、静态结构分析、数据流分析、控制流分析等。
它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
静态测试通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。
静态测试结果可用于进一步的查错，并为动态测试时的测试用例选取提供指导。
动态测试：通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。
经验表明，使用静态测试法能够有效的发现30%到70%的逻辑设计和编码错误。
但是代码中仍会有大量的隐性错误无法通过视觉检查发现，必须通过动态执行才能够捕捉到。
所以，动态测试也成了单元测试的重点与难点。
3测试环境
静态测试：XP主机+TestBed静态测试工具
动态测试：XP主机+ TBrun单元测试工具+ TBConfig单元测试配置工具（支持目标机平台xxxxxxxxxxx开发环境）+ xxxxxxxxxxx仿真环境
4测试方案
4.1静态测试
4.1.1代码规则检查
遵循标准MISRA-C:2004，利用TestBed测试工具完成。
4.1.2边界值检查
确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），在动态测试中将利用分析结果针对我们的系统在测试过程中输入一些合法数据/非法数据，主要在边界值附近选取。
其中涉及到等价类划分，它是指将所有可能的输入数据（有效的和无效的）划分成若干个等价区间，每个区间选取有代表性的一个或一组数进行测试。
一般按照输入参数边界及函数内部分支来划分等价区。
4.1.3数据流分析
检查数据流异常情况，利用TestBed测试工具完成。
TestBed的Static Data Flow Analysis功能能对以下数据流异常情况（基于工程）进行报告：
–UR声明后没有定义就被引用
–DU 定义后没有被引用
–DD 两次定义之间没有被引用
4.1.4控制流分析
以有向图的方式表示函数内部控制流图（控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句（单入单出，无分支），连
接结点的叫边，边表示节点间的控制流向。
）利用TestBed测试工具Static Flowgraph
可以图形化显示函数内部控制流图，确认其与函数设计流程一致。
检查是否有不可达代码，利用TestBed测试工具LCSAJ分析完成
4.1.5检查表
4.1.6代码走读
根据检查表各项，以及以上各测试方法的要求通过测试工具TestBed并辅以人工方式对代码进行走读，得到各项分析结果。
另外对一些关键模块，例如xxxxxx通信，以及一些和硬件紧密结合的软件模块，组织开发组、测试组及专家组对代码进行逐行走读讨论。
注：以上各项利用TestBed进行分析时均需辅以人工方式协同完成。
4.1.7 猜错分析
模块代码应能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是模块功能的一部分。
测试人员应检查模块代码是否对错误逻辑输入进行检验，对错误条件的处理是否正确等以分析模块的错误处理功能是否包含缺陷。
4.2动态测试
4.2.1测试方案
单元测试是一个在隔离状态下测试单个独立软件单元的过程，如下图所示：
图单元测试
应为测试单元开发一个驱动模块（driver）和（或）若干个桩模块（stub）。
驱动模块在大多数场合称为“主程序”，相当于所测单元的主程序。
它接收测试数据，把这些数据传送给所测单元，最后再输出实际测试结果。
桩模块其实是一个假函数，当被测试的函数要调用另外一个函数，为了避免因调用的函数出错引起的测试函数出错，要建立一个被调用函数的替代函数，这个替代函数就是桩函数
驱动函数和桩函数是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。
所测单元与它相关的驱动模块及桩模块共同构成了一个“测试环境”，
图单元测试的测试环境
使用TBrun单元测试工具可以自动生成测试驱动、桩模块，这样测试人员可将重点放在设计测试用例上。
TBrun分析出被测试的单元的所有函数调用，TBrun 可以自动的创建管理桩，也可以让用户手工创建桩；TBrun 自动创建的管理桩搭建好了一个十分完善，灵活的测试框架，里面包含了大量的测试和追踪信息，即用户能控制这个桩函数
如果函数原型或函数体存在，则参数列表自动被创建，返回类型也自动被创建。
TBrun 提供图形界面方式输入返回值，变量和调用次数信息，也允许在桩函数中插入用户代码。
4.2.2测试步骤
动态测试通常需要做如下三项工作:
1. 设计测试用例；
2. 编写测试驱动与桩模块；
3. 执行测试，记录并分析结果。
测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。
测试输入数据可根据静态分析的结果来选择。
编写测试驱动与桩模块、执行测试、记录并分析测试结果可由TBrun自动执行结合人工操作来共同完成。
4.2.3测试方法
边界值测试
根据静态分析中的边界值分析结果，针对各函数输入参数允许的取值范围，取其边界值以及边界以外的值编写测试用例做测试，以验证在参数取得最
大值和最小值的情况下，以及如超出取值范围时，输出是否正确。
等价类测试
将输入数据进行等价区间划分时可利用TBrun的范围测试（range），给定范围的初始值、范围的最大值、步长（即测试用例之间的间隔），TBrun会生
成每个单独的测试用例。
在设计测试用例还应该考虑包括输入参数的条件边界（即函数内部的if, while，for，switch 子句等）。
错误推测法
列举出程序中所有可能的错误和容易发生错误的特殊情况，根据它们选择测试用例
4.2.4测试覆盖率要求
利用单元测试进行覆盖率分析。
通常覆盖率需求可以包括语句覆盖，分支覆盖，条件覆盖等。
语句覆盖：指选择足够的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次
分支覆盖：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次
条件覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
XXXXX软件单元测试应达到xxxx覆盖率100%。
利用TBRun能够得到各类动态覆盖率（通过Danymic Graph可以看到函数内部是否有未走过的控制流，以此设计相应的测试用例来达到全覆盖率；也可通过Dynamic Coverage Analysis Report获得动态覆盖率分析报告）。
