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

兆隆8032

没有测试用例，在一些偶然出现缺陷即不可重现的缺陷，是很难被记录下来的。
在向开发人员说明曾出现这个错误的时候，没有证据，没有证据谁相信啊！自己做了事情反而没有得到效果，这样干工作太笨了。

wxm2004734

唉，写简单一点。没有规矩，不成方圆。要是你能控制过来，你NX

beryl_lin

测试的目的就是尽可能的减少系统的bug，确保软件的质量，好的测试用例是保证测试质量的前提。
如果没有测试用例，对于相对比较复杂的功能，尤其是多人同时参与测试的情况下，很可能忽略某些很重要的细节，从而放过了很多bug。严格的讲，不仅需要测试用例，而且测试用例必须经过多人评审，确保其质量才行。需求变动，测试人员拿不到最新的需求，但这不是不写测试用例的借口，相反，应该尽可能的督促相关人员以拿到最新的需求，根据变动及时更新测试用例。

CHOUYUNHAT

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

lanbiers

需求决定功能

功能取决于测试

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

birdcc

需要写，但是要看你怎么写，在什么阶段写

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


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

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


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

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

qinkun26911615

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

kukumaru

　测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
　　测试用例（TESt Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　测试用例（TESt Case）是将软件测试的行为活动做一个科学化的组织归纳．目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一．

kukumaru

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

calliopsis

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

liyayaliutao

用例是必要的

佐伊

原帖由 搂搂兔 于 2009-2-25 16:13 发表
起码还是工作量呢，年底算奖金时可以加点分

我崩溃．．．

雅丹咔咔

原帖由 sweetxmy 于 2009-2-12 16:10 发表
写需求（或测试用例）是为了更好的确认测试目标和提高团队工作能力


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

这样一分析，自然写用例更有意义了！

yanjie_4

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

atomtiger

起码可以简单写写吧。。。。。列个提纲总是好的。。。

jessies

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

对于ahu201的回答，我有一个疑问，变更后的需求，快速定位了之后，你怎么保证在多个测试人员的团队内，每一个人对这个变更之后的需求都是理解一致的？
或者提一个场景来说，如果用户提出了一个新的需求，项目组做了变更，也修改了功能列表，那么真正执行这部分功能的测试人员是否知道这个变更呢？或者说，他是否已经领会了这个变更的真正意思？他的测试是否真的遵循了变更后的列表？测试负责人要如何衡量如何保证？
测试人员的测试执行是否正确，这个又如何保证？也许他执行的过程和实际需求有出入呢？你又如何去把握？
其实我觉得这个辩题可能没有完全的描述好真正的场景，在软件测试过程中，个人认为，如果测试组是一个小团队的话，那么就需要描述清楚完整的用例场景，但是如何测试人员是熟练的或者说，测试人员就一个或者两个，那么沟通不成问题的情况，可以写比较简单的用例。
但是用例是必要的，简单的功能列表我觉得也是用例的一种，用例不一定非要标准到步骤输入输出，特殊情况下，用例可以简化，当然这个视项目组成员的能力以及项目规模和时间来决定。
对于较复杂的项目，我支持写用例，维护的成本可能比较高。但是如果项目到最后发现最后测试的功能其实是和需求有偏差的，那么这种修改带来的代价可能更加大。

jessies

原帖由 pupu840323 于 2009-2-10 15:17 发表
开门见山的说，我认为不需要写测试用例，但我们需要简化版的功能覆盖点。

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

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

支付你的解决办法，但是在我们这里，我们可能会使用简化版的测试用例来代替，同你提出的功能覆盖点。

ghf.m

个人觉得主要功能还是需要用例的...并且和原需求一起存档，如果客户改来改去还是觉得原来的功能好的话，也不至于又要卷土重来..

drwei123

需求经常变,那程序的设计呢??CODE呢??
如果都变了,不更新 TC ,那测试标准有 反方 怎么来定义呢??
TC 也是一个熟悉需求的过程,只有更新它,很多的细节上的问题都会出现,那样能更好了解需求,了解客户到底是要什么样的一个东西.....
那样才能对开发人员做出来的东西进行一个很好,很全面的 TEST

七明芝

还是要写的吧，否则如何向老板证明你做了多少事情。只是可以简略些