第五章单元测试和集成测试的技术

单元静态测试主要由开发人员完成。

标准：规定什么能做，什么不能做。

规范：建议你要怎么做。

5.1.2 代码评审

代码评审是一种发现代码缺陷的另一种测试方法。

代码审查的最佳实践：

1. 创建代码审查清单
2. 培养代码审查文化
3. 提供建设性反馈
4. 以小规模、渐进式变革为目标
5. 制定代码审查目标并收集相关指标
6. 不要匆忙进行审查
7. 定期轮换代码审查人员
8. 始终记录代码审查决

代码审查的方式：

1.代码走查：日常用的最多的一种测试方法。过程：代码开发人员引导小组部分成员读代码，成员提出问题，做出评价。测试人员提出测试实例，在会议上用头脑想出测试实例的执行结果，测试实例只是作为怀疑程序逻辑的参考。

2.正式会议审查

最正式的检查和评估方法。它原理：逐步检查源代码中语法错误以及逻辑错误来检查故障。它要软件开发者自己检查也要成立代码检查小组进行检查。具体的工作流程p107.

代码审查避免：1.超时，2.现场修改。

会议的目标：看代码编写是否符合标准和规范，是否存在逻辑错误。

3.走查与会议审查的对比（如图）

4.缺陷检查表

这个表把程序设计中可能发生的缺陷进行分类，做成表格，在会议中使用，在会议后发现新的缺陷也要进行分类，不断充实缺陷检查表。缺陷检查表的作用：防止人为的疏漏。

去网上看对应的表格就能理解是什么样的啦。

5.3 借助代码评审工具来完成静态测试
 

如果将静态代码检测工具集合到项目持续集成环境中，通过不断地检查和修改来减少软件缺陷。

具体的工具：

1.java：PMD，CheckStyle。

2.c++：Helix QAC。

3.python:PyCharm

也有多语言检查的工具，下面介绍一些工具的使用：
1.FindBugs检查代码缺陷

它是扫描分析java字节码，选中的字节码文件对应的源文件，可以定位出问题的代码行。

它可以在idea，eclips中使用。

这里工具的使用到了具体的应用场景在去实际的操作。

2.PMD检查代码缺陷

3.CheckStyle检查代码风格

4.SonarQube构建自动的代码扫描

5.4 单元测试的目标和任务

软件系统由组件和模块组成，保证软件系统的质量，就要开展单元测试活动。单元测试属于代码级别的动态测试，代码级测试需要保证功能性，代码在结构上要有良好的响应。因此需要进行充分的测试用例以验证业务逻辑合理。

5.4.1 为什么要进行单元测试

单元测试是系统功能测试的基础，开发人员在编程完立马想提交上来给测试人员测试，如果没有执行好单元测试，软件会发现更多的错误。表面上的进度代替不了实际进度。单元测试是早期抓住错误的最好时机。

5.4.2 单元测试的目标和要求

测试是为啦发现缺陷，调试是为啦修正缺陷。检验各单元是都被正确的编码，保证代码在结构上可靠且健壮，能够在各种条件下给出正确的响应是单元测试的主要目标。

单元测试的一系列活动：

1.建立测试环境

2.测试脚本的开发和调试

3.测试执行以及结果分析

单元测试需要主要关注：

(1)建立单元测试环境,包括在开发集成环境(Integrated Development Environmen
IDE)中安装和设置单元测试工具(插件);
(2)测试脚本(测试代码)的开发和调试;
(3)测试执行及其结果分析。
在单元测试活动中强调被测试对象的独立性,软件的独立单元将与程序的其他部分被
离开,以避免其他单元对该单元的影响。这样,缩小了问题析范围。在单元测试中,需要关
注以下主要内容。
(1)目标:确保模块被正确地编码;
(2)依据:详细设计描述;
(3)过程:经过设计、脚本开发、执行、调试和分析结果等环节;
(4)执行者:由程序开发人员和测试人员共同完成;
(5)采用哪些测试方法:包括代码控制流和数据流分析方法,并结合参数输入域的测试
方法;
(6)测试脚本的管理:可以按照产品代码管理的方法进行类似的配置管理(并入代码
库),包括代码评审、版本分支、变更控制等;
(7)如何进行评估:通过代码覆盖率分析工具来分析测试的代码覆盖率、分支或条件的
覆盖率。

