1. 项目概述：为什么我们需要告别手动CTS/GTS测试

如果你是一名Android系统开发工程师、测试工程师，或者正在从事ROM定制和系统集成工作，那么对CTS（Compatibility Test Suite，兼容性测试套件）和GTS（Google Mobile Services Test Suite，Google移动服务测试套件）这两个词一定不会陌生。它们就像是Android设备进入主流市场的“准生证”和“身份证”。CTS确保你的设备符合Android开源项目（AOSP）的兼容性标准，而GTS则验证设备对Google移动服务（GMS）的集成是否合规。没有通过这两项认证，你的设备几乎不可能预装Google Play商店等核心应用，在海外市场寸步难行。

然而，手动执行CTS/GTS测试，绝对是一场对耐心和体力的终极考验。标准的流程通常是这样的：从Google官方下载数GB的测试包，通过命令行工具 tradefed 启动测试，然后盯着终端里一行行滚动的日志，祈祷不要出现红色的 FAIL 。一个完整的CTS验证周期（VTS/CTS/GTS）可能包含数万个测试用例，运行时间长达数十小时。这期间，你需要手动处理设备掉线、测试卡住、环境异常等问题，整个过程枯燥、重复且极易出错。更痛苦的是，当开发迭代频繁时，你需要在每个版本构建后都重复这套流程，以确保兼容性没有被破坏。

这正是我决定用Python脚本将这套流程彻底自动化的原因。这个项目的核心目标，不是简单地封装几个 adb 命令，而是构建一个 健壮、可监控、可报告 的自动化测试流水线。它能自动处理从环境准备、测试执行、到结果收集、异常恢复的全过程，将工程师从重复劳动中解放出来，专注于更有价值的兼容性问题分析和修复。接下来，我将详细拆解这个自动化系统的设计思路、核心实现以及我踩过的那些坑。

2. 自动化框架的整体设计与核心思路

设计一个自动化测试框架，尤其是针对CTS/GTS这种复杂且耗时的场景，绝不能是“脚踩西瓜皮，滑到哪里算哪里”。我的核心设计原则是： 模块化、可配置、强容错 。整个框架被划分为几个松耦合的模块，每个模块负责一个明确的职责，通过配置文件驱动行为。

2.1 系统架构与模块划分

整个自动化脚本的架构可以看作一个微型的CI/CD流水线，主要包括以下五个核心模块：

1. 环境配置与检查模块 ：这是所有测试的基石。它负责检查宿主机（运行脚本的电脑）的Python环境、ADB版本、Java版本，以及确认被测设备（DUT）是否已连接、是否处于可用状态（如已解锁、开启USB调试）。它还会根据配置，自动向设备推送必要的测试资源文件。
2. 测试计划管理与执行模块 ：这是大脑。它解析用户定义的测试计划（例如，“只运行CTS中的 CtsMediaTestCases ”），与 tradefed 控制台进行交互。其核心职责是启动测试会话、监控测试状态、捕获实时日志，并将标准输出和错误流进行分离处理，以便后续分析。
3. 异常监控与恢复模块 ：这是安全网。CTS/GTS测试动辄运行几十个小时，设备死机、进程无响应、网络闪断等情况时有发生。这个模块会周期性检查设备连接状态和测试进程心跳。一旦检测到超时或异常，它会尝试一系列恢复操作，如重启 adb 服务、重新连接设备、甚至重启整个测试计划，而不是让脚本直接崩溃。
4. 结果解析与报告生成模块 ：这是价值提炼器。原始的测试结果是一堆XML和日志文件。此模块会解析这些文件，提取关键信息：通过率、失败用例列表、失败原因摘要、测试耗时等，并生成结构化的报告（如HTML、JSON或Markdown格式），让人一眼就能看清整体状态和问题所在。
5. 日志聚合与归档模块 ：这是黑匣子。它将整个测试生命周期中所有重要的日志——包括脚本自身的运行日志、 tradefed 的控制台输出、 adb logcat 设备日志——按时间线和模块进行分类存储和压缩归档。当出现难以复现的诡异问题时，这些完整的日志就是排查问题的唯一依据。

