单元测试大揭密

单元测试大揭密 

http://blog.csdn.net/vincetest

• 它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。
• 我是一个很棒的程序员，我写的代码肯定是没有问题的。
• 做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在不行在系统测试总该能发现吧。
• 它仅仅是证明这些代码做了什么。

对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。 1.2      测试的重要性 单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。

• 时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。
• 测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。

•  语句覆盖（StatementCoverage）：也称为行覆盖（linEC）,段覆盖（segmentcoverage）和基本块覆盖（bAS）。它度量每一个可执行语句是否被执行到了。icblockcoverageoverage
• 判定覆盖（DecisionCoverage）：也被称为分支覆盖（branchcoverage），所有边界覆盖（all-edgescoverage），基本路径覆盖（basispathcoverage），判定路径覆盖（decision-decision-path或DDPtesting）。它度量是否每个BOO型的表达式取值true和false在控制结构中都被测试到了。L
•  条件覆盖（ConDI）：它独立的度量每一个子表达式， 告每一个子表达式的结果的true或false。这个度量和判定覆盖（decisioncoverage）相似，但是对控制流更敏感。不过，完全的条件覆盖并不能保证完全的判定覆盖。tionCoverage
•  路径覆盖（PathCoverage）：也称为断言覆盖（prEDI），它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是：需要彻底的测试。但有两个缺点：一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048；二是，许多路径不可能与执行的数据无关。catecoverage

2.2      测试的内容 单元测试的对象是软件设计的最小单位——模块或函数，单元测试的依据是详细设描述。测试者要根据详细设计说明书和源程序清单，了解模块的I/O条件和模块的逻辑结构。主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理和不合理的输入都能鉴别和响应。要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。在单元测试中，需要对下面5个方面的内容进行测试，也是构造测试用例的基础。

  3         测试方法与过程 3.1      用例设计 1. 测试用例的组成（在单元测试中测试用例基本上由测试脚本组成）

• 用例运行前置条件
• 被测模块/单元所需环境（全局变量赋值或初始化实体）
• 启动测试驱动
• 设置桩
• 调用被测模块
• 设置预期输出条件判断
• 恢复环境（包括清除桩）

2.测试用例的设计原则

• 一个好的测试用例在于能够发现至今没有发现的错误；
• 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；
• 在测试用例设计时，应当包含合理的输入条件和不合理的输入条件；
• 为系统运行起来而设计测试用例；
• 为正向测试而设计测试用例；
• 为逆向测试而设计测试用例；
• 为满足特殊需求而设计测试用例；
• 为代码覆盖而设计测试用例；

3.用例设计方法 1)        规范（规格）导出发 2)        等价类划分法 3)        边界值分析法 4)        状态转移测试法 5)        分支测试法 6)        条件测试法 7)        数据定义－使用测试法（又名数据流测试法） 8)        内部边界值测试法 9)        错误猜测法 4. 特定的用例测试设计 1)声明测试：检查模块中的所有变量是否被声明。经验表明，大量重要的错误都是由于变量没有被声明或没有被正确的声明而引起的。 2)路径测试：要求模块中所有可能的路径都被执行一遍，属逻辑覆盖测试。 基本路径测试：由于实际中，一个模块中的路径可能非常多，由于时间和资源有限，不可能一一测试到。这就需要把测试所有可能路径的目标减少到测试足够多的路径，以获得对模块的信心。要测试的最小路径集就是基本测试路径集。基本测试路径集要保证：

• 每个确定语句的每一个方向要测试到；
• 每条语句最少执行一次。

3)循环测试：重点检查循环的条件－判断部分以及边界条件。测试循环是一种特殊的路径测试，因为循环比其他语句都复杂一些。循环中错误的发生机会比其他代码构成部分多。因此，对于任何给定的循环测试应该包括测试下面每一条件的测试用例：

•  循环不执行；
•  执行一次循环；
• 执行两次循环；
• 反映执行典型的循环的执行次数；
• 如果有最大循环次数，最大循环次数减1；
• 最大循环次数；
• 大于最大循环次数。

对于增量和减量不是1的FOR语句，要特别注意，因为程序员习惯于增量1。 4) 循环嵌套：循环嵌套使逻辑的次数呈几何级数增长，设计测试嵌套循环的测试用例应该包括的测试条件有：

