51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 41245|回复: 70
打印 上一主题 下一主题

[资料] 测试人员在需求阶段应做哪些工作

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-5-30 14:48:44 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
相信很多人跟我一样有过这样的困惑,那就是在需求阶段我们测试人员应该做些什么?下面就将看过的一篇文章贴出来与大家一块分享。

首先,测试用例和测试工作本身是不断完善的,在开发过程的初期,可以认为是需求阶段,或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档,可以在这个阶段检查完了需求文档以后开始设计测试用例。这里,对于需求文档的检查主要是两个方面:
1.检查需求文档描述的正确性,愚以为测试人员要对于真实的系统所涉及的业务非常熟悉,比如一个简单的财务软件,那么测试人员本身就要对会计工作熟悉,财务制度熟悉,在检查需求
文档的时候不要迷信所谓的“都是用户真实的需求”,这里存在两个问题,一是用户是否真的能正确地描述自己的需求,二是需求人员是否真的能正确地理解需求。另外,还有一个用户的嘘气是否符合行业规范的问题,如果不符
合,那么是否要确认——这里存在一个隐患,用户可能会在开发的后期突然要求他们自己要走行业规范,让你的需求变动,所以要事先明确好。
2.检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方,对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。
那么在检查完了需求之后,就可以开始设计测试用例了,愚以为,在这个阶段因为没有开始设计工作,所以对于测试用例的考虑不能仅仅从界面出发——虽然RUP中对于用例的要求有这一项。因而测试用例的设计应该从业务角
度出发,从实际业务出发来设计测试用例。当然,在测试用例的描述时,要尽量考虑怎样同应用程序脱离开而仍然具有有效性。
当然,这个阶段所实现的测试用例是不过完善的,只能涵盖某些内容,但是我认为这些用例不仅仅全部都是功能测试用例,而且在整个项目中都将有效。
不过,当缺少需求文档时,那就要发挥测试人员自己的能动性了,要主动的工作,而不是被动的等待。要自己尝试着去熟悉实际业务,要尽量通过自己所能想到的方法来开展工作。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    开心
    2016-2-27 08:48
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    推荐
    发表于 2007-6-2 11:45:09 | 只看该作者
    谢谢分享!
    回复 支持 0 反对 1

    使用道具 举报

  • TA的每日心情
    开心
    2014-12-8 13:22
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    3#
    发表于 2007-6-4 15:25:33 | 只看该作者
    需求阶段,感觉很多需求还是未确定状态。此时研发人员对需求的要求更实际些
    最终成型的需求文档,在大部分还是以研发可以满足为基准

    测试人员的需求依据,还是需求文档,在此之前,难道只能做些测试方案?
    如何更好的参与需求阶段,还是需要很多人去研究完善
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2007-6-12 14:49:08 | 只看该作者
    不错!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2017-1-13 07:55
  • 签到天数: 22 天

    连续签到: 1 天

    [LV.4]测试营长

    5#
    发表于 2007-6-28 15:58:49 | 只看该作者
    不过,当缺少需求文档时,那就要发挥测试人员自己的能动性了,要主动的工作,而不是被动的等待。要自己尝试着去熟悉实际业务,要尽量通过自己所能想到的方法来开展工作。

    嗯,一定要主动。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2007-7-5 10:44:49 | 只看该作者
    提倡测试工作早介入,我个人觉得从开始调研客户需求测试人员就介入是一种最理想状态,一起和需求调研人员完成需求工作,这个过程测试人人员可以从测试的角度考虑用户所提需求是否可行,开发人员可以从开发的i角度考虑
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2007-7-16 09:37:51 | 只看该作者
    谢谢分享
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-7-19 16:06:41 | 只看该作者
    不错..谢谢分享...
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-7-17 10:34
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2007-7-20 13:28:12 | 只看该作者
    谢谢,记得刚开始工作时,我们领导就问过我这样的问题,那时就没有一点儿的概念,现在真的感觉知识、经验都是一点儿一点儿累计的,当然还需要不断的了解新的信息。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2007-7-23 10:10:40 | 只看该作者
    我们这测试人员同时也负责需求分析,这头一次做,还真得注意这些细节。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2007-7-23 14:54:59 | 只看该作者
    学习了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2007-7-23 21:10:36 | 只看该作者
    需求文档还应该尽量的可以的详细,规范,尽量的覆盖更多的条件和枝节。
    一份好的需求文档,应该从业务,技术上层层覆盖。让软件测试人员拿到手就能够写出良好的测试用例。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-7-26 12:24:47 | 只看该作者
    sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2007-8-2 16:15:00 | 只看该作者
    sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-8-6 18:02:15 | 只看该作者

    同感

    现在我们公司就让我从一开始参与新的项目,去客户现场调研,收集需求分析报告。可是到现在不知道进一步开展工作,测试用例也不知道怎么写????
    要努力加油啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-8-6 21:18:53 | 只看该作者
    注意需求接受的标准,这里到时产生你的测试用例和接受标准
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-8-7 10:45:42 | 只看该作者
    是啊,谢谢分享
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-8-10 09:46:11 | 只看该作者
    不错
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-8-24 16:59:45 | 只看该作者
    谢谢分享thks
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-9-11 17:09:27 | 只看该作者
    fen  xiang
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 03:28 , Processed in 0.088974 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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