本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：谷歌的gtest是一个被广泛采纳的开源单元测试框架，主要为C++编写。它通过断言来验证代码的预期行为，支持创建可重用的测试用例和套件，并能够处理参数化测试。gtest与测试驱动开发（TDD）模式相结合，提高代码质量和促进编程实践。本实战指南将引导你理解gtest的基本概念、核心组件，以及如何编译gtest并将其集成到项目中。
google test 单元测试框架

1. gtest单元测试框架介绍

本章将引导读者进入gtest这一强大的C++单元测试框架的世界。gtest是Google开发的一个开源库，用于编写和运行测试用例，通过它开发者可以以简单而直接的方式对代码进行单元测试。本章将概述gtest的起源、主要特点以及为什么它在软件质量保证中占据了重要地位。

gtest通过提供丰富的断言宏、测试夹具（Test Fixtures）、测试套件和参数化测试功能，使得测试过程既灵活又强大。此外，gtest与持续集成（Continuous Integration）系统的兼容性，以及对各种编译器和平台的支持，都让其成为业界的首选测试框架之一。

在后续章节中，我们将深入探讨gtest的高级特性，并提供实践案例以展示如何在日常的软件开发中有效地使用gtest进行单元测试。为了确保读者能够顺利跟随我们的教程，建议读者具备一定的C++语言基础和单元测试的基础知识。接下来，我们将从gtest的核心概念开始，逐步深入了解其工作原理和使用方法。

2. 单元测试基本概念

2.1 单元测试的目的与意义

单元测试是一道防线，它保护代码库免受未来更改带来的破坏。通过编写和执行单元测试，开发者能够验证软件代码的特定部分（即单元）是否按照预定的方式运行。

2.1.1 提高代码质量与稳定性

单元测试能够以最小的成本发现和修复代码中的缺陷，从而提高整体软件产品的质量和稳定性。通过频繁的执行单元测试，可以快速定位到代码中的问题，这些测试通常在代码修改后立即执行，因此能够有效地防止缺陷的扩散。 

TEST(sum, should_return_correct_sum) {
    EXPECT_EQ(2, sum(1, 1));
    EXPECT_EQ(4, sum(2, 2));
}

在上述测试用例中，我们通过 TEST 宏定义了一个名为 should_return_correct_sum 的测试函数，它将验证 sum 函数的正确性。通过 EXPECT_EQ 断言，我们检查了 sum 函数对于相同输入和不同输入的计算结果是否符合预期。

2.1.2 促进软件开发流程的优化

单元测试鼓励开发者设计出更容易测试的代码，这通常意味着更高的模块化和更低的耦合度。此外，单元测试可作为文档使用，帮助新开发者理解代码的预期行为。它也是持续集成和持续交付流程的关键组成部分，确保每次代码提交后软件质量保持在可接受的水平。

2.2 单元测试的生命周期

单元测试的生命周期描述了从测试计划到测试结果评估与维护的一系列步骤。

2.2.1 测试计划

测试计划是单元测试生命周期的第一步，它决定了哪些功能或方法需要被测试，并为每个测试确定了优先级。测试计划应当包括测试的目标、范围和资源分配等关键信息。 

flowchart LR
A[开始] --> B[定义测试目标]
B --> C[确定测试范围]
C --> D[分配资源]
D --> E[制定时间表]
E --> F[结束]
2.2.2 测试设计

测试设计阶段主要关注于如何实现测试计划，包括用例的创建和测试数据的准备。设计阶段的输出是一系列明确的测试用例，它们为每个目标提供了清晰的预期结果。

2.2.3 测试执行

执行阶段是单元测试生命周期中实际运行测试用例的步骤。使用自动化测试框架可以极大地提高效率并减少人为错误。执行结果通常分为三种：通过、失败和阻塞。

2.2.4 测试结果评估与维护

测试结果评估阶段负责分析测试结果，确定测试是否通过，并识别失败的原因。如果测试失败，需要修改代码并重新运行测试，直到测试通过。在软件的整个生命周期中，测试用例需要持续地被评估和维护，以确保它们仍然有效，并且能够覆盖代码库的变化。

通过本章节的介绍，我们了解了单元测试的重要性和它在软件开发中的作用。下一章节，我们将深入讨论测试用例的设计原则与组织方法。

