51Testing软件测试论坛

标题: 需求天天变，怎么测试呢？ [打印本页]

作者: fengjinge 时间: 2010-4-24 11:28
标题: 需求天天变，怎么测试呢？
领导说开始测试了，可是很多block错误，需求在天天改，请教大家，这种情况，该怎么办呢？

测试的人不知道软件要满足什么需求，怎么能测试出来bug呢？bug没有定义的基准了。

请大家指点迷津吧。

作者: fengjinge 时间: 2010-4-24 12:04
可能我说的还不够清楚。目前是开发时间很紧张，只有我一个人隶属于开发组在测试，基本上是一边改需求一边在测试，软件过程并没有比较规范的需求、开发、测试阶段。这种情况算是敏捷开发？这种状况，规范流程下的各种东西，不太适用了。
不知道大家有没这种经验，请大家提些建议吧。

[ 本帖最后由 fengjinge 于 2010-4-24 12:35 编辑 ]

作者: joancarl 时间: 2010-4-24 15:41
就围绕需求进行测试啊！
看需求的实现情况即可

作者: pal_zll 时间: 2010-4-28 11:07
需求不明朗并且在不停的变，是因为大家都没有明确的能够知道怎么做才是正确的，就需要紧跟需求，把变化的每一点都记录下来，问清楚为什么变，想想这种变化是否可行，还有没有更好的方案；把不清晰的需求划出来，考虑怎么做会比较好。对需求的考虑保持走在开发之前，测试驱动开发。这就是我做敏捷开发模式的测试的感觉。但是这么做要比做一些大的项目，按双V或者瀑布模型的开发的那些要累很多。时刻保持着头脑的清醒，呵呵

作者: fengjinge 时间: 2010-5-4 14:54
标题: 回复 4# 的帖子
感谢大家的热心回复，现在的项目开发，基本就是组长和开发一起开会讨论需求，不关测试啥事…………看来我应该主动要求参与需求

作者: chop123 时间: 2010-5-14 19:15
唉，还是需要大环境来支撑。需求变更都不通知测试，那还测什么需求。

作者: msnshow 时间: 2010-5-14 19:28
看上去你们公司的问题，不是你一个测试人员能掌控的

作者: msnshow 时间: 2010-5-14 19:29
做为测试人员，你让你的领导知道面临的问题就差不多

作者: honey520 时间: 2010-5-20 15:51
多和开发人员或项目经理交流、沟通，发现改动或变化比较大的和项目经理确认一下需求

作者: 水中的鱼 时间: 2010-5-26 14:59
估计这项目都难以完成。
我是这么做的。
要求给出软件概要设计说明书SRS
对SRS进行评审
将不明确的地方先解决
PM给出项目的总进度
在开始开发的时候，不接受变更，开发告一段落后，留出了设计变更处理的时间
一切按照项目计划时间进行。
当然这需要PM 开发，测试的协同工作，以及领导层给予的资源上的支持

作者: 水中的鱼 时间: 2010-5-26 15:11
如果大家对每一次的需求变更持更加谨慎的态度，遵循一定的流程，就会很大的提高项目的进度和质量了。否则很容易变成虎头蛇尾，到临近发布，新BUG还很多，无法控制的地步。

作者: cdxfujian 时间: 2010-5-28 13:09
个人觉得楼主现在的问题相信是每个测试人员都在面临的一个问题，楼主所处的项目应该是属于敏捷开发，测试是驱动开发的，简单点就是要拥抱变化！一般这种项目BUILD出现的频率很高，而每个BUILD的形成也一般都是需求的变更到稳定的阶段。对于需求的不断变更，如果你的项目需求是有客户参与的，我想测试人员的介入是很有必要的！第二点就是所谓的BUG的问题，这个阶段的BUG可以分成两种：1 增强性enhancement bug，这个需要测试对这个领域有比较多的了解，因为这种BUG一般最后会成为需求！2 就是真正的BUG，这就是来源于相对稳定的需求！所谓稳定的需求，我认为如果你真正的了解这个项目应该知道哪些需求的变更是相对稳定的了，也就是说客户的需要。不过话说回来，敏捷开发一般周期为一个月，每周几乎会有BUILD出来，所以这个不需要太多的顾虑，还有一点很重要的就是要时刻保持着和开发的沟通！当然不是让你去问开发这个是否是个BUG了！以上是个人了解，如果你找到更好的答案请和我update下。

作者: xavier_007 时间: 2010-6-2 17:57
呵呵，这个怎能算是敏捷开发呢？
例如于测试里面的h模型
tdd更要对需求和设计文档明确
的确不是lz一个人的问题，是整个管理的问题。
建议lz不要把问题扣的太细，把握功能，经常3方交流是必要的
找正确的人说正确的事

作者: yetties2005 时间: 2010-6-17 16:02
很多需求变更都不会走什么正规的流程的，这点公司很重要，质量控制部门很重要，如果要只靠测试来把关的话是很难