• 把外循环设置为最小值，并运行内循环所有可能的情况；
• 把内循环设置为最小值，并运行外循环所有可能的情况；
• 把所有的循环变量都设置为最小值运行；
• 把所有的循环变量都设置为最大值运行；
•  把外循环设置为最大值，并运行内循环所有可能的情况；
• 把内循环设置为最大值，并运行外循环所有可能的情况；

•  程序的执行过程―――便于构造发散用例
• 不要放过任何细节―――这种细节可能就是问题

1、测试用例的优化

2、测试执行的优化

• 哪些是重点模块
•  哪些程序是最复杂、最容易出错的
•  哪些程序是相对独立，应当提前测试的
•  哪些程序最容易扩散错误
• 哪些程序是开发者最没有信心的

3.4      测试评估    单元测试完成以后，需要对单元测试的执行效果进行评估，主要从以下几方面进行： 1)测试完备性评估，主要检查测试过程中是否已经执行了所有的测试用例，对新增的测试用例是否已及时更新测试方案等。 2)代码覆盖率评估，主要是根据代码覆盖率工具提供的语句覆盖情况 告，检查是否达到方案中的要求，公司要求语句覆盖达到100％。但很多情况下，第一轮测试用例执行完后是很难达到的，这时在评估过程中要对覆盖率进行分析，主要从以下方面来考虑：

• 不可能的路径或条件
• 不可达的或冗余的代码
• 不充分的测试用例

3) 从覆盖的角度看，测试应该覆盖：

•  功能覆盖
•  输入域覆盖
• 输出域覆盖
• 函数交互覆盖
• 代码执行覆盖

   大多数有效的测试用例都来自于分析，而不是仅仅为了达到测试覆盖率目标而草率设计测试用例。千万不要误解测试覆盖，测试覆盖并不是我们最求的目的，它只是评价测试的一种方式，为测试提供指导和依据。 3.5      测试过程 1.测试过程中各种人员的作用

• 系统分析设计人员

• 软件开发人员

• 软件测试人员

     参与单元测试计划、方案和 告的评审，对单元测试的计划、设计和执行质量进行监控。根据实际情况，可选择参与由开发人员负责的代码检视、单元测试等活动。

•  配置管理人员

    对代码及单元测试文档进行配置管理。

• 质量保证（QA）人员

     参与编码与单元测试评审，对编码和单元测试过程进行审计。 2.  单元测试输入

• 《软件需求规格说明书》
• 《软件详细设计说明书》
• 《软件编码与单元测试工作任务书》
• 《软件集成测试计划》
• 《软件集成测试方案》
• 用户文档

3.单元测试的输出

• 《单元测试计划》
• 《单元测试方案》
• 《需求跟踪说明书》或需求跟踪记录
•  代码静态检查记录
• 《正规检视 告》
•  问题记录
•  问题跟踪和解决记录
• 软件代码开发版本
• 《单元测试 告》
• 《软件编码与单元测试任务总结 告》

3.6      测试实施 1.  单元测试实施步骤 1)        制定测试计划和测试方案（包括测试工具的选择） 2)        根据计划和方案及相关输入文档编写测试用例 3)        搭建测试环境 4)        执行测试 5)        记录和跟踪问题 6)        编写测试 告和总结 告 2.  单元测试实施遵循的原则

•  精心制定测试计划
•  严格评审测试计划
•  严格执行测试计划
• 系统分析测试结果并提交 告

• 脚本化测试驱动
• 脚本桩
•  在线测试
•  即时调测
• 测试工程管理

•   即时测试类/函数
• 支持极端编程模式下的代码测试
• 自动建立类/函数的测试驱动程序和桩调用
• 自动建立和执行类/函数的测试用例
• 提供快速加入和执行说明和功能性测试的框架
•  执行自动回归测试
•  执行部件测试(COM)

4)        相关 站 http://www.parasoft.com 

欢的 站： 新浪 Google新闻 搜狐新闻 雅虎 天极 CSDN新闻 CSDN博客 B周刊 博客中心 DoNews博客 SourceForge ShareIt 无忧测试 VC在线 共创联盟 华军软件园