3. 测试用例（Test Cases）

在软件测试的宏伟画卷中，测试用例是不可或缺的色彩。它们是编写单元测试不可或缺的组成部分，是构建自动化测试的基础。一个精心设计的测试用例不仅能够验证特定的功能或行为，还能驱动软件开发的整个流程。本章节将深入探讨测试用例的设计原则、结构、数据准备和分类管理，帮助读者构建出更加高效、可维护的测试用例库。

3.1 测试用例设计原则

在设计测试用例时，原则是我们的灯塔，它们指引我们在测试的海洋中导航，确保不会迷失方向。首先，我们要确保测试用例的独立性和可重复性，这两者是测试用例设计的灵魂。

3.1.1 测试用例的独立性

独立性意味着每个测试用例都不依赖于其他测试用例的状态或执行结果。这种特性使得测试用例可以独立执行，提高了测试的灵活性和可维护性。在实践中，确保测试用例独立性通常涉及到以下几个方面：

  • 数据准备：每个测试用例都应使用独立的输入数据，避免因为数据的共享而导致测试结果的相互影响。
  • 测试环境：每个测试用例的执行应保证在一个干净、一致的环境中进行，不受其他测试用例的干扰。
  • 依赖隔离：通过模拟、存根（Stubs）和模拟对象（Mock Objects）等技术，隔离被测试对象对外部依赖的调用。 
TEST(ExampleTest, IndependentTest) {
    // 使用独立的数据进行测试
    int input = 10;
    int expected_output = 20;
    EXPECT_EQ(expected_output, FunctionToTest(input));
}

3.1.2 测试用例的可重复性

可重复性是指在相同条件下，测试用例的执行能够得到一致的结果。这对于测试用例的可靠性和维护性至关重要。要实现测试用例的可重复性，需要注意以下几点：

  • 环境一致性：确保每次执行测试用例时，运行环境是相同的。
  • 测试初始化和清理：在测试前后进行适当的初始化和清理操作，保证测试环境的状态不发生意外变化。 
TEST(ExampleTest, RepeatableTest) {
    // 初始化测试环境
    Setup();

    // 执行测试
    ASSERT_TRUE(Test());

    // 清理测试环境
    Teardown();
}

3.2 测试用例的编写与组织

3.2.1 测试用例结构

测试用例结构是测试用例的骨架，通常由测试步骤、输入数据、预期结果和实际结果组成。一个清晰的测试用例结构有助于测试人员快速理解测试的意图，并准确地执行测试。 

| 测试用例ID | 测试步骤 | 输入数据 | 预期结果 | 实际结果 | 测试状态 |
|-------------|----------|----------|----------|----------|----------|
| TC001       | 步骤1    | 数据1    | 结果1    | 结果2    | 通过/失败 |

3.2.2 测试数据的准备

测试数据对于测试用例的执行至关重要。测试数据可以是硬编码的，也可以从数据池中抽取，或者使用数据驱动测试的方法来动态生成。准备测试数据时，应考虑数据的多样性、有效性和边界条件。

3.2.3 测试用例的分类与管理

测试用例的分类和管理是提高测试效率和覆盖度的关键。通过将测试用例进行分类，例如按功能模块、按测试类型（如功能测试、边界测试、异常测试等）分类，可以方便管理和维护测试用例。测试用例管理工具或框架，如TestLink、TestRail等，能够协助我们更好地组织和跟踪测试用例的执行情况。 

graph TD
    A[测试用例管理] --> B[按模块分类]
    A --> C[按测试类型分类]
    A --> D[使用测试管理工具]

通过本章节的介绍，我们可以看出测试用例设计不仅需要有严格的原则来保证测试的有效性，还需要良好的结构和组织方法来保证测试的效率。在下一章节中，我们将继续深入探讨断言的原理与技巧，这是确保测试用例有效执行的核心元素。

4. 断言（Assertions）

4.1 断言的作用与分类

4.1.1 基本断言

在软件开发中，断言（Assertion）是用于测试软件内部的假设是否成立的语句。在gtest中，断言用于验证程序的行为是否符合预期。基本断言是指那些验证单个条件的断言，例如 AssertTrue 、 AssertFalse 、 AssertEq 、 AssertNe 等。这些断言在条件为假时会终止程序执行，并显示失败原因。

