标签：备份服务器 apk 登录 控制 架构 优点 流程 生成 shard
cts全流程自动化。大致包括以下模块：
| 目标 | 方案 | 问题等级&痛点 |
|---|---|---|
| 版本构建 | 目前方案： python库paramiko远程ssh登录 详细： win端python脚本paramiko库远程ssh登录Linux编译服务器,将一键编译命令写入一个python文件，然后执行该“一键编译命令”py文件 |
问题等级：低 版本有时候会下载不下来，需要人工干预。 自动构建不是问题，daily已经实现的东西。 |
| 强制OTA升级 | 目前方案： 方案需研究讨论，关于如何改配置 另外多台机顶盒升级未实现过 之前方案： 1.将编译服务器的OTA包copy到win端的Apache服务器路径（备好升级规则文件以及配置，升级配置是为了避免循环升级） 2.adb install 改配置apk修改versionserver，重启强制升级（同时升级配置） 配置分离后有aidl，所以实现jni客户端，以一个service接受参数形式完成了这个apk，如此可以am satrtservice 写配置。 但是现在已无法使用，具体原因需讨论（Android9禁止后台启动service） |
问题等级：高 无法adb 命令修改配置，该模块约等于废掉 方案猜想：am satrt activity 然后-es传参？ 另外，OTA升级data满了在selinux：enable下如何清空（涉及cts拷贝媒体文件）？导key（烧录过一次无需再烧？）OTA升级和USB烧录，版本区别是？ |
| 自动retry | 目前方案： shell脚本调用gnome终端来实现的伪子进程，新retry的开始来自于cts-tf >l r 命令结果监听 为什么采用目前方案？： 是由于以下尝试： 1.python子进程：可启动cts-tradefed脚本，可启动测试，无法加--shard-count参数 2.shell直接./cts-tradefed xxx 调用脚本开启测试，可以运行测试，但是无法退出。如果你运行过cts测试你会发现这个脚本是一直处于等候输入状态cts-tf > 3.另外比较重要的一点，以上两种的标准输出无法重定向，所以目前采用./cts-tradefed l r 结果监听的手段，猜测有其他手段，请讨论 |
问题等级：高 一般我设retry5次，这样开七八个终端测试机就开始出现明显的卡顿。另外该retry方案无法通过ssh远程调用(运行脚本不会产生新gnome终端)，原因未知。 我相信这是最low的retry手段，请讨论 另外排除人工干预的话有一个重要问题（如何确定这是我们想要的稳健的拿来给开发人员分析的报告），在下一模块集中讨论。 |
| 报告+日志备份并解析 | 目前方案： 1.将Linux测试机的结果copy到备份服务器 2.requests和bs4解析报告html，并进行失败项过滤分类，生成Markdown格式HTML（为了同步ICenter以及比文本好看一丢丢？） |
问题等级：低 虽然全自动化的理想很美好，但是不得不面对的现实是： 版本早期，失败项少则几十多则五六百，脚本如何确定什么状态的报告是能发出来的，这个需要重点讨论。根据经验，开发人员需要的用来分析的不应是环境引起的失败（例如网络断了，没导key，没插电视，机顶盒adb掉线，系统挂了不响应了导致大批量失败），为什么呢？因为这种状况应该由测试人员（工具）做保证，调整正确物理环境排查过滤掉，而不是反复反复报出来由开发人员再过滤一遍，综上一句话：测试工具如何保证测试结果的稳健性，纯净性！！！尤其是早期系统不稳定故障多的时候比较难不依赖人工干预，还是需要测试人员去监测运行状况的 |
| 邮件发送 | 目前方案： 目前没做，将‘简单分类’复制粘贴ICenter，写测试总结，失败项分析任务安排,然后转发邮件 为什么不自动发邮件？ A:还是上面的问题，我们无法确认报告是我们想要的报告，自动发出的垃圾邮件垃圾数据无分析必要的话，反而会增加沟通成本。 测试人员会频繁问，这结果能证明是系统问题？我怎么发现好多环境引起的问题，你确定这是正常稳健的测试结果吗？于是测试人员不得不再次回头确认测试结果，再次retry，获得与经验相符的稳健结果 |
问题等级：低 个人建议，邮件自动转发是不必要的，因为测试完需要测试人员根据经验来过滤并指定责任人来安排分析任务。因为失败项是全领域的，而开发人员是分领域的，不安排的话，各领域面对一堆数据，会比较懵，不知道自己该分析哪个 |
一些补充
目前的架构是
win端为控制台，win端需要将Linux编译服务器，Ubuntu测试机挂载为网络驱动器
Ubuntu测试机需要双网口，同时接10与192外网。
机顶盒有线接10，无线接192外网
另一种考虑：
能不能完全屏蔽掉win端，所有模块都搬到Ubuntu测试机上去，
Ubuntu上远程编译服务器编译版本
Ubuntu上配置好Apache服务器给机顶盒强制升级
Ubuntu上直接开启测试，retry
Ubuntu上解析结果，服务器备份结果
然后人工获取服务器备份发邮件进行分析任务安排。
以上相较于目前方案优点在于，免了win端远程Ubuntu执行命令，执行结果标准输出&日志打印回显win端是件麻烦事不回显德华作为控制台的win端就显得鸡肋。
标签：备份服务器 apk 登录 控制 架构 优点 流程 生成 shard
原文地址：https://www.cnblogs.com/houser0323/p/10992898.html
