自动化工具 Web 自动化测试平台设计与落地-概览

阿羅 · June 25, 2017 · Last by YUE PENG replied at April 28, 2018 · 3843 hits
本帖已被设为精华帖!

引言

自动化金字塔-灵魂手绘版
关于Web自动化测试,投入产出比是一个绕不开的话题,对于走到2017年的测试人,这时候可能已经有很多人会想到著名的自动化测试金字塔。它形象地展示了Mike Cohn对自动化分层中各层所应该投入比重的看法,可以作为我们Web自动化实施策略的重要参考。

我最初开始接触Web自动化测试的时候,没有直接的领路人,测试行业知识也远不及如今这么丰富和易获取,当时我对于自动化测试的分层几乎没有什么了解,更不知道什么金字塔,就如很多同行一样,我一开始先入的是UI自动化的坑,那时候我还没有养成搜索英文资料的习惯,关于Selenuim2、WebDriver的中文信息还相当有限,国内主流还在Selenuim1, 先熟悉API,熟悉元素定位方式,进行一些简单的封装,到后来的PageObject,干劲十足。

不过在UI自动化这个阶段的后期,我已经对自动化测试有了更多的认识,加上工作变动,开始跳接口自动化的坑,通过工作经历、朋友和网络,对现状有了一定的了解,大约2015年的时候,心里隐约有一些想法,我们的测试对象的架构从最简单的三层架构,到分布式架构,再到SOA,到微服务,一路向前,而再看我们测试人对Web系统接口自动化的实现方式,直接使用如 Postman这样成熟工具的先不谈,就自研框架而言,有用Java的,如Junit/TestNG + Ant( + Jenkins + JMeter + xxx),有用Python的,比如基于广为人知的RobotFramework,有用Ruby的,可能基于BDD界耳熟能详的Cucumber,等等,技术栈可能各有不同,本质上,大多是孤立的工程 + 文件形式管理的数据和用例。

可能四五年前,我看到的,大多是这样的方案,到今天,测试从业者的数量大幅度增长,有良好代码能力的并且能将其用到测试工作中的也越来越多,然而我看到的,这些的方案仍然占大多数,除开国内几家顶尖的互联网企业,就我所了解的以及网络上能搜索到的,尝试将方案走到简单Web系统的形式,用数据库存储数据,在线管理自动化实施的,很少。就这些方案本身,我觉得只要能达到自己团队的目的,都是很好的,没有优劣之分,我在意的是,我看到的变化低于预期很多,新的尝试低于预期很多,我觉得很多新的尝试,对于现在的测试人来说,难度并不会比以前的方案高多少,所需要的时间成本,也并不会高出多少,我希望我们测试人在做自动化实施的时候,能够像做业务测试一样,能够不局限于某一个方向。

既然看到的尝试很少,那我就想自己去做一做,慢慢形成一些思路,到2016年,公司原有的自动化方案不能支撑一些新产品的需求,开始投入精力去设计和实现一个Web类型的测试平台,当时感觉就像当年刚开始自主实施UI自动化一样,有一股劲。设计选型、编码、首版服务端上线、第一个团队开始使用、首版UI上线、1.6、2.0、...在功能方面来说,算是做出了勉强接近自己预期的系统(如果不考虑那拙劣UI的话)。 平台明面上是我单独完成的,但实际上,同行大牛对思路的肯定、工作安排上的支持、业务线伙伴的需求,都是不可或缺的。本来今年年就计划写关于这部分的文章,但由于今年工作、生活上都很忙,这半年几乎没有一个周末有自己独立的时间,加上拖延症作祟,所以直到今天才总算开始码了。

虽然并不确定这次计划输出的内容对读者能有多少帮助,但还是计划分几篇来写,当然具体能输出几篇现在我也没底,拖延症是个强敌,所以决定第一篇先做一个总览

