什么样的项目适合UI自动化测试？

点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快我们在考虑做自动化测试之前一定要先分析一下这个项目到底适不适合做自动化测试避免在不太适合自动化测试的项目中痛苦挣扎既浪费了大量的人力和时间又收效甚微。下面简单列举一下评估一下项目是否适合做自动化的一些考虑因素需求变动不频繁自动化测试脚本变化的大小与频率决定了自动化测试的维护成本。如果软件需求变动过于频繁那么测试人员就需要不断地更新自动化测试用例从而适应新的功能提升脚本的稳定性。而脚本的维护本身就是一个开发代码的过程需要不断的扩展、修改、调试有时还需要对架构做出调整。如果所花费的维护成本高于利用其节省的测试成本那么自动化测试就失去了他的价值与意义。一种折中的做法就是先对系统中相对稳定的模块与功能进行自动化测试变动较大的地方进行手工测试。项目周期较长由于自动化测试需求的确定、自动化框架的设计、脚本的开发与调试都需要一定的时间而这个过程本身就是一个软件的开发过程如果项目周期比较紧张没有足够的时间去支持这样一个过程的话就不要进行自动化测试。自动化脚本可以重复使用自动化测试脚本的重复使用要从三个方面来考虑1.所测试的项目之间是否存在有很大的差异性如C/S系统架构与B/S系统架构的差异2.所选择的测试技术和工具是否适应这种差异3.测试人员是否有能力设计开发出适应这种差异的自动化测试框架目前常见的自动化测试工具非常多 比如 UFT (以前的名称是QTP)、Robotframework、Airtest、Cypress等涉及到APP的自动化的话一般用Appium的多一些这里建议有编程基础的朋友自己选择框架进行二次开发可能使用的会习惯点开源框架可能功能强大但是工具学习也需要成本有时候也会有局限性而且自动化底层原理都差不多自己封装的话便于扩展可以自己将框架中比较好的功能单独剥离出来。那么如果是自学的自动化没有项目实战经验的时候怎么衡量自己是否能独立承担UI自动化测试的工作呢可以从以下几点去思考如何去设计测试场景如何提高元素操作的成功率如何提升脚本的稳定性如何提升脚本的执行效率脚本可扩展性、代码可复用性如何去管理你的测试用例、执行测试用例如何生成测试报告脚本执行报错后能否快速定位到问题一些复杂的元素定位不到或者通过传统的元素定位无法进行操作时该如何处理比如canvas、如何设计高质量自动化脚本实现业务逻辑、脚本、数据分离。使用PO设计模式将一个页面用到的元素和操作步骤封装在一个页面类中。如果一个元素定位发生了改变我们只用修改这个页面的元素属性对于页面类的方法我们尽量从客户的正向逻辑去分析方法中是一个独立场景例如登录到退出而且不要想着把所有的步骤都封装在一个方法中。测试用例设计中减少测试用例之间的耦合度。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。