这种模块化设计的好处是显而易见的：每个模块可以独立开发和调试；你可以轻松替换某个模块的实现（比如将报告从HTML换成PDF）；更重要的是，它极大地增强了系统的可维护性和可扩展性。

2.2 关键技术选型与考量

为什么选择Python？这是最自然的选择。Python在自动化运维、脚本编写和跨平台支持方面有着无可比拟的优势。丰富的第三方库（如 subprocess 用于调用命令行、 xml.etree.ElementTree 用于解析结果、 logging 用于记录、 paramiko 如需远程执行）能让我们快速搭建原型。其简洁的语法也降低了后续维护和团队协作的成本。

在与 tradefed 交互的方式上，我放弃了某些方案中采用的直接解析其Java源码或使用复杂RPC的方式，而是选择了最直接、最稳定的 标准输入/输出流控制 。即，通过Python的 subprocess.Popen 启动 tradefed 控制台，并将其标准输入、输出和错误流全部接管过来。这样，我就可以像真正的用户一样，向控制台发送命令（如 run cts --plan CTS ），并实时读取它的反馈。这种方式虽然看起来“笨”，但它与 tradefed 的官方使用方式完全一致，避免了因 tradefed 内部接口变动而导致脚本失效的风险，稳定性最高。

注意 ：直接操作流需要对 tradefed 的输出格式有深入了解。它的输出并非纯文本，而是混合了控制字符（用于刷新行、改变颜色等）的ANSI转义序列。在解析时，需要使用 re 模块进行正则匹配，并过滤掉这些控制字符，才能提取出“测试用例XYZ：PASS/FAIL”这样的纯净信息。

3. 核心模块的代码级拆解与实现

有了顶层设计，我们深入到几个最关键模块的内部，看看代码具体是如何实现的。这里我会附上核心代码片段，并解释每一行背后的意图。

3.1 环境检查器：打造坚如磐石的测试地基

环境检查是自动化脚本的“开机自检”。一个常见的陷阱是，脚本运行到一半才发现 adb 版本太旧或者设备存储空间不足。因此，我们的检查器必须“冷酷无情”，在开始任何实质性工作前，排除所有已知的环境风险点。

import subprocess
import re
import sys

class EnvironmentChecker:
    def __init__(self, adb_path='adb', required_adb_version='1.0.41'):
        self.adb_path = adb_path
        self.required_adb_version = required_adb_version

    def check_adb(self):
        """检查ADB版本及设备连接"""
        try:
            # 获取ADB版本
            result = subprocess.run([self.adb_path, 'version'], capture_output=True, text=True, check=True)
            version_line = result.stdout.split('\n')[0]
            match = re.search(r'version (\d+\.\d+\.\d+)', version_line)
            if not match:
                raise RuntimeError("无法解析ADB版本信息")
            current_version = match.group(1)
            self._compare_version(current_version, self.required_adb_version, "ADB")

            # 检查设备连接
            devices_result = subprocess.run([self.adb_path, 'devices'], capture_output=True, text=True, check=True)
            lines = devices_result.stdout.strip().split('\n')[1:] # 跳过第一行标题
            connected_devices = [line.split('\t')[0] for line in lines if line.strip() and 'device' in line]
            if not connected_devices:
                raise RuntimeError("未找到已连接的Android设备。请确保设备已开启USB调试并已授权。")
            if len(connected_devices) > 1:
                print(f"警告：检测到多台设备({connected_devices})，将默认使用第一台：{connected_devices[0]}")
            self.device_serial = connected_devices[0]
            print(f"✓ ADB版本检查通过 ({current_version})， 设备已连接: {self.device_serial}")
            return self.device_serial

        except subprocess.CalledProcessError as e:
            raise RuntimeError(f"执行ADB命令失败: {e}")
        except FileNotFoundError:
            raise RuntimeError(f"未找到ADB可执行文件于路径: {self.adb_path}。请确保ADB已加入系统PATH或提供完整路径。")

    def _compare_version(self, current, required, component):
        """简单的版本号比较（仅适用于x.y.z格式）"""
        from packaging import version # 推荐使用packaging库，这里为简化用tuple比较
        cur_tuple = tuple(map(int, current.split('.')))
        req_tuple = tuple(map(int, required.split('.')))
        if cur_tuple < req_tuple:
            raise RuntimeError(f"{component}版本过低。当前: {current}, 需要: {required}。请升级。")

