基础必备知识普及：测试用例十问十答。

chenjianlin

测试用例，是测试从业者必备的基础知识。

然而，很多测试从业者，一晃，工作经验多年，却连基础的测试用例都没过关...

今天，再次回归基础，给大家普及下测试用例的一些知识。

之前分享过几篇测试用例方面的文章？建议看看：

如果你还在纠结是否需要写测试用例，测试用例什么粒度合适时，看看此文 。

没有需求文档 ！如何测试？如何设计测试用例？

OK，如下贴一篇百人计划成员，关于测试用例的专题讨论，整体讨论质量分享不错；能解决你的一些问题。

上周日下午1点钟，我们第五组9位同学一起参与了关于设计测试用例的必要性？及其相关引申话题。

首先，非常感谢大家的积极参与。老徐经常说学习是自己的事，相信参与百人计划的每个人也都是觉得自己某方面还不够优秀，期待学习提高的。所以大家的自主参与和最终收获肯定是成正比的。

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

下面针对我们的首次主题分享讨论做个简单小结。

1、测试用例是什么？

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

2、设计用例是否有必要？

好记性不如烂笔头，纯大脑思考，想象的东西如果只是存在脑海中，很可能到执行的时候部分测试点就遗漏了。另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。

故测试用例一定要写，颗粒度可是情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图载出测试点。

3、如何写测试点呢？

根据需求及设计交互稿，先列功能点，后扩展功能点为测试点（作为用例的标题）。有必要的时候借助产品、开发、后端的力量，保证用例的覆盖度，学会借力。

测试点（注：这里不是测试用例，用例一般都比较详细，开发不一定会花费很多时间去做自测）写完后，可发给开发做自测，部分遗漏点可以在测试时进行记录与补充。

4、设计用例的益处？

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

5、测试用例有哪些设计方法？

等价类划分法，边界值分析法，功能图法、错误推测法、因果图法，场景法等。

6、如果保证用例的覆盖度？

首先一定要熟悉需求，需求分析，拆解非常重要，需求熟悉过程中，不理解或有疑惑的地方，一定要找产品进行及时沟通，确定结果。其次项目开发过程中，每期的用例都要不断总结，学会总结，尽可能的保证少漏。其实这个与测试思维关系密切，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。

7、用例写完，我们先要做什么？

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

8、哪些人应该参加用例评审？

产品，开发（客户端，后端，前端等，每个公司情况不一，可根据实际来），测试需一起进行用例评审，评审力度需加大，不能只是走个过场，需要有产出，否则有可能体会不出用例评审的作用。

如果开发不重视，可直接拉上研发总监一起评审。我们公司每次用例评审结束后，有需要调整的地方，我都会做个简单小结，作为补充点，并周知所有评审参与人。这样做的目的是，告诉大家，我们做了什么事，做的结果如何，后续还有什么改进的地方。及时总结，目标清晰，可带动大家积极参与。

9、用例评审有必要逐条念吗？

用例评审没必要逐条念标题和预期结果，这样很浪费时间，就我们公司目前的项目周期，每期测试用例的测试点有200条左右，如果挨个念下来，那得不少时间，建议可以根据条件总结性的过，大部分用例结果是已知的，步骤和预期结果是不用讲的。除非个别有疑惑的测试点，可以花费时间一起讨论沟通下。

10、对于开发不自测的，测试该如何做？

建议加入提测环节，测试给出提测标准，没达到就打回。或者先给产品进行功能主流程验收（设计对UI进行验收），产品说通过验收了再给测试提测。之前老徐讲过，要开发自测可自上而下进行推动，加入某个环节也需要技术总监的支持。

开发自测可以使测试人员轻松点，有更多的时间去测复杂的逻辑问题，而不是只测需求功能问题。同时，给研发一点压力，开发的功能模块质量也会有所提高。多次提测不通过也可以作为研发考核的一个标准。

xuejun1992

分析很透彻，感谢你的分享