最近正在学习关键字驱动的自动化测试框架模式。什么是关键字驱动？Kimi Chat给出的定义是：“关键字驱动的自动化测试框架是一种设计模式，用于简化和加速自动化测试的创建和执行。这种框架的核心思想是将测试用例的逻辑与具体的代码实现分离，使得非技术背景的测试人员也能够参与到自动化测试脚本的编写和维护中来。”实现这种设计模式的方法就是封装关键字。怎么做关键字封装的？基于我个人的经验，我认为关键字驱动的自动化测试框架可以有三种层次的封装：
第一层次：封装单步用户操作
用户常见的单步操作有：点击、输入、清除、滚动页面等等。把这些操作可以封装成一个个方法。以下是使用Selenium Python实现的代码：
这里封装了三种方法：点击、输入和滚动。封装的基本逻辑就是用显示等待定位到元素之后再执行操作。(注意，此处用try...except来捕获异常。我觉得写代码时捕获异常是一个好习惯。这里可以把print换成记录日志，这样在每次操作出错后方便查看日志排错，而不是面对控制台一大堆Python原生报错信息无处入手。)
第二层次：封装对于单个组件的操作
公司里的前端开发往往不是自己去定义每个HTML元素，而是套用成熟的前端框架封装好的各种组件。比如ElementUI就提供了大量现成的封装好的控件。具体可以参考：https://element.eleme.cn/#/zh-CN/component/installation
于是我就在想，Web自动化测试是否也能这样进行组件层面的关键字封装？就是把对于单个Web组件的操作封装成一个类。比如一下展示了对于ElementUI的对话框Dialog的操作的封装：
selenium对于原生js的alert弹窗有专门的操作：通过driver.switch_to.alert定位，然后有accept和dismiss方法，但是对于这种ElementUI组件库中提供的弹窗组件就没有这样便捷的操作了。那么我们可以试着自己这样封装一下。这样的好处是，如果我们测试的系统中有多个模块会出现类似的弹窗，那么就都可以复用这个组件的操作类了。
第三层封装：封装单步业务操作
更进一步的，我们的业务系统中如果有大量重复的业务操作，比如增删改查，那么我们是不是也可以做到单个业务操作的封装？
比如：对于列表中单条数据的删除操作，可以细分为对于两个组件的操作：
1）点击删除按钮
2）定位到对于用户进行提示的弹窗，点击“确定”
我们可以把这两步骤操作封装成一个delete方法。
需要注意的是，封装关键字不能为了“封装”而“封装”。“封装”只是为了屏蔽不重要的细节，复用重复的代码，让自动化测试用例编写变得简单易读。但不是所有情况都适合封装。比如某个业务操作的步骤多且复杂，或者某个组件的在业务系统中使用频率极低，那就没有做封装的必要了。
