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

默默巫

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

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

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

aloan

http   t点cn/Efk3pEv   线上网址马上观看

femir

重要功能用例是必须要写的，每次需求变动之后对变化的需求写少部分用例就可以了

高次有

程经理：18850468120 QQ:2310682411 个人无抵押无担保信用贷款，有工作有信用即可申请，额度1-50万，最快2天放款，老师、医生、公 务 员、律师及国家事业单位的工 作 人 员，利息低，无手续费，福州五区八县 宁德 莆田 泉州可办理。网址，www.CreditEase.cn详询
2 银行信用贷款，主要针对老师、医生、公务员、律师及国家事业单位上班的工作人员，手续简便，利息5厘到8.3厘。
3 房贷信用贷款，只要你有房子，曾经或现在有房贷，便可申请，额度可做到每月月供的20-28倍不等，4-7天便可下款，利息7厘
4 车贷，若你在福州有房子，信用没有太大问题，可贷20-30万，5-7天可下款。
5 低点**，保证能报销。

资金渠道多样，不论大额还是小额，都可与本人联系

yxx8012

一个月,半个月的项目用例也是有必要的.这是个测试设计(测试用例\测试方案等)的过程是必须的.就像开发的代码一样.是你的产出.而且用例必须经过一系列的评审.前期必须输出AT用例.后期完成ST,SDV.项目周期短可以省略SIT,但是如果是半年的项目有充分的时间完成上面一系列的质量动作.

切记,不是为了写用例而用例.而是这是质量保证的必要手段.是检查软件能否正常工作的动作.不然裸奔．这样的项目最后将是一塌糊涂．

songjunster

生命周期只有半年就不该开发！

你说的应该是研发周期半年吧？很长了啊，俺们这边一般一个项目研发周期也就3个月。

春天梅花

Michael0112

非常有必要做  design test cases。

yuefang3344

恩恩....






我的MSN jk@tiwens.com

maxhoo8003

1、没测试用例怎么通过用户单位或者监理单位的验收过程？
2、测试用例起码要准备两份：一份是自己写的详细的针对系统每个功能点的详细用例 一份是简单命了的通过性测试用例给用户和监理验收使用的

himily

支持写写提纲，写写思路，也就是业界说的测试规程。我在设计一些取值比较易变的测试用例时，就是采用这种方法，把我的测试思路记录下来，写一个大概的提纲，因为是自己测所以只要自己能够看懂就可以了，对于经常做需求变更的项目可以具具体情况而采用这种方案

Eric2515

必须写测试用列,而且要进行需求跟踪...对于人力成本的提高可以找客户收手要钱.控制好客户的需求是解决这个问题的根本..是需求分析人员本身存在调研不足还是客户本身善变..对于不同的情况有不同的解决方法。
客户需求频繁变更,但是软件本身有很多需求是不会变的,测试LEADER可以优先考虑把计划定在这些范围内;比如软件的性能,环境等.

fengbo

我觉得这个问题必须得认真对待。测试用例作为可衡量的软件测试过程与测试效果和与之相对应的测试工作进展是重要的一个评估手段。测试用例的设计能力直接体现着公司的测试技术力量，所以因为项目周期短，项目变更频繁而对测试用例的设计不加重视。
     一个软件项目变更在频繁，也会有其基本的项目架构和主线，而如何对其软件项目主线和架构进行有效的测试用例编写，从而形成测试用例复用以降低软件项目功能的增对测试用例编写的成本。
     但现在测试用例复用技术好像许多许多的公司都不重视，我当年就研究的这项技术，但我还是被公司守旧势力给扼杀了。

nqk

原帖由 birdcc 于 2009-2-20 16:30 发表
需要写，但是要看你怎么写，在什么阶段写

    首先按照传统的测试方法：
    项目研发周期为半年的小项目，大概需要5人以下小团队花至少一星期去编写测试用例（包括了解需求的时间），根据楼主的说明（经常会遇到 ...

同意！

圣西罗

个人认为还是有必要写的，但是没有必要全部按部就班的去写，那样对测试人员的心里也是一种疲劳战术，首先可以明确测试重点，根据测试点的要求，找出重点，严格按照测试用例的标准详细写清测试步骤，其他的可以根据实际情况适当安排，根据测试点的需要，最后可以看出测试用例的覆盖程度，而且可以保证项目常用模块的完全覆盖。

七明芝

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

drwei123

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

tiannianyong

我觉得测试计划和方案是一定要写的。方案里面写明重点测试内容，以及各主要功能点测试用的方法。
如果多人测试：最好要写测试用例。
如果一个人或者两个人，按照测试方案来直接执行测试就可以了。
目前我是这样来做的，感觉还行。
请指正。。

ghf.m

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

jessies

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

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

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

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

jessies

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

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