测试基础

测试基础知识

1.1 功能性需求与非功能性需求

1.1.1 功能性需求

         满足基础功能，执行功能测试

1.1.2非功能性需求

1.1.2.1 安全性测试用例

     加密
     sql注入攻击
     跨站脚本攻击
     暴力破解

1.1.2.2 性能压力测试用例

高并发场景的响应时间、服务器端的监控指标
高集合点并发场景下，是否存在资源死锁和不合理的资源等待
大量用户连续登录登出，验证服务器是否存在内存泄漏

1.1.2.3 兼容性测试用例

 不同浏览器、版本、移动终端、分辨率

1.2 测试用例的设计方法

1、等价类划分法
2、边界值分析法
3、错误推测方法

  错误推测方法是基于对被测试软件系统设计的理解、过往经验以及个人直觉， 
  推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。
  这种方法强调的是对被测试软件的需求理解以及设计失陷的细节把握。

1.3 测试用例设计的其他经验

1、需对内部架构有清楚的认识，比如数据库连接方式、数据库的读写分离、Kafka的配置、缓存系统的层级分布、第三方系统的集成等等
2、必须深入理解被测试软件的设计与实现细节，深入理解软件内部的处理逻辑。单单依靠测试需求点设计的测试用例，只能覆盖”表面“的一层，往往会覆盖 不到内部的处理流程、分支处理，而没有覆盖到的部分就可能出现测试遗漏。
实践中，可以根据代码覆盖率指标找出测试遗漏点。
3、引入需求覆盖率和代码覆盖率来衡量测试执行的完备性。

1.4 单元测试的基础知识

1.4.1 单元测试的定义

单元测试属于最严格的软件测试手段，是最接近代码底层实现的验证手段，
可以在软件开发的早期以最小的成本保证局部代码的质量。

单元测试一般都以自动化的方式执行，所以在大量回归测试的场景下执行单元测试，更能提高测试效率。

同时，单元测试的实施过程可以帮助开发改善代码的设计与实现。

1.4.2 单元测试的最佳实现

1、代码的基本特征
条件分支都是一次分类处理
嵌套的条件判定或者循环都是在做分支处理
2、代码产生错误的原因
分类遗漏
分类未遗漏，但分类有错误
分类未遗漏也未有错误，但处理逻辑有误
（等价类、边界值）

1.4.3 单元测试用例详解

单元测试是一个输入数据和输出数据的集合。

预计输出 绝不仅仅是函数返回值这么简单，还包括了函数执行完之后所改写的所有数据。包含以下几类：

被测函数的返回值
被测函数的输出参数
被测函数所改写的成员变量
被测函数所改写的全局变量
被测函数中进行的文件更新
被测函数中进行的数据库更新
被测函数中进行的消息队列更新
被测函数中调用的其他函数

1、驱动代码、桩代码和MOCK 代码

（1）驱动代码——调用被测函数

（2）桩代码、Mock代码——代替真实代码的临时代码

	起到隔离和补充的作用，还可以控制被测函数执行路径

2、桩代码的编写

（1）桩函数要具有与原函数完全相同的原型，仅内部实现不同，这样测试代码测可以链接到桩函数
（2）用于隔离和补充的桩函数比较简单，只须保持原函数的声明，方法体为空即可，目的是通过编译和链接
（3）实现控制功能的桩函数是应用最广泛的，要根据测试用例的需要，输出合适的数据作为被测函数的内部输入。

1.4.4 单元测试在实际项目中的最佳实践

1、并不是所有代码都需要进行单元测试，通常只在底层模块或者核心模块的测试中采用单元测试。
2、需要确定单元测试框架的选型，这和开发语言有关。Java 最常用的单元测试框架是JUnit和TestNG, C/C++最常用的单元测试框架是CppTest和Parasoft C/C++ test。
3、框架选型完成后，还需要对桩代码框架和Mock代码框架进行选型。选型的主要依据是开发所采用的具体技术栈。
通常，单元测试框架、桩代码的选型工作由开发架构师和测试架构师共同完成。
4、为了衡量单元测试的代码覆盖率，通常还需要引入计算代码覆盖率的工具。Java的JaCoco、JavaScript的Istanbul
5、需要对单元测试的执行、代码覆盖率的统计和持续集成的流水线进行集成，以确保每次提交代码，都会自动触发单元测试，并在单元测试的执行过程中自动统计代码覆盖率，最后以”单元测试通过率“和”代码覆盖率“为标准来决定本次提交的代码是否能被接受。

