做专业的Tester，写牛掰的Testcase！

测试积点老人

编写测试用例可以说是一个测试人员最重要的工作之一。那么，如何写一份优秀的测试用例呢？我估计很多人就会懵了。啊？什么？大家的测试用例不都差不多吗？怎么还有优秀和不优秀之分呢......
当然有！好的歌曲听起来旋律优美动听，歌词妙笔生花意味深远；好的文章或通俗易懂或感人肺腑；好的书画让人心旷神怡叹为观止。同样，好的用例，结构明朗，条理清楚，表达清晰，总结一下就是：易看，易做，易管。

言归正传，想写好一份用例，其实要从用例的受众对象来分析，就更容易实现。
用例本质上是与受众对象沟通的一种媒介。受众对象一般是本项目相关人员，例如测试人员（包括手工测试人员及自动化测试人员）、开发人员、测试经理、项目经理等等。那么，测试用例设计者就是通过测试用例与上述受众对象沟通。所以，一份好的测试用例的标志，就是它能够很顺畅地搭建起测试用例设计者和受众对象之间的沟通桥梁。
所以，沟通好就意味着用例好。
测试用例要素详解接下来，我们从测试用例要素角度来说说如何写一份优秀的测试用例。
测试用例要素如下：

1.        编号

2.        标题

3.        摘要

4.        模块

5.        功能点

6.        预置条件

7.        操作步骤

8.        预期结果

9.        是否可实现自动化

虽然这些要素作为测试人员的我们都司空见惯了，但是，我们是否都深刻理解了这些要素的目的、用途和重要性了呢，我想这并不见得。所以，接下来，我带大家详细解读一下这些要素。
测试用例要素之标题、预置条件、操作步骤、预期结果
首先，我们看一下上述要素中，最重要的几个要素：标题、预置条件、操作步骤和预期结果。
有的人可能会说，对于用例执行来说，标题不重要，真正执行测试用例的时候，还不是要看详细的用例内容。殊不知，用例的标题其实是要概括测试用例的“中心思想”的，就像一篇文章的题目或者一首歌曲的名字一样。说的夸张一点，测试用例的标题是测试用例的“魂”。
为了让大家感受更深，我们看一下实际的例子。假如测试一款APP，我列举几种不同表达程度的标题，体会一下。

A.        APP测试用例一

B.        APP功能测试用例一

C.        测试XX APP的用户登录功能

D.       测试XX APP，已注册的用户，使用密码方式登录，能够成功登录

大家更希望用例标题是以上哪种情况呢？
觉得用例标题不重要的同学，很有可能就会选择A和B两种。选择C的，要么是觉得用例标题不那么重要，要么是因为对测试场景分析的不够细致。相对来说，选项D是更合适的测试用例标题。
有了一个好的测试用例标题之后，接下来，就是围绕这个标题详细描述预置条件、操作步骤和预期结果。预置条件在操作步骤和预期结果的前面。有的时候，由于项目要求不同或者使用用例管理工具的不同等因素，操作步骤和预期结果可能出现分开或者合并。但是，不管哪种情况，操作步骤和预期结果这两种要素都是必不可少的，二者缺一不可。缺少预期结果，将无法判断此测试用例是否执行通过；缺少操作步骤，更是让执行人员无法继续下去。
预置条件是执行此用例的大前提，一般是执行该用例的基本条件，经常是描述系统性的、环境准备方面的要求。预置条件不满足，后面的操作步骤将没有必要继续。等到预置条件满足之后，才轮到去看操作步骤。
操作步骤的编写也有一定的讲究，每个操作步骤的操作对象和操作行为要明确、无歧义，操作步骤的数量不宜过多或者过少。步骤数量过多，会出现其中一个步骤不通过影响整个用例的执行，从而导致评估测试覆盖和产品质量的时候，无法快速确定真正的风险所在。并且，当原来导致Fail的缺陷修复之后，还要整个用例重新执行，效率较低。步骤数量过少时，会影响测试执行的连贯性，同时会导致不同程度的重复工作量。
前面说了用例标题、预置条件、操作步骤及预期结果需要注意的问题，接下来我们看一下其他的用例要素。
测试用例要素之摘要
摘要部分主要是对整个用例内容的要点进行摘录和概括。这部分当用例标题很清晰，或者用例步骤相对较简单的情况下，有的时候可以省略。如果用例管理工具要求必填，则可以同用例标题相同。除上述情况外，这部分通常不应该被省略，因为它是介于用例标题和详细用例之间的一种要素。当详细用例相对比较复杂时，可以通过摘要部分更多地了解用例概况（相对于用例标题而言）。
测试用例要素之模块、功能点模块和功能点两个要素的作用，是对用例的一种分类。通常模块为大，功能点为小，也就是说，一个模块下面包含若干个功能点。那么，当用例依据模块和功能点进行分类之后，有好几个方面的好处：第一，在后续用例维护时，我们就知道哪些模块或功能点得到了覆盖，哪些遗漏了，可以持续对用例进行优化改进；第二，如果后续版本改动较小时，我们就可以按照可能影响到的模块或功能点进行挑选用例，而不是全量执行；第三，通过模块和功能点进行统计用例，就可以知道哪些模块和功能点的缺陷较多，哪些的缺陷较少，这样就可以有针对性的进行分析、评审、改进等活动。
测试用例要素之编号、是否可实现自动化编号比较好理解，用于识别、查找用例，在整个用例库中是唯一指定的，便于精准定位用例，同时也更方便团队内部、跨团队针对用例的沟通和交流。

