大家应该都有过写测试用例的经历。

我的经历大概是这样的。

十多年之前刚入行的时候是用excel写用例。大概就是往模版里填充一些必填字段，比如用例编号，名称，步骤，预期等等。那时候啥都不懂，预期里基本上是随心写，填的都是"应该正常执行", "结果应该正确"之类的写了等于没写的话语，无非就把格子填满，显得很有工作量的样子。执行用例的时候基本上是看需求文档，自己写的用例也不看，测完了就无脑打勾，显得工作是按时按量完成了的。

后来很多年用例管理也一直没有改善，无非就是excel换模版，然后用打勾的形式去表明工作已经完成。这是手工执行的方式。

也经历过很长一段时间用自动化的方式去运行用例的情况，这时候用例基本是代码，代码是经常要去更新的，以便增强稳定性和更新业务逻辑。这时候报告和日志比较重要，因为跑出问题之后需要通过报告和日志迅速去定位问题，提bug或者再人肉验证一下。

再后来便是开发了一些测试用例的管理系统，自己用起来还行，无非就是把excel填格子的过程改成了从网页上填表单，但是推广的时候遇到了很大的阻力，毕竟大家还是习惯于用excel去管理，在写好了execl之后导入到系统里，整个系统除了执行的时候可以体现用例状态之外，其他的话意义不是很明显，而且很多时候，用例的执行状态并不是大家关注的重点，所以用例管理系统后来也没太多任用，荒废掉了。

近些年很多同学用脑图的方式来管理测试用例，等于就是把需求换个维度整理了一番，变成了一个个的场景或者检查点，测试的时候可以对照着检查点来，比excel有不错的提升，可以推荐大家试一下。

脑图其实是整理+记录的过程，很像是我们之前初高中时候老师写的板书，好发散，格式比填格子灵活。我建议可以不用在脑图里写预期结果，执行完成之后再补充也行。

写脑图可以用场景导向，枚举大部分的异常场景可能会比较的有价值。

如果写了用例但是测试的时候不去对照着看或者执行，那么写不写都无所谓了。真正有价值的用例可能是

• 自己测试的时候会去对照着看或执行
• 大家都能看懂
• 保持跟最新的需求同步

最后给一张最近关注度比较高的个税脑图，这个图基本上算是非常全面的测试检查点了，大家可以参考一下。