1，软件开发方式不能再一味的用瀑布开发模式，应先开发出一个核心功能模块，后再继续扩展。即演化方法开发
2，真正的重视测试，不要再最后才拉进测试团队。应确保测试人员对于客户的需求以及改动及时掌握，并对与测试用例第一时间改动
3，自然对于测试的项目不能随改随测，即在一定较短的时间内出一版本
4，自然最后就是客户，PG，TESTER之箭及时沟通，以确保清晰表达及被准确的理解 呵呵，大家讨论很激烈啊
这种现象的确很常见，当然我们也存在，以下是我们目前的处理方法，
1、在设计测试用例时，增加冒烟测试用例。
2、版本提交后，先按冒烟测试用例进行冒烟测试，保证软件的基础功能及流程可实现后才按计划安排测试，否则返回给项目组修改，直至冒烟测试通过。
冒烟测试不通过时，直接导致测试计划延期，我们每次都向项目经理反馈，严重时直接向上级领导反馈，经过几次配合，开发人员也特别注意，在提交版本前自己也进行简单测试，确保冒烟测试通过。
经常还出现这样的情况：开发人员担心提交的版本不通过，在版本提交之前，私下找测试人员简单过一遍
关于版本控制和需求变更的几点想法
我相信每个公司都会涉及到这两个问题，不管是大的还是小的，如何减少版本过多造成测试效率低下至关重要，版本过多根本原因是需求的变更和项目缺少有效的管理。众所周知，需求变更在带来管理的难度的同时也创造了价值，需求变更的评审是必须的，项目经理在每次提交一个新的版本时，必须检查是不是最新，从而确保测试人员都能拿到最新的。 根本原因是管理不善。一般从以下几个方面着手改善，但不能杜绝1. 不能有效管理客户需求的变更请求，导致版本更迭过于频繁
这种情况应在项目经理层进行控制，可以采用延后集中处理的方式进行处理；在实在不能妥协的情况下，才采取立即变更处理——但一般情况下都可以通过沟通协调解决；
2. 不能有效使用Smoke Testing工作，导致提交版本错误迭出，继而进行补丁修正；
这种情况一般是由于工作流程不完善导致的。常见的场景是本地没问题，一旦更新提交了就出问题。PM可以借助Smoke Testing的方式规避掉这种由于配置管理无效导致的问题，同时应在项目管理制度上进行增强。确保具体的流程实施。
3. 更新配置管理计划失调
这种情况是缺乏预见和预防的表现，也是一种比较糟糕的情况。出现这种情况的罪魁祸首是项目组的经验（尤其是项目领导人）缺乏，不能预防可预见的风险而导致的。项目计划的后期出现这种情况的话则是由于处理失当导致的，如：项目计划的更新与配置管理计划不匹配，出现明显的偏离等。
4. 技能不足
这种情况最好解决。增强培训和相关技能即可。但是项目组不一定可以在短时间内达成目标，所以归根结底还是项目准备阶段的问题。 个人认为能够引起版本变更的因素很多，但比较普遍的是如下几点：
1.需求频繁变更。（个人认为软件的核心就是需求，软件是为了满足需求而生的，所以需求变更，往往会引起版本变更）
2.代码频繁变更。（可能是为了新功能，也可能是改缺陷，也可能是优化之类的）
3.版本控制没做好（找不到以前的版本了，或者找到了也不知道哪个是最新的，找还不如重新做一个快，结果版本越生越多，一片混乱）
针对以上，个人认为因从几方面控制：
a.在开发前期，要认清客户，定位好产品，要做好需求分析（尽可能地多挖掘，功夫做前头，要让需求有扩展性）
b.在确定需求过程中尽量让客户参与，能充分引导客户，并且消除和客户之间的误解，在充分沟通达成一致后要白纸黑字落实，并和客户约定好在一段时间里面不会做太多调整。（呵呵，当然这个需要客户支持，如果遇上强势客户，这步就比较麻烦了）
c.对需求进行评审把关（尽可能保证要实现的需求合理而且扩展性较好），对决定在某个版本中应满足的需求进行明确化并进行管理。
d.需求确定后，在进行设计的时候，应充分考虑扩展性，同时也对设计进行评审。做好版本规划。
e.对开发人员进行技能培训，在项目小组进行充分地沟通，消除误会。（尽量不要出现客户想要苹果，但是项目小组的人开发人员以为要的是梨，别的人员以为是香蕉的现象）
f.如果可以，支持测试先行，把缺陷尽可能地解决在前面。
g.看到前面有些帖子说，先开发核心系统，这个观点我支持，系统的耦合度应尽可能地低，尽可能地简单易拼装，争取能以不变应万变。
h.如果客户频繁变更需求，则应该对客户提出的需求变更进行评审，要考虑是不是和原来的有冲突，不要因为容易实现就满口应承，再容易实现也是要有成本的。即要作为引导方，正确引导客户能稳定需求。一方面如果确定合理的变更，应及时做好需求变更。要尽可能在全过程中保证需求和实现一致。因为需求是核心啊！
i.对于开发人员对测试的态度不端正的问题，建议增加绩效考核。当然最好是从思想上给予教育，加强培训。毕竟善良的人多。
j.还有有帖子说引入自动化工具提前进入测试，支持，不过这个只是争取让变更降低成本的一个措施，如果不从根本上去控制，再多的工具也可能忙不过来。
k.版本混乱，那就要做好配置管理了，就好像住家，总不能老住猪窝吧，该清理的要清理，该命名的就命名，合理的配置管理计划还是很重要的。干净整洁的环境能让人更健康，软件也一样。
总之，确实是个管理问题，而管理应该从一开始就开始控制，要让变更变成可控的，可追溯的。毕竟做什么事情都希望能够用最少的成本获取最大的效益，要争取“双赢”才是根本目的的。
以上纯属个人观点，可能有些理想化，仅供参考。
[ 本帖最后由 haohaoxuexi 于 2008-3-4 12:00 编辑 ] 提到版本问题必然会牵涉到配置管理
在国外，很多公司都是聘请一些很有经验的开发人员来做配置管理的事情
配置管理人员地位是相当高的
但是在国内，不少配置管理人员是因为开发做不下去，或者测试做的太差才会被指派去做配置管理
所以首要问题要加强配置管理意识：
1 不允许随意地提交版本
2 打tag
当然除了配置管理以外还有其他因素
比如流程管理的问题
但是规范配置管理是当务之急
改过了就提交一下的现象必须要杜绝
还有个问题。。。
我看到上面回帖的有不止一个人说的是需求变更。。。-_-
作为一个测试工作者居然那么不仔细。。。
回复 28# 的帖子
to Ls，人家的题目是如何应对频繁的版本变更，需求变更很容易引起频繁的版本变更，所以至少我认为上面的回帖有不止一个人说的是需求变更是没有问题的，偶实在不太赞成你说人家“作为一个测试工作者居然那么不仔细。。。”。。。。。。[ 本帖最后由 haohaoxuexi 于 2008-3-4 12:21 编辑 ] 本人意见是尽可能多的在原始版本上进行测试，除非是遇到block的BUG，才更换至新的的版本。 在新的版本中需要对修复后的bug进行详细的测试，包括与之有关联的相关模块。:)
最后，在说一句话，回归测试是一个很好解决版本经常更替的方法，至于作几轮，就要看各个资源配置情况和质量控制情况了！
谢谢！
[ 本帖最后由 lovemiya 于 2008-3-4 13:27 编辑 ]
测试版本由测试人员主导发布（基于测试团队与开发团队分离的情况下）
1、 测试从需求阶段开始介入。加入测试角色进行需求分析以及需求评审工作可以有效避免因为需求不清以及需求歧义导致的测试版本更新。2、 测试部分介入测试之前，开发团队需要提供一个可测试的基准版本。
3、 测试过程中的版本更新由测试人员主导发布。这也是个行之有效的方法。可以直接由测试人员发布也可是由测试人员监督发布。这样测试人员可以对本版本的情况了熟于心，这会节省不少回归测试的时间；
4、 这样最终版本经过测试人员测试得出，无疑增加了提交版本到客户的赢得好评的信心。
[ 本帖最后由 yayapang 于 2008-3-4 13:43 编辑 ]
测试过程中如何应对频繁的版本变更?
1、通过管理制度约束，要有明确的版本打回的考核制度，把版本打回次数与开发人员的考核指标挂钩，并有一定的惩罚措施，这样才能使开发提高提交版本的质量，从而使提交版本可测试。2、通过清晰，明确的流程保证，如提交测试的版本要有一定的测试准入条件，没有达到准入条件的一律打回处理，不能浪费更多的时间测试一个不可测试的版本。针对版本所规划的需求未实现这一问题，可以增加需求验证这一环节，这个环节的验证不会要求很细，但是可以规划的需求已全部实现，或实现的功能与需求规划是一致的，这样提交到测试环节的版本，我们就可以按计划开展比较详细的测试。
3、通过一些方法和策略保证。把测试分级，一个版本的提交，通过几个级别的测试，然后再确定是否全面投入测试，1级的可以定义为运行BVT或一些预测试，例如正确执行安装，运行等测试用例，这些是最基本的用例，通过后再运行2级用例，定义为一些基本功能和主要流程类的用例，运行通过后再按计划展开全面的测试，避免盲目的投入造成测试资源的浪费和做无用功。前2个级别的测试完全可以通过自动化来实现，这样的话可以夜间进行，既提升了效率，也不会对进度有太大影响。
总之，我认为制度，流程，方法结合，可以把风险和影响降到最低，但最终的根本还在于整个研发团队的质量意识和团队精神，这两方面都比较强的话，再加以健全的流程和制度，包括这个问题的许多问题都可以迎刃而解了。 还是那句老话：过程保证质量！
还是要做好 过程的啊！ 赶上大家讨论的末班车了
个人看法：
1.开发人员编码的规范和修改bug的质量；
2.build版本的质量
3.测试用例的覆盖度，测试人员严格执行情况
4.开发与测试之间的沟通
5.缺陷管理工具的跟踪
6.公司的管理体制 1测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现
在流程中作相应的规定出现上述问题可以申请停止测试，原因是交付的版本不能达到测试标准，这点很重要。会减少很多没有必要的重复测试工作.:victory:
2测试过程中发现自己所测试的版本频繁变更(很让人郁闷呀，刚测试过的还得要测试一遍，哈哈)，这在软件公司是很普遍的现象。
说实话频繁的变更版本对测试人员和研发人员都不是好事，实际操作时经常会出现这个人的代码没有打进去或是那个人的代码刚改完
从新打包的情况。一般还是要按照周期来做比较保险。新版本交付测试一个周期完成后再打包。当然这其中可能碰到一下阻碍测试
继续进行的问题可以适当处理，但是这个比例是要控制的。一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的
我们还是应该坚决拒绝测试的。前提是你公司和你的领导真的很重视测试。否则一切都是扯淡
针对上面的问题还有一个相对比较好的解决办法,在进行单元测试时又测试人员进行协助测试,这过程中不紧紧是简单的功能测试还有性能测试.在单元测试时严格把关,把一些简单的BUG(界面上的)尽量大的在单元测试中结束,这样即减少了后期系统测试时的很多无谓的重复劳动也把很多严重的性能问题在最早期发现并解决.但是需要研发人员的配合.:victory: 测试过程如果只是测试执行过程，如果能够预见面对版本的频繁变更，测试执行策略应该做出弹性规划，或者跟更多的采用探索式的session based的测试。
事后分析原因，看看问题是出在配置管理还是代码质量上
第一个问题说明要有一个好的构建发布的配置管理流程
如果是第二个问题，原因可能不同，首先可以尝试加强unit test, integration test以及requirement review, design review, code review等quality control的方法 “边测边改”不能算是一个很糟糕的现象。
我现在所在的公司多数项目就处于这种状态。我之所以说“边测边改”不是一个糟糕的现象是由于，项目组对于版本的划分不是非常明确，从而导致有很多版本的出现，但是这种多版本并不能算是真正意义上的“版本”，可以算做是开发阶段或者说集成阶段的“开发版本”或“小版本”。
在这种版本提交到测试的时候，如果发现影响测试进行的缺陷，这种版本立即退回并停止测试，这个时候开发人员有事情去处理，测试人员依然有事情需要去做，测试人员需要做的可以是继续完善系统测试用例等等。
“边测边改”的情况是测试部来划定软件版本的一个方法，例如收到项目组的一个测试版本的时候，测试组可以对此版本定义测试版本，测试提交缺陷，同时开发人员在缺陷管理器上查看缺陷，修复并继续开发。
一轮测试结束（覆盖所有的业务功能点）后，分析缺陷管理器，之后，项目组可以修复提交的缺陷，并重新发布新的版本供测试部进行回归测试
这个过程是一个迭代的过程，因此“边测边改”并不能算是一个很糟糕的现象。
:)
个人见解
首先，我认为对处理版本的变更是一个重要的环节。由于需求的不同及增多，会产生很多不同的版本，所以在测试的时候会带来很多不必要的麻烦。因此，我建议将测试版本化。将测试需求、计划、执行的测试用例等分成不同的版本。并且要了解各个版本之间的区别，这样可以重点的测试这些环节。为了醒目还可以采用不同的颜色加以标识。还有一种可行办法就是可以做一个通用版本的测试需求、计划、执行的测试用例，然后对不同的版本对应不同的功能再附加其相应信息。
测试过程中如何应对频繁的版本变更?
现在让我们来假定频繁的版本变更已成事实。:)既然现在的情况是这样，肯定能找出造成这种现象的原因。
1.需求不断变换: 当碰到客户有新的需求或需求有改动的时候，开发和测试人员应该要协调好，正确的学习新的需求和变动的需求。这样开发和测试人员才能统一对需求的理解。要是对需求的理解不一致，在整个开发和测试过程中就会出现很多不必要的麻烦。例如：开发人员对需求理解有误，写出来的功能点程序必然不符合客户的需求，这样在测试人员那里通不过，就得返工；测试人员对需求的理解有误，在测试的过程中，将正确的功能点报告成bug，反馈到开发人员那里，这样就浪费了开发和测试的时间。当版本频繁变更，作为测试人员一定要紧跟需求变更，抓住一个软件的质量的根源，及时更形测试用例。
2.系统的开发管理： 一个软件的开发的好坏很大程度上取决于整个软件开发的项目管理上。当各个团队之间的实力都相差无几的情况下，项目管理越完善，开放一个软件的成本就越低，质量就越好。因此，面对版本频繁变更的情况，及时调整项目管理的方法，亡羊补牢。
3.开放人员的程序能力存在问题： 这是在软件开发环节中致命的弱点。当碰到这种情况，也只能耐着性子，慢慢来了。^_^
4.工作态度存在问题： 有些人会认为，版本更新的越快软件就更新的快，整个开发的过程质量就越高。这种想法是错误的。一个版本的更新到下一个版本的更新时间间隔必须要达到一定的时间度，也就是说，要让测试人员有足够的时间测试一个新的版本。在这种情况下，测试人员能做的有两个方面。一方面是，主动和开发人员协商，调整版本更新的时间；另一方面是，清楚的知道开放人员改动的地方是哪些，对改动的地方，以及与其相关的地方进行重点测试，同时，对于每一个新版本，一定要把每一个功能点都测试到，不能遗漏。
5.版本更新过于草率： 有的开发人员，在改过一次代码后，不经过检查，就迫不及待的将代码提交了上去，更新版本。这样，在这个新的版本中就可能会出项很多很简单很不应该有的简单错误。这样就增加了版本更换的频率。作为测试人员应当跟开发人协调，让一个新的版本在进行完整的测试之前，进行预测试，测试各个主要的功能是正确。通过了之后，再进行全面的测试。
以上仅仅是个人意见，各位高手多多指教！
回复 1# 的帖子
当前问题：测试过程中如何应对频繁的版本变更？（08-02-29）不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继续测试失去意义等等，不得不频繁打回版本、修复缺陷后重新开始测试，使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，还影响对测试对象质量的完整评估。这种情况是否有好的办法加以规范呢？欢迎大家各抒己见！
==========================================================
这应该是一个公司的测试从混乱走向规范，必然经历的一个过程。
这个现象我觉得需要分两种情况来说：
1.需求随着市场等各方面因素不断变化的情况：这种情况下，无论计划做得再好，计划跟不上变化，必须不定期的变更需求，生成版本，不断测试。这是一个频繁迭代的过程，就需要边测边改。
2.需求相对比较稳定的情况：这种情况下，如果发生了上述问题，我觉得那就是研发、配置管理、测试三方面的责任了。1）研发的责任在于，没有将单元、集成测试做好，没有经过基本的自测试，可能是开发完，最基本的验证都没做就提交了代码；
2）配置管理的责任在于，没有对提交给测试的版本进行冒烟测试（或由其他人以及自动化完成），没有把好版本控制关。对于基本的冒烟测试都无法通过的版本（除非特殊情况、特殊放行），是不能提交给测试的；
3）测试方面的责任在于，不能一味的追求在最新版本上测试，应该按照测试计划，有目的、有步骤，系统的进行全面的测试。切忌无目的、盲目的测试。
因此，如果不是需求变更导致的频繁生成版本，我觉得重点应该在研发及配置管理这两块把好关。否则，只能适应这种快速迭代的开发过程，对于这种情况，测试计划就不能定的太长，总体测试计划可以比较粗，把测试的原则、目标、总体规划定义清楚即可。随着项目的推进，小节点的测试计划必须跟研发计划同步，随时更新。另外，对于基本的功能、性能测试点，可以自动化的尽量自动化，重复的劳动能省就省。
以上是个人的一些观点，欢迎指教。
