软件测试技术与实践：单元测试-2015

1、单元测试9/21/20221课前问题1. 单元测试就是模块测试吗？2. 单元测试应该谁来做？9/21/20222本章内容为什么要做单元测试？单元测试的概述 单元测试的方法和技术单元测试的内容单元测试的过程9/21/202231 为什么要做单元测试对缺陷分析观察结果原因思考9/21/20224对缺陷分析的思考故障发现阶段需求缺陷设计缺陷编码缺陷测试缺陷总计需求阶段22设计阶段105060编码和单元测试251522系统测试12100103验收测试002020总21/20225观察结果编码阶段引入的缺陷远远多于其它阶段系统测试发现的缺陷大多数是编码缺陷测试版本频繁，测试和项

2、目进度被无休止的拖延。 Why?9/21/20226原因1是否开发人员水平不够？是否开发人员工作强度或工作时间不够？ 不是！9/21/20227原因2传统的开发观念？开发人员的任务是完成编程，让系统正确运行起来。程序调试通过任务就完成了。自信自己的程序不会出错。实际上：开发人员的任务是完成程序，直到交付和维护。人的失误是不可避免的，无论多小心，都会有错误。9/21/20228原因3测试是测试人员的事情，我们只管编程和改正BUG？ 错！ 测试是什么？9/21/20229测试生命周期9/21/202210测试分类确认测试 确认系统是否满足了用户的意图。系统测试 将整个系统的硬件、软件和人员等所有元

3、素结合在一起的测试，关注点是需求的验证：系统是否正确完成了需要的功能。集成测试 部分模块的组合测试，验证接口和集成问题。单元测试9/21/202211原因4开发进度和任务紧，没有时间做自测？必须关注质量，如果质量保证不了：1.太多缺陷，返工和测试延长，进度反而更慢。2.即使抢了市场先机，还是会被对手超过。对自测的时间和工作投入，可以在测试阶段和维护阶段捞回来，从总体上缩短项目周期。项目经理应该足够重视单元测试，并为单元测试安排足够的时间。业界经验，1：19/21/202212如果把单元测试的任务堆积到系统测试阶段，将会怎样？大量的故障堆积在项目中后期：项目后10%的工作，占用了项目90%的时间

4、。故障难以定位故障飘忽不定开发、测试人员疲于奔命9/21/202213原因5单元测试难做？ 单元测试比编写程序更难吗？Yes。9/21/202214XP极限编程测试先行，开发以测试为导向写不出测试用例，就谈不上编写单元代码开发一个单元的代码的步骤：1.设计和编写测试它的用例代码2.编写单元的代码3.使用前面的用例测试它单元测试是编码的一部分！9/21/2022152 单元测试概述9/21/202216单元测试是什么？单元测试，是针对软件设计的最小单位 程序模块，进行正确性检验的测试工作。 Unit：函数，源代码文件，类把测试比作是清洗一台机器： 系统测试就是清除机器外面的尘土。 集成测试就是保

5、证机器各个部件的接头处干净。 单元测试就是清洗各个零件的内部。9/21/202217单元测试不是不是模块测试？不是子系统测试不是功能测试？9/21/202218单元测试是自测的主要方式软件模块自测的手段：代码走查：单人或多人评审阅读代码软件模块的系统级测试：从软件模块完成的功能方面，放在整个系统中进行验证。单元测试：设计和编写测试用例，运行检查9/21/202219单元测试定义单元测试，是针对软件设计的最小单位 代码模块，进行正确性检验的测试工作。 函数 文件(.c .cpp .java .pas) 类9/21/202220单元测试的对象单元单元测试的对象是软件设计的最小单位单元。9/21/2

