1、 测试的粒子大小决定了多轮测试的复杂程度，这一点是不让测试员崩溃的前提，每一个的每一阶段的劳动成果都应该得到尊重。
在每一轮测试中，测试计划，测试方案，测试用例、测试环境和测试脚本可复用性是起重要作用的。
在开发设计过程中现在提倡低藕合性，在测试过程中也要注意这一点。所以测试用例的设计和测试脚本的设计也是要相当的功力的。
在每一轮的测试过程中只要把修改的部分和可能影响的部分重新设计测试用例和测试脚本，没有修改的或者可能没有影响的部分做回归测试。
2、 在管理中适当总结每个小版本的修改部分的原因和可能引起的原因进行分析，适当地评估因为不同的版本的测试所需要的工时。每个BUG修改后，修改的开发一定要指明是什么原因造成的，有可能影响的功能点是什么（这一点就关系到BUG的管理规范了）。
3、 在实际测试过程中，每一轮的测试不可能是全面的测试，应该具体指出第一轮的测试目标，第二轮的，最后一轮的测试目标。
在以住的项目中，一般是第一轮进行全面的系统的测试，第二版本进行BUG回归测试，第三版本进行重点功能的测试，。。。。。。。。。最后一个版本进行全面的验收。进入全面验收时的目标是发现可能影响发布的BUG。
4、如果是因为需求发生变更，测试人员一定要及时反馈因为变更而造成的影响。不能说不能发生变更，只能说应该尽可能地避免，所以一次需求变更，一定要把负作用让上层听到。 个人认为这种问题产生的原因有
1.需求在随意的更改。
2.冒烟测试没有通过，导致许多问题遗留在后期。
3.测试和开发没有形成一个完整的流程。
4.版本控制出现问题。
5.测试用例出现遗漏。
以上仅仅是我个人的观点，有什么不对的，请大家多多指教。 觉得这个问题，理论上可以解决，但在实际操作上难度很大！ 百家争鸣啊！以下个人拙见，如有不对之处请勿进行人身攻击。
我觉得作为一名测试人员，对业务的熟悉和产品的了解要有一定的深度，因为所有的产品不可能100%的测试到，在测试过程中必须做到取重避轻。就像是我们在测试过程中的一些很好的策略。其次，回归测试是不可能避免的，但是测试人员一次一次这样的回归测试，是不是有点像杀虫剂效应，难免会产生麻痹的意识。所以我觉得自动化测试可以更好的为我们服务，把我们有限的精力投入到设计分析中去，执行不过是人员的问题。
怎样有效降低测试的轮次？
软件测试的轮次多少，大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下，谈谈我们团队的做法，希望同行继续补充指正：1.让研发团队的领导重视测试：
测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直就是轻而易举的事情。
2.测试团队和开发团队的独立性：
国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个Bug，也就安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。
3.细化送测标准，建立完善的测试规范：
测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试平凡发布版本，不是什么新鲜事。目前，我们公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也能够有效的减少测试的次数。
4.测试部门建立详尽的预测试标准：
如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。
5.保持测试和开发独立的测试环境：
大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，我也去掉了绩效考核中“对无效的Bug”的考核项，大家终于可以放心的提缺陷了。
6.重视单元测试，提高被测软件质量：
很多时候，测试部门和开发部门单元测试比较马虎或应付客户了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现，加之项目进度的压力，给公司也带来了较大的经济负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。
7.重视测试用例的评审，提高测试用例的质量：
就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。
8.部门员工进行模块交叉测试，避免漏测提高测试效率：
测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。
9.加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：
加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗？特别是测试半天都没发现Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。
10.严格控制需求变更的流程，减少后期的需求变动：
在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。
非常赞同25#的说法
zhuzx，好久没有看到你答题目了，您讲的很精彩，很详细！！希望以后多参加51testing的答题活动，让我们学习学习，呵呵！！zhuzx楼主，你太强了，居然心有灵犀呢？
你讲的1、4、6、8、9这几点都非常适用，很有效。我很有同感，你太牛了。我的经验是：一般测试就3轮就OK了。补充个人的意见：
开发人员开发模块，自测试的仔细程度，很大程度上也影响版本的测试次数。 1.需求明确。每次需求变更都要落实到书面上，并通知相关人。
2.提高开发人员的质量意识，做好单元测试。
3.测试case详细，全面。
4.对于每次迭代都要重复测试的功能，最好用自动化测试。
5.有一个完整的开发流程和测试流程。并且保证相应软件文件完整。
25楼的朋友回答比较详细、经典
很佩服您的回答，概括能力挺强，是一块当领导的料！！！添加一些我的观点：
个人觉的可以冲配置管理上下功夫，限制版本Release的次数，不知道如何？
我的观点
1。感觉首先是需求方面不要频繁更改在需求分析的阶段需求工程师可以控制
最根本问题是客户无法控制
2。测试阶段测试人员在编写用例的时候合并同类项以及用例之间的合并（例：GUI测试用例和功能测试用例合并）
这个在编写用例的阶段测试人员可以控制
但对编写用例的测试人员对业务相当熟悉并且有一定的工作经验
3。对任何版本的测试首先做预测试
测试人员可控制
4。环境的搭建上 一定要按照客户的操作环境搭建有可能的话测试数据用客户的原始数据
客户的操作环境 测试人员可控制
客户的原始数据 因为面向的用户不一样所以客户的原始数据未必会给你（例：银行）
不可控制
这些都是本人能想到的 因为我还是个新手所以有些观点很不成熟希望大家能多多指教。
提点偶的一些看法啊
我觉得如果是作为第三方的测试，要相对好一些，因为测试的对象是确定的了，那这样测试计划、测试执行都相对稳定一些；那这样的情况下，关键是要看测试的入口以及出口标准的制定了。对于一个明确的小项目，因为项目的启动、试运行、初验、终验标准都是固定的，这样对于一个项目测试，关键是要看项目的目标，以及开发的整体进度，在开发的过程中注意模块测试已经部分功能、流程的集成测试；这样来说，测试轮次的执行关键是要看整体项目完成后的集成测试效果；一定程度上是要看开发的质量；
但，对于一个时间沿线较长的项目较大的软件产品来说，测试的轮次有时要根据产品提交的时间来定：一般来说，如果是对于时间比较宽裕的项目，那回归测试应该根据系统的功能做大的划分，对人员做好分工，交叉测试，查漏补缺，这样可以在降低测试轮次的同时，提高测试效率。
对于，一个系统功能更新较快，而现场需求较急的情况，在这种情况下，根本没有时间做完整的测试，这时，应该根据程序修改的内容（虽然不用做白盒测试，但是在看代码的基础上，可以判断某处修改的影响），对产品的模块做风险性，对高风险的模块，做尽可能全的回归测试，保证系统功能的正确性。
由于时间的关系，我就先写这么多，期待大家的精彩做答，相互促进喽。 以上总结很好 大家总结的都很好，我一定要好好学习啊。:D
高瞻远瞩的测试思维，非高手莫及
上轮每周一问中看到了sun_0910经理的精彩回答，今天又看到了zhuzx高瞻远瞩的测试思维方式，真是好极了！！！唯有送3朵鲜花表示敬意！！！添加一点我的想法，我是新手请勿见笑，还请高手指点：
好像“冒烟测试”和zhuzx中的“预测试”好像是一个吧，只是不同的叫法对吧！！！
麻烦zhuzx高手指点迷津，本人非常感谢！！！
降低有效测试的轮次
要降低有效测试的轮次需要多方面进行解决:1、软件管理：
1）项目管理：在项目管理中要求测试人员尽早从需求阶段介入到项目，保证测试人员对产品有深入的了解
2）配置管理：a.要做到有效的版本管理，避免因版本混乱而导致测试工作的重复；
b.要做到有效的变更管理，每一次变更要有效控制，并让测试人员也清楚
3）测试管理：测试工作要有计划性，制定比较合理的测试计划
2、人员素质：
公司软件管理方面得到有效保证后，人员的素质就是重要的影响因素：
1）、测试人员：写出覆盖全面的测试用例，做到有的放矢，提高测试质量
2）、开发人员：a.提交测试工件时需要进行自测，提高软件质量b.对软件构架要深入了解，避免修改当前BUG时影响其它功能模块
或是没有修改彻底，使回归测试的轮次增加。
3、自动化水平的提高：自动化水平也是比较重要的因素，对于回归测试使用自动化工具可以全面将回归涉及到的功能模块全面测试，提高测
试效率。
回复34楼的朋友，不知道是否满意，请版主保留：
首先感谢34楼朋友送的鲜花。下面是预测试与冒烟测试的资料
1. 什么是软件预测试？
预测试的概念：当软件产品转入到软件测试部门开始系统测试之前，开展软件预测试，由软件测试人员验证被测试软件的基本功能是否正常，从而保证系统测试不会由于软件基本功能的缺陷而挂起。软件预测试是软件测试可以正常进行的一种保证手段。
2. 软件预测试的必要性，何种软件项目和软件产品需要软件预测试？
必要性：软件预测试在软件产品开发测试流程中，是必不可少的一个环节，如果，缺少了软件预测试环节很可能导致软件测试被异常挂起。
软件预测试适用于哪些软件项目：软件企业只要有独立的软件开发部门和软件测试部门，就应该由软件预测试的环节，与软件项目类型没有必然联系。
3. 软件预测试的基本流程，参与预测试的人员角色划分、预测试阶段划分等等
(1) 由软件测试人员根据配置管理员发布的最新版本报告，到配置管理库上获取被测试版本的代码。
(2) 软件测试人员在编译环境上编译代码，如果代码编译通过，继续下一步，否则版本被返回，由软件开发人员修改相关问题，重新发布版本。
(3) 用版本库上提供的被测试软件安装包，在软件测试环境上开始基本功能测试。如果基本功能未通过测试，由开发人员修改相关问题，重新发布版本。
(4) 软件预测试还需要查验开发软件提供的相关文档，比如开发人员的版本验证报告、用户说明书、操作手册等等。
4.什么是冒烟测试：
关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。
冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。 1选取一组测试用例中最有效的
2 利用最少的步骤突显出软件的问题
3减少冗余
zhuzx非常感谢您无私的帮助，您是当今的活雷锋！！
刚看了的预测试与冒烟测试的相关理论受益匪浅，非常感谢zhuzx热心的教导。:lol
大道理外的补充
无废话.1.别想单纯的减少回归测试次数.为了最终质量,公司是不会因为你累不累的就减少次数的.
2.把关注点放在流程上,放在过程控制上,才能在最后少背点锅,少做点重复劳动.
3.自动化工具可以适当引入,我估计Test Manager也很同意这样,大家都喜欢省力,
4.按工业化标准,规格(需求)是严格控制不可随意更改的.若不能规范,...放正心态吧:lol <<在日常的测试工作当中，一个版本的发布常需要经过五轮或者六轮的测试，导致测试人员身心疲惫，工作积极性不同程度的下降。
为了改变这种现状，我们在项目管理或执行当中应该注意那些方面呢？期待各位同行的建议。>>
这个也涉及到开发人员的问题，如果开发人员在修复bug时，关联到其他的模块，产生连锁反应，对 测试人员来说是毁灭性的打击。所以在做项目需求时就应该把测试和开发人员安排在一起，然后对相关人员进行培训，尽量保持代码规范，和测试用例全覆盖，保证第一轮测试的完全覆盖性。
如果有实力的话，可以考虑使用自动化测试工具，在最后几轮测试的过程中，只做BUG修复验证，其余的回归测试和大范围的快速测试交给机器去做。当然这样会增加很多成本。
还有就是有些开发人员经常修复一两个bug就打个安装包发过来交给测试人员。我觉得这是测试人员 最不能接受的。有时一天会发三五个build，这个我觉得是测试人员最不耐烦的。应该注意一下。
