针对测试用例这个话题，当互联网公司越来越多冲击传统型公司的时候，貌似提及的更多了。

现在的公司，1 个月 1 个版本都觉得慢，月初定的需求月底不改点的都不正常。其实也对，因为世界在变，我们在变，客户在变，唯一不变的就是变本身。

那么我们说，基于这样的现状，我们是否还要花费心思写一个非常完善的测试用例，然后用心来维护呢？

我们考虑 1 个词：生命周期

什么意思呢，就是用例自产生起，到评审通过，到测试之行使用，到很难维护下去的时间是多久？

有的公司 1 周发布几个版本，有的公司几个月发布 1 个版本，用例的生命周期是不同的。

上述 1 周发布几个版本的公司，同学们也不用直接定性说：我们公司就是这样的，我们也就不用维护用例啦！

这么说不一定全面，我们再仔细分析下，假设我们系统有 10+ 个模块，而我们改动的频率又不会是每次版本每个模块都改动，那么我们是不是就可以分析出来哪个模块相对稳定？

很多时候，我们自动化也是这么分析的对吧。自动化在做的时候都会考虑ROI，那么类似的，测试用例也如此。

是否花心思写用例、执行用例、维护用例，甚至还会搭建一套测试用例管理系统，都是基于现状、成本、投入产出比来看的。

当然，测试用例只是一种手段，形式多样，如果你说繁重的 Excel 模式和系统录入模式过于重了。那么 Xmind 来编写测试大纲、分析测试范围和方法，是不是很高效。

所以，不管测试用例最后写到了什么粒度，个人认为，这个手段必须存在，而形式可以斟酌。

记得有一次开周会，我们部门一个同事说：我们的用例写的好繁琐啊，我们之前在 *** 的时候，用例都蛮简单直接的。紧接着另外一个同事立刻附和表示同意，说我们的用例就是挺多的。

我当时这么回答：

1. 在我们当前 1 个优秀用例产出后能用上半年甚至 1 年之久（系统大，而真是有很多模块变化不快），我们就是有时间来维护并且长期复用的
2. 在我们看别人是怎么做的同时，也一定要明白别人是什么情况下做的这个决定
3. 用例的繁琐不代表用例本身该不该写，而是你写的是否冗余了，如果没有，就不繁琐
4. 我认为测试用例是测试人员的核心技能之一，也是非测试开发岗位的其他测试人员最需要具备的能力，从这点上来说，我们有部分测试好几年的同事，我仍然认为你不会写用例，不然我们也不会花很多心思培训、评审了
5. 测试用例是测试过程中重要的产物，是指导测试行为、明确测试准则、有效衡量基线覆盖的最有效的工具

讲道理，其实还是很多测试人员干了很多年后，觉得黑盒没意思了，就是手工手工。

测试往高走确实难，但是大牛的测试开发大有人在，转型到其他方面如：项目经理、甚至成为项目总监、敏捷教练、产品经理取得更大成绩的也大有人在。而无法跨出舒适区，又不能静下心来好好沉淀、学习的人，我觉得，还是不要在测试行业久待了吧，不管怎么说，这也是一个技术岗位啊。

最后，我们来聊聊测试用例怎么管理。

我并非指的是我们用什么系统管理。当然如果我们已经通过系统进行测试用例的管理更好，我想说的是管理思路，并且怎么和系统结合的更好。

首先，用例的管理思路，应该接近但不等于代码管理思路。这个在之前的文章（我们到底该如何进行黑盒测试——用例设计篇）里写过，感兴趣的同学可以再次阅读下

其次，要使用系统，并且最好能和 Story、Bug 结合起来，并能支持很好的图标分析（推荐 Jira+Zephyr）

再次，要在实际工作中不断的维护测试用例：需求变了就改，用例没用了就删，看到不足了就补

最后，让你的用例成为测试活动的中心，将很多活动都和用例产生关联，持久起到作用

有一句话可能已经有很多人不认可、很多人不知道，“一个好的测试用例，是可以让大多数人很清晰的看懂，并且很好的执行的，当然他包括我们的客户”

我不知道你们会不会维护用例、不知道你们是否真的会写用例，不知道你们写了后能起到多大的作用，但如果要写，就写好