源宝导读：ERP是“业务密集”的大型复杂软件，而且对于业务逻辑与数据的精确度要求几乎是零容忍，其质量保障的挑战很大。本文将介绍ERP平台通过自动化测试保障质量的技术实践。

一、自动化测试概念介绍

测试金字塔原理

1.1、测试的成本

    UI自动化依赖于用户界面，用户界面发生变化，可能需要调整大量用例，用例维护成本较高；在用户界面的测试中发现缺陷，修复缺陷的成本也是远远高于通过单元测试的成本。单元测试不依赖于用户界面，维护成本较低；单元测试发现的缺陷可以尽早暴露缺陷，修复成本相对较低。

1.2、测试的效率

    UI自动化测试需要准备数据，需要可以看到系统界面，还需要预先执行一些诸如登陆账户之类的操作，才能对测试用例进行验证，所以花费时间比较长，得到的执行结果也比较慢，反馈周期长。而单元测试能很快地验证很小的功能或者方法是否运行正确。而且单元测试运行时间短，反馈也及时。

1.3、缺陷定位的难易

    单元测试如果失败了，测试人员很容易知道被测试的特定功能或者方法不正确。而如果是用户界面的缺陷，测试人员就需要花费更多的时间来进行排查，确定出现问题的功能模块，最后开发分析再进一步地发现需要修复的功能和方法。

总述：

• 越往上，越接近QA、业务/最终用户，越往下，越接近开发；

• 越往上，测试执行越慢，越往下，测试执行越快；

• 越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。

二、自动化测试如何做

    按照测试金字塔模型，我们得知越向下回报率越高，所以应该使用大量的单元测试和全面的接口测试来覆盖产品提供的基本逻辑和功能，使用少量的集成（UI）测试来进行前端界面的功能验证。

    业内最佳实践如Google，Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service）：占比20%；集成测试（UI）：占比10%。

概述：

• 单元测试：尽可能编写单元测试覆盖产品的功能逻辑，尽可能增加单元测试用例覆盖率；

• 接口测试：首先保证所有公开接口正常场景、异常场景均覆盖，再逐步覆盖产品私有的核心接口用例；

• UI自动化测试：减少重复操作，将固化的回归业务场景梳理，转化为UI自动化用例。

三、单元测试用例设计

3.1、基于方法说明编写单元测试用例

方法示例场景：参数省略

参数不省略：

参数取值场景：

参数类型不匹配场景：

3.2、基于测试业务角度

方法实现功能场景：

测试业务输入等价类划分：输入与之前相同值

测试业务输入等价类划分：空值

测试业务输入等价类划分：空格

测试业务输入等价类划分：首尾空格

测试业务输入等价类划分：较长内容（设置了最大长度）

还有其他场景划分的方法：

• 测试业务输入等价类划分：较长内容（未设置最大长度）；

• 测试业务输入等价类划分：特殊符号测试；

• 测试业务输入边界值分析：输入内容刚好等于最大长度；

• (测试业务输入边界值分析：输入内容比最大长度小1；

• 测试业务输入边界值分析：输入内容比最大长度大1；

• 测试业务分析：只读模式赋值。

3.3、基于开发代码编写单元测试用例

    单元测试关注的是代码的实现与逻辑。单元测试是最基本的测试，也是测试中的最小单元，它的对象是函数对象，也可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑。

单元测试的覆盖种类：

• 语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；

• 判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；

• 条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；

• 判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次；

• 条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次；

• 路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

代码示例：

null值测试：

undefined值测试：

tooltip测试：

四、UI自动化测试实践

4.1、测试数据准备

1. 测试数据库准备；

2. 数据脚本准备（如用户登录初始化脚本 ）；

3. 自动化环境初始化配置。

基本信息配置：

数据库信息配置：

登录用户配置 ：

4.2、测试用例页面规划

1. 规划要做UI自动化的页面：

2. 1. 梳理固化的回归业务场景；

   2. 规划纳入UI自动化的用例页面（对于平台 ，沉淀平台组件、控件、平台特性的用例页面）；

3. 根据选择页面录制自动化脚本。

4.3、编写测试用例

1、规划设置公共片段；

2、基于业务场景操作组合片断设计测试用例：

4.4、测试计划配置及执行

1、选择用例添加标签；

2、配置定时执行计划；

3、配置执行标签、不执行标签；

4、设置通知邮箱：

4.5、UI自动化与研发协同平台打通

• jenkins与云测平台关联：

• • jenkins配置HashCode、应用、项目名称、分支名称参数；

• 云测平台与Rdc关联：

• • 云测平台设置与Rdc项目、应用、分支名称一致（必须保证：云测平台、jenkins接口、RDC上三者一致）  ；

• Rdc触发自动化阈值控制：

• • 分支流水线测试通过时自动收集自动化结果，并判断自动化质量阈值。

五、关于TDD的学习与思考

5.1、什么是TDD

    测试驱动开发(TDD)是敏捷中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
    TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

5.2、TDD的目的

    TDD的目的不仅仅是测试软件产品，保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

5.3、哪些可以做TDD

    单元测试、接口测试可以使用TDD。

5.4、实施TDD需要什么

1. 接口、事件、方法文档输出（包括方法使用说明、方法参数、方法调用示例、方法返回结果）；

2. TDD流程规范；

3. 测试人员具备编码能力，可以分析功能逻辑编写测试代码；

4. 足够的时间。

5.5、TDD可用于目前项目么

1. 每次需求新增接口不多，接口文档输出较容易；

2. 接口测试相较于单元测试，对测试人员编码能力要求较低；

3. 设计接口测试用例时间上不会额外占据太多时间。

5.6、结论

    综合考虑成本、人员能力等因素，接口测试TDD可优先考虑在迭代中执行。

------ END ------

作者简介

邱同学： 测试工程师，目前负责ERP建模平台的测试工作。

也许您还想看

接口测试用例设计思路

使用MiddleMan进行接口自动化实践

研发协同平台持续集成实践

链路追踪在ERP系统中的应用实践