如何设计自动化测试 case？

本文是自动化测试系列的第三篇文章。

前面两篇文章聊了自动化测试在团队中落地的必要性和注意事项，这篇我想聊聊设计自动化测试 case 的一些实践和观点。

为什么要设计 case？

无论是功能测试还是自动化测试甚至性能测试，设计测试 case 都是必须的。

当然，不同的测试类型，在设计测试 case 时候的侧重点和颗粒度是不同的。

设计测试 case 的目的，我个人认为主要有如下几点原因：

便于测试活动开展

测试工作的本质是尽可能以更高的效率保障交付产出物的质量满足甚至超出预期，这是所有测试工作的最终目标。

但在实际的工作实践中，绝大多数的测试工作都是围绕测试 case 来开展。比如：case 评审/冒烟测试/提测检查/case 执行/bug 提交/bug 跟踪和修复验证，直至最终线上发布。

确保业务场景覆盖

软件测试工作，简单来说就是通过设计各种场景并进行检查，确保交付的软件符合预期设计结果。

无论是功能测试采用的等价类边界值方法，还是自动化测试分层的概念，都是希望通过一定的方法和手段，尽可能的保障业务场景覆盖，避免遗漏所导致的问题逃逸到线上，影响最终交付产出物的质量。

质量度量和质量内建

无论是质量度量还是近几年业内所提倡的质量内建，其实都和测试 case 息息相关。

在前面的文章《聊聊我对质量度量的看法》中我提到过，质量度量分为三个阶段，分别是：

1. 需求设计质量；

2. 研发过程质量；

3. 用户使用质量；

而测试 case 是研发过程质量中很重要的组成部分，或者可以理解为测试 case 是研发过程阶段各项测试工作开展的核心。

测试 case 具备“粒度最小+耗时最久”的特点，我们常说的通过各种测试技术手段多维度去验证软件是否符合预期，都是验证和保障交付质量的手段。而流程规范、度量标准，也是为了保障最终的交付物达标。

如何设计测试 case？

按照分层测试理念，金字塔模型中，越是向下，投入/产出比就越高，但开展的难易程度/成本和技术要求就越高。

聊到如何设计自动化测试 case，这里我并不会就着某些细节去拼命挖掘，而是分为 UI 自动化/API 自动化/UNIT 自动化各自展开来阐述我的一些思路和想法。

UI 自动化

UI 层是用户使用产品的入口，所有功能通过这一层提供给用户，功能测试工作大多集中在这一层。

如上图所示，要开展 UI 自动化，在设计 case 时候要针对性评估和筛选适合的业务场景，当然在实际工作实践中，不可能完全满足上述条件。一般来说只要满足如下几点，就可以开展 UI 自动化测试：

1、需求稳定，不会频繁变更

UI 自动化测试最大的挑战就是需求和 UI 频繁变化，脚本需要修改、扩展去适应新的改动，如果频繁修改会导致投入产出比太低，那么 UI 自动化测试也失去了其价值和意义。折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分手动回归。

2、多平台运行，组合遍历型、大量的重复任务

测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值。

3、软件维护周期长，有生命力

UI 自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了。

4、被测系统 UI 设计较为规范，可测试性强

主要出于这几点考虑：被测试系统 UI 差异、测试工具适应性、测试人员能力能否快速上手并落地；

API 自动化

从测试分层金字塔模型来说，API 自动化测试是综合性价比最高的一种测试手段。在设计 case 时可遵循如下顺序：

1. 明确要开展 API 自动化测试的业务范围；

2. 针对业务范围内的接口，区分优先级(一般都是先覆盖 P0/P1)；

3. 梳理接口对应的业务场景(优先保障正向的业务场景覆盖，如下单是正向，取消订单是逆向)；

4. 明确接口对应的数据类型(包含哪些字段/对应数据库的表字段/必填非必填/验签鉴权特殊账号权限等)；

5. 准备测试数据，接口调试通畅(先确保单接口单场景的覆盖，再考虑复杂场景的各种依赖和业务链路串联)；

6. 自动化执行起来，边执行边观察效果，不断优化(切忌大而全的过度设计)；

UNIT 自动化

单元测试(unit testing)，是指对软件中的最小可测试单元进行检查验证，最初都是由开发来完成，即保障自己所在环节的交付产出物满足进入下一阶段的标准。

关于单元测试，我的观点是测试需要介入这个环节，尽可能早的去测试验证发现问题，但并不表示测试需要在这个环节什么都自己来做。在设计单元测试 case 和执行方面，可以考虑如下几点：

1. QA 和 DEV 针对单元测试 case 级别达成共识；

2. QA 和 DEV 在单元测试环节进行合作共建和职责边界划分；

3. QA 提供用例，DEV 进行实现；

4. QA 提供的用例需要经过评审并通过；

5. QA 进行 Check 和校验(度量维度和评估指标与开发达成一致)；

6. 设定优先级，从 P0 核心模块开始实现；

7. 覆盖范围以 service 核心模块，新增功能优先；

8. 在 code review 阶段，对单元测试实现情况进行检查；

9. 需要通过实施前后不同维度的比较度量来评估能否带来收益；

10. 数据度量：覆盖率、通过率；

11. 发现 bug 数：线上问题、线下发现的 block bug；

12. 度量粒度：小到最底层函数级别，大到代码类方法；

13. 测试用例：单元测试的实现和度量，一定是 case by case 的；

更多内容，大家可以参考我前面的文章《测试需要做单元测试吗？》。

设计 case 要注意什么？

由简到难，适可而止

不同维度的自动化测试 case 设计和实施，都是覆盖范围越大/粒度越小，投入成本越大，这是个边际递减的问题。

现在很多企业都提倡研发效能和快速迭代，这种时候就不能慢工出细活了，要考虑如何以更小的投入和更快的速度完成核心场景覆盖，达到快速验证的目的，不要太过于追求所谓的覆盖率和 case 数量等度量指标。

切记不要面向质量度量和 KPI 搞自动化测试，这样容易捡了芝麻丢了西瓜。

可观察，可验证，可度量

在设计自动化测试 case 时还应注意这三点：

1. 可观察：case 执行过程需要能够直观的进行观测，比如抛异常或数据写入变更；

2. 可验证：自动化 case 的结果是否符合预期，一定要通过断言或其他验证方式进行确认；

3. 可度量：自动化执行的结果要可度量（不要面向质量度量搞自动化，但没有度量的自动化测试没有意义）；