1 简介

Yocto 项目是一个开源协作项目，它提供模板、工具和方法，帮助您为嵌入式产品创建基于Linux的定制系统，而无需考虑硬件架构。QA团队负责验证一些可用的工具和组件，以及支持的不同平台的image完整性和功能性。

2 目标和任务

测试过程主要侧重于跟踪和审查Yocto项目及其参考系统和内部项目的质量和性能。该计划还包括识别和跟踪需要改进的领域、回归、验证增强功能和错误、开发测试方法（重点是自动测试）。除非另有说明，例如作为验证新功能过程的一部分，否则文档和许可状态不包括在测试过程的范围内。

2.1 测试目标

Yocto 项目 X.X 周期的整体测试计划旨在验证当前开发中的整体增强功能，并检测可能出现的回归。

  • Bug和功能验证
  • 运行回归测试
  • 对所需领域（如 Toaster）进行探索性测试
  • 改进和扩展整体自动化

2.2 任务

下面列出了本测试计划确定的所有任务。

  • 一般组件测试
  • 错误和功能报告
  • 错误和功能验证
  • 测试自动化
  • 探索性测试
  • 为所需领域创建测试计划
  • 与开发人员一起审查测试方法
  • 为主要功能指派QA负责人

3 测试范围

概述了测试流程，如测试领域、类型、周期和报告，以及每项验证活动的摘要和目标。各部分可链接到包含更多细节或相关信息的其他文章。请注意，本文或此处链接的文章中提供的信息可能会根据需要进行修改，以反映当前版本的Yocto项目所开展的实际活动。

4 测试策略4.1 测试内容

Yocto项目下的每个内部项目都是需要测试的领域。测试区域按其功能性质分组如下：

  • 构建系统
  • 运行时测试
  • 开发工具
  • Distro 测试

4.1.1 构建系统

构建引擎及其周边组件，为构建映像或烘焙软件提供手段。在这一区域将执行构建时测试。目前oe-selftest涵盖所有Bitbake、oe-core和Metadata自动测试。

  • BitBake

对BitBake进行功能测试，BitBake是一个构建引擎，它的所有功能和组件都能在各种配置和场景下运行。

  • Toaster

Toaster是Bitbake构建系统和Yocto项目内Poky发行版的网络接口。该项目原名为Web Hob/Webhob/webhob，你可能仍会在文档中找到对旧名的引用。Toaster测试计划维基涵盖了针对Toaster的所有验证。测试过程主要集中在验证从构建过程中收集到的数据，以及验证Toaster GUI的正确功能，例如

  • 用户界面

  • 与bitbake进行的后台交互

  • 后台与数据库的交互，用于存储和访问构建信息

  • 测试目标只涉及Toaster现有功能的正面测试。

  • 执行探索性测试，重点关注更新的功能；这有时会产生新的测试用例。

  • 元数据(Metadata)

对Yocto项目核心元数据的测试主要是通过上述BitBake和Toaster 等其他测进行的。我们还在meta-yocto测试运行模板中设置了涵盖元数据的特定测试，并定期在Full Pass上运行。

  • 发行版测试

发行版测试旨在使用yocto-autobuilder捕捉发行版特有的bug。所有测试都在相同的硬件上运行，并更新了所有操作系统。使用的发行版包括Fedora、Ubuntu、CentOS、OpenSuse及其最新更新版本。如果发行版在发布期间有测试版，则 n+1（测试版）也将进行验证。

更多详情，请参阅 “发行版测试计划”。

4.1.2 运行时测试

主要针对目标操作系统或其附带的应用程序，作为构建过程的输出。

我们使用映像测试来运行自动测试。

  • 冒烟测试

冒烟测试由公共AutoBuilder 执行，所有BSP构件均在此构建，并检查构建是否正确。在公共AutoBuilder中，还对QEMU映像运行映像测试。

  • 每周测试

包括运行所有自动BSP测试，这些测试的目标是每周针对每周构建运行一次。镜像测试维基页面介绍了测试的启用和运行。测试适用于QEMU BSP和安装在真实硬件上的BSP。

  • 全量测试

全量测试旨在运行非自动化的BSP测试用例。它们扩展了每周测试的覆盖范围，包含更复杂的场景，如更改运行级别或音频测试。

  • 压力测试

压力测试在Beagleboard和genericx86-64 BSP上运行。详情如下：

  • Beaglebone core-image-sato-sdk映像使用LTP和Crashme压力测试进行测试

  • genericx86-64 core-image-lsb-sdk映像使用Helltest和Crashme压力测试进行测试

  • 系统性能（未实施）

