软件测试 第6章单元测试

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