研发效能 itestwork(爱测试) 开源一站式接口测试&敏捷测试工作站 9.0.0 GA 发布,重大升级

5itest · 2021年02月04日 · 最后由 5itest 回复于 2021年03月04日 · 2429 次阅读

(一) itest 简介

itest work (爱测试) 一站式工作站让测试变得简单、敏捷。itest work 包含极简的任务管理,测试管理,缺陷管理,测试环境管理,接口测试,接口 Mock 6 合 1,又有丰富的统计分析。可按测试包分配测试用例执行,也可建测试迭代 (含任务,测试包,BUG,接口) 来组织测试工作,也有测试环境管理,还有很常用的测试度量;对于发版频繁,需求常变,itest 还可导出用例,线下修改、执行,新增后再导入(同步)到线上;且可根据测试策略来设置测试流程,并可实时调整;在测试看板中,能查看迭代报告,测试包执行情况,测试任务进展,也可以在看板上直接执行用包用例,也支持在线 web 思维导图写用例。

官网 http://www.itest.work
在线体验 1 http://www.itest.work/demo
在线体验 2 http://120.78.0.137/demo
v9.0.0Ga 下载地址 :itest 下载

二:9.0.0 Ga Release 说明
继 1 月 12 发版后,不到半月 9.0.0 又来了,用户的持续反馈是我们不断更动力! 年后发布新一版源码,之前的是 2.5 的 。
9.0.0 Ga ui 按商业化软件的标准重写,交互和体验更友好,“好用、好看,好敏捷” ,是我们追求的目标。logo 也更新为 itestwork ,更符合我们定位。

截止 9.0.0 接口测试,已包含接口 mock ,接口加密,解密和签名,接口参数化,接口间动态参数传寄,接口依赖推导,建测试测试场景时,自动加入依赖的接口并按依赖关系排好执行顺序,拖拽生成断言,拖拽提取参数 。在此也预告一下后续要支持的功能:支持 swagger 导入,实现 web 化 jmeter 压测(己在实现的路上),下面先欣赏一下新 UI ,再来看升级详情


9.0.0 Ga 详情如下:
增强:
1: 适配大屏 3840 分辨率(3840 时右键菜单太小,下拉列表拆行,按钮间距太密,切换项目下拉列表拆行,显示的页面,下半部空起很多等)
2: 接口依赖关系拓补图样式优化
3: 手工功能测试用例增加标签视图显示模式

bug 修复:

1:迭代下提交 BUG 时选不了测试需求项

2:项目列表中,修改项目基本信息时,又创建了一个新项目

四:接口测试及新特性截图


为结省时间,不在新 UI 中 一载图了,直接用老版本 U I 示意


呱唧 1800 次混沌测试完成了

执行测试场景时,先执行正向用例,如 check 混沌开关,正向执行完后执行接口混沌测试

接口数据参数化





下面是上图以数化在执行时打印出来的值

参数化且应用了加密算法后打 印出来的值

按接口参数依赖关系 推导出来的接口依赖,建测试场景时,自动加入所依赖的接口,并按依赖关系排好执行顺序

这是 mock 的一个接口,josn 数据是加密了的,

第一次测试这接口没加解密算法

响应是密文

第一次测试这接口解密算法
维护好解密算法

之前的接口中选这个解密

再测试,接口的结果解密了

mock 支持上图 4 种延时

五:功能概览

(一) 功能模型

引导图上蓝色文字是热点,可以点击,方便引导上手

(二)接口测试 功能概览:

基本流程: (1) BaseUrl 设置------>(2) 基础认证设置 ----->(3)接口安全设置------>(4)维护接口用例----->(5)拖拽生成接口断言------> (6) 建接口测试场景 (可在迭代中直接增加)--->(7) 手动执行接口测试场景 (可单个,也可一键执行场景中所有接口) 或定时执行测试场景。另外还有接口 mock

1:全局设置

3:接口按全设置

维护好接口的加密,解密及签名 ,上传相关类或 JAR ,在接口用例中选维护好的加密,解密及签名,供 itest 执行接口测试时来回调 ,

4:接口用例维护

接口参数维护,非常方便 ,对测试人员友好,复杂 json 支持 xxx.xx.xx 这种面向对像的形式写

5:拖拽式断言设置
不用再写 jsonpath ,把响应结果解析为 tree ,然后拖拽想要的节点,设置操作符及值,可以拖任意多个

6:接口场景
可以手动一键执行,也可以设置定时任务自动执行

在场景中可单个,也可一键执行所有接口用例,,缺省执行顺是按依赖关系来排的 ,也可手动调整执行顺序

9:接口 mock

