oec-hardware测试工具的测试流程分析

本篇博客结合项目代码来介绍一下oec-hardware测试工具的测试流程，即工具是如何从运行命令到开始测试各个测试项的。本篇博客以兼容性测试(compatibility)为例，同时不涉及具体测试用例的测试流程分析。

流程是自己阅读代码总结出来的，供大家参考。

• 测试环境：浪潮云启操作系统（InLinux-23.12-LTS-SP1）
• 测试工具版本：oec-hardware 1.1.5

oec-hardware项目简介

oec-hardware工具是openEuler社区提供的一款硬件兼容性测试工具，oec-hardware提供服务器整机、板卡与openEuler的兼容性验证测试，验证仅限于基本功能验证，不包括性能测试等其它测试。

具体安装使用流程参考项目文档。

项目地址：https://gitee.com/openeuler/oec-hardware

代码框架概览

.
├── hwcompatible 框架主功能
│   ├── compatibility.py  框架核心功能
│   ├── client.py         上传测试结果到服务端
│   ├── command.py        bash命令执行封装
│   ├── command_ui.py     命令行交互工具
│   ├── device.py         扫描设备信息
│   ├── document.py       收集配置信息
│   ├── env.py            全局变量，主要是各个配置文件或目录的路径
│   ├── job.py            测试任务管理
│   ├── log.py            日志模块
│   ├── reboot.py         重启类任务专用，便于机器重启后仍能继续执行测试
│   ├── sysinfo.py        收集系统信息
│   ├── config_ip.py      自动检测并配置网卡IP
│   └── test.py           测试套模板
├── scripts  工具脚本 
│   ├── oech                  工具客户端命令行工具
│   ├── oech-server           工具服务端命令行工具
│   ├── oech-server.service   工具服务端 service 文件，用于启动 web 服务器
│   ├── oech.service          工具客户端 service 文件，用于接管 reboot 用例和日志转储
│   ├── oech_logrotate.sh     工具客户端日志转储脚本
│   └── kernelrelease.json    工具支持认证的系统和内核版本
├── server   服务端
│   ├── oech-server-pre.sh    服务预执行脚本
│   ├── results/              测试结果存放目录
│   ├── server.py             服务端主程序
│   ├── static/               网页图片、样式设计文件存放目录
│   ├── templates/            网页模板存放目录
│   ├── uwsgi.conf            nginx 服务配置
│   └── uwsgi.ini             uwsgi 服务配置
├── config   配置文件
│   ├── version.config        工具版本配置文件
│   └── test_config.yaml      工具测试项配置文件
├── templates                 兼容性清单模板存放目录
├── tests    测试套
└──vendor_tests               厂商测试工具存放目录

测试流程分析

本次流程分析主要包括有一下几个模块：

• oech：这是整个测试项目的入口，这里面有一个类Certlock，作用是对某一文件读写时获取或者释放独占锁。主函数处理oech及参数命令，通过创建EulerCertification实例来执行测试流程。
• compatibility.py：oech兼容性测试的主程序。该文件只维护一个类EulerCertification。
• job.py：Job类负责测试的实际运行，在这个类中进行测试类实例的setup初始化，同时执行实例的test()方法。
• device.py：device模块中维护两个类，一个是Device类，该类负责维护某个设备信息；另一个类是CertDevice类，该类的维护的核心方法get_devices()，该方法获取系统中的所有可用设备并用一个devices列表进行维护。

EulerCertification中的测试核心流程

1. 利用udevadm info --export-db命令扫描设备数据库，获取所有的设备信息；
2. 根据设备名称或类型等字段信息生成设备字典sort_devices，该字典的key与测试套（tests目录）中的用例的文件名是对应的；
3. 利用设备字典生成test_factory；
4. 利用choose_tests方法将test_factory中的test["run"]设为True；
5. 对于test_factory中的每一个"run"字段为True的test字典生成testcase，testcase字典中存有对应的测试类实例。将这些testcase集成到test_suite中。
6. 之后将测试套件test_suite作为参数传递到Job实例中启动测试。

Job类中的核心方法

Job类主要有3个核心方法，他们的依赖关系是：

run() -> run_tests() -> _run_test()

• run()：获取测试套件 test_suite，安装测试依赖包，执行 run_tests()
• run_tests()：对 test_suite 中的每一个testcase执行 _run_test()
• _run_test()：执行单个testcase，对testcase[test]字段中对应的测试实例用setup方法，并执行测试入口test()。

注：对于每一个测试项来说，都有对应的测试类，每一个测试类都继承自Test类，每一个测试类中都定义有setup()方法用于初始化实例，以及test()方法作为测试项的测试入口。

device模块

每个Device实例都有一个properties属性是一个字典，他是通过在CertDevice类中通过get_devices()方法执行udevadm info --export-db命令获得的，他的格式如下：

{
    'INFO': '/devices/LNXSYSTM:00', 
    'DEVPATH': '/devices/LNXSYSTM:00', 
    'SUBSYSTEM': 'acpi', 
    'MODALIAS': 'acpi:LNXSYSTM:', 
    'USEC_INITIALIZED': '2747157', 
    'ID_VENDOR_FROM_DATABASE': 'The Linux Foundation'
}

总结

整个测试工具的核心测试流程是在compatibility.py实现的，首先得获得设备信息，通过设备信息生成测试套件。值得一提的是，有些测试项不用获取设备信息也能默认加入到测试套件中，这些测试项始于系统强相关的测试项，这些测试项定义在hwcompatible\constants.py中的NODEVICE宏中。生成测试套件之后就交由Job类实例来启动测试。