集成测试套件
在撰写本文时,我们有60个集成测试,这些测试在真实场景中测试abrt、libreport和satyr功能。
这些测试每晚都会针对当前受支持的Fedora和Red Hat Enterprise Linux版本运行。你可以在我们的网站上找到结果 public mirror .
运行测试套件
小心
不要在你的机器上运行测试套件 直接地 ,使用虚拟机或专用于测试的机器。
- 在虚拟机或专用机中:
克隆ABRT存储库:
git clone git://git.fedorahosted.org/abrt.git
去
abrt/tests/runtest/
运行
./run
这将按中指定的顺序运行所有测试 ./aux/test_order
. 测试完成后,可以在 /tmp/abrt-testsuite/
.
要覆盖目标目录或其他选项,可以编辑 ./aux/config.sh
.
运行单个测试
要只运行其中一个测试,必须通过 ./aux/runner.sh
. 此脚本通过重新启动所需的服务和清除可能的过时文件来准备系统。
例如,运行 dbus-api
考试,你必须通过整个考试 runtest.sh
到 runner.sh
脚本::
./aux/runner.sh dbus-api/runtest.sh
运行测试的子集
要仅运行部分测试,请编辑 ./aux/test_order
将不想运行的测试归档并注释掉。
例如,当使用测试套件测试已经安装的软件包时,您不需要构建和安装git版本。在这种情况下,您可以注释掉 abrt-nightly-build
测试和所有 \*-make-check
测验。默认情况下,这些选项现在处于禁用状态。
编写新的集成测试
- 要创建新测试,您必须:
创建一个反映其名称的目录
在该目录中创建两个文件:
可执行文件
runtest.sh
文件PURPOSE
文件
将测试添加到
./aux/test_order
这些测试是使用bash编写的 BeakerLib library . 烧杯式快速参考 [PDF] 是你需要的。
最好复制一个现有的测试作为测试的基础。好的候选人是:
run-abrtd
基本上就是一个例子,
ccpp-plugin
如果需要测试崩溃处理(如果需要崩溃目录),
dbus-api
如果需要测试DBus功能。
复杂测试
请提供复杂测试的解释。或者在中的注释中解释测试的某些部分 runtest.sh
或创建 README
测试目录中的文件。
输出目录结构
为了避免在几个不同的文件中进行痛苦的挖掘,日志记录现在分为几个逻辑级别:
$OUTPUT_ROOT
变量在中定义 aux/config.sh
它表示所有日志的根。
对于测试套件运行的每个阶段,根目录中都有相应的目录。它包含 stage.log 包含控制阶段的脚本输出的文件。
/tmp/abrt-testsuite
├── format/
├── post/
├── pre/
├── report/
├── results
└── test/
阶段:
PRE
安装所需的软件包,收集日志文件,收集系统信息
TEST
运行所有测试
FORMAT
格式化报告阶段的结果
REPORT
报告结果
POST
收集日志,清理
为了 TEST
每个测试用例都有一个附加的子目录:
/tmp/abrt-testsuite/test/
├── abrt-make-check
├── abrt-nightly-build
├── abrt-should-return-rating-0-on-fail
├── blacklisted-package
...
每个目录包含几个文件:
/tmp/abrt-testsuite/test/systemd-init/
├── dmesg
├── avc
├── fail.log
├── full.log
├── messages
└── protocol.log
只有 full.log
是强制性的。它包含 stdout 和 stderr 测试运行的一部分。 protocol.log
只包含bikerlib生成的协议。如果测试失败并出现致命错误, protocol.log
未生成。如果出现其他故障,这些故障将被提取到 fail.log
以及指向中的行的行号 full.log
.
dmesg
, messages
和 avc
每个都包含在测试运行期间编写的日志文件消息。