测试用例编写的“侯式标准”

　　作为软件测试人员，执行测试用例是我们进行测试工作的主要手段，测试用例设计的好坏，直接影响着测试工作的质量。一个“好”的测试用例能保证测试的质量，规范测试的进程，进而提高我们的测试效率。

　　那什么样的用例才是好的测试用例?这已经是一个老生常谈的问题，大家见仁见智 ，众说云云，不一而足。

　　而我的TL--候风的一句话，让我对用例的有了新的认识。他是这样说的：一个好的测试用例，就是在保证测试质量的前提下，做到以下几点：当一个不熟悉业务的人，看到你的用例后，要知道用例的测试目的什么，知道你要做什么，怎么做，为什么这样做，取得了什么什么成果。

　　做什么?

　　做任何事情，都要有的放矢。我们在编写一个测试用例的时候，应该知道我们要的是什么，这也是编写一个用例最基本的前提。

　　怎么做?

　　即具体的如何设计用例。就是要明确用例的执行过程，这样在测试的时候才能有章可循，摸着石头过河

　　为什么这样做?

　　这要求用例编写者要明确设计用例时用到的方法(如边界值，等价类等等)，以及用这种方法的好处。

　　取得了什么成果?

　　这要求用例编写者明确通过这个测试用例,我们将取得什么效果。比如一个采用边界值设计的用例，取得的效果是在极端的数据下，软件是否能够正常执行功能。

　　标准规范中包含的主要元素如下：

　　测试名称(Test Name)：测试用例编号和测试用例名称。

　　创建日期(Creation Date)：测试用例创建时间，系统自动产生。

　　设计人员(Designer)：测试用例设计人员

　　状态(Status)：测试用例状态

　　描述(Descrīption)：测试用例详细描述

　　步骤名称(Step Name)：测试步骤名称

　　步骤描述(Step Descrīption)：测试步骤详细描述。

　　预期结果(Expected Result)：测试预期结果。

　　要是按照“候风标准”(暂且这样命名，还没申请侯哥批准)，我们要对上面的标准进行规范的优化以及内容的明确

　　1测试名称

　　A)用例根据各用例的功能来命名，尽量做到简洁明了。

　　B)一级目录使用各项目的顶级菜单名称来命名，如功能、业务、查询三大类;

　　C)二级目录使用顶级菜单下的二级菜单名称类命名，用户可根据名字判别该用例是测试哪个模块的。

　　2 描述(Descrīption)：测试用例详细描述

　　要用通俗易懂而又简洁的语言描述描述用例的设计目的，让其他人能够明白我们在什么

　　3 步骤描述

　　步骤描述要详细而不臃肿，条理而不凌乱。

　　同时，在规范上要增加以下几项

　　测试目的(Purpose)：编写这个测试用例的目的

　　测试方法选择依据(Foundation)：即用这样方法的好处

　　测试取得的成果(Achievement)：通过执行用例取得的成果

　　用例执行的前提条件(Precondition)：执行用例的需要满足的前提

　　这样，一个完整的用例包含的元素如下：

　　测试名称(Test Name)

　　测试目的(Purpose)

　　测试方法选择依据(Foundation)

　　用例执行的前提条件(Precondition)

　　创建日期(Creation Date)

　　设计人员(Designer)

　　状态(Status)

　　描述(Descrīption)

　　步骤名称(Step Name)

　　步骤描述(Step Descrīption)

　　预期结果(Expected Result)

　　测试取得的成果(Achievement)

　　综上所述，测试用例的“侯式标准”的精髓，就是把自己的思维过程尽可能的展现到用例中，做到即使一个完全不懂业务的人，看到我们的用例后，也能知道业务的需求和流程，知道测试的过程，能够无障碍的执行我们的用例。

　　以上是我学习用例编写过程中的一些体会，不足之处请大家批评指正。让我们一起交流分享，共同进步成长。

　　参考书籍

　　《软件测试》 作者：[美]Paul C.Jorgensen 译者：韩柯 杜旭涛 机械工业出版社

原文转自：http://www.uml.org.cn/Test/201208294.asp