研发效能 分享一下 xmind 转化测试用例工具的思路和收获
关键词
测试用例 xmind 禅道 gitlab 自动化 质量平台 api
现状
- 测试人员使用 xmind 编写测试概要，每个人写的用例都不一样，缺少具体的格式及规范。
- 测试人员执行用例通常直接在 xmind 源文件上做标记，缺乏详细的用例执行记录，测试完成没有具体的依据及报告产出。
- 测试用例 xmind 文件使用 git 管理，每次测试完成后会上传到 gitlab。
- 团队日常使用禅道作为项目管理工具，禅道有完整的测试用例、套件、测试单等功能，但目前未使用。
解决方案
- 制定合适的 xmind 编写用例规范，统一格式及书写习惯，让测试用例换人依然可以顺畅执行。
- 解析 xmind 文件为禅道格式的用例，自动更新到禅道，生成测试用例及套件，方便关联测试单。
- 仍然使用 gitlab 管理 xmind 源文件，同步 gitlab 更新状态，实时更新用例到禅道。
- 后续使用禅道执行测试用例及关联缺陷，测试完成后可以有报告产出。
技术关键点
问：如何获取 gitlab 的更新状态？
答：使用 gitlab webhook，简单来讲就是网络回调，在 gitlab 项目里配置一个网络接口，当 gitlab 有状态更新时，会把对应的更新消息推送到网络接口。推送消息里面包含了本次推送所包含的 commits 以及文件变更。
问：如何从 gitlab 拿到 xmind 源文件？
答：使用 gitlab rest api，直接访问 gitlab 可以拿到公开项目的信息，访问 private 项目的话则可以配置 access token。接口返回的数据是二进制信息，即 bytes，可使用 BytesIO 转化为 stream 流。gitlab-python客户端可以直接使用，也比较全，如果用到的 api 比较少，不想安装依赖也可以自行封装 client。
问：如何解析 xmind 文件？
答：xmind 本质上是一个压缩包，即把一系列文件打包压缩后更改后缀名为 xmind，通过解压可直接查看压缩包里面的文件，xmind8 的内容存放在 content.xml，xmind11 版本的存放在 content.json，而 xml 和 json 都是树型结构，可以把 xml 和 json 转化为树，通过遍历树可以拿到所有节点的信息。
问：如何兼容 xmind8 和 11 版本，以及其他概要、标注等信息？
答：上面讲到 8 和 11 都是存储格式不太一样，但内容大同小异，我这里是直接解析 xml，再对内容做调整，使 8 版本的 xml 直接转成 11 格式的 json 数据；标注和概要等都有具体的格式可循，既然 xmind 可以解析源文件并渲染格式，我们自然也可以解析对应格式然后拿来做更多的拓展，基础内容可参考xmind sdk和xmind2testcase。
问：如何把 xmind 转成测试用例？
答：我们通常使用 xmind 都是一条线写到底，分别包含了测试用例的迭代、模块、标题、前置条件、测试步骤、预期结果等信息，及树的一条路径为一条测试用例，遍历树的所有路径，即可拿到所有的测试用例，一条路径可简单理解为长度不固定的字符列表 list[str]，迭代、模块信息一般是第一二个节点，测试步骤、预期结果是最后两个节点，中间的不定长节点可归为用例标题或前置条件，可按实际使用习惯去调整；如果想一条测试用例包含多个步骤和预期结果，可判断多个步骤前是否有公共父节点，如果有则可以收拢为一条用例；概要信息可以解析为所有概括节点的子节点......
问：如何把测试用例信息更新到禅道？
答：可使用禅道 web api，具体可查询官方文档；管理员账号访问后台 - 二次开发 - 接口信息；直接从前台抓接口信息；操作禅道数据库。常用接口有新建测试用例、编辑测试用例、批量删除测试用例、获取产品信息等。看具体使用情况，直接看开源代码和数据库设计也会有一些收获。
问：如何做到 case 或步骤颗粒度的增删改？
答：以迭代 (文件) 为维度，在新建或修改文件时记录测试用例信息，可简单理解为 list[Testcase]，二次修改时，也解析新文件为 list[Testcase]，以用例标题为衡量标准，判断两条用例是否相等，以所有测试步骤、预期结果为标准，判断用例是否有更新。通过对比两个列表，得出差异，旧列表有而新列表没有，即删除了一条用例；新列表有而旧列表没有即新增了一条用例；两者皆有但步骤、预期不一致的，即为更新用例，分别根据这些更新信息调对应禅道接口即可做到最低颗粒度的同步。
具体成效
开发工时 7 天，才刚刚开始使用，总体来说没有增加使用者成本，相对规范了测试用例的编写及执行，执行结果和测试单、报告也为测试过程提供了更好的依据。
xmind8 转 XMind10 问题不大 只需要内部做一下另存为就行， 已有实战可行。 实际是因为开发语言导致的问题。至于 CASE 转换可以参考市面上的 XMind 转 Excel ，两种方式（1，固定模板，最省时省力；2，类似 metersphere 做标识，增加用户操作）
以前曾经做过类似的，规范 xmind 写法实现 xmind 转传统用例格式。但实际使用发现，要让大家的 xmind 格式统一非常困难。大家用 xmind 的目的是通过脑图减少用例中的重复编写成本，提高编写效率，xmind 更多是思路的体现，而非固定按传统用例的 前置条件 - 操作步骤 - 预期结果 这种写法。
好奇问下贵司这种强格式规范要求，实际推行的时候测试人员接受度高吗？
陈恒捷
回复
首先讲讲 xmind 的优点，利于发散，快捷键生成不同节点比 excel 等编辑更顺畅，格式简单且方便收折...总体来讲编写和阅读体验会比传统的 excel 或者在线编辑更好，这个没什么疑问，所以 xmind 是首选。=> 一定要用 xmind。
关于强格式规范，虽说有固定解析规则，但解析规则其实并不多，因为测试用例核心要素本就不多，迭代名称取 root 节点，用例标题按照中间的路径生成，倒数两个节点解析为操作步骤、预期结果，比起以往其实只多了一个预期结果。大部分人不喜欢写预期结果，而不喜欢写预期结果的原因在于结果一般是常识性问题，所以预期结果不复杂时可以写得很简单 (例如 “执行成功”，“数据展示 ok”)，当然前提是操作步骤和预期结果等算是常识时才尽量精简，如果复杂的话，还是写得准确些更好。说起是规范，但更多的是约定大于配置，这些约定基本是符合人的思考方式和常识的，并不是强制制定一个规范而让大家都来遵守。=> 规则不多，且符合常识和 xmind 使用习惯，推行时学习成本很低。
从规范上来讲，争议最大的点应该是操作步骤和预期结果是否应该写得很详细以及重复的内容是否应该写几遍，关于这两点，①有操作步骤和预期结果应该是下限，写得完整且准确应该是上限。每一个有追求的测试人员都应该守住下限，提高上限。测试用例是需要评审的，需要用于开发自测，产品验收的，需要后人接手的，如果没有下限，将会是灾难。②重复内容可使用父节点和概要归纳为一个节点，相对减少重复编写的内容。=> 问题看似很难，实际不难。
关于接受度，我个人使用上来讲非常能够接受，因为和我之前的编写习惯基本一致，反而因为规范，我写的用例比之前更加清晰明了；其他人至少基本没有不能接受的，也有一部分人觉得现在细节还不够，希望再增加一些规则 (例如优先级、编写人) => 基于上面的原因，目前接受度还行。
贴一份最近写的完全符合解析规则的用例吧，虽说内容相对简单，但是书写思路和复杂用例是一样的，用例编写难在设计，书写反而是简单的 (类似编程)。
看到这个我也是想说两句。最近也是被领导要求用例格式以便做转换。最大的痛苦就是完全打乱我的思考思路。像楼上这种我个人也很难接受。我自己认为，用例=需求文档 + 测试用例 + 技术细节。也就是说，我看我自己的用例，自上（需求）而下（技术实现以及用例执行），我自己全都能明白，我通常会贴不少图片，甚至贴代码，贴测试思路。请问楼主，像我这种贴图片，贴代码的，能解决吗？极度痛苦中。。。。
陈随想
回复
xmind 本质上来讲是一个多叉树数据结构，而测试用例算是一个数据类，这中间的转化过程主要分为两步：
- 如何对树的所有节点进行归类 (辨别它们归属于同一条 case)
- 如何对归类后的数据进行职能匹配 (识别哪些是标题信息、步骤、预期结果、辅助信息) 简单的解析方式是把一条路径解析成一条 case(对应归类)，通过固定路径上节点的 index 来匹配职能 (对应匹配)
您的问题点在于：
- 贴图片、代码、测试思路 => 扩充了节点的职能和数据类型，从编程角度来讲算是增加了测试用例数据类的字段和支持非文本节点解析，难度并不高。
- 由扩充节点引发了第二个问题，需求、技术实现、测试思路等辅助信息 (细节) 可能位置相对分散，不容易固定，及如何对这些节点进行归类会相对复杂一点，但我相信一定是有规律可循，您也可以相对制定一些使用规则来方便分类这些信息，最简单的方式是打标记。
规范不是为了限制 xmind 和使用人原有的能力，而是为了方便抽离转化的普遍规律以及统一使用人的认知和习惯。
综上，您目前的问题虽说增加了归类和匹配的复杂度，但是并没有超出转化模型的能力范围，是完全能够解决的，编程是把抽象的逻辑信息化，在用例转化这个问题上，只要您能看懂文档 (更希望团队的所有人都能看懂)，计算机也就能看懂、识别、转化，并不存在特别的限制。
看到 xmind2TestCase 刚好我也在用，看到 6 楼说强制格式打乱思路，+1，不单单是我一个，其他的测试小伙伴大致一样；后面把 xmind2TestCase 的解析逻辑改了下，通过标记优先级来确定用例标题节点，和作者的第二点差不多，降低使用成本。
这段时间也正好在做 xmind to excel 的工作，楼主的思路挺好的，已经根据上面的建议优化了一部分，哈哈
frankxii
回复
思路打乱影响太大了，影响了思维。我 xmind 写，层级很多都不是固定的，但是固定后领导会要求格式统一，比如 tt -- tt -- tt--tt，不能超过 4 层，不能有图片，每一层要有前缀，比如 tt 表示 XXx，sd:表示步骤，ex 表示期望。那我以前扩散思维，三层的，我得使劲换成 4 层，超过 4 层的，我又得改成 4 层；我跑通一个用例，喜欢标记绿色勾，不通过打红色叉，但是又不给图片，说是转换 excel 不支持；那这样子跑完我又不知道那些用例跑了那些没跑，我又得换个方式记录。
还有我最喜欢的贴技术细节，贴一点代码，贴数据库字段（有时候是写有时候贴），都没得玩了。
真把用例格式都限制了，那人真的是一模一样的机器了，搞久我都怀疑每个测试思维甚至都九九归一了。。。。
我是坚决要求用例质量：用例=需求 + 技术细节 + 执行用例；但坚决反对用例统一格式。
最后感谢老哥码字那么多回复。我仍然很难改变我的坚持。（也许为了工作会卑微苟同，但测试思维一定要形成自己的一套）
这种工具提效的效果很有限，有的公司如果严格要求测试过程中各类文档规范的，那这类工具或许有一点效果，但如果公司本身就没有这种条条框框的要求，强行施加这些规范无疑是对束缚了测试人员的思维与灵活性，我举个例子，我曾经迫于领导的 KPI 要求，做过类似的一个工具，简单说说当时的情况：
当时公司各个测试团队都使用 xmind 写测试方案，方案评审通过后，就需要根据方案写 Excel 用例，注意这些文档每次测试都是需要留档（这公司流程很死板），所以就会产生重复工作问题，于是就做了一个工具，能将 xmind 转为 Excel 文档，为了实现这种功能，那必然要规范 xmind 格式，最终效果是能帮助测试人员减少一些重复内容的编写，但是减少的工作量个人觉得可能也就是蹲一次坑的功夫，最终也就是一个让领导忽悠老板用的素材。。。
陈随想
回复
可能不同角度看问题会不一样吧，从管理的角度来看，最理想的状态就是大家产出的用例都是一致的，这样不管是交接，还是相互交叉测试，学习的成本都比较低；
但是像你说的这个例子，连要用多少层都限制，就太过了，不利于发挥 xmind 的灵活性。
建议有机会的话，还是和领导谈一谈，看怎么才是更好的解决方案。
陈随想
回复
大致看了下，你说的这些问题，其实技术上都可以解决，只是需要多一些额外的兼容处理而已。
其实难点倒不是这些兼容处理，而是你的写法是不是团队的统一写法。如果每个人都有自己的习惯写法且差异较大很难统一，这个才是最难的。xmind 是很自由的，而很多传统的用例管理系统格式并没有这么自由，习惯 xmind 的团队很容易由于 xmind 的自由各自形成自己的写用例风格或者叫思维风格。这种风格本身和规范冲突还是比较大的，而且说实话，只要这种自由风格不会引起协作问题，其实也没太大必要去统一规范增加协作成本。
我之前呆过的一家公司，1.0 版本的用例管理是走 xmind 转传统用例格式的方式的，结果因为每个人风格差异太大且转换后没法类似 xmind 那样超级自由地编辑（互联网公司，执行用例的时候需求调整所以用例需要对应调整，非常常见），基本除了上传后自动统计用例数量和通过率数据有点用外，基本没人在上面直接写/执行用例。最后 2.0 版本直接改成在线 xmind 编辑，让大家基本不怎么需要调整习惯，才真正落地。
还是得先求质量再求统一格式。高质量必然导致 xmind 格式复杂。excel 太简单了。出了一个新系统，测试人员写完用例，我问，你这个新系统改了哪些表加了什么字段没；诶你这个查询啊什么的操作用的哪个接口哪个协议，协议内容格式都有啥；有没有影响到旧功能旧数据，旧数据什么结构，程序怎么处理；等等一问三不知。我一直认为，用例不是简单的功能用例，因此是做不到格式统一的，但是见了太多人都是那种我去市场上随便拉一个人，也能写的用例。
我还是这个观点：用例=需求 + 技术细节 + 执行用例
但是做到如上，很难规范格式，或者说规范成本太高了。
我不太喜欢那些只有功能的用例，虽然有时候迫于时间有些我也仅写功能。。。。。不过这个和我不喜欢应该没冲突吧。。。。说实话，鄙人游戏出身，第一次看到 web 测试人员的用例时，我大惊失色，用例原来可以这么简单。。。。
以上纯属话唠，各位看官看看就行，别当真了。
其他同事能看明白吗?牧歌
回复
我们组有很多人看不懂，因为 90% 都是混功能的。现实和 testerhome 是不一样的，还是很多人只会功能，最多会个 jmeter 工具，或者一点点代码，并不能编写实战工具。我其实这么写用例也很难受的，但是现实很多时候得这么干才能减少坑。我记得以前游戏策划经常出现疑问，诶如果你这么操作会怎么样（或者交接的策划问这个功能以前是怎么样的文档不详细啊），那个时候我经常都是翻看用例就能解答。现在我做不到了。退步了。有时候我也在想，用这种 excel 规范好的用例格式，怎么编写游戏用例，比如复杂的抽卡机制，王者荣耀战斗 AI。我发现我好难做到，我必须带各种其他信息，才能使我以后重新看用例的时候能看明白。
