51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【111期】:聊聊想出国找测试工作最核心的那些事!2020不玩虚的,先来一波技术PK! 【征稿】疫情当下手头紧?这波投稿补贴很及时! 自学软件测试那点事
查看: 49908|回复: 84

生命周期半年的项目需求是否有必要写用例?(2009-2-9 )获奖名单已公布

[复制链接]

该用户从未签到

发表于 2009-2-9 13:58:58 | 显示全部楼层 |阅读模式
背景描述:对于稳定客户的项目类测试,经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动,导致BA/PM等都未能及时更新需求,从而给测试组的需求经常是非最新版本,且测试阶段的需求也经常有小变动,导致用例效果不大甚至失效.(可能是针对需求说明书失效,更多情况是针对实际需求-即系统实现方式失效).

感谢会员joycena提供此精彩话题!如果你也有矛盾的问题想提出来和大家一起讨论,请点击此处>>
说不定下期PK的话题就是由你提出的哦,请快快参与吧!




奖项获奖名单奖励答案连接
最佳话题PK手Jackc
当当购物卡50元+最佳PK手勋章
39#
正方观点 (744)

仍有必要写用例

反方观点 (686)

没有必要写用例

回复

使用道具 举报

  • TA的每日心情
    开心
    2014-10-24 09:36
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2009-2-9 15:40:46 | 显示全部楼层
    需求总是在变动的,但变是相对于不变的需求而言的,软件在各阶段,需求总是变化的。有变化,就要记录变更,就要记录对应的用例。这样做可以使需求,用例,结果的可跟踪。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-9 16:52:07 | 显示全部楼层
    不管软件的生命周期是多长时间,写测试用例是必须的。测试的宗旨是使软件的bug降低到最小,对客户的影响最小,如果没有测试用例,测试工程师会想出很多冗余的测试用例,浪费了很多时间,最后有可能漏掉致命的缺陷。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-10 10:21:03 | 显示全部楼层

    必要的前提是代价

    1. 正如对方aman_cao所说: "需求总是在变动的", 但显然他曲解了使用了后半句"但变是相对于不变的需求而言的", 我们使用论点的背景是"经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动".
        如果需求变动很小或者相对很小,我关注的是重新写还是跟踪它的变化?那一点更有价值更有必要? 我们都知道需求决定用例,如果需求变了测试用例必然需要更新, 但是当测试用例"效果不大甚至失效"时,有必要去写么?
    2. 而zynuage所说:"不管软件的生命周期是多长时间,写测试用例是必须的",请问写测试用例在软件生命中的哪个周期?请问合理的流程和开发模式又是什么?而将测试的重点放在测试用例上,显然又和辩友的"测试宗旨是使软件的bug降低到最小"是矛盾的,当需求不断变化的时候,如何保证测试用例的可依据性?

    下面我提出我方观点:
    1. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试的依据可以适当进行调整,譬如:i, 最新的需求个功能列表. ii, 公司软件规范要求列表. iii, 软件需求变化跟踪列表.
    2. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试重点不是测试用例编写, 而是如何快速准确的定位客户的最新需求, 在软件生命周期中可开发协调工作,保证最优的实现, 将项目代价降低到最低,避免重复冗余的劳动.

    以上观点, 从软件工程角度来说可能是不合理的,但是在我们大部分国内软件公司中确实就是这么去做的,"存在即为合理", 因为这样的论题背景在软件工程也是要尽量避免的.

    -----抛砖引玉,不吝赐教..
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-10 15:17:23 | 显示全部楼层

    测试用例的意义以及适用性

    开门见山的说,我认为不需要写测试用例,但我们需要简化版的功能覆盖点。

    一、测试用例意义:
        测试用例主要是督促测试人员熟悉理解业务情况,辅助全面回归测试,梳理测试思路,测试用例的好坏,在交叉测试中尤为凸显。
        测试用例的引入,致使测试人员在测试之前就需要对业务很了解,知道如何着手测试,在这个过程中寻找模块间关联点,不断补充进测试用例。就好比油画,通过不断的渲染和填充,才能使我们发表一幅优秀的作品。他的作用就在于让我们深入透彻的了解系统架构和业务知识,以及数据关联性等。
        在回归测试以及交叉测试中,用例让我们可以很快速的想起测试思路和过程,帮助其他测试人员熟悉测试模块,检测其他人员的测试用例是否全面等。有很多时候,我们往往会突然冒出一些有亮点测试思路,但人又偏偏是记性差的生物,到后面也就忘记的干净,测试用例的记录,帮助我们将所有的测试思路和过程记录,辅助我们进行记忆。举个例子,一个人拿着模板来写字,您说能不容易吗。交叉测试中,别人对你的测试模块一无所知,再讲一遍,不仅自己感觉繁琐,也影响进度时间,而好的用例不需要讲解,就可以很好的引导测试人员进行测试工作。举个例子,盲人走路很困难,但有了导盲犬后,他们就可以非常方便的出行。
        通过上面这些,可以看出测试用例的重要性,可以说,测试用例是不可缺少的。

    二、测试用例适用性
        测试用例如果想实用,那麽他所带来的工作量就会非常大,我们需要很多的时间来完善和补充,所以如果项目变动很小,那麽测试用例将是长久性的保持效用。但如果项目变动大,则测试用例的维护成本将使测试质量明显下降。
        通过这些我们可以看出,测试用例在这种情况下又是不能引入的。

    三、解决方法
        为了解决测试用例的意义所带来的效益,测试用例适用性所带来的缺陷,我认为应该引入功能覆盖点来平衡这两方面因素。
        功能覆盖点是对所测试项目功能点的一个简要概括,编写功能覆盖点可以让我们去熟悉业务系统,平且将功能点,关联点等简单罗列,让我们纵观测试的广度和深度。在需求变动情况大的情况下,维护功能覆盖点的成本要远远小于测试用例,他所带来的效用是实效而灵活的。

        综上所述,测试用例在需求变动大的项目中,是不需要引入的,而应该引入更为实效的功能覆盖点,辅助测试工作的开展和考察。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-11 11:33:15 | 显示全部楼层
    用例是必需的.软件在用例在.如果时间赶,那只能在后面补咯
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-11 13:48:30 | 显示全部楼层

    追踪需求进行测试

    编写维护测试用例是需要很多人力和时间成本的,如果维护用例的速度都赶不上需求变化的速度,在这种情况下不如根据需求来测,而不是测试用例,日常追踪需求的变化,根据需求的变化进行对应的测试。当然测试工程师必须要有责任心,在没有用例的情况下也能尽可能地进行各种各样的有效测试,只要保证需求100%被覆盖就可以了。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-11 17:50:36 | 显示全部楼层
    觉得还是有必要去设计测试用例的。自由测试避免不了会漏测
    随着需求的变更在跟着更改测试用例。前提测试人手要充足
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-11 17:59:01 | 显示全部楼层

    有必要的,侧重点偏移下。

    我认为还是有必要的,不能因为周期短而忽略这部分,对于管理来说,会有漏洞的。
    至于怎么写,整个项目组需要达成一直,尽量简化,模板化,节约成本。
    而至此引发了一个问题,版本的管理问题,因为需求变更的频繁,版本的管理要跟上,不然写起用例来,会跟不上进度。
    拙见,
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-11 18:00:21 | 显示全部楼层
    扔有必要写用例,不能因为时间短就忽略.
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 10:52:10 | 显示全部楼层
    按照CMMI的要求,需求进行变更后,是需要做记录的,所以应该要写用例。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 15:03:36 | 显示全部楼层

    必要

    非常必要
    测试用例是需要写的!!
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 15:05:04 | 显示全部楼层

    有必要写用例,但可以写简化用列

    虽然需求在经常变动, 但一个相对小的时间里需求总是稳定的,所以用列还是需要写,不仅是在写用列的过程中可以发现一些细节性的问题,而且还可以让测试人员更好的理解需求。由于需求经常变动,我们的用列也可以稍微简化,可以只写到没有用列应当关注的点,测试步骤就可以不写。呵呵个人观点。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 15:21:02 | 显示全部楼层
    我认为仍有必须写测试用例,因为通过测试用例除了可以发现BUG,同时还要依据用例对BUG进行重现,如果不修改测试用例,仅仅通过个人的想象来测试,很难做到BUG的重现,而且有了测试用例,其它人员也能容易的接收对软件的测试工作。同时随着需求的改变,修改测试用例,也更加深了测试人员对需求的理解。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 15:21:59 | 显示全部楼层
    对于需求变更非常频繁的项目可不用花过多时间在测试用例上面,如果非得写用例,就会因用例搞人仰马翻。测试活动是靠测试计划指导的。所以只要在需求变更时候,根据需要调整测试计划即可。但需求变更后是必须记录的。测试覆盖还可以通过需求的覆盖来保证。我在现在中就是这样做的。非常赞同pupu840323说的前两点。
    回复

    使用道具 举报

  • TA的每日心情
    无聊
    2018-3-20 17:07
  • 签到天数: 35 天

    连续签到: 1 天

    [LV.5]测试团长

    发表于 2009-2-12 15:57:17 | 显示全部楼层

    必要:但可以分情况编写或补充

    个人认为:在项目时间和人员允许的的情况下可编写测试用例;条件不具备的情况下可以在项目完成后补充。对照需求变更,用例起一个项目跟踪的作用,可在项目中有效重复利用。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 16:08:44 | 显示全部楼层
    没有必要写
    费神浪费时间.
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 16:10:39 | 显示全部楼层

    写需求(或测试用例)是为了更好的确认测试目标和提高团队工作能力

    写需求(或测试用例)是为了更好的确认测试目标和提高团队工作能力


    1、很多开发团队认为写不断变化的需求(或测试用例)是浪费时间,何不用这个时间做开发和测试
    但事实是,随着时间的推移,同时因为没有需求文档(或测试用例),每个人记住的资料又非常有限(谁都不能否认自己的记忆力随着年龄的增长不断老化,二者人总有个头痛脑热的时候,有时如果不是开会或小组讨论也许会遗忘通知某些人),最差的后果一有分岐导致大家找PM或客户做确认。

    2、由谁来写需求(或测试用例),一个小团队并没有划分真正写需求文档(或测试用例)的人
    做为测试人员,当公司的开发未完成这项任务时,只有测试人员自己整理需求(或测试用例),在测试过程中不断完善需求(或测试用例)。

    3、无论谁写文档(或测试用例),从长远来看。对个人或公司都是一笔很大的财富
    一个经常写需求(或测试用例)的人,势必非常了解所写项目的功能,当二次出现同类的需求(或测试用例)时,可以在第一时间做出有利的判断(因为之前有失败的经验做后盾)。
    对于一个新人,是锻炼和提升自我的最佳机会。
    对于公司是一大笔无形资产。

    4、如果一个项目做好了形成公司的产品,原有的需求文档(或测试用例)优势就更大了
    当团队进行2次开发或升级时就有参照的依据,可以屏弃不适合的模式,寻求高效益的功能。
    如果是外资企业,国内做好了需求(或测试用例),想想2期开发只能由国内开发(测试)团队来完成,可以说增加大家的工作机会。(现在可是经济危机)

    个人观点仅供参考,希望和大家一起讨论。

    [ 本帖最后由 sweetxmy 于 2009-2-12 16:13 编辑 ]
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 16:22:15 | 显示全部楼层

    来尝试一下

    这种情况在做客户现场项目时候实在是太常见了。

    首先批评一下公司方的客户联络人员,对客户没有一点影响力,就这么容忍他随便改需求吗?带来的工作量和不断的返工次数,如果对方不付钱,你们老板不会吹胡子瞪眼吗?

    其次既然现象已经发生,为了避免开发人员和测试人员都跟着重复劳动疲于追命,那就做一个好的需求跟踪矩阵吧,做不到?偶说第三点

    再次测试人员不能够只拘泥于需求规格说明书啊,当然测试用例的第一版还是要依据这个的,后面就得多靠自己把握啦,灵活多变是必须得能力哈。

    最后,该写的还是写吧,免得最后会发现统计工作量时没有必要的支撑数据。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-12 16:32:38 | 显示全部楼层

    支持

    谁都不能否认自己的记忆力随着年龄的增长不断老化,二者人总有个头痛脑热的时候,有时如果不是开会或小组讨论也许会遗忘通知某些人
    回复

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2020-4-1 16:47 , Processed in 0.083041 second(s), 30 queries .

    Powered by Discuz! X3.2

    © 2001-2020 Comsenz Inc.

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