标签: 动态测试

HDMI是市场上影音产品的主流接口之一，随着电竞市场蓬勃发展，HDMI 2.1规格针对电竞产品新增加了VRR(可变刷新频率)功能，让用户在玩游戏时可以减少画面的撕裂延迟等现象。VRR功能目前已普遍支持PS5、Xbox等游戏机或是Nvidia、AMD等高阶显卡，也成为消费者在考虑购买电竞屏幕时的重要评估指针。 电竞屏幕画面延迟风险与解决方案 电竞屏幕属于高阶产品，且客群非常重视其效能表现，百佳泰与市场上主流品牌及ODM在屏幕上有着长期的合作，我们在实测中发现导入了VRR功能的屏幕却仍发生画面不顺畅的状况。VRR功能应是使游戏功能更顺畅，为何却存在让画面产生延迟的风险？经过百佳泰专业顾问团队分析后，发现到因早期HDMI认证针对VRR测试是使用静态的Pattern，故只能确认画面颜色是否正常、画面是否闪烁，而无法充分验证VRR功能运作是否正常。 静态测试Pattern 针对这个问题，百佳泰能够提供最新VRR测试使用动态Pattern，搭配高速摄影机，可以充分确认画面是否有撕裂或是延迟等情况产生。周全的VRR验证方案，将确保您的电竞产品具备理想效能。 动态测试Pattern Pattern内容 测试Pattern由4个方块组成, 每个方块皆是由左至右移动 验证方法 1. 使用高速摄影机录制测试画面 2. 将录制的影片使用播放器格放(Frame-by-Frame)检视，确认每个方块都有依序移动，且无破图或延迟等现象产生

T PT19 亮点概览 1. 形式化需求：自动生成测试用例 在TPT 19中，测试用例可以通过形式化需求自动创建—只需要按下按钮。 此前，形式化需求已经自动评估。现在我们对此进行了更深一步的改进。 2. 参数集的混合执行 TPT19中 可以更容易地创建参数集，可以多次执行，当然也可以对其进行评估。 这意味着不同参数 设置 的测试用例不必被复制，并且测试项目保持清晰和结构良好。 3. 最坏情况下执行时间的指示 TPT 19 第一次为 C/ C ++ 平台指定了每个单独测试步骤的执行时间。换句话说，一个早期预警系统，它可以指示哪些测试和哪些条件会增加本地主机上的执行时间。 该指标可用于在目标处理器上进行测 试 时减少测试的选择。这意味着 : 更少的测试执行和更快地获得必要的见解。 4. 对所有目标编译器的支持 TPT19支持 为任何目标 ECU 构建软件，为任何处理器架构使用任何编译器 - 可用于 c 平台。 5. 在虚拟环境中执行PiL测试 如何在PiL测试中节省硬件？ TPT19的该项新功能对汽车环境中的应用开发团队来说试非常理想的，他们必须在真实环境中进行测试——理想情况下无需构建硬件基础设施。 TPT19中通过Lauterbach的Trace32环境可以实现虚拟环境中的PiL测试。 不仅可以 为模型或 C/ c++ 代码执行现有的测试用例，也为任何目标体系结构执行测试用例 。 在背靠背 测试 过程中，自动将 PiL 测试结果直接与之前的测试运行 (MiL 和 SiL) 进行比较。 这些测试的执行直接在主机上的模拟器中完成。不需要硬件接口和 PiL 板。 6. 压力测试 多次运行测试用例，增加检测被测系统的非确定性行为的可能性。简单地指定一个测试用例是否应该使用不同的参数集执行几次。 7. L inux环境中的Simulink模型 TPT 现在支持 Docker 环境下，在 云中的 Linux 、持续集成环境或本地主机上运行 MiL 测试。 8. 问题视图 在测试项目设置过程中新的问题视图像一个助手。它能帮助用户罗列出发生的警告和错误。 只需点击一下，你就可以直接跳转到它们的源代码并 修正 它们。 无论是脚本实现中的拼写错误，配置中的错误还是忘记了测试框架的更新 ; 所有阻止测试执行的因素都 会 被清楚地列出。 欢迎联系我们申请TPT19的免费试用。 后续我们会发布对TPT19新特性的详细解读文章，敬请期待！

