测试用例范例.docx

测试用例范例.docx

《测试用例范例.docx》由会员分享，可在线阅读，更多相关《测试用例范例.docx（16页珍藏版）》请在冰豆网上搜索。

测试用例范例

讨论用TestDirector管理测试用例

编制时间:

2007-03-16

编制部门:

测试组

编制人:

郭宏元

“测试用例”虽有国标作蓝本，但实际中，一直以来“测试用例”是所有测试人员有争议的地方，此所谓“仁者见仁，智者见智”。

而“法无定法，则无定则”，所有的规范与标准都是围绕更适应人们的工作环境而创建。

在此，我就我的一些体会在此与大家分享。

一般来说，“测试用例”的编写主要分三大类，贯彻的原则与基本架构如下：

分类：

1、对验证过程的一个记录；

2、展现一个功能；

3、描述一个场景步骤；

原则：

1、有“对象”属性的描述；

2、阐述了某个“对象”的方法或事件。

3、对属性、方法或事件有详细的定义。

基本架构：

1、目的；

2、前提条件；

3、输入步骤（输入动作或数据，预期结果）

以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。

以方便统一测试用例的编写，并保证使用最用效的测试用例来保证测试质量。

我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能，而在于验证软件应该达到的功能，这样可以去除软件开发过程中的随意性。

所以下面就明确测试用例的“目的”、“范围”、“原则”是什么？

以及采用的方法做了一点描述。

1、目的：

围绕测试名称或满足实现测试功能而进行。

2、范围：

适用于所要测试的质检项目。

3、功能测试用例编写原则

3.1单元测试功能用例的编写目的

单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能，由于是单个模块所以无法检验关联性，可能会牵扯到数据库的操作，例如：

删除时，需要查看数据库是否完全删除了数据。

3.2集成测试功能用例的编写目的

集成测试功能用例的目的在于验证软件连接时，模块的连接是否正确（及数据的传递是否正确）。

.我们的软件中体现出来的是，是否正确调用界面，界面之间显示的数据是否正确，特别是财务、费用、数据方面的。

集成测试用例的编写过程中，经常将功能用例与业务流程混合编写，因为在集成测试时需验证业务流程中的数据正确性，以及界面之间的数据传递的准确无误。

3.3系统测试业务流程用例的编写目的

系统测试业务流程用例的目的在于验证软件最终数据的准确性，我们的软件体现为，手工数据与报表数据的一直性。

用例与用例之间有着一定的关系，目的性十分明确。

4、测试用例设计的原则

4.1全面性

指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。

4.1.1数据库程序基本的增、删、改功能

增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。

输入的数据可能有无限种组合，此时可以采用等价类划分和边界值法，下面有较详细的说明。

删除的测试用例比较简单，只有操作没有数据的输入，但是应该在“备注”中注明，删除的限制条件，以及数据库中应该删除的表的情况，有条件限制时，测试用例应该包含各种删除条件，必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。

4.1.2对于无输入的操作，应该详细描述其具体的操作步骤和结果

例如：

选择“用户帐号”，可以通过多种途径进行，此时应具体描述程序从何处进入，通过何种操作，达到查看“用户帐号”界面。

对于报表的测试用例，最好紧跟在输入数据的后面，并且应该给出报表输出的数据的界面图（含数据）。

对于不便书写测试用例的情况，应该在备注中说明，并写出可能的操作步骤。

例如：

对于文件夹的拖动，说明左右拖还是上下拖，结果如何就可以了。

4.1.3单元测试用例的书写是使用一条数据，多种可能的情况考虑。

但是对于其余各阶段的测试用例，必须考虑多条数据时的情况，此时主用是针对新增多条数据后，进行删、改、拖等情况的考虑。

4.1.4针对有结算的测试用例，数据的应考虑存在跨年、跨月的数据。

4.2正确性

包括数据的正确性和操作的正确性。

首先保证测试用例的数据正确。

其次预期的输出结果应该与测试数据发生的业务吻合。