这期的引言太长了点,抱歉。希望本文能为有耐心读到这里的人带来些许价值

一、目标和定位

首选需要说明的是,由于近年的工作重心主要在Web服务端,同时根据团队当前的工作情况,定的自动化策略是优先实施接口层而非UI层,所以平台当前的主要功能是围绕HTTP层的自动化测试展开的。

平台的定位是作为公司各业务线服务端的自动化公共平台,目标是通过快速落地自动化测试来支撑公司各产品组提高测试效率。

二、平台特点

最基本的特点,平台是一个前后端分离的Web服务、由数据库管理基本信息和测试用例、在线查看测试报告。详细一点的话,我认为通过对比的方式来呈现可能比较明了。这里以引言中提到的实施方案与本文所述的测试平台进行对比。

对比项 业界常见项目 本文平台
定位 支撑某一产品线的接口自动化需求 支撑各产品线的多种自动化需求
适用性 适用于特定Web系统接口的自动化 适用于不同产品、不同设计理念接口的自动化
基础架构 独立的工程,基于文件管理数据 前后端分离的Web服务,基于数据库管理数据
落地方式 本地搭建运行环境,获取工程并运行以调试新用例 在线UI操作,开放接口便于CI集成
数据管理 通过更新/上传文件的形式管理用例 在线创建/更新用例,使用MySQL管理数据
运行方式 通过编辑Jenkins job/Crontab等实现运行计划管理 在线自定义运行时间计划和运行内容
结果校验 校验粒度较粗,数据库校验可能在代码中 基于Json解析的细粒度校验,在线管理数据库校验
历史数据 历史数据缺乏有效管理 在线查看历史运行记录和测试报告

三、系统架构

整个平台的大体系统架构如下图,其中产品数据库交互主要是数据预置/清理/校验
平台系统架构

四、相关技术栈

应用 技术/工具
Web服务基础框架 Spring Boot
Web容器 Jetty
持久层框架 MyBatis
HTTP调用和校验基础框架 REST-assured
用例调度执行 TestNG
HTML报告 Allure
平台接口信息 Swagger
基础UI组件 Bootstrap
前后端交互 AJAX(Jquery)
在线代码编辑 Ace

关于在线代码编辑,主要提供给有基础代码能力的同学应用在复杂场景的自动化实施,普通的接口自动化需求不需要。后续文章会做更多的说明。

五、UI概览

基础信息管理
基础信息管理
用例管理
用例管理
在线场景编辑
在线场景编辑
定时计划管理
定时计划管理
用例调试
用例调试
在线报告
在线报告
邮件样例
邮件样例

六、待完善部分

平台目前有两个较大的功能欠缺:

  • 账户体系和权限控制
  • 代码动态编译运行的安全控制(沙箱)

账户体系和权限控制目前没有实现,主要是时间成本的问题,考虑目前平台都是公司内部各测试组使用,暂时没有特别强的需求。至于动态编译运行的安全问题,主要是难度和时间成本两方面的原因,对于这个安全问题,目前我自己还没有一个周全的解决方案,另一方面,作为内网运行的平台,安全需求相对较低,欢迎提出宝贵意见。

共收到 33 条回复 时间 点赞

赞一个,是否有开源计划?

以前也写过一个这种类似的平台,不过后面没有用起来! 当时 过于侧重测试用例的管理,而不关注 用例编写的灵活性,导致用例编写和维护困难!

我们现在的自动化就是无码,db管理

阿羅 #4 · June 26, 2017 作者
孟德 回复

