51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 18111|回复: 26
打印 上一主题 下一主题

需求评审时测试人员需要关注哪些方面?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-12-8 13:04:34 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
如题。第一次参加,不知道怎么准备,也不知道要做什么,
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2004-12-8 13:33:38 | 只看该作者
站再测试的角度,主要还是可测不可测的评审
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2004-12-11 12:24:44 | 只看该作者
1、先挑错。看看他们要评审的文档,说法是不是前后一致。
2、如肚皮所说。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2004-12-15 14:40:23 | 只看该作者
就是从测试角度将需求分解为可测的功能点,考虑如何测试这些功能点。
对不可测功能点的解决办法了,可以和项目经理/系统架构师讨论决定。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-1-17 16:00:15 | 只看该作者

谢谢,我接着楼上的说。。。

对不可测的功能点,要加以分析:
1)可以继续拆分成多个可测的用例,说明原来的粒度太大
2)不可测是因为根本不是需求
3)不可测是因为暂时没有测试方法(需求本身没有问题)
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2005-3-8 11:33:06 | 只看该作者
一是检查软件需求的正确性、完整性、一致性
二是保证软件需求的可测性
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2005-3-24 16:41:07 | 只看该作者
给你具体一点的吧,他们太笼统了。。
需求上往往规定的是1+1,但没说1+1=几
我们比较关注的就是这个结果了
因为功能测试是看结果的~~~~~~~~~
当然我说的只是一方面
还有一些简单的,比如他们说能进行“部分查询”

这就存在不可测试性了,因为不知道具体怎么查,不知道要查什么~~

我说话比较朴素,你应该听的懂,哈
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2005-4-22 10:20:53 | 只看该作者

最近参加了几个项目的需求评审工作

站在测试人员的角色参加需求评审工作,本人认为有以下几个要点:
1、        检测需求是否表达了它本身的意义同,对需求本身进行一次详细的测试;
2、        需求的描述是否准确;
3、        需求的描述是否完整;
4、        站在用户的角色,要对用户的要求进行详尽的分析后对需求进行的评审;5、        以测试员的角色,审查需求的可测性和易测性,即需求是否定义了清晰的测试标准和测试规范;
还有点非常重要的是要进行需求评审前,测试人员应该尽可以详细的先了解项目的需求,并且收集尽可能多的与项目相关的专业知识。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2005-6-15 10:12:24 | 只看该作者
需求测试就是提出文档的中疑问及缺陷吧?
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2005-6-16 09:41:53 | 只看该作者
需求评审的时候,基本上是你发问的过程,前提条件是:项目经理已经把提前两天初稿给参与评审的人了。只有这样评审才能真正的达到效果,要不也是走过场。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2005-6-17 12:04:04 | 只看该作者
1、读需求,看你读的懂吗?和你测试小组的人沟通,看有没有不同理解?如果你读不懂或有不同理解,那好,这就是需求明确性和无二义性的问题,请你提出;
2、从测试的角度看你看的每一条需求都可以写出对应的测试用例吗?如果不能对应需求写出测试用例,那好,这是需求可测性的问题,请你提出;
3、总之,你看到需求是你要参照展开测试工作的,所以,从你测试工作的本身考虑就可以了,置于其他方面,你如果没有精力和时间,会有其他角色的人考虑的
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2005-6-21 12:12:40 | 只看该作者
还是觉得各位兄弟讲的太概,不具体,有没有实例的文档看看阿!
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2005-7-7 11:30:03 | 只看该作者
关注文档化后良好需求的十个特性:
完整性、正确性、一致性、可行性、无二义性、健壮性、必要性、可测试性、可修改性、可跟踪性。

另外,评审前最后将基于产品的项目的业务需求、用户需求和功能需求好好组织、理解、梳理一遍,这样对于整个产品就有了更为全面的了解。
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2006-9-25 16:12:30 | 只看该作者
学习
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2006-12-27 18:00:42 | 只看该作者
很有帮助。谢谢各位精彩回答 sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2006-12-29 14:23:33 | 只看该作者
先明确那些是可以测试的
对于可以测试的部分,在写测试用例时需要哪些条件?尤其是对那些模棱两可的内容
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2007-1-19 10:17:06 | 只看该作者
觉得yiyihui说的那几点都非常正确!
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2007-4-12 15:46:14 | 只看该作者

回复 #4 sincky 的帖子

没错,就是L4的答案
主要更加需求分析来测试的!
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2010-6-11 15:00:08 | 只看该作者
应该是站在,测试的角度去看问题就好了。
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2010-7-13 12:03:26 | 只看该作者
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-9-21 20:38 , Processed in 0.091807 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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