模块回归测试介绍
在日常的软件开发中，我们用通过一系列的测试手段来提高软件的交付质量。常见的有单元测试，回归测试，集成测试等等。有时集成测试和回归测试会混在一起说。其实回归测试也分为模块的回归测试和整个软件集或者说功能集的回归测试。也就是说集成测试包括回归测试加集成测试。
单元测试相对来说是更容易实现的，只要测试函数级别，基本不依赖于外部环境。如果需要依赖外部环境，则会以mock的方式来解决。
相对于单元测试，回归测试则麻烦一点。一个是需要的环境更复杂，另一个是执行的时间也更长。
这里说的回归更多的偏向于功能和性能的回归测试。按我的理解，单元测试其实也可以算作回归测试的一部分，因为在添加新功能修改旧功能的时候，单元测试可以保证原功能不受破坏。当然这样说不太严谨，单元测试不只是旧功能的验证，还可以对新功能进行测试。
在软件工程中，分层的测试金字塔，从下往上越早测试所花费的成本约小，收益约大。从单元测试→模块的集成测试→功能的集成测试。
模块回归测试实现
那么如何实现模块的自动化回归测试呢？这里的模块指整个系统的子系统，可以理解为微服务的一个小服务。
测试用例和测试脚本的管理
首先得考虑模块的自动化回归测试需要哪些东西？怎样才能做到自动化？
对于测试，其实不外乎测试用例的描述和执行，而在执行过程中，则会依赖一些外部的数据。
对于测试用例，最简单直接的可以使用脚本来描述，执行脚本输出测试结果。
当然也可以使用一些结构化的字段来描述测试用例，通过测试框架来做的更通用一些。
这里以脚本为例，如何实现一个模块的回归测试。
核心是测试用例的描述和测试报告的解析，最少得跑完用例拿到测试的结果。
使用yaml来描述测试用例和测试报告。
测试用例的描述
name: ""
description: ""
before_script:
- |
echo "exec before_script"
after_script:
- |
echo "exec after_script"
enviroments: # 整个回归测试时的环境变量
CSV_LOG_PATH: ${CI_PROJECT_DIR}/tmp/debug/csv_log
LOG_PATH: ${CI_PROJECT_DIR}/tmp/debug/log
test_cases: # 测试用例的描述
- name: case1
description: " "
enviroments: # 单个 case 执行过程中的环境变量
APP_NAME: app1
before_script:
- echo "exec case before_script"
after_script:
- |
echo "exec case after_script"
command: "cd scripts && bash run.sh"
case_files: # nas 上 /data 下的目录,在执行过程中自动增量同步测试数据
- module/data
这个格式主要是模仿 gitlab ci的yaml 格式。
·before_script 和 after_script 主要是提供测试用例运行前后的钩子函数，方便做环境的准备和清理
· enviroments 主要是提供环境变量的配置，支持系统环境变量的内嵌，方便测试脚本的复用
· case_files 指定测试需要的数据，会通过环境变量的形式注入到脚本运行环境中
测试报告的描述
name: case1
duration: 2000 # 单个 case 花费的时间，单位：秒
pass: true
extra: # 额外需要记录的信息，格式不限
sub_cases:
- name: left
duration: 1000 # 单个sub case 花费的时间，单位：秒
pass: true
extra: # 额外需要记录的信息，格式不限
- name: right
pass: true
duration: 1000 # 单个sub case 花费的时间，单位：秒
extra: # 额外需要记录的信息，格式不限
测试报告本身并没有太多的东西，主要是结果是否通过，执行时间（用于后续测试的优化）等等。
测试脚本环境变量
为了方便测试脚本的编写，同时也是为了方便管理，测试脚本中可以使用一些环境变量
# ENV_REGRESSTION_TEST 是否在回归测试环境中，通过这个变量区分本地和 CI 过程中，方便调试
ENV_REGRESSTION_TEST="true"
ENV_REGRESSTION_TEST_CASE_NAME=case1
ENV_REGRESSTION_TEST_CASE_MODULE=app
ENV_REGRESSTION_TEST_CASE_REPORT_PATH=/data/regression/report/${module}/${CI_PIPELINE_ID}
# ENV_REGRESSTION_TEST_CASE_FILE 测试用例数据文件的环境变量
ENV_REGRESSTION_TEST_CASE_FILE=/data/regression/${module}/${dir_or_file_path}
# ENV_REGRESSTION_TEST_CASE_REPORT_FILE 单个 case 生成报告的文件名，可以直接将结果写入到这个文件，由框架统一收集整理成整体的测试报告
ENV_REGRESSTION_TEST_CASE_REPORT_FILE=/data/regression/report/${module}/${CI_PIPELINE_ID}/report_case_{case_idx}_{case_name}.yaml
测试用例形式已经约定好了，那么如何实现测试用例和测试脚本的版本管理呢？
因为不同版本的功能或者性能要求是不一样的，那么每个版本所需要测试用例或者脚本可能也是不同的。为了保证软件版本和测试用例、测试脚本的版本一致，将测试用例和测试脚本维护在模块所在的git 仓库中。
也听说过以excel管理测试用例，通过文档的形式管理测试脚本，这种方式我认为更适合整个软件的集成回归测试。当然更标准的做法是有测试用例和脚本的管理系统，可以根据提测的内容调整所需要的测试用例。比如开发定位修改的内容，针对性的进行回归测试。不过这个成本相对来说更好，也需要一定的开发能力。
测试数据的管理
另一个需要考虑的是测试所需的数据应该如何管理？
模块回归测试的数据是相对来说是比较大的，可能达到Gb的量极。这么大的数据，如何高效快速的执行。不可能每次跑回归测试时再临时的拉取，也不可能放在代码仓库中管理。为了方便管理，将所有的数据统一存放在nas上，跑回归测试时，根据测试用例描述的case_files,自动增量拉取。也可以定时的增量同步，缩短拉取所需要的时间。
同时还需要考虑如何进行测试数据的版本管理。保证测试用例的版本和所需的数据版本一致，可重复执行，所以测试数据可以进行新增但严禁覆盖的操作，最好有专门的人员进行统一的管理。
如何通过代码实现自动化的回归测试呢？通过 python 脚本实现测试用例和报告的yaml文件解析，在代码推送时，自动触发gitlab pipeline，实现本身并不太复杂。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
