关键词 （文末有福利哦）
测试用例 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 天，才刚刚开始使用，总体来说没有增加使用者成本，相对规范了测试用例的编写及执行，执行结果和测试单、报告也为测试过程提供了更好的依据。
福利
