UI接口自动化测试的痛点

UI接口自动化测试的痛点

　　当我找组织工作的这时候查看招录信息发现都需要有接口自动化测试经验，由此可见测试人员不会一点接口自动化测试技术都不好意思说自己是做软件测试的。绝大部分测试人员也都是从采用接口自动化工具、录制回放、测试脚本、研发小工具进阶接口自动化测试的，接着在慢慢的碰触 UI 接口自动化、接口接口自动化、持续内置，最终构建接口自动化测试架构系统。

　　绝大部分测试学习者进阶接口自动化测试碰触最少的也许是 UI 接口自动化了，也都采用过移动端的 Uiautomator、Appium UI接口自动化架构、PC 互联网用户界面相关的 Selenium、Robot Framework UI接口自动化架构，无意识里认为 UI 接口自动化测试很简单。但是采用一段天数后得力于，特别是在组织工作中真正采用时就立马孤立无援了，研发和保护脚本的天数远远大于纯手工测试的时间，反过来，最终由重回到了纯手工测试。

　　假如要想 UI 接口自动化在实际的组织工作中得以采用，必需要化解以下关键点，否则 UI 接口自动化的测试还有较远的路要走。

　　1、市场需求不平衡，频密更改的工程项目

　　UI 接口自动化测试最大的挑战是市场需求的变动，用户界面假如时常变动，脚本就需要重新撰写，用户界面市场需求频密的更改引致撰写脚本的速度追不上市场需求的变动，那 UI 接口自动化是不复存在，因而 UI 接口自动化测试特别适宜市场需求平衡、不能频密更改的工程项目。灵巧研发的工程项目市场需求不平衡，市场需求的更改时常会引致用户界面的更改，同时灵巧研发的工程项目成本高，因而灵巧研发的工程项目就不适宜做 UI 接口自动化。

　　2、研发保护成本高的工程项目

　　对于一次性研发的、成本高的工程项目，考量到 UI 接口自动化的其次比，不宜展开 UI 接口自动化测试。UI 接口自动化的收益主要是在数轮测试的这时候才能体现出来，换言之一个保护成本高的工程项目测试的轮数比较少，如用户界面测试就测试 1 到 2 轮即可，这样完全能采用纯手工测试就行了。同时接口自动化脚本的研发和增容本身就需要一定的天数，假如工程项目的成本高，没有足够的天数支撑脚本的研发，那也无需接口自动化测试了。

　　3、被测系统开发不规范，可测试性需求不明确

　　UI 接口自动化测试其实是演示纯手工点击，不像肉眼能直接找出需要页面的管理器，流程就不一样了，需要我事先要找出要页面的管理器，接着让流程去页面完成演示纯手工的操作。这就需要在工程项目研发前特别针对接口自动化测试表述一些列的规范化，研发工程师在研发的这时候遵循规范化研发，UI 接口自动化才能展开下去。例如特别针对按键管理器没有表述唯一的 id 或者文档描述等，在接口自动化脚本撰写的这时候就难以找出该管理器。假如研发在不同的版本以后时常随便更改管理器的表述，那以后能继续执行的脚本在后就难以正确的运行，需要动态保护，带来很高的物力效率而变得工作效率低下。同样的还有接口接口自动化测试过程中的接口参数等。

　　那什么样的工程项目适宜展开 UI 接口自动化测试呢?如下列出的能展开参考：市场需求平衡不频密更改;需要频密的重回验证;UI 用户界面平衡、用户界面管理器表述规范化可测试科灰藓;研发保护成本高的工程项目;工程项目进度压力小;大型公司大平台;测试部门中绝大部分测试人员具备脚本研发能力。

　　当前，UI 测试是耗费测试团队物力最少的测试环节，绝大部分的测试人员日常的组织工作是 UI 测试。因而 UI 接口自动化非常适宜化解简单、机械、重复的任务，增加测试的覆盖率。UI 接口自动化测试不仅仅撰写测试脚本，也需要设计，不仅需要考量成千上万条用例的继续执行工作效率，还需要考量保护效率，继续执行结果的一致性。我需要明白，UI 接口自动化测试不能替代纯手工测试，也很难减少测试人员，不能盲目的尊崇和追求 UI 接口自动化测试。

　　以上内容为大家介绍了UI接口自动化测试的痛点，希望对大家有所帮助，如果想要了解更多接口自动化测试相关知识，请关注多测师。https://www.aichudan.com/