软件单元测试（静态、动态测试）设计.docx

软件单元测试（静态、动态测试）设计 软件单元测试〔静态、动态测试〕设计 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检查表检查项 检查函数的逻辑正确性；所编写的代码算法、 数据构造定义〔如：队列、堆栈等〕是否实现了所要求的功能 函数接口的正确性检查；形式参数个数、数据 利用TestBed测试工具代码规那么检查类型、依次是否正确；返回值类型及返回值是〔其中包含数据流分析规那么列表〕完成 否正确 输入参数有没有作正确性检查；假如没有作正 确性检查，确定该参数是否确实无需做参数正确性检查，否那么请添加上参数的正确性检查 程序风格的相同性、标准性是否符合《软件编 码标准》 函数内部注释是否完整，是否清楚简洁；是否 正确的反映了代码的功能；是否做了多余的注释 函数静态调用关系图是否和设计相同 通过视察TestBed测试工具static Callgraph实现 备注 ? 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覆盖率101%利用TBRun能够得到各类动态覆盖率〔通过Danymic Graph可以看到函数内部是否有未走过的限制流，以此设计相应的测试用例来到达全覆盖率；也可通过Dynamic Coverage Analysis Report获得动态覆盖率分析报告〕。

本文来源：网络收集与整理，如有侵权，请联系作者删除，谢谢！第8页 共8页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页第 8 页 共 8 页。