51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5805|回复: 17
打印 上一主题 下一主题

[求助] 没有需求文档如何写测试用例?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-5-17 10:29:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我所在的公司比较小,项目也没有一个正式的需求文档,采用的是敏捷开发的模式,需求点总是在变动,我是新进来的测试,有个基本成形的软件产品了,要我按照这个基本成形的产品来写测试用例,这个怎么写啊?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2011-5-17 14:36:36 | 只看该作者
回复 1# jingwdongw

我觉得有成型的产品,就有功能的实现,有功能至少可以设计出功能测试用例来。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-6-24 09:23
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    3#
    发表于 2011-5-17 16:47:38 | 只看该作者
      我与楼主现在的情形很相似,正在摸索当中。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2011-5-25 22:41:56 | 只看该作者
    既然有基本成型的软件产品,就应该有软件本身的帮助文档,这个文档是个设计用例的重要依据
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2011-6-1 14:36:39 | 只看该作者
    我现在和楼主的情况一样
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2011-6-1 14:37:27 | 只看该作者
    我现在和楼主的情况一样
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2011-6-1 16:11:38 | 只看该作者
    我也一样,写了功能用例,结果界面这些设计又变了,我又得改用例,天呀。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 2011-6-9 15:05:08 | 只看该作者
    回复 2# 水中的鱼
    已经实现了大部分功能,都是一点点增加的,也没有成文的需求文档,我又是新人,所以慢慢摸索着。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
     楼主| 发表于 2011-6-9 15:05:35 | 只看该作者
    回复 3# 相逢似梦中
    有结果的时候分享一下哦!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2011-6-9 15:07:01 | 只看该作者
    回复 4# yichunlei123

    是的啊,可是现实情况不乐观啊,尤其是小公司,需求总是变化的话,也没有人力去一直维护需求稳当了,一旦新人来了就不停的问了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
     楼主| 发表于 2011-6-9 15:07:14 | 只看该作者
    回复 6# orz4shift
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2011-6-14 17:08:15 | 只看该作者
    我和楼主情况一样啊,怎么写呢 ?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-5-21 10:44
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    13#
    发表于 2011-6-17 17:24:07 | 只看该作者
    对呀,我们公司的需求文档天天的变呢,最后都不知道到底是怎么样的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2011-11-11 14:07:31 | 只看该作者
    需求--用例--测试--BUG管理,整个过程对于小公司来说应该是一步到位的。先把大概的需求逐条写成要件的形式,由每条要件引出测试用例,对应每条测试用例测试并管理BUG。需求变更或需求追加时,你只需要追加要件的个数,引出相应的用例即可。当然如果需求变化较大,或需求杂乱无章那就另当别论了。要做好变更控制和版本控制。同时要警惕项目风险,做好风险控制。希望我说的这些能对您起点作用。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2011-11-11 16:10:00 | 只看该作者
    我现在的情况基本上也是一样,但是软件基本已经成型。
    只要熟悉业务逻辑,其他的都不是很大的问题。主要是要站在客户的角度上去思考问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2011-11-11 23:34:48 | 只看该作者
    和LZ一样。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2011-11-12 10:54:53 | 只看该作者
    没有需求的话,需要你自己去整理出Function List,然后细化成Test List。这样基本上测试就能有依据了。
    当然,一些很细节的东西,需要你根据同行业产品的做法和你自己的经验去判断了,因为没有需求文档的规定。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2011-11-13 18:04:53 | 只看该作者
    可以参照目前成型产品或以往的数据进行测试用例编写工作;也可以参照同行软件功能进行编写。
    如果有新需求的话可以考虑从新需求和成型产品的交互,兼容,界面统一风格,同一功能逻辑的一致性等方面入手
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-25 19:34 , Processed in 0.084889 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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