ERP平台的自动化测试技术实践【小白看不懂系列！】

• 📢 我是小濠，一个快要秃头的测试人

• 📢 欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！

• 📢 我收集了一些软件测试资料，关注我公众号：程序员小濠，免费领取！

• 📢送给大家一句话，世界的美丽，来源于你的努力

前言                                         

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

一、自动化测试概念介绍

测试金字塔原理

1.1、测试的成本

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

1.2、测试的效率

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

1.3、缺陷定位的难易

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

总述：

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

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

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

二、自动化测试如何做

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

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

概述：

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

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

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

三、单元测试用例设计

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