培训教材2-软件单元测试省名师优质课赛课获奖课件市赛课百校联赛优质课一等奖课件

软件测试理论—单元测试

1/54课程内容1.为何做单元测试2.单元测试概念和内容3.怎样做单元测试4.单元测试难点和对策2/54程序员难题开发模块出现问题，极难定位，已经熬了几个通宵了！！！怎么办？刚更正了一个BUG，过没几天，又发觉了新问题！！！程序总在出问题，联调了几个月，还是问题不停！！！3/54高质量程序高质量程序取决于以下几个方面：1.高质量设计2.规范编码3.有效测试4/54程序员职责我是程序员，除了编码我还需做些什么？5/54程序员职责传统开发观念？1.开发人员任务是完成编程，让系统正确运行起来。2.程序调试经过任务就完成了。3.自信自己程序不会犯错。实际：1.开发人员任务是完成程序，直到交付和维护。2.人失误是不可防止，不论多小心，都会有错误。6/54小插曲你以前做过程序开发工作么？你是怎样自测？效果怎样？7/54现实中发觉编码阶段引入缺点远远多于其它阶段系统测试发觉缺点大多数是编码缺点测试版本频繁，测试和项目进度被无休止拖延。

Why?8/54开发部压力现实状况：一个负担多个角色团体参加或部分参加高层设计；负担低层设计；程序实现；负担低层测试；设计编码测试9/54开发部测试效果不好：为何？没有时间测试不知道怎样测试不好组织缺乏方法和工具这种情况下，往往把单元测试任务堆积到系统测试阶段10/54问题假如把单元测试任务堆积到系统测试阶段，将会怎样？大量故障堆积在项目中后期：项目后10%工作，占用了项目90%时间。故障难以定位故障飘忽不定开发、测试人员疲于奔命11/54软件缺点修复费用12/54单元测试（why）最高成本收益比降低联调和后续测试时间BUG更轻易定位更有信心去修改老代码13/54业界平均水平商业软件单元测试工作量/总工作量=8.3%编码工作量/总工作量=16.6%军工软件单元测试工作量/总工作量=10.1%编码工作量/总工作量=18.1%14/54业界标杆单元测试（25%）审查评审（20%）设计（17%）编码（14%）需求（7%）系统测试（4%）计划和跟踪（4%）公布后缺点0.06Defects/KLOC单元测试发觉缺点密度：31defects/KLOC15/54主题内容1.为何做单元测试2.单元测试概念和内容3.怎样做单元测试4.单元测试难点和对策16/54单元是什么？(IEEE)软件单元指软件设计说明中一个可独立测试元素，是程序中一个逻辑上独立部分，它不能再分解为其它软件成份。

(实践中)软件单元指软件源代码中单个函数，源文件或类。17/54单元测试是什么？单元测试，对单个软件单元或者一组相关软件单元所进行测试，是代码级测试。Unit：函数，源代码文件，类把测试比作是清洗一台机器：系统测试就是去除机器外面尘土。集成测试就是确保机器各个部件接头处洁净。单元测试就是清洗各个零件内部。18/54单元测试应用输入潜在错误对象19/54单元测试测试一个类Thatiseasy!20/54单元测试标准应该尽早地进行软件单元测试。应该确保单元测试可重复性。尽可能地采取测试自动化伎俩来支持单元测试活动。21/54单元测试内容单元功效测试单元接口测试单元局部数据结构测试单元中主要执行路径测试单元各类错误处理路径测试单元边界条件测试22/54单元测试内容开发测试设计评审代码走查单元测试集成测试面向单元白盒测试（单元覆盖率测试）狭义单元测试内容面向单元黑盒测试（单元功效测试）内存和运行错误分析（内存泄漏、越界，异常）代码运行性能profile（函数效率和瓶颈分析）23/54单元测试（who）单元测试能够是开发者本人执行，也能够是独立专业测试人员执行。二者各有优势。提议开发人员必须完整地做单元测试，同时测试人员针对重点模块实施独立单元测试。24/54主题内容1.为何做单元测试2.单元测试概念和内容3.怎样做单元测试4.单元测试难点和对策25/54单元测试过程单元测试过程包含8个活动：确定单元测试计划确定待测特征制订单元测试规程设计测试套件构建测试套件执行测试套件检验终止条件评定测试结果26/54确定单元测试计划

