测试开发工作者日记：2020.6.22-6.23

继续开始本系列哈～

最近收到了来自于领导和开发及其他测试同学的 需求。关于android自动化的。

本来正在忙接口自动化线上监控。但是没办法，这边需求较紧急。

之前我开发的安卓自动化平台，主要用来监控线上的各种功能。自己设置什么时候跑～

但是众所周知，ui自动化除了监控之外，更重要的是上线前回归全量用例，代替手动的麻烦，而且支持多用户多设备多用例多线程的自由组合，还要对应我们用例管理平台的所有手工用例，形成1:n关联。达到一个超级可用的企业级状态。

难度：*****************

所以就是要再开发一套可以回归用的测试用例。

这里要考虑几个问题：

1. 监控用例监控的是线上，数据都是线上的。而回归的阶段是在上线前，也就是用例要运行在测试环境。那么数据必然要搞一套测试环境的。
2. 监控平台一直跑线上的，性能已经趋于极限，不可能再增加新的设计，何况是更大的一次设计，所以需要再找另一台服务器。
3. 安装包问题，安装包管理较混乱，每次也都不同。所以新回归平台必须支持使用者自己上传apk包。这和监控平台设备都下好的线上包逻辑不同。
4. 环境问题，线上监控平台不考虑环境切换。而回归平台的环境是使用者可以任意切换的。
5. 接口性能问题，测试环境的性能肯定远不如线上的速度快，所以用例必须要增加容错。
6. 稳定性问题，测试环境即便是master环境，某些服务等模块经常因为部署问题压根无法访问。所以使用者需要自行对用例进行组合，大多时候是按照模块区分，所以我去写用例脚本，那么也需要一开始就分好模块。
7. 用例数量问题，既然要对应用例管理平台的用例，那用例划分必然也要尽量贴合，但是自动化用例为了稳定性有自己的一套考虑和标准，难免会和手动用例产生冲突，如果全部照搬手动用例，必然要做一份相当牛x的用例规程才行，否则执行时间将大大增加。
8. 多用户的多需求问题，因为设备并不是很多(有些用例必须用真机)，电脑也不是很快。所以为了避免用户之间出现资源冲突，最好是一个用户只能分1台真机+1台模拟器。目前电脑的极限我估计也就是2台真机+2台模拟器。
9. 平台设计问题，大部分核心技术可借鉴之前的监控平台，但是也要新增很多新设计来配合上述的各个需求，肯定还会遇到新坑。所以代码量和排期不好估计。
10. 测试报告问题，之前只区分用例。新平台要在此基础上，再区分设备。

目前能考虑到的就这么多。根据本人开发过不下20个测试平台/工具的经验来说，结合2/8原则。我估计顶多还有2个我没考虑到的点，所以在项目进行前做好2个新考虑点的风险心里准备。

好了，想的差不多了，开始动手。结果马上就遇到了坑：

1. 破电脑三个月没开机 居然显示器不好使了。我和同事研究半天，试了好久，最后干脆拆开主机，发现全是灰，显卡接口氧化了，擦了一下，好使了。
2. 新电脑格式化重做了系统。然后一点点配置各种自动化平台环境。结果配置到最后，启动一个demo脚本的时候，居然报错？是我用python 在pycharm中调用sys/subprocess 来启动我解析的appium客户端launch命令，报了一个java -version 命令失败的错误。很显然，是appium内部执行java -version时候发现没有获得想要的结果的问题。一摸一样的电脑/一摸一样的系统/一摸一样的各种环境/一摸一样的各种代码/一摸一样的第三方插件版本。就这么毫无理由的报错了.....

（第一时间去百度吧，不过百度了好久，发现连搜都搜不到一样的报错。难道只有我会有这个错误么？真tm无语。）

不过贾乃亮说过：只要智商不滑坡，办法总比困难多。在我多年的在这条路上挣扎的漫长岁月里，这种疑难杂症，百度找不到，问谁谁不会的情况 也不是第一次了，甚至不是十次八次，而是百八十次了！ 每次我摸索解决后都会写个博客，然后混点粉丝和流量。所以万事皆有好坏俩面。

