集成测试套件

在撰写本文时,我们有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.shrunner.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 是强制性的。它包含 stdoutstderr 测试运行的一部分。 protocol.log 只包含bikerlib生成的协议。如果测试失败并出现致命错误, protocol.log 未生成。如果出现其他故障,这些故障将被提取到 fail.log 以及指向中的行的行号 full.log .

dmesgmessagesavc 每个都包含在测试运行期间编写的日志文件消息。