前言
我们测试的产品从传统行业跨向了互联网行业，我们的测试用例也从传统测试用例跨向了互联网测试用例，过程中很坎坷，主要经历了一下几个转变：
1、最早的测试用例管理方式：我们公司有一个项目管理平台，在上面进行用例的设计的编写执行；
2、传统测试用例管理方式：excel，用例评审过程也是拿 excel 进行，整个评审过程简直就是浪费生命；
3、采用思维导图的用例设计方案；
4、采用思维导图的用例设计 + 编写，目的是要实现思维导图式的测试要点可执行；
小结：
方式 1 和方式 2 适用于产品测试周期长，有大量的测试用例设计和编写时间；
方式 3 和方式 4 适用于产品测试周期短，为保障产品快速上线，快速铺开，测试时间被大量压缩；
不同阶段和不同的产品测试对应的测试策略不同（这里主要说测试用例），但是当产品达到一定的稳定程度的时候，思维导图试的测试用例的缺点就会很快的暴露出来：
1、思维导图测试用例在不断的版本迭代过程被分割的非常小和零散，基本上一个小版本就会有一个思维导图文件，很难实现测试用例回归；
2、思维导图式的测试用例有一个很大的弊端，很难实现可执行性和延续性，也就是说给别人一个思维导图的用例，别人无法帮你进行回归；
用例管理的问题
思维导图式，过于零散，无法实现用例回归；
思维导图式，维护成本高，一般人不太容易看懂；
思维导图式，存在不可执行的问题；
近期手上负责的 3 个项目的产品基本趋于稳定，进入维护状态，进入了产品测试用例整理阶段，一直在思考用什么样的方式管理比较合适；
用例管理平台
1、testlink
2、excel
相信很多测试团队都会碰到我的问题，不知道大家是如何选择测试用例管理平台的？
和我们现在的做法一样，前期用思维导图，稳定之后再转化成具体的测试用例导入平台。
前期就用测试管理平台也没什么不行得，不一定非得等产品稳定之后再迁移。没人逼你在用例管理平台上写用例就一定得把详细步骤写清楚。 就算光写个 title 当 check list 也是可以的。规矩是死的，人是活的。用例管理平台的优势不仅是给你个地方管理用例，它也相应的跟踪了每个迭代的用例执行情况，将测试信息展现给团队中的所有人等等
#2 楼 @aizaimenghuangu 因为项目管理用的 TFS，TFS 自带用例管理，所以我们就用的 TFS。特点就是 TFS 可以同时管理需求、BUG、用例，并且这三者之间可以相互关联。
#8 楼 @aizaimenghuangu 如果目的是让不熟悉产品的人也可以执行测试用例，那就又回到刚开始的问题了，产品业务不稳定的时候用例是很难详细到每一步都记录下来的。那个改动成本太高。这跟是不是用例管理平台其实没太大关系了。产品初期的时候必然是就写一写 check list 的。
思维导图 +excel 的飘过。。。
mindmanager 自带 word 导入，excel 导出，能对接需求 word 和用例 excel。
—— 来自 TesterHome 官方 安卓客户端
excel 转 testlink。
目前正常项目的编写用例使用的是思维导图 +excel，回归用例用的是 checklist，会把步骤也写上
做 KTV 产品？
xmind 就差不多了，缺点是不好管理，最好是测试代码跟随业务代码，这样其实也能比较好的进行积累
以前用 excel，但是业务变更快，测试周期短，没人会写特别详细的测试用例，最后都转战 xmind 了。
个人认为 xmind 已经足够专业人员回归测试了。
只是有时候不同的人写 xmind 思路不太一样，但是了解后读懂不会有大问题。excel 太繁琐，写起来费时费力，效果也不一定好。
现在项目组有专门维护 case 的人员，比较注重积累，这样已经能一定程度上解决问题啦。
其实不管哪个管理，最痛苦的是版本 2.0 改版后，项目组说你们把所有的用例都执行一轮。这个以前没有维护好用例，你就会痛苦了
建议从开始就做好用例管理，不然后期返工成本也很高，风险也比较大，比如人员请假、离职等变动都会成为项目风险