上一篇，分享了关于测试用例的一些观点，以及实际工作过程中的做法；－》基础必备知识普及：测试用例十问十答。

今日，继续聊聊测试用例；

如下是百人计划成员五娃对测试用例的理解。供大家参考。欢迎说说你的不同观点。

1、测试用例的定义：

百度百科的解释是这样的：测试用例是为某个特殊目标而编制的一组输入、执行条件以及预期结果，以便测试某个程序路径或者合适是否满足特定需求

俗话理解：通过一组输入输出来验证某个需求的状态或者结果是否满足预定结果

2、测试用例的好处：

A、有效、快速的了解待测需求

B、测试用例的编写、执行数量可以评估需求的覆盖度

C、测试用例的细化程度、可以作为阶段性工作的排期的依据

D、测试用例的输出可以将人为因素的影响减少，如a同学编写用例后，b同学可以依据用例进行执行功能

总结：思路清晰、避免遗漏、跟进测试进度、历史数据参考、避免重复性劳动

3、何时开始设计测试用例？

需求文档定版后，即可开始陈列测试点和编写测试用例

4、如何设计测试用例？

A、首先将需求文档或者产品文档中的规则转述为每个用例的检查点

B、单个用例最小化原则，即一条用例只做一件事

C、先从单个模块或者功能点入手写用例

D、借助常用的测试用例设计方法，如等价类、边界值、因果图等

总结：

n1：除了上诉的内容外，还需要考虑兼容性问题、浏览器兼容性、操作系统兼容性，如果是app侧的还要考虑中断测试、弱网测试等等

n2：设计测试用例时也要注意涉及到的数据库中的字段值是否正确

n3：需要注意关联模块的用例设计

n4：注意新增接口、新增字段的用例的设计

5、实际工作中如何设计用例？

A、根据需求文档找到角色和功能模块的匹配关系，输出Usecase图

UseCase图

B、输出流程图（如果产品有输出流程图那是最好的了，没有只能测试自己输出流程图，并发给产品进行查缺补漏）

C、依据业务规则、UseCase、流程图输出测试用例

6、测试用例的评审与更新？

测试用例是一定要评审的，因为每个人都有自己的测试盲区，所以不要认为自己考虑的是全面的

评审参与人员，相关产品、开发、测试参与即可

评审的意义：将测试用例编写中遇到的疑问在此得到答案，并引导开发、产品功能进行思考补充现有用例（查缺补漏）

测试用例更新：一是评审后需要更新，在者就是测试过程中需要更新，测试结束后根据线上反馈情况进行更新

7、所有项目都需要写测试用例么？

测试用例的编写需要根据待测试任务的大小、紧急程度、测试人员数量等多方面衡量

对于大中型任务，个人建议还是要写详细的用例，因为写用例就是思考的过程

对于紧急小型任务，可以写测试点

对于新人负责的模块，一定要写测试用例（本人写或者老人写完，新人执行）

8、测试用例的颗粒度？

其实和问题7有一定的关联，在问题7的前提下，仅仅就测试人员来说是否写测试用例，写何种颗粒度的测试用例其实取决于测试人员本身的水平

如何写用例、怎么写、写到何种粒度都需要依据当前公司的项目的情况决定。

但是依旧建议无论测试人员本身水平如何，都需要输出基本的测试用例或者测试点。

首先这是对自己的负责，其次随着时间的流逝，你能保证记录下曾经所有的用例么，

这也就是为何建议输出用例或者测试点的原因，不要认为测试用例的设计没有任何的含量，

恰恰相反，测试用例的设计反而是最核心的技能。

老徐补充：

阅读此文的正确姿势是对比昨天的文章 －》基础必备知识普及：测试用例十问十答。

测试用例，是必备技能，也是很多从业者欠缺的技能。 掌握测试用例设计技巧，除了看理论书籍，还得多实操、多练习、多思考、多总结。 

更重要的是，掌握测试用例的度，什么时候写用例、什么颗粒度、解决什么问题等等。

欢迎交流。

推荐三篇有价值的文章：

软件测试从业者，Linux知识从入门到玩转（必读）

这里是18位测试工程师的工作日常。

测试经理每天到底在忙些什么？

<End>

我是IDO老徐，Tester，十年测试职业老鸟，分享原创职业观点，经验，答疑解惑。希望通过自己的文字分享能改变测试职业现状，让测试从业者整体水平提升一个Level 。

老徐所有原创文章

第一时间发布至此公众号

长按二维码/微信扫码  关注老徐

老徐私人微信isTester

有问题，可留言

试着，在公众号对话框，

回复任何你想要的关键词，自动获取资料。