(三) 产品截图及其他功能概览

可线下离线处理测试用例,再同步到线上,
在项目中可以从用例库或是 EXCEL 呀是 xmind 中导入用例,且在导入时,如需求项,用例分类,优先级,以及用例标签 ,如系统中不存在,会自动在导入时建立


除了可同步线下执行,还支持多种导入,在用例 BUG 统计示图中,测试需求分解对上,每个模块上显示 BUG 数和用例数

可按测试包分配测试任务,通过把多个测试包加到测试迭代中,统计测试执行情况

在迭代中 直接建测试包, 方便一气呵成分配测试任务,且可快捷分配测试用例到用例包中,还可在迭代测试包 TAB 中,二次分配测试包中,测试用例  

执行测试用例包用例

Q

可在工作空间里,呆以填写任务进度,执行测试用例包,或是处理流转到名下的 BUG,或是进入迭代执行任务里

流程驱动测试
流程驱动缺陷在 26 种状态中演化,更精准反正工作实况
测试流程引擎自动推算可演化状态及流转到谁名下,且可实时调整流程

从 BUG 的邮件通知中连 BUG 链接,可能直接处理 BUG

在收到的 BUG 邮件中,带一个连接,一点就自动登录 ITEST,同时,弹出邮件中的 BUG 处理界面

多维度测试度量
趋势分析洞察研发过程潜在风险,为项目管控提供决策依据
结果数据分析掌控团队效率,为持续改进提供量化数据支持
测试总揽,测试经理每日工作复盘好帮手,量化的测试日报



测试人员简报: 里面有测试人员写用例情况,执行用例情况,提交的 BUG 数,提交的 BUG 按

状态按人分布,提交的 BUG 按类型按人分布,提交的 BUG 按等级按人分布,且可按不同版本作

为条件进行分析



开发人员处得 BUG 简报 : 有开发人员 BUG 数统计, 也有按 bug 状态按人分布,按 bug 等级按人分布,

按 bug 类型按人分布,按人按 BUG 龄期分布 (龄期可按天也可按周计),且可按不同版本作为条件进行分析





测试环境维护

共收到 41 条回复 时间 点赞

仔细看了下,跟现在流行的各种测试工具别具一格,竟然开源,测试人的福音啊,对上不仅承接项目管理的角色,对内测试,每个功能都是测试实际面临的短板的补充, 接口链路关系图/脑图用例对接口测试是一大创新,相信测试工具盛行的大环境下,这绝对是测试人自己开发的工具才能赋能测试行业的转型发展,💫 ✨ 🎆 🎇 🎇 🎆

bug 度量分析是我见过最专业,最全面,最符合质量管理的视角统计的,再看看禅道.bugfree 这种传统测试工具,都想抛弃了,省去了测试经理主管很大一部分精力去把控测试过程指标 ✨

好庞大的接口测试平台,竟然开源,大佬 NB

很大很全很牛比,一看就是积累了很久的平台,有几点建议:
1、代码看起来很久远了,考虑重构一下切到 springboot 上来,可以简化用户部署
2、前端 UI 设计略粗糙,建议换个 blingbling 的框架
3、demo 里面的字典定义太过于个性化,不同维度的概念混淆到一起,既然是开源么,建议参考 testlink 的默认定义
4、度量分析,建议按照业务目标/价值或者用户角色为导向做一下分类,都挤在一起很难区分

槽神 回复

有点慢。。。玩了一会。

槽神 回复

收到,感谢建议

恒温 回复

今天访问量有点大,还有开源中国过来的,带宽临时加了,其他资源最是最低配置,一直有人在下载,所以慢,

槽神 回复

昨天我们团队,一条一条分析了您的建议,非常感谢提这么好,中肯又很有建设性的建议,我们照单全收。打算先实现 2,4 条,然后再实现,3,1 条。再次对您的建议表示感谢!!!

总结就是很好很优秀,很适合测试敏捷化转型的团队使用。看板,用例管理,bug 管理,接口管理,环境管理,一应俱全。最重要的是还有一些趋势分析和相关报表统计。希望 itest 越做越好~

怎么添加加密算法,我看目前只有一种

5itest #12 · 2021年02月10日 Author
Liuyxwant 回复

不明白你说的一种是什么意思!可以是 JAVA 源文件,也可以是 编译好的 JAR 包, 本质上是 itest work 来回调你的实现 ,在线 demo 我们只是放了一个上,你可以在你本地安装的环境上,你任意上传你的实现。接口用例管理中可选择的加密,解密,签名算法,是来源于这里维护的数据,最终实现接口测试代码和加密,解密,签名算法分离 。
可以上传 jar ,jar 里是编译好的 class 文件,如果加密,解密,签名实现依赖第三方包,可能用这方式,把你的实现类的 class 和第三方包的 class 合同一个 jar(如有多个 jar 合同一个 )。如下图所示