确定单元测试范围尽可能争取完全地覆盖（标准上应该做到完全覆盖）参考：通常以下情况必须安排单元测试：a）新模块b）新增代码百分比超出20％c）关键模块27/54确定单元测试计划

单元测试充分性要求比如：语句行覆盖率=100%；分支覆盖率〉85%测试覆盖率要求是测试充分性一个方面，除此之外，在单元测试中还应考虑每个软件特征测试覆盖，如函数性能。28/54确定单元测试计划

确定终止条件确定单元测试过程正常终止条件。该终止条件应该包含了对测试充分性要求满足。（100%代码行覆盖，85%分支覆盖）识别可能造成单元测试过程异常终止条件（如发觉重大设计错误、抵达进度期限等）。29/54确定单元测试计划确定单元测试资源估算进行测试活动所需资源。应考虑测试人员、硬件、通信或系统软件、测试工具和其它资源。识别需要进行准备或申请资源（如定制测试工具），并做出对应安排。指明总体进度计划基于资源和项目计划等方面要求，确定单元测试活动总体进度计划。30/54确定待测特征

研究待测特征要从研究单元需求开始功效需求、非功效需求（如性能或设计约束等）、与待测单元相关任何使用或操作过程单元状态识别针对状态机测试单元数据特征识别单元输入输出数据分析以上研究分析对于制订单元测试方案和指导测试用例设计很主要待测特征分析过程中还有可能发觉单元需求上缺点。31/54制订单元测试规程

输入单元测试计划、待测特征分析结果、项目总体进度计划识别可重用技术（待查）经过待测特征分析，可从用例库中识别出能够重用测试用例和测试规程，以降低重复工作。资源详细列举单元测试所需资源，包含人员、设备、工具、环境等，进度计划详细进度计划，包含风险分析和应对办法规程评审32/54设计测试套件