困难：
1、紧密耦合的代码难以隔离
2、隔离后编译、链接运行困难
3、代码本身的可测试性比较差，通常代码的可测试性和代码规模成正比
4、无法通过桩代码直接模拟系统底层函数的调用
5、代码覆盖率越往后越难提高

1.5 自动化测试的原始驱动力与使用场景

1.5.1 基本概念

自动化测试工具模拟人工操作，并自动验证是否符合预期

优势

1、提升回归测试的效率，适合敏捷开发
2、适合无人值守时执行测试，工作时间分析测试用例执行失败的原因。
3、适合系统稳定性测试和高并发场景下的压力测试

1.6 软件开发各阶段的自动化测试技术

1.6.1 单元测试的自动化技术

以后再补充

1.6.2 代码级集成测试的自动化技术

代码级集成测试是指将已开发完的软件模块放在一起测试。与单元测试非常相似，都是对被测函数以不同的输入参数组合进行调用并验证结果，只不过代码级集成测试的关注点是软件模块之间的接口调用与数据传递。

   二者最大的区别是前者被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替。

C++Test可以使用抽桩技术来实现代码级集成测试。

1.6.3 Web Service测试的自动化技术

Web Service 测试，主要是指SOAP API和 REST API 这两类API测试。

Web service

Web servce 是一个平台独立的，低耦合的、自包含的、基于可编程的web的应用程序，可使用开放的XML标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的交互操作的应用程序。

	Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。
	依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。
	Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。

SOAP

Simple Object Access Protocol 简单对象访问协议，定义了一种强类型的消息传递框架，该框架高度依赖XML和schemas.
SOAP是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。

SOAP是一种基于XML的协议，可以和很多现存的因特网协议和格式结合使用，包括HTTP、SMTP、MIME，基于通用传输协议是SOAP的一个优点。

它还支持从消息系统到远程过程调用等大量的应用程序。

相对而言，SOAP属于复杂的、重量级的协议。

SOAP偏向于面向活动，有严格的规范和标准，包括安全、事务各个方面的内容。

SOAP强调操作方法和操作对象的分离，有WDSL文件规范和XSD文件分别对其定义。

如何确定使用REST
若本身只是简单的CRUD业务操作，那么抽象资源就比较容易。
而对于复杂的业务活动抽象资源并不是一个简单的事情，比如校验用户等级、转账和事务处理等。

如何确定使用SOAP
若有严格的规范和标准定义要求，且前期需要指导多个业务系统集成和开发时，因SOAP风格有清洗的规范标准定义，SOAP更合适。

简单数据操作，无事务处理，开发和调用简单使用REST架构风格较好

REST

REST 表述性状态转移，是一种轻量级的Web Service架构风格，其实现和操作都比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议开实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都要优于SOAP协议。

REST架构对资源的操作包括获取、创建、修改和HTTP删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

REST架构尤其适用于完全无状态的CRUD（Create、Read、Update、Delete,创建、读取、更新、删除）操作

基于REST的软件体系结构风格称之为面向资源体系架构（ROA）。

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。

REST 提出设计概念和准则为：

1、网络上的所有事物都可以被抽象为资源
2、每一个资源都有唯一的资源标识（URI），对资源的操作不会改变这些标识
3、所有的操作都是无状态的

由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题，极大的提高系统的可伸缩性。

Web Service 测试

最典型的是用SoapUI或Postman等类似的工具进行API测试。但这类测试工具的使用基本上都是在界面上操作，手动发起请求并验证响应，所以难以和CI/CD集成，于是就出现了API自动化测试框架。

如果要采用API自动化测试框架来开发测试用例，则测试用例的表现形式就是代码。

要开发基于代码的API测试用例，通常包含三大步骤。
1、准备API调用时所需要的测试数据
2、准备API的调用参数并发起API的调用
3、验证API调用的返回结果

目前流行的API自动测试框架是REST Assured，它可以方便地发起Restful API 调用并验证返回结果。

Web Service测试自动化的内涵不仅包含API测试用例执行的自动执行，还包含以下四个方面：

1、测试脚手架代码的自动生成
2、部分测试输入数据的自动生成
3、响应验证的自动化
4、基于SoapUI或者Postman脚本的自动生成。