对比了几个开源的平台,这个对测试的工作基本都做了覆盖,尤其是度量分析这块的功能非常强大。之前用的是 jira,虽然 jira 提供了 JQL 帮助统计,但是比较麻烦,itest 的统计维度基本能初步度量测试和研发工作了。希望后面集成 sonar、代码覆盖率、性能等多维度的测试

5itest #14 · 2021年02月17日 Author
lee 回复

目前在实现压测 ,web 化 jmeter , 这个完成后,集成 cd /ci, 接下来就是 sonar qube 等

对比了很多工具,感觉这款很好很强大,项目相关的功能都有一步到位。关键迭代很快持续更新,虽然还有一些问题,但是有一个团队在维护。我们还需要犹豫吗?选它就对了。准备部署团队内部使用了。

观察了好久,也体验了一段时间,功能太强大了,站在测试人员的角度开发出了我们最需要的工具,而且功能优化速度惊人,感谢大佬的团队,用起来就完事了

功能这么复杂导致 bug 好多啊

吹啥呢,系统 bug 太多

5itest #19 · 2021年02月22日 Author
ZOO 回复

有 BUG 正常,不过你说 BUG 太多,这个表示不认同, 200 家在用呢,早上系统刚更新为 9.0.2 RC1

5itest #20 · 2021年02月22日 Author
ZOO 回复

有 BUG ,欢迎提出来

5itest 回复

bug 真的很多,我主要用的接口测试这块,随便加了几个出现了 4-5 个严重 bug,尤其是复制,保存等,保存完接排到第一个去了,还有接口排序填数字这操作太魔幻,建议改成拖拽方式

5itest #22 · 2021年02月26日 Author
ZOO 回复

感谢反馈,接口复制,保存一直正常呀,
接口测试还在快速迭代中,不过基本能用,其他功能很稳定,再有两周,接口测试这块,也稳定了,正在实现,插件,支持采样器插件,前置处理插件,后置处理插件,断言也增加 正则,等。

9.0. 2 Rc2 己发布,修复了如下 6 个 BUG :
1: 修复 JMX 导入,端口号前冒号,导入后变为斜杠的问题
2: 修复 postman 导入时,如文件中有多个 item 嵌套时,导入不了的问题
3: 修复 postman 导入时 如果没有 description 时,参数没导入进来的问题
4: 修复在 head 中引用参数,但是在接口日志中记录时,没存实际值,存的还是变量名的问题
5:修复接口依赖拓补中,如果接口提取的参数,被其他接口在 head 中引用了,在我的被依赖中不显示依赖关系的问题
6:修复接口测试合并参数时,丢了参数的 BUG

5itest #23 · 2021年02月26日 Author
ZOO 回复

再次感谢您的反馈,有两个问题,我想确认一下
1:保存完接排到第一个去了,这个我要说明一下,如果是在接口用列表中,最新更新的在前面,如果在接口测试场景中,一键重排执顺 序是按接口依赖关来排的,如手工改了顺序,以你改的为准。
2:还有接口排序填数字这操作太魔幻,建议改成拖拽方式;在测试场景中,我们按接口依赖排自动排序,要调整时,可手工填,比拖更方便,接口少拖 OK ,接口多,一个接口在底部要拖到顶部,也费事,这时手填更直接

ZOO 回复

有问题很正常。这个版本到现在最新版本之间又发布了 7 个版本了。我随便拷贝一个版本的版本变更说明吧。几乎一周 2 个版本,有问题几乎第二天就解决了,比商业软件还快。有什么不放心的呢?

9.0.2 Ga
增强优化:
1:用例在原有普通视图,统计视图,标签视图三个视图功能后再加增加了一个脑图视图,整个项项目的用例显示为脑图
2: 脑图模式维护用例时,切换文件时,如没保存,给出提示
3:服图用例显示优化,更扁平化,且用过,不能过,阻塞,未测试和和根节点的前景色做调整
4: 新建迭代时,项目下拉列表,显示优化
5: 新建项目进,下下拉列表,显示优化
6: 支持查询的下拉,禁回车事件
7: 项目简报,下钻到人显示优化
8: 脑图用例维护,给根节点加子节点时 ,新节点和根节点,摆放位置重叠
9: 脑图用例维 支持在不同脑图文件间,脑图分枝复制和粘帖