目标：跟踪目标系统的运行时性能；跟踪带有gcc安全标记的目标系统的运行时性能；

指标：systemd 和 sysvinit 的启动时间；从Buildhistory跟踪回归的image大小；Piglit测试套件结果；可集成的其他基准，如openbenchmarking网站上列出的基准。

4.1.3 开发人员工具

  • 应用程序开发工具包（Application Development Toolkit）：ADT测试包括meta-toolchain-sdk和用户构建sd 测试。它将在每周测试和全量测试中涉及。

    • 交叉工具链安装和编译测试
    • 可重置SDK
    • 可扩展 SDK (eSDK)
    • 工具链压缩包
    • yocto 构建树

  • Eclipse IDE插件：Eclipse 插件测试将涵盖基本功能。这包括安装、配置Yocto项目ADT设置、Yocto BSP、Bitbake 项目以及项目编译和部署到目标。根据将要实现的功能，将添加新的测试用例，以支持Windows和Mac。这将在”功能”部分详细介绍。

    • 无头构建
    • 创建 C/C++工程
    • 调试/部署
    • 用户空间工具
    • Bitbake工程

根据SDK的新功能（如 MacOS 和 Windows 支持），将运行其他测试以验证新功能。

有关eclipse测试自动化，请参阅Eclipse测试框架部分。

  • 构建设备

将测试构建设备的基本功能。测试包括成功构建构建设备镜像。

4.1.4 测试周期

以下是最常用的通用测试周期，但每个Yocto项目的测试版本都可能发生变化。

  • 冒烟测试：简短快速的自动测试，执行时间不超过 10 分钟。

    • 测试范围：在AutoBuilder上触发。
    • 目标：
      • 无错误完成构建；
      • 检查QEMU映像的基本功能，如启动、网络、软件包管理器等；
      • 根据构建类型确定测试周期是否可以继续。
      • 在AB上运行的测试是映像测试。根据目标镜像类型，其配置存储在AB配置文件”yocto-autobuilder/buildset-config”中。

  • 每周测试

    • 测试范围：每周构建并通过发行团队发布的镜像。
    • 目标：
      • 用最少的测试集对大部分区域进行功能测试；
      • 回归测试：极有可能发现错误。

  • 全量测试

    • 范围：作为里程碑或最终版本候选的image；
    • 目标：确保所有Yocto项目组件的功能。

  • 发布测试

    • 测试范围：发布通过全量测试的候选版本
    • 目标
      • 涵盖或重新安排所有预定功能；
      • 修复并验证所有相关错误。
    • 增加覆盖范围
      • 压力测试
      • 合规性测试
      • 分发测试

4.1.4 测试执行

测试执行将按照https://wiki.yoctoproject.org/wiki/QA#QA_Process的QA维基页面中定义的QA流程进行。

参考资料

  • 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
  • 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
  • python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
  • Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
  • https://wiki.yoctoproject.org/wiki/QA/Master_Test_Plan#Test_Plans

5 测试工具5.1 AutoBuilder

参见：https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder

5.2 oe-selftest

Oe-selftest是用于测试OpenEmbedded构建系统的测试框架。以下是介绍oe-selftest的一些要点：

  • 基于Python unittest
  • 旨在模拟正常使用模式
  • 不包括image运行时测试
  • 实现了一个新层，其中包含仅由测试使用的通用/特定元数据

更多参考：Oe-selftest wiki。

5.3 image测试5.4 合规性测试

用于genericx86-64的合规性测试套件/框架：

  • LSB（Linux Standard Base）测试
  • POSIX（Portable Operating System Interface for UNIX）测试
  • LTP（Linux Test Project）测试

安装步骤

  1. 从autobuilder下载lsb映像（与genericx86-64-lsb bsp LSB 每周测试中的映像相同），我们使用 genericx86-64-lsb、core-image-lsb-sdk 在NUC上测试合规性

2.在DUT上安装镜像

