做自动化测试时所谓的“难点”

这篇关于自动化测试的文章，可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师，没有开发过自动化的工具或者框架，用的自动化的工具也不多，也没有做过开发，所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的，我觉得这些东西并不是我的，而且也是可以很容易获取的。

（测试即服务基本架构）

那么在自动化这个很大的领域来说，我是什么呢？ 我是自动化技术的使用者，要在团队中做自动化，还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中，给大家分享一下我这些年实践自动化的经历，特别是那些不是那么成功的经历，希望能够给你带来一些思考和共鸣。

做自动化测试时会遇到以下一些难点：

1. 定位元素：自动化测试需要通过代码操作页面上的各种元素，但有时候元素的定位比较困难，可能需要使用多种方法进行尝试和排查。

2. 环境配置：自动化测试需要使用特定的工具和技术来实现，需要在不同的操作系统和浏览器中进行测试，因此需要进行一些复杂的环境配置和调试工作。

3. 测试用例设计：自动化测试需要编写测试脚本，而测试脚本的编写需要考虑全面的测试场景和用例，需要对被测软件的功能和业务逻辑有深入的了解。

4. 维护成本高：自动化测试需要持续维护和更新测试脚本，因为被测软件的变化可能会导致测试脚本失效，需要及时修复和更新测试脚本。这会带来一定的维护成本，尤其是对于大型和复杂的应用程序来说。

5. 技术门槛：自动化测试需要掌握一定的编程技能和测试工具的使用，如果没有相关的背景和经验，学习和掌握这些技能可能需要花费较长的时间。

6. 无法完全代替手工测试：自动化测试虽然可以提高测试效率，但它无法完全代替手工测试。有些场景和用例需要人工测试才能发现问题，因此需要进行手工测试和自动化测试的结合。

一、测试范围

无论是功能测试，还是自动化或者性能测试，第一步要做的，是明确测试范围和需求指标。对于自动化测试来说，特别是UI自动化，并不是所有的功能点都适合做UI自动化。

根据具体的业务情况和项目稳定程度，选择UI自动化+API自动化结合，选择合适的业务点来进行针对性的自动化测试方案设计，才是最佳方案。

二、系统架构

对大多数功能测试人员来说，系统架构不用太多关注，但对于自动化或者性能测试人员来说，系统架构是前期需求分析、技术方案选型设计的一个重点。

比如系统开发的编程语言，使用的数据库类型，通信服务框架ÿ