10:新建项目选项目 PM 的下拉列表,改为支持查询的组件
11:工作空间里,待确认的 BUG 放在进行中泳道上;关闭/遗留" 和 "关闭/撤销"放终止泳道;上
"挂起/下版本修改" , "待改/下版本修改" 和"挂起/不计划修改" 放暂停泳道上

BUG
1:为某个测试需求一并维护 kloc 和功能点数时, 刷新页面积后,只成功提交了一个

2: 脑图维护用例时,显示的叶子节点,显示的背景色,和保存后,再切换到这个脑图时的背景色不一样
3: 修改因菜单配置错误,导致不能给角色授用户组权限的问题

这个工具最开始是只有项目管理、测试用例管理和 bug 管理以及出报告,度量的管理工具。接口测试是最近 2 个月才加的功能,而且迅速做大做完善。我是差不多最早开始体验的那批用户了,对比了很多工具,这个工具是目前为止最适合的。我随便说几个细节的功能,是很多现有的测试工具所不具备的:
1、直接导入思维导图,生成用例(可以把测试设计的思路先生成用例,再慢慢完善用例步骤),不需要从 0 开始写用例。
2、可以拖拽生成断言,不用考虑语法和方法
3、直接支持 jmter 接口等工具直接导入(只能支持最基本的单接口用例导入,场景用例和关联的还不支持)
4、支持 LDAP 统一登录,不用单独再维护一套用户管理
5、用例和用例之间有变量依赖,可以直接生成接口依赖拓扑图
6、混沌测试,接口里各种字段(设了变量的),可以自己定规则,进行批量发送,确认接口的健壮性

据说后续还会支持压测和 UI 自动化的功能,对这个工具还是比较期待后续的发展的。

twf 回复

修改问题值得鼓励,但是做测试管理平台相当于一个小型开发项目,功能越加越多,修改也越来越多,一定会有很多逻辑上或者功能上的缺陷,这样的测试管理平台不一定功能越多越好,人力不足的话抓住几个核心功能点做完善就可以了,又不是商业软件追求大而全。

1、作为产品不在细分市场寻求突破,追求全面,就有可能因为某一项赶不上别家而被全盘放弃。
2、太多的度量指标,给人的感觉是产品方自己在测试领域没有沉淀,所以就把能透出的指标都透出来,让用户自己进行选择。
3、某些概念没有采用通用标准来描述,比如缺陷状态的已改未确认,非错未确认,不太明白开发者是不知道怎么描述还是刻意寻求差异化。
4、敏捷测试管理那张图逻辑性也有待商榷,参考https://www.cnblogs.com/linkxu1989/p/6673087.html,不是说老外总结得就一定好,但现有的这张图说服不了我个人。

5itest #28 · 2021年03月04日 Author
ZOO 回复

感谢建言,人力我们不是问题。我们定位就是要做一个一站式的且免费的可以和同类商业软件 一拼高下的,我说了不算,时间能证明一切,目前在实现,接口测试 采样器插件,前 后置插件,以及断言可以选择操作对像如 http head ,http 响应码,http 响应体,且支持 xpath ,正则,截取,和 jsonpath ,提取参数也同断言一样,压测也在测试中了。我们团队人多,基本上周周有版本,所以不担心人力不足的问题。再等等两周,9.5.0 出来,欢迎再提意见

5itest #29 · 2021年03月04日 Author
MarvinWu 回复

感谢建议,关于 您说的第一项,某一项赶不上不怕,我们能实现,一直快速按用户反馈在迭代,时间证明一切;第 2 项,现在没来能分,能做来,还能分不出来? ;第 3 项我认为不能过于教条,比如说的已改未确认 ,非错未确认 ,我们不是过于追求差异化,就是更真切的反应 BUG 状态,非错未确认表明,开发设置了非错,测试还没处理,他处理时,可以是撤销,说明他同意这是个非错,不同意时,他设置为分歧后到仲裁人那里,这有什么不好? 关于第 4 条,我们从没想说服谁,只要说服我们自己,我们按排这个来打造就完事。 任何产品都会存在争议,这正常,想再多,不如真实干出来,出错不错,有用户反馈,我们现在为什么发版这么快,就是不断有人反馈 。目前我们就是撸起袖子加油干,干就完了, 不完美也不怕,我们改进 。

5itest #31 · 2021年03月04日 Author
MarvinWu 回复

第 2 项,"现在没来能分" 我是说,现在没来及分 上面打错了

5itest #32 · 2021年03月04日 Author
MarvinWu 回复

