这篇关于自动化测试的文章,可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师,没有开发过自动化的工具或者框架,用的自动化的工具也不多,也没有做过开发,所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的,我觉得这些东西并不是我的,而且也是可以很容易获取的。
(测试即服务基本架构)
那么在自动化这个很大的领域来说,我是什么呢? 我是自动化技术的使用者,要在团队中做自动化,还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中,给大家分享一下我这些年实践自动化的经历,特别是那些不是那么成功的经历,希望能够给你带来一些思考和共鸣。
做自动化测试时会遇到以下一些难点:
-
定位元素:自动化测试需要通过代码操作页面上的各种元素,但有时候元素的定位比较困难,可能需要使用多种方法进行尝试和排查。
-
环境配置:自动化测试需要使用特定的工具和技术来实现,需要在不同的操作系统和浏览器中进行测试,因此需要进行一些复杂的环境配置和调试工作。
-
测试用例设计:自动化测试需要编写测试脚本,而测试脚本的编写需要考虑全面的测试场景和用例,需要对被测软件的功能和业务逻辑有深入的了解。
-
维护成本高:自动化测试需要持续维护和更新测试脚本,因为被测软件的变化可能会导致测试脚本失效,需要及时修复和更新测试脚本。这会带来一定的维护成本,尤其是对于大型和复杂的应用程序来说。
-
技术门槛:自动化测试需要掌握一定的编程技能和测试工具的使用,如果没有相关的背景和经验,学习和掌握这些技能可能需要花费较长的时间。
-
无法完全代替手工测试:自动化测试虽然可以提高测试效率,但它无法完全代替手工测试。有些场景和用例需要人工测试才能发现问题,因此需要进行手工测试和自动化测试的结合。
一、测试范围
无论是功能测试,还是自动化或者性能测试,第一步要做的,是明确测试范围和需求指标。对于自动化测试来说,特别是UI自动化,并不是所有的功能点都适合做UI自动化。
根据具体的业务情况和项目稳定程度,选择UI自动化+API自动化结合,选择合适的业务点来进行针对性的自动化测试方案设计,才是最佳方案。
二、系统架构
对大多数功能测试人员来说,系统架构不用太多关注,但对于自动化或者性能测试人员来说,系统架构是前期需求分析、技术方案选型设计的一个重点。
比如系统开发的编程语言,使用的数据库类型,通信服务框架ÿ