6、02221单元的特征软件系统的基本组成单位由一个程序员完成在系统详细规范中详细说明其功能特性能被单独地汇编和测试规模较小，逻辑较简单9/21/202222单元测试特点关注程序的基本组成部分若干个单元可以并行测试发现错误后容易隔离和定位规模和复杂性较低，可利用多种测试技术进行比较充分细致的测试 9/21/202223单元测试关注点代码 关注代码问题，而不是功能问题。 功能测试是测试部的职责。9/21/202224单元测试内容单元接口局部数据结构重要的执行路径错误处理的路径影响上述几点的边界条件9/21/202225单元测试时机尽早进行9/21/202226单元测试人选由谁去做由谁去做：通常由开发

7、人员自己测试 。也可是专职测试人员。也可是其他开发人员。开发者是单元测试的最佳人选9/21/202227单元测试应该开发人员来做代码级的测试效率：了解和熟悉程序方法：白盒，不可能让测试人员读懂程序手段：通常需要通过编写程序角度：开发人员提高质量觉悟9/21/202228单元测试的目标单元测试的目标：确保模块被正确地编码 。使用详细设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误。9/21/202229单元测试的依据单元测试的依据是详细设计描述。9/21/202230单元测试退出准则什么时候可以停止：通常是当程序员感到代码没有缺陷时 。有的公司有量化的度量标准。（例如，当某段时间内该

8、模块千行代码错误率小于某一阀值。）9/21/202231单元测试的量化要求举例1.静态检查：编程规则触犯率低于10%(每十行代码至多有一个编码规范错误)2.动态检查：无内存泄漏，无越界读写，无未处理异常3.测试用例： 语句覆盖90%,关键模块100% 判定覆盖80%(关键模块)，条件覆盖不要求 接口边界检查（关键模块：根据80%原则，要求最复杂的，缺陷最集中的20%的单元） 最低测试范围：修改的代码和新增的代码。单元测试记录和文档故障记录：通常没有记录 。或记录不全。文档：单元测试规程单元测试报告9/21/2022333单元测试方法 可用手段：白盒测试方法 静态分析 动态分析 黑盒测试方法9/

9、21/202234单元测试方法怎样去测试： 白盒为主 系统内多个模块可以并行地进行测试。关注覆盖率（应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。 ）关注运行错误：如逻辑错误，算法错误，内存错误，异常错误。黑盒为辅 接口错误9/21/202235为什么要白盒测试9/21/202236白盒测试技术实现手段：设计驱动和桩 为了得到一个完全隔离的单元，把此单元以外的代码进行隔离和控制。 接口（输入输出），全局变量，子调用实现方法：代码覆盖 确保程序运行过所有逻辑路径，各个角落得到清扫！ 9/21/202237为什么单元要做覆盖率测试？覆盖率测试是单元测试的核心！是清除软件代码BU

10、G的最主要的手段！9/21/202238测试覆盖率语句覆盖率 以Statement为单位判定覆盖率 以分支为单位条件覆盖率 以逻辑条件为单位条件覆盖判定覆盖语句覆盖9/21/202239白盒用例设计方法控制流： 基本路径法，条件测试法数据流 循环测试9/21/202240基本路径法控制流图节点，边，区域9/21/202241工具 Logiscope Audit1.根据代码生成程序流程图和控制流图。2.自动计算环形复杂度。3.流图和代码对应。借助Logiscope Audit和Logiscope TestChecker,可以更加有效的进行单元测试。9/21/202242循环测试循环分类：简单循环

11、，串接循环，嵌套循环，不规则循环。简单循环9/21/202243循环测试嵌套循环串接循环9/21/202244循环测试不规则循环9/21/202245循环的测试用例设计简单循环的测试集(假设有n次循环)：1)整个跳过循环2)只有一次通过循环3)两次通过循环4)某个m次通过循环，mn5)n-1,n,n+1次通过循环9/21/202246循环的测试用例设计嵌套循环的测试集1.从最内层循环开始，把其它循环设为最小值。2.从对最内层循环使用简单循环测试，使得外层循环为最小值3.由内到外构造下一个循环的测试，但其它外层循环最小，内层循环为典型值。 4.继续直到全部循环测试完。 9/21/202247循环