通过单元测试的一般原则：
(1)软件单元功能与设计需求一致。
(2)软件单元接口与设计需求一致。
(3)能够正确处理输入和运行中的错误。
(4)在单元测试中发现的错误已经得到修改并且通过了测试
(5)达到了相关的覆盖率的要求。
(6)完成软件单元测试报告

5.4.3 单元测试的主要任务

单元测试为啦完成上面的目标，需要进行以下任务：单元中所有独立执行路径，数据结构，接口，边界条件，容错性等测试。

1.单元独立执行路径的测试：主要检查以下问题

(1)误解或用错了算符优先级;
(2)混合类型运算;
(3)变量初始化错误、赋值错误;
(4)错误计算或精度不够;

(5)表达式符号错等。
且要检验所涉及的逻辑判断、逻辑运算是否正确,如是否存在不正确的比较和不适当的
控制流造成的错误。此时判定覆盖、条件覆盖和基本路径覆盖等方法是最常用且最有效的测
试技术。比较判断与控制流常常紧密相关,这方面常见的错误主要有以下几种。
(1)不同数据类型的对象之间进行比较;
(2)错误地使用逻辑运算符或优先级，
(3)因变量取值的局限性,期望理论上相等而实际上不相等的两个变量的比较;
(4)比较运算或变量出错;
(5)循环终止条件错误,或形成死循环;
(6)错误地修改了循环变量。

2.单元局部数据结构的测试
检查局部数据结构是检查临时存储的数据在程序执行过程中是否正确、完整。局部数据
结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误。
(1)不合适或不相容的类型说明;
(2)变量无初值;
(3)变量初始化或默认值有错;
(4)不正确的变量名(拼错或不正确地截断);
(5)出现上溢、下溢和地址异常。

3.单元接口测试
只有在数据能正确输入(如函数参数调用)、输出(如函数返回值)的前提下,其他测试才有
意义。对单元接口的检验,不仅是集成测试的重点,也是单元测试的不可忽视的部分。单元接
口测试应该考虑下列主要因素。
(1)输人的实际参数与形式参数的个数、类型等是否匹配、一致;
(2)调用其他单元时所给实际参数与被调单元的形式参数个数、属性和量纲是否匹配;
(3)调用预定义函数时所用参数的个数、属性和次序是否正确;
(4)是否存在与当前入口点无关的参数引用;
(5)是否修改了只读型参数;
(6)对全程变量的定义各单元是否一致;
(7)是否把某些约束作为参数传递。
如果单元内包括外部输入输出(如打开某文件、读入文件数据、向数据库写人等),还应该
考虑下列因素。
(1)文件属性是否正确;
(2)OPEN/CLOSE语是否正确;
(3)格式说明与输入输出语句是否匹配;
(4)缓冲区大小与记录长度是否匹配;
(5)文件使用前是否已经打开;
(6)是否处理了文件尾;
(7)是否对异常的输入输出进行判断;
(8)输出信息中是否有格式错误。

4.单元边界条件测试

程序容易在边界上失效，采用边界值分析技术可能发现新的错误

5.单元容错性测试

这个测试主要检查下列问题：

(1)输出的出错信息难以理解;
(2)记录的错误与实际遇到的错误不相符;
(3)在程序自定义的出错处理代码运行之前,系统已介人;
(4)异常处理不当;
(5)错误陈述中未能提供足够的定位出错信息。

6.内存分析

5.4.4 驱动程序和桩程序

我们要单独分出单元进行测试，也就是要隔离单元，需要开发对应的驱动程序和桩程序，

驱动程序（驱动模块）：模拟被测单元的上级模块，可以调用被测单元。测试中，驱动模块接受测试数据，传给被测模块。

桩程序（桩模块）：模拟被测单元的下级模块，进行少数的数据处理。

驱动模块和桩程序隔离被测单元，驱动程序做为入口，来完成各种测试用例。

5.4.5 类测试

对于类的单元测试可以看成是对类的成员函数进行测试。

在一个类中给每个测试用例定义一个方法，叫做测试用例方法。

