Android Compatibility Test Suite(CTS)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011391629/article/details/82963664

Overview

How does the CTS work?

CTS(Compatibility Test Suite)兼容性测试套件,是一个免费的商业级测试套件,CTS 代表兼容性的“机制”。

CTS 在桌面设备上运行,并直接在连接的设备或模拟器上执行测试用例。CTS 是一套单元测试,旨在集成到工程师构建设备的日常工作流程(例如通过连续构建系统)中。其目的是尽早发现不兼容性,并确保软件在整个开发过程中保持兼容性。

CTS 是一个自动化测试工具,其中包括两个主要软件组件:

  • CTS tradefed 自动化测试框架会在桌面设备上运行,并管理测试执行情况。
  • 单独的测试用例会在被测设备 (DUT) 上执行。测试用例采用 Java 语言编写为 JUnit 测试,并打包为 Android .apk 文件,以在实际目标设备上运行。

兼容性测试套件验证程序(CTS 验证程序)是对 CTS的补充。CTS 验证程序为无法在没有手动输入(例如音频质量、加速度计等)的固定设备上进行测试的 API 和功能提供测试。

CTS 验证程序是一款手动测试工具,包含以下软件组件:

  • 在 DUT 上执行并收集结果的 CTS 验证程序应用。
  • 在桌面设备上执行,以便为 CTS 验证程序应用中的某些测试用例提供数据或额外控制的可执行文件或脚本。

Workflow

PC端和Device端(手机、平板等等)通过adb通信,PC发command到Device,run test case;然后Device执行完会把测试结果返回给PC
在这里插入图片描述

Types of test cases

CTS 包含以下类型的测试用例:

  • 单元测试会测试 Android 平台中很微小的代码元素;例如 java.util.HashMap 等单个类。
  • 功能测试会通过较高级别的用例将 API 组合到一起进行测试。

CTS 的未来版本将包含以下类型的测试用例:

  • 稳健性测试会测试系统在压力下的耐久性。
  • 性能测试会根据定义的基准测试系统的性能(例如每秒渲染帧数)。

Areas covered

Area Description
Signature tests 每个 Android 版本中都包含一个 XML 文件,用于描述这一版本所含的所有公开 API 的签名。CTS 包含一个实用工具,用于根据设备上可用的 API 检查这些 API 签名。签名检查的结果会记录在测试结果 XML 文件中。
Platform API Tests 按照 SDK 类索引所述内容来测试平台(核心库和 Android 应用框架)的 API,以确保 API 的正确性,包括正确的类、属性、方法签名以及正确的方法行为;此外还需进行负面测试,以确保不正确的参数处理产生预期行为。
Dalvik Tests 这类测试侧重于测试 Dalvik 可执行格式的文件。
Platform Data Mode CTS 会测试通过内容提供程序提供给应用开发者的核心平台数据模型:通讯录、浏览器、设置等。
Platform Intents CTS 会测试核心平台 Intent。
Platform Permissions CTS 会测试核心平台权限
Platform Resources CTS 会测试核心平台资源类型的处理是否正确。这包括对以下资源的测试:简单值、可绘制资源、九宫格、动画、布局、样式和主题背景,以及加载备用资源。

Setting up CTS

Desktop Machine

在run cts之前需要搭建cts测试环境,需要安装以下工具,这三个工具可以到Android官网上下载。

  • Java Development Kit - JDK
  • Android Debug Bridge - ADB
  • Android Asset Packaging Tool - AAPT

装好了用以下命令检查一下

java -version
adb version
aapt version

CTS files

然后下载CTS测试包

Android device configuration

需要对设备做一些设置,这个应该要看具体的testcase和设备

Running CTS tests

其实我现在最常用的就是 run cts -m [module] -t [testcase_name]

Run Description
run cts full run
run retry For Android 9. Retry all tests that failed or were not executed from the previous sessions.
–plan <test_plan_name> Run the specified test plan.
run cts -m [module] -t [testcase_name] Run the specified test module or modules. For example: run cts -m Gesture -t android.gesture.cts.GestureTest#testGetStrokes
–subplan <subplan_name> Run the specified subplan.
–shard-count <number_of_shards> For Android 9. Shard a CTS run into given number of independent chunks, to run on multiple devices in parallel.
–serial/-s Run CTS on the specific device.
–include-filter <module_name> [–include-filter …] Run only with the specified modules.
–exclude-filter <module_name> [–exclude-filter …] Exclude the specified modules from the run.
–log-level-display/-l <log_level> Run with the minimum specified log level displayed to STDOUT. Valid values: [VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT].
–abi <abi_name> Force the test to run on the given ABI, 32 or 64. By default CTS runs a test once for each ABI the device supports.
–logcat, --bugreport, and --screenshoot-on-failure Give more visibility into failures and can help with diagnostics.
–device-token Specifies a given device has the given token eg. --device-token 1a2b3c4d:sim-card…
–skip-device-info Skips collection of information about the device. Note: do not use this option when running CTS for approval.
–skip-preconditions Bypasses verification and setup of the device’s configuration, such as pushing media files or checking for Wi-Fi connection.

在这里插入图片描述

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/u011391629/article/details/82963664