当前位置: 代码迷 >> 综合 >> AOSP>设计>测试(第一节)概览
  详细解决方案

AOSP>设计>测试(第一节)概览

热度:85   发布时间:2023-11-17 14:48:30.0

AOSP>设计>测试

  • 第一节 概览
    • Android 平台测试
      • 新变化
        • 测试开发工作流
        • 简单的测试配置
        • Atest
      • 测试什么以及如何测试
      • 兼容性测试套件 (CTS)
      • 供应商测试套件 (VTS)
      • Trade Federation 测试基础架构
      • 调试

第一节 概览

Android 平台测试

本内容面向 Android 平台开发者。在了解如何在 Android 平台上进行测试之前,请参阅 Android 平台架构,大致了解相关的信息。

另请注意,您可以使用特定于安全性的测试机制检测设备上的漏洞以及加强设备抵御漏洞的能力。

  • 新变化

  • 测试开发工作流

    测试开发工作流小节现在包含介绍性材料,其中包括所有主要测试类型的端到端示例。

  • 简单的测试配置

    我们在 Android 8.0 (Oreo) 中引入了 Soong 编译系统,该系统可支持 android_test。android_test 即将在 Android 10 中推出,而现在已在 Android 开源项目 (AOSP) master 分支中提供。Soong 基于 Blueprint 的配置比以前的 Make 解决方案简单得多。

  • Atest

    Atest 是一个命令行工具,用户可以使用该工具在本地编译、安装并运行 Android 测试。建议采用此标准对您的功能进行初始测试。

  • 测试什么以及如何测试

    平台测试通常与一个或多个 Android 系统服务或硬件抽象层 (HAL) 交互、执行受测对象的功能,并断言测试结果的正确性。

    因此,平台测试可以:

    1. 通过应用框架执行框架 API;执行的特定 API 可能包括:
      • 用于第三方应用的公共 API
      • 用于特权应用的隐藏 API,也称为系统 API
      • 私有 API(@hide 或受保护,软件包私有)
    2. 直接通过原始 binder/IPC 代理调用 Android 系统服务
    3. 通过低级别 API 或 IPC 接口直接与 HAL 交互
      类型 1 和 2 通常编写为插桩测试,而类型 3 通常使用 gtest 框架编写为原生测试。

    如需了解详情,请参阅我们的端到端示例:

    针对应用的插桩
    自插桩测试
    原生测试
    请熟悉以下工具,因为它们是在 Android 系统中进行测试所固有的工具。

  • 兼容性测试套件 (CTS)

    Android 兼容性测试套件是一个包含各种类型的测试的套件,用于确保 Android 框架实现在 OEM 合作伙伴以及平台版本之间保持兼容性。该套件还包括插桩测试和原生测试(也使用 gtest 框架)

    CTS 与平台测试并不互斥,下面是一些常规准则:

    • 如果测试断言框架 API 函数/行为的正确性,并且应该在 OEM 合作伙伴之间强制执行,那么它应该在 CTS 中
    • 如果测试的意图是在平台开发周期内捕捉回归,并且可能需要特许权限来执行,还可能依赖于实现细节(如 AOSP 中所发布),那么它只能是平台测试
  • 供应商测试套件 (VTS)

    供应商测试套件 (VTS) 会自动执行 HAL 和操作系统内核测试。要使用 VTS 测试 Android 原生系统实现,请设置一个测试环境,然后使用 VTS 方案来测试相应补丁程序。

  • Trade Federation 测试基础架构

    Trade Federation(简称 tradefed 或 TF)是一种连续的测试框架,专门用于在 Android 设备上运行测试。TF 可以在本地、在桌面设备上以及在平台检验处运行功能测试。要在 TF 中运行测试,您必须具备两个文件,一个是 Java 测试源文件,另一个是 XML 配置文件。有关示例,请参阅 RebootTest.java 和 reboot.xml。

  • 调试

    调试部分总结了一些实用的工具和相关的命令,在开发平台级功能时,可使用这些工具和命令来调试、跟踪和分析原生 Android 平台代码。