软件单元测试

单元测试心得体会

2014/6/9

一、背景/概述：

1、单元测试的概念：

单元测试（unit testing），是指对软件中的最小可测试单元（功能模块）进行检查和验证。

2、单元测试的重要性：

保证功能模块代码的正确性，保证不会有大量的bug遗留到产品系统测试中，让bug尽早的被发现。

二、普遍存在的问题及现状

1、开发人员存在的错误观念

1) 测试是测试部门的责任，我的责任应该关注在与代码上

2) 我们有测试人员，有集成/系统/确认测试，他们迟早会发现我的错误的。

3) 项目进度如此紧急，我没有时间做测试。

2、产品质量隐患

1) 软件的质量完全取决于程序员的个人技能和责任心，具有很大的随机性。

2) 系统测试阶段，发现很多bug，且很难把问题定位。

3) 后期维护成本高昂，1个月的开发，几天的测试，然后花几个月的时间去修补错误。

4) 公司测试不出的bug，总被客户发现。

缺陷的发现时间越晚，修复的成本越高，在部署阶段每个缺陷的修复成本都会及其高昂（每一个major以上的缺陷修复都不得不作完整的系统测试和确认测试）,严格实施scm的组织尤其昂贵。

3、根本原因：

1) 错误可能会随机的分布在产品代码的任何一个地方。

2) 编码阶段引入的缺陷远远多于其它阶段。

3) 系统测试发现的缺陷大多数是编码缺陷。

4) 模块功能的缺陷引入到系统集成后，隐藏性会更深，破坏力会更强。

三、正确的意识和理念

1、开发人员方面

1）测试产品的bug，不单是测试人员的工作，更多的是开发人员的职责，开发人员有责任保证产品的质量。

2）程序员必须对自己的代码质量负责，单元测试是对自己代码质量的基本承诺，程序员=UT+CODE。

3）要在开发过程中引入单元测试，使产品的大部分bug在最初阶段被发现。

4）越早发现bug，修复成本越少。

2、测试人员方面

1）测试必须并行的融入到软件开发生命周期的各个阶段，以覆盖软件结构和开发生命周期的不同关注点。

2）测试是基于需求测试，而不是基于开发测试，故测试人员的参考文档除了开发人员提供的技术文档，要更多的依据产品需求文档，以及基于风险测试，基于用户体验测试。

3、项目管理方面

1）在产品的进度与质量权衡中，要坚持以质量为核心。

2）要建立公司知识库，积累开发经验案例及工作总结。

四、单元测试的实施

1、单元测试要尽早的落实到开发中。

1)测试活动融入整个软件开发

的生命周期

2)不同阶段的测试强调的是从

不同视角关注不同的方面，

尽可能早而全的出去错误，

不累计错误。

3)每一种类型测试的效果，将

严格依赖于前期阶段其他类

型测试的执行的正确，完整

与否。

4)测试有分工，合适的人在合

适的时候承担合适的测试

2、规范单元测试的流程

3、单元测试的技术

单元测试技术有两种，静态测试及动态测试

1）静态测试，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。

方法有如下几种：

- 走查：WalkThrough

- 审查：Inspection

- 评审：Review

辅助的检查工具：

- 代码检查工具PC-LINT

- 内在检查工具Boundschecker

- 覆盖率工具Logiscope

2）动态测试，是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能。

由三部分组成：

- 构造测试实例

- 执行程序

- 分析程序的输出结果。

推荐的工具：

- cpp unit

- C Unit

- Visual Unit 4.0 betal

条件：需要编写测试驱动和测试桩

单元本身不能独立运行，所以必须为每个单元测试开发驱动模块(Driver)和桩模块(Stub)以构成一个可运行的软件系统进行测试。

“驱动模块”是一个接收测试数据，并把数据传送给（被测试）模块，然后显示或比较相关结果的“主程序”

“桩模块”是替代那些隶属于本模块（被调用）的模块，使被测对象得以运行

五、关于单元测试的一些建议

结合公司的实际情况，及自身对单元测试的理解，给出一些相关建议。

1、增强开发人员的测试意识及质量责任感。

2、严格遵守编程规范，编写简洁，可靠，可维护，可测试，可移植的代码。

3、对于软件单元测试，最初阶段可以使用静态测试方法，可以用较少的资源达到较好的效果。

把静态测试分为三个活动，每次活动时间控制在1-2小时，在产品的工作样机提交测试前完成。

走查-活动：

- 软件组内部进行，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。- 由代码开发人者进行讲解，回答并记录

- 不要现场修改

- 检查要点为，逻辑错误，代码标准/规范/风格

审查-活动：

- 开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的

活动，并提交结果报告。

- 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表，代码开发者回答问题并记录

- 不要现场修改

- 检查要点为，设计需求，代码标准/规范/风格

评审-活动：

- 软件组、测试组和相关人员(PM、SE等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。并提交结果报告。

- 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表，代码开发者回答问题并记录

- 不要现场修改

- 检查要点为，设计需求，文档的完整性和一致性

单元测试的准则：

- 采用二八定律，20%的常用功能要重点测试

- 新增的功能模块，需重点测试

- 新平台，新组件，新通用模块需重点测试

- 修改变性的代码需重点测试