嗯,难的从来不是coding。
我也经历过自己做的东西远没有达到自己预期的情况。我觉得要做这类平台,首先自己要对业务测试本身有相当的了解,然后,公司产品比较多的,需要进行一些归类和分析,每个类型的系统至少熟悉一个产品的业务特性和系统设计风格,这对做出一个能顺利落地的平台是很重要的,因为这些将影响首版的设计,如果首版不能成功落地,不管是对使用者还是对自己,都有很消极的影响。
我自己来说,对公司多数产品业务都有一定了解,系统的接口设计风格也都比较清楚,请求、返回、身份验证这些细节等等,最初设计的时候就会考虑如何适用于各种不同设计风格,需要考虑在表现层进行一些针对性的设计来增强易用性,最终做出来的平台目前算是顺利落地了,有的用来做对外接口的自动化,有的用来做业务冒烟,也有纯后端平台的同学用来做业务测试。中间也有一些不满足需求的地方,这种时候我会尽量快速响应,并收集一些他们的想法。

首先不得不说设计的很强大。
有几处没看懂的,我感觉在实际应该过程中,有很多不确定性,以下场景也比较多
1,参数化怎么处理的,录入的接口case的入参是固定的么?
2,入参没有加密,出参解密的情况么?都是是明文传输和校验的?
3,上下文关联的接口怎么处理的?只是单个接口的检查么?
4,校验的部分只能是已经知道结果的前提下对比?

阿羅 #6 · June 26, 2017 作者
白纸 回复

平台后端代码本身倒是基于github管理的,平台的多数功能,也具备通用性,但一来对于身份认证部分,各公司肯定会有所不同,而来这是一个系统,而不是一个基础框架,之前设计的时候没有考虑开源方面的事情,所以算是没有开源计划。有时间的话后面会拿一些关键逻辑放到后续文章。

阿羅 #7 · June 26, 2017 作者
Baozhida 回复

嗯,都是些很实际的问题,比如入参是否固定,我们公司有团队之前的自动化框架就是固定参数,因为他们当时的目的只是测试产品对外的接口,这些接口的参数都是固定的几个K-V,比如timestamp,method,data等等。下面就对你的四个问题说一些我的思路。

问题1

首先目前平台上的业务接口来自于多个不同类型的产品,case入参各有不同,并不是固定的。其次是平台用例接受的入参也没有限定。可以从最后一节的第二张截图看到,我在平台把入参分为了三种类型:
- Path参数-如果产品API遵循RESTful风格,就很容易见到如/user/{id}这样的操作特定资源的形式,这里的id就归为Path参数;
- Form参数-就是场景的表单/K-V键值对,这不管是遵循RESTful风格还是随意的风格,都非常场景,一些简单的业务基本这样的简单参数就满足需求了;
- Body参数-放在request body中传输的内容,通常是Json串,一些比较复杂的业务,参数结构比较复杂,可能需要这样的形式。path参数、form参数都不限制数量,只要按规则填写让平台可以解析即可(这和一些开放平台如淘宝开放平台接受可选参数的方式是类似的,用一个字符串来接受用户按规则填写的不定数量的K/V,后台按规则解析。),Body本身是直接接受一个字符串,不存在参数数量的问题。

问题2

目前公司线上是全站HTTPS,所以数据传输没有再做别的加密。所以目前平台没有做加解密方面的特性,不过这个问题不大,先了解自己产品的加密传输过程,做的时候用例里面还是明文写入参和其他要素,后台用一个基础服务来算摘要、加解密这些,应该没有特别大的障碍。

问题3