例如，在测试一个函数 Add 是否正确计算两个数的和时，可以使用如下断言： 

TEST(AddTest, HandlesZeroInput) {
    int sum = Add(0, 0);
    ASSERT_EQ(0, sum);
}

TEST(AddTest, HandlesPositiveInput) {
    int sum = Add(3, 5);
    ASSERT_EQ(8, sum);
}

在这两个测试用例中， ASSERT_EQ 断言用于验证 Add 函数返回的结果是否等于期望的值。如果 Add 函数的实现在这两个测试用例中不满足预期，则测试将会失败，并且会报告错误，指示出错的位置和原因。

4.1.2 复合断言

复合断言涉及到多个条件或断言的组合，以更复杂的方式验证程序状态。gtest提供了一系列复合断言，例如 AssertThat ，配合Hamcrest库进行更复杂的数据验证。复合断言通常用于处理更复杂的测试逻辑，比如验证一个对象集合。

举个例子，假设我们需要验证一个字符串列表是否包含特定的元素，可以这样编写测试代码： 

#include <gtest/gtest.h>
#include <vector>
#include <gmock/gmock.h>

TEST(StringListTest, ContainsElement) {
    std::vector<std::string> list = {"apple", "banana", "cherry"};
    auto matcher = testing::ElementsAre("banana", "cherry");
    EXPECT_TRUE(testing::IsSubstringOfElement(matcher, list));
}

在这个例子中， testing::ElementsAre 创建了一个预期的元素集合， testing::IsSubstringOfElement 复合断言则检查实际列表中是否包含这些元素。

4.2 断言的使用技巧

4.2.1 断言的最佳实践

正确使用断言对于编写高质量的单元测试至关重要。断言的最佳实践包括：

  • 明确预期行为 ：在编写测试用例时，始终清楚每个断言所验证的预期行为。
  • 适当使用断言类型 ：根据测试需要选择合适的断言类型，比如 ASSERT_* 在失败时会停止执行后续代码，而 EXPECT_* 则不会。
  • 避免模糊的断言 ：确保断言中不包含过于模糊或不明确的预期条件。
  • 重构断言 ：保持断言的简洁性，如果断言变得复杂，考虑将它们分解成多个更小的断言。

4.2.2 避免常见的断言错误

在使用断言时，开发者常犯的一些错误包括：

  • 滥用断言 ：将断言用作错误处理机制，例如用断言来检查输入参数的有效性，这是不恰当的。应使用异常处理来处理这类错误。
  • 过度依赖断言 ：有些场景下，开发者可能会过分依赖断言来检查程序状态，这可能会隐藏程序逻辑中的问题。应通过合适的程序设计来避免需要过度使用断言的场景。

正确地使用断言能够极大提升测试用例的可读性和可维护性，同时能够有效指导开发者关注代码中的关键假设和验证点。

5. 测试套件（Test Suites）

5.1 测试套件的概念与优势

5.1.1 组织测试用例

测试套件是组织和运行多个测试用例的一种方法。在大型项目中，单个测试用例可能会迅速增长到成百上千个，这时就需要一种方式来有效管理这些测试用例，以保证测试的可维护性和可扩展性。测试套件提供了一种结构化的方法，允许开发者将相关的测试用例分组，创建一个测试套件就像创建一个测试用例集合，通过这个集合可以一次性运行一组特定的测试用例。

使用测试套件有以下几个优点：

  • 代码重用 ：测试套件允许测试用例复用，避免了代码冗余。
  • 组织有序 ：复杂项目中的测试用例通过分组，使得测试的组织结构更加清晰。
  • 提高效率 ：可以快速选择并运行一组特定的测试用例，提升开发和调试效率。
  • 集中控制 ：测试用例的执行、统计和结果报告变得更加集中和方便管理。

5.1.2 提高测试效率

测试套件的另一个显著优势是提升测试的效率。在传统的测试执行中，测试人员或开发者需要手动地逐个运行测试用例，这在包含大量测试用例的项目中效率十分低下。通过构建和使用测试套件，可以简化测试的执行过程，测试人员只需要执行一个测试套件，就可以运行该套件中所有的测试用例。

