明白。

避免用例丢失思路我们是一致的，都是保存历史记录，并支持一键恢复。

可以随时选择任意父节点进行拼接这个挺好的，可以像前面其中一位同学说的，可以任意组合用例库里的用例形成自己的测试计划。从目前大家使用上来说，这种场景比较少，偶尔遇到直接在脑图里复制粘贴也基本可以满足。后面如果需要这方面的特性，我们也参考下这个思路。感谢分享。

语言很通俗易懂，也有很多例子，点赞！

针对消息不一致，分享下我接触过的系统做法：

首先，消费者在消费成功后通过同步请求或者另一条 mq 队列，反馈给生产者，生产者更新自己内部这条消息的状态为已处理。

同时生产者内置一个定时任务，查看内部所有待处理消息是否超时，如果超时，进行自动补偿。补偿大概步骤是

1、发起 http 同步查询给消费者，确认消费者是否有消费
2、若消费者反馈已消费，直接更新生产者自身内部消息状态
3、若消费者反馈未收到，则进行预警，人工介入处理（一般不会直接重发，因为重发有可能引发更严重的问题，如加剧 mq 消息堆积的情况）

好奇问下，你们当时数据存储设计，把用例拆那么细的初衷是？每次读取完整脑图都需要各种连表查询重新组合，会不会对数据库造成比较大的负载？

文章中的思路应用到你提到的 “不想每次给到后端的 json 都是整个脑图”，其实也是可以的，json-patch 的生成改为由由前端来做就行了，这样就可以只提交 patch 内容给服务端（json-patch 和 json-merge-patch 两个格式设计初衷就是做 json 数据增量保存，节省大型 json 修改保存时的带宽用的）。至于统计每个人每天新建、修改了多少用例，个人理解已经不是增量保存的范畴了，应该用你说的加更新时间和更新用户信息会更好。

我当时整个 patch 生成的逻辑全部放服务端，主要 2 个原因。一个是找到的库是 java 的，另一个是冲突时后端有全量 json ，方便做整体备份避免丢失用例。从我们引入 agileTC 进行落地的整个经历看，对于用例平台来说，丢失写过的内容（哪怕是引起冲突无法保存的内容），是用户最无法容忍的问题，所以要尽一切努力去存储用户期望保存的内容。

tapd 也支持 xmind 测试用例？看介绍好像没提及。

可以问下在京东里面的测试同学帮查，这方面信息客服不一定能看到。

这个得京东内部查下登录方式了。一般这种大型 app，除了用账号密码，还可能会提供别的登录方式。

不同团队可能需求不一样。我们这的优先级、自定义标签，用得还挺多的。

比如写用例的时候，有些地方需要用例评审时特别关注，就打个【待确认】标签。
比如给开发自测用例的时候，一般就直接给 P0 优先级的

信息留言放在地址管理这个挺奇怪的，感觉真的有点像地址管理的其中一个对外暴露的接口鉴权有漏洞。

这种算是测试用例里面的前置条件吧，类比测试框架里的 @Before 类方法。这种场景很常见。

至于是每次生成订单，还是写死固定几个不会改状态的订单 id，就要根据实际情况来选择了。

依赖检测找到另一个算法，看起来逻辑比有向图判断环更简单，可以参考下：
https://github.com/scarcoco/projx/issues/38

1、是不是需要做下循环依赖的校验？比如 1 依赖 2，2 依赖 3，3 依赖 1 这种。
2、这里最深的 if 已经是第四层了，嵌套略深，而且也缺少对 step id 没有对应 api_id 这种异常情况的检测，目前只是直接忽略返回空列表，而非抛异常。
3、有一个场景没有描述，比如 1 依赖 2、3，2 和 3 都依赖 4。此时应该生成的是 [4, 2, 3, 1] ，还是 [4, 2, 4, 3, 1] ？按照目前实现，会出现的应该是后者。

建议按照这几个信息，分块编写相关逻辑：

1. 递归结束条件：step 数组内元素个数为 0、值为 null 或者不存在此 key
2. 每次递归需要进行的操作：把依赖的 step id ，在验证确认对应 id 的用例存在后，加到执行顺序列表中当前 step 的前面
3. 其它需要抛出异常的场景：循环依赖校验、step id 在用例列表中不存在

同类逻辑 java testng 框架的 depends 逻辑也有类似实现，建议也可以参考下。

哦哦，明白。

和我这块确实不大一样。我这里的 diff 除了展示，还需要具备给用户直接复制粘贴，重新应用的能力，所以展示方式使用了脑图，而不是 json 之类的纯文本展示方式。

我的展示效果大概是这样的：

服务端相关的代码改动及配套单测，已提交 PR 给官方。地址：https://github.com/didi/AgileTC/pull/93

