51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【周活动】 找茬--心里圈的故事 !【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【106期】:如何树立正确使用Python做开发的习惯 【征稿】提交你的测试成绩单! 【专题】用尽一切办法只为让你学好用例 自学软件测试那点事
楼主: 默默巫

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

[复制链接]

该用户从未签到

发表于 2009-2-19 14:04:46 | 显示全部楼层
以上是偶以前工作的一些体会,有些怨气在里面(看来还没有磨练到“心平如水”的境界),大家见谅~
回复

使用道具 举报

该用户从未签到

发表于 2009-2-19 17:13:13 | 显示全部楼层

测试用例是工作成果的体现

虽然需求总在变动,但测试用例还是应该写。这既体现了你的工作成果,也是出现问题后的证据。测试用例也表明了哪些需求是测试过的,哪些没有,避免了工作的随意性。
回复

使用道具 举报

  • TA的每日心情
    慵懒
    2019-8-15 07:37
  • 签到天数: 112 天

    连续签到: 1 天

    [LV.6]测试旅长

    发表于 2009-2-20 08:40:20 | 显示全部楼层
    关键并不是需不需要写用例
    而是明确自身的目的(你写用例的目的是什么?)
    如果真的是变动比较多 日程又比较紧的话
    可以列一个check list...
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-20 13:26:59 | 显示全部楼层
    需求决定功能

    功能取决于测试

    需求有变,功能跟着变,如何确定正确的变更? 唯有测试
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-20 13:32:34 | 显示全部楼层
    看各种情况,再决定咯
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-20 13:46:04 | 显示全部楼层
    原帖由 lanbiers 于 2009-2-20 13:26 发表
    需求决定功能

    功能取决于测试

    需求有变,功能跟着变,如何确定正确的变更? 唯有测试



    同意!!
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-20 16:30:54 | 显示全部楼层
    需要写,但是要看你怎么写,在什么阶段写

        首先按照传统的测试方法:
        项目研发周期为半年的小项目,大概需要5人以下小团队花至少一星期去编写测试用例(包括了解需求的时间),根据楼主的说明(经常会遇到需求三天一变,两天一变),估计用例刚刚写完,就发现需求完全变了,然后更新用例,至少又要花上两到三天时间(而且还没有算上BA/PM等都更新需求的时间),需求再变~~用例再更新~~~测试人员花费了大量的时间浪费在用例上,也可能是老牛耕地,耕了又耕,毫无进展。而且测试人员编写的用例的质量也会慢慢变低,根本起不到用例的原始作用,反而成为累赘。
       成本又多大,根本没办法估算,收益几乎为0.
       
        对于这种情况我认为有必要先解决项目的经常变更的问题。变更是无限的,项目周期是有限的,怎么样在有限时间内控制住无限的变更呢?这就必须将客户提前带入项目中,加强客户体验,加强和客户之间的交流。
        开发需要分成很多小组,每组负责一个子功能(具体分配可以根据实际情况)
        按自上往下的开发原则,首先将项目大体框架完成,再逐一实现里面的子功能。完成一个子功能,进行简单的测试保证功能可以正常运行试用后给客户试用,客户试用过程周期中可能会提出一些新的需求,负责该功能的开发小组进行修改,反复几个周期后,需求基本稳定,测试组再进行详细的测试,这时候就可以编写用例 …………很快第二个子功能就出来了,现在就需要一个简单的集成测试…………然后反反复复,一个完整的系统就出来了。
        说起来非常的简单,做的时候必须要加强于客户之间沟通,完完全全的了解客户到底要做成什么样的,再进行严格的需求分析。所以了解需求和需求分析是重中之重。
        还有个隐患就是现状,测试人员明显比开发少,可能一个测试需要负责一个开发组,甚至一个人需要负责两个以上小组,这什么就可以有充足的理由招人了~~呵呵


    我体验过一个项目的都进行随机测试,没有任何用例,简单模块完全可以应付的过来,复杂的模块根本达不到100%覆盖,而且很累人,最后还是顶着需求变更的风险,加班完成了用例的编写。

    事实告诉我们用例不能少。


    有空给我投点票~~~~HOHO

    [ 本帖最后由 birdcc 于 2009-2-20 16:33 编辑 ]
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-22 22:27:57 | 显示全部楼层

    应该写级别为高的用例

    对于需求不断变化的项目,只要大体写出级别为高的用例(项目或产品目标不会变化太大),其他用例根据需求微妙的变化简单记录就可。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 00:32:46 | 显示全部楼层
    反方支持一下.
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 00:33:34 | 显示全部楼层
    我也觉得没必要写,楼上有些说的不错.
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 00:38:48 | 显示全部楼层
     测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
      测试用例(TESt Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
      测试用例(TESt Case)是将软件测试的行为活动做一个科学化的组织归纳.目的是能够将软件测试的行为转化成可管理的模式;同时测试用例也是将测试具体量化的方法之一.
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 00:39:39 | 显示全部楼层
    要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。
      既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
    回复

    使用道具 举报

    该用户从未签到

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

    应该写,但形式可以多样

    我认为不管周期多长的项目写测试用例都是必要的,只是形式上可以多样:如果没有硬性要求,可以写得比较简洁,这样既能保证测试的覆盖率(特别是回归测试的时候容易漏测),如果需求变更修改起来也会比较省力。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 11:13:41 | 显示全部楼层
    用例是必要的
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-23 18:04:03 | 显示全部楼层
    首先,我们必需要清楚,我们为什么要写测试用例,现在项目出现变更,不写测试用例会出现什么问题,就是说,测试用例有什么用处,现在的实际情况,说明现在的测试流程可能出现的问题,或者说现在测试的流程已经不适合现在开发的过程,所以我们可以从过程改进的角度进行分析
    改进我们的过程,符合项目开发实际
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-25 11:34:30 | 显示全部楼层
    对于项目周期短,需求变更快的项目我想是否可以采用简化测试用例,标注测试关键点的方法来进行,只要测试团队同心协力富有责任心即可。不过在时间允许的情况下我觉得写用例是很重要的
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-25 16:13:47 | 显示全部楼层

    还是写用例的好,

    起码还是工作量呢,年底算奖金时可以加点分
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-25 17:11:16 | 显示全部楼层
    原帖由 搂搂兔 于 2009-2-25 16:13 发表
    起码还是工作量呢,年底算奖金时可以加点分

    我崩溃...
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-26 15:16:18 | 显示全部楼层
    原帖由 sweetxmy 于 2009-2-12 16:10 发表
    写需求(或测试用例)是为了更好的确认测试目标和提高团队工作能力


    1、很多开发团队认为写不断变化的需求(或测试用例)是浪费时间,何不用这个时间做开发和测试。
    但事实是,随着时间的推移,同时因为没有需求 ...


    这样一分析,自然写用例更有意义了!
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-2-26 15:26:31 | 显示全部楼层
    用例还是要写的!
    1.作为测试负责人.必须要把握好项目的进展程度,以便安排好测试工作.即使生命周期为半年,也要参照第一版的需求文档写出用例,这个用例可以不用细化到步骤级,但测试重点要明确.
    2.由于项目周期比较长,因此可以让测试人员有足够的时间去消化需求.即使大家担心需求变更,根据经验来说,做项目的时候需求不变才是不正常的.但每次变化只是局部变更,如果客户产生了大规模的变更,只能是pm要说明原因了(需求没有控制好).
    3.真正要开始项目的时候,此时再进行细化用例,对于测试人员来说应该是得心应手了,而且可以设计出效率较高的用例.因为我们有了之前的需求理解.
    4.用例是用来支撑测试的重要因素,没有用例的支撑,我们的测试只能是狗熊掰梆子了.的确,写用例的时间和精力都很多,但这也是为了更好的测试,为了项目的质量.作为测试人员,担当项目中把握质量最后一关的重要角色,所以一定要严格按照最基本的测试过程.
    5.另一方面,也是工作量核算的重要依据.同时也在提醒需求人员,一定要控制好需求,否则发生变更,将会带来一连串的工作量.
    6.开始可以安排较少的人员来参与用例的编写.还是那句话,用例还是要写的!
    回复

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2019-9-22 09:53 , Processed in 0.071795 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2019 Comsenz Inc.

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