Lego

2023-08-05 09:30| 来源: 网络整理| 查看: 265

一、概述1.1 接口自动化概述

众所周知，接口自动化测试有着如下特点：

低投入，高产出。比较容易实现自动化。和UI自动化测试相比更加稳定。

如何做好一个接口自动化测试项目呢？

我认为，一个“好的”自动化测试项目，需要从“时间”、“人力”、“收益”这三个方面出发，做好“取舍”。

不能由于被测系统发生一些变更，就导致花费了几个小时的自动化脚本无法执行。同时，我们需要看到“收益”，不能为了总想看到100%的成功，而少做或者不做校验，但是校验多了维护成本一定会增多，可能每天都需要进行大量的维护。

所以做好这三个方面的平衡并不容易，经常能看到做自动化的同学，做到最后就本末倒置了。

1.2 提高ROI

想要提高ROI（Return On Investment，投资回报率），我们必须从两方面入手：

减少投入成本。增加使用率。针对“减少投入成本”

我们需要做到：

减少工具开发的成本。尽可能的减少开发工具的时间、工具维护的时间，尽可能使用公司已有的，或是业界成熟的工具或组件。减少用例录入成本。简化测试用例录入的成本，尽可能多的提示，如果可以，开发一些批量生成测试用例的工具。减少用例维护成本。减少用例维护成本，尽量只用在页面上做简单的输入即可完成维护动作，而不是进行大量的代码操作。减少用例优化成本。当团队做用例优化时，可以通过一些统计数据，进行有针对性、有目的性的用例优化。针对“增加使用率”

我们需要做到：

手工也能用。不只是进行接口自动化测试，也可以完全用在手工测试上。人人能用。每一个需要使用测试的人，包括一些非技术人员都可以使用。当工具用。将一些接口用例当成工具使用，比如“生成订单”工具，“查找表单数据”工具。每天测试。进行每日构建测试。开发的在构建之后也能触发测试。开发将被测系统构建后，能自动触发接口自动化测试脚本，进行测试。

所以，我这边开发了Lego接口测试平台，来实现我对自动测试想法的一些实践。先简单浏览一下网站，了解一下大概是个什么样的工具。

用例维护页面

自动化用例列表

在线执行结果

用例数量统计

1.3 Lego的组成

Lego接口测试解决方案是由两部分组成的，一个就是刚刚看到的“网站”，另一个部分就是“脚本”。

下面就开始进行“脚本设计”部分的介绍。

二、脚本设计2.1 Lego的做法

Lego接口自动化测试脚本部分，使用很常见的Jenkins+TestNG的结构。

Jenkins+TestNG的结构

相信看到这样的模型并不陌生，因为很多的测试都是这样的组成方式。

将自动化测试用例存储至MySQL数据库中，做成比较常见的“数据驱动”做法。

很多团队也是使用这样的结构来进行接口自动化，沿用的话，那在以后的“推广”中，学习和迁移成本低都会比较低。

2.2 测试脚本

首先来简单看一下目前的脚本代码：

public class TestPigeon { String sql; int team_id = -1; @Parameters({"sql", "team_id"}) @BeforeClass() public void beforeClass(String sql, int team_id) { this.sql = sql; this.team_id = team_id; ResultRecorder.cleanInfo(); } /** * XML中的SQL决定了执行什么用例, 执行多少条用例, SQL的搜索结果为需要测试的测试用例 */ @DataProvider(name = "testData") private Iterator getData() throws SQLException, ClassNotFoundException { return new DataProvider_forDB(TestConfig.DB_IP, TestConfig.DB_PORT, TestConfig.DB_BASE_NAME,TestConfig.DB_USERNAME, TestConfig.DB_PASSWORD, sql); } @Test(dataProvider = "testData") public void test(Map data) { new ExecPigeonTest().execTestCase(data, false); } @AfterMethod public void afterMethod(ITestResult result, Object[] objs) {...} @AfterClass public void consoleLog() {...} }

测试脚本结构

有一种做法我一直不提倡，就是把测试用例直接写在Java文件中。这样做会带来很多问题：修改测试用例需要改动大量的代码；代码也不便于交接给其他同学，因为每个人都有自己的编码风格和用例设计风格，这样交接，最后都会变成由下一个同学全部推翻重写一遍；如果测试平台更换，无法做用例数据的迁移，只能手动的一条条重新输入。

所以“测试数据”与“脚本”分离是非常有必要的。

网上很多的范例是使用的Excel进行的数据驱动，我这里为什么改用MySQL而不使用Excel了呢？

在公司，我们的脚本和代码都是提交至公司的Git代码仓库，如果使用Excel……很显然不方便日常经常修改测试用例的情况。使用MySQL数据库就没有这样的烦恼了，由于数据与脚本的分离，只需对数据进行修改即可，脚本每次会在数据库中读取最新的用例数据进行测试。同时，还可以防止一些操作代码时的误操作。

这里再附上一段我自己写的DataProvider_forDB方法，方便其他同学使用在自己的脚本上：

import java.sql.*; import java.util.HashMap; import java.util.Iterator; import java.util.Map; /** * 数据源数据库 * * @author yongda.chen */ public class DataProvider_forDB implements Iterator { ResultSet rs; ResultSetMetaData rd; public DataProvider_forDB(String ip, String port, String baseName, String userName, String password, String sql) throws ClassNotFoundException, SQLException { Class.forName("com.mysql.jdbc.Driver"); String url = String.format("jdbc:mysql://%s:%s/%s", ip, port, baseName); Connection conn = DriverManager.getConnection(url, userName, password); Statement createStatement = conn.createStatement(); rs = createStatement.executeQuery(sql); rd = rs.getMetaData(); } @Override public boolean hasNext() { boolean flag = false; try { flag = rs.next(); } catch (SQLException e) { e.printStackTrace(); } return flag; } @Override public Object[] next() { Map data = new HashMap(); try { for (int i = 1; i 大于等于：>=小于：

【本文地址】

公司简介

联系我们