扯远了，我的意思就是，针对这种寻求不到帮助的问题砸脸的时候，我有很多解决经验和套路。

先思考都有几种解决办法，然后对每种办法进行预估，预估它的复杂度，自己能否驾驭了，成功率，耗时率，是否会产生其他坑的概率。然后做个排比，从评分最高的办法入手。我就不信世界上没有解决这个破问题的办法。

在漫长的实验不同方法道路的过程中，最重要的是保持住心态，别试了几种几天没解决就放弃。

本次问题，首先进行分析：

1.改appium源码，强行写死java版本：不推荐，治标不治本，也许改完这个还有下一个类似问题，最后突然遇到某个彻底写死不了的就前功尽弃了。

2.百度：失败了

3.问大佬：失败了

4.问题定位- 扒开表面报错，最后找到真实原因再说---可行

按照方法4，首先确定现场因素，电脑-pycharm-python3-appium命令-java版本报错。

1.换台电脑，发现没问题，所以确定代码版本等都没问题，问题出在这台电脑

2.在cmd中执行java -version，没问题.所以问题出在pycharm+python3+appium上

3.在cmd中执行python3 这个脚本.py ，没问题，所以问题出在pycharm+appium上

4.在pycharm中更改外部命令，从启动appium 直接启动java -version。发现仍然报错，且错误乱码无法辨认，所以appium的影响排除。问题就出在pycharm上！。

5.java -version报错是乱码，无法辨认。所以输入其他任意字符串。发现报错乱码的形状一摸一样，所以排除java -version本身影响。

6.因为任意字符串报错，基本肯定是说找不到/解析不了 的错误。所以推断乱码就是这个意思，那么往回说，就是java -version 报错是因为解析不来，那么原因99%是环境变量没配置好的问题。

7.因为环境变量已经在系统path变量中配置好，外面的cmd是可以的印证了此事。而pycharm中不行，那就说明pycharm的执行环境变量没有接通电脑本身。

8.因为java 是今天刚刚安装的，所以在pycharm中尝试旧的外部命令，如pwd,dir,node等。发现均可正常。所以推断是今天刚刚安装java的问题。

9.既然跟安装时间有关，那么大概率是因为配置没同步的原因，所以打开右上角的设置，根据我的东北味英语找到了这个不起眼的设置：

environment 我知道是环境的意思。点开看看

发现显示了系统环境变量，但是已经勾选并写名：包含父环境变量了，也就是包含了外部电脑本身的变量。那么考虑到我前面推断的同步问题，这就很好验证了。观察一下，发现我今天新加入的JAVA_HOME变量并没有在这里！

所以到此，确定了问题原因。pycharm没有实时同步系统变量！

但是pycharm作为这么著名的软件，不可能犯这种问题，否则早就炸锅了。而且之前使用也没有特意在这手动进行配置过，一样好使，那么真相只有一个：

pycharm的同步机制 是隐藏在了一个经常出现，且不易察觉的用户操作中！

用户每次进行这个操作，都是暗暗的在同步系统变量！

那么这个操作是什么呢？我闭着眼睛就猜到了 ：

它就是-----网管神技！重启！

好的，今天中午修电脑的时候，有人看到我这么大个工程师蹲在地上拿着螺丝刀子修主机就说我好像个网管。那么现在印证了，重启吧！

重启pycharm就行了！然后在我大胆推断，小心论证这么长的链条之后，我重启了pycharm，然后迫不及待的点开一看，果然新的变量JAVA_HOME出现了。

然后左手掐诀，口念法咒。右手点击运行！

最后的效果，神奇的成功了。没报错，就这么成功跑起来了。

怎么样。以上就是我多年来摸爬滚打，久经沙场的解决疑难杂症的套路。小伙伴们学会了么？