写在开头

故事的开头从我在群里吹的牛逼开始，距离吹这牛逼刚好过了1年，我也把今年做的用例管理系统整体思路跟大家一起探讨探讨，文字不多，基本是图，大家蛮看。
image.png

为啥我想做用例管理平台

我们看看之前我们内部用于管理测试用例的工具平台，我觉得也基本代表了绝大部分的公司的用例管理情况：
image.png
是的，我们要嘛拿着Excel、Xmind 这种非专业的测试用例管理工具来管理我们的测试用例，要嘛拿着TestLink这种从界面到交互都感觉上古时代的平台来管理，而且一个不到百人的QA Team，连一个用例管理都没做统一，上面三种同时存在，不同Team 用不同的方式，甚至一个Team内都可能多种并存，而且更让我吃惊，他们都拿不出一份自己系统完整的测试用例，因为他们每个版本都用一份新的文件去管理用例，所有旧的用例都不会被传承下来。

用例管理平台设计思想

发现问题，提出问题，那就想办法去解决问题。那对要做的平台提出10个字思想

高效

这点不用质疑，如果没办法比现有的平台、工具更方便管理，方便编写，方便维护等，谁用。 同时还得满足多个Team的对用例的不同管理需求（表格和脑图）

传承

用例不应该用完就丢，应该是可以迭代。 上线后把对应用例归档，下个版本用例在已有的用例上新增、修改、删除，保持一份完整的系统用例库，并可以随时回溯以往版本系统对应的测试用例。这样后期统计一些数据时这个分母才有值。

复用

除了继承了以往版本的用例，同时抽取公共的用例，如公共模块，公共组件，基础功能用例，编写用例时可以快速从公共用例库中导入对应用例，复用了用例也提高了编写用例效率，同时用例应该可以被多次评审，多次执行。

共享

用例管理不应该是孤岛，需要跟其他现有平台打通，除了做到一些基础数据共享，如基础用户数据、团队等数据。还需要更更多平台交互，例如需求管理、Bug管理等。

度量

以往的工具平台这点比较缺乏或者很难去统计一些有用的数据，例如某QA的工作量（编写多少用例，执行多少用例），某系统的用例数、测试覆盖率、P0用例覆盖率等等。

用例管理大体功能结构图

image.png

image.png

  1. 红底色部分未完成
  2. 同时支持脑图和表格用例
  3. 自动化测试用例跟功能测试用例是同一份用例，只是对已完成自动化测试的用例上面添加一个自动化标识，然后通过用例ID和外部API自动化测试脚本用例关联
  4. 评审计划可以一键转成测试计划
  5. 测试用例可以不经过评审，直接被加入到测试计划
  6. 测试计划类型是同时支持 手工测试类型和API自动化测试类型

实际界面

实际界面也看几张吧，很多东西就自然明白了：

脑图用例编写

image.png
image.png
通过左边一棵无层级的树结构来管理空间和用例集，同时支持表格和脑图的用例集。
脑图是基于百度的 kityminder-core 和 hotbox 二开的，同时增加了一些功能，如通过优先级、标签等过滤数据，支持选中某些叶子节点，并直接规划到测试计划等，hotbox 节点右键功能也做了一些扩展和修改，例如新增了导入公共用例等，同时在后端存储上，原百度脑图是结构是整个json串，但是我们落库后做了结构化存储，每个节点是一条数据，这也更好的让我们对节点信息的扩展，例如节点信息其实都带有storyID 、创建、修改的用户信息和时间等。

表格用例编写

表格的编写就太普遍了，也就懒得截图了，直接过。

因为用例评审的规划和执行和测试计划的评审和执行很像，这边就直接截几张测试计划图片。

用例规划

新建一个评审计划，填写了基础信息后，就可以开始规划当前计划需要评审的用例。 规划用例除了可以逐个从对应的测试集中去找到对应的用例，也支持快速通过一些信息去选取对应的用例。
image.png

执行测试计划

image.png
执行计划界面，左边的树不在显示完整的用例空间等，而仅仅把有被这次计划规划的用例集和其对应的的空间显示。 同时评审过程依旧是一个脑图，但该脑图不让编辑节点，只允许添加备注，标注评审结果或测试结果，同时会有一个时时进度和报告。

平台定位

其实用例管理是当前在做平台的一个核心也是落地较好的一个模块，而其整体的设计思路跟别的模块几乎类似，这也是我对这个平台的一个定位：

核心：一站式持续测试平台

image.png
虽然上面都在讲用例管理，但个人是不会仅把平台定位做用管理，所以把目标拉大，平台的定位应该是一站式的持续测试平台，能在全程软件测试过程中，对每一个环节都提供相应的工具平台支持，并提供最佳的实践方式。
那如果我们把问题聚焦回用例管理，那用例管理具备的 用例管理 -> 测试任务管理 -> 用例执行管理 -> 测试报告分析 4大能力，而这4个功能是基本上可以适用其余模块，只是给到用户的展示交互信息等不一。

数据驱动

例如用例管理中，当用例管理、执行等都放到平台上后，必然会有一大堆的数据，从这些数据中捞出一些有意义的数据，去度量QA的工作，数据化去展示项目质量等等，为不同层级人展示不同纬度的的质量看板，从而去提高交付质量。

桥梁

平台绝对不能孤立，而是要更多去跟公司现有的平台做打通，例如用例管理跟需求Story打通，跟已有Bug管理打通，跟CICD流水线打通等等，对外提供测试能力，也从外获需要的资源。

写在结尾

2020这一年真的太难了，难到无数次想“逃离”，经历了各种不可抗拒的外在因素，也经历了职场这么多年，最“孤独”的一年。
做平台，把想法实现都不是难点，难点在你做出来的东西怎么去落地，然后持续的从用户那边拿到有价值的反馈，并持续改进，落地真的很难，特别像我这一线的打工人，跨部门让别人去接受你的东西太难了。
“孤独”的一年，当你的直接上头对平台的侧重点和将承接的能力跟你的想法几乎是相反时，例如平台到底要不要做API自动化测试，陷入了大半年的争吵，心巨累。最后只能一头做着上头要的A方案，同时默默在做这B方案，事实也证明B方案调度方案才是目前最佳的方案。
也特别感谢前后端几个大佬们，没有他们，我所有的想法也许还只是想法。

关于开源

大家可能最关心的是当前做的东西能否开源。 实话我也热爱开源，但是实际不允许，最简单原因底层框架全部是公司内部框架（虽然底层还是那些），所以没办法。 但是。。。。虽然整个平台我更多的是产品与运营的角色，但我抽了点时间把这边前端大佬们做的百度脑图大部分的功能搬到了用 Vue+Elemnet UI 实现Case_Minder_Vue，有兴趣的可以拿走二开自己想要的更多功能，大概这样子吧：
image.png