百度百科的解释是这样的：测试用例是为某个特殊目标而编制的一组输入、执行条件以及预期结果，以便测试某个程序路径或者合适是否满足特定需求
俗话理解：通过一组输入输出来验证某个需求的状态或者结果是否满足预定结果
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的前提下，仅仅就测试人员来说是否写测试用例，写何种颗粒度的测试用例其实取决于测试人员本身的水平
如何写用例、怎么写、写到何种粒度都需要依据当前公司的项目的情况决定。
但是依旧建议无论测试人员本身水平如何，都需要输出基本的测试用例或者测试点。
首先这是对自己的负责，其次随着时间的流逝，你能保证记录下曾经所有的用例么，
这也就是为何建议输出用例或者测试点的原因，不要认为测试用例的设计没有任何的含量，
恰恰相反，测试用例的设计反而是最核心的技能。
