测试开发工作者日记：2020.9.28
作者：互联网
又开始这个系列。
最近半个月。忙的跟个monkey一样。天天研究业务。只能利用闲散时间维护下工具和平台。
不过最近拒绝了一次业务测试。发了脾气。甚至扬言大不了不干了，有能耐开了我...这种“豪言壮语”。
经过询问得知，我们组之前好多同事都受到了那个部门提测的不同程度的欺负。比如没有测试环境，要求着急上线，线上测试。然后出了问题，测试背锅。或者线上的测试因为没有办法利用各种工具/脚本，节省人力时间，导致很多测试只能持续很久，比如测试一个三天的优惠卷，你需要真的等3天，而且这个卷还要经过财务的层层审批，防止你套现。出点bug，还没来得及提，财务那边风控部门先找你了。
最可怕的是经常有一些防打扰的测试需要半夜几点测试。如果在测试环境我们可以轻松修改数据库来实现替代。但是线上呵呵。你需要真的等半夜爬起来。
更可怕的是，你一定在很多知名大软件上见到tsest推送吧？然后sha个测试祭天？其实真实原因并不在测试。
比如他们要线上测推送，然后说帮你写个if过滤，只给你一个人发推送。你忐忑不安的开始，结果发现，推送给了千万的用户.... 因为那个if写错了，或者刚写完被其他人上线部署给覆盖回复原状了.....
这种情况压根就不是正经的开发项目周期流程。为什么还硬拉着测试人员呢？因为需要背锅侠啊....
不过最近我在支援各部门的时候，这种锅砸在了我头上，作为嗅觉灵敏的老油条立即开始反抗。不测就是不测，风险无法承担。要么别上线，要么你自己自测去吧。反正你们没过自测冒烟，流程上也不对。
当然领导还是向着我，紧急开会给这事平息了，对方又是道歉又是退步的。但是我仍然没有松口，要么下成本搞测试环境要么以后他们部门的东西别提测。不过听组员说，以前就吃过很多次亏，敢怒不敢言，而且申请过测试环境，但是没批。这次我闹的这么大，然后以一个最高p级去申请，结果..居然仍然失败了。算了，带不动。
利用空闲，还是回来搞之前设计的ui自动化架构。其实说白了，就是一套关键字驱动核心的架构。只是利用了很多很多的设计，和小技巧。能把我们各个测试同学写的好几千条用例，直接翻译成缓存中的代码来使手机app运行。
看着很神奇，那边汉语描述的各种用例，这边手机就开始自动跑起来，断言出报告了。中间环节的写脚本的自动化测试人员消失了。
做这个之前，我分析了ui自动化的各种特点特性及适用场景，包括一些我们以前不考虑的问题。
比如问题:
都说ui自动化不好，因为维护成本高，前端总变。
思考：
为什么高？因为前端总变？那么到底变了什么？其实就三点，1是旧用例逻辑，2是旧用例元素定位语句 ， 3是新用例。
如果解决了这三点，ui自动化是不是就稳了？当然我们不可能彻底解决，但是能解决多少算多少，当达到了一个可接受的维护成本内，是不是就可以搞起来了？而且如果能利用ai智能，不断的纠错提高准确度，是不是最终会达到一个不需要人维护的状态呢？
当然类似于上述的设想和分析到底的 节点，有很多。
而且在一开始，我也分析预测了各种开发风险，最可怕的就是一个没思考过的突发问题，然后无法解决或绕过，导致整个项目设计前功尽弃，然后引咎辞职吧～
在经过了一个月的零散时间的开发中，真的如我所料，遇到了不少突发问题。好在运气比较好，全部完美解决了。
终于昨天晚上，第一个demo用例成功了。 直接对着我们用例平台上的一条用例，然后手机app开始运行，和人一样的逻辑，和人一样的判断。
这个demo打通，说明这个架构的设想是成功的，带来的效果也非常非常震撼，我试着改了改用例，随便写了点逻辑和断言。果然app就像一个活的人一样，开始按照你写的汉字开始准确的运行和断言。
比如我写的用例是：进入个人中心页面，点击登录，然后登陆成功，然后去首页看看欢迎语对不对，再去个人设置页面看看昵称。
然后新架构的做法是先打开app，然后判断要先去个人中心页面，但是自己当前并不在这个页面，发现自己在首页，然后判断出要怎么做才能最短路径进入个人中心，然后和人一样进了去之后，判断一下是不是进入成功了，然后开始找登陆按钮，点击。然后进去之后，识别用例需要登陆成功，好的，自动找到用户名/密码/登陆按钮，成功后，自己会判断一下是不是真的登陆成功，之后觉得自己要去首页了，但是自己并不在首页，然后就找到一条路跳转到首页，看看欢迎语觉得没问题，然后又同样方法跑到个人设置页面去看看昵称。
反正听我说，可能觉得很平常的操作，但是实际上看到是很震撼的，仿佛有生命一样。比如我改成登陆成功后，去聊天页看看有没有新通知小红点。再次执行它会真的这么做。
以上，就是我如何解决用例逻辑变更 带来的问题的方案和已经实现的技术。
接下来就是如何应对元素定位变更的问题，好在我的wqrfnium_app 自动维护元素这个开源工具先研究出来了，直接套用，能应对不少前端变更元素定位的问题。
接下来就是新用例的问题。这个更不用考虑了。因为每次执行，对于架构系统而言，都是新用例，都会重新按照逻辑去跑app。所以无所谓老旧。
中间遇到不少意外问题：
比如同一个页面，在不同登陆状态下，里面的内容完全不相同。
比如俩个页面，在某种状态下，里面的东西一摸一样，导致系统都分不清自己当前处于什么位置了。
比如一个输入框元素的数据在用例上写的太潦草 并没有给出应该输入的确切内容。
比如某个流程用例中缺少很多关键信息，比如登陆，应该写输入用户名/输入密码/点击登陆按钮， 但是用例中我们往往看到就简单四个字：登陆成功
很多很多这样的意外问题，都被一一解决掉，添加新控制器的，添加新层级的，添加新过滤层，添加新组件，还有引入ai深度学习 和大数据识别等技术。
上面这些只是定位执行操作的过程，另一个大过程是断言。当然也被实现了。
一个一开始听起来很简单的架构，真实达到稳定的能用的状态，代码量起码翻番2次。任何一个小问题解决不了，都可能导致最终全盘皆输。
在第一个用例被成功执行后，就说明线路通了。其他用例估计还会遇到一些意外风险，但是总数是固定的。迭代几次后一定会解决掉全部用例。
我觉得这个稳定运行之后，我可以写成一个教程或者一本书。 当然还有很多系列教程等待我去写完，真希望那时候这公众号和博客还有人看。
博客的个人域名地址
：https://wangzijia.blog.csdn.net/
收录于话题 #测开日记系列散文
27个
上一篇测试开发工作者日记：2020.9.21下一篇测试开发工作者日记：2020.10.10
标签：2020.9,app,28,然后,用例,登陆,测试,日记,页面 来源： https://blog.51cto.com/u_15282986/2953191