目录 软件与车辆：高度复杂 测试对象，测试用例和动态测试 测试级别 测试环境 无论是 MiL 、 SiL 、PiL、 HiL 、单元测试、软件测试还是集成测试: 汽车软件测试的世界 有 很多技术术语，所以可能会 出现 两个人在同一个术语 下理解 不同的 情况 。误解可能会发生，使有效的合作变得困难——我们也知道类似的情况。让我们把事情弄清楚一点，从头开始讲。 汽车世界在不断发展，“软件定义的汽车”等新术语证明了软件对当今汽车的重要性。 在发展过程中，以前纯粹的机械领域逐渐扩展到包括软件和数字功能。汽车的功能和行为现在几乎完全是通过软件来实现的。伴随着这一点，当人们谈到软件时，测试也会立即被提及。但是为什么是软件和测试呢? 软件也只能在车上的硬件上运行，它们一起组成了一个ECU(电子控制单元)。这些车辆配备了多达150个 ECU ，大约有1亿行代码(LOC)。 ECU 之间相互通信和交互，以实现车辆的特定功能，并使其对客户 具象化 。 有这么多编程代码，还能出什么问题? 让我们来看一个客户可以直接体验的车辆功能示例:在仪表盘中显示交通标志。 它是这样工作的: 照相机拍摄照片并对其进行评估。 检测到的交通标志被传达到一个显示控制单元，并 进行 可视化。 此信息同时传递给其他控制单元上的其他功能，并进行处理。 所有传感器、执行器和控制单元的连接被称为网络架构，该架构至少需要三年的时间来开发一辆汽车，直到准备好量产。所有传感器、执行器和控制单元之间的正确交互自然会塑造车辆的功能和质量。为了测试正确的交互作用，必须在多个阶段重复和迭代地测试车辆。 最大的挑战是，汽车的部件往往更多地是作为产品而不是作为项目来开发的，因此，来自几个公司和部门的许多人都参与到汽车的创造中来。 总之，这意味着汽车的开发比人们最初想象的要复杂得多。这一方面是由于组织框架条件，另一方面是由于大量的系统组件具有软件内容。复杂性进一步增加，因为可以通过几个系统组件的 交互来 体验功能。 为了弥补这一切，需要对车辆进行许多测试。测试什么，具体地说，在哪个测试级别上，以及如何进行测试 会在后文中提到 。 什么是测试对象或被测试系统? 测试对象、被测系统和测试元素通常是同义词。根据ISTQB，一个测试对象被非常一般地定义为“待测试的工作产品”。因此，测试对象可以是 ： 一个单元 几个软件部分 的集合 ， 一个完整的软件程序， 一个控制单元， 几个控制单元组成的网络， 一整辆车， 任何其他被测试的对象 在下文中，我们将术语“测试对象”和“被测试系统”同义地用于要测试的所有内容。 什么是测试用例? 一个测试用例总是至少包含以下两部分信息: 1 . 定义如何刺激测试对象的测试数据。 2 . 测试对象的期望值，它定义了测试对象在模拟过程中应该假设哪些计算/状态。 而且 可以 选择 用进一步的相关信息来丰富测试用例。测试对象“ECU”的典型前提条件:ECU处于唤醒状态并准备接收消息。 测试数据和期望值是所有测试级别的测试用例和以这种形式执行的测试用例所需要的。期望值是由各种各样的信息来源给出的——也称为测试预言。测试 预言 可以是现有的系统(作为基准)、规范或个人的专业知识。在任何情况下，被测试的代码都不应该作为信息的来源。 什么是动态测试? 动态测试是测试对象的执行。大多数人将测试与动态测试联系在一起。 在动态测试中，创建并执行测试用例，用测试数据刺激测试对象。刺激导致测试对象要么执行计算，要么改变其状态。在动态测试中记录测试对象的反应，并与期望值进行比较。如果反应与期望相等，则认为测试用例已通过。如果不相等，就认为失败了。 与动态测试相对的是静态测试。在静态测试中，测试对象不是模拟的，而是静态分析的。静态测试的一个例子是源代码文件的审查。 什么是测试级别？ A SPICE间接地将测试级别分配给它的过程模型，并 包含 以下五个过程: 1 . 软件单元验证(SWE.4) 2 . 软件集成与集成测试(SWE.5) 3 . 软件 资质 测试(SWE.6) 4 . 系统集成与集成测试(SYS.4) 5 . 系统 资质 测试(SYS.5) 当根据ASPICE进行分配时，应该注意 ： 流程期望更多的活动而不仅仅是动态测试。 但是测试用例实际上是在哪个测试级别上执行的，目的又是什么?我们从最小的层 级 开始:编码。这些是最早可以测试的测试对象。 软件编程之后是与开发相关的单元测试。它们也被称为模块测试、功能测试或单元测试。在单元测试中，测试最小的软件组件，即单元 。 单元经常变化，因此单元测试必须经常调整、补充并再次执行。单元测试有两个主要目标: 早期质量保证 快速检测代码更改中的交叉影响 单元测试通常是软件开发中首先自动化的。 因为软件或软件组件是永久地 调整 和更改的，所以在持续集成方法框架内的一致性是非常有用的，并且已经建立起来了。无论测试级别如何，测试的重复总是被称为回归测试，并且在ASPICE中，软件单元验证是必需的。实现回归测试的最简单方法是自动化测试并在持续集成环境中执行它们。 单元测试之后是软件集成测试。集成是单个软件组件的组装及其测试。这里的重点是软件组件之间的兼容性。集成测试通常分几个阶段进行。根据整个软件的程度，在几个中间阶段到几百个中间阶段之间提供集成测试。中间阶段的数量和选择最终取决于软件体系结构和软件设计 。 元素和级别越多，集成测试的中间阶段就越多。 通常，集成测试是自底向上开发的，首先相互集成和测试几个单元(大约3-5个)。然后，所得到的复合 体 与其他已经测试过的复合 体 或其他单元集成在下一个中间阶段，并再次测试。这个迭代 链一直 持续到ECU的整个软件被构建和测试完毕。 大量的集成测试一开始听起来工作量很大，但它有一个明显的优势，就是可以更快更好地发现错误。在我们的经验中，在集成测试中建立一个额外的中间阶段所需要的工作， 可 在最初建立测试阶段时，通过减少创建测试用例所需的工作来得到补偿。 还有什么是支持集成测试的? 发现的错误可以更容易地缩小到其原因，从而大大简化了分析。 最重要的是: 经验表明，大多数软件错误都是在集成测试中发现的。 对于那些还不相信的人来说，任何持续集成方法都提供了这些测试阶段。 集成测试完成后，软件测试紧随其后，软件测试通常在目标硬件上执行。软件测试中的测试对象与集成测试中的最后一个测试对象相同:它是完全集成的软件。然而，它们各自的目的将两个测试级别彼此区分开来。 1. 集成测试的目的:检查软件组件之间的兼容性。 2 . 软件测试目标:检查软件是否符合要求，例如与传感器和执行器的兼容性， 3 . 信号处理 4 . 软件行为改变参数等方面 软件测试之后是进一步的集成测试。但是，这一次不是在软件级别，而是在系统组件级别。该过程与软件集成测试相同。ECU与一个或多个传感器或执行器一起测试，然后一点 一点 地添加其他组件，直到系统就位。 最后的测试在系统测试中进行。在此过程中，将所有系统组件集成到一个系统中并进行测试。系统测试的重点是确定是否符合系统需求和系统的可交付性。 在汽车开发中，现在有一些额外的组织挑战，例如: 什么是系统? 对于汽车OEM来说，它就是一辆车。但是，提供子系统(如动力系统或软件组件)的供应商如何回答这个问题呢? 在这 种情况下，必须为测试阶段更紧密地指定测试对象。 从合同的角度来看，还有一个进一步的测试阶段: 验收测试，由客户进行。从合同的角度来看，验收是对开发(软件、硬件、系统等)符合合同标准的声明。验收合格后，剩余款项到期，保修开始。 什么是测试环境？ 测试环境就像测试对象及其参与者的训练场。它应该尽可能接近真实的生产环境，以便测试在与其他玩家、状态和信号 交互时 的重要性尽可能高。 在这种情况下，经常会讨论 在环 测试，例如 模型在环（ Model-in-the-loop ， MiL ） 软件在环（ Software-in-the-loop ， SiL ） 处理器在环（ Processor-in-the-loop ， PiL） 硬件在环（ Hardware-in-the-loop ， H iL ） “in- in- loop”之前的术语代表测试对象的类型。“在环”指的是测试对象与模拟生产环境的组件之间的一种特殊类型的交互。在“ 在环测试 ”中，环境对测试对象的状态和计算做出反应。因此，这些测试与开环测试相反，开环测试没有模拟环境的反应。 与开环测试相比，“在环测试”的优点是更接近真实的生产环境。但是，在 环环境 的设置更加复杂。 在汽车环境中，开发通常是基于模型的。大多数模型是用MATLAB/Simulink或 TargetLink 创建的。这些模型通常在开发环境中直接以单元和软件集成测试的形式作为 模型在环 ( MiL )进行验证。 这种类型的动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的仿真是在同样 仿真 的环境模型中执行的。这种非常早期的测试的优点是可以快速检测到模型构建中已经存在的错误，并有可能对其进行修正。 在 软件在环测试（ SiL ） 中，测试代码是在PC上测试的。这要么是手写的，要么是从模型生成的。这两种代码的作用域是不同的。 1 . 测试生成的代码:检查代码生成器是否正常工作。生成的代码的功能应该尽可能接近模型。 2 . 对于手动代码， SiL 是第一个可能的测试级别。与 MiL 一样，目标是在早期阶段发现错误。 SiL 用于测试阶段的单元测试、集成测试，在某些情况下也用于软件测试。硬件在这个阶段还不适用。 在 SiL 中测试的代码不能在嵌入式ECU上执行。为了执行，必须为目标处理器编译代码。在这个过程中生成的代码可以通过两种方式进行测试: 1 . 通过一个评估板与 有 未来目标环境的处理器。 2 . 在PC上模拟处理器的虚拟环境中。 在这两种情况下，都提到了处理器 在环 (PiL)，实际上是指为目标处理器架构构建的软件测试。严格地说，测试阶段因此也可以称为目标软件在环。 处理器在环测试的主要目标是检测编译器错误，或者在软件组件非常接近硬件的情况下，例如驱动程序或执行器的控制，在早期阶段检查硬件和软件组件的兼容性。 下一个逻辑步骤是测试硬件: 也就是说，在带有外围设备的物理ECU上完成软件。现在的重点是输入和输出、通信总线和其他接口如何实时交互。这种 测试 的术语是硬件在环( Hardware-in-the-Loop ， HiL )。 HiL 测试从ECU开始，可以实现到系统网络级别。 HiL 试验台 架 可以 对整车进行测试， 但设置 和操作成本相应较高。尽管如此，他们还是很成熟的，因为进行手动车辆测试也很昂贵，而且更费时 。 在车辆测试中，ecu、执行器和传感器组件在最终目标环境中进行测试。车辆大多在寒冷、温暖和炎热地区的不同环境条件下进行测试。即使在今天，这些测试也主要是手动执行的。在某些情况下，测量结果会被自动记录，然后在工具的帮助下进行评估。这个测试阶段发生在每个OEM。要进行车辆测试，车辆及其所有部件必须可用。然而，由于手动测试需要训练有素的司机和车辆，测试的可扩展性较差。 总结 术语和信息的密集使得一件事很清楚: 背景知识、过程和项目之间的沟通是有效和高效地开发、测试和成功实现嵌入式系统的关键。 在汽车软件测试中，有许多方法和方法，在我们看来，没有对与错，而是有利与不利。当然，这取决于各种参数，涉及的组织，最终取决于一起工作的人。 我们是早期测试的支持者，我们建议直接从单元测试级别开始。进一步说到集成测试，可以测试不同的功能以获得开发的直接反馈。所有这些都导致了快速、合作的产品开发。