增量生成、应用、标记的逻辑全部在 case-server/src/main/java/com/xiaoju/framework/util/MinderJsonPatchUtil.java 这个工具类

配套单测在 case-server/src/test/java/com/xiaoju/framework/util/MinderJsonPatchUtilTest.java

哈哈，看来大家都殊途同归。

下面介绍的 start end 坐标字段，有点没太理解具体是什么的坐标。可以写个示例么？目前节点坐标信息我是通过 json-patch 里面的 jsonPointer 直接拿的。对于子节点数组型用下标会不准，我是先把 array 都转成 object ，key 是节点里 data.id 的值。

看了下官网，找到答案了：

鸿蒙的 app 不再是 apk 格式了，而是 hap 格式？

好奇问下，实际落地怎样，各个团队的测试人员愿意用单测框架写代码的形式，来记录用例信息，和登记测试结果么？

嗯嗯，我们主要用来写用例、评审用例和执行用例，作为测试平台的用例管理模块，也用于作为测试过程数据中测试进度、用例数量的量化指标来源。

不同项目组在整个测试流程上还是有一些差异的，暂时还没统一，所以暂时也不需要太复杂的，我们更崇尚 less is more ，专注做好一个功能就足够了。用户权限这个官方的最新版已经加上了，看板这个，我们内部有用另外的项目流程管理平台，看板用那里的足够了。

至于单任务关联多用例集，以前有想过，但其实维护成本和使用成本都很高（要不用例集拆得很碎方便组合，要不任务关联能力要很强能任意选择部分用例）。实际上，只要有历史用例集和复制粘贴，就可以完成类似目的了。

这是个 bug，我周末查下啥原因，修复下

好奇问下，你们现在手动测试用例是怎么编写和记录测试结果的？我们这边基本都是 xmind 为主，少数无界面可以直接 api/单测测试的，就直接写代码/上对应测试平台写用例。

哈哈，其实我 title 确实是测试开发。

非常赞同你对 “测试开发” 和 “自动化测试” 两个概念的阐述。在我们公司，自动化测试要求是社招的所有 title 带有 测试 的岗位都需要具备的。

最后这个 “而且要求具备对测试流程的理解”，也非常认同。确实这个需求其实不是一开始就按这个需求方案做的，甚至因为这个方案的复杂性，想过各种 “绕过” 的手段。但最后发现确实没有更好的手段，所以才最终选择啃下这块硬骨头。

手工的测试用例也是用单元测试框架来做吗？

谢谢

我们之前也是直接 git 管理 xmind，但发现很容易后面改动后的用例就没再同步了，而且也不好直接统计通过率、用例数什么的，所以用了 agileTC

大概看了下这篇文章，好像没提及 xmind 这种格式？

非常认同你的观点，能用已有成熟方案的话，尽量用，避免自己造轮子。但 git 可能在这个领域，经过我的思考，不一定适用。git 适用的领域主要是纯文本，对二进制文件相对比较弱，基本就是全量更新。

xmind 文件本质上比较接近于 xml ，但实际存储格式是非纯文本，在 git 里面基本都是全量更新。而在线脑图 kityminder 可以将其以纯文本 json 格式存储，理论上具备可行性。但实际上，这个 json 和脑图看到的内容，直觉上还不大能直接关联起来。

举个例子，脑图 json 如下：

{
    "root": {
        "data": {
            "text": "百度产品"
        },
        "children": [{
            "data": {
                "text": "1",
                "resource": ["自定义标签"],
                "priority": 1
            },
            "children": [{
                "data": {
                    "id": "cc3eeotpqsg0",
                    "created": 1623679673934,
                    "text": "1.1"
                },
                "children": []
            }, {
                "data": {
                    "id": "cc3eepzptug0",
                    "created": 1623679676474,
                    "text": "1.2"
                },
                "children": []
            }]
        }, {
            "data": {
                "id": "cc3eerciow00",
                "created": 1623679679425,
                "text": "2",
                "layout_mind_offset": {
                    "x": 405,
                    "y": 80
                }
            },
            "children": []
        }]
    },
    "template": "default",
    "theme": "fresh-blue",
    "version": "1.4.43"
}

对应实际脑图是这样的：

这还只是一个很简单只有 3 层、5 节点的脑图。如果是日常过千个用例，数千个节点的脑图，出现冲突看着 git 里面的 diff ，真的会一脸懵逼呀。

同时还有一个问题，就是测试任务场景里，很可能用户看到的只是子集而非全集，这个时候可以理解为看到的版本和实际用例版本不一样。git diff 是基于行号 + 改动内容前后数行内容来定位的，如果是测试任务的场景，很容易因为改动内容前后数行和全集不一致，直接理解为冲突。