关于测试用例编写(二)

上一篇 / 下一篇  2007-02-11 12:32:50 / 个人分类:测试用例

在(一),困扰我的问题主要是如何把Test Requriements和Test Plan连接起来。

我们先来了解一下什么是“软件需求(software requirements)”,即“软件需求”定义

软件需求是(1)用户解决问题或达到目标所需的条件或权能(Capability)。
       (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
       (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
        (IEEE软件工程标准词汇表(1997年)中定义)

 

我们再来看看什么是“测试需求(test requirements)”?

在“http://bbs.51testing.com/viewthread.php?tid=269”用举例的方式阐述什么是测试需求,而且描述得很不错(个人意见)。为了朋友们阅读方便,我把网址内容直接粘贴过来了

Brian Marick
测试需求的概念比较简单。例如,比方说一个计算平方根的程序,如果输入一个大于或等于零的数,程序可以给出一个结果;如果输入一个小于零的数,程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试;对零非常接近的负数进行测试,这就是两个具体的测试需求。

在一个更加复杂的程序中,你可以将打算测试的项目做成一个列表。但是,这些测试需求都不会确定具体的测试数据。例如,一个银行交易程序,一个测试需求是试图支付客户的金额为负数,另一个测试需求是交易中的客户并不存在,等等。你有一系列这样的测试需求,它们并没有指出具体的数值或数据,如客户的姓名。

测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
1)插入一个新的条目
2)插入失败-条目已经存在
3)插入失败-表已满
4)哈希表在插入前为空
这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。

从上面关于“软件需求”和“测试需求”解释的内容,总结一下几点内容:

1 它们的主要读者不一样,前者主要针对开发人员,后者主要针对测试人员;

2 软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。开发人员一般在受限的情况下(用户需求,业务需求,非功能需求)以开发软件(功能需求);而测试人员必须参考“软件需求”内容,从各自工作的内容出发(主要白盒,黑盒,性能等)编辑出适合自己的“需求”,即是“测试需求”。

现在既然明确了“测试需求”,那么测试人员就要开始工作,设计自己的测试用例(Test Plan),来最大化地发现软件中的BUGs。

最后,还是那句话,请各位朋友多多提意见,小弟再此感谢拉。


TAG: 测试用例

 

评分:0

我来说两句

我的栏目

日历

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

数据统计

  • 访问量: 4965
  • 日志数: 7
  • 建立时间: 2007-02-06
  • 更新时间: 2007-04-03

RSS订阅

Open Toolbar