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

贴上宝藏资源:
https://gitee.com/itestwork/itest.git

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

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

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

有点慢。。。玩了一会。

收到，感谢建议

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

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

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

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

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

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

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

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

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

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

吹啥呢，系统 bug 太多

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

有 BUG ，欢迎提出来

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

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

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

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

有问题很正常。这个版本到现在最新版本之间又发布了 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 自动化的功能，对这个工具还是比较期待后续的发展的。

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

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

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

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

https://www.oschina.net/news/131849/itest-9-0-3-released 9.0.3 又来了，

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

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

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

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

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

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

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

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

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

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

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

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

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

登录用户名和密码多少，想登录学习一下；也没看注册入口

线上登录页下面有帐户密码，可能您上次登录时，发新版，马这注掉了 ，现在是 OK