关键点解析 ：

1. 版本检查 ：使用 subprocess.run 捕获 adb version 的输出，并用正则表达式提取出版本号。这里我实现了一个简单的元组比较，但在生产环境中，强烈建议使用 packaging.version 库，它能正确处理 1.10.0 大于 1.9.0 这类情况。
2. 设备检测 ： adb devices 的输出需要仔细解析。我们只关心状态为 device 的行（表示已授权且可连接），并提取设备序列号。处理多设备情况是必要的，脚本应明确指定使用哪台设备，避免后续命令歧义。
3. 异常处理 ：任何检查失败都应立即抛出清晰的异常信息，并终止脚本，而不是继续执行。这符合“快速失败”原则，能节省大量因环境问题导致的无效测试时间。

3.2 测试执行器：与Tradefed的深度对话

这是整个脚本最核心、也最复杂的部分。我们需要创建一个子进程来运行 tradefed 控制台，并与之进行双向通信。

import subprocess
import threading
import queue
import time

class TradeFedRunner:
    def __init__(self, tradefed_jar_path, results_dir):
        self.tradefed_jar_path = tradefed_jar_path
        self.results_dir = results_dir
        self.process = None
        self.output_queue = queue.Queue()
        self.is_running = False

    def start_console(self):
        """启动Tradefed控制台进程"""
        # 构建命令。关键参数：--console启动交互式控制台
        cmd = ['java', '-jar', self.tradefed_jar_path, 'console', '--log-level', 'VERBOSE']
        self.process = subprocess.Popen(
            cmd,
            stdin=subprocess.PIPE,
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT, # 将标准错误合并到标准输出，便于统一处理
            bufsize=1, # 行缓冲
            universal_newlines=True, # 以文本模式处理
            cwd=self.results_dir # 设置工作目录，测试结果将生成于此
        )
        self.is_running = True
        print(f"Tradefed控制台已启动 (PID: {self.process.pid})")

        # 启动一个后台线程，持续读取控制台输出，避免缓冲区阻塞
        self._start_output_reader()

    def _start_output_reader(self):
        """在独立线程中读取进程输出"""
        def reader():
            while self.is_running and self.process.poll() is None:
                line = self.process.stdout.readline()
                if line:
                    # 过滤ANSI转义序列，并放入队列供主线程消费
                    clean_line = self._strip_ansi(line)
                    self.output_queue.put(clean_line)
                time.sleep(0.01) # 避免空转消耗CPU
        thread = threading.Thread(target=reader, daemon=True)
        thread.start()

    def run_command(self, command, timeout=60):
        """向Tradefed控制台发送命令并等待特定输出"""
        if not self.is_running or self.process.poll() is not None:
            raise RuntimeError("Tradefed控制台未运行或已退出")

        print(f"执行命令: {command}")
        self.process.stdin.write(command + '\n')
        self.process.stdin.flush()

        # 收集命令输出，直到出现提示符或超时
        start_time = time.time()
        output_lines = []
        while time.time() - start_time < timeout:
            try:
                line = self.output_queue.get(timeout=0.1)
                output_lines.append(line)
                print(f"[TF]> {line.rstrip()}") # 实时回显，方便调试

                # 关键：检测到控制台提示符，表示命令执行完毕
                if line.strip().endswith('>'):
                    break
            except queue.Empty:
                continue
        else:
            raise TimeoutError(f"命令 '{command}' 在{timeout}秒内未完成")
        return '\n'.join(output_lines)

    def run_cts_plan(self, plan_name, module=None):
        """运行指定的CTS测试计划"""
        command = f"run cts --plan {plan_name}"
        if module:
            command += f" -m {module}" # 可选：只运行特定模块
        output = self.run_command(command, timeout=3600*24) # 设置一个很长的超时，因为测试可能跑一天
        # 这里可以开始解析输出，实时统计进度
        self._parse_test_progress(output)

