我自己做的是
1、xmind 测试用例直接上传禅道
2、开了个服务，联动企业微信机器人进行定时任务通知设置
3、禅道 bug，测试报告数据统计总结
还有一个，github 搜索 jcci，这个代码变动分析工具

评价自己：钱到位，血管干碎
不足：钱不够，动力不足

老哥，关注你了，期待后续分享

有二开禅道的经验，其实是可以实现的。页面请求的 html 请求，尾缀.html 改成 .json 就是一个接口了。

有没有可能，转化成功之后，确认数据无误，直接自动上传禅道。
这个是我最近再构思的新功能， 我们项目也用这个转化的，挺长一段时间了，每次都需要手动上传，还是有点麻烦

老哥，能方便交个好友吗?有问题想请教一下

笑死，我们团队自从量化 bug 数量，以前一个问题如接口返回报文字段缺失，就报一个 bug。现在演化成了缺了多少个字段就报多少个 bug

我入门技术，可以获得一份分工吗

@ 白开水 pp #6 大佬已现身 ，直接问问

有大佬：https://testerhome.com/topics/39516
github:https://github.com/baikaishuipp
初步实践过，很强，可以直接找出影响了具体的接口

我们是分工的时候就交叉了，让你测不同模块的。

我认为你说的这种方式会更加合理一些，会比我们现在的策略更加合理。我们只是单纯的采用了交叉，没有采用其他配套的方式：指定负责人，用例重视及完善的呢个等

1、交叉测试适用场景，我也认为应该是功能比较稳定的时候才适用的场景。而我们现在是功能场景还在不断迭代的时候，就已经开始进行这种测试方式了。
2、目前我们对测试用例的重视程度不够，没有内审，只有项目评审，项目评审的作用也没有被发挥出来。 属于是交叉测试学了样子，没学到里子

感谢回复~
我再次返回头来理解，checkList 为梳理测试点， 测试用例是具体执行步骤。
我尝试在新的迭代版本中使用一下这个模式

感谢讨论~
checkList 由谁去编写，如何保证覆盖性这个问题 @ 沫沫 sir 确实说出了我心中的疑问 --【不过也会存在写的 checklist 有可能会过于通用，或者很多方面和具体的业务其实关联不上的情况】
我更为关注的也是这个问题，我认为这是最基本的问题：既当你想推动一项新的变化事项时，如何去向大家证明新事项的有效性。
当然，我考虑的问题会基于目前的项目情况：迭代频率大概 3 个星期 1 次，迭代范围广。且项目深度、广度都有，团队的测试人员很难有一个能够知悉全部业务细点的人存在。
1、所以像第一点中您的回复，我认为在项目中需要一个对全局业务都能了解，并且能对版本迭代新功能都有了解的人来学 checkList，才能保证覆盖性。 如果不存在，可以由负责对应模块的测试人员来写。 那问题就来到了第二点（哈哈哈）
2、如果每个人只熟悉自己的模块的时候，即使进行团队 checklist review 环节， 成员之间应该也很难发现彼此 checkList 覆盖不全的问题。
需要说明一点的是，我所在的团队不是敏捷开发模式，我本人也未曾长时间呆过敏捷开发的团队，因此对这个流程是缺乏实际感受的。但看到您提出来实际的操作流程来看，这个 checkList 应该是行得通并且可持续的。
因此还是想得到答案（哈哈哈）：3、在楼主已有的执行记录来看，checkList 的验证性和遗漏点的比例是多少，有效性如何？
另外还有一个疑问：checkList 的推广对团队成员的要求是啥，或者说 checkList 的推广是否存在局限性

感觉是一个很好的规范用例，查漏验证点的工具。但具体实施起来有几点疑问：
1、checkList 由谁去编写？（谁来保证 checkList 的覆盖性）
是由负责对应模块的测试人员去编写吗？ 如果是的话，我理解可能 checkList 本身也会有遗漏。理论上需要考虑测试点校验的时候，也相当与在编写测试用例雏形了
2、checkList、用例都写完了，是由谁来进行检查，什么时间进行检查
这个问题本质上还是在询问怎么去确保 checkList 结果的正确性。
3、在楼主已有的执行记录来看，checkList 的验证性和遗漏点的比例是多少，有效性如何？
4、可以分享执行这个 checkList 过程中需要注意的点吗