测试用例方法的任务是：给用例构建输入状态，生成事件序列并检查输出状态来执行测试用例。

由于继承和多态的使用，测试的时候还需要考虑父类和子类的影响。

在父类的测试用例中随机挑选几个测试用例，把子类的实例当父类的实例来运行测试用例。这样可以检查子类的多态方法是否满足父类的方法的要求。

5.5 分层单元测试

目前程序开发都是分层的，控制层，数据访问层，业务层等。

下面分别讨论如何对不同层次进行测试。

5.5.1 Action层的单元测试

Action层主要接受页面传过来的参数，调用业务逻辑层的封装方法，最后负责跳转到响应的页面。对该层的测试主要进行跳转的验证，看能不能跳转到制定的页面。

对需要依赖外部系统的代码进行单元测试，需要使用Mock对象隔离外部依赖。

1.Mock就是模拟测试时所需要的对象以及测试数据。可以用Mock来模拟Acion层的请求和接受对象。

2.StrutsTestCase

StrutsTestCase提供基于Struts框架的代码测试，可以设置请求参数，检查在Action被调用后的输出请求或者 session状态这种方式完成Struts Action的测试。

StrutsTestCase可以测试Action对象的实现，还可以测试mapping，frombeans和forwards声明。

更多StrutsTestCase资源可以在

2024 年最佳开源 Windows 软件中下载

Java容器:Overview (StrutsTestCase Documentation)

看到课本上的案例，实际就是使用上面的框架编写测试的代码，看p128.

5.5.2 数据访问层的单元测试

业务逻辑层：简单的业务逻辑可以使用Junit测试，复杂的逻辑用Mock对象来模拟测试，如果测试对象依赖于DAO的代码，可以用Mock Object方法。测试数据层本身，使用开源的DbUnit项目。

Dbunit(dbUnit Aggregator – DbUnit)可以控制测试数据库的状态，在DAO测试之前，它可以为数据库准备测试数据，测试结束时，他会把数据库状态恢复到测试前的状态。也就是它为数据库提供数据。

它有多种方式向数据库中插入数据，最常用的是：FlatXmlDataSet。

5.5.3 servlet的单元测试
 

在测试servle本身的代码块，可以选择HttpUnit，他提供啦一个模拟的servlet容器，让servlet代码不需要发布到servlet容器中就可以测试。

5.6 单元测试工具

单元测试工具一般相对不同的编程语言而存在的。很多集成开发环境都会提供。

比如xunit工具家族。

5.6.1 JUnit介绍

JUnit是一个java测试框架，用在编写和运行可重复的测试脚本之上。

在JUnit 5简明教程_junit5 pom下载-CSDN博客该文章中可以大概了解JUnit框架

在idea中使用JUnit5应用举例：

1. 建立被测试的类：

   
   //创建这个类实现两个字符串的连接
   public class test {
   
       public String addString(String str1,String str2){
           return str1+str2;
       }
   
   }

2. 建立其对应的JUnit Test类：在这个测试类中快捷键：ctrl+shift+t，弹出创建测试类的窗口。单击ok即可
3. 生成如下代码：对代码进行补充，让他满足对特定功能的测试。
4. 成功就会提示：
5. 如果修改语句：可想而知这两个字符串连接起来不能成为addbb，所以运行结果：

5.6.3 Mock框架Mockito

Mockito是目前主流的支持java语言的mock框架，可以很容易编写测试来模拟被测对象的依赖对象。详细看【单例测试】Mockito实战_mockito 单测-CSDN博客

5.6.4 测试覆盖率工具 Jacoco

单元测试结束后，需要统计测试覆盖率，看单元测试是否充分。

jacoco是开源的java测试覆盖率统计工具，使用插桩的方式来记录覆盖率，它提供啦多种覆盖率计数器：1.指令覆盖，2.分支覆盖，3.行覆盖，4.方法覆盖率，5.类覆盖率

5.7 系统集成的模式与方法

单元测试需要隔离模块，但是遇见集成的模块时，就会出现接口之间的问题，这时候需要进行集成测试，集成测试的目的是检查单元之间接口的问题，它主要是将进行过单元测试的模块集成起来测试。