上下文关联接口,这恐怕是多数解决方案都比较头疼的问题,要尽量简单易用,然而又想尽可能的满足更多更复杂的需求。可以从两方面看:

  1. 分析当前阶段有没有必要,如果是比较纯粹的接口测试,就应该尽量单独对每个接口进行测试,优秀的接口设计也应该能适应这样的测试,那这时候有数据需求,就考虑预置数据来解决,我这边的设计是通过填写直接的SQL语句支持数据预置和清理,就放在用例的setUp和tearDown里面,支持多条SQL语句,目前平台上有个产品就是这样来实现所有用例独立的,这在实施的时候需要对数据进行一些必要的规划,可能需要一些思考,但不管是怎样的自动化方案,要做好数据预置,必然需要进行规划的。

  2. 如果业务特殊,接口间依赖确实难以解除,或者数据预置的成本太大,或者本来的需求就是做一些业务流程冒烟测试,我在平台给出的解决办法是,自己用代码在线自由组装任何场景。

    可能看到这里有同学会想到,看,还是要写代码。我也很无奈啊,像这种需要多个接口组合,要从前一个接口获取预先不确定的值传给下一个接口的复杂用例,如果非要通过设计来实现无代码,以我的经验和见识,需要投入太多,而且设计出来的仍然有这样那样的条条框框,既然是要解决复杂场景,就是想要应对尽可能多的,所以最终我选了现在这样的设计。

    但这里的自己用代码,其实只是实现一个接口,像写脚本一样写一些简单的结构化代码就可以应对99%的场景测试,一般就是点条件判断,最多加点循环,数据库操作都已经封装好了,只要传SQL语句作入参即可,请求组装,HTTP调用,响应数据获取,响应体的Json解析,都是现成的,编译也是平台运行时动态编译的,小伙伴只要照着样例就写出源码即可,甚至一些常用的包,也在抽象类里面引入了,在线写的代码里面只有个别不常用的包需要自己引入,这个水平在公司每个组都有能胜任的。这个特性在平台培训的时候确实需要多做一些说明,但也仅此而已,现在平台上做业务流程冒烟自动化的产品,就是用这个特性来做的,只要协助小伙伴实现一两个场景,后续基本就能自己解决了。

问题4

就我这边的设计来说,对于常规的接口自动化用例,确实是需要预先知道用例的确切预期结果,包括数据库校验,也是需要给出明确的条件。
而就前面提到的通过在线代码实现的场景测试,则可以在部分场景下实现不需要提前知道结果,最典型的就是一些查询接口,比如平台上有个产品一个业务查询消费明细、查询账单金额等case,就没有考虑预置数据,而是用例执行时先从数据库查到结果,然后和接口返回的结果进行对比,用例设计这不需要预先知道每次执行时,实际的金额。

一下写的有点多,总之目前我的实现,只到这个程度。

其实没必要考虑面面俱到,每个公司的产品都有自己的特性! 考虑大而全,就会导致操作体验变的比较糟糕!
我待过几个公司,做安全的、做电信业务的、做移动互联网的、做手机的 ,每一种做自动化的方式都是不一样的!
这个平台 跟我一起做电信业务时做的接口测试平台比较类似!
主要做单接口的 参数校验,采用数据驱动的方式!
这样就挺好的了!
👍

我现在做移动互联网服务端接口测试,多要很多接口进行串联走业务流;
我这边暂时是用robotframework ,行为驱动的方式来写用例的!
做数据驱动就比较勉强!

#7楼 @wal_bx 挺好,我自己这边也在写你这样的平台,这种平台是不完全适合强业务模型的接口组合测试,适合单个接口的健壮稳定性测试,建议楼主可以在数据初始化和销毁加上redis和memcach操作,因为很多产品单纯处理mysql不够的

—— 来自TesterHome官方 安卓客户端

阿羅 #10 · July 01, 2017 作者
飞狐 回复

嗯,缓存方面的处理现在没有做,因为还没有实际需求,目前的几个产品线虽然都有缓存,但是在当前的自动化用例里面还没有设计。谢谢提醒,我先考虑一下,一遍后续有实际需求来了能更好的解决。
强业务的接口组合测试,应该是很多接口自动化实施过程中难以良好解决的问题,我做的尝试是放在在线代码编辑这部分来处理的,就是页面上提交一个继承指定抽象类的代码,自己在里面组织业务场景的各个步骤,用例运行时动态编译,前面漏了这部分的截图,在UI概览补上了

有开源吗