操作的预期结果应该与业务流程在程序执行的结果吻合。

4.3符合正常业务惯例

测试数据应符合用户实际工作业务流程，实际就是测试用例的先后顺序，先新增，后修改或删除，不能将删除放在第一位。

4.4仿真性

人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；

4.5可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果不同，达到的目的是，任何人，均可以根据测试用例，单独进行测试。

5、测试用例设计的方法

测试用例的核心是输入数据。

预期输出是依据输入数据和程序功能来确定的，也就是说，对于某一程序，输入数据确定了，预期输出也就可以确定了，至于生成/销毁被测试对象和测试的方法等，是所有测试用例都大同小异的，一般只有操作而没有输入。

因此，我们讨论测试用例设计方法时，重在输入数据。

　　而我们都知道，输入数据包括四类：

参数、成员变量、全局变量、IO媒体。

IO媒体是指文件、数据库或其他储存或传输数据的媒体，例如，被测试函数要从文件或数据库读取数据，那么，文件或数据库中的原始数据也属于输入数据。

这四类数据中，只要所测试的程序需要执行读操作的，就要设定其初始值，显然，把输入数据的所有可能取值都进行测试，是不可能也是无意义的，我们应该用一定的规则选择有代表性的数据作为输入数据，主要有三种：

正常输入、边界输入、非法输入。

每种输入还可以分类，也就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入也是可以通过的。

下面举例说明：

（1）正常输入

例如“字符串Trim函数”，功能是将字符串前后的空格去除，那么正常的输入可以有四类：

前面有空格；后面有空格；前后均有空格；前后均无空格。

（2）边界输入

上例中空字符串可以看作是边界输入。

再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：

0和100。

（3）非法输入

非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：

文件不存在；目录不存在；文件正在被其他程序打开；权限错误。

如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。

一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。

实际上，一个合格的功能模块测试，编码时对上述三种输入都是必须考虑的，否则代码的健壮性就会成问题。

下面详细介绍一下“等价类划分法”与“边界值分析法”的原则与测试用例的编写。

5.1等价类划分法

5.1.1确定等价类的原则

1）如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

2）如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类.

3）如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类

4）如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合

5）如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）

6）如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类

5.1.2测试用例的编写

1）为每一个等价类规定一个唯一的编号

2）设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过

3）设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止

5.2边界值分析法

5.2.1测试用例的编写

1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据

2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小的小1的数作为测试输入数据

3）根据详细设计说明书的每个输出条件，使用前面的原则

4）如果程序的详细设计说明书给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列

5）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例

6）分析详细设计说明书，找出其他可能的边界条件

6、测试用例编写格式细则

举例用TestDirector生成的测试用例。

下面有两份样式举例，其中一份是摘录的别人的“测试用例”，希望在此可以“抛砖引玉”，对大家对测试用例的具体编写有一定的启示。

另一份是根据自己编写的“概要设计文档”写的“操作员新增开户帐号”“测试用例”，以供大家参考分析。

TestDirector中没有关于测试用例的“目的”，以及该用例的“前提条件”等字段，因此，可以将用例的目的和前提条件等在“描述”字段中进行描述，注意事项等也可以在此描述，如果有测试数据的话，可以在描述字段中对测试数据进行描述，具体的测试数据以文本或Excel方式保存，作为该测试用例的“附件”。

样式举例：

用例名称:

启动客户端程序

路径:

……

主题:

ZJ2006……

设计状态:

Design

设计者:

***

创建日期:

2006-06-11

用例类型:

MANUAL

描述:

目的：

1.检查服务程序能否以设计的五种方式正确启动客户端程序

1.1.菜单启动

1.2.快捷键启动

1.3.鼠标双击启动

1.4.定时启动

1.5.隔时启动

前提条件：

1.服务程序已经运行；

2.客户端程序尚未运行；

Steps:

StepName

Description

ExpectedResult

Step1

运行服务程序Server.exe

1.服务程序运行；

2.服务程序在系统托盘中显示为图标；

Step2

