51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 6467|回复: 12
打印 上一主题 下一主题

[求助] 需求频繁变动中,如何进行用例维护及测试

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-12-23 11:46:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
小弟所在公司,用例都按照老需求完成,产品已经提交测试,但经常出现后期需求的变动,导致原来的用例很多都不适用,浪费了很多测试时间,各位碰到这样的问题如何进行处理及沟通的?

而且最郁闷的在于辛苦写出来的用例可能用一次就浪费掉,也导致后期用例维护非常繁琐

恳请各位达人意见及先进的用例管理理念。。。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-12-23 11:50:31 | 只看该作者
要随着需求的改变去改用例的,公司里都是这样的。像一些常用的用例,例如像增、删、改、查你可以做成类似的模板,用的时候小改一下就OK了。可以减少很多的时间
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2008-12-23 11:52:36 | 只看该作者
看来各公司都会出现需求经常变动的情况?那前期想的用例不是都浪费掉了。。。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-12-23 13:01:33 | 只看该作者
我不太清楚你们公司测试用例的流程是什么,需求变更,那是很正常的事情,我们公司一个项目都要快纳期了
还在变,但是客户变,我们需要完善什么
我们公司一般都是根据客户和我们确定的需求规格说明书或者说是详细设计书,开发人员负责编码,测试人员负责写测试用例,先写出测试观点,就是针对每个机能或功能在写测试case,这样可以保证客户修改了哪部分,我直接对应
还有客户需求的变更,这些又没有相应的统计,我们的工作怎么能叫没有用呢,对这部分工作量的统计,变更的纪录,这些量化的东西都必须纪录和保留,否则客户哪天问你为什么要延期,为什么要增加成本怎么办?
总之,我们的过程要完善,具体探讨,可短消息联系
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-12-23 18:23:35 | 只看该作者
我觉得需求变动频繁会导致成本大增,还是需要一定的手段去控制需求变更的。
记得什么培训里说的需求工作一方面要帮助用户在前期想到他们还没有提出来的需求,把后期的变动缩到最小;另一方面也要引导说服用户去向着我们系统实现的方向上去使用,或者有时要增加一些规范流程类的工作,让需求变更不那么“容易”,自然而然会减少一些需求变更。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2008-12-26 11:50:07 | 只看该作者
我们公司现在是自己研发产品并提交测试,所以需求变动很多,也没有固定的模板用例,导致现在习惯性加班。。一直苦于没有合适的方式来减少这种情况。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-1-17 21:57:27 | 只看该作者
汇总需求信息,根据需求来写用例。这样变需求即可变用例,不会漏掉测试点。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2009-2-3 11:54:00 | 只看该作者
原帖由 superlm 于 2008-12-23 11:46 发表
小弟所在公司,用例都按照老需求完成,产品已经提交测试,但经常出现后期需求的变动,导致原来的用例很多都不适用,浪费了很多测试时间,各位碰到这样的问题如何进行处理及沟通的?

而且最郁闷的在于辛苦写出来的 ...

迅速的反應及敏捷的響應
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-2-17 22:26:40 | 只看该作者
需求跟踪矩阵
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2009-6-5 15:25:20 | 只看该作者
我公司的需求也是经常变动,而且项目管理上也十分的混乱,导致现在通常是先测试,再补测试用例.虽然我已做了很大努力,规范这方面,但是领导的推行力度不大,以至于现在很多测试用例没有完善!郁闷!
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2009-6-19 00:48:28 | 只看该作者
对需求很不稳定的模块,不设计详细的用例,只要让自己看得懂就行,甚至就只写个记号;在测试用例不可继承的情况下,选择花大量时间写下所谓高质量的测试用例是没有意义的,因为除了你以外,可能没有第二个人再去用它,测试用例就不需要写得很细,让大家都明白,只需要写得让自己懂就行了。

在测试用例会得到多次复用的情况下,应该详细设计,这样可以缩短其它人进入测试的时间;短时间来看设计这样的用例可能是耗费了时间,长时间来看,它实际上是节约了测试成本。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2009-6-19 11:06:44 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2009-7-2 11:19:28 | 只看该作者

烦恼呀

烦恼呀
测试用例的维护真的蛮烦恼的
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-5-9 21:26 , Processed in 0.081317 second(s), 26 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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