单元测试任务

比较判断与控制流常常紧密相关，测试用例还 应致力于发现下列错误： 1不同数据类型的对象之间进行比较； 2错误地使用逻辑运算符期望理论上相等 而实际上不相等的两个量相等； 4比较运算或变量出错； 5循环终止条件或不可能出现； 6迭代发散时不能退出； 7错误地修改了循环变量。
单元测试任务
单元测试理论基础
李振学
单元测试理论基础
测试是软件开发的重要环节之一。按照软件开发的过程测试可分为： 单元测试、集成测试、系统测试、域测试（Field test）等。我们 这里将讨论面向程序员的单元测试。 单元测试定义 单元测试目的 单元测试的特点 单元测试的范畴 进行单元测试的时机 单元测试任务 单元测试方法 单元测试过程
单元测试的优点

它具有回归性。 自动化的单元测试避免了代码出现回 归，编写完成之后，可以随时随地的快 速运行测试。
单元测试的范畴

如果要给单元测试定义一个明确的范畴，指 出哪些功能是属于单元测试，这似乎很难。但 下面讨论的四个问题，基本上可以说明单元测 试的范畴，单元测试所要做的工作。 它的行为和我期望的一致吗？ 这是单元测试最根本的目的，我们就是用单 元测试的代码来证明它所做的就是我们所期望 的。
单元测试的范畴

我可以依赖单元测试吗？ 不能依赖的代码是没有多大用处的。 既然单元测试是用来保证代码的正确性， 那么单元测试也一定要值得依赖。
单元测试的范畴

单元测试说明我的意图了吗？ 单元测试能够帮我们充分了解代码的 用法，从效果上而言，单元测试就像是 能执行的文档，说明了在你用各种条件 调用代码时，你所能期望这段代码完成 的功能。
单元测试的优点
它是一种验证行为 它是一种设计行为 它是一种编写文档的行为 它具有回归性

单元测试的优点

它是一种验证行为。 程序中的每一项功能都是测试来验证 它的正确性。它为以后的开发提供支缓。 就算是开发后期，我们也可以轻松的增 加功能或更改程序结构，而不用担心这 个过程中会破坏重要的东西。而且它为 代码的重构提供了保障。这样，我们就 可以更自由的对程序进行改进。
测试用例文档
测试记录文档
缺陷跟踪报告
完毕
测试总结报告测试总结Fra bibliotek单元测试过程
测试计划内容：
1) 概要：明确测试目的和主要任务，被测系统的简单描述， 被测系统依赖的其它系统描述 2) 领域：定义测试和不需要测试的内容，描述与测试计划相 关的重要术语和缩略语，测试场所 3) 建议的重大事件时间表：列出阶段性进度 4) 转换标准：允许系统进入一个特定的测试阶段所必须具备 的条件。定义可能会导致测试执行挂起的状态和事件。说 明如何决定测试何时可以结束 5) 测试配臵和环境： 6) 测试执行：测试人员与分工，错误管理，测试周期等；
单元测试的优点

它是一种设计行为。 编写单元测试将使我们从调用者观察、 思考。特别是先写测试（test-first），迫 使我们把程序设计成易于调用和可测试 的，即迫使我们解除软件中的耦合。
单元测试的优点

它是一种编写文档的行为。 单元测试是一种无价的文档，它是展 示函数或类如何使用的最佳文档。这份 文档是可编译、可运行的，并且它保持 最新，永远与代码同步。
单元测试过程
错误管理-修改级别： 1) 高 2) 中 3) 低
单元测试过程
错误管理-错误描述：
1 分配给错误的ID号 3 错误提交人 5 错误发生的条件 2 提交错误的时间 4 版本号 发生错误的子系统或模块 6 对错误的详细描述
7 所使用的测试用例号
9 使用的机器号 11 错误的改正优先级 13 错误是否易再现
什么是单元测试

单元测试是开发者编写的一小段代码，用于检 验被测代码的一个很小的、很明确的功能是否 正确。通常而言，一个单元测试是用于判断某 个特定条件（或者场景）下某个特定函数的行 为。例如，你可能把一个很大的值放入一个有 序list 中去，然后确认该值出现在list 的尾部。 或者，你可能会从字符串中删除匹配某种模式 的字符，然后确认字符串确实不再包含这些字 符了。
什么是单元测试

单元测试是由程序员自己来完成，最 终受益的也是程序员自己。可以这么说， 程序员有责任编写功能代码，同时也就 有责任为自己的代码编写单元测试。执 行单元测试，就是为了证明这段代码的 行为和我们期望的一致。
为什么要使用单元测试
我们编写代码时，一定会反复调试保证它能够编 译通过。如果是编译没有通过的代码，没有任 何人会愿意交付给自己的老板。但代码通过编 译，只是说明了它的语法正确；我们却无法保 证它的语义也一定正确，没有任何人可以轻易 承诺这段代码的行为一定是正确的。 幸运，单元测试会为我们的承诺做保证。编 写单元测试就是用来验证这段代码的行为是否 与我们期望的一致。有了单元测试，我们可以 自信的交付自己的代码，而没有任何的后顾之 忧。

