UI 自动化测试,因界面元素变动大,导致维护成本高。那有没有可能利用脚本去扫描前端代码,来获取或是自动更新测试用例定位元素
这样应该可以扫描出元素,可以把自动化编写及维护进行左移
好想法,要是哪怕有个 demo 就好了
那你就要去维护前端扫描脚本了。
Android 上你这个方案应该可行,但是仅针对布局文件的 xml 里 id 确定的元素,通过确定的 id 来找到对应的资源文件里的文案,但是有些元素是动态的,xml 里无法找到这个元素,我就不知道怎么解决了.其他端,没有经验,不丢人了.
这个可能会有比较多难点。
1、在控件内容(比如原来定位的 id)变了的情况下,怎么判断新的元素是用于替换旧元素的?这个我没想到什么比较固定的准则,实际项目里基本也是需要结合需求判断,有些不确定的需要找开发二次确认的。
2、如果不只是改控件,而是连布局、交互都改了呢?这种情况下可能不存在原来的控件改成了什么新控件这种一对一关系,需要改动的其实不只是定位元素,甚至用例逻辑都得改。这时候可能需要的是会自动生成用例,而不仅仅是维护用例的工具了,现阶段除了智能遍历类外,暂时没见到这方面有比较成熟通用的工具。
所以,如果界面元素持续变动很大的话,建议取消做 UI 自动化,或者考虑用录制之类的更便捷的方式生成用例。
我觉得您这种方式没法去纯自动的完成,因为受 UI 具体变更影响太大;
简单来说,就算只是变一个按钮,咱也不能确定这个按钮触发的后续功能是不是和之前一致的;
按照上面角度来看这个问题,那么做这个事情需要的时间包括:开发这个脚本的时间 + 脚本识别完后做确认的时间。
我们是通过定义抽象 xpath 表达式的方式来实现降低维护成本的
虽然不能完全避免 UI 变动带来的维护 但是需要维护的页面对象比之前少了 90%+ 从实际效果来看 还是很不错的
最近项目改了架构,所有的 ID 都没有了,没错,是木有了。
自动识别的前提是改动不多。
有没有可能利用脚本去扫描前端代码
没有
感觉还是让前端定时提供一个记录表或者变更表会更好些,这样研发也能了解前端页面的一些变更历史。
你的想法很好,几乎不可能。不过奇林测试平台(kylinTOP) 你可以研究一下,录制的脚本中包含元素的所有属性,即使用元素部分属性变更举动影响步骤的执行。也算是一个不错的方案。
就跟楼上说的一样,完全自动化维护不太现实,因为自动找到更改后元素匹配 (这部分还需要人工根据业务来识别), 但是我们可以通过辅助手段来降低一些维护成本。比如 PageObject 模式既然把页面对象隔离开了,我们可以通过辅助工具对元素进行快速的增删改查。 这个是我们目前使用的工具,可以方便的维护对象库 https://testerhome.com/topics/30503, 你或许可以参考下这种思路。
另外,UI 框架的设计可以多贴合前端的规范,然后通过一些代码生成技术,实现快速书写自动化用例。