软件验证策略是软件单元验证过程中所有活动的基础，因此也是评估的基础。软件验证策略是基础实践 1 所要求的 : 开发 包括回归策略 在内的 软件单元验证策略。 本文是 A SPICE 系列文章的第 2 部分。 通过链接 查看第 1 部分 ： ASPIC E 系列： 顺利通过 ASPICE 流程软件单元验证 (SWE.4) ASPICE系列：顺利通过ASPICE流程软件单元验证(SWE.4)-面包板社区 (eet-china.com) 对于评估人员来说，单元验证策略必须至少包括以下 10 个方面 : 1. 所有单 元 的定义。定义可以是通用的，也可以是特定的。确保 单元 是唯一可识别的。在最简单的情况下， 可以把一列 函数或文件分类为单元。 您应该能够回答以下问题 ： 如何确保所有单元都包含在函数列表中 ？ 这可以通过 比如 定期检查列表或自动更新列表 等方式 来实现。 2. 定义如何涵盖与验证和测试相关的特定需求。这 包含 功能需求、非功能需求和过程需求。 您应该对整个项目的需求有一个概览。补充对单元验证有影响的信息。这些通常也是来自 A SPICE 、 ISO26262 或其他安全标准、 横断面荷载 手册、法律、利益相关方、 MISRA 等的要求。如果您明确地在验证策略中包含各个需求，并简要地记录您的解决方案以供实现，这将是很有帮助的。 3. 定义测试用例的 开发 方法和来自详细设计和非功能需求的测试数据。 这 需要 你 解释为此使用的方法，例如为所有接口形成等价类，正面和负面测试等等。 如果您有通用的单元定义，您可能也会为此使用通用的定义。如果你对质量管理和功能 安全单元有约束 或 变量 （ constraints/variants） ，那么 就会 期望它们也能显示质量管理和功能安全单元的概述。这一期望同样适用于所有其他变体。因此，通用的单元定义 会 增加测试工作 量 。 为了处理这方面的问题，我们建议预先分析所有的需求，并在此分析的基础上推导出最合适的方法。 4. 定义用于静态验证和评审的方法和工具的方法。 5. 定义 每个 测试环境和使用的每个测试方法 论 。 现成的工具实现方法。参考现有的工具供应商文档以节省时间。 使用掌握尽可能多的方法和技术的工具。节省培训和许可证的项目成本。有了一些可以广泛使用的工具，员工可以更快地重新确定优先级，不再需要熟悉工具。 使用已 有 的方法，例如等价类或限制测试来收集测试数据。 使用能最大限度地减轻重复活动工作量的工具，例如自动生成报告和可追溯性。 尽可能实现自动化 6. 根据项目和发布阶段定义测试覆盖范围。 没有人期望你在第一天就达到 100% 的覆盖率。利用项目的持续时间，并显示可实现的建设曲线。 从人员或其他资源方面得出你为此需要什么。 回顾你的策略，如果有偏差就进行调整。根据流程进行变更 ( SUP. 10 变更请求管理 ) 。 7. 定义 动态单元测试的测试启动条件和测试结束标准。 哪些条件导致哪些活动的开始 有相关序列吗 ? 什么时候终止，什么时候重新开始 ? 他们是怎么得到这个的 ? 他们什么时候停止测试 ? 最好不要使用时间，而是使用技术或可度量的标准 ( 覆盖度量，如何测试所有需求 ) 。说明为什么这些指标是充分的。 8. 如果测试级别是组合的，那么 需要 每个测试级别的充分测试覆盖率的文档。 如果您合并测试级别，您必须证明您如何确定覆盖级别。覆盖可以意味着代码覆盖、接口覆盖和需求覆盖。一个一致的基本原理是，例如，您将测试内容移动到更高的级别，因为您可以在这个级别上更有意义地分配测试用例和需求。 他们通常从标准和其他指导方针中获得覆盖率目标。 ISO 26262 为与安全相关的代码部分的代码覆盖率设定了目标。 ISO 26262 含蓄地 要求高覆盖率，并注明 :“ 无正当理由的 没有目标值或低目标值的结构覆盖率被认为是不 充分 的。 ” 一般来说，最好是证实所有覆盖率目标值低于 100% 。这可以通过使用发布计划和预定的需求或特性优先级 更 容易地完成。 专业建议： 从源代码引用或链接相关需求到软件单元验证策略的适当部分。 9. 处理失败的测试用例、失败的静态检查和检查结果的过程。 本程序应与 ASPICE 问题解决管理策略 (SUP.9) 过程相关并保持一致。 你应该描述谁被告知，以及如何和何时做什么。 你还应该描述你将在这个过程中分享什么信息 / 数据。 10. 执行回归测试的定义。 回归测试指的是在对单元进行更改后重新执行静态和动态测试。目标是确定一个单元中未 更改 的部分是否继续工作。 在自动化测试中，回归测试是 一键 完成的。 在持续集成 / 持续测试环境中，表明回归测试是由 “ 每日 构建 ” 或其他自动化保证的就足够了。 关于评估的说明 如果您没有覆盖软件单元验证策略中提到的所有 10 个方面，那么您肯定不会得到 BP1“ 开发软件单元验证策略包括回归策略 ” 的 “ 完全 ” 评估。直到第 4 点才完成第 2 点将导致他们在 BP1 中被评为部分或更 糟 。 隐含地，评估人员还期望参与过程的所有人员都了解软件单元验证策略的内容。如果他们没有证据，例如邮件、日志或类似的形式，可能会 出现 测试人员被召集到评估中，并在面试中确定他们的知识 的情况 。 在 A SPICE 中，更详细地描述了更高级别的工作产品验证策略 (WP ID 19-10) 。 它规定了验证策略 需要安排活动、处理风险和限制、 验证 的独立程度和其他方面 等能力和要求 。