12、的测试用例设计串接循环的测试集如果两个循环相互独立，分别采用简单循环方式。如果互相不独立，比如上一个循环的计数是下一个循环计数的初始值，推荐使用嵌套循环方式。9/21/202248循环的测试用例设计不规则循环 尽量把这些循环重新设计为结构化的程序设计。 结构化编程的定义：任何一个控制流图，如果可以化简为环形复杂度为1的图，它就满足了结构化编程的要求。 9/21/202249静态分析编程规范检查 遵循编程规范，可以大大降低编码缺陷。标准有：C/C+软件编程规范Java软件编程规范 Delphi代码编程规范 GUI通用软件界面规范代码质量分析 分析代码结构，给出复杂度，可维护性，稳定性，可读性等度

13、量，找出缺陷可能性最多的代码，进行修改和单元测试。9/21/202250静态分析工具Logiscope RuleChecker C/C+,Java Audit C/C+,JavaCodeClearCodeWizardPCLINT9/21/202251动态分析内存错误：内存泄漏，内存（数组）越界读写，读未经过初始化的内存，内存分配错误。异常错误：没有处理的异常覆盖率检查：寻找没有运行的代码, 内部边界点，强制错误运行效率分析：分析运行瓶颈，提高性能9/21/202252动态分析工具1.Rational PurifyPlus（PurifyPlus RealTime） Purify 内存和运行错误

14、PureCovarage 代码行覆盖率 Quanlity 运行效率分析2.Parasoft Insure+3.BoundChecker9/21/202253黑盒测试把测试对象看做一个黑盒子，不考虑程序内部的逻辑结构和内部特性，只关注接口。 待测单元(UUT)9/21/202254黑盒测试技术实现手段：设计驱动和桩 为了得到一个完全隔离的单元，把此单元以外的代码进行隔离和控制。 接口（输入输出），全局变量，调用实现方法：用数据对接口进行测试 确保接口正确，预定的输入，产生预料中的输出。 9/21/202255黑盒用例设计方法按照功能需求等价类划分边界值9/21/202256测试用例代码打桩编写驱

15、动工具 C+Test（自动生成驱动、桩和部分用例数据） Rational Test RealTime,VectorCast（自动生成驱动、桩） JUnit,CppUnit,DUnit,cUnit（提供代码框架）利用开发工具的Debug功能 断点和修改变量，单步，插桩(Instrumentation)9/21/2022574单元测试的内容单元测试内容包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试 9/21/2022584.1模块接口测试模块接口测试是单元测试的基础。对模块接口的测试保证在测试时进出程序单元的数

16、据流是正确的。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。所以模块接口测试要在其它测试之前进行。 9/21/202259模块接口测试内容测试接口正确与否应该考虑下列因素：1 输入的实际参数与形式参数的个数是否相同；2 输入的实际参数与形式参数的属性是否匹配；3 输入的实际参数与形式参数的量纲是否一致；4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；9/21/202260模块接口测试内容5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；7 调用预定义函数时所用参数的个数、属性和次序是否

17、正确；8 是否存在与当前入口点无关的参数引用；9/21/202261模块接口测试内容9 是否修改了只读型参数；10 对跨模块的全局变量的定义是否一致；11是否把某些约束作为参数传递。 9/21/202262模块接口测试内容当一个模块执行外部I/O操作的时候，必须进行附加的接口测试，考虑下列因素：1 文件属性是否正确；2 OPEN/CLOSE语句是否正确；3 格式说明与输入输出语句是否匹配；9/21/202263模块接口测试内容4缓冲区大小与记录长度是否匹配；5文件使用前是否已经打开；6是否处理了文件结束条件；7是否处理了输入/输出错误；8在输出信息中是否有文字性错误。 9/21/2022644

