背景
UI 自动化, 在进行的过程中, 难免会遇到平台化,
在实际的工作中, 有的领导也会想要实现自动化测试的平台化. 自动化平台化后, 有了更为实际的成果,
在做 UI 自动化, 很想吧现在的自动化的框架进行平台化, 完成更多的移植.
设想
其实平台化也是不难的, 也是简单的, 前提你也有思路, 我在前面的接口平台的时候的构思就是吧所有的都集中到一个平台. 但是在 UI 自动化测试的平台, 我选择了另外的一个思路 平台端 + 客户端
客户端保持执行测试用例, 平台端进行测试用例的管理, 两者相辅相成. 缺一不可.
平台作为测试服务端, 客户端作为测试执行端, 服务端的改变对客户端减少变动, 客户端对服务端负责, 服务端对客户端提供依赖.
原理
利用平台 -- 客户端的构思, 平台端侧重用管理, 对数据的管理, 对用例的管理, 对任务的管理, 对测试报告的管理, 客户端负责: 获取相应的项目或者任务详情, 执行测试用例, 手机测试结果, 对测试结果进行反馈给平台端,
客户端调用, 平台端管理
客户端执行, 平台端展示
客户端收集, 平台端汇总.
客户端依赖, 平台端支持.
客户端持续集成, 平台端持续收集.
客户端不限制, 平台端能兼容.
有了这样的构想, 下面要做的就是对产品的需求的分析, 对现有的设想进行细分, 对现有的原则进行合理化解.
去分析需求, 去总结需求, 去对现有的需求进行细分拆分.
我们可以看到, 这样的两段, 我们可以用思维导图去细化分析我们的需求.
整体的需求其实就是这么多, 那么我们去来细化我们的需求, 针对 pc 端和手机端分别进行需求的分析
那么我们的客户端也教 pc 端需要什么样的东西呢
这样我们的大概的思路有了, 大概的功能需求分析点有了,
我们就开始我们的技术选型, 根据你的学习的进度还有你的想法去选择, 我选择的是 django, 这里是因为好久不用了, 巩固下 django 相关的知识,
在选择使用的框架的时候, 注意下面几个方面:
1. 自己对框架的掌握度
2. 实现难易程度,
3. 与项目相匹配度.
4. 成本的大小,
5. 经验的多少
6. 学习的难易程度,
7. 部署测试的成本, 调试的代价等
一般来说选择自己熟悉的来做最好, 但是一般还要看项目适合什么样的, 资料的多少, 因为开发过程难免会遇到很多的问题,
接下来就是正式的开发了,
开发的过程不是那么简单的, 也不是那么复杂的, 但是也不是那么一帆风顺的, 遇事会 google, 会百度, 可谓是良师益友. 善于利用开源的东西
写在最后, 最原始的最美好,
一切源于应用, 一切回归应用,
一切服务于应用, 一切简单化,
一切合理化. 一切可操作.
回归本质, 最初的美好.
来源: https://www.cnblogs.com/leiziv5/p/9035324.html