您可能存在的困扰： 目前的测试过程或内容，是否符合ASPICE或ISO 26262 标准？ 如何快速测试，降低成本，实现最大程度的自动化测试？ 如何识别和避免安全漏洞，以及如何快速符合CERT和CWE等安全规范？ 对代码不完全满足MISRA®的编码规范和安全规范以及生成代码的度量报告不达标而苦恼？ 对代码出现的类型的缺陷、运行时错误的检查而感到费时费力？ 嵌入式软件代码测试工具往往需要集成实际目标板，占据硬件资源？ 如何与您现有的需求管理系统（PTC / Door s /Polarion等）集成？ 您在进行C++代码测试时，是否担心工具对C++新特性的支持情况？ 您是否担心测试工具对Windows与Linux平台的支持情况？ 测试工具上又如何实施软件集成测试？ 随着嵌入式软件的关联度越来越高，汽车的功能安全，成为关注的重点，尤其是涉及到人身安全问题，更加引起了大家的注意。从开发和测试角度来说，整体安全方法涵盖整个开发周期，因此需要额外的验证和确认。 在嵌入式软件开发中，大量的缺陷一般是在编码阶段引入的。所以在代码开发后通常就应该进行相应的测试，这也符合“尽早测试的原则”。那如何进行正确、持续和符合标准的测试呢？ 针对以上困扰问题，我们特意为你准备了一份软件代码的静态和动态测试解决方案 Helix QAC（以下简称“QAC”）让您的代码快速符合编码规范，满足代码静态测试要求。 QAC提供丰富的编码规范包：MISRA、AUTOSAR、CERT、CWE、HICPP等，还通过了不同行业的标准认证：ISO 26262、IEC 62304、IEC 60880、DO-178B等。同时它作为嵌入式静态分析领域公认的行业领导和先驱，受到广大供应商和主机厂的青睐！此外它又满足静态代码持续测试，更受追捧！ QAC无缝支持Linux系统，提供Jenkins插件，持续改进对容器的支持，帮助我们快速部署QAC到持续集成平台中。 QAC支持headless模式，提供WEB版项目管理平台——Dashboard，可以将QAC工程的分析结果上传到该平台上，可以通过登录Dashboard，查看工程详细的分析结果、同一个工程不同版本之间的质量变化趋势、不同版本之间代码的变更情况等。 VectorCAST/C++，提供高度自动化的单元测试和集成测试解决方案，满足动态测试的要求。 VectorCAST/C++适用于基于C和C++开发的嵌入式系统软件测试，能够自动生成和编译测试桩和驱动程序，可以在不编写任何测试代码的情况下“一次性”完成测试执行。可以支持业内主流的300余种编译器，通过模块器执行方案替代传统的目标板集成方案，从而减少对硬件资源的占用。具有完整的代码覆盖度分析，支持多种覆盖度指标，能够选择生成各种符合受众需求的测试报告。此外它还提供了基于WEB的软件代码质量和测试完整性度量的仪表盘视图VectorCAST/Analytics，为相关人员实时了解测试进展，明确当前风险提供方便。 Helix QAC & VectorCAST/C++符合ISO 26262标准，符合ASPICE测试要求。您（供应商或主机厂）在正确使用的同时，也在向市场和消费者提供保证，即他们将购买的是一种更安全的产品。当然，使您的团队或企业更具有竞争优势。 北汇信息始终专注于汽车电子领域的新技术和新产品，为整车厂和零部件企业提供完整的研发、测试解决方案，为工程师在汽车领域提供“趁手装备”！同时我们还提供软件代码动态测试服务。 软件单元测试及软件集成测试服务 测试需求分析 基于需求的功能测试 完整的代码覆盖度分析 实现测试用例、测试需求和测试覆盖度之间的双向追溯 代码的回归测试 根据客户需求，提供相应测试报告 及时反馈测试问题并记录 参与测试评审 北汇信息成立于2010年，是一家技术驱动的创新型服务企业。北汇信息始终专注于汽车电子领域的新技术和新产品，为整车厂和零部件企业提供完整的研发、测试解决方案。从测试工具、专用测试设备、完整测试方案到实车测试服务，我们与我们的客户一起努力，让中国的汽车变得越来越安全、越来越舒适、越来越智能。