实践中测试用例编写——抓牌理牌法

上班也有一阵了，尝试过几次编写新需求的测试用例。

我是一个比较强迫症的人，同时思维会较为严谨，所以在写测试用例的时候会遇到很多瓶颈，经常卡壳，在一两个点上非常纠结。

一方面是经验不足，另一方面还是方法问题。

我们公司要求用Xmind编写测试用例，

其中最逼死强迫症的点就是思维导图的大纲属性。

为什么这么说呢？

思维导图是从1开始发散，高屋建瓴，先定主干道，再写每一支的细节。

这里就有一个很严重的问题，

如果主干定错了怎么办？

事实上就是会定错，即使你对需求文档已经倒背如流，如果需求文档的条理没有很清晰，你一上来就先给用例分组，大概率是会分错或者遗漏的。

等写到后面发现这块东西应该在那个模块，这两个分支应该算在一起，那条主干道反而应该放到这条支线里面，你就会发现，这改起来真的千头万绪一团乱麻理不清楚了。

所以，Xmind这种工具，表面上看起来极其有条理，很高大上，但是在实际使用中非常不现实。越是有条理的东西在实际生产生活中，实现起来反而越是困难，越是逼死强迫症。

、、就好像你想把房间弄整洁，或者学别人给桌子理线实现无线桌面，你经常会发现怎么都弄不满意，好不容易弄好了又发现了更好的方案。又要全拆了重新弄一遍，最终发现最好的解决方式就是不要放心里，线乱心不乱。

好了闲话少扯，回归正题。一上来就思维导图是绝对不行的，尤其是我这种强迫症。

那怎么办呢？

我发明了一种方法论：抓牌理牌法！

什么意思呢？当刚开始准备写测试用例的时候，我们采用抓牌法。

对照需求文档，按照文档顺序一条一条地记录测试点，就像是抓牌一样按顺序把每一张牌先抓到手里。

对照需求文档，这样想到多少写多少，会遗漏一些，而且没有条理，因为需求文档很多时候都很粗糙。

生产环境下很正常，产品能写的清清楚楚要你测试干嘛。

但是不用多想，想到哪里写到哪里，一条条对照，尽量覆盖，这个时候只是写测试点，我个人是觉得word就很好用了。

当你把能联想到的东西都写完了，这个时候心里才真的算是有了一点数，可以开始整理测试点了。这个时候再开始理牌，把相关联的测试点放在一起。这个是顺子，那个是对子，那个是炸弹，然后这边凑飞机带翅膀，剩下几个单只看看放到哪边。

整个过程和理牌是非常相像的，先大概理一理手里有哪些东西，然后逐渐看清手里牌的局势，最后定下出牌思路。

到这个时候，你还会发现自己缺了哪些牌，去凑齐自己的顺子，或者凑齐自己的炸弹。随着整体思路的清晰，没有覆盖到的地方可以慢慢补全。

当然你也会发现，你自己打牌的时候是会边抓牌边理牌的， 这当然也完全是正确的。

最重要的是，主干分支往往是在整体局势明朗之后才能看清的，无论是先抓牌再理牌，还是边抓牌边理牌，都是循序渐进的整理，而不是一上来就确定我要把炸弹放这边，把顺子放那边。