单元测试要求:1.熟悉单元的内部细节，2.能从高的层次观察整个系统。

现在提倡微服务架构，就是将业务系统组件化，一个微服务完成一个特定的业务功能，服务之间通过轻量级的通信协议进行交互。集成测试有很多不一样，下面介绍两种结构模式下的集成测试：

5.7.1 单体架构的集成测试

集成测试时，要选择什么样的集成模式（集成测试的策略）

集成测试有一下两种：

1.非渐增式测试模式：先分别测试每个模块，再把所有的模块按照设计好的放在一起结合成自己想要的程序。

2.渐增式测试模式：把下一个要测试的模块跟前一个测试好的模块结合起来测试。也就是一点一点增加测试模块进行测试。（这个不容易乱，有序，更容易找到错误）

渐增式测试模式具体的实现有：

1.自顶向下法，2.自底向上法，3.混合策略

5.7.2 微服务架构的集成测试

第六章系统功能测试

第七章专项测试

第八章软件本地化测试

第九章测试自动化及其框架

本章主要介绍测试自动化的概念，原理和方法，如何引入和实施测试自动化以及测试的框架，让大家能够掌握测试自动化的有关知识和技能。

9.1 测试自动化的内涵

测试自动化需要有自动化测试，它是相对于手工测试而存在的概念，自动化测试由测试工具，脚本等来实现，有良好的可操作性和可重复性。测试自动化是软件测试不可或缺的技术。

9.1.1手工测试的局限

手工测试具有创造性，可以举一反三。简单的功能性测试用例在每一轮测试中都不能少，而且需要重复执行，工作量大，手工测试一个一个做就比较乏味。

9.1.2 什么是测试自动化

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，也就是模拟手工测试的步骤，由工具自动完成各种测试的工作。自动化测试需要用到的工具大约有：1.测试工具问问，2.网络通信环境，3.邮件系统，4.系统shell命令，5.后台运行程序，6.改进的开发流程等，让系统自动完成测试的各项工作。

不可能让每个过程都自动化，但是测试员需要不断地问自己，这些测试工作能否由软件系统或工具来完成？也就是要有全过程地自动化测试思想。

9.1.3软件测试自动化地优势

1.自动运行速度快，执行效率高

2.不会疲劳

3.测试结果准确

4.可靠，机器不会撒谎

5.可复用性

软件测试自动化对测试带来地好处：

1.缩短软件开发测试周期。2.更高质量地产品，3.软件过程更加规范，4.测试效率高，充分利用硬件资源，5.节省人力资源，6.增强测试地稳定性和可靠性，7.提高软件测试的准确度，8.手工不能完成的事情软件测试工具可以完成。

9.2 测试自动化的实现原理

测试自动化的基础：可以通过特定的程序对软件应用的代码进行测试。

测试自动化包括：1.UI自动化测试，2.API自动化测试，3.自动化的单元测试，4.自动化的代码分析。

自动化测试也包括：动态的静态的测试，1.UI自动化测试，2.API自动化测试，3.自动化的单元测试，是动态的测试，代码分析属于静态的测试。

自动化的单元测试在第五章有介绍。这里就介绍其他测试的原理

9.2.1 代码分析

自动化的代码分析由代码静态检测工具完成，工具自带规则，用户自定义的规则对代码进行扫描。最早的代码分析工具：编译器。

代码分析工具还体现在集成开发环境（ide）中，看到不合理的代码段会提示或者警告你。并且它们都有可选的插件来运用，这样可以更全面的进行代码分析工作。例如：JUnit

9.2.2 脚本技术

脚本是一组测试工具执行的指令集合。它可以通过录制测试的操作产生，然后再修改，这样可以减少脚本开发的工作量。

脚本的分类：1.线性脚本，2.结构化脚本，3.数据驱动脚本，4.关键字驱动脚本。

目前大多数测试工具都支持数据驱动脚本和关键字驱动脚本。在脚本开发中，经常将这几种脚本结合起来使用。

1.线性脚本

这种通过录制手工制定的测试用例得到的脚本。它包含击键，移动，输入数据等动作。线性脚本可以加入简单的指令：1.时间等待，2.比较指令等。它适合简单的测试，一次性测试，常用于：脚本初始化，或者演示。