作者: 咚咚宝031102 时间: 2010-6-17 17:09
这个现象很正常相信你会习惯的

作者: asai-oyh 时间: 2010-6-30 15:01
我们这里情况雷同啦，需求随时都有变，更何况我们这里连需求文档都没有，只有业务流程图和界面图。。哈哈，也正处理紧急赶工阶段

我们是这样做的，事先制定好一定周期（一般是一周）工作量，安排开发（开发内容可以是变更的需求或者计划的缘由需求，工作分配主要根据任务的优先紧急程度来定），在开发完成后，马上安排进行测试（开发组会提交测试组一份测试需求）。在提交测试期间，就不对测试需求做任何变更。起码得保证在执行测试时，测试需求不能变。当然，这么做得同时，很重要的一点，就是要做好版本管理啦。如果你们项目是十分十分紧急，可以再把周期缩短一些，只要能及时开发人员能及时完成。。哈哈哈

作者: james.zhong 时间: 2010-7-13 11:30
以不变应万变

作者: chengning 时间: 2010-7-13 11:49
和你一样悲惨的命运啊

作者: Coolwind9 时间: 2010-10-29 13:49
我也遇到过这种问题的啊... 是挺烦的

作者: 愚人 时间: 2010-10-30 16:41
这个跟你领导探讨一下比较好……

作者: JD_TS_2010 时间: 2010-10-30 22:56

作者: 测试新新手 时间: 2010-11-1 14:32
该怎么测还怎么测...
测试也是人...不是神...

作者: msnshow 时间: 2010-11-12 00:10
天天变化的是不同的功能部分吧，不可能一个功能天天变

作者: testerwu 时间: 2010-11-17 14:36
我觉得和领导探讨是有必要，可能是测试做的工作还不够引起公司领导的重视，觉得开发或销售部门更重要，他们的工作有成效，而测试就不同，项目下来以后测试的时间会因为需求的变化一少再少。

作者: testerwu 时间: 2010-11-17 14:37
所以必须提高测试工作本身的质量，引起公司的重视。主动参与需求评审等等，你不是一个人在奋斗！

作者: moonjew 时间: 2010-11-18 15:22
自打敏捷一出生就被很多人误解。很多公司高呼：啊！救世主，我们公司就需要敏捷。

作者: melodys 时间: 2010-11-18 22:28
我也碰到过开发和测试的沟通不算很良好的情况，但是需求天天变到时没碰到过，汗。。。
我们公司没有质量保证部门，所以这一块会比较难掌控
看出来了，需求评审测试参与很重要，但是在这方面可能都会薄弱点，作为小测试，我们也不能强出头啊。唉。。。

作者: 老学生 时间: 2011-1-26 10:34
楼上有说的：“以不变应万变”，那么我们怎么做到“应万变”?
* 我想，我们首先应该明确一点。这种项目工期紧，需求不明确（客户都不是太明白他要什么）的情况是普遍现象。我们作为测试人员无力改变这个事实，其实任何人都不能改变。为什么这么说呢，因为客户给钱让你给他开发软件，那么不仅仅是软件本事，同时也包括怎么做这一部分。在不断的变更中为用户找到一种最合理的应用方法。
* 面对这样的事实，我们就应该紧跟一次次的需求变更，进行测试。每次的测试重点除了需求本事，还有就是需求的追踪。也就是把所有需求都穿线，一个需求变了，我们可以立刻检索出该需求相关的所有需求、用例、现有bug情况、对应的程序单元等。
* 对需求追踪进行汇总，定期报告给用户知晓。从而提高用户对我们工作量的认识。

好了，总结出来“应万变”的方法《进行需求追踪》

作者: yangfengwait 时间: 2011-1-30 15:16
需求天天变的项目,不待也吧,跟这样的PM,也不会有什么出息,对自己将来的发展也不会有多大好处

作者: 碧水小龙 时间: 2011-2-9 10:14
一样的问题！！！是不好处理啊！有时候感觉测试的压力很大。

作者: echo5410 时间: 2011-2-9 15:58
最重要的还是及时沟通

作者: maojuan110 时间: 2011-2-21 22:51
学习！

作者: 楠族开心果 时间: 2011-2-24 17:44
我们也是这样，只能跟着他们慢慢改了

作者: shqn 时间: 2011-2-28 23:24
其实只要明确一点就可以了，就是原始需求的确定。后面的测试也要围绕这个需求来进行了。若是中途改需求的，很简单，就当它是新需求，在项目过程中讨论下，是否要改，若是改的话就以新的Story提出，交给开发。测试再根据Story明确测试方案，这样对于测试来说。可以省很多吃亏不讨好的事。

作者: kadw85 时间: 2011-3-14 10:57
看来不只是我们公司出现这种问题，给上面提也没有什么用，

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)