自动化测试技术笔记 (二)：准备工作的切入点

上篇整理的技术笔记，聊了自动化测试的前期调研工作如何开展，最后一部分也提到了工作的优先级区分。

这篇文章，接上篇文章的内容，来聊聊自动化测试前期的准备工作，需要考虑哪些方面。

测试环境选择和搭建

自动化测试运行环境，不外乎测试环境(SIT)、验收环境(UAT)、灰度环境(PRE)和生产环境(PROD)。

在不同的环境运行的目的、效果、优势和不足也各不相同，下面是不同环境的区分对比结果。

不同环境对自动化测试开展的便利性和制约性不同，建议根据自动化测试的成熟度、要解决的问题来选择不同的环境。

当然，如果选择搭建单独的自动化测试环境，就要考虑环境资源申请、域名、代码仓库权限、维护成本等因素。

还有个很容易忽视的点就是服务器操作系统类型和版本，举个我当时遇到的例子：

要做 web 的 UI 自动化测试，工具选择了 selenium，我们常用的浏览器是 chrome，用户使用环境是 windows，自动化测试要求快速无感执行，就需要考虑 Linux 环境下基于 chrome 浏览器的 case 执行(chromium)，还要考虑 Linux 操作系统对 chrome 的适配问题（centos 和 uhuntu，以及 centos 的版本选择 6.5 还是 7.2），甚至还要考虑浏览器驱动的适配问题。

测试框架选型和设计

近几年成熟稳定的开源自动化测试工具和框架可选择的比较多了，但具体问题具体分析，测试框架的选型和设计同样是很重要的事情。在选择测试框架或者工具时，一般需要考虑如下几方面：

1. 自动化测试类型：UI/API/UNIT，UI 自动化要考虑 web 和移动端的区别，单元测试要考虑被测系统的开发语言；

2. 框架自身的生态：框架支持的编程语言、社区活跃度、文档是否齐全、业内落地案例、测试同学自身的技术栈；

3. 框架的学习成本：不能只考虑选择个人熟悉的，还要考虑后续的多人协同，团队其他同学的学习上手难度；

4. 框架的维护成本：后期 case 多了或业务场景变更后，case 的维护成本以及框架本身是否提供了更好的封装模块；

测试脚本和数据管理

测试脚本和测试数据管理，需要结合自动化测试的执行环境一起来看。

一般来说，测试脚本为了便于统一管理和多人协作维护，现在都是采用 Git+gitlab 的方式，做好版本管理和分支规范即可。

而测试数据的管理，相对来说比较复杂，可选的方式也不同。下面是常见的几种测试数据管理方式对比：

测试范围和校验粒度

标题所述的两点，其实是同一种问题。

测试范围的筛选，需要结合投入的资源，项目紧急程度来综合评估，一般测试范围的覆盖优先级，可以遵循这个顺序：核心业务——高频业务——问题较多的业务。

覆盖率的考量，可以遵循这个顺序：核心场景——核心业务流程——异常场景，如此覆盖后，再考虑逆向流程。

测试用例的粒度，可以参照功能测试用例的区分，从 P0 &冒烟 case 到 P1 再到 P2，以此类推。

当然，如果遇到比较复杂和亢长的流程，可以考虑拆分为多个测试用例，在同一个任务里按上下游关系去执行。

粒度的设定和拆分，在不同阶段有不同的划分。刚开始落地时，可以由粗到细，先实现再考虑不断优化。

持续集成和测试报告

自动化测试，如果无法做到持续集成快速验证，那就不能称之为自动化。

要做到将自动化测试，我个人认为有如下几个标识来判断：

1. 执行的频次和效率：比如 1 天可以执行 100 个功能 case，那自动化最起码要在 10 分钟甚至 1 分钟内完成；

2. 执行结果自动校验：功能测试可以人工来判断测试是否通过，自动化测试的通过率 &成功率需要达到一定的成功率(比如 90%以上)，且失败的 case 可以重试验证，或者失败的结果和日志及时通知给相关人员；

3. 无人值守自动运行：这点其实很多方法可以实现，比如定时任务，条件触发。当然做到这点还算不上自动化，必须考虑到如果出现重大问题还需要及时的发现和告警通知；

4. 是否融入交付流水线：交付流水线即我们今天常说的 CICD 或者 devops 流水线，常见的场景有服务打包编译后的自动化单元测试，服务自动发布后的接口自动化和 UI 自动化测试，以及服务上线前和上线后的自动化冒烟和回归测试，甚至还可以加入线上的日常自动化巡检。

外部调用和多人协作

以电商业务为例，支付需要调用三方，短信通知需要调用短信服务商，发货物流需要调用三方，但实际工作中三方提供的环境往往不满足我们的测试需要，这个时候就需要一定的手段来解决这个问题。常见的手段如下：

1. 挡板 &mock（最常用的手段）；

2. 流量染色+影子库（实现成本较大，技术复杂性较高）；

3. 和三方协商一致后配置专门的白名单或者渠道（很难协商）；

至于多人协作问题，其实涉及很多方面，比如：

1. 测试数据专人统一维护，还是按需维护，提供专门的工具或者流程规范约束；

2. 测试用例和测试脚本的维护，各管各的还是提供统一的规范 demo，专人检查或者定时 review；

3. 测试范围的边界如何界定，重合部分如何区分职责；

以上就是自动化测试落地前的准备工作，内容来源于我之前做自动化测试工作时的一些笔记内容，稍加提炼和修改。

下一篇我会聊聊自动化测试落地方案以及落地过程中常见的问题以及解决思路。