2.结构化脚本

对线性脚本的加工，类似结构化设计的程序。（好比如建房子，线性脚本就是地基，结构化脚本就是之后建房子的其他工序）

结构化脚本容易维护。

3.数据驱动脚本

它将测试脚本和数据分开，输入数据单独存在独立的文件中，不存储在脚本中。针对于一个功能测试，使用不同的输入数据。也就是一个脚本使用多个测试数据实现多个测试用例的自动执行。

通过脚本来引用变量，通过变量引用数据，脚本描述测试的具体执行过程。

4.关键字驱动脚本

关键字驱动脚本用一个简单的表格来表示，它是数据驱动脚本的逻辑扩张，封装啦各种基本操作，每个操作由相应的函数实现，也就是直接把对应操作的函数进行组合，完成相应的动作。

关键字的层次处在合适水平比较好，不要太细节。

9.2.3对象识别

UI自动化测试：使用自动化测试脚本将用户 在被测试的应用 的界面上的操作转变为自动化操作。也就是模拟用户使用应用的情况，查看输出结果是否是正确的。

1.识别用户界面的元素以及模拟各种输入

2.将用户的操作过程转换为脚本。

3.对脚本进行优化

4.加入测试的验证点

5.运行脚本，对比结果。

UI自动化测试的核心：页面对象的识别技术。

界面上的对象识别方式有以下3种：

1.按照屏幕的实际像素坐标来定位。

2.通过寻找UI 上的对象来确定操作目标，控制识别

3.通过图像识别算法对图片进行图像匹配和文字识别。

selenium是web ui的自动化测试工具，采用控件识别方法。移动应用主流的ui自动化测试框架：Appium也是采用控件识别方法。

图像识别技术：

1.图像匹配

2.基于光学字符识别的文字识别

工具有：Airtest

文字识别工具：OCR技术

9.2.4 接口调用

API测试是用来验证API的软件测试类型，目的是检查api的功能，性能等，用于验证软件系统的业务逻辑的处理。

原理：通过测试工具对被测接口的请求，然后验证返回的响应是否正确。

API测试的步骤：

1.准备需要输入的各种测试数据

2.通过接口测试工具，发起对被测接口的请求

3.在各种数据输入组合的情况下，验证被测接口返回的结果是否正确。

9.2.5 自动比较技术

自动比较在自动化测试中非常重要。

1.简单比较：对执行过程中输出的数值和期望获得的数值进行比较。

2.图片验证原理就是比较正确的图片和自动化测试时截取的图片进行比较，使用到的技术在9.2.3中有介绍。

3.自动化测试中有两种比较模式：验证模式和断言模式。

断言命令有对应的验证命令，其中selenium就提供啦三种模式的断言。

9.3测试自动化的实施

9.3.1 测试自动化系统构成

自动化脚本的开发类似于软件开发的工作，需要集成开发环境。集成环境构成自动化系统的基本框架。基本结构p263

选择测试工具就显得很重要啦。

根据软件产品或项目的需要，确定要用哪一类工具。

工具的选择要看工具具备那些功能，预算是基础，解决问题是前提，质量和服务是保证，适用才是根本。

选择工具的具体流程：

1.小组讨论测试工具的选择和决策，制定时间表

2.明确自己的需求，看看有没有其他不同的解决需求的方案，最后进行利弊分析。

3.了解能够满足自己当前需求的产品

4.根据市场上的产品功能，限制和价格，结合自己的开发能力，预算，项目周期，觉得自己是选择开源工具还是商品工具。

5.进行对比分析，货比三家，确定两个三个产品作为候选产品。

6.如果是商业产品，请候选产品的厂商来介绍，演示，并解决几个实例。

7.初步确当

8.商务谈判

9.最后决定

9.3.4 测试框架的构成和分类

测试框架提供一个架构，可以根据自己的需求进行填充把一些功能加上去，集成测试工具等，提高测试效率。

自动化测试框架：需要支持脚本的开发，调试运行，需要集成相应的测试工具，管理测试机器，测试任务和测试报告等。

很多测试工具结合单元测试框架可以形成一个功能强大的测试框架。