1.在服务程序图标上单击右键；

2.在弹出的悬浮菜单中选择【启动在线升级程序】；

1.弹出悬浮菜单，包括【启动在线升级程序】、【启动定时服务】、【启动隔时服务】和【关闭服务程序】四个菜单项；

2.1如果柜台系统需要更新，则弹出窗口提示是否更新，选择“Yes”按钮则启动客户端程序进行更新，选择“No”则关闭提示窗口；

2.2如果柜台系统不需要更新，则弹出窗口提示不需要更新，点击“OK”按钮关闭提示窗口；

3服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的temp目录中；

4version.txt文件的内容与服务器端的version.txt文件的内容一样；

5服务程序根据version.txt文件的内容与本地对应的文件进行比较，将需要升级的文件生成下载清单DownLoadList.ini

6如果需要更新并确定要更新，则下载更新文件并解压缩到Download目录中；

Step3

双击服务程序图标

1如果柜台系统需要更新，则弹出窗口提示是否更新，选择“Yes”按钮则启动客户端程序进行更新，选择“No”则关闭提示窗口；

2如果柜台系统不需要更新，则弹出窗口提示不需要更新，点击“OK”按钮关闭提示窗口；

3服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的temp目录中；

4version.txt文件的内容与服务器端的version.txt文件的内容一样；

5服务程序根据version.txt文件的内容与本地对应的文件进行比较，将需要升级的文件生成下载清单DownLoadList.ini

6如果需要更新并确定要更新，则下载更新文件并解压缩到Download目录中；

Step4

按启动服务快捷键（Ctrl+F12）

1如果柜台系统需要更新，则弹出窗口提示是否更新，选择“Yes”按钮则启动客户端程序进行更新，选择“No”则关闭提示窗口；

2如果柜台系统不需要更新，则弹出窗口提示不需要更新，点击“OK”按钮关闭提示窗口；

3服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的temp目录中；

4version.txt文件的内容与服务器端的version.txt文件的内容一样；

5服务程序根据version.txt文件的内容与本地对应的文件进行比较，将需要升级的文件生成下载清单DownLoadList.ini

6如果需要更新并确定要更新，则下载更新文件并解压缩到Download目录中；

Step5

修改配置文件Config.ini中的定时启动时间（SpecifyTime）

1.到启动时间后，如果柜台系统需要更新，则弹出窗口提示是否更新，选择“Yes”按钮则启动客户端程序进行更新，选择“No”则关闭提示窗口；

2.到启动时间后，如果柜台系统不需要更新，则弹出窗口提示不需要更新，点击“OK”按钮关闭提示窗口；

3服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的temp目录中；

4version.txt文件的内容与服务器端的version.txt文件的内容一样；

5服务程序根据version.txt文件的内容与本地对应的文件进行比较，将需要升级的文件生成下载清单DownLoadList.ini

6如果需要更新并确定要更新，则下载更新文件并解压缩到Download目录中；

Step6

修改配置文件Config.ini中的隔时启动时间长度（IntervalTime）

1.每间隔隔时启动时间长度后，如果柜台系统需要更新，则弹出窗口提示是否更新，选择“Yes”按钮则启动客户端程序进行更新，选择“No”则关闭提示窗口；

2.每间隔隔时启动时间长度后，如果柜台系统不需要更新，则弹出窗口提示不需要更新，点击“OK”按钮关闭提示窗口；

3.如果尚未对上一次的提示进行操作，而在此之间，升级状态发生了变化，到新一次隔时启动时间长度后，正确显示提示信息；

4服务程序下载version.txt并生成DownLoadList.ini文件到服务端程序的安装目录下的temp目录中；

5version.txt文件的内容与服务器端的version.txt文件的内容一样；

6服务程序根据version.txt文件的内容与本地对应的文件进行比较，将需要升级的文件生成下载清单DownLoadList.ini

7如果需要更新并确定要更新，则下载更新文件并解压缩到Download目录中；

用例名称：

操作员新增开户帐号

