# 二、DevOps-Platform自动化测试平台
# 2.1 基于PR的单元测试
基于PR的单元测试是一种小粒度的测试，能够对开发人员每次提交的代码进行测试，可以快速进行反馈和减少bug。 团队采用了Github推荐的“Fork + Pull”协作模式，我们同时推荐通过Pull Request这个功能来进行团队中的代码审查。
基于PR的单元测试的作用:
- 帮助开发人员编写代码，提升质量、减少bug。 开发人员就会先考虑各种场景相关，例如正常注册、用户名重复、没有满足必要的填写内容......等等，之后就会编写相关的测试用例
- 提升反馈速度，减少重复工作，提高开发效率。开发人员实现某个功能或者修补了某个bug，
- 保证你最后的代码修改不会破坏之前代码的功能。
- 让代码维护更容易。由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。
- 有助于改进代码质量和设计。除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。
基于PR的单元测试的缺点:
- 单元测试的学习成本比较高。
- 编写单元测试会增加程序员工作量。
- 推广和运用单元测试需要比较大的投入。
# 2.2 基于服务的组件测试
基于服务的组件测试主要作用是为了测试新的功能对组件内部其他服务是否正常。组件测试通常由编写代码的开发人员开展，组件测试是需要访问到被测软件的代码。 开发人员可以将组件开发与发现和修复缺陷交替进行。开发人员经常在编写组件代码后编写并执行测试。
组件测试的目标包括：
- 降低风险
- 验证组件的功能和非功能行为是否符合设计和规定
- 建立对组件质量的信心
- 发现组件中的缺陷
- 防止缺陷遗漏到更高的测试级别
组件测试中可用作测试依据的典型工作产品包括：
- 详细设计
- 代码
- 数据模型
- 组件规格说明
组件测试的典型测试对象包括：
- 组件、单元或模块
- 代码和数据结构
- 类
- 数据库模块
组件测试发现的典型缺陷和失效包括：
- 功能不正确(例如，不符合设计规格说明中的描述）
- 数据流问题
- 代码和逻辑不正确
组件测试通常没有进行正式的缺陷管理，缺陷通常在发现后立即修复。但是，当开发人员报告缺陷时，这为根本原因分析和过程改进提供了重要信息。
基于容器的自动化组件测试在自动化的测试中在云原生中具有很重要占比。目前对于很多公司的采用的强依赖于环境测试的组件测试，导致需要大量的资源。
轻量化组件测试
一个系统中拥有的大量的微服务，为了改变组件测试中对真实环境的强依赖，我们采用采用轻量化的组件测试来代替原来的强依赖的测试，具体的流程如图所示：
多版本组件测试
由于依赖的环境的可能发生改变，在众多版本中容易出现mock的服务更新不及时，导致获取依赖测试环境没有更新，导致测试无效或者失败， 同时对于特殊版本的产生的测试依赖可能原来与不同版本的不同服务，因此为了实现全流程的自动测试功能，采用解耦的方式来实现的依赖测试环境自由构建。 采用制品仓库的方式，来实现mock测试服务环境与测试对象的解耦，使用能够通过多版本测试依赖方便，自由的组合，快速的进行组件测试。
# 2.3 基于组件的集成测试
基于组件的集成测试主要是为了测试更新组件对其他组件的影响是否正常。为了减少组件与组件之间的bug，否者导致在产品系统测试发现问题更难排查。
# 2.4 产品系统测试
该阶段主要对系统的准确性及完整性等方面进行测试。系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。
产品系统测试主要包括:
- 功能确认测试
- 运行测试
- 强度测试
- 恢复测试
- 安全性测试
系统测试的测试人员由测试组成员（或质量保证人员）或测试组成员与用户共同测试。在整个系统开发完成，即将交付用户使用前进行。在这一阶段，完全采用黑盒法对整个系统进行测试。
在自动化测试平台中采用基于K8s的容器化系统测试，实现环境和隔离,快速测试，测试资源的重复利用，提高系统测试效率与资源利用率。解决公司成本。