51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2608|回复: 2
打印 上一主题 下一主题

[原创] 如何通过软件需求或产品需求,来编写测试需求呢?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-8-13 16:51:00 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
如何通过软件需求或产品需求,来编写测试需求呢?希望大家多提提建议!谢谢
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

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

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

  测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
   
  这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
  
  1)插入一个新的条目
  2)插入失败-条目已经存在
  3)插入失败-表已满
  4)哈希表在插入前为空
   
  这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。


转自:http://www.mike.org.cn/blog/index.php?load=read&id=360

大哥,啥事google一下。google不到了再提问。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2008-8-19 17:27:48 | 只看该作者
谢谢你回复,那就是说:测试需求应该是从客户的角度,参考软件需求来编写测试点或测试项!
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-17 04:15 , Processed in 0.067971 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表