测试套件测试用例、脚本、驱动、桩、测试数据测试规程和测试用例开发当前测试规程和测试用例是合一。开发过程中在重用基础上新增和修改。结合待测单元特征分析，充分考虑测试用例覆盖率。�测试工具设计自研测试工具设计要充分考虑可重用性，不一样项目间通用性普通较小，统一项目不一样版本间一定要具备通用性。测试规程/用例评审33/54单元测试数据单元测试设计中，测试数据设计是很关键，一样测试规程，不同测试数据，可能会到达不一样测试结果。a)正常数据：在测试中所用正常数据量是最大，而且也是最关键。少许测试数据不能完全覆盖需求，但我们要从中提取出一些含有高度代表性数据作为测试数据，以降低测试时间。b)边缘数据：边缘测试是界于正常数据和错误数据之间一个数据。它能够针对某一个编程语言、编程环境或特定数据库而专门设定。边缘数据要靠测试人员丰富经验来制订。c)错误数据：显而易见，错误数据就是编写与程序输入规范不符数据从而检测输入筛选、错误处理等程序分支。34/54构建测试套件测试数据准备测试工具开发/调试构建测试环境35/54执行测试套件运行测试确定测试结果，处理测试过程中异常对每个测试用例，确定单元是否经过测试。对异常进行分析，并依据情况处理：情况1：测试用例或测试数据问题。修正并重新运行。情况2：测试规程执行问题。重新运行。情况3：测试环境问题。纠正测试环境并重新运行；或者异常终止测试，并汇报统计异常终止原因。情况4：单元实现中故障。纠正单元故障，并运行全部测试；或者异常终止测试，并汇报统计异常终止原因。情况5：单元设计中故障。纠正单元设计和实现中故障，必要时修改测试设计和测试数据，并重新运行全部测试。36/54检验终止条件测试充分性检验检验是否到达覆盖率要求，包含测试用例执行/经过覆盖率和被测单元代码/分支覆盖率。以及其它测试充分性要求。异常终止条件检验补充测试套件以上条件不满足时，则需要补充测试套件，继续进行测试。37/54评定测试结果按照单元测试汇报模块出具单元测试汇报如有必要对单元测试汇报进行评审将全部测试相关工作产品纳入配置管理38/54主题内容1.为何做单元测试2.单元测试概念和内容3.单元测试方法、技术与工具4.怎样做单元测试5.单元测试难点和对策39/54参见单元测试难点没有时间做单元测试单元测试责任人不清楚测试代码难以管理覆盖率难以手工统计故障汇报形式驱动和桩编写困难（可测试性）40/54对策：没有时间做单元测试单元测试计划在项目计划应该有表达。编写代码之前或同时，先设计测试用例。每个软件单元应该有什么功效？是否每个功效都有测试用例来验证它？41/54对策：单元测试责任人不清楚强调单元测试必须由类包设计者负责编写，因为只有这么，测试才能确保对象运行时态行为符合需求。让测试人员或第三方人员编写测试用例，将花费更多工作量。（20>>1）执行测试用例能够让测试人员或自动结构系统。42/54对策：测试代码难以管理采取测试工具管理测试代码如XUnit、C++Test、RTRT配置管理中建立配置项如，不一样模块一组代码，建立对应测试代码目录和配置项43/54对策：覆盖率难以手工统计利用各种工具PureCoverage(C/C++/Java/.Net,Windows/UNIX)RTRT(C/C++/Java/Ada,嵌入式系统)C++Test(C/C++,Windows/UNIX)Discover(Delphi,Windows)44/54对策：故障汇报形式各种工具普通都会生成测试汇报XUnit测试用例执行汇报RTRT、C++Test各种综合汇报（测试用例执行结果、测试用例覆盖率、内存检验和性能）45/54对策：驱动和桩编写困难（可测试性差）通常情形下，测试驱动难以编写，测试难以进行由以下几方面原因造成：1、被测试对象需要传入参数过多。2、内部逻辑判断过多（内部牵扯复杂）。3、和界面显示部分交互过于频繁（耦合性太强）。4、被测对象过多调用了其它类或方法。5、需要结构作为参数对象本身过于复杂46/54处理：提升可测试性1、首先最主要是坚持测试驱动设计（测试先于设计）方法。优先编写测试代码。这是标准XP方法。这不是说您应该一次性编写全部测试代码后，再一次性全部实现。对一些单元接口，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更加好方法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中更正它。2、功效分解类：把功效分解到细粒度，提倡小类。方法：尽可能做到每个操作对应一个方法，使方法小型化。功效分解促进：提升重用性，降低耦合度3、分层标准。对于显示部分（GUI），尽可能做到显示与控制分离。把代码移到GUI视图外面。然后各种GUI动作就能成了模型上简单方法调用。这么，对GUI测试者来说，经过方法调用测试功效比间接地测试功效轻易多。另一个好处是它使修改程序功效而不影响视图变更轻易。47/54处理：提升可测试性4、抽象我们能够想出各种各样方法来降低耦合程度，不过归纳起来，不外乎增加抽象层次来隔离不一样类，这个抽象层次能够是详细类，也能够是接口。GOF23种设计模式，没有一个模式思绪不是从增加抽象层次入手来处理问题5、对于可能要作为参数复杂类，能够做一个接口，用接口说明外部程序组件使得我们能够轻易地在测试案例中模拟这些组件。当需要时能够实现按接口生成一个模拟类作为参数传入。尤其是当该类还没有完全实现时，这种方法最为行之有效。48/54处理：提升可测试性6、假如自己不负责测试工作，作为开发员在设计过程中要时刻提醒自己“我怎样才能测试这些代码？我怎样才能以可测试方式编写这些代码”。7、重构是提升可测试性主要伎俩49/54单元测试经验测试驱动开发，开发以测试为导向写不出测试用例，就谈不上编写单元代码开发一个单元代码步骤：1.设计和编写测试它用例代码2.运行自动测试，检验是否发生错误3.编写单元代码4.使用前面用例回归测试它单元测试是编码一部分！50/54单元测试经验测试驱动开发编写单元测试用例促进解除模块之间耦合。先编写测试用例，强