实际开发16- 单元测试

目录

1. What‘s 单元测试

1. 单元测试原则 / 一般准则

2. 单元测试的目标和要求

1. 目标 : 单元模块被正确编码

3. 单元测试的主要内容 ( 目标 / 依据 / 过程 / 执行者 / 采用方法 /... )

1. 模块独立执行通路测试

2. 模块局部数据结构测试

3. 模块接口测试

4. 模块边界条件测试

5. 模块的各条错误处理通路测试

4. 谁承担单元测试的职责 ( Who )

2. 单元测试的意义 / 好处 / 必要性

1. 为何要进行单元测试

1. 单元测试是不是太浪费时间了 ？

2. 单元测试仅仅是为了证明这些代码作了什么吗 ？

3. 我是一个很棒的程序员，是不是可以不进行单元测试呢 ？

4. 有集成测试就够了 , 集成测试将会抓住所有的 Bug

5. 单元测试的成本效率不高 ？

2. 单元测试的重要性

1. 开发流程时间表 与 修改 Bug 代价的关系图 ~ pic

---

1. What‘s 单元测试

单元测试是什 么？

单元测试，对单个的软件单元或者一组相关的软件单元所进行的测试，是代码级的测试。

Unit：函数，源代码文件，类

把测试比作是清洗一台机器 ：

• 系统测试就是清除机器外面的尘土。

• 集成测试就是保证机器各个部件的接头处干净。

• 单元测试就是清洗各个零件的内部。

单元测试的一系列活动:

1. 建立单元测试环境，包括在集成开发环境中安装和设置单元测试工具（插件）；

2. 测试脚本（测试代码）的开发和调试；

3. 测试执行及其结果分析。

---

1. 单元测试原则 / 一般准则

单元测试原则

• 应该尽早地进行软件单元测试。

• 应该保证单元测试的可重复性。

• 尽可能地采用测试自动化的手段来支持单元测试活动。

单元测试的一般准则:

• 软件单元功能与设计需求一致。

• 软件单元接口与设计需求一致。

• 能够正确处理输入和运行中的错误。

• 在单元测试中发现的错误已经得到修改并且通过了测试。

• 达成了相关的覆盖率的要求。 完成软件单元测试报告。

---

2. 单元测试的目标和要求

---

1. 目标 : 单元模块被正确编码

• 信息能否正确地流入和流出单元；

• 在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。

• 在为限制数据加工而设置的边界处，能否正确工作。

• 单元的运行能否做到满足特定的逻辑覆盖。

• 单元中发生了错误，其中的出错处理措施是否有效。

• 指针是否被错误引用、资源是否及时被释放。

• 有没有安全隐患？是否使用了不恰当的字符串处理函数等。

---

3. 单元测试的主要内容 ( 目标 / 依据 / 过程 / 执行者 / 采用方法 /... )

• 目标：确保模块被正确地编码。

• 依据：详细设计描述。

• 过程：经过设计、脚本开发、执行、调试和分析结果等环节。

• 执行者：由程序开发人员和测试人员共同完成。

• 采用那些测试方法：包括代码控制流和数据流分析方法，并结合参数输入域的测试方法。

• 测试脚本的管理：可以按照产品代码管理的方法进行类似的配置（并入代码库），包括代码评审、版本分支、变更控制等。

• 如何进行评估：通过代码覆盖率分析工具来分析测试的代码覆盖率、分支或条件的覆盖率。

---

1. 模块独立执行通路测试

检查每一条独立执行路径的测试。保证每条语句被至少执行一次。

Checklist :

• 误解或用错了算符优先级。

• 混合类型运算。

• 变量初始化错误、赋值错误。

• 错误计算或精度不够。

• 表达式符号错等。

---

2. 模块局部数据结构测试

检查局部数据结构完整性

Checklist :

• 不适合或不相容的类型说明。

• 变量无初值。

• 变量初始化或缺省值有错。

• 不正确的变量名或从来未被使用过。

• 出现上溢或下溢和地址异常。

---

3. 模块接口测试

检查模块接口是否正确

checklist :

• 输入的实际参数与形式参数是否一致。 (个数、属性、量纲)

• 调用其他模块的实际参数与被调模块的形参是否一致。 (个数、属性、量纲)

• 调用预定义函数时所用参数的个数、属性和次序是否正确