1、测试脚手架代码的自动生成
和单元测试阶段的用例框架代码自动生成类似，测试人员在开发API测试的过程中更关心的是如何设计测试用例的输入参数及组合，以及在不同参数组合情况下响应的验证，而不希望将精力浪费在代码层面，例如组织测试用例的方式，测试数据驱动的实现等非测试业务。
这时，测试脚手架代码的自动生成技术就派上用场了，它生成的测试脚手架代码，通常包含了被测API的调用，测试数据与脚本的分离以及响应验证的空实现。
2、部分测试输入数据的自动生成
遵循边界值原则
3、响应验证的自动化
对于API调用返回的结果的验证，通常关注的点事返回的状态码（status code）、Schema结构以及具体的字段值。
响应验证自动化的核心思想是自动比较两次相同API调用的返回结果，并自动识别出有差异的字段值。比较过程中可以通过规则配置去掉诸如时间戳、会话ID等动态值。这部分内容也会在后续章节中详细讲解。
4、基于SoapUI或者Postman的脚本自动生成
Postman的测试用例支持转换成主流代码级API测试框架下的测试用例代码。

1.6.4 GUI测试的自动化技术

它的核心思想是基于页面元素识别技术，对页面元素进行自动化操作，以模拟终端 用户的行为并验证软件功能的正确性。

目前GUI自动化测试主要分为两大方向——对于传统Web浏览器的GUI自动化测试和对于移动端原生应用的GUI自动化测试。

基于传统Web浏览器的GUI自动化测试，业内主流的开源方案采用Selenium，商业方案采用Micro Focus的UFT

基于BDD自动生成GUI测试用例

基于GUI页面自动生成页面对象的定义

基于模型生成GUI自动化测试用例等

1.7测试覆盖率

1.71 需求覆盖率

1.7.2 代码覆盖率

至少执行了一次的条目数占整个条目数的百分比

1、行覆盖率
2、函数覆盖率
3、判断覆盖率
4、条件覆盖率
5、条件、判断覆盖率
6、修改条件/判断覆盖率

工具

JaCoCo

1.8.1传统软件产品的测试策略——金字塔模型

重量级API测试、轻量级GUI测试+单元测试“

1.8.1.1 单元测试

白盒测试，通常由开发工程师自己完成

1.8.1.2 API测试

通常采用灰盒测试方法，主要针对的是暴露的接口。
首先以黑盒方式设计如何调用API的测试用例，同时在测试的执行过程中统计代码覆盖率，然后根据代码覆盖率的情况来补充更多、更有针对性的测试用例。

1.8.1.3 GUI测试

端到端（End-to-End，E2E）测试，是最接近软件真实用户使用行为的测试类型。
GUI测试的优点是，能够模拟真实用户的行为。
GUI测试的缺点是，执行代价比较大，即使采用GUI自动化测试技术，用例的维护和执行代价也以依然很大。
另外，GUI测试的稳定性问题，是长期以来阻碍GUI测试发展的重要原因。==即使你采用了注入retry以及异常场景恢复等方式，GUI测试的随机失败率也依旧很高。

1.8.2 互联网产品的测试策略——菱形模型

1.8.2.1 GUI测试

互联网产品的GUI测试通常采用“手工为主，自动化为辅”的测试策略，GUI的自动化测试往往只覆盖最核心且直接影响主营业务流程的E2E场景。

1.8.2.1 API测试

测试重点
1、API测试用例的开发与调试效率比GUI测试要高得多，而且测试用例的代码实现比较规范，通常就是准备测试数据、发起请求、验证响应这几个标准步骤。
2、API测试用例的执行稳定性远远高于GUI测试。
3、单个API测试用例的执行时间往往要比GUI测试短很多。
API测试易于并发方式执行，可以在短时间内完成大批量API测试用例的执行。
4、很多互联网产品采用了微服务架构。而对微服务的测试，本质上就是对不同服务的测试，也就是API测试。
在微服务架构下，客户端应用的实现都基于对后端微服务的调用，如果做好了每个后端服务的测试，就会把握整体的应用质量。
5、API的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性。
后向兼容性
最基本的要求就是保证原本的API调用方式维持不变。
显然，如果调用方式没有变化，那么原本的API测试用例就不需要做大的改动，这样测试用例的可重用性就很高，进而可以保证较高的投入产出比。

1.8.2.3 单元测试