单元测试培训资料PPT课件下载推荐.ppt

单元测试培训资料PPT课件下载推荐.ppt

《单元测试培训资料PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《单元测试培训资料PPT课件下载推荐.ppt（36页珍藏版）》请在冰豆网上搜索。

软件测试软件测试什么是软件测试：

定义1：

软件测试是为了发现错误而执行程序的过程。

定义2：

软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入数据和与其输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

软件测试的对象：

软件测试不等于程序测试软件测试贯穿于软件定义和开发的整个周期。

因此，需求分析、概要设计、详细设计，以及程序编码等各阶段所得到的文档，包括需求规格说明书、概要设计说明书、详细设计规格说明书以及源程序，都是测试的对象。

软件测试软件测试软件测试分类按测试用例的设计方法，软件测试分为白盒测试和黑盒测试。

按测试策略和过程，软件测试分为单元测试、集成测试、确认测试和系统测试。

按软件系统工程，测试是软件质量保证的最后的一关。

本培训文档主要内容将围绕软件开发编码阶段运用的单元测试过程加以描述和讨论单元测试为什么要进行单元测试

（一）1单元测试是不是太浪费时间了？

不经过单元测试，直接进入集成测试，系统正常工作的可能性非常低，大量的时间被花费在跟踪那些简单的Bug上，会导致集成为一个系统时增加额外的工期。

编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。

但是，一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作，这才是真正意义上的进步。

调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

2单元测试仅仅是为了证明这些代码作了什么吗？

这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发人员提出的一条普遍的抱怨。

这样的测试完全基于已经写好的代码，这无法证明任何事情。

单元测试基于详细设计文档，这样的测试可以找到更多的代码错误，甚至是详细设计的错误。

因此，高质量的单元测试需要高质量的详细设计文档。

为什么要进行单元测试

（二）3我是一个很棒的程序员，是不是可以不进行单元测试呢？

每个人都可能犯错误。

真正的完整的系统往往是非常复杂的，不能寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。

4有集成测试就够了，集成测试将会抓住所有的Bug。

系统规模愈来愈大，复杂度愈来愈高，没有单元测试，开发人员很可能会花费大量的时间仅仅是为了使该系统能够运行。

任何实际的测试方案都无法执行。

在系统集成阶段，对单元功能全面测试的负载程度远远的超过独立进行的单元测试过程。

最后的结果是测试将无法达到它所应该有的全面性，一些缺陷将被遗漏，并且很多Bug将被忽略过去。

单元测试为什么要进行单元测试（三）5单元测试的成本效率不高？

无论什么时候做出修改都要进行完整的回归测试。

在生命周期中尽早的对产品进行测试将使效率和质量得到最好的保证Bug修改越晚，费用就越高，单元测试是一个在早期抓住Bug的机会。

相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。

从全程的测试费用来考虑，相比复杂且旷日持久的集成测试，或是不稳定的系统，单元测试所需的费用是最低的。

单元测试单元测试的重要性一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。

系统开发的后期阶段，Bug的检测和修改将会变得更加困难，并要消耗大量的时间和开发费用。

无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽早的对产品代码进行测试将是效率和质量得到最好的保证。

在提供了经过单元测试的情况下，系统集成过程将会大大的简化。

开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不会陷入充满很多Bug的单元之中不能自拔。

使测试工作的效率发挥到最大化的关键在于选择正确的测试策略，这包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当的使用好工具来支持测试过程。

单元测试模块接口的测试项目调用被测模块的输入参数与模块的形式参数在个数、属性、顺序上是否匹配。

被测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配。

是否修改了只做输入用的形式参数。

输出给标准函数的参数在个数、属性、顺序上是否正确。

全局变量的定义在各模块中是否一致。

限制是否通过形式参数来传送。

单元测试局部数据结构测试：

模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误。

检察不正确或不一致的数据类型说明。

使用尚未赋值或尚未初始化的变量。

错误的初始值或错误的默认值。

变量名拼写错误或书写错误。

不一致的数据类型。

单元测试路径测试对基本执行路径和循环进行测试会发现大量的错误。

测试方法：

白盒测试和黑盒测试相结合。

常见的不正确计算有：

1运算的优先次序不正确或误解了运算的优先次序；

2运算的方式错误（即运算的对象彼此在类型上不相容）；

3算法错误；

4初始化不正确；

5运算精度不够；

6表达式的符号表示不正确等常见的比较和控制流错误有：

1不同数据类型的比较；

2不正确的逻辑运算符或优先次序；

3因浮点运算精度问题而造成的两值比较不等；

4关系表达式中不正确的变量和比较符；

5“差1错”，即不正确的多循环或少循环一次；

6当遇到发散的迭代时不能终止的循环；

7不适当的修改了循环变量等。

单元测试错误处理测试概述：

比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理对策，以便在程序出错时，能对出错程序重新做安排，保证逻辑上的正确性。

这种出错处理也是模块功能的一部分。

出错处理模块有错误或缺陷的情况有：

1出错的描述难于理解；

2出错的描述不足以对错误定位和确定出错的原因；

3显示的错误与实际的错误不符；

4对错误条件的处理不正确；

