怎样有效降低测试的轮次？（08-08-18）（获奖名单已公布）
在日常的测试工作当中，一个版本的发布常需要经过五轮或者六轮的测试，导致测试人员身心疲惫，工作积极性不同程度的下降。为了改变这种现状，我们在项目管理或执行当中应该注意那些方面呢？期待各位同行的建议。
感谢会员okokokk提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至8月24日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接
一等奖zhuzx当当购物卡50元25#
二等奖archonwang300论坛积分10#
二等奖阿七300论坛积分 14#
以下说说我个人的看法，见笑了:>
1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定；但是有一点是确定的，那就是当我们在做测试计划的时候，测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致。
我想五轮或者六轮的测试，最主要的是没有在测试之前做好测试计划吧。
3.如果提前订了测试轮次，但是程序一直有bug怎么办？来来回回测试，导致人员身心疲惫，如何解决？
引用《有效软件测试》：不管是哪个测试阶段，为软件测试执行周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是非常重要的。
以上所说的入口标准和出口标准应该标准化，而标准化的基础应该是经过若干项目考验的标准。测试人员要及早和开发人员讨论入口和出口准则。
举个样例说说出口标准的一部分：
a.已经执行了用来满足系统指定的功能和非功能性的需求的测试；
b.在测试结果中记录的所有的1级，2级和3级（导致运行中断的，紧急的和优先级的）软件问题都已经解决；
c.在测试结果中记录的所以的1级和2级（导致运行中断的，紧急的）软件问题都已经解决，同时报告的90%的3级问题也已经解决。
4.质量方针
现实中预算和进度都有一定的限度，一定存在一个测试必须结束和产品必须发行的时刻。在软件测试中，最困难的决定可能就是停止测试的时机。为了帮助作出这个决定，必须建立软件完成和发行的质量方针。比如说一万行代码中有多少缺陷，当低于这个量时，测试过程可以结束。
总的来说，无论是开发还是测试，都应该建立一个标准的工作流程。
回复 1# 的帖子
以下说说我个人的看法，见笑了:>1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定；但是有一点是确定的，那就是当我们在做测试计划的时候，测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致。
我想五轮或者六轮的测试，最主要的是没有在测试之前做好测试计划吧。
3.如果提前订了测试轮次，但是程序一直有bug怎么办？来来回回测试，导致人员身心疲惫，如何解决？
引用《有效软件测试》：不管是哪个测试阶段，为软件测试执行周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是非常重要的。
以上所说的入口标准和出口标准应该标准化，而标准化的基础应该是经过若干项目考验的标准。测试人员要及早和开发人员讨论入口和出口准则。
举个样例说说出口标准的一部分：
a.已经执行了用来满足系统指定的功能和非功能性的需求的测试；
b.在测试结果中记录的所有的1级，2级和3级（导致运行中断的，紧急的和优先级的）软件问题都已经解决；
c.在测试结果中记录的所以的1级和2级（导致运行中断的，紧急的）软件问题都已经解决，同时报告的90%的3级问题也已经解决。
4.质量方针
现实中预算和进度都有一定的限度，一定存在一个测试必须结束和产品必须发行的时刻。在软件测试中，最困难的决定可能就是停止测试的时机。为了帮助作出这个决定，必须建立软件完成和发行的质量方针。比如说一万行代码中有多少缺陷，当低于这个量，我们就可以视为可以结束测试。
总的来说，无论是开发还是测试，都应该建立一个标准的工作流程。
大家有好的看法和见解可以一起交流。:D 个人觉得这个问题没有绝对避免的手段。从某种角度来讲软件测试甚至扩展到所有产品测试都必然具有重复枯燥的一面。我们能做的可以是一是减少重复的次数，二是降低每一轮测试的枯燥程度。后一种方式有点背离题目，但更有效。
要真正减少重复的次数没有太好的办法，只有增强质量控制，减少缺陷数目，重开缺陷数目和繁殖缺陷数目（由于修改缺陷的代码而引入的新缺陷），使缺陷数目快速收敛。另外就是提高每一轮尤其是头一轮的测试效率。好的测试用例设计能帮助减少测试数，提高效率。
倒是在降低测试枯燥度上我们有很多文章可以做。
1。用迭代开发模式，每次测新完成的一小块功能，但大多是新功能，不容易产生厌倦感，旧功能怎么办--
2。测试自动化。这个谁都知道，自动化测试省时省力，而且机器是不会厌倦的。
3。调整构建频度，精测和粗测相结合，用例要恰当分级。通常第一轮测试士气高涨，适合精测，以后对于风险不高的部分可以降级，测试详尽程度依次为：full test(100% test cases)>end to end test(基于场景)>regression test>happy path>smoke test>sanity check>build verification采用哪一种可以根据不同情况定义。
4。调整用例测试和探索测试的比例。执行用例枯燥乏味，而探索测试就有趣的多，可以更好地激发测试人员的积极性和创造力。通过思索找到潜在的“高深“缺陷对于测试人员来说是很有成就感的。从项目的角度来说也很有意义，一些项目里由于杀虫剂效应很大部分缺陷都是通过随机测试或者探索测试找到的。
5。轮换分工。
呵呵，先想了那么多。 斑竹大人，我不知道为什么我昨天的帖子没有被贴出来，有什么问题么？ 说说自己的愚见，为什么测试的轮次会增加，版本会很多呢，造成这个原因产生的原因可能有两种
1、是测试的遗漏，并不可能一次发现所有的bug，并且是每次都有新的bug产生，开发总改不完，以致很多版本已经产生还有新的bug发现
2、是由于开发修改的问题又带来新的问题，还有可能是根本就没有修改，或者没有经过详细的单元测试
第一个问题的解决方式需要注意下面几点
A、 测试的系统的业务需要熟悉。作为一个资深的测试人员必须考虑的比较细腻，尽量杜绝功能点的漏测的情况，发现漏测要及时总结得失，不断的提高，争取更早的在测试的版本就发现bug
B、 加强测试用例的评审。对于测试用例的rewiew至少需要开发，需求一同进行，查漏补缺，好的测试用例是保证测试质量的基础
C、 需加强回归测试的覆盖率。在时间充裕的情况下，每次回归测试最好覆盖所有的内容，这部分可以借助测试工具，同时少不了手工回归一些问题
第二个问题的解决方式需要注意下面几点
A、 控制bug的reopen和版本的冒烟不通过次数。增强开发人员单元测试的意识，开发完的模块，自己首先要有一个自测的过程，修改完的bug也应该经过自测再发给测试人员版本去测试，这个可以考虑在bug的reopen的个数数量收集和冒烟测试不通过上有一个指标，和开发人员绩效挂钩，也就是说如果开发人员不自测，自然reopen的bug会增多，冒烟测试不通过的几率也会增大。
B、 修改bug的人员最好由熟悉代码的人员完成。并不是所有的人都可以修改bug，bug最好由对系统熟悉并且对此模块代码熟悉的开发来完成，如果由其他人来完成，往往对代码理解的不够透彻。经常会引来更大的问题，使软件变的更加脆弱。
这是我的一点看法，如果还有其他的欢迎补充，说的不对的也请大家指出。 TO： jiaozi
我有几点不明白，请赐教：
1、“测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致”：这是一种理想的情况，我认为在绝大多数的情况下，测试轮次包括测试天数都会因项目的变化而变化。就我现在在的这个项目来说，客户会时不时地提出做整套的回归测试；这并不在我们的计划范围内，但我们必须做。
2、一般情况,项目会对整个项目的测试有入口及出口标准。这个标准是用于每个ITERATION或是整个项目交付时，对这个项目的一个标准。
所以我不清楚这个入口及出口标准如何能影响测试轮次？
假设我们按这个标准来，如果1-3级的软件问题解决了，我们就不需要再回归测试了吗？ 4-5级的软件问题就不需要去发现吗？
可能我也有一些误解，请大家拍砖。
原帖由 jiaozi 于 2008-8-18 17:45 发表 http://bbs.51testing.com/images/common/back.gif
以下说说我个人的看法，见笑了:>
1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定； ... 个人认为有三个方面：
第一，从需求上来说，有可能客户不断的提出新的需求，或者说是改需求，所以需要从需求上把关
第二，编写代码的质量，即程序员方面的原因引起的：程序员写完程序没有自检，也不管改好了没，直接丢给测试人员，或者说程序员的代码水平比较差，一些处理的不够好，而测试人员是黑盒测试有可能造成只是发现表象，真正的原因没有找到，埋下了隐患。
第三，测试方面引起的原因：测试管理方面的流程不规范，比如测试用例写的不够完整，或者根本没有写测试用例，随便测，这就很容易造成测试的不够详细，测试执行的不够认真等，BUG没有完整记录等等
第四，管理上引起的：主要是版本管理混乱，这个是最严重的问题，边测边改简直是一件太恐怖的事情，但我想很多单位可能都有这样的原因
改进的方面就是针对以上三个方面，另外我觉的重要的一点就是绩效要和管理挂钩，如money，只有这个大家可能才是真正的比较在乎的:lol 只要关系到money我想没有几个会跟它过意不去的
十分赞成这个观点！
我们公司也因为回归测试太频繁，也在找相应地减少的方法，但是至今的成效并不大。所以也是往提高测试人员的兴趣为主，同时也注重各个成员对整个项目的整体把握。
原帖由 goal1860 于 2008-8-18 18:55 发表 http://bbs.51testing.com/images/common/back.gif
个人觉得这个问题没有绝对避免的手段。从某种角度来讲软件测试甚至扩展到所有产品测试都必然具有重复枯燥的一面。我们能做的可以是一是减少重复的次数，二是降低每一轮测试的枯燥程度。后一种方式有点背离题目，但更 ... 呵呵，不同的系统其回归测试的相关策略是不同的。现就该问题说明下个人的一些观点：
1. 自动化回归测试的确可以缓解这种问题，但是仅限于由这个必要和实力进行该项工作的公司。很多公司在项目开发上比较少使用这种方式，是因为这种方式的初期投入巨大且成效并不一定很好（受限于很多的因素，如开发流程是否规范、文档资料的是否完备等因素），另外，其实施成本高过手工回归很多倍（可能是手工测试投入的5倍以上）——不论在人员素质上，管理成本上，还是实施周期上。如果不是一种长期的、可延续性的项目或产品，则无法突出其效能，甚至是浪费有限资源在一个无底洞上。另一个缺点也是很明显的，则是该项工作往往滞后开发很多，需求的变更、编码设计的变化对其影响更甚。除此之外，目前的自动化回归测试技术还存在僵化、死板的问题，目前还没有一套比较成熟、灵活的框架可以适应所有的系统来完成对应的自动化开发，仅限于某一类特定框架、某一种特定类型而论。
2. 可采用迭代的开发模式来减少测试次数——我觉得几乎不可能。从开发模式上来说，频繁进行集成的确有助于提高系统的代码质量，提高集成的效率，但是从测试方面来说，该问题的实质并没有得到缓解。标准RUP的生命周期是集成不断，测试不断的生命周期，该周期内，只要一次正式发布，则必然有一次正式的测试过程，无论其质量是否已经真正提高了，该过程无法省略，也绝不可能省略。这种方式的有效性需要基于设计的模块间低耦合度才能达到其应有的效能，但是问题是现代的大型系统往往都是相对耦合度较高的系统，其模块间接口、系统间接口繁杂，必然导致测试工作量成倍增加，我觉得，若是这种情况，倒是应该考虑第一点的自动化测试说明，但是手工测试依然无法避免，至少要一次。讲到这里，相信大家都明白，开发模式无论如何变化，其最终的测试工作的简化是基于开发的具体流程而不是开发模式的好坏。
3. 版本管理。这个方法可能是被认为是最有效的办法，但是对于一个需求不断变化的系统而言，实现其版本管理的实质应该是对需求范围的阶段性实现进行管理的广义定义，而不是单纯意义上对代码、文档、模型、发布等内容上的管理。讲白了，版本管理的方法可能更多的是治标而不是治本。光靠这个方法还不能完全实现测试效率的提升。
个人觉得提升测试效率，降低测试轮次需要多方协作，数种方法组合才可能真正有效，必须针对特定的开发模式，系统架构、当前的阶段以及可用的有效资源，着实确定各项方案策略，结合实际的管理现状才有可能达成该项目标，否则的话，往往疲于奔命，劳苦不堪，却无任何成果可言。
[ 本帖最后由 archonwang 于 2008-8-19 14:45 编辑 ]
回复 7# 的帖子
呵呵，7#的回复很现实啊。说点自己的看法1. 关于三方协同。真的很难，几乎不可能（除非一个人可以同时担任这三个角色），这几个角色中总会有几个角色会妥协或退让，进而达成一种协同一致。——但是这个仅仅是谅解，并不是真正的一致哦~~
2. 有没有标准对测试轮次的确有影响，但我觉得是必要条件，不是充分条件，这项不是决定性的。往往更多的情况下标准是个参照，更何况，对标准的理解人人有异，仅能做个大概而不能绝对。很多问题最后还是必须集体讨论最终决定的。
3. 回归测试需不需要不是任何一个人说了算，而是在开发过程或维护过程中，出于责任规避，利益获得等缘由，为保障现有功能/业务做出的一种相对理性的选择。标准在这里是什么，仅仅是参考。一个参考如何决定选择的结果？大家以为如何？ 一般来说，测试过程是繁琐的，测试人员疲惫是正常的。
如果实在要减少工作次数而且效率提高的话，可以在以下几个方面多下点功夫。
第一，准备要充足全面。
第二，需求一定明白清楚。
第三，及时记录Bug以及采用轮班制，但是最好还是一起来，这样子才能发现更多的问题。
第四，回归测试时要留心，不要漏掉错误。
第五，最后，最重要的一点，即使没有完成，也不要让测试人员过多的加班加点。
为人Boss者，以德服众，才能有立足天下的资本嘛。
回复 7# 的帖子
TO: jiuquanzi你提到的问题都很好，我做了以下的解释，如果有不对的地方请指出。
1.以软件外包的项目为例，“测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致”这种情况是要做到的。从项目开始报价开始，我们所开发的软件应该就有了明确的生命期，即版本release的时间。那么作为测试负责人等三方应该会制定有效的项目开发计划或测试计划，计划包括测试用例的设计周期以及测试的轮次和时间。当已经得到项目变化的通知后，测试负责人就要及时的更改测试计划，包括人员以及任务的分配。
“客户会时不时地提出做整套的回归测试；这并不在我们的计划范围内，但我们必须做”，这个问题我想说明的是，回归测试在我们做测试计划的时候已经包含了，而且在项目的前期，我们应该和客户达成共识，有关会对回归测试的具体工作。如果客户时不时的提出一些我们没有计划的工作，那么作为测试负责人是需要和项目经理沟通，将这个情况反映，协商出一个好的解决办法。客户虽然是上帝，但是要求应合理。
2.有关测试的入口和出口标准，我想说明的是：
控制测试的入口标准，是保证程序版本的稳定，并且是测试周期的基础。
控制测试的出口标准，测试组能确定测试工作完成的时间，测试资源以及人员是否充分。
我举出的一些出口标准，只是一些个人的看法，针对不同的项目可以有不同的标准，但是制定标准是必须的。
回归测试是在测试的后期必须做到的测试，验证缺陷是否解决，保证交货版本的质量。并不是不需要回归测试。
我们作为一名测试人员，当然是希望发现更多的问题，使得交出的版本几乎没有问题，但是“大家都明白测试本身并不能产生出高质量的产品---测试的质量是不可能成为产品质量的”。在程序员保证开发质量的同时，我们测试制定有效的测试计划，考虑问题全面。
:D 我把自己的一些工作体会和大家分享，有说的不好地方，请大家指出哦。 *_*
[ 本帖最后由 jiaozi 于 2008-8-20 09:44 编辑 ] 1 从源头抓起--需求
不合格的需求分析.如客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与.用户需求的不断增加,这样都是测试的时候版本更新次数过多和频繁的原因.所以这里就要求我们的需求人员和客户良好沟通,要和足够多的客户,用足够多的时间,理解足够多的需求.尽量减少后期的需求变动.(这里说的用户包括了客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者),最后将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成，也能确保软硬件系统功能匹配适当。有效的变更控制和影响分析过程也能降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量，以使所有风险承担者感到满意。
2 从安排上控制
项目开始后,项目经理或者再上一级的BOSS要集合所有参与项目的人员召开项目计划会议,制订项目日程计划,如开发多久,测试多久,开发提交测试的标准,测试测试完成的结束标准等等.这是给测试人员一个时间概念和压力,认真测试.当然安排的BOSS心里肯定要定一个合理延时的天数.
3 开发
这里不好说了,开发写的好,肯定我们测试的次数肯定要少了,这里就要强调开发的质量了.单元测试!!!也就是我说的开发提交测试的标准了.基本的功能点都要过,每个公司的准备都不同,但至少要测试走的下去吧,比如购物网站,选商品,下单,支付,这条主线要下的去吧,然后才好在支线把没做好的XXBUG发现出来,(这是最差的情况了,呵呵o(∩_∩)o...)
4 测试
从需求开始,测试人员就要参与到需求讨论中去,这样才能把需求吃透,并且提示在测试的角度看需求存在的问题加以补足.这样才能把项目涉及的方方面面都想到.然后就是写测试用列了,需求都很明白了,想到的方面也齐全了,写的测试用列覆盖率就上去了,质量肯定差不了,当然,测试用列还是要评审的,100个人看世界,有100种心情嘛.团体一起讨论,能有效的改善测试用列的质量.软件出来以后,测试要分优先级别,先测试主线,然后测试新添加的功能,然后测试支线,再测试整体,这也是属于先功能后系统的1种.我还是以购物网站为例说下,购物网站,肯定是客户选择商品-下单-支付-签收为主线,所以先要保证其正确性,然后再测试这个版本新添加的功能是否完成了,然后再测试其他的支线,如商品展示,卖家买家评价,站点短消息,邮件等等相对弱点的功能,然后就要整体测试了,到这里就要全面测试了,完成以后,再进行安全测试,如攻击测试,注入测试等,到此测试通过以后就可以发布了,在发布后还要进行跟踪测试.好像有点跑题了,之所以要分成这样的优先测试,其实是有目的的,如果我们在主线就出错了,其他的不要再测试了,直接打回去,这样测试就可以节省测试的时间,不会傻傻的吧网站全部测试完再打回去.呵呵,这也是我个人的做法,不知道你们同不同意啦,呵呵,我用的效果还是很不错的.
5 环境
测试的环境不能让人动.要保持测试环境的干净,测试环境的更新和换版本,修改最好是测试部门的人员自己弄,有的公司从测试,部署,发布都是开发人员弄,有什么问题和BUG 也是在测试服务器上直接改,这样和真实环境就产生了差异,此外,我们的每1次更新和换版本都要记录到日志文件中去,便于更新时,提醒自己是否遗漏了什么修改的东西.
6 地位和交流
为什么说这个呢,地位对测试还是很重要的,如果测试部门在项目组"潜意识"里地位比较低,开发叫你测,你就测,开发说改就改,测试的人员肯定会被折腾死,反反复复测试是肯定的了,所以才会提到地位环境,不过好像现在的公司测试组的地位一般还算平等吧,o(∩_∩)o...,然后就是交流和沟通了,测试和需求人员,测试和开发,在项目进行过程中发挥重要作用.测试的时候不懂的要及时问,一些报错的页面等等,也要和开发人员说说是什么情况引起的,这样使你自己可以在代码层面了解BUG的产生,知道了原理,找到BUG的几率就翻了N倍了.
7 总结
测试版本的更换说到底,是个个部门工作的堆积体现,个个部门都做的好,测试就做的少了,个个部门1人差1点,到测试就是几何数级的放大.所以项目的成功是团队的集体努力.就让我们吧每个环节都做好,这样才是王道!
[ 本帖最后由 阿七 于 2008-8-19 17:50 编辑 ]
怎样有效降低测试的轮次？
降低测试轮次的唯一方法是提高每一轮测试的有效性。一个版本从提交测试到最终的发布经过五、六轮的测试很正常的事情，没有什么大惊小怪的，反倒让我担心的是这几轮测试测试人员身心疲惫，并且影响到工作的积极性，这样的结果会不会影响到最终的测试质量。
一个完整生命周期的产品或是项目，从功能测试、集成测试、系统测试、发布测试再到客户验收，这可能是一个相当长的时间过程，这一系列过程中所完成的测试版本怕不止这五、六个版本而已，所有测试版本的制定都会在测试计划中表现，是由测试规模的大小来决定的。
如果问题所提到的版本发布指的是从一个版本提交到能够真正展开测试，需要经过五、六轮的反复，那么就应当考虑版本提交质量的问题了。
问题的解决方法，一方面要提高开发人员的送测版本的质量。这个需要和开发人员达成共识，得到开发人员的承诺。（入口条件）
其次需要辅助相应的测试流程，并严格执行。流程是规范彼此的操作，应保证执行的有效性。
1）保证计划的正确制定和执行。如果测试反复超过计划预期，则会减少测试的时间，无法保证测试质量。有效的报告问题测试执行中的问题，不仅仅是系统存在的问题，还包括测试执行中所出现的风险和问题。
2）保证测试的入口和出口的质量。测试入口是要求提交测试系统的质量，出口是保证最终测试交付物的测试质量。高质量的提交测试系统是实现有效测试的重要前提，不是任何一个送交的系统都能够测试的，需要在展开测试前验证送交系统的可测试性（不管你是用送测试单还是彼此之间的约定，可测试性一定是需要验证的，好像有人叫冒烟测试来着）
3）有效测试版本控制。每一轮的测试版本应当是有效而稳定的，有针对性的测试会提高整体的测试质量。提交测试系统的质量不高，要考虑是不是提交系统的单元测试和自测度是否有效的执行了，适时叫停是个不错的选择。
4）不断改进。除了发现系统的BUG，要不断发现测试现有工作方法、流程所存在的问题缺陷，不断的改进，提高整体的测试效率和测试质量 （出口质量）
最后需要提高大家的质量意识。质量免费，质量不是某一个人或是某一些人的事，彼此的质量意识和有效协作才是保证最终质量的根本所在。
总之，摆正自己的位置，不焦不躁，始终使自己保持一个良好的工作和精神状态。
一切从自身做起，严格执行自己的工作职责，不断改进自己的工作，用自己专业的工作态度影响周围的同事。 我的回答，请看，，
我答：怎样有效降低测试的轮次？
http://www.51testing.com/?18049/action_viewspace_itemid_90664.html
回复 14# 的帖子
总结的非常好:) 我是一个即将迈进测试行业的新手，我提出我的想法，如果觉得幼稚千万别见笑啊我觉得可以在回归测试阶段做一个测试的度量，这样可以知道大概在什么时候能结束回归测试，发布新的版本
比如我们可以通过度量得到一些数据，然后制定一个BUG的跟踪曲线，通过对这条曲线的跟踪来决定是否还要进行新一轮测试
如果这条曲线处于一个收敛的状态，如果达到一个公司的基线的标准则可以考虑结束测试，发布新的版本 还是那几条
1、控制需求变更，这次版本不是必须引入的功能，可以在2期项目中加入
2、控制代码质量，采用冒烟测试，不合格的版本打回
3、提高测试质量，在一个版本里尽量发现尽可能多问题，不能抱有侥幸心理，还有下一个版本呢
[ 本帖最后由 zrg9399 于 2008-8-21 10:31 编辑 ]
个人意见
一个项目回归测试多次，公司怕的就是风险；为了减少风险，他就让测试的进行多次测试；
为了减少测试，也就要从需求开始，每个需求都进行评审，软件开发每个阶段流程都进行评审；预防bug；避免发现bug；
[ 本帖最后由 张帆Test 于 2008-8-21 10:43 编辑 ]
