标签: 云端测试

在此 Docker 教程中，你将学习如何创建 Helix QAC 并将其作为容器化 镜像 运行。 Docker 的基本定义是一种开源和流行的操作系统级虚拟化（通常称为 “ 容器化 ” ）技术，它是轻量级的，可移植的，并且主要在 Linux 和 Windows 上运行。 Docker 使使用容器创建、部署 和运行应用程序变得更加容易。 从根本上说，容器只是一个正在运行的进程，并应用了一些附加的封装功能。借助容器，开发人员（和 DevOps 管理员）可以将应用程序与运行应用程序所需的一切（包括代码、运行时、库、配置的环境变量和配置文件）打包在一起，并将其全部作为一个包提供。 还值得一提的是， Docker 可以立即启动，并具有用于版本控制和组件可重用的内置机制。这些 Docker 容器可以通过公共 Docker 中心或私有存储库共享，从而使其易于访问和使用。 以下是 Docker 的一些最显著的优势： 快速部署： Docker 可以为每个进程创建一个容器，然后可以根据需要快速启动和 删除 该容器，而无需启动平台操作系统 （ OS ）。这将部署过程时间缩短到几秒钟 此外， Docker 镜像 启动几乎是 实时响应 的。 可移植性： Docker 允许将经过测试的容器化应用程序部署到运行 Docker 的任何其他系统，并确保其执行方式与您测试时完全相同。 Docker 镜像 可以与其他团队共享。 性能： 尽管虚拟机 （ VM ） 是容器的替代方法，但 VM 具有操作系统，而 Docker 容器则没有。这意味着容器的占用空间比 VM 小，创建速度更快，并且启动和 删除 时间更快。 持续集成效率： Docker 使你能够构建容器 镜像 ，并在从开发 、 测试到部署的每 个步骤中使用它。此外，您还可以分离不相关的步骤 并且 并行 地 运行它们，从而缩短从生成阶段到生产部署阶段所需的时间。这减少了设置环境和调试特定于环境的问题的时间，使它们更可靠，更易于维护。 但是， Docker 存在一些限制，尽管它们对 Docker 静态分析器 的设置的影响很小甚至为零，但了解这些限制对您来说仍然很重要。 Docker 不能替代虚拟机： 许多在 VM 中运行的应用都可以移动到容器中，但这并不意味着它们都可以或应该移动到容器中。例如：具有严格法规要求的行业可能无法将容器交换为 VM ，因为 VM 比容器提供更多的隔离。 容器中的数据： 有时容器确实会出现故障，在这种情况下，它需要备份和恢复策略。虽然有几种解决方案，但没有一个是自动化的 或者 尚不可扩展的。另一个限制是，除非您在容器关闭之前先将其保存在某个位置，否则当它关闭时，其中的所有数据都会永远消失。 跨平台兼容性： 如果应用程序被设计为在特定平台（如 Windows OS 平台或 Linux ）上的 Dock er 容器中运行，这是一个主要问题，因为它无法在任何其他平台上运行。但是，虚拟机不受此限制的约束，因此 该 限制使 Docker 对一些由 Windows 和 Linux 服务器组成的高度异构环境的吸引力降低。 使用图形界面运行应用程序： 通常， Docker 设计用于托管在命令行上运行的应用程序。虽然我们有几种方法（如使用 X11 转发或 MobaXterm ）可以在 Docker 容器内运行图形界面，但这些过程很笨拙。因此，我们可以说 Docker 对于需要丰富接口的应用程序来说不是一个好的解决方案。 为了帮助将静态分析工具设置为 Docker 并解决这些限制，我将把设置分解为三个简单的部分。 一个适合入门者学习的网站是 https://docs.docker.com/get-started/overview ，其中包含有关设置 Docker 引擎的大量详细信息，以及如何验证环境的正确设置。 第一部分：准备 Docker 引擎 从此站点下载并安装适用于您选择的操作系统 （ OS ） 平台的 Docker 引擎： https://docs.docker.com/engine/install 要验证 Docker 引擎是否已正确安装，请运行名为 “hello-world” 的示例 Docker 镜像 。使用以下命令示例： $ sudo docker run hello-world 该命令将下载一个简单的 “ hello-world 测试 Docker 镜像 ，并在容器中运行它。因此，当容器运行时，它会 打印 消息并退出。 我们的 Docker 容器教程的下一部分的目标是将 Docker 容器设置为作为 Helix 静态代码分析工具 运行。有几种方法可以配置 Docker 镜像 以支持不同的编码合规性模块，例如 MISRA 、 AUTOSAR 、 CWE 、 CERT 和静态代码扫描工具等。 但是，在本教程中，我将仅演示如何使用一些重要组件构建特定的 Docker 镜像 ，我们将在 Docker 容器中将这些组件用作 Helix QAC 工具 （ DaaQT ）。 此外，我将讨论在运行分析扫描工具时如何处理项 目数据配置的持久性，以便您可以将 Helix QAC 项目规范和项目支持配置文件存储在 docker 容器之外，例如 prqa 项目文件夹和 pqraproject.xml. 支持的文件。 即使 Docker 容器执行完成并关闭，对这些文件所做的任何更改都将保持不变。从 docker 执行上的生成到生成的任何生成脚本更改都将输出到主机上映射的外部项目文件夹，并保持持久性。 第 二 部分：创建、生成和运行 首先，让我们确定我选择用于构建 docker 镜像 的一些组件及其基本说明。 Helix QAC-2022.2 （ C/C++ 静态分析解析器） ASCM-3.3.0 （ AYTOSAR C++14 编码合规性） M3CM-3.3.0 （ MISRA C 2012 编码合规性） MCPP-2.3.0 （ MISRA C++ 2008 编码合规性） CERTCCM-2.3.0 （对 C 的安全编码标准支持） CERTCCPCM-2.3.0 （ 支持 CPP 的安全编码标准） 接下来，下载您 试 用（或已购买）的 Helix QAC 解析器工具和编码合规性模块，并将这些安装文件放在主机上的已知文件夹位置。 在我的示例中，将有六个文件（一个解析器工具文件和五个编码合规性模块）。 接下来，创建一个 docker 构建脚本文件。例如，我将文件命名为 “qacDockerfile” ，没有文件扩展名（默认名称为 “dockerfile” ）。 docker 引擎将使用此文件创建 docker 镜像 。基本上，它有一个命令列表，可以发送给 docker 引擎，以自上而下的顺序执行它们。 。 然后将这些文件（包括 qacDockerfile ）放在 DaaQT 文件夹中。这些是生成此 docker 镜像 所需的唯一文件。另外，请注意，我已经将它们放在 “vDockerBuilds/DaaQT” 文件夹下。 以下是 “qac 文档 ” 脚本文件的内容以及一些说明。 第 1 行是使用 Ubuntu 22.04 作为基本 镜像 开始的。 第 4 行至第 7 行使 Ubuntu 操作系统保持最新状态，并允许时区设置。 第 10 行是可选的，但建议添加这些有用的工具，因为 Ubuntu 基础 镜像 是准系统 镜像 。 第 15 行将安装基本的构建工具、 gnu 编译器依赖项和任何支持文件。此步骤对于编译器工具链使用需求会有所不同。但是，在我的示例案例中，此图像将使用 gcc/g++ 11 编译器。 第 19 行和第 20 行指示 Docker 引擎创建一个名为 “QacWorkspace” 的工作目录，所有子顺序命令都将使用该目录。 第 25 行将所有安装文件的权限更改为可执行文件。 第 28 行以静默模式安装 Helix-QAC 解析器工具并接受许可协议。 第 31 行至第 35 行以静默模式安装选定的编码合规性模块，并接受许可协议。 第 38 行正在清理安装文件，以使 docker 镜像 尽可能小的占用空间。 接下来，要构建 docker 镜像 ，我们需要运行以下命令： docker build --pull --no-cache -f qacDockerfile -t qacscatools ： 22v2. 拉取和无缓存参数是为了确保它始终获取最新的 ubuntu 镜像 ，并从头开始构建 docker 镜像 。 -f 是 qac Docker 文件名称，默认情况下，原始名称是 dockerfile 。 -t 是格式 “ 名称：标签 ” ，因此名称是 “ qacscatools” ，标签是 “22v2” ，以指示使用了哪个 Helix-QAC 工具版本。 不要忘记末尾的 “ 点 ” ，这表明它是一个本地目录。 构建 镜像 过程完成后，您可以看到最后两行消息，这些消息指示写入文件并标记 镜像 。若要验证生成是否成功，请运行以下命令以显示所有可用 Docker 镜像 的列表。 docker images （注意：在上图中，图像标记 ID 为 bd8c9d08dc4d 。 ） 第三部分：在本地项目上运行 DaaQT 在使用此 docker 容器化 镜像 （ Docker 作为 QAC 工具 – DaaQT ）在本地桌面项目上运行任何静态代码分析之前，我们需要确保可以访问许可证服务器以获得使用该工具的权限。 在我的示例中，我将使用外部远程 Reprise 许可证管理服务器来请求要使用的许可证。 首先，我们需要创建一个本地项目运行脚本，该脚本知道在何处以及如何访问远程 Reprise 许可证服务器。此项目运行脚本还必须知道 Helix QAC Dashboard 服务器所在的位置，以便在分析运行完成后上载项目诊断消息结果。 让我们回顾一下名为 “runQACSCA.sh” 的脚本文件及其内容。我将逐步提供一些关于它的作用的解释。 第 3 行是对桌面计算机上项目文件夹名称的引用。 第 7 行是 Helix QAC Dashboard 服务器上的项目持有者的名称，用于上载诊断消息和项目信息。 （注意：第 8 行可用于与本地文件夹名称匹配。 ） 第 9 行到第 11 行是有关 Helix QAC Dashboard 服务器的信息，例如 URL 地址（或 FQDN ）、服务器端口和许可证服务器端口。 第 14 行是本地桌面项目工作区名称 “ 服务器 URL 地址 ” （或 FQDN ）、服务器端口和 “ 许可证服务器端口 ” 。 第 15 行和第 16 行引用了 Helix QAC 解析器工具所在的内部 docker 镜像 ，以及映射项目工作区位置。 第 19 行用于使 Docker 与许可证服务器通信，以请求工具许可证以供使用。 第 25 行将 Docker 镜像 设置为映射的项目工作区所在的正确入口点。 第 28 行到第 29 行是选择要用于项目的规则配置文件之一。这些默认文件名是为特定规则组配置标识的。您可以通过合并任何一个或多个规则配置文件来创建自己的客户 RCF 文件，但是，自定义 RC F 文件需要在 Helix QAC 桌面 GUI 应用程序中完成，然后才能使用。此外，新的自定义名称需要与默认文件名不同。 第 34 行和第 35 行用于映射到要使用的编译器工具链。对于我的例子，我已经映射到使用任何一个 GNU C/CPP 11.2 版本。 第 38 行是创建 PRQA 项目配置并设置要求项目配置。 第 41 行允许 Helix QAC 监控和跟踪如何使用其命令在本地构建项目的方式。 如果项目需要执行一些关系跨模块分析 （ RCMA ） 和 / 或多线程分析 （ MTA ），则通常使用第 44 行和第 45 行。 第 47 行至第 49 行是选择一个编码合规性模块，用于满足您的编码合规性需求。请确保此设置与第 28 行到第 31 行的 RCF 设置匹配。 第 52 行是使用上述所有配置和设置参数对项目执行静态代码分析。 第 55 行是将项目分析扫描结果上传到 Helix QAC Dashboard 服务器，并将其放在项目支架中。上载的信息是包含诊断消息和项目配置设置的源代码文件。 运行以下 docker 命令，这些命令会将本地项目卷映射到 docker 项目卷，以便保留分析数据文件。请密切注意 ENTRYPOIN T 参数，其中脚本文件 “runQACSCA.sh” 将从项目根文件夹执行。 以下是带有一些解释的 Docker 命令： docker run --rm -it -v ~/ProjectsSandbox/MyCppCodeQac:/QacWorkspace/MyCppCodeQac--entrypoint=/QacWorkspace/MyCppCodeQac/runQACSCA.sh qacscatools:22v2 “ run ” ，就是执行。 “-it” 以交互方式运行 Docker （所以你会得到一个带有 STDIN 的伪 TTY ）。 “--rm” 使 Docker 在容器退出时自动将其删除。 “-v” 表示卷映射本地主机卷： DockerVolume 。 “-- entrypoint ” 表示登录时从哪里开始，命令行开始运行带有说明内容的位置 /file_name.sh 。 您还可以使用 shell 脚本来运行它，而不必记住在命令行上键入所有这些参数。除了不必记住所有这些细节之外，这还允许我们对脚本文件进行最小的更改，以适应其他类似的项目。 对于我的示例，我创建了一个名为 “runDaaQT.sh” 的 shell 脚本。 显示 docker 命令行用法的屏幕截图。 显示 shell 脚本用法的屏幕截图。 （可选）还可以为 CMakeNinja 项目运行此 Docker 容器， 它的命令行与之前演示的项目类似 。此项目使用 CMake 和 Ninja 命令行 构建 系统。 要使用类似的命令行或 sh ell 脚本文件，您需要在命令行中对正确项目卷 （ CMakeNinja ） 名称的命令语法进行一些编辑，如下所示： docker run --rm -it -v ~/QacProjectsSandbox/CMakeNinja:/QacWorkspace/CMakeNinja--entrypoint=/QacWorkspace/CMakeNinja/runQACSCA.sh qacscatools:22v2 CMakeNinja 项目的命令行用法 截图 。 ➡ ️ H elix QAC 免费试用版 ➡️➡️➡️ 立即申请免费试用Helix QAC,发送邮件至info@polelink.com

