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

默默巫

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

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

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

ahu201

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

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

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

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

pupu840323

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

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

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

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

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

candy_83

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

namisang

没有必要写
费神浪费时间．

光明

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

tinayuan1981

当然要写，测试用例是写给自己看的，不写自己不就乱了？

月野幻儿

没有必要写，耗力．
需求三天两头变，自己随机应变．

namisang

原帖由 wuyu702 于 2009-2-18 13:57 发表
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...

不错不错．

namisang

原帖由 wuyu702 于 2009-2-18 13:57 发表
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...

不错不错

Jackc

1、LZ的题目中缺少两个关键属性：项目的规模（包括需求变更规模）和测试资源

2、浅析项目规模和测试资源的影响
    其实LZ这个题目最大的争议点就是在这里，如果这两个属性可以确定，相信大家的思路会清晰很多。下面偶只分两类进行简单的分析：
    A、项目规模大（需求变更规模大），测试资源少：按照CMMI 5中测试用例的编写标准来说，限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...
      显而易见，剩余还有多少时间完成测试执行的跟踪和改进？即使前期能勉强跟进，偶相信在后期也只能疲于奔命，敷衍了事，什么“测试驱动开发”也只是梦中花而已。
       国内很多企业都是这样的情况，相信N多测试同仁对此是深有体会。
    B、项目规模小（需求变更规模小），测试资源多：人多好办事，只要Test Manger不是个草包，将测试工作进行有条理的细分，责任到人，在测试准备阶段选择有利于修改的测试流程（包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等），在测试执行阶段，注意需求收集已经各部门以及客户之间的信息交流，还是很容易搞定的。

3、浅析正方观点的风险：
    A、如正方wuyu702 所说：“先会把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。”。
       什么叫大概的用例?
      用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例，当你临时有其他更重要的任务，然后把这块测试工作交付给其他人来做，能够保证别人肯定能看明白？
    B、又如正方Okayde、wuyu702、jessies、兆隆8032等提出的：用例是用来保障测试的质量，以及对测试执行的指引。
       测试用例是唯一的保障产品/测试质量的手段？没有测试用例就无法指导和跟踪测试执行了？
       当然不是，这里偶引用一个只有部分公司在用的一个概念“测试规程（test procedure）”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容，以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
       测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
       楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程，然后以测试规程来指导测试执行，提供测试质量（比如测试覆盖率）的评估。但是楼上的同仁没有对简化测试用例提出标准？如果一个测试团队里有3、4个简化标准，大家的测试用例简化的“度”都不一致，岂不乱套？
    C、2A中描述的项目情况，仍采用设计常规的测试用例的方法，那么只能有两种结果：a、披着“测试用例”的外套，却是到处缺胳膊少腿，敷衍了事，难以达到测试用例的覆盖标准；b、忙于测试用例的编写，无法在测试执行中完成测试的跟踪与改进，每天都疲于奔命，最终完成N个项目后，测试团队的水平仍然停滞不前，经常受到项目组的“鄙视”。

4、偶的观点：敏捷性测试团队才是王道，项目不同测试流程不同。针对LZ的项目，选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。
    A、前提：测试团队组成基本由熟练测试人员组成（就软件黑盒测试来说，加入团队半年以上的就可以叫做熟练了）。统一规范的测试流程（相信这个只要是稍微正规点的公司都有）PS：此流程只适用于2B的情况，并且可以进行裁减。有些公司是将标准流程做成checklist形式，方便项目组选择。
    B、策划：测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程，并进行评审。其中有两点必须说明：测试执行依据采用测试用例还是测试规程或者两者皆用；测试用例（测试规程）设计的标准。
    C、变更：满足以上两个条件，如若遇到实际需求被迫变更，则修改相应测试规程，并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别，偶举一个例子：
       为了简单，用例和规程的格式就忽略了，只写具体输入步骤一部分，书写格式也比较随意。
       原需求：编辑框A中允许输入最多20个中文
       规程的输入步骤：
       只输入0~20个中文,点击确定，检查结果。备注：其中0、20必须测试
       输入21个中文，检查结果
       输入非中文字符，检查结果。备注：包括英文/特殊符号...
      混合输入中文与非中文字符，检查结果。备注：中文字符在第一位的情况必须测试
       ...
      测试用例的输入步骤：
       不输入任何字符，点击确定，检查结果
       输入10个中文字符，点击确定，检查结果
       输入20个中文字符 ，点击确定，检查结果
       输入21个中文字符，点击确定，检查结果。
       ....（不写了，N多）
       假如修改需求：编辑框A中允许输入最多20个中文或数字
       规程的输入步骤：
       输入0~21个中文或数字，点击确定，检查结果。备注：数字/中文混合输入、0/20/21位字符输入必须测试。
       ....
      假如换成测试用例，那就只有....慢慢写了~
   D、跟踪/评估：其实从4C中的例子可以看出，测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法，比如缺陷分析技术，详细信息请看http://bbs.51testing.com/thread-117496-1-2.html

小结：综上，LZ所说的问题可以使用测试规程代替测试用例来解决。
建立敏捷性测试团队，不“墨守成规”的进行测试活动，才是测试的王道

[ 本帖最后由 Jackc 于 2009-2-19 14:02 编辑 ]

Jackc

以上是偶以前工作的一些体会，有些怨气在里面（看来还没有磨练到“心平如水”的境界），大家见谅~

xiaodada

反方支持一下．

xiaodada

我也觉得没必要写，楼上有些说的不错．

chengxq

首先，我们必需要清楚，我们为什么要写测试用例，现在项目出现变更，不写测试用例会出现什么问题，就是说，测试用例有什么用处，现在的实际情况，说明现在的测试流程可能出现的问题，或者说现在测试的流程已经不适合现在开发的过程，所以我们可以从过程改进的角度进行分析
改进我们的过程，符合项目开发实际

试验

测试一下！

linda22

谁也没有质疑测试用例的有效性，可是对于一个有经验的测试人员来说，那么短的时间，可能与项目经理、程序员沟通，测试的时间都不是很充足，花大力气写完了测试用例，可能还没写完，就有需求变动了，而且这变动还是自己不知情的，再改测试用例还是用不适用的测试用例去执行呢？还不如按自己的经验来进行测试，虽然可能会有疏漏，总比来不及执行测试这最后，并且最终要的一步来的好吧。