测试用例的重要性及设计方法

上一篇 / 下一篇  2014-07-31 06:54:06 / 个人分类:转载

 

 

    测试用例的设计在很大程度上是由简单到详细且逐步完善的一个过程。其依据需求文档、概要设计、详细设计等参考资料。假如在测试过程中没有测试用例或仅有简单的功能描述,那么测试过程难以控制或测试结果将毫无可靠性而言。网上对测试用例的具体设计的文章也数不胜数了,笔者在这也不重复阐述。

 

    因此,笔者对测试用例的总结为:

    简单的测试用例可靠性低、重用性差,且可能导致不同人员理解不同。

    详细的测试用例可靠性高,而且便于估计执行所需时间,易于控制。

 

    我们在设计测试用例时应当考虑以下几点:

第一、     时间要求。[是否在测试过程中,测试用例的执行易于控制

第二、     执行者。  [应当考虑不同的测试用例执行者对系统的了解程度

第三、     理解程度。[当把测试用例交付给他人执行时应不需要过多的解释

 

所以,测试用例的设计重要性显而易见。

登录功能,是一个大家熟悉得不能再熟悉的功能了。但是往往这类看似简单但却不简单的功能,在设计测试用例时却漏洞百出。下面,我们通过Google邮箱的登录窗口实例进一步了解测试用例的设计。

 

²   简单的测试用例

用例编号

功能点

操作过程

预期结果

备注

01

登录

能够正确处理用户登录

正确处理登录操作

 

²   一般的测试用例

用例编号

功能点

操作过程

预期结果

备注

01

登录

输入正确的用户名和口令可以进入系统

登录成功

输入用户名或口令错误无法进入系统

登录失败

 

²   详细的测试用例

用例编号

功能点

操作过程

预期结果

备注

01

登录

输入正确的用户名和口令(均为6位),点击[登录]按钮

进入系统

输入正确的用户名和口令(均为10位),点击[登录]按钮

进入系统

输入正确的用户名和口令(均为68位之间),点击[登录]按钮

进入系统

用户名为空,点击[登录]按钮

提示输入用户名

不能进入系统

用户名为空格,点击[登录]按钮

提示无效用户名

不能进入系统

用户名小于6位,点击[登录]按钮

提示用户名太短

不能进入系统

 

通过以上三个测试用例,我们可以很直观的了解到测试用例具体实现价值。但是,我们达到第三种测试用例设计技巧时还是不能体现其“详细”的概念化。

到这,可能很多读者会问为什么?其实,答案很简单。虽然我们在设计用例时把过程体现了,但并没有把测试数据容入当中。那为什么又要写入相应的测试数据呢?我们可以分三点看待这个问题。第一、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大,不利于测试员理解,导致难以控制和执行;第二、通过将用例参数化,可以简化用例,使测试用例逻辑清晰,数据与逻辑的关系明了,易于理解;第三、有利于提高测试用例的复用性。所以,在加入输入(数据或操作等)、输出(结果数据或预期结果等)的测试用例可以很好的重复使用。

 

²   详细的测试用例(含测试数据)

用例编号

功能点

操作过程

测试数据

预期结果

备注

“用户名”

“口令”

01

登录

输入正确的用户名和口令(均为6位),点击[登录]按钮

user10

pass10

进入系统

正确的用户名和口令(6)

输入正确的用户名和口令(均为10位),点击[登录]按钮

user000010

pass000010

进入系统

正确的用户名和口令(10)

输入正确的用户名和口令(均为68位之间),点击[登录]按钮

user789

“pass789”

进入系统

正确的用户名和口令(6-8)

用户名为空,点击[登录]按钮

“”

pass

提示输入用户名

不能进入系统

无用户名为空

用户名为空格,点击[登录]按钮

“空格”

pass

提示无效用户名

不能进入系统

用户名为空格

用户名小于6位,点击[登录]按钮

user

userpass

提示用户名太短

不能进入系统

用户名小于6

用户名大于10位,点击[登录]按钮

user0000011

userpass

提示用户名太长

不能进入系统

TAG:

oneworldyg的个人空间 引用 删除 oneworldyg   /   2014-07-31 07:31:58
测试用例来源:
1)设计文档中的Use Case,按照Use Case步骤记录可用于

软件的可接受性测试;
2)按照界面功能区或者系统功能模块,按照用户可能的操

作,分块或跨模块,形成系统的功能性测试(可能包括

Normal-通常操作,Exceptional-异常操作,Boundary-边

界测试);
3)将曾经发生过的Bug记录下来,形成是测试用例,可以

作为Regression Testing的一部分。
oneworldyg的个人空间 引用 删除 oneworldyg   /   2014-07-31 07:29:09
1)功能测试用例:包含功能测试、健壮性测试、可靠性测


2)性能测试用例:包含性能测试、压力测试、强度测试;
3)集成测试用例:包含接口测试、健壮性测试、可靠性测


4)安全测试用例:安全测试用例;
5)用户界面测试用例:包含用户界面测试用例、少量功能

测试用例;
6)安装/反安装测试用例:安装/反安装测试用例
oneworldyg的个人空间 引用 删除 oneworldyg   /   2014-07-31 07:16:20
1)完整性:无论ISO9000还是Cmm都要求做任何事情要有记

录、书面文档。如果不设计测试用例,那是随机测试,很

难度量是否做的完全。——设计测试用例可以有效防止又

被遗漏的测试点或功能,对测试完整性有重要的意义;
2)沟通性:对于开发和测试的沟通建起桥梁
3)管理性:便于测试管理和具体量化,同时通过收集缺陷

可以分析确证是漏测还是缺陷复现;评估测试结果编制测

试报告的度量基准(如测试覆盖率、测试合格率以及重要

测试合格率是多少等)
4)指导性:指导测试的实施
oneworldyg的个人空间 引用 删除 oneworldyg   /   2014-07-31 06:59:46
゛無磿頭.㊣

编号:每个测试用例的唯一编号,有且于其和测试结果、错误报告等其他文档的链接。
测试模块:讲述此测试用例测试的大模块。
标题:用简单的一句话来描述测试用例。
测试目的:描述设计此测试用例的目的是什么。
测试级别:按照测试用例的重要性来给不同的测试用例分级别。
预置条件:执行此测试用例之前需要做的准备。
操作步骤:测试人员执行测试所需的运作。
预期结果:在检查点上待测功能应有的正常反应、运作或显示。
实际结果:待测功能在操作后所表现的反应、运作或显示。


编写测试用例时应该认真思考:
1、如何保证测试用例的覆盖率;
2、如何确保紧跟开发文档的变化;
3、如何把用例的重复性限定在适度的范围内;
4、如何实现测试用例的更新;
5、如何实现测试用例的重用性;
 

评分:0

我来说两句

日历

« 2024-03-24  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 12787
  • 日志数: 51
  • 建立时间: 2014-04-25
  • 更新时间: 2018-06-02

RSS订阅