5在对错误进行处理之前，错误条件已经引起系统的干预等。

单元测试边界测试概述：

边界上出现错误是常见的，必须设计测试用例检查。

出现边界问题的情况：

1在n次循环的第0次、1次、n次是否有错误；

2运算或判断中取最大最小值是否有错误3数据流、控制流中刚好等于、大于、小于确定的比较之时是否出现错误。

单元测试的内容图示：

模块独立路径边界条件出错处理局部数据结构模块接口单元测试何时进行单元测试：

单元测试在编码阶段进行。

何时设计测试用例：

在源程序代码编制完成、经过评审和验证、确认没有语法错误之后，就可以开始进行单元测试的测试用例设计。

用例设计的依据：

软件设计文档。

对于一组输入，应该有预期的正确结果。

在单元测试时，如果模块不是独立的程序，需要辅助测试模块。

辅助测试模块种类：

1驱动模块（Driver）-所测模块的主程序。

他接受测试数据，把这些数据传递给测试模块，最后在输出实测结果。

当被测试模块能完成一定功能时，也可以不要驱动模块。

2桩模块（Stub）：

用来替代所测模块调用的子模块。

单元测试驱动模块桩模块被测模块桩模块桩模块测试用例测试结果单元测试与单元测试相关联的开发活动代码走读（codereview）代码走读主要是对程序的编程风格如注释、命名等以及编程时易出错的内容进行检查静态分析（StaticAnalysis）静态分析就是对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。

动态分析（DynamicAnalysis）动态分析就是通过观察代码运行时的动作，来提供执行跟踪、时间分析，以及测试覆盖度方面的信息。

单元测试作为无错编码的一种辅助手段在一次性的开发过程中加以运用。

单元测试单元测试的过程分为计划、设计、实现、执行、评审等几个步骤计划单元测试。

确定测试所用资源（包括人力和设备资源），创建测试任务时间表。

设计单元测试。

设计单元测试模型，制定测试方案，确认并结构化测试过程。

实现单元测试。

参考测试模型和测试方案，制定具体的测试用例，创建可重用的测试脚本。

执行单元测试。

根据单元测试的方案、用例对单元进行测试，验证测试的结果并记录测试过程中出现的缺陷。

评审单元测试。

对单元测试的结果进行评审，主要从需求覆盖和代码覆盖的角度进行测试完备性的评估。

单元测试分解软件，写测试需求反复检查并理解各种信息，和用户交流，理解他们的要求。

可以按照以下步骤执行：

1确定软件提供的主要商业任务。

2对每个商业任务，确定完成该任务所要进行的交易。

3确定从数据库信息引出的计算结果。

4对于对时间有要求的交易，确定所要的时间和条件。

这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

5确定会产生重大意外的压力测试，包括：

内存、硬盘空间、高的交易率。

6确定应用需要处理的数据量。

7确定需要的软件和硬件配置。

通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：

最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

单元测试步骤执行8确定其它与应用软件没有直接关系的商业交易。

包括：

管理功能，如启动和退出程序配置功能，如设置打印机操作员的爱好，如字体、颜色应用功能，如访问email或者显示时间和日期。

9确定安装过程，包括订制从哪安装、定制安装、升级安装。

10确定没有隐含在功能测试中的户界面要求。

大多界面都在功能测试时被测试到。

如：

操作与显示的一致性，如使用快捷键等；

界面遵从合理标准，如按钮大小，标签等。

单元测试设计

（一）单元测试模型的设计。

测试项目的设计。

单元测试模型设计构造最小运行调度系统，即驱动模块，用于模拟被测模块的上一级模块。

模拟实现单元接口，即单元函数需调用的其他函数接口，即桩模块。

模拟生成测试数据或状态，为单元运行准备动态环境。

对测试过程的支持，对测试结果的保留，对测试覆盖率的记录等。

单元测试环境的示意图如下：

被测单元驱动模块桩模块测试用例测试结束桩模块桩模块单元测试设计

（二）测试项目设计测试项目是测试用例的一个总则，主要是根据测试需求设计测试点，不包含具体实践的用例。

在测试项目的设计中，主要从功能覆盖和代码覆盖两个角度进行考虑。

1功能覆盖属黑盒的范畴，用来指出测试用例是否已经覆盖了程序应该提供的功能。

逻辑覆盖率是考核单元测试质量的一个关键指标。

2代码覆盖也称逻辑覆盖，包括语句覆盖、分支覆盖、路径覆盖，是一种常用的白盒测试方法。

（1）语句覆盖：

设计若干测试用例，运行被测程序，使得每一个可执行语句至少执行一次。

（2）分支覆盖：

也称判断覆盖，使得程序中每个判断的取真分支和取假分支至少执行一次。

（3）条件覆盖：

设的程序中每个判断的每条件的可能取值至少执行一次。

覆盖率指标：

核心代码覆盖率达到100%，共享资源库的代码覆盖率达到100%，非核心代码覆盖率达到90%。

单元测试单元测试用例的设计单元测试用例编写原则之一测试用例设计的根据是详细设计说明书。

测试用例不仅要证明被测单元是否做了它应该做的事情，同时需要证明