前言

又到年底了。今年的工作内容和往年没有太大的变化，产品有条不紊地 2-4 周一个周期的迭代，在需求评审、设计评审、测试执行、问题跟进、客户支持之间团团转。
唯一一个基本上全年在持续做的，是在空闲时间开发了一个内部使用的测试平台，和不断地维护、更新。
之前把这个平台分享过一次（https://testerhome.com/topics/15534 ），有些朋友使用后会问里面的设计和运行逻辑，这里简单记录一下吧。

与自动化测试的那些年

初识自动化-QTP

08 年毕业开始第一份工作时，团队里已经使用 QTP（当时最主流的自动化测试工具）维护了很大规模的自动化测试用例。
不过不巧的是，我入职这家公司时，正好遇上几个时间点：

• 08 年次贷危机，公司主打北美小型贷款业务的产品线（占公司 70% 收入）直接被砍。测试团队包括老大在内的十来人陆续离职，最后包括刚转正的我在内只剩两人。
• 另一个产品正好经历一次大规模的 UI 升级，原来的 QTP 用例基本无法执行，需要花费大量时间进行升级维护。

所以原来花了大力气搭建的 QTP 框架和用例系统，直接被废弃了。只有在空余时间自学了一下简单的 QTP 使用技巧，没有在项目中实践。

自动化实践 - vs code ui test

大约过了两年后，部门调整过来以为新的主管，在产品测试流程稳定下来之后，开始调研和推动重启自动化测试。
经过对原有的 QTP 框架分析后，最终选择了 visual studio 的 code ui test 组件来实施自动化测试。原因如下：

• 产品是使用 c# 开发的，visual studio 的 code ui test 也是使用 c# 编写脚本，正好是研发过来的主管所熟悉的体系。
• 测试框架和产品开发采用同样的体系，可以进行更好的融合。

确定工具和框架后，由于主管对测试体系进行了一些思维碰撞和讨论，最终确定了一些自动化测试准则：

• 自动化测试用例从功能测试用例而来。将功能测试用例按优先级分为 P1-P5，自动化测试先覆盖 P1 级别，待推广稳定后再根据决定是否扩大范围。
• 用例原子性：用例之间不产生耦合。确保每个用例都能独立执行。
• 用例重复性：用例的关键数据随机生成，确保每次执行都能产生相同的结果。
• 环境配置化：将环境地址、登录用户/密码等信息用配置文件的方式进行管理，实现在不同环境间均可执行。
• 数据恢复与初始化：测试执行前进行数据恢复，测试完成后进行数据清理。
• 用例模块化设计：每个功能模块的用例需先进行设计，内部评审通过后才进行具体用例实现。

定下框架和流程后，很快把相关的用例建立了起来，而且运行效果很不错。
顺便简单介绍一下 visual studio code ui test 组件，它有一个特点是用一组信息（id、name 等）来标记一个元素，如果某个属性无法定位，会尝试使用其他属性来定位元素。

偏好关键字驱动 - 入坑 selenium

13 年入职一家以开源技术为主导的软件外包公司。由于公司理念是使用开源技术，于是开始入坑研究 selenium。
在对比了当时流行的 java+selenium+ant（当时部门同事做过类似的分享）框架搭建自动化后，开始寻找不同的思路。 在调研不同的框架后，找到了一个用 python 编写的关键字驱动、Excel 组织用例的开源框架（没错，就是前几天被人怒怼的 “毒瘤” 型框架）

对于这个框架，当时看上它的以下几个点：

• 关键字封装。将通用的一些方法封装成对应的关键字。其实总结一下，一个项目里通用的自动化操作来来回回也就是点击、填写、验证、截图等步骤，而且项目由于是使用同一个技术框架进行开发，所以这些操作的通用性非常高。所以用关键字封装的方式非常高效。
• Excel 管理用例，用例管理简单轻便。 在外包公司工作，临时性地短期项目是常态，因此用 Excel 编写一批简单的冒烟测试用例非常方便，也适用于在客户现场临时找一台机器安装使用。
• 关键字驱动，步骤简单清晰。 只要对你的用例步骤设计地清楚，写用例非常方便，只是一个格式转换；而且一般用例就是增删改查，通用性很强，把 A 模块的几条用例复制成 B 模块，简单修改一下里面的关键元素即可，所以上手后很短时间内就可以把几个基础模块的用例写好，不用占用太多的项目测试时间。

于是开始在自己负责的项目里尝试使用，并根据需求不断增加新的关键字封装。也是为了基于这套源码二次开发自己所需要的功能，才开始学习和接触 python，开始啃相关的方法：读写 Excel、格式转换、多线程并发、环境配置，等等。

一条路走到黑 - 将简单框架扩展为一个平台

入职现在这家公司，开始做长期的产品迭代开发和维护。继续使用这套框架做自动化。由于使用场景的变化，遇到以下问题：

• 由于涉及到团队合作，Excel 管理用例的方式受到很大制约。
• 测试报告较为简单。
• 执行依赖于自己的 PC 机，无法作为固定环境进行使用。

改造方式：

• 将用例改为到数据库中读写和保存。
• 用例编写、维护需要通过界面来维护。于是最终决定搭建一个测试平台。
• 用 docker + selenium 的方式作为用例运行载体，拜托对 PC 机的依赖。
• 由于已经编写了不少的用例，且一直在使用，因此沿用原有的用例格式。

改造过程：

1. 设计对应的数据库表。

• 用例管理： 分为 test_case(原始测试用例)、test_suite(测试用例集) 、test_batch(测试用例执行记录) 三个表管理用例。达到的目的：一条用例可以在多个不同用例集中执行；一个用例集可以根据需求选择合适的测试用例。
• 关键字管理： test_keyword ，用以管理对应的关键字封装，将关键字和具体的封装方法、参数列表进行映射。

2. 平台搭建和页面开发。

• 使用 flask 搭建平台。
• 基于 flask - bootstrap 编写对应的页面： 用例管理（增删改查）、用例集管理（增删改查、用例关联、执行记录和报告）、关键字管理（增删改查）

3. 测试执行核心代码改造

• 启动一个主进程 coreservice， 定时查询数据库中是否有待执行状态的用例（页面中点击执行某条用例或某个用例集，会将对应 test_batch 记录修改为待执行状态）。如有，则开始执行。
• 读取对应的测试用例列表，将对应 test_batch id 以多进程方式并发分配执行。
• 每条用例执行时，读取对应的用例，并逐步转换为对应的封装方法进行执行，直至步骤全部执行完成。
• 用例执行完成后，将对应执行状态、失败步骤、截图等信息保存到数据库。
• 具体任务执行，会使用 selenium remote 的方式在已启动的 docker 容器内的 selenium server 进行分配执行。
• 报告生成和邮件通知。 用例执行完成后，自动发送测试报告。

因为改造方向很明确，所以开发比较顺利，很快将一整套框架开发搭建完成。

后续优化

随着这个平台稳定运行，逐步把一些测试相关的功能也集成进来：

• android 自动化测试集成。开始选用的是 macaca ，后来改为 atx 。 采取相同的用例结构和关键字格式。
• 接口测试框架集成。
• 集成百度脑图的 kityminder 框架，以思维导图的格式管理测试点。