浅谈测试用例的编写

关于测试用例，我们测试人员的问题有很多，比如：

1. 测试周期紧张时，是否可以不写用例？
2. 测试周期紧张，希望用测试点来替代用例，可测试点的呈现形式和复杂程度应该如何控制呢？
3. 为了方便分工，领导安排我们按照模块来编写用例，导致很多场景/流程没有覆盖，此时如何处理？
4. 用什么工具来管理用例呢？excel或者专门的工具？哪种更优呢？
5. 产品中很多页面的测试点很相似，每个页面都写用例感觉是在浪费时间，但不写用例又担心执行时有遗漏，怎么办？
6. 产品的场景/流程较多，这意味着很多用例需要前后关联，此时该如何写用例才能更清晰、简洁呢？
7. 终于把用例写完了，但发现按照用例执行的效果还不如随机测试效果好，并且感觉还浪费时间，怎么办？
8. 用例评审时，自己很用心的在讲用例，但评审效果并不理想，原因是什么呢？怎么才能提升评审会的效果呢？
9. 产品迭代频繁，每个迭代版本的测试用例不好选择，怎么办？
10. 分配了几个人共同执行用例，其中不少模块还有重叠，但产品上线后仍然有漏测，分析原因并非因为用例覆盖不全，而是执行人没有完全理解设计者的意图，怎样才能提升用例执行的效果呢？
11. .....

诸如此类的疑问很多，今天我们先来聊聊“如何编写用例”的问题。编写用例是我们测试人员日常工作中最主要也是最频繁的工作，我们可以从书上或者网上查到很多这方面的资料，很遗憾的是，很难用一篇文章能把这个问题讲得全面而清晰。这也跟企业中面临的情况复杂多变有关，本文希望抛砖引玉，欢迎大家在文章下方留言。

01

思考用例的目的

“无效用例”的典型，就是那些看起来不错但实际没有任何用途的用例。每一条用例都需要慎重思考：为什么要写这条用例？希望达到什么目的？测试点是否清晰，跟自己的期望目标是否有出入？

02

用例要易于编写、修改和更新

需求的变更、执行用例时脑海中突然涌现的想法、随着对需求理解的加深而发现某些用例的不足以及产品补丁的添加等等，都会引起用例的变更。变更用例对我们来说是一种被动接受的行为，我们无需去考究这种行为的原因或者重要性，我们要考虑的是用什么方式管理用例才能让它便于更新。

对于一些简单项目，可能这个问题并不知道讨论，也许这种情况我们该讨论是否需要写用例？

但对于业务复杂、项目周期长或者迭代频繁的产品型系统，就很有必要来思考这个问题了。

对于这个问题，我想很多人会首先联想到自己工作中使用的用例管理工具，想到在那些工具中是如何新增/修改某条或某个模块的用例，会想到使用那些工具在更新用例时的一些不便之处。但编写/更新用例是从了解需求开始的一系列的工作，编写/更新用例只是这个流程中的最后一个环节。所以讨论这个问题，需要把我们的焦点放开一些，比如：

• 如何更快速的了解需求？是否有固定的套路，让无论是新手还是老手都能既高效、又准确的把握需求？答案是有的。
• 原先的项目测试负责人离开了，接手的人怎么做才能尽快开始用例的编写、更新？怎么写用例才能让刚接手这个项目的人很轻松的读懂？既能理解用例还不会花费过多的时间。
• 每条用例中的每个字段，在方便性上是否还有提升的空间？
• 为了减少用例的编写/更新时间，我们会借助公共的测试用例仓库，用例仓库应该整理哪些类型的用例？而项目用例集又如何使用用例仓库中的用例呢？
• 为了减少某条用例的编写/更新时间，我们常常复制一条跟它类似的用例，这个过程有没有地方可以改进？
• 应该制定什么样的标准，让场景/流程用例既能写起来简单，读起来也清晰？
• 如何安排测试用例和对应的测试数据？
• 用例更新后总得汇报吧，今天写了多少条用例，是针对哪些模块的？....若需要每天进行汇报，总不能每次都手工统计吧？
• 用例执行阶段也需要汇报，今天执行了多少，执行效果如何？....同样需要统计，目前的管理工具中是否支持，若不支持怎么做才能自动统计。

说明：篇幅所限，这里只给了问题没有给出答案。其实这些问题答案很简单，某些问题的答案在其他文章中已经给出，没有给出的后面的文章也会探讨。在笔者带团队的这些年，发现很多测试人员多专注于执行的工作，而对于改善工作并不会多做思考。不是其思考能力弱，而是没有这样的意识。所以笔者的文章风格也是倾向于提问题而不给答案，目的也是希望引导部分读者培养思考的习惯。

03

用例要易于执行

笔者的经验，很多测试人员在编写用例时不注意思考这个用例是否便于执行。写出来的用例乍一看很规范很清晰，但如果进一步思考如何执行这条用例就会发现这条用例其实是条无效用例。越是年轻的测试员这个现象表现越明显。

另外，如果经常遇到提测版本质量不过关，可以筛选恰当的用例交给开发人员，让开发人员按照用例进行自测。这就需要我们在编写/更新用例时思考，自己写的用例是否能很方便的“筛选”出交给研发的那部分？

04

使用测试用例集

属于一个场景或流程的测试用例，可能分散在不同的模块，这会导致执行不便。可以考虑

创建测试集在应对这种情况。某些公司习惯单独创建一个表格来管理测试相关的测试点，与测试集相比无关优劣，只是在需要监控每次迭代的执行结果时测试集更方便。方式的选择取决于公司的情况。

顺便提一点，如果用excel管理用例，建议多用excel的分组功能。

05

不要迷信需求和设计

不要迷信需求文档和设计文档，设计用例时仍要多思考需求和设计是否合理，是否有更好的方式。

06

总结

测试用例的编写是一项会对整个测试阶段产生重要影响的活动。这个事实使得测试用例文件编制这个任务变得非常的关键并且微妙。所以，编写测试用例得先适当的计划一下，还得非常的具有条理性。编制测试用例文件的人必须记住，这项活动不是为他/她自己而做的，而是为了整个团队，这个团队包括了其他测试人员和开发者，还有那些会被这项工作直接或间接影响到的 客户。 所以，在这项活动进行的过程中必须给予适当的关注。对所有的使用者来说，测试用例文档必须是很好理解的，方式明确，维护简单。除此而外，测试用例文档必须介绍所有重要的特征，必须覆盖所有重要的逻辑流，伴随着实时和实际可接受的输入。