标签：包括 CI 单元测试 CD 功能测试测试服务端

写在前面的(一枚走在测试开发路上的新人)

简单自我介绍，博主是一位刚步入工作的小白，很幸运毕业后入职了一家不算大但也不小的互联网公司，岗位是测开，参与的业务也还算核心。虽然作为一枚刚毕业参加工作不足两年的新人，可能以我的工作经验也没有什么能够教给网友的，但还是希望把自己近期的一些工作积累记录下来，供大家阅读讨论与指导，感激不尽。

众所周知，测试开发的指责就是质量保障(Quality Assurance)，所以一般测试都被称为qa。质量保障目的当然是尽早发现问题来降低解决问题的成本(也因此我们老板说除非服务器爆炸了，否则每一位qa应当对线上问题负责Orz)。特别在公司一直在负责服务端的测试，深有体会。服务端任何代码或配置的风吹草动都可能造成线上事故的爆发，当然，这些问题如果在上线前被拦截那就都不是问题了。

服务端的测试内容

服务端承载了一个产品的业务逻辑，并为WEB或APP 端提供后台接口(http、rpc接口等)。接口是服务端对外提供数据服务最常用的信息交换方式，但服务端的测试并不等同于接口测试。服务端测试的范围比较广泛，包括以下几部分：单元测试、集成测试、功能测试、性能测试、安全测试、负载测试、部署和配置测试。服务端测试已不再局限于简单的接口功能测试了，开发同学的高频变更也不允许qa每次都人工地进行接口功能的验证，而是通过自动化流水线或脚本的方式才是我们的常态。

CI/CD自动化流程

现在公司项目的开发模式，大多是进行协同开发，因此就涉及到多个研发同学处理自己负责的功能或者多位同学共同负责一个模块。通过gitlab进行版本控制，可以使多位同学的代码集成在共享存储库里。每一位同学在仓库中维护自己的分支(简称local分支)并进行需求开发，最终每个人会将自己开发的那部分代码合并主分支(master分支)，进而实现了项目协同开发。
在整个开发周期中，无论是local分支的开发，还是向master分支的合并，这一过程中肯定会遇到各种的问题。因此，qa同学的测试工作介入并不是只对主分支的测试，而实际是从每位研发同学在local分支开发时就需要参与其中。为了保证开发的效率、质量和交付速度，就需要CI/CD[持续集成(Continuous Integration)、持续交付(Continuous Delivery)]这样一个自动化的测试流程，以确保在代码更改过程中保持软件系统的稳定性和质量。通过下图描述一下CI/CD的整个流程：

代码提交与build

