测试基础设施是指支持测试运行、测试开发、测试管理，以及研发环境集成的综合性平台。测试基础设施作为贯穿整个测试过程的支撑，在敏捷话、DevOps 化的开发环境中的地位日益重要。
持续集成（CI）与持续交付（CD）
持续集成（Continuous integration，CI）：通过持续集成可以让软件始终保持在一个可工作的状态。持续集成是一种软件开发实践，团队开发成员每天 1 次或多次的集成。每次集成都通过自动化的架构（测试）来验证，从而尽快发现集成错误。
持续交付（Continuous Delivery，CD）：持续交付是一种能力，能够以可持续方式，安全、快速把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，上用户使用。
区别对比：
持续交付关注的是持续交付价值给用户，是对持续集成的延伸，强调从业务需求把价值交付到用户手上形成闭环。
持续集成关注的是让代码能够工作在一起，以便开展进一步的测试。
敏捷的目标
在 Scrum 模式下，每次迭代结束后会产生一个可以发布给用户的软件版本。
持续集成中的测试活动
代码的一次构成/集成包含：编译、测试、打包、部署、结果反馈。开发人员从提交代码变更触发构建，到收到反馈所需的时间，最好在 10 分钟内，并且整个过程是全自动化的。
自动化测试活动
单元测试：是指对软件最小可测试单元（函数或类）进行验证，目的是发现代码底层的缺陷。单元测试对外部系统的依赖少，运行时间通常在秒级，发现代码缺陷的成本低、效率高。敏捷开发的研发团队需要对单元测试的代码覆盖率提出比较高的要求，如 80% 以上。
静态测试：也称静态分析，通过镜头分析工具不需要运行应用程序（代码）就可以对软件代码进行检查，从而发现代码规范问题、结构问题及代码错误等。
BVT（Build Verification Test）：用来验证软件的基本功能是否正常工作。
其他可选测试
代码评审（Code Review）：互查或由技术级别更高的工程师评审的方式针对代码进行检查以进一步确保代码质量。如果引入了代码评审机制，代码只有经过指定人员检查后才能真正入库或合并到主干，随后才会触发自动构建和测试。
持续交付中的测试活动
包括研发和运维。研发阶段又称测试左移，包括：需求评审、设计评审、代码评审、持续集成中的测试、迭代中的各项持续测试活动。运维阶段又称测试右移，是生产环境中的在线监控和线上测试。如，自动化回归测试等。
持续交付中的测试活动
自动化回归测试包括：接口测试、UI 测试、性能测试、兼容性测试。
持续集成保证我们随时获取可工作的软件并进一步开展深入测试。
持续部署
就是按需部署（On-demand Deployment），强调通过技术手段，随时地、快速地将软件包部署到各类环境中，并确保系统可以正常工作。环境包括：生产环境、测试环境和准生产环境。
持续部署强调软件部署在技术上的自动化，能够持续在各类环境中快速、频繁地进行安装、升级。在理想情况下，从开发人员提交代码触发持续集成到持续测试，再到持续部署，整个过程是全自动化的方式。
持续运维（Continuous Operation）
持续地收集线上用户数据和用户反馈，为软件的持续改进提供依据。实现全自动的监控、告警、故障定位和自愈，以及自动的数据收集、分析和处理。
如何将测试融入持续集成/持续交付环节
持续集成环境基本构成示意图
支撑持续集成的测试环境
持续集成工具集：
- 代码版本管理工具：GitHub、GitLab、BitBucket、SubVersion 等
- 版本构建工具：Anita、Gradle、Maven 等
- CI 调度工具：Jenkins、BuildBot、Bamboo、Fabric、CircleCI 等
- 自动部署工具：Capistrano、CodeDeploy、Superviso、Forever 等
- 配置管理工具：Ansible、Bash、Chef、Cfengine、Puppet、Ruddler 等
- 代码静态分析工具：Findbugs、C++Test、CppTest 等
- 单元测试工具：Junit、CppUnit、Mocha、PyUnit
- 版本验证工具：Selenium、Appium 等
支撑持续交付的测试环境
持续交付环境是在持续集成环境的基础上进行扩展，主要是为了支持全面的回归测试、验收测试。
自动化测试金字塔：
- 单元测试：JUnit、CppUnit、Mocha、PyUnit 等
- API 测试：Cypress、Karate、Postman、REST-Assured 等
- UI 测试：Selenium、Appium、Cypress、Geb 等
专项测试：
- 功能测试：Selenium、Appium
- 性能测试：JMeter、Gatling
- 安全测试：Wapiti、OWASP ZAP
- 验收测试：Robot Framework、Cucumber。支持 ATDD、BDD 和需求实例化的测试框架。
持续集成/持续交付流水线中的测试过程
持续测试/持续交付环境中的自动化测试平台
Jenkins Pipeline 为例：
- 在 Jenkins Pipeline 中，制定要执行的持续集成/持续交付流水线脚本（Pipeline script）的存储位置。
- 在 Jenkins 流水线脚本发起构建请求后，对指定代码仓库的指定分支上的代码进行编译、测试和打包。
- 持续集成/持续交付流水线脚本发起请求下载指定的测试脚本集到一个 Jenkins Node，通常也是测试的执行环境。
- 持续集成/持续交付流水线脚本发起部署请求，自动化测试平台的资源调度与管理服务找到可用的被测试系统资源，下载指定的软件包进行部署。
- 持续集成/持续交付流水线脚本发起测试执行请求。
- 如果测试环境比较复杂，则需要搭建测试执行的集群环境，测试执行模块会调用资源调度与管理模块分配、配置测试执行环境。
- 测试脚本调用测试数据管理模块获取测试数据、执行测试。
- 测试执行完毕，自动化平台分析测试结果，生成测试报告，报告可以提交给统一的平台来整体呈现。
- 在持续集成/交付流水线脚本里，指定测试报告的邮件接收人名单，测试结束后以邮件形式发送报告。
基于 DevOps 的测试基础设施构成
2005 年的软件研发与运维质量保证全流程
DevOps 测试基础设施
软件测试工具：
- 基础架构类：CloudFormation、OpenStack 等
- 容器类工具：Docker、Rocket、ElasticBox 等
- 资源编排管理工具：Kubernetes（K8s）、Apache Mesos、Swarm 等
- 微服务平台：OpenShift、CloudFoundry、Mesosphere 等
- 日志管理：Elastic Stack（ElasticSearch、Logstash、Kibana、Beats）、Logentries、Splunk 等
- 系统监控、警告与分析：Prometheus、Icinga2、Nagios Core、Zabbix、Cacti、Zookeeper 等
- 性能监控：APPDynamics、Datadog、Dynatrace、New Telic、CollectD、StatsD 等
代码分析（静态测试）
代码的静态测试，也称为静态分析，他不需要运行应用程序就可以进行检查，并找出其中的缺陷。自动的静态测试是指利用镜头分析工具对代码进行自动扫描以发现缺陷的技术。
可发现问题：
- 代码结构问题：重复性代码、高耦合的代码等
- 发现问题：资源泄露、空指针引用、“死”循环和缓冲区溢出等
- 可读性差、不规范的问题：有些代码没有缩进、变量在使用前未定义等
要实现静态测试的前提：
- 选择适合的静态测试工具：团队要一起定义扫描规则，使用统一的规则进行静态测试。在开发过程中，对发现的代码缺陷进行总结、提炼或抽象，把这些代码缺陷模式借助规则集、模型、解析树和形式化方法等方式扫描出来，结合编程规范就形成了自定义的扫描规则。
- 开发人员提交代码前先在本地开发环境里执行静态测试：结果可作为人工评审的输入项进行分析。
- 将静态测试工具集成在持续集成环境中：静态测试将成为持续集成活动的一部分，并且自动生成可视化的代码分析报告。发送邮件通知开发人员进行分析和修复工作。
优秀的测试工具：
- Java 语言：PMD、FindGugs、Checkstyle
- C/C++ 语言：C++Test、CppTest、Splint
- Python 语言：Pylint、Pychecker、Pycharm
自动化测试框架的构成
自动化测试框架的逻辑结构
- Harness/IDE：自动化测试框架的核心，相当于“夹具”，框架的其他组成部分都能与之集成，而且具有脚本的创建、编辑、调试和管理等功能。
- 自动化测试脚本的管理：包括公共脚本库、项目归类的的脚本库，这部分可与 GitHub 这类（代码库）配置管理工具集成。
- 测试资源管理：增加、删除和配置相应的测试设备（软件和硬件资源），并根据他们的使用状态分配测试资源，这部分可以与容器管理工具集成。
- 测试数据管理：测试数据的自动生成、存储、备份和回复等。也可以演化成一个数据平台，甚至是数据中台。
- 开放的接口：提供给其他持续集成环境或其他测试环境的集成接口。这种接口以 API 形式提供。
- 代理（agent）：负责 Harness 与工具的通信，控制测试工具的运行。
- 安排任务（scheduler）：安排和提交定时任务、事件触发任务等。以便实现无人值守的自动化测试。
- 数据统计与分析：针对测试结果（含测试工具运行产生的日志），生成可读性良好的测试报告（如 HTML 格式的测试结果），如使用 SonarQube、Allure 等。
评论