【软件测试】自动化测试的追求，水土不服？看看资深测试咋说的......

---

前言

大部分测试初学者入门自动化测试接触最多的也许就是 UI 自动化了，也都使用过移动端的 Uiautomator、Appium UI自动化框架、PC 互联网界面相关的 Selenium、Robot Framework UI自动化框架，潜意识里认为 UI 自动化测试很简单。

但是使用一段时间之后喜忧参半，特别是在工作中真正使用时就立马水土不服了，开发和维护脚本的时间远远大于手工测试的时间，得不偿失，最后由回归到了手工测试。

UI 自动化在实际的工作中得以使用，必须要解决以下痛点。

需求不稳定，频繁变更的项目
UI 自动化测试最大的挑战就是需求的变化，界面如果经常变动，脚本就需要重新编写，界面需求频繁的变更导致编写脚本的速度赶不上需求的变化，那 UI 自动化就是名存实亡，因此 UI 自动化测试特别适合需求稳定、不会频繁变更的项目。

敏捷开发的项目需求不稳定，需求的变更经常会导致界面的变更，同时敏捷开发的项目周期短，因此敏捷开发的项目就不适合做 UI 自动化。

开发维护周期短的项目
对于一次性开发的、周期短的项目，考虑到 UI 自动化的投入产出比，不宜进行 UI 自动化测试。

被测系统开发不规范，可测试性需求不明确
需要在项目开发前针对自动化测试定义一些列的规范，开发工程师在开发的时候遵循规范开发，UI 自动化才可以进行下去。例如针对按钮控件没有定义唯一的 id 或者文本描述等，在自动化脚本编写的时候就无法找到该控件。

如果开发在不同的版本之前经常随便变更控件的定义，那之前能执行的脚本在之后就无法正确的运行，需要实时维护，带来很高的人力成本而变得效率低下。同样的还有接口自动化测试过程中的接口参数等。

为了确保自动化测试的顺利进行，自动化测试应当遵循以下规范：

设计自动化测试用例应以主场景为先
在设计自动化测试用例时，应遵循以下顺序：主场景，扩展场景，流程。因为主场景包含了常用的，使用次数最多的功能需求。

保持自动化测试脚本的可读性
设计自动化测试脚本时，应尽量使其保持简单，让一个单元只做一件事，同时，为脚本加上必要的注释，使其具有很好的可读性。

保持自动化测试脚本的可维护性
可维护性意味着维护自动化测试脚本的成本降低，使得自动化测试可持续改进。所以，测试人员设计测试脚本的时候应避免“硬编程”，将固定的值或者测试依赖的数据写入脚本当中。

使用统一的脚本语言
虽然一些自动化测试工具支持多种脚本语言，但在设计自动化测试脚本时应统一使用同一种语言，这样有利于测试人员与各利益相关方之间的交流。

尽量避免复杂控件的测试
复杂的控件测试难度高，易出错，会大大提高自动化测试的成本。所以，测试人员应当尽量避开复杂控件的测试，或者请求开发人员开发更多的测试接口，甚至更换控件。

遵循基本的测试流程开发自动化测试脚本
自动化测试脚本的开发最后也遵循测试的基本流程，比如，先定义预期的输出结果，再输入测试数据，执行测试步骤，将实际输出结果与预期的输出结果比较，记录比较结果，给出结论。

不要轻易地将检查某个错误的脚本注释掉
某些情况下，自动化测试发现的缺陷不能全部及时地修改，这时候的自动化测试会对其中为修复的缺陷给出同样的错误信息。需要注意的是，测试人员不能为了自动化测试流程不被这种情况中止就简单地将检查这个缺陷的脚本删除或注释掉，因为这样可能会使得这个缺陷被“遗忘”。

正确的做法是测试人员设计用来检查缺陷状态的脚本，当检查到缺陷是“已修复”状态时，就执行对应的自动化测试脚本，否则，不执行该脚本。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

如果你周围是一群鹰的话，那么你自己也会成为一只鹰；如果是在一群山雀中间的话，那么你就看不到海阔天空。

用快乐带动心情，用观念导航人生，用执着追求事业，用真诚对待朋友，用平淡对待磨难，用努力追求幸福，用感恩对待生活！

每当夜深人静的时候望着那灿烂的夜空我会感到那里充满了太多的梦想、告诉自己生命就象一场比赛、不争取就一定会失败！