3.配置网络，使其能联网工作：编辑/etc/resolv.conf并添加网关IP地址；使用”ifconfig”命令添加IP和掩码；使用 “route add default gw “添加路由；使用”export http_proxy=”命令添加代理

  1. 在DUT上复制 “compliance_test.py”脚本
    5.确保网络连接正常
    6.像这样运行脚本：”chmod a+x compliance_local.py” ; “./compliance_test.py “。等待 “配置完成。必须从机器启动LSB 脚本。”（约 8-12 小时）
    7.通过ssh或手动运行”LSB_test.sh “并等待其完成（约一天）
    8.从DUT获取日志：result–data.fulllog;result–data.log;result–data.fail;posix.log（可在以下位置找到：/opt/ltp/testcases/open_posix_testsuite）,其他三个日志在 /opt/ltp目录下的 output、temp、result文件夹中。日志需要发送到yi.zhao@windriver.com，并指定版本和映像类型
    ;在/var/opt/lsb/test/manager/results/x86…/x86….tar.gz（您可以使用自动完成（选项卡）轻松找到它）,它大约有 18 兆字节,将此文件上传到硬盘，并将链接发送到 hongxu.jia@windriver.com和mark.hatle@windriver.com，我还会发送电子邮件。

9.将Testopia – Runtime测试运行中的测试放在已通过的测试中。

脚本可在此处找到： http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=cagurida/compliance

5.5 pTest

ptest（软件包测试 package test）是一个概念，用于构建、安装和运行软件包本身包含的测试套件，同时产生一致的测试执行输出格式。有关启用和安装的更多详情，请访问Ptest。

安装和运行步骤

  • 从autobuilder下载pTest映像（可在pTest目录中找到core-image-sato-sdk映像）
  • 将映像安装到DUT上（使用传统启动方式）
  • 启动映像并在DUT上复制”ptest-runner.sh”脚本
  • 在命令行中运行”ptest-runner.sh > ptest.log”并等待完成（约 5 小时）

5.6 Eclipse测试框架

Eclipse测试框架使用Dogtail实现测试自动化。有关安装和框架的详细信息，请参阅 contrib 上的 eclipse-framework README。Dogtail是用Python编写的图形用户界面测试工具和自动化框架。Dogtail脚本用Python编写，并像其他Python程序一样执行。

5.7 构建性能测试

在多个常用配置中，根据通过构建流程所花费的时间，对构建系统的性能进行跟踪。

使用的工具：http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/contrib/build-perf-test.sh
更多详情，请参阅性能测试wiki。
目前，可在此处以图表形式查看构建性能结果（从 YP 1.6 开始），点击此处

5.7 补丁自动测试

[待定] – 未实现

6 测试自动化

  • 目标
    • 通过自动化当前测试，减少手动测试的工作量；
    • 改进运行时测试。
    • 改进构建时测试。
  • 工具
    • Distro 测试
    • AutoBuilder
    • 在AutoBuilder上运行映像测试。
    • 可以使用Oe-selftest。目前oe-selftest 也在公共AutoBuilder上运行。

6.1 测试自动化贡献库

  • Oe-selftest
  • Image tests
  • Ptest
  • Toaster
  • Eclipse测试框架

7 测试时间表

有关项目的总体日程安排，请访问被测版本测试计划中的”日程安排”部分

8 进入和退出标准

本节定义了开始和结束测试周期的标准：

8.1 进入标准

  • 发布候选版本并发送”开始QA活动”邮件。
  • 自动生成image可用
  • 候选版测试运行模板已准备就绪
  • 已发送包含使用日期和构建说明的邮件

8.2 退出标准

  • 计划的所有组件均已 100% 完成
  • 所有失败/受阻的测试用例都与有效的错误相关联（未解决也未验证）
  • 重大问题导致组件/构建受阻

还定义了一般标准，请参阅”通过/失败标准”部分

9 假设和限制

TBD

10 验证

  • 目标

验证当前版本的Yocto项目中引入的新变更功能是否正确。

  • 输入标准

    • 通过填写 “QA Owner “字段来跟踪中+/高增强的变更
    • 变更在Bugzilla中被列为优先
    • Bugzilla 条目在当前版本中有目标里程碑
    • 更改已记录在案，或在无需记录时已指出（相应地设置doc标志）
    • 错误状态设置为”已解决”。

  • 退出标准

    • 变更已为编写测试用例（如适用）做好文档记录
    • 计划测试用例已通过
    • 错误状态设置为已验证

11 测试报告

  • 目标
    • 在最新版本中显示当前测试运行的实时状态；
    • 在测试周期结束时向Yocto项目邮件列表发送报告电子邮件；
    • 归档报告；
    • 使用QA状态模板进行报告；
    • 在最终版本发布后更新版本维基

关于具体的可交付成果，请查看当前测试版本的”测试可交付成果”部分。

12 测试计划

本节分为两种类型的测试计划：发行版和组件。

13 测试执行

有关Yocto项目各版本测试执行的历史信息，请访问Releases。

有关当前测试版本的测试执行的具体信息，请访问最新Test Plans中的”执行历史”部分

钉钉或微信号: pythontesting 微信公众号：pythontesting