18、.2模块局部数据结构测试 对局部数据结构的检查保证临时存储的数据在算法执行的整个过程中都能维持其完整性。局部数据结构局部数据全局数据？9/21/202265检查局部数据结构检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例。9/21/202266检查局部数据结构常见错误：1 不正确或者不一致的数据类型描述；2变量无初值；3变量初始化或省缺值有错；4不正确的变量名（拼错或不正确地截断）； 5出现上溢、下溢和地址错误。 9/21/202267全局数据除了局部数据结构外，单元测试时还应该查清全局数据（例如多个模块共享全局数据，

19、其它模块修改全局数据对本模块的影响评估）对模块的影响。 9/21/2022684.3模块边界条件测试边界条件测试是单元测试中最重要的一项任务。对边界条件的测试保证模块在极限或严格的情形下仍然能够正确执行。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。 9/21/2022694.4模块中独立执行路径测试 单元测试中，应对模块控制结构中的每一条独立执行路径（基本路径）进行遍历测试，以保证模块中每条语句至少执行一次。对执行路径的测试（即代码覆盖测试）是单元测试中最主要的任务。此时基本路径测试和循环测试是最常用且最有效的测试技术。 9/21

20、/202270模块中独立执行路径的测试 测试用例应能发现由于错误计算、不正确的比较、或者不正常的控制流而产生的错误。还有其他常见的错误，如下：9/21/202271计算中常见的错误计算中常见的错误包括： 误解或用错了算术优先级；混合类型的运算；变量初始化不正确；精度不够精确；表达式的不正确符号表示。9/21/202272比较判断常见错误比较判断和控制流常常紧密地耦合在一起（比如，控制流的转移是在比较之后发生的），测试用例应当能够发现下列错误：不同数据类型之间进行比较；不正确地逻辑操作或优先级；应该相等的地方由于精度的错误而不能相等。（因计算机表示的局限性）9/21/202273比较判断常见错误

21、不正确的比较或变量出错；不正常的或者不存在的循环终止条件；当遇到分支循环的时候不能退出；不适当地修改循环变量。 9/21/2022744.5模块的错误处理路径测试 好的设计应能预见各种出错条件，并预设各种出错处理路径。当错误真的发生的时候，错误处理被建立，以重定向或者干净地终止处理。在错误处理部分应当考虑的潜在错误有下列情况：输出的出错描述信息难以理解；所报的错误与实际遇到的错误不一致；9/21/202275模块的错误处理路径测试 错误条件在错误处理之前就引起了系统异常；异常处理不当；错误描述中未能提供足够的信息来帮助确定错误发生的位置。常见坏现象：把错误处理路径加到了软件中，但从不进行出错路

22、径的测试。 9/21/2022765单元测试过程9/21/202277按造哪些步骤做单元测试推荐的步骤：1.静态检查:用工具Logiscope或者人工检查单2.动态检查:用工具PurifyPlus或者人工调试3.测试用例执行(工具或人工)设计测试用例及数据；（提前）编写测试用例代码、脚本、驱动模块和桩模块；（提前）运行测试用例，记录结果。（在步骤1,2之后进行） 单元测试的输入软件详细设计（可以是代码）待测单元列表和代码可重用的已有测试用例9/21/202279单元测试的输出1.编程规范检查报告。（工具生成或人工编制）2.运行异常检查报告。（工具生成或人工编制）3.测试用例执行报告。（工具生成

23、或人工编制） 测试用例代码 测试用例数据和说明 运行结果（覆盖率统计）合格准则：同行可以读懂，可以用它们来重新验证或做回归测试，鼓励使用工具。 9/21/2022805.1单元测试用例设计单元测试常被看作编码步骤的附属品。在源代码被开发、编译调试、审查后，单元测试用例设计就开始了，也有可能提前。对设计信息的复审可能能够为建立前面讨论的每一类错误的测试用例提供指导。测试用例的设计应与设计信息的复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。 9/21/202281单元测试用例设计正常数据：在测试中所用的正常数据的量是最大的，而且也是