单元测试任务

模块接口测试是单元测试的基础。只有在数据 能正确流入、流出模块的前提下，其他测试才 有意义。测试接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否 相同； 2 输入的实际参数与形式参数的属性是否 匹配； 3 输入的实际参数与形式参数的量纲是否 一致； 4 调用其他模块时所给实际参数的个数是 否与被调模块的形参个数相同；
单元测试过程
测试用例内容：
1 用例编号 2 用例名称 3 测试目的 4 输入数据 5 测试步骤 6 测试脚本 7 预期结果 8 响应时间 9 实际输出 10用例类别 11用例状态 12用例设计人 13创建时间 14用例评审人 15评审时间 16评审结果 17执行结果 18相关模块
单元测试过程
错误管理-缺陷的级别： 1) 致命性错误（Critical） • 数据丢失，数据计算错误、系统崩溃和非常死 机 2) 严重功能性错误(Serious) • 规定的功能没有实现或不完整、设计不合理造 成性能低下，影响系统的运营 3) 警告性错误(Moderate) • 不影响业务运营的功能问题 4) 建议性错误(Suggestion,Cosmetic) • 软件设计和功能实现等不甚合理之处提出建议
分析测试记录，如 果发现与预期结果 不同，确定并重现 缺陷。
检查测试设计是否 全部执行完毕，缺 陷是否全部关闭。
分析
完毕 测试总结
缺陷跟踪
分析测试过程和缺陷报告， 评估测试质量和测试效果， 给出是否通过测试的建议。
单元测试过程
测试文档：
测试计划 测试设计 测试执行 测试记录 分析 缺陷跟踪
测试计划文档

一个好的设计应能预见各种出错条件，并预设 各种出错处理通路，出错处理通路同样需要认 真测试，测试应着重检查下列问题： 1输出的出错信息难以理解； 2记录的错误与实际遇到的错误不相符； 3在程序自定义的出错处理段运行之前， 系统已介入； 4异常处理不当； 5错误陈述中未能提供足够的定位出错信 息。
单元测试任务

边界条件测试是单元测试中最后，也是 最重要的一项任务。众所周知，软件经 常在边界上失效，采用边界值分析技术， 针对边界值及其左、右设计测试用例， 很有可能发现新的错误。
单元测试策略
桩模块（Stub）：用以模拟被测模块工作过程中所 调用的模块，他们一般只进行很少的数据处理，例 如打印入口和返回； 驱动模块(Driver）：用以模拟被测模块的上级模块， 它接受测试数据，把相关的数据传送给被测模块， 启动被测模块，并打印相应的结果；
单元测试策略
•
由顶向下的单元测试策略； - 先对最顶层的单元进行测试，把顶层所调用的单 元做成桩模块，其次对第二层进行测试，使用上面已 测试的单元做驱动模块，以此类推； • 由底向上的单元测试策略； - 先对模块调用层次图上最底层的模块进行单元测 试，为该模块建立驱动模块，其次对上一层做单元测 试，下面测试过的模块做桩模块，以此类推； • 孤立测试 - 不考虑每个模块与其他模块之间的关系，为每个 模块设计桩模块和驱动模块；
8 错误被发现的数据库
10 错误的重要性
12发生错误的子系统或模块及相关 的模块
14 其他
单元测试过程
错误管理-错误跟踪：
1 错误负责人 2 严重性 3 优先级 4 估计改正错误的日期 6 错误改正后需要重新做 的测试 7 改正错误所影响的组件 8 目前错误的状态 9 错误类别
单元测试过程
测试计划内容：
7) 风险和意外事故：意外事件的对策 8) 更改记录：到目前为止对测试计划本身所作的更改和修订。 内容可包括：编号、更改人、更改内容、修订的发布时间 等。 9) 参考文档：测试计划引用的其他文档。如: 需求规范、设 计规范、操作手册、标准、其他相关信息。
单元测试过程
测试方案内容： 1) 概要 2) 被测试特性：进一步明确和细化被测试的特性 3) 测试需求：分析和明确功能等各方面的测试需求 4) 测试方法：拟采用的具体测试技术和方法 5) 需求规范追踪：把测试需求转化为测试设计 6) 测试用例集描述：对测试用例分层次说明 7) 更改记录 8) 参考文档
单元测试任务

检查局部数据结构是为了保证临时存储在模 块内的数据在程序执行过程中完整、正确。局 部数据结构往往是错误的根源，应仔细设计测 试用例，力求发现下面几类错误： 1 不合适或不相容的类型说明； 2变量无初值； 3变量初始化或省缺值有错； 4不正确的变量名（拼错或不正确地截 断）； 5出现上溢、下溢和地址异常。 除了局部数据结构外，如果可能，单元测 试时还应该查清全局数据（例如FORTRAN的 公用区）对模块的影响。
单元测试任务

5 调用其他模块时所给实际参数的属性是否 与被调模块的形参属性匹配； 6调用其他模块时所给实际参数的量纲是 否与被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属 性和次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数； 10 对全程变量的定义各模块是否一致； 11是否把某些约束作为参数传递。