目前公司代码的维护基本依赖于gitlab，gitLab CI/CD 是一个内置在gitLab中的工具，方便我们进行持续集成、交付和部署[转载:https://zhuanlan.zhihu.com/p/37411745?utm_id=0]。

gitLab的CI是通过在工程项目下维护.gitlab-ci.yml 文件，来实现对项目的配置及自动打包流程
gitlab-ci.yml本质是一组命令行脚本，既然是脚本，就需要一个执行环境。环境可以是一台物理机，也可以是虚拟机，当然更方便的是容器。说到容器，肯定会想到docker，通过配置Dockerfile与我们gitlab-ci.yml脚本可以很容易地实现：
gitLab下载代码-->build镜像-->推送镜像到镜像仓库
到此就完成了项目打包成镜像的过程，后面便是通过该镜像来进行服务部署并等待测试的流程。但提到服务的部署就不得不说下另一个强大的工具:Kubernetes(由于k和s之间隔着8个字母所以简称k8s)。在CI/CD流程中，可以使用k8s将不同环境（例如开发、测试、生产）的应用程序实例隔离开来。k8s还允许使用不同的部署策略，如滚动更新（Rolling Update）或蓝绿部署（Blue-Green Deployment）等，这些策略可以确保应用程序的平滑升级和回滚。进而也保证了CI/CD中持续部署的实现。

持续集成

持续集成部分是研发同学希望在代码变更完成后，立刻进行业务服务在测试环境下的构建并自动完成相关测试。然后根据测试的结果来确定是否可以合并集成到master分支中。最终，再用整合后的master分支代码进行服务部署和测试，当主分支测试通过后才满足了交付的条件，即可以使用该版本进行生产发布。

持续交付

持续交付是持续集成的延伸，确保以可持续的方式快速发布新的更改。即图中的灰度测试，该阶段会将代码自动部署到预生产环境，并承接少量的线上请求，通过自动化测试来确保该环境下服务的正确性和稳定性，灰度测试通过后才意味着允许正式进行生产全量的发布。因此，在整个CI/CD流程中除了自动化测试，还需要有自动化的发布流，可以通过一个按键就可以随时随地实现应用的部署上线。

持续部署

持续部署扩展了持续交付，以便业务服务在通过所有测试时自动部署。

自动化测试

在该流程中的测试基本是依赖自动化测试脚本或服务的方式来完成。这里的测试可能包含了Code Review、单元测试、接口功能测试、服务性能测试、安全测试等。

CI/CD中的测试能力

在CI/CD流程中，自动化测试是一个关键的环节，无论是在local测试阶段还是主分支测试阶段，它有助于确保应用程序的质量，减少错误，并提高交付速度。在CI/CD流程中的测试能力可以有以下几种：code review、单元测试、功能测试、性能测试等。其中，单元测试、功能测试和性能测试都可以通过自动化脚本或服务的方式来实现，这可以大大节省人工成本、提高开发效率。

Code Review

在CI/CD测试-交付的过程中，虽然自动化测试的方式可以大大地节省人工成本，但可能无法完全依靠自动化的方式来确保问题的0发生。因此，在研发的分支代码合入主分支时还需要对其代码和自动化测试结果进行人工review。Code Review一方面是为了发现变更代码是否有语法错误，边界行为错误，经验错误，算法错误，部分算法错误等问题；另一方面是为了重新review自动化测试结果是否可靠，以保证代码的质量及服务稳定性。

单元测试

单元测试是软件开发中的一种测试方法，它主要用于验证代码的各个独立单元（通常是函数、方法或类）是否按照预期进行工作。单元测试可以通过Maven中功能在CI/CD流程中实现自动化测试，Maven 通常使用 JUnit 作为默认的单元测试框架：

创建单元测试类：在 Maven 项目的 src/test/java 目录下，创建与你的主代码相对应的包结构，并在这些包中编写单元测试类。单元测试类的命名通常以 Test 结尾，例如 MyClassTest。
```
import org.junit.Test;
import static org.junit.Assert.*;

public class MyClassTest {
	@Test
	public void testSomeMethod() {
		// Your test logic here
		assertTrue(true);
	}
}
```

配置 Maven 项目：在 Maven 项目的 pom.xml 文件中，确保以下配置信息存在，以启用单元测试。Maven 默认使用 JUnit 作为单元测试框架。

<dependencies>
	<!-- 其他依赖项 -->
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		<scope>test</scope>
	</dependency>
</dependencies>

运行单元测试：在项目根目录下使用 Maven 命令运行单元测试。
mvn test
Maven 将自动查找并执行所有的单元测试类。测试报告将显示在控制台中，并且 Maven 将在 target/surefire-reports 目录下生成测试报告。
集成到 CI/CD 流程：在 CI/CD 工具中配置构建步骤，确保在构建过程中运行单元测试。不同的 CI/CD 工具有不同的配置方式，但通常需要在构建脚本或配置文件中添加命令来运行单元测试。例如，使用 GitLab CI 的 .gitlab-ci.yml 文件：
```
stages:
  - test

test:
  stage: test
  script:
	- mvn test
```

功能测试

服务端接口功能测试是在服务端应用程序的API层进行的一种测试，用于确保业务服务功能按照预期工作。服务端功能的测试一般以黑盒方式，qa设计测试用例，通过向服务端接口请求的方式开验证返回结果是否符合预期，常用的接口测试工具如postman。但在CI/CD流程中，我们通常会编写脚本来实现向服务端请求并校验相应结果的准确性，以确保在每次代码更改后都运行测试。这有助于及早发现潜在问题，并防止问题进入生产环境。

端到端的功能测试
仅在服务端一侧来校验返回结果是否符合预期并非万全之策，只有通过模拟整个应用程序或系统的用户交互，从用户界面的角度验证应用程序是否按照预期工作才算功能测试闭环。即需要在web前段或app客户端上来模拟请求验证功能的准确性。

但在进行端到端测试时，需要确保使用与生产环境相似的测试环境。这包括与实际数据库、外部服务和其他集成点相对应的环境。这一部分可能无法通过自动化的方式来完成，通过需要qa同学搭建完成的sit或beta环境，并设计完备的测试用例来完成对应的功能测试需求。

性能测试

服务端性能测试是一种用于评估服务器应用程序在不同负载条件下的性能和可伸缩性的测试。这种测试有助于确定服务器在处理并发用户请求时的性能表现，以及在达到负载极限时是否能够保持稳定。

在CI/CD流程中如何去验证服务端的不同负载呢，答案是通过流量回放进行压测，即我们通过录制线上请求，然后在测试环境对被测服务进行流量回(流量回放的方法有很多，例如Jmeter、netty，以后再展开介绍吧..)，并通过qps的控制来观察服务端在不同负载情况下其若干关键指标的表现。

这里我只列出了性能测试中可能需要关注的一些基础指标

QPS/TPS: 用于衡量系统性能的指标。这两个指标表示在一秒钟内执行的查询或事务的数量，在高负载的情况下，系统需要能够处理更多的查询或事务，因此高QPS和TPS通常被认为是一个系统能够有效处理负载的指示器
响应时间：响应时间是指从用户发出请求到服务器返回响应的时间。这是一个关键的性能指标，用户通常期望应用程序在合理的时间内响应其请求。当然在压测时通常会观察压测期间的平均相应时间、P99(表示处于数据分布中最高的1%的观测值)、P90(表示处于数据分布中最高的10%的观测值)。在性能分析中，P99和P90等百分位数对于理解系统的尾部性能和极端情况非常重要。
服务错误率：在性能测试期间发生的错误的百分比。这包括HTTP错误码、超时等。较低的错误率通常表示更好的性能。
网络延迟：在分布式系统中，网络延迟是一个关键因素。了解网络延迟对于评估服务器在不同地理位置的用户之间的性能至关重要。
资源使用情况：监测服务器资源的使用情况，包括CPU利用率、内存使用、磁盘I/O等。高资源利用率可能表明服务器在高负载下的瓶颈。
服务可用性：在性能测试期间，确保服务始终保持可用。监测服务的健康状态，并确保在高负载下不会发生不可用或崩溃。

性能测试的分析会针对相关的指标来展开，其实际是为了探索服务性能的瓶颈，同时测试阶段的压力测试可以让我们即使发现一些未知的问题。

未完待续...

标签：包括,CI,单元测试,CD,功能测试,测试,服务端
From： https://www.cnblogs.com/liuxgblog/p/17974503

服务端测试都包括些什么