24、最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。9/21/202282单元测试用例设计例如若使用SQL Server数据库，则可把SQL Server关键字（如：;AS;Join等）设为边缘数据。其它边缘数据还有：HTML的HTML;等关键字以及空格、负数、超长字符等。边缘数据要靠测试人员的丰富经验来制定。 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。 9

25、/21/2022835.2代码静态检查方法：审查走查通过代码静态检查找到的错误可以比测试用例测试所能找到的错误更加深入；并且发现错误的时间也比测试用例要早。代码检查要以代码标准（根各公司具体情况自行制定）为依据。（编程规范） 9/21/202284代码静态检查内容 代码风格和规则审核 程序设计和结构的审核 业务逻辑的审核 9/21/202285代码风格和规则检查代码风格和规则的审核是在每个程序员完成一个模块或类的 时候要进行编码规范的检查。要召开审核会议让所有的项目组人员都参加。在会前项目经理要做一个检查表，以表的内容为检查依据，检查表的内容主要是检查的要点。在审核会上项目组的每一个人员都能看

26、到自己和其他人员的编码问题，从而起到预防的作用。这些问题都要被解决，并且解决的结果要在审议会上被确认。自动检查工具 9/21/202286程序设计和结构的审核 进行程序设计和结构的审议是因为开发工具的不同和项目时间的限制而造成设计不详细。比较深入的设计通常是在编码阶段完成的，但由于程序人员和设计人员的经验是不同的，所以会出现很大的问题。我们引入了程序设计和结构审核来保证质量。审核人员要有先进的技术开发经验。9/21/202287程序设计和结构的审核 在审核之前也要一个审核列表，列出主要几项，如：程序的概要、详细设计。但仅局限于列表是不够的，审议人员 还要审议程序的精巧度和具有创造力的方面，这只

27、能靠经验而不能只靠列表中的内容来审议。对于不同的程序员所检测代码的宽度和深度也是不同的。项目经理可以根据程序员经验的不同制定被审议人员的宽度和深度。例如：年轻的程序员要审议所有代码。但有经验的就可适当减少。 9/21/202288业务逻辑性审议业务逻辑性审议必须要在代码完成后审议。业务逻辑审议实际上是审议单元模块的功能。这些功能是以系统说明为依据的。审议人员要有开发的经验并且对系统也要熟悉。审议人员通过执行程序从而了解底层代码的状态。这阶段的审议实际也包含了前两种审议，因为审议者也可以通过最后的结果检测单元模块设计和结构的准确性。 9/21/202289单元测试过程代码审查以上三种审议都要耗费

28、一定的时间和资源，但是它却能更早地发现和解决不易显现的错误。 代码审查通过后，我们终于可以使用测试用例来进行代码测试了。 9/21/2022905.3代码动态检查它主要包括： 编译调试内存泄漏检查（工具）9/21/2022915.4测试用例执行它主要包括： 功能测试 代码覆盖测试性能和健壮性测试9/21/202292功能测试我们可使用已编好的用例并以正常数据测试用例进行测试，若不能正常运行则要用调试工具调试。在这阶段，我们要用大量正常数据去测试。测试后，该程序应可在绝大多数的正常数据中运行。 9/21/202293代码覆盖测试目标： 测试到每一个最小语句的代码 测试到所有的输出结果 我们应该通过一步步的调试去运行每个程序的所有语句和分支。如果我们想要百分之百地覆盖就应适当运用边缘数据和错误数据。测试在这个阶段的质量是难以掌握的。它基于程序员的责任心和经验。当这阶段完成后，每个程序员所测的深度也是不同的。 。 9/21/202294性能和健壮性测试性能（代码行性能分析工具）：找到瓶颈，改进。稳定性（健壮性）：内存泄漏、资源吊死9/21/202295单元测试环境驱动模块桩模块桩模块桩模块被测单元9/21/202296单元测试驱动模块和桩模块驱动模块: 用以模拟被测单元的上层模块，测试执行时由驱动模块调用被测单元使其运行。桩模块: 模拟被测单元