实操心得与避坑指南 ：

1. 缓冲区与死锁 ：直接使用 subprocess.PIPE 而不处理输出流，很容易导致子进程缓冲区被填满而卡死。必须像上面一样，开启一个独立的线程去持续消费（ readline ）标准输出。这就是 _start_output_reader 方法的作用。
2. ANSI转义序列 ： tradefed 控制台输出包含颜色代码（如 \033[32m 表示绿色）。如果不处理，日志会很难看且包含乱码。 _strip_ansi 函数（实现略）需要使用正则 re.sub(r'\x1b\[[0-9;]*m', '', text) 来过滤这些序列。
3. 命令完成判定 ： tradefed 执行完一个命令后，会重新打印提示符（如 tf> ）。我们的 run_command 方法通过检测行尾的 > 来判断命令是否执行完毕，这是一个简单有效的启发式方法。但需要注意，某些测试本身的输出也可能包含 > ，所以超时机制是必不可少的备份。
4. 超时设置 ：对于 run cts 这样的长任务，不能设置一个短的超时。我通常设置为24小时。更好的做法是实现一个“心跳”检测：定期检查测试是否还在产生输出，而不是单纯依赖绝对时间。

3.3 异常守卫：让测试在风雨中持续奔跑

自动化测试最怕的就是“脆断”——一个意外就全盘停止。我们的异常恢复模块需要像一名老练的救生员。

class TestGuardian:
    def __init__(self, device_serial, adb_path='adb', check_interval=300):
        self.device_serial = device_serial
        self.adb_path = adb_path
        self.check_interval = check_interval # 每5分钟检查一次
        self._stop_monitoring = False

    def start_monitoring(self, tradefed_runner):
        """启动后台监控线程"""
        def monitor():
            last_activity_time = time.time()
            while not self._stop_monitoring:
                time.sleep(self.check_interval)

                # 1. 检查设备连接
                if not self._is_device_connected():
                    print("警告：设备连接丢失，尝试恢复...")
                    self._recover_device_connection()
                    continue

                # 2. 检查Tradefed进程是否存活
                if tradefed_runner.process.poll() is not None:
                    print("错误：Tradefed进程意外退出！")
                    # 这里可以触发报警，如发送邮件或钉钉消息
                    break

                # 3. 检查测试是否“假死”（长时间无新输出）
                current_time = time.time()
                try:
                    # 尝试从输出队列获取最新行，设定一个很短超时
                    _ = tradefed_runner.output_queue.get(timeout=0.5)
                    last_activity_time = current_time # 有输出，更新活跃时间
                except queue.Empty:
                    # 队列为空，可能测试卡住
                    if current_time - last_activity_time > 1800: # 30分钟无新输出
                        print("警告：测试可能已卡住超过30分钟，尝试注入唤醒命令...")
                        self._inject_wakeup_command(tradefed_runner)
                        last_activity_time = current_time

        self.monitor_thread = threading.Thread(target=monitor, daemon=True)
        self.monitor_thread.start()

    def _is_device_connected(self):
        """检查特定设备是否仍处于'device'状态"""
        try:
            result = subprocess.run([self.adb_path, '-s', self.device_serial, 'get-state'],
                                     capture_output=True, text=True, timeout=5)
            return result.stdout.strip() == 'device'
        except subprocess.TimeoutExpired:
            return False

    def _recover_device_connection(self):
        """尝试恢复设备连接的标准流程"""
        recovery_steps = [
            lambda: subprocess.run(['adb', 'kill-server'], capture_output=True),
            lambda: time.sleep(2),
            lambda: subprocess.run(['adb', 'start-server'], capture_output=True),
            lambda: time.sleep(5),
            lambda: subprocess.run(['adb', '-s', self.device_serial, 'wait-for-device'], timeout=30),
        ]
        for step in recovery_steps:
            try:
                step()
            except Exception as e:
                print(f"恢复步骤失败: {e}")
        # 最终检查
        if self._is_device_connected():
            print("设备连接恢复成功！")
        else:
            print("设备连接恢复失败，可能需要人工干预。")

这个监控循环解决了几个典型问题 ：

1. 设备意外断开 ：USB接口松动、设备重启都会导致 adb 连接丢失。监控器检测到后会尝试重启 adb 服务并重连，这套组合拳能解决90%的临时连接问题。
2. 进程崩溃 ：如果 tradefed Java进程本身因为OOM或其他原因崩溃，监控器能立刻发现并上报，避免脚本在“僵尸”状态下空转。
3. 测试假死 ：某些测试用例可能会陷入死循环或等待一个不存在的资源。通过检查输出队列是否长时间（如30分钟）没有新内容，可以判断测试可能卡住了。此时， _inject_wakeup_command 可以向控制台发送一个无害的命令（如 list plans ），有时能“唤醒”控制台。如果无效，则可以考虑更激进的方法，如重启整个测试模块。

4. 实战部署与配置详解

理论说得再多，不如一个可运行的实例。让我们看看如何将上述模块组装起来，并配置一个完整的自动化任务。

4.1 项目结构与配置文件

一个清晰的项目结构是维护性的基础。我的项目目录通常如下：

android_cts_gts_automation/
├── config.yaml               # 主配置文件
├── main.py                   # 脚本主入口
├── modules/
│   ├── __init__.py
│   ├── checker.py           # 环境检查器
│   ├── runner.py            # Tradefed执行器
│   ├── guardian.py          # 异常守卫
│   └── reporter.py          # 报告生成器
├── logs/                    # 日志目录（自动生成）
│   └── 20240520_143022/
├── results/                 # 测试结果目录（自动生成）
│   └── cts_20240520/
└── requirements.txt         # Python依赖

config.yaml 配置文件示例 ：

# 设备配置
device:
  serial: "ABCDEF0123456789" # 指定设备序列号，留空则使用找到的第一台设备
  adb_path: "/path/to/your/adb" # 可自定义ADB路径

# Tradefed配置
tradefed:
  jar_path: "/path/to/android-cts/tools/cts-tradefed.jar" # CTS tradefed路径
  gms_jar_path: "/path/to/android-gts/tools/gts-tradefed.jar" # GTS tradefed路径
  java_opts: "-Xmx8g -XX:+HeapDumpOnOutOfMemoryError" # JVM参数，大内存测试必备

# 测试计划配置
test_plans:
  cts:
    - name: "CTS" # 运行完整的CTS
    - name: "CTS-on-GSI" # 运行在通用系统映像上的CTS
  gts:
    - name: "GTS" # 运行完整的GTS
    # - name: "GTS-enterprise" # 可以配置多个计划

# 执行策略
execution:
  retry_on_failure: 3 # 失败用例重试次数
  shard_count: 4 # 将测试分片到多个设备上并行运行（如果有多个设备）
  skip_preconditions: false # 是否跳过预条件检查（如设备屏幕解锁）

# 报告与日志
reporting:
  output_format: ["html", "json"] # 生成HTML和JSON格式报告
  archive_logs: true # 是否压缩归档完整日志
  notify_email: "team@example.com" # 测试完成通知邮箱（需配置SMTP）

使用YAML作为配置文件，结构清晰，易于阅读和修改。主脚本 main.py 会加载这个配置，并依此初始化各个模块。

4.2 一个完整的执行流程示例

假设我们想每晚自动运行一次CTS测试，并将结果邮件通知团队。我们可以创建一个 run_nightly_cts.py 的脚本：

#!/usr/bin/env python3
import yaml
import sys
from datetime import datetime
from modules.checker import EnvironmentChecker
from modules.runner import TradeFedRunner
from modules.guardian import TestGuardian
from modules.reporter import HtmlReporter

def main():
    # 1. 加载配置
    with open('config.yaml', 'r') as f:
        config = yaml.safe_load(f)

    # 2. 初始化并运行环境检查
    print("=== 开始环境检查 ===")
    checker = EnvironmentChecker(adb_path=config['device'].get('adb_path', 'adb'))
    try:
        device_serial = checker.check_adb()
        # 还可以添加磁盘空间、Java版本等检查...
    except RuntimeError as e:
        print(f"环境检查失败: {e}")
        sys.exit(1)

    # 3. 准备结果目录
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    results_dir = f"./results/cts_{timestamp}"
    os.makedirs(results_dir, exist_ok=True)

    # 4. 启动Tradefed并运行测试
    print("=== 启动CTS测试 ===")
    runner = TradeFedRunner(
        tradefed_jar_path=config['tradefed']['jar_path'],
        results_dir=results_dir
    )
    runner.start_console()

    # 5. 启动守护线程
    guardian = TestGuardian(device_serial=device_serial)
    guardian.start_monitoring(runner)

    try:
        # 运行CTS计划
        print(f"开始执行测试计划: {config['test_plans']['cts'][0]['name']}")
        runner.run_cts_plan(config['test_plans']['cts'][0]['name'])

        # 测试完成后，Tradefed会返回到提示符，我们可以发送退出命令
        runner.run_command("exit", timeout=10)

    except (TimeoutError, KeyboardInterrupt) as e:
        print(f"测试执行被中断: {e}")
        runner.process.terminate()
    finally:
        guardian._stop_monitoring = True
        runner.is_running = False

    # 6. 生成报告
    print("=== 生成测试报告 ===")
    reporter = HtmlReporter(results_dir)
    report_path = reporter.generate()
    print(f"报告已生成: {report_path}")

    # 7. 发送通知（此处简化，实际需集成smtplib）
    # send_email_notification(report_path, config['reporting']['notify_email'])

if __name__ == "__main__":
    main()

这个流程清晰地展示了从检查到执行再到报告的完整闭环。你可以通过系统的 cron （Linux）或 任务计划程序 （Windows）来定时执行这个脚本，实现真正的无人值守自动化。

5. 避坑实录：那些年我踩过的“雷”

在开发和使用这套自动化脚本的过程中，我遇到了无数意想不到的问题。下面这个表格总结了一些最常见、最棘手的“坑”及其解决方案，希望能帮你节省大量排查时间。

问题现象	可能原因	排查步骤与解决方案
tradefed 启动后立即退出，报 NoClassDefFoundError	Java类路径错误或依赖缺失。	1. 确认 java 命令版本（需要Java 8或11）。 2. 使用 -cp 参数明确指定classpath，包含 tradefed.jar 及其所有依赖的jar包（通常在 lib/ 目录下）。 3. 最佳实践 ：直接使用Google提供的启动脚本（如 cts-tradefed ），而不是自己调用 java -jar 。我的脚本后来改为调用这个封装好的shell脚本，稳定性大增。
测试运行中大量用例因 TEST_TIMEOUT 失败	设备性能不足、系统卡顿或测试本身存在死锁。	1. 检查设备负载（ adb shell top ）。 2. 增加超时时间：在 run cts 命令中添加 --test-arg-timeout 参数，例如 --test-arg-timeout 10m （10分钟）。 3. 排查特定模块：往往是多媒体、相机相关测试耗时较长，可以将其单独列出，分配更长的超时。
adb 命令间歇性无响应或报 device offline	USB接口供电不稳、线材质量差、或设备端 adbd 进程僵死。	1. 更换高质量的USB数据线和接口。 2. 在脚本中增加 adb kill-server 和 adb start-server 的重试逻辑（如异常守卫模块所做）。 3. 极端情况下，通过 adb shell stop adbd && adb shell start adbd 重启设备端的 adbd 服务。
测试结果XML文件解析失败，报告为空	tradefed 生成的结果文件格式可能因版本不同而有细微差异，或文件编码问题。	1. 使用Python的 xml.etree.ElementTree 解析时，增加 try-except 块，并记录原始文件内容以便对比。 2. 先使用 xml.dom.minidom 或 lxml 库的解析功能检查文件结构是否完好。 3. 关键技巧 ：在解析前，使用 subprocess 调用 tradefed 自带的 cts-report 工具生成标准格式的报告，这比直接解析原始XML更可靠。
在多设备分片测试时，任务分配不均	默认分片策略可能不智能，某些设备上的测试用例更耗时。	1. 不要完全依赖 tradefed 的 --shard-count 。可以手动将测试计划按模块拆分成多个子任务，然后分别分配到不同设备上并行执行。 2. 根据历史数据，将耗时长的模块（如 CtsMediaTestCases ）单独作为一个分片。
生成的HTML报告在浏览器中样式错乱	报告模板中的CSS/JS使用了在线CDN，而内网环境无法访问。	将报告生成器（如 HtmlReporter ）模板中引用的外部资源（如Bootstrap CSS、jQuery）下载到本地，并修改模板指向本地路径。确保报告能在完全离线的环境中查看。

最重要的一个心得是：日志，日志，还是日志！ 一定要让脚本输出足够详细、分级的日志。我建议使用Python的 logging 模块，将不同级别的日志（DEBUG, INFO, WARNING, ERROR）输出到不同的文件。当测试在半夜失败时，详细的DEBUG日志是你第二天早上排查问题的唯一线索。我的日志目录通常会包含 script.log （脚本自身日志）、 tradefed_console.log （控制台原始输出）、 device_logcat.log （设备系统日志），这些文件会按测试会话打包归档。

6. 进阶玩法：从自动化到智能化

基础自动化已经能节省大量人力，但我们还可以走得更远。结合现有的技术趋势，这里有几个值得尝试的进阶方向：

1. 与CI/CD管道集成 ：将你的Python脚本封装成一个Jenkins Pipeline任务、GitLab CI的Job或者GitHub Action。这样，每次代码提交到特定分支（如 main ）时，自动触发CTS/GTS测试，并将结果报告附加到构建产物中。实现“每夜构建”（Nightly Build）级别的持续兼容性验证。

2. 失败用例自动分类与提单 ：目前，报告只是列出了失败的用例。可以更进一步，写一个分析模块，对失败日志进行模式匹配。例如，将所有因 Permission Denial 失败的用例归类为“权限问题”，将因 Native Crash 失败的归类为“原生层崩溃”。甚至可以集成JIRA、GitLab等系统的API，自动创建Bug工单，并附上失败日志和截图。

3. 历史趋势分析 ：将每次测试的通过率、失败模块TOP榜、总耗时等关键指标存入一个时间序列数据库（如InfluxDB）或简单的SQLite数据库。然后用Grafana等工具绘制仪表盘，你可以清晰地看到随着版本迭代，兼容性质量是上升还是下降，哪个模块是“故障高发区”，为质量评估提供数据支撑。

4. 基于机器学习的Flaky测试识别 ：有些测试用例是“不稳定”的（Flaky Test），时而通过时而失败，极大地干扰判断。可以收集大量历史运行数据，训练一个简单的模型来识别这些Flaky测试。在报告中将它们高亮标记，或者建议在首次失败时自动重试多次，以确认是否是真实缺陷。

实现这些进阶功能，意味着你的脚本从一个“自动化执行工具”进化成了一个“智能测试分析平台”。这需要更多的前后端开发知识，但带来的效率提升和质量洞察是革命性的。

最后，我想分享的是，构建这样一个系统不是一蹴而就的。我的建议是 从最小可行产品（MVP）开始 ：先实现能自动运行一个CTS模块并生成文本报告。然后，像搭积木一样，逐步加入异常恢复、报告美化、结果分析等功能。每增加一个功能，都立刻用它来跑一次真实的测试，在实践中发现问题、迭代优化。这个过程本身，就是对Android系统兼容性测试理解不断加深的过程。当你看到脚本在深夜默默运行，清晨准时将一份清晰的测试报告发到你的邮箱时，那种成就感，足以抵消所有调试的艰辛。