@wal_bx 您好 能说下用testng跑用例 怎样能做到类似封装一个testng方法,然后每个用例都调用这个方法运行就好,我现在都是一个用例 写一个testng方法,这样写用例都花大量的时间。
希望能解答下 谢谢

阿羅 #13 · July 10, 2017 作者
erinet 回复

嗯,这里有个前提,就是你的用例可以抽象出相同的逻辑,如果每个用例的逻辑差别很大,那为每个逻辑写单独的代码是很难避免的。
不过即使你不能为所有用例抽象出同一个逻辑,那抽象出几类逻辑应该是可以的,这样的话,抽象出几个逻辑,就对应几个test类。

我用的解决方案:TestNG的Factory + DataProvider。
本文的平台主要是做接口层面的测试,可以抽象出相同逻辑,比如:前置:数据库数据准备 + 用例:准备参数-调用接口获取响应-响应校验 + 后置:数据库数据清理,每个步骤都做了封装,所以只要用TetNG的这两个特性做数据驱动就可以实现只需要一个tsetcase类。最后在用例组织的时候,借助XmlSuite/XmlTest等类以Programatically的方式构造当次的执行计划(也就是构造临时的testng.xml)。

Factory + DataProvider中文英文资料都有,在内存里构造testng.xml这个也是有资料的,你搜一下吧。下面是我的一个testcase类的简化版,去掉了一些无关的信息,以供参考。

public class APITestNGCase extends DefaultTestClass {
private static final Logger logger = LoggerFactory.getLogger(APITestNGCase.class);
//整个过程所需的参数较多,所以对入参进行了封装
private TestCaseDataEntity entity;

public APITestNGCase(TestCaseDataEntity entity) {
super(entity.getCaseName(), entity.getCaseOrder());
this.entity = entity;
}

@BeforeMethod
public void setUp() {
if (isNotBlank(entity.getDbSetUp())) {
TestCaseConditionProcess.getInstance().setUp(entity.getDbSetUp(), entity.getJdbcTemp(), entity.getTranTemp());
}
logger.info("Testcase : {} beforeMethod completed ", this.caseName);
}

@Test
public void IntegrationTest() {
//参数准备-调用接口-获取响应
Response response = RestExecutor.getResponse(RestExecutor.init(params),entity.getApiDomain(), entity.getApiPath(), entity.getHttpMethod() );
//响应校验
RestExecutor.validate(response, entity.getStatusCode(), entity.getValidationPaths(), entity.getValidationTypes(),
entity.getExpectedValues());
//数据库校验
if (isNotBlank(entity.getDbCheck())) {
TestCaseConditionProcess.getInstance().checkFromDb(entity.getDbCheck(), entity.getJdbcTemp());
}
}

@AfterMethod(alwaysRun = true)
public void tearDown() {

if (isNotBlank(entity.getDbTearDown())) {
TestCaseConditionProcess.getInstance().tearDown(entity.getDbTearDown(), entity.getJdbcTemp(), entity.getTranTemp());
}
logger.info("Testcase : {}, afterMethod completed ", this.caseName);
}

}

大神,开源吗,购买也行

@airsen 有兴趣聊聊接口自动化平台么?

阿羅 #16 · July 21, 2017 作者
阿森 回复

最近刚被公司提醒了,属于公司项目,不要私自传播😂 ,已经从github撤下来了。大概可以聊聊设计和思路

嚯嚯 回复

当然有,现正在开发中,咱们可以交流下,我qq:154077341

能问下,你的前端所要执行的用例数据,是怎样传递给 testNG的呢????

阿羅 #19 · July 29, 2017 作者
阿森 回复

可以参考我#13楼层的回复,从数据库把当次要执行的用例数据全部捞上来之后,运用TestNG的Factory + DataProvider,然后用TestNG所支持的在内存中构建虚拟的testng.xml,最后用如下方式执行:

TestNG tng = new TestNG();
tng.setXmlSuites((List<XmlSuite>) suites);
tng.run();