此外，测试套件可以在持续集成（Continuous Integration，CI）系统中配置为定期自动运行，这不仅提高了测试的频率，也有助于快速发现并修复因代码更改引发的问题。自动化测试套件的执行，有助于保持高质量的代码标准，并减少人工干预的需求。

5.2 构建测试套件的方法

5.2.1 使用gtest的测试套件功能

Google Test 提供了非常方便的测试套件功能。利用gtest的测试套件功能，开发者可以创建一个测试套件，然后将多个测试用例添加到该套件中。使用gtest的 TEST套件 宏可以创建测试套件，然后使用 TEST_F 宏来定义具体的测试用例。

下面是一个基本的gtest测试套件的示例： 

#include <gtest/gtest.h>

// 定义测试套件
TEST(SuiteName, Case1) {
    // 测试用例代码
}

TEST(SuiteName, Case2) {
    // 测试用例代码
}

// 将测试用例添加到测试套件中
int main(int argc, char **argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

在这个例子中，我们定义了一个名为 SuiteName 的测试套件，其中包含了两个测试用例 Case1 和 Case2 。通过调用 RUN_ALL_TESTS() 宏，gtest会自动执行测试套件内的所有测试用例。

5.2.2 测试套件的维护与更新

随着项目的发展和测试需求的变化，测试套件可能需要定期的维护和更新。这包括添加新的测试用例到套件中、删除不再需要的测试用例，或者修改现有的测试用例来适应新的测试需求。

在维护测试套件时，有一些最佳实践需要遵循：

  • 保持一致性 ：确保测试套件中的测试用例都遵循相同的命名规则和格式，以便于理解和维护。
  • 细粒度控制 ：如果测试套件太大，考虑将其拆分成更细小的套件，以提供更精细的控制。
  • 文档化 ：更新测试套件时，保持文档的同步更新，以反映测试套件的最新结构和用途。
  • 自动化回归测试 ：新开发的测试用例应该自动集成到测试套件中，并在每次构建中运行，确保项目的长期稳定性。

5.3 测试套件的深入应用

5.3.1 测试套件间的依赖管理

随着测试套件数量的增加，测试套件间的依赖关系可能会变得复杂。管理这些依赖关系，保证测试的顺序性和独立性是非常重要的。在gtest中，虽然它不会强制执行特定的测试顺序，但最佳实践是确保测试用例的独立性，避免测试用例间的相互影响。

在测试套件间，可以通过控制测试用例的执行顺序来模拟依赖关系，而不会直接影响测试的独立性。例如，一些测试用例可能依赖于数据库或外部服务的初始状态，我们可以在这些测试用例执行前，使用测试套件来设置环境。

5.3.2 测试套件的优化策略

测试套件的执行效率和可维护性是需要持续优化的。为了提升测试套件的性能，可以采取以下策略：

  • 并行测试 ：利用多核处理器并行运行测试用例，以减少测试执行的总体时间。
  • 内存使用监控 ：测试套件的执行可能会消耗大量的内存资源，通过监控工具来确保内存使用在合理范围内。
  • 测试结果缓存 ：对于不经常变化的测试用例，可以使用缓存机制来避免重复执行，从而节省时间。

这些策略能够帮助测试团队更高效地执行测试，确保项目按时交付且质量达标。

5.4 测试套件的案例分析

5.4.1 成功案例

在大型软件项目中，测试套件的成功应用案例数不胜数。例如，许多公司使用测试套件来自动化测试他们的API接口。测试套件可以组织所有的API测试用例，并定期运行以确保接口的稳定性和可靠性。

例如，一个基于Web服务的公司，可能会有以下结构的测试套件：

  • 用户认证套件：包含登录、登出、注册等用例。
  • 购物车套件：包含添加商品、删除商品、计算总价等用例。
  • 订单处理套件：包含创建订单、支付订单、取消订单等用例。

通过这些结构化的测试套件，可以确保不同团队在开发新功能时，不会无意间破坏现有功能。

5.4.2 失败案例及教训

然而，并非所有的测试套件应用都是成功的。有时由于设计不当，测试套件可能会变得庞大而难以管理。一个失败的案例是，一个测试套件因为包含了太多不同类型的测试用例而变得十分笨重。这个套件包括了单元测试、集成测试甚至是端到端测试，这种混合类型的测试套件导致了混乱，并且每次测试的持续时间变得很长。

这个失败案例给我们的教训是，测试套件需要保持清晰的界限和专注的目标。对于复杂项目的不同测试层次，应该分别建立不同的测试套件，以保持测试的清晰性和专注性。

6. 参数化测试

6.1 参数化测试的原理与应用

6.1.1 参数化测试的定义

参数化测试是一种允许你用不同的参数多次运行相同测试用例的技术。这种测试方式非常有用，特别是当你需要测试一个函数在不同输入下的一致性行为时。通过参数化测试，你可以避免编写多个几乎相同的测试用例，这样不仅减少了代码的重复，还提高了代码的可维护性。

在gtest框架中，参数化测试是通过宏定义TEST_P和使用Google Test的Parameterized库来实现的。TEST_P允许你为测试用例指定一个参数列表，然后测试框架会自动为每个参数组合运行一次测试。

6.1.2 参数化测试的适用场景

参数化测试特别适用于以下场景：

  • 测试函数对不同输入的响应。
  • 验证函数对各种边界条件的处理。
  • 确保代码能够正确处理各种可能的异常输入。

使用参数化测试可以使测试过程更加简洁高效，因为你只需要编写一次测试逻辑，就可以覆盖多种测试场景。这样不仅提高了测试的覆盖率，还增强了测试用例的健壮性。

6.2 参数化测试的实现技术

6.2.1 使用gtest的参数化测试框架

gtest框架提供了一套参数化测试机制，允许开发者使用TEST_P宏来定义参数化测试用例。使用TEST_P进行参数化测试涉及以下几个步骤：

  1. 定义测试用例的参数类型。
  2. 创建一个工厂类继承自 ::testing::TestWithParam<T> ，其中T是你的参数类型。
  3. 使用 TEST_P 宏定义测试用例，它接受一个参数，这个参数是由参数工厂类产生的。
  4. 编写测试逻辑，它将会使用 GetParam() 方法获取当前测试用例的参数。
  5. 注册参数化测试，使用 REGISTER_TEST_CASE 宏或者在 main() 函数中调用 InitGoogleTest() 之后再调用 Test::AddTestCaseseries() 。

下面是一个简单的参数化测试示例： 

#include <gtest/gtest-param-test.h>
#include <gtest/gtest.h>

using namespace testing;

class FibonacciTest : public TestWithParam<int> {
};

TEST_P(FibonacciTest, HandleZero) {
    EXPECT_EQ(0, GetParam());
}

TEST_P(FibonacciTest, HandlePositive) {
    EXPECT_GT(GetParam(), 0);
}

INSTANTIATE_TEST_CASE_P(InstantiationName,
                        FibonacciTest,
                        Values(0, 1, 5, 10, 20));

在这个例子中，我们创建了一个名为 FibonacciTest 的测试用例类，它有两个测试用例： HandleZero 和 HandlePositive 。 INSTANTIATE_TEST_CASE_P 宏用来为测试用例实例化具体的参数值。

6.2.2 参数化测试案例分析

为了深入理解参数化测试的实际应用，考虑一个测试函数 Add ，它将两个整数相加并返回结果。我们想要确保该函数对于各种输入组合都能正确返回预期结果，包括正数、负数、边界值等。

首先，我们定义一个类型别名和一个测试用例类： 

using Integers = std::pair<int, int>;

class AddTest : public TestWithParam<Integers> {
};

然后，我们定义测试用例： 

TEST_P(AddTest, AddTwoNumbers) {
    auto params = GetParam();
    EXPECT_EQ(params.first + params.second, Add(params.first, params.second));
}

这里， Add 函数是我们要测试的函数， AddTest 类的每个实例会自动调用 GetParam() 来获取参数，并执行测试逻辑。现在我们需要定义参数列表，可以使用 ValuesIn 宏： 

INSTANTIATE_TEST_CASE_P(AddTestSuite,
                        AddTest,
                        ValuesIn(std::vector<Integers>{
                            {0, 0}, {1, 2}, {-1, 1}, {INT_MAX, 1}, {INT_MIN, 1}
                        }));

通过这种方式，我们的 AddTest 用例将依次使用不同的参数组合进行测试。如果 Add 函数正确实现了加法，所有的测试都应该通过。

这样，参数化测试帮助我们实现了对函数行为的全面测试，确保了我们的代码能够在各种情况下正常工作。

请注意，本章节的示例代码仅供参考，实际应用时需要根据具体情况调整。

7. 测试驱动开发（TDD）

7.1 TDD的核心理念与工作流程

7.1.1 TDD的定义与好处

测试驱动开发（Test-Driven Development，TDD）是一种软件开发方法论，其核心在于先编写测试用例，后编写满足这些测试用例的代码。TDD 的目的是快速迭代，确保每一小块代码的正确性，并且使得软件能够更容易地适应需求变化。

TDD 的好处显而易见：
- 提高代码质量 ：因为始终在考虑如何编写满足测试的代码，开发者会更注重代码的可测试性和模块化。
- 减少缺陷 ：通过早期测试，缺陷在开发过程中被发现和修复，从而减少了后期发现严重缺陷的风险。
- 设计的简化和改进 ：TDD 鼓励简单的设计和重构，从而逐步形成更灵活、可维护的代码结构。

7.1.2 TDD的循环过程

TDD 的循环过程通常被称为“红-绿-重构”：
1. 编写一个失败的测试用例（红） ：首先编写一个测试用例，然后运行测试。因为还没有实现功能，所以这个测试会失败。
2. 编写满足测试的最简代码（绿） ：实现代码以满足测试用例，此时关注的是功能的正确实现，而不是代码的优化或重构。
3. 重构代码以提高质量 ：一旦测试通过，就可以对代码进行重构，改善其设计和可读性，同时保证测试用例仍然通过。

7.2 TDD与gtest的结合实践

7.2.1 TDD在gtest中的应用

在 TDD 开发实践中，gtest 作为测试框架，扮演了至关重要的角色。通过使用 gtest，开发者能够轻松地创建测试用例并进行自动化测试。

具体实践中，开发者需要：
- 设计测试用例，这通常与设计代码的函数或方法相对应。
- 在编写具体功能代码之前，使用 gtest 创建测试用例，并看到测试失败（红）。
- 编写最简代码通过测试（绿），此时代码实现了最基础的功能。
- 重构实现代码，使用 gtest 持续验证功能的正确性。
- 重复上述步骤，直到功能完备。

7.2.2 TDD案例与代码演示

下面通过一个简单的例子来演示 TDD 的过程，使用 C++ 和 gtest。

假设我们要实现一个加法函数 add ，其工作流程如下：

  1. 编写失败的测试用例 ： 
#include <gtest/gtest.h>

int add(int a, int b) {
    return a + b; // 这是一个简单的实现，为了演示 TDD 流程
}

TEST(AddFunctionTest, HandlesZeroInput) {
    EXPECT_EQ(add(0, 0), 0);
}

int main(int argc, char **argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

  1. 编写满足测试的最简代码 ：
    在上述测试不通过时，我们修改 add 函数，使其通过测试。

  2. 重构代码 ：
    一旦测试通过，可以考虑是否有更优雅的实现方式，例如重载函数来处理更多类型的输入。

  3. 运行测试 ： 

$ g++ -std=c++11 -pthread -o add_test add_test.cpp -lgtest -lgtest_main
$ ./add_test

以上代码中，我们使用 gtest 的 TEST 宏定义了测试用例，并在主函数中调用 RUN_ALL_TESTS() 来执行所有的测试。这个例子展示了 TDD 的快速迭代过程，开发者可以在实际开发中运用这一流程，提升代码质量。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：谷歌的gtest是一个被广泛采纳的开源单元测试框架，主要为C++编写。它通过断言来验证代码的预期行为，支持创建可重用的测试用例和套件，并能够处理参数化测试。gtest与测试驱动开发（TDD）模式相结合，提高代码质量和促进编程实践。本实战指南将引导你理解gtest的基本概念、核心组件，以及如何编译gtest并将其集成到项目中。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
乐奇 Rokid 开放社区

更多推荐

cover

AR巡检哪家好，和浪潮比哪家方案更成熟

avatar 乐奇 Rokid 开放社区
cover

国庆文旅安保上新！AR智能眼镜守护景区，黑科技护航假期出游

avatar 乐奇 Rokid 开放社区
cover

2027中国深圳智能穿戴产业链展览会

avatar 乐奇 Rokid 开放社区