对了我们还有已改,以及已改/同步到测试环境,存在即合理有些小公司,开发改后,直接更新环境,加这个 已改/同步到测试环境,方便测试人员验证, itest BUG 状诚,不仅是想表达当前的状态,还想表达,在流程中走到哪了。itest BUG 状态是多,我们是想精化化,且不影响使用体验,我们状态是根据设置的 BUG 处理流程来的,当前是什么状态,能演化为什么状态,全是我们控制,用户只用下拉选 。比如有分配流 程 测试人员提交的 BUG 就是分配状态,没有分配流程就是待改,如有分析流程,还有其他状态。 这要看个人,肯定有反对,也有支持,我的目的是做好测试管控,不要太教条

5itest 回复

感觉你的回复暴露了更多的测试管理方面的问题,缺陷常见状态就下面这些,目前看足够覆盖所有的业务场景。

已改未确认跟已修复或者已解决有什么区别?非错未确认跟已拒绝又有什么区别?
换个表述意味着客户得重新接受一次概念,这里的风险产品经理要不要考虑?
已改/同步到测试环境这状态是想解决什么问题,测试工作产出不是针对指定版本、指定环境吗,这样是不是带来测试管理的混乱。
最后说下那张图的毛病,
1、测试任务与项目测试是通过什么维度并列展示在一起的
2、项目研发下面为什么放的是测试任务
3、如果说每一栏最上面一行想表示项目生命周期的各个阶段,缺陷跟踪怎么又和测试执行并列了
4、需求部分为什么不在敏捷测试的测试迭代里
5、需求管理下面怎么列的是维护测试模块?

5itest #34 · 2021年03月04日 Author
MarvinWu 回复

已拒绝,这个远远不够,根本没表达出,不是 BUG,还是是 BUG 但不改;不管是不是问题,每个产品不可能所有人满意,只要我们的用户满意就行。欢迎讨论,我们认可的肯定改,不认可的肯定不改 。你问到了这个图,那我放上我的功能模型,

5itest #35 · 2021年03月04日 Author
MarvinWu 回复

关在 BUG 状态,你说的对我来说,不够用,不精细;itest 中有 遗留 状 态 说明是 BUG 但不改,当然要填原因 ;还有一种 BUG 是 BUG 但当前版本不改,Itest 是待改/下版本修改, 要变为这状态,开发要设置为不改/下版本修改,经仲裁人同意后,才变为 待改/下版本修改. 请问你的这些状态,能表达这意思吗? 作为一个管理人员,我就是需要更精细的装态,而不是笼统的状态;如 BUG 重复了,itest 中有重复,开发设置为重复时要关联所重的 BUG 。我还是这观点,我更的这几种太粗,虽然好多都是这样,我做精细,有什么不好

5itest #36 · 2021年03月04日 Author
MarvinWu 回复

5、需求管理下面怎么列的是维护测试模块? 不要把测试需求,等价于产品需求,

5itest #37 · 2021年03月04日 Author
MarvinWu 回复


没法打字一一回复你,再加一个我们的概念模板图,教条,死扣理论这是不行的,解决测试管理过程中的问题就 OK

创业不易,我也无意泼冷水。
至于拒绝缺陷,tapd 的处理方式是这样:

支持根据解决方法检索或统计缺陷。
中间还有哪些想抽取出来拆成不同的状态呢?
新改的那张图上还是有很明显的 bug,为了产品形象建议再看看。
最后的建议是想清楚到底是管理敏捷开发过程还是只管测试,目标用户是哪一类,他们的痛点在哪,现在定义的流程适合他们吗。

5itest #39 · 2021年03月04日 Author
MarvinWu 回复

拨冷水不怕! 也没人规定,只能在解决方中写这些,我认为不直观,直接在状态中体现更好,都是做跟屁虫没用。
聊天天感 觉对牛弹琴,为什么这么说,
麻烦看看
定位就是测试,没看就高高在上说教! 我们也不是创业,就是觉得没一个我看来好用测试平台,所以我们就做 ,仅此而己

5itest #40 · 2021年03月04日 Author
MarvinWu 回复

我们是欢迎反馈的,但是这种高高在上的说教 ,不是反馈;有人说 itest work 是狗屎我都能按受,这种一派说教,没劲呀,太自以为事,有 BUG,有不足可以改,这姿态 只能呵呵

5itest #41 · 2021年03月04日 Author

关于 B UG 状态 麻烦理解流程驱再来说,itest 又不是,让你下拉选 N 多状态,ITEST 按流程控制的,根据流程和当前状 态控制下一步可以演化,这一点不增加使用上的麻烦,这有什么不可以, 这是更精细化的管理 BU G 状态 ,又不带来体验,我就喜欢这样子,死板的教条,一切拿来主言就是对的吗,这是仁者见仁,智者见智的问题 .。相反写到解决方案中,一点不直观

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册