是否可实现自动化，这个要素主要是为了让自动化团队能够清楚用例库中哪些可实现自动化，哪些无法实现自动化。标记为可实现自动化的用例，自动化团队可根据投入产出比来评估是否实现自动化。

提升测试用例质量的“秘籍”上面介绍了测试用例的要素，大部分篇幅只是说了每个要素的作用。但是，如何提升测试用例的质量呢？有没有一些有效的方法呢？下面我结合我的经验，跟大家分享一下，希望对大家有一些启发和帮助。
先设计，再编写首先，不要一上来就写用例，更不要一条写完再写下一条。想输出高质量的用例，正式写之前必须列提纲，而这个提纲的框架来源于对于需求的详细分析。也就是说，输出用例是一个需求分析->模块分析->功能点分析->编写用例的过程，当然，在编写用例之后，专家评审也是必不可少了，经过评审->修正->复核之后的用例，会让测试用例更加完善，达到一定的高水平。
撰写提纲（需求分析->模块分析->功能点分析）的过程，我一般习惯使用Xmind思维导图工具，当功能点分析完成后，基本就可以转到EXCEL去编写用例了。前面提到不要一条一条的写，意思是说，要将模块/功能点的框架全部列在表格中，形成一个有条理的用例结构（骨头），然后再去推进、扩展，将详细用例描述（肉）塞满。
如何提升测试覆盖率

第二点，测试用例的质量取决于测试用例的覆盖率，覆盖率高则用例质量高。那么如何提高测试用例覆盖率呢？白盒、灰盒的覆盖率不是本文的讨论范围。而提升黑盒测试覆盖率，一个切实有效的方法就是质量属性法。国际标准 ISO/IEC 25010:2011规定了软件质量属性有使用质量和产品质量两个方面，产品质量主要关注产品固有的特性。包括功能适应性、效率兼容性、易用性、可靠性、安全性、可维护性、可移植性共8个属性，每个属性还有若干个子属性。使用质量主要是关注用户在使用软件过程中的满意度、效率、风险避免等方面。归纳一下，其实就是功能测试、非功能测试以及用户体验测试。如果测试用例全面覆盖了这些质量属性，则毋庸置疑，用例质量一定是较高的。

高手是怎样炼成的第三点，在掌握了质量属性分析方法的基础上，另外一个影响用例质量高下的因素，就是对产品的熟悉程度和理解深度了，也就是产品业务能力及产品经验。经验是通过项目实战一点一点的积累、总结、炼化出来的。这个几乎没有捷径。只能通过多思考，多交流，多总结来提高。