关于自动化实施过程中思考与感悟（1）

        小组内做自动化是从19年开始做的，到目前为止有一年多时间了，中间踩过很多坑，目前还在探索适合当前项目，适合当前公司的一种模式，如何将自动化的效益最大化，帮助小组成员解决项目中实际问题，而不是束之高阁的形式而已，我们自己团队的及项目情况作了如下分析。

       分析之前，我们思考一个问题，自动化最终要的结果是什么？目标明确之后才能做好下步，这个问题先放置，看博文的朋友，或者在做自动化的朋友也问一问自己，自动化的价值在哪里。

一：自动化项目选择

      第一自动化项目是长期做，基线项目，对于长期变更，或者一次性做完不维护的项目不建议做，投入产出比不成正比。所以自动化价值之一是回归。长期项目，且接口变更数量少，适合自动化，自动化可以检测出因为需求未变更，开发 修改或者因新增需求导致之前已经存在功能出现bug情况。对于一些底层中台项目还是比较适合做自动化。

二：UI自动化和接口自动化选择

       还是和具体项目有关。UI的web端自动化一般是基于selenium，APP端的UI自动化是appnuim，都是xpath路径查找元素点击，对于前端html元素比较依赖，所以经常变更需求的项目，元素经常变更，UI投入大，产出小，时间基本耗在维护上，小组内作了一段时间，维护太累。果断放弃，转而做接口层面测试。我的想法是，接口层能保证数据的正确性，UI层面再怎么出错，都不会有数据问题，顶多的UI体验问题，不会出现影响范围很大的问题（重申下，还是和项目有关）。如果API接口经常变更，那么这个后端开发可以领饭盒走人了，或者架构设计很差。项目做UI还是接口自动化，还是看投入产出比。

三：自动化工具选型

       我们自动化使用的RobotFrameWork，工具的优点在于GUI图形化界面清晰，用例独立性比较好，用例管理也简单，而且支持python自定义关键字，可以开发自己个性化关键字。缺陷rideGUI用例库庞大之后，会有卡顿现象，我们目前用例数量有5000+功能用例，需要电脑配置 比较好，我们团队经常 有成员说卡顿受不了。解决办法，将用例模块拆分，一个大的模块作为一个项目，可以有效减少卡顿问题，这个问题研究过，查看stock网站，工具本身问题。解决这个问题要么是技术上，要么是工程层面解决，要么从硬件上解决问题。也看过pytest+html报告，但是觉得用例管理不太好，报告过程也不清晰，需要自己print,或者log，感觉不方便，也可以选择java，但是我java实在没精力去弄。总之工具选型可以从用例管理（用例庞大之后问题，需要重点考虑） ，用例书写方便性，用例执行（单个用例的执行），测试报告（用例报告的可读性，非测试人员是否能看懂）的查看这些方便综合考虑，还有团队人的因素，是不是每个人都可以使用。

下午还有事，今天就说这些，后续还有用例设计，用例的持续集成等