最近，我们经常听说解决方案是去云端。但是为什么呢? 我们注意到，云技术现在在科技领域非常流行。即便在嵌入式开发领域，也有越来越多的人希望将开发转移到云中或与云一起进行。 我们从用户的角度为您总结了我们的汽车客户努力转移到云计算的3个主要原因。 原因 1: 数字化工作场所: 统一、安全、可归档、快速部署 一些客户希望为他们的员工创建一个数字化工作场所。对于用户来说，这意味着他们可以得到任何笔记本——有时被称为瘦客户机——并通过互联网拨号进入公司提供的数字办公场所。数字工作场所最终给用户的感觉就像普通的操作系统。 管理员在推出新软件时会节省大量精力。有很多人在讨论这样是否更安全。对于用户来说，速度、可用性和鲁棒性非常重要 云端数字工作场所的最大优势之一是，配置(例如操作系统和应用程序)可以完全推出和存档。 用例归档配置是从过去的任何时间点恢复一个工作站。因此，旧的软件版本可以在最初使用的开发环境中进行修补。 为什么要这么做？ 在汽车领域，你需要具备在软件第一次发布5年或10年之后修复软件的能力。 经验表明，在产品开发的同时，所使用的基础结构也在不断改进和扩展(新脚本、新工具、新方法等)。这对于整个团队来说都是非常好的，除非一个旧的软件版本必须被修复。 大多数情况下，调整基础设施以构建/测试软件所花费的时间比实际打补丁和保护软件所花费的时间要长。 解决方法:恢复旧环境，补丁软件，测试，部署，结束。 原因 2: 数字化工作场所: 数据和工具紧密相连，便于快速访问。 在许多开发团队(驾驶辅助、人工智能、图像处理等)中，产品开发需要大量的数据。这些数据主要存储在服务器或云上，以实现中央可用性。 在开发过程中，数据必须通过主机PC在本地可用。结果是下载时间过长。这要花很多时间。开发者的解决方法是用一夜时间下载。总而言之，这种方法既不可持续，也无用，对于开发人员来说，等待也不有趣。 其理念是将开发工具引入云端——尽可能接近数据(图像、视频、测量等)。这种方法的优点是大大减少了访问时间。新数据立即可用。几乎不需要等待数据。当他们运行测试时，仍然需要一些时间。这也是使用云技术的第三个原因。 原因 3 ： 加速执行以获得更快的结果 开发应该/必须变得越来越快。随着功能的增加，测试成为了一个挑战。特别是使用真实数据的测试执行可能会花费很长时间。我们的客户在驾驶辅助或自动驾驶方面的测试需要几天到几周的时间。在开发的火热阶段，这通常是非常烦人的。 “它必须快一点!”，这句话你可能会从某些工作组的经理那里听到。 好消息是:它可以更快。 同样，解决方案是: 使用云。 测试执行的主要限制因素是环境的资源。 本质上是RAM和CPU的功率。 在云计算中，用户可以随意提高或降低参数。在此上下文中区分了两种类型的扩展:垂直扩展和水平扩展。 垂直扩展指的是机器RAM和CPU功率的增加。这允许用户按需显著地加快测试执行实例的速度，甚至可以在很短的时间内完成。这很强大，但不幸的是，这在某种程度上也是有物理限制的。然后水平扩展就起作用了。 水平扩展指的是测试执行的多个实例化。换句话说，用户克隆他们的基础设施，并将测试拆分到多个实例中。因此，它们可以并行计算，理论上可以变得无限快。然而，这也需要相应的预算，不建议日常使用。 用户需要提前澄清和设置一些关于拆分的问题。用户必须设计和实现拆分测试和合并数据。这需要一点脑力。 总之，对于嵌入式开发来说，云是一个令人兴奋的未来主题。它可以解决过去的一些问题(存档)，并可以在关键阶段显著加速这些问题。我们将继续在这一领域投资，并迅速扩大我们的能力。 作为一名全球测试专家，我们已经在云测试方面积累了几年的经验。我们很高兴与您分享我们的知识。欢迎与我们的软件专家交流，并创造产品质量的新高度。 TPT在TPT 17版本之后支持通过Docker 的云端测试提高计算能力的可扩展性，助力客户测试效率提高。 TPT作为PikeTec公司的嵌入式软件测试工具，具有很高的扩展性和便捷性。随着软件测试日趋复杂并且需求多样化，TPT不断改进以满足与时俱进的要求。您可以在所有开发阶段使用TPT进行测试。无论是简单的单元测试还是复杂的系统测试，TPT都能够使得测试变得快捷、简单和直观。 PikeTec公司是全球知名的基于模型的嵌入式系统测试工具TPT的软件供应商，总部位于德国柏林。北汇信息作为PikeTec在中国的独家合作伙伴，致力于帮助中国客户提升嵌入式控制系统的开发效率。目前，TPT已被众多国内知名主机厂和零部件企业认可，在新能源（VCU/BMS/MCU）以及ADAS等领域中被广泛应用。 本文翻译自PikeTec官网。原文链接：We Run Testing in the Cloud - PikeTec