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

lqc5211314 · 发表于 2009-2-26 15:47:04

根据项目的规模，如果项目规模较大的话，测试用例是必须的，但如果时间较短，测试准备时间和，测试时间可能会有冲突，所以大多这类项目均执行冒烟测试。
我们公司的项目大多都只有一个月甚至更短，测试时间本身就只有2-3天时间，需求时常变动，有些在出厂前都没有明确定义，最主要的是人力不够，如果书写测试用例将造成测试周期加长，造成项目无法正常出厂，项目延期可是很不好的事哦

默默巫 · 发表于 2009-2-26 17:15:42

都讨论起来哦！

atomtiger · 发表于 2009-2-26 20:44:48

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

试验 · 发表于 2009-2-27 09:29:55

测试一下！

linda22 · 发表于 2009-2-27 11:37:30

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

jessies · 发表于 2009-2-27 12:26:49

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

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

jessies · 发表于 2009-2-27 12:30:08

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

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

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

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

ghf.m · 发表于 2009-2-27 12:31:08

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

tiannianyong · 发表于 2009-2-27 13:37:21

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

drwei123 · 发表于 2009-2-27 13:38:11

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

七明芝 · 发表于 2009-2-27 15:10:55

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

圣西罗 · 发表于 2009-2-27 18:01:38

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

nqk · 发表于 2009-3-1 22:01:18

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

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

同意！

fengbo · 发表于 2009-3-2 14:09:51

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

Eric2515 · 发表于 2009-3-2 15:03:45

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