总体来说都是运用TestNG自己已有的特性,可以从TestNG官网去了解这些特性

真正最大的缺陷是作者意识不到的缺陷。
测试用例版在web上编写就是最大缺陷。

希望你这个平台不要像我这里的一个前人做的平台一样,编辑一个测试用例服务器竟然要发给我1万4千行的html。为啥这么多行,因为长年累月往case里加东西,本来很简单的网页变成一大坨s。

我们这还有一个缺陷就是因为用例放在web上,没有了版本控制。别人基于文件系统的测试数据放在git上各个版本随便切来切去。我们的存在数据库里压根没办法拿到以前某个指定版本。要是不小心把case删了就没咯。

我们还有一个缺陷就是没办法调试。就因为case放在网页和数据库上,每次改动要调试一下都蛋疼。你敢集成一个ide进网页吗,做不到的话如何调试。当然如果你的平台只测最简单的业务逻辑,写case不需要调试都能一次成功的话就当我没说吧。

我们这里的这种web平台最致命的缺陷就是他的代码原作者跑路了。留下一大堆本身没有单元测试没有接口测试的web代码。现在交给一个基本改不了多少东西的组维护着。自己改不了,也不愿意让别人来改造,变成一堆越来越硬的s。

祝楼主好运吧,别变成我们这里这种垃圾测试平台。另外你说的理念其实很多年前就有很多人实现了。但就我这里看来,还不如纯代码的测试框架。那些还相对来说容易与时俱进一点。

阿羅 回复

用TestNG所支持的在内存中构建虚拟的testng.xml,你是说他可以支持生成动态的 testng.xml文件吗?

阿羅 #22 · July 31, 2017 作者
ting 回复

非常感谢,都是很实际的问题,我并没有做好。

版本问题

这可能是个隐患,我先想想,感谢。 平台设计时没有考虑,目前平台运行近一年,暂时没有遇到这方面的需求,所以并没有相关的处理。

前端的问题

还没有遇到。我不清楚对于从HTTP层进行的测试,case里添加什么东西需要不断的添加前端代码,平台除了新增功能有添加新的页面外,原有页面基本只进行过文案优化和添加几个函数进行易用性优化。
我认为一个系统需要有成体系的设计,它并不能一成不变就满足新增的需求,但是能够以较小的去实现。同时一个系统要有自己的边界,确定自己真正要做的是什么,不管是业务范围、还是UI/UE,特别是在资源有限的情况下,更是如此。我本身前端水平很初级,所以尽量考虑怎么简单,中间也考虑过一些感觉更好用更酷炫的特性,非要做也能做出来,最终还是放弃了,不然或许就向你说的这种情况发展了。

调试的问题

平台并没有完全解决,不过没有成为日常使用中的阻碍。
- 就接口测试来说,基本还没问题,平台有提供在线调试用例,会将用例所调接口的完整响应格式化展示在界面上,给出用例定义的校验项的结论。如果接口根本不通,会有相应的反馈,那就需要自己去排查原因了。
- 而在业务场景测试这里,确实没有完全在线解决。因为一个业务场景可能包括很多次业务调用,还涉及一些逻辑判断,调试的需求比接口测试多很多,我这里也只是如果报错,界面展示报错信息,后台日志记录完整调用过程,因为本身是内部平台,所以这种折中办法基本能处理。另外因为是HTTP层的测试,业务场景里面基本也是业务调用,数据库操作,简单逻辑控制等,范围相对清晰,调试问题还不太严重。

最后这个问题

哈哈哈,这个问题确实很常见,我的做法是尽量保持简单,以及开放和分享,效果并不确定

阿羅 回复

加油吧,不要被困难吓倒。版本控制我帮我们这里的人平台想的办法是让他开放建case和改case的接口。然后我再以某种形式把case描述在python文件里甚至txt文件,这一大堆文件就能放git上了。

