1、软件开发的需求分析阶段：开发人员获得并生成客户的需求说明书后，需要认真核对需求说明书是否完整和准确。这样可以确保开发人员开发的软件模型和客户需求不至于差得太远，也就是版主所说的频繁变更问题。
2、软件开发的代码生成阶段：开发人员在开发过程中应一个完成模块后尽早测试，保证该模块的正确性；并由单元测试-集成测试-系统测试依次完成。这时软件测试人员和开发人员的合作是很紧密的。
3、软件开发的质量保证阶段：软件第一版完成后，如果出现bug或者客户有新的要求等等，需要重新对相应模块进行修正，并进行回归测试。
偶的观点大概是这样的。
突然想起微软和Google的软件开发流程。一个是生成了一个软件版本后，通过投入给客户使用得到一系列的bug反馈，从而在第一个软件版本的基础上形成第二版、第三版……；而Google则是开发出一个基本的版本， 我觉得V-model是个很好的测试和开发交互的模型。
1、软件开发的需求分析阶段：开发人员获得并生成客户的需求说明书后，需要认真核对需求说明书是否完整和准确。这样可以确保开发人员开发的软件模型和客户需求不至于差得太远，也就是版主所说的频繁变更问题。
2、软件开发的代码生成阶段：开发人员在开发过程中应一个完成模块后尽早测试，保证该模块的正确性；并由单元测试-集成测试-系统测试依次完成。这时软件测试人员和开发人员的合作是很紧密的。
3、软件开发的质量保证阶段：软件第一版完成后，如果出现bug或者客户有新的要求等等，需要重新对相应模块进行修正，并进行回归测试。
偶的观点大概是这样的。
突然想起微软和Google的软件开发流程。一个是生成了一个软件版本后，通过投入给客户使用得到一系列的bug反馈，从而在第一个软件版本的基础上形成第二版、第三版……；而Google则是开发出一个基本的版本，然后直接投放到网上让大众测试，感觉大众的参与频率更高，效果ms更好。
有点扯远了，毕竟微软和Google一个是做操作系统这样的大型软件，一个是做中小型软件，开发和测试的人员、资源管理是不同的。
版本控制
1.预测很重要;2.研发成型产品需要大致运行一遍功能点
3.测试计划和测试沟通很重要.融洽的团队,有利于工作. 冒烟测试很重要
回复31#
原帖由 yayapang 于 2008-3-4 13:36 发表 http://bbs.51testing.com/images/common/back.gif1、 测试从需求阶段开始介入。加入测试角色进行需求分析以及需求评审工作可以有效避免因为需求不清以及需求歧义导致的测试版本更新。
2、 测试部分介入测试之前，开发团队需要提供一个可测试的基准版本。
3、 测试 ...
我个人觉得，对于测试团队来说，主导（或者说是控制）版本的发布是一件很危险的事情．在实际的项目过程中，你获取了主导的权利，那么大家就会把相应的责任加在你身上（当然这没什么不对），以后产品发布或者相应的进度出了问题（出问题经常是难以避免的），项目的其他人（甚至是除了测试团队外的所有人）都会认为应该为此负责的人是测试团队，但是这绝对是不公平的，我个人觉得产品出了问题，开发团队和测试团队都有责任，甚至开发团队的责任可能应该更大些，但是因为产品的发布是你主导的（拍板，"say go!"的人是你），那么大家就会把大部分的责任都加到你身上，追究测试团队的责任，你将可能面临很大的压力．你可能保护不了自己，也保护不了团队的成员． 对于这个问题，我觉得首先应该分析清楚引起频繁的版本的原因是什么？我觉得有以下3种原因：
1. 客户方经常提出对需求的修改；
2. 开发前期的需求分析没有做好；
3. 开发提交的软件版本质量太差，达不到进行系统测试的标准；
针对以上3种可能的原因，相应的对策如下：
1. 如果是客户方经常提出对需求的修改，则可以与他们协商尽量在需求阶段提出，如果是在设计编码阶段提出，则
应该明确需求的修改对测试有无影响，如果有大的影响则要拒绝此次修改，可以放到下一个版本中解决；如果没有
大的影响，则可以修改，不过这样的变更次数要尽量少。
2. 如果是开发前期的需求分析没有做好，则要加强需求分析的质量，要对每一个需求的功能点都分析得很透彻。
3. 如果是开发提交的软件版本质量太差，则可以在软件系统正式进行系统测试时，先进行预测试，主要是对软件的
基本功能点和核心功能进行测试，如果通不过，则不能进行正式的系统测试，这样就避免了出现边测边改、边改
边测的现象。另外也可以在制定测试计划时，在测试挂起/恢复的条件中写明类似如“当测试发现的缺陷数量
比较多，导致有40%以上的测试用例无法继续执行下去时，测试被挂起！”这样的标准，并且还要让开发经
理、项目经理以及高层管理人员知道，这样当发生这样的情况时测试就不能继续执行下去。此外，进行系统
测试时应该以一个版本为单位进行测试。
以上是我个人的看法，如有不当之处，请大家指正，谢谢！
下面说说频繁的版本变更问题：
下面说说频繁的版本变更问题：1.制定项目计划不合理；
2.开发人员个人心理素质差；
3.开发人员技术还没有达到一定的水平；
4.开发人员做出来就升级，没有通过全面的测试；
5.开发人员对质量不是很严格，没有质量意识。
测试过程中如何应对频繁的版本变更？
首先，版本变更，是要对变更的严重程度有所估计的1. 需求变更，导致产品/项目出现彻头彻尾的一些变化
这种情况，理论上我们是要坚决杜绝的
这就需要做好最初期的需求工作
做需求的时候，测试组可以多确认几次
不能嫌麻烦，project manager说什么样就什么样
test manager要有高度的积极性去一而再再而三的确认每一条细节
把不可测不明确的需求扼杀在摇篮里
但是，估计大家都会不可避免遇到这样的情况的，尤其是客户定制的一些项目
客户是上帝啊，他们的想法有不可预见性
很可能就在半年以后，突发奇想，给你来一个大逆转
这个时候怎么办呢？
我个人还真的没有什么好主意
遇到这种情况，只能是整个项目组，包括测试组的人重新坐下来商量讨论一番
确定这新增加新改动的需求对原来的进程有多大的影响
进而视情况绝对如何处理
如果影响不大，那好办，只要稍微的修正一下需求用例，然后按原计划进行
如果影响很大，那可能就得重新制定开发测试计划了
整个项目的进度表都要随之调整
2. bug修复导致的版本变更
这种情况不可避免的
我个人认为，应该有不少的公司都是这种边测边改的情况
我倒觉得这样的情况不是什么坏事情
我建议的做法是
在合适的时机引入daily build（产品相对稳定，或者某些模块逐步完成，进入增 值式集成测试的时候）
每天的测试都用新版本进行
但是测试内容还是按照原定计划进行
即，在第一遍测试没有完整的做完之前，不考虑任何回归
当全面测试结束以后，再开始回归，验证bug的修复情况
在回归过程中，一方面跑例行的功能自动化
另一方面，验证bug（这是重点）
回归也跟第一遍测试一样，以新版本为主
但是在未完成完整的一遍回归之前，都是接着昨天的活往下干。。。
个人建议，仅供参考。。。 利用版本控制工具把，这个问题我也提出过，没有人解答。
自我觉得是需要利用工具来控制，分轮测试，一轮未进行完之前，赞不修改，以免边测边改，永无止境。 1.在测试计划里明确进入和退出测试的准则
2.让冒险测试起到它因有的作用,基本功能不能实现有哪个基本功能不能实现都应该在冒险测试的时候发现,然后把问题汇总并提交到BUG管理系统定为最严重级别
3.冒险测试不通过的原因要追查到底,沟通不到位的原因还是人为不负责的作法所引起的.这些数据都可以是员工绩效考核提供参考并做一些处理.
4.某个版本的BUG数量修复太少(根据实际情况判断),做为测试管理者是不应该接受这种版本的
5.版本号变更太多,项目经理也是有很大的负责的,应该指针些问题在全项目组内开会分析问题,并把结果发给公司高层负责人或让其参加会议. 原帖由 51testing 于 2008-2-29 18:11 发表 http://bbs.51testing.com/images/common/back.gif
不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继 ...
我重新思考了这个问题,这个问题的关键在于版本的频繁更替,根源应该是在软件的版本控制方面中出现的问题.
应该遵循“提交->版本集成->集成测试->FIX版本->版本发布->版本备份->功能测试”。对每一个环节都要设置入口准则和出口准则,与软件的质量控制结合在一起! 学习中！！:) :)
提出自己的看法
我做测试还不到一年，谈谈心情！看了前辈们的心得感受很深，有些情况跟我们公司的很类似。我做手机测试，一个项目已经脱了3个月了。但是好像没动静，我就这样天天抱着手机测啊测，我感觉没意思了。:(产品经理也就记起来了就问我一下。说测试的怎么样了，项目经理也不管。改BUG也慢，成天不知道在干啥。我测的怎么样了。他也不问，成天改版本。改了好多了。但还是BUG多多啊。我有时候看不到希望。时间就在我手中流失了。希望前辈们看了我这帖子能给出回复！谢谢！
[ 本帖最后由 longhu123 于 2008-3-11 12:01 编辑 ]
我们项目组的做法：
在测试过程中，版本的频繁变化的确让测试人员头疼尤其是在测试人员不充足，时间紧的情况下，开发人员提交的测试版本在没有进行单元测试就匆匆集成下发，导致测试人员在接到新的测试程序后，还没有运行几步就出现了致命性的错误，此时测试人员不得不打回开发人员进行修改，在下发－打回－修改－下发如此的反复循环，费时费力，而且还是测试只成了一种边缘性的测试，很难进行系统的测试。
我们项目组的做法是：每天都有开发组的专人负责下发保证可以正常化运行的版本，测试组人员在当日只测试这一个版本，如果发现错误统一提交到bug库，由开发人员统一进行修改，修改完后在统一下发版本，再进行测试，这样最起码可以保证每天的测试都有效。 每个阶段的基线控制没有做到位啊!!
个人认为不是管理问题是人的问题,开发自己要找原因,他找不到就全推给测试的,最后就进入堵塞了
很受启发！
做测试做了几年了，在实际操作中，版本频繁变更的问题确实很常见！今天看了这篇文章，深受启发，并将其载入到日志中了。希望对日后的工作有所帮助。 好，，我又收获不少东东`` 具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：
×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；
×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；
×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。
要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。 具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：
×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；
×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；
×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。
要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。 我认为有以下几个关键点：
1、在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
2、开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；
3、每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
4、强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；
5、强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
6、强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
7、积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。
要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。
