关于测试用例的20道经典问答题

测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行，是一系列有次序、受控制的状态变化过程。

如果不记下来，很可能执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作也没有改进作用（没有参考），所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。

设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也利于用例评审。

对于中大型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例（加深对业务功能的理解）。

写用例的思路：产品需求 -> 测试需求 -> 测试点 -> 测试用例

可分为以下几个要点：

用例要点：需包括与其他模块耦合关系、用例的级别（level0、level1）考虑哪些需求必须先完成，哪些需求可以后完成。

首先要保证产品的质量，测试用例的数量并不能决定质量的好坏，要做到覆盖全面，提倡高质量的用例设计。

excel、word；也可以是工具，如testlink、zentao、xmind等。

考虑以下几个主要元素：

首先一定要熟悉产品、熟悉需求，对需求进行分析和拆解非常重要，需求熟悉过程中，不理解的地方，一定要找产品及时沟通，确定结果。

其次项目开发过程中，每期的用例都要不断总结，学会总结，尽可能的保证少漏。其实这个与测试思维关系密切，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。

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

A. 什么是用例评审？ 用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。

B. 用例评审的目的？ 为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题）；为了避免三方需求理解不一致；为了每个测试人员的质量标准与项目要求标准达成一致。

C. 评审前需要做哪些工作？ 用Xmind，将测试点梳理出来；在脑图上，补全预期结果和实际测试结果，便于测试结果跟进；用例写完后，先做自检，有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论；和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。

D. 用例参加人员？ 主要是产品、开发、测试、项目负责人、运营;

E. 用例评审时间？ 对于敏捷开发项目，建议控制在半小时以内；如果需求太复杂，功能点太多，半小时讲不完，那么建议对功能点划分优先级，优先评审优先升级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过；

F. 用例评审形式？ 先对功能复杂，优先级高、疑问多的用例进行评审，再评审功能简单，优先级低的功能点。对于评审过程中，还没有结论的问题，可以记录下来，作为会后讨论跟进的重点。另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。

G. 正式评审？ 评审要按用例的优先级，功能的复杂程度进行；评审时间尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；超过5分钟无法确定结果的问题留作会后讨论跟进。

H. 评审结束后需要做些什么事？ 第一时间整理测试用例，把修正的内容重新整理补全；会上未确定的内容，会后继续跟进，直到确定结果；都无疑问了，做个简单的用例评审总结（如修正了哪些功能点，补全了哪些，哪些模块功能有变动？哪些功能推迟到下一期做？）。

先自检，自检完毕，列出有疑惑的点，评审之前，把用例提前发给相关的开发、产品，预留时间告诉他们先看，再统一时间进行评审。

评审后需要更新、测试过程中需要更新、测试结束后根据线上反馈情况进行更新。

不是发现多少bug，而是产品上线之后，有多少漏测问题。作为测试从业者，必须明白自己的核心价值在何处，把它作为目标，才能正确指引我们平时的测试工作中的具体内容及细节落实。