呵呵,然而我们这的工具开发不愿意别人插手他们的工具。

@wal_bx 你好 请教你个问题
File in = new File("tmp/results");
File out = new File("tmp/html");
AllureReportGenerator allureReportGenerator = new AllureReportGenerator(in);
allureReportGenerator.generate(out);
这段代码只生成 index.html 、data、plugins三个文件,跟手工运行命令行生成报告比起来 缺少了很多文件。
请问是什么原因呢?

阿羅 回复

@wal_bx 想问一下

运用TestNG的Factory + DataProvider,然后用TestNG所支持的在内存中构建虚拟的testng.xml,最后用如下方式执行:

TestNG tng = new TestNG();
tng.setXmlSuites((List) suites);
tng.run();

这个你是怎么用的呢,我看你的平台里有个“运行”按钮,是说从前台点了这个运行按钮,然后就调用到server端的某个方法来执行

TestNG tng = new TestNG();
tng.setXmlSuites((List) suites);
tng.run();
这块吗? 如果不是,能大概说说,通过前端点运行按钮后,怎么启动的testng来运行,并执行用例的吗?谢谢!!

26Floor has been deleted

期待大神能回复一下

恒温 将本帖设为了精华贴 13 Sep 09:11
王先生 回复

抱歉,最近比较忙,没有及时看到。
前端的“执行”是通过http调用了后端执行测试任务的接口,将接口名称、用例名称、测试环境名称作为入参。
测试任务执行接口后面的业务逻辑,大概有一下几步:

  1. 首先后端已经把接口签名、接口入参组装、接口调用、接口响应获取和解析、数据校验,都封装好了,在一个自定义的继承ITest的testcase类里面,将数据作为testcase的入参,将数据预置放在@BeforeMethod,签名、调用、校验放在@Test,数据清理放在@AfterMethod,只要有相应的数据,就可以完成测试.(在上面13楼有这个testcase类的样例)
  2. 根据入参中的接口名称得到被测接口方法名,根据入参中的用例名称得到该用例调被测接口时的入参、预期结果和校验方式等信息,根据环境名称得到接口中心域名,这些是一条用例里面要调接口所需要的数据。如果是批量执行,则得到一个数据集合
  3. 将前面得到的数据,用TestNG的Factory + DataProvider,生成一个在内存中存在的虚拟testng.xml,传给testng,然后调用run()方法,就开始真正执行用例了
  4. 然后生成报告,可以自己选择,最后返回结果,就用响应的tesgng监听器即可,我这里只用了TestListenerAdapter,然后要在接口返回简单的测试结果数据的话,就从TestListenerAdapter拿,比如获取失败用例数tla.getFailedTests().size()。把这些数据作为点击“执行”之后的响应返回,这样前端有反馈,而且方便在CI中使用。也就是一次测试任务执行后,有两类结果,一是html形式的测试报告,二是接口返回里面的简要执行结果数据

最后总结一下,整个过程分为数据获取、用例集组装、接口调用和校验、生成报告、执行结果数据反馈。这里每一步都是独立封装

erinet 回复

因为最关键的是data,其他都是已经写好不变的,每次报告的不同,就只有data,报告页面是根据data来展示的,所以你看到的手工生成报告的其他文件,都是可以公用的,如果要每次独立报告, 最简单粗暴的做法就是每次新建一个文件夹,把固定的部分复制到文件夹,然后把本次的data放进来,就是一份新的报告

阿羅 回复

谢谢指点

ting 回复

我还是比较赞同这个观点,web化的测试平台很多时候会作茧自缚,无数的个性化需求很容易把它压垮,而且框架如何长时间维护也是一个大问题。既然对测试人员的基本要求都是能coding了,直接代码化编写不是更合适吗。

我们也做了一款和你这个差不多的工具,界面什么的几乎一样。。。。。

Author only
白纸 回复

同问😂

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 13 Dec 20:49
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up