软件测试 第6章单元测试.doc

第6章单元测试1. 单元测试概述1 什么是单元n 传统软件对“单元”一词有着不同的定义Ø 单元是可以编译和执行的最小软件组件Ø 单元是决不会指派给多个设计人员开发的软件组件n “单元”与被测软件系统所采用的分析设计方法以及在其开发过程中采用的实现技术有关Ø 函数、子程序、紧密相关的一组函数、类、复杂类中的单个方法、紧密相关的一组类n 基本单元Ø 必须具备一定的基本属性，有明确的规格定义，以及包含与其他部分接口的明确定义等Ø 从软件工程的角度来说，具有功能的独立性、符合高内聚和低耦合的特性Ø 能够清晰地与同一程序中的其他单元划分开来2 什么是单元测试？n 通常而言，单元测试是在软件开发过程中要进行的最低级别的测试活动n 或者说是针对软件设计的最小单位即程序模块、函数、类或方法所进行的正确性检验的测试工作n 其目的在于发现每个单元内部可能存在的错误或缺陷单元测试的主要工作分两个步骤：2.1 人工静态检查（静态测试）Ø 保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性Ø 尽可能地发现程序中可能存在的错误或缺陷2.2 动态执行跟踪（动态测试）Ø 通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误或缺陷3 什么时候进行单元测试3.1 单元测试越早越好3.2 在测试驱动开发（TDD, Test Driven Development）中，先编写测试代码，再进行开发3.3 在实际过程中，先写函数的框架，再针对函数的功能编写测试用例，然后编写函数的实现代码。一边编写代码，一边测试，往往会有比较好的效果。4 单元测试由谁来执行4.1 一般情况下由程序员完成单元测试工作Ø 单元测试也可以看作是编码工作的一部分，在编码的过程中考虑测试问题，得到的将是更优质的代码Ø 所以，单元测试有时也称自测试Ø 许多集成开发环境（IDE）可以集成各种单元测试工具帮助编码人员进行单元测试，如Eclipse环境中集成Junit4.2 必要时可以由测试团队专门进行单元测试5 单元测试的一般流程5.1 开发小组承担单元测试5.2 在开发负责人（Leader）的监督下进行5.3 根据单元测试计划和测试说明文档，设计测试用例，执行充分的测试，达到覆盖要求5.4 建议专人负责监控测试过程5.5 单元测试具有回归性6 单元测试的实质n 主要是证明代码的行为和我们的期望是否一致Ø 在进行单元测试时常常并不关心整个产品或系统的确认、验证及其正确性等方面Ø 主要侧重于功能Ø 有时也关注性能方面的问题n 只有所有单元的行为都通过了验证，确保它和我们的期望一致，才能开始进行集成测试n 所以，足够的单元测试的好处在于：Ø 使开发工作变得更轻松Ø 对设计工作也能提供帮助Ø 大大减少了花费在调试上面的时间7 单元测试的目标n 验证开发人员所编写的代码是否产生预期结果、是否符合设计的要求，最终确保单元符合需求n 代码的质量、可复用性、代码的可维护性及代码的可扩展性的检查也是单元测试的目标n 符合需求的单元代码通常具备以下性质Ø 正确性：代码逻辑正确，能实现预期功能Ø 清晰性：代码简明、易懂，注释准确Ø 规范性：代码符合规范Ø 一致性：代码在命名上、风格上保持统一Ø 高效性：尽可能减少执行时间Ø 可复用性：代码尽量标准化，便于复用8 为什么要进行单元测试n 未经测试覆盖的单元代码可能会存在大量的错误或缺陷Ø 这些错误或缺陷可能是严重的，可能是微小的或表面的Ø 但是，这些错误或缺陷可能会相互影响Ø 尤其在开发后期，错误或缺陷可能会扩展n 这些暴露的错误或缺陷难于定位，结果会大幅度提高后期测试和维护成本，降低了开发商的市场竞争力9 单元测试在软件测试中的作用和地位n 单元测试被认为是集成测试的基础：只有通过了单元测试，才能将各个单元集成在一起进行集成测试n 单元测试通常在项目的详细设计阶段已经开始了，贯穿于项目开发的生命周期中n 单元测试已经不仅仅是只有编码完成以后才能进行的工作了2. 单元测试的环境及过程1 驱动模块（Driver）1.1 扮演被测模块的主程序1.2 接收测试数据，将数据传递给被测模块，最后输出实际测试结果1.3 作用Ø 接受测试输入Ø 对输入进行判断Ø 将输入传给被测单元，驱动被测单元执行Ø 接受被测单元执行结果，并对结果进行判断Ø 将判断结果作为用例执行结果并输出测试报告2 桩模块（Stub）2.1 代替被测模块需要调用的子模块2.2 可以进行少量的数据操作，不需要实现子模块的所有功能2.3 根据需要实现或代替子模块的一部分功能2.4 桩模块是一次性模块，主要是为了配合调用它的父模块2.5 被测模块和与它相关的驱动模块和（或）桩模块共同构成了一个“测试环境”3 单元测试的过程缺陷的提交、跟踪和报告一般借助于工具来支撑，如buzzilla、TestDirector等工具代码审查、用例评审以静态测试作为技术基础用例的设计以黑盒测试方法和白盒测试方法及两种方法的结合作为技术基础是单元测试的进入准则3. 单元测试的策略4. 单元测试分析1. 单元测试分析是单元测试用例设计的基础，全面地分析才能设计出合理的测试用例Ø 涉及详细设计、代码、功能业务需求、非功能业务需求、组件内部数据结构、组件接口等方面2. 单元测试分析的9条指导原则Ø 检查详细设计是否通过评审并验证其和代码逻辑的一致性，为代码审查和白盒测试用例设计服务Ø 分析单元组件涉及到的所有功能点和非功能需求，为功能性和非功能性用例设计服务Ø 分析单元组件是否满足所有的边界条件，为经典的边界值方法设计用例服务Ø 对强制发生的一些错误情况进行分析，为意外情况设计补充用例服务Ø 分析被测单元组件接口Ø 分析模块内部的数据结构Ø 分析基路径覆盖，为基路径覆盖设计用例服务Ø 分析其他覆盖，为基本覆盖设计用例服务Ø 分析单元出错处理的正确性，为设计出错处理用例服务5. 单元测试用例的设计1. 静态测试技术用于单元测试1.1 一般不需要设计具体的测试用例1.2 按照静态测试技术的要求完成相关工作即可2. 动态测试技术用于单元测试2.1 黑盒方法：单元最小功能点覆盖，边界值法2.2 白盒方法：对单元的内部逻辑进行测试3 黑盒测试最小功能点覆盖3.1 以ATM取款单元组件为例，其功能点有:（1）正常取款，（2）输入的取款金额是否合法，（3）检查超出当天的最大取款（假设为2000RMB），（4）余额不足（假设账号余额为1500RMB）（5）打印收据各功能点各一次，前提是银行卡和密码为有效4 非功能性测试4.1 非功能特性一般实现为特定的功能Ø 对排序算法效率的测试首先要实现排序功能，然后对其数据量、时间进行测试Ø 系统登录的安全性通过完成多次密码输入错误后拒绝登录来实现，因此首先也要实现密码多次错误的检查功能。4.2 因此，非功能性测试一般通过黑盒测试实现特定的功能来达到测试的目的。5 黑盒测试边界值法5.1 银行系统规定在每次ATM交易中，密码输入错误次数不能超过5次，超过5次要吞卡Ø 设N为密码输入错误的次数Ø N小于等于5，则不吞卡，否则吞6 黑盒测试强制错误情况发生Ø 主动造成磁盘空间不足Ø 主动造成内存不足Ø 例如：7 黑盒技术设计单元测试用例小结Ø 测试程序单元的所有最小功能点是否覆盖Ø 测试程序单元非功能性是否满足要求，比如安全性、可靠性、强度/压力测试（可选）Ø 考虑可选的其他测试特性，如接口、边界、余量、强制性出错、人机交互界面测试等8 白盒测试8.1 单元测试用例的设计可以使用黑盒测试方法，但以白盒测试为主8.2 黑盒测试侧重于功能，白盒测试侧重于逻辑8.3 白盒测试进入单元测试的前提条件是测试人员已经对被测试对象有了一定的了解，基本明确了被测试软件的逻辑结构8.4 为了度量测试的完整性，白盒测试通常也要求达到一定的覆盖率8.5 通常使用下面几种测试覆盖率来度量测试Ø 如语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖等8.6 白盒测试最低应该达到的覆盖率目标是：Ø 语句覆盖率达到100%Ø 分支覆盖率达到100%Ø 覆盖程序中主要的路径8.7 测试人员在实际工作中要根据不同的覆盖要求用白盒方法来设计面向代码的单元测试用例，运行测试用例后至少应该同时满足如下几个覆盖：Ø 对程序模块的所有独立的执行路径至少覆盖一次，达到基路径覆盖，即McCabe覆盖Ø 对所有的逻辑判定，真假两种情况都至少覆盖一次Ø 用边界值的方法来测试循环体Ø 测试内部数据结构的有效性等6. 单元测试实例1. 教材P142-158页给出了一个“酒店服务与管理”系统中FlashRemoting包的单元测试实例Ø 给出了8个方法（实际测了7个）Ø 对每个方法分别进行测试分析和测试用例设计² 每个方法都可以看成一个单元Ø 基于等价类划分，为每个等价类设计若干测试用例