• 全程变量的定义在各模块是否一致。

• 外部输入、输出 ( 文件、缓冲区、错误处理 )

---

4. 模块边界条件测试

检查临界数据处理的正确性

Checklist :

• 普通合法数据的处理。

• 普通非法数据的处理。

• 边界值内合法边界数据的处理。

• 边界值外非法边界数据的处理。

• 其它

---

5. 模块的各条错误处理通路测试

预见、预设的各种出错处理是否正确有效。

Checklist :

• 输出的出错信息难以理解。

• 记录的错误与实际遇到的错误不相符。

• 在程序自定义的出错处理代码运行之前，系统已介入。

• 异常处理不当。

• 错误陈述中未提供足够的定位出错的信息。

---

4. 谁承担单元测试的职责 ( Who )

• 单元测试可以是开发者本人执行，也可以是独立的专业测试人员执行。

• 两者各有优势。

• 建议开发人员必须完整地做单元测试，同时测试人员针对重点模块实施独立的单元测试。

---

2. 单元测试的意义 / 好处 / 必要性

• 最高的成本收益比

• 减少联调和后续测试的时间

• BUG更容易定位

• 更有信心去修改老代码

---

1. 为何要进行单元测试

• 尽早发现错误 ( 错误发现越早 , 成本越低. 发现问题比较容易 修正问题更容易 )

• 检查代码是否符合设计和规范

---

1. 单元测试是不是太浪费时间了 ？

1、不经过单元测试，直接进入集成测试，系统正常工作的可能性非常低，大量的时间被花费在跟踪那些简单的 Bug 上，会导致集成为一个系统时增加额外的工期。

2、编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。但是，一旦完成了这些单元测试工作，很多 Bug 将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作，这才是真正意义上的进步。

3、调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

---

2. 单元测试仅仅是为了证明这些代码作了什么吗 ？

• 这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发人员提出的一条普遍的抱怨。 这样的测试完全基于已经写好的代码，这无法证明任何事情。

• 单元测试基于详细设计文档，这样的测试可以找到更多的代码错误，甚至是详细设计的错误。

• 因此，高质量的单元测试需要高质量的详细设计文档。

---

3. 我是一个很棒的程序员，是不是可以不进行单元测试呢 ？

• 每个人都可能犯错误。

• 真正的完整的系统往往是非常复杂的，不能寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。

---

4. 有集成测试就够了 , 集成测试将会抓住所有的 Bug

• 系统规模愈来愈大，复杂度愈来愈高，没有单元测试，开发人员很可能会花费大量的时间仅仅是为了使该系统能够运行。

• 任何实际的测试方案都无法执行。

• 在系统集成阶段，对单元功能全面测试的负载程度远远的超过独立进行的单元测试过程。

• 最后的结果是测试将无法达到它所应该有的全面性，一些缺陷将被遗漏，并且很多Bug将被忽略过去。

---

5. 单元测试的成本效率不高 ？

• 无论什么时候做出修改都要进行完整的回归测试。

• 在生命周期中尽早的对产品进行测试将使效率和质量得到最好的保证

• Bug 修改越晚，费用就越高，单元测试是一个在早期抓住 Bug 的机会。

• 相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。

• 从全程的测试费用来考虑，相比复杂且旷日持久的集成测试，或是不稳定的系统，单元测试所需的费用是最低的。

---

2. 单元测试的重要性

• 一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的 Bug，并且修改它们的成本也很低。

• 系统开发的后期阶段，Bug 的检测和修改将会变得更加困难，并要消耗大量的时间和开发费用。

• 无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽早的对产品代码进行测试将是效率和质量得到最好的保证。

• 在提供了经过单元测试的情况下，系统集成过程将会大大的简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不会陷入充满很多Bug的单元之中不能自拔。

• 使测试工作的效率发挥到最大化的关键在于选择正确的测试策略，这包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当的使用好工具来支持测试过程。

---

1. 开发流程时间表 与 修改 Bug 代价的关系图 ~ pic

• 编程过程中，每写 1000 行代码会犯几十个错误

• 编程与编译运行结束后，每 1000 行代码中大约残留有 2-6 个 Bug

• 寻找与修改程序错误的代价占总体开发投资的 30% -60%

• Bug 在整个研发流程中被发现的越早，修改的代价就越低

这篇好文章是转载于：学新通技术网