路径:

……

主题:

ZJ2007……

设计状态:

Design

设计者:

***

创建日期:

2007-06-11

用例类型:

MANUAL

描述:

目的：

1.检查操作员是否能正常新增开户帐号

1.1.新登记开户

1.2.预受理开户

1.3.开户卡开户

前提条件：

1.用户已在自服务进行了预受理注册；

2.批量开户模块已有批量开户卡帐号；

《概要设计文档》——操作员新增开户帐号案例：

登陆进入操作员模块

点击“开户”，进行开户操作：

DOCASE

CASE新登记开户

1、打开“帐号开户”界面；

2、帐号ID自动加1；

3、录入必填字段；

4、依次录入其它界面内容

5、检查判断界面录入字符的合理、合法性；

IF录入字符不符合数据表结构约束

THEN系统给出提示

6、点击“确认提交”按钮；

IF必填字填==NULL

THEN系统判断，并一一给出提示；

检查判断用户帐号、用户名称、安装地址是否有重复值；

IF有重复值

THEN系统给出提示

保存界面录入内容

CASE预受理开户

（用户已在自服务进行了预受理注册；）

1、打开“预登记受理”查询界面；

2、按条件查询或模糊查询出要进行预受理的帐号；

3、点击“受理”按钮，

受理成功，进入“帐号开户”界面

重复“新登记开户”的2—6的操作；

CASE开户卡开户

（批量开户模块已有批量开户卡帐号；）

1、打开“开户卡受理”查询界面；

2、按查询条件或模糊查询出要进行受理的帐号；

3、选中要受理的帐号；

IF帐号“受理标志”=“1”

Then“受理”按扭激活，可以受理

点击“受理”按钮，进入“帐号开户”界面；

Else“受理”按钮灰色，不可以受理；

4、进入“帐号开户界面”；

重复“新登记开户”的2—6的操作；

EndCASE

Steps:

StepName

Description

ExpectedResult

Step1

登陆进入操作员模块

1）帐号/密码都正确；

2）能正常登陆；

Step2

点击“开户”，进行开户操作

可以看到三个选项：

1）新登记开户；

2）预受理开户；

3）开户卡开户；

Step3

选择“新登记开户”

1、打开“帐号开户”界面；

2、录入必填字段；及依次录入其它界面内容

3、点击“确认提交”按钮，系统自动检查；

1、帐号ID自动加1；

2、如果录入字段里的字符不合法，系统有提示

3、系统检查必填字段如果为空，给出提示

4、系统检查断用户帐号、用户名称、安装地址不能有重复值，否则给出提示

5、用户资料保存成功

Step4

选择“预登记开户”

1、打开“预登记受理”界面；

2、查询要受理的“预登记”帐号；

3、点击“受理”按钮；

4、进入“帐号开户”界面，同上操作，点击“确认提交”；

1、查询条件或模糊查询条件可以查询出要受理的预登记帐号；

2、受理按钮执行有效，进入“帐号开户”界面；

3、帐号ID自动加1；

4、如果录入字段里的字符不合法，系统有提示；

5、系统检查必填字段如果为空，给出提示；

6、系统检查断用户帐号、用户名称、安装地址不能有重复值，否则给出提示；

7、用户资料保存成功

Step5

选择“开户卡开户”

1、打开“开户卡开户”界面；

2、查询可受理的“开户卡”帐号；

3、点击“受理”按扭；

4、进入“帐号开户”界面，同上操作，点击“确认提交”；

1、查询询条件或模糊查询条件可以查询出要受理的开户卡帐号；

2、如果受理标志为“1”，受理按钮可以执行并有效，进入“帐号开户”界面；否则受理按钮为灰色，不可执行；

3、帐号ID自动加1；

4、如果录入字段里的字符不合法，系统有提示；

5、系统检查必填字段如果为空，给出提示；

6、系统检查断用户帐号、用户名称、安装地址不能有重复值，否则给出提示；

7、用户资料保存成功

Step6

……

……

Step7

Step8