51Testing软件测试论坛

标题: 怎样有效降低测试的轮次？（08-08-18）（获奖名单已公布） [打印本页]

作者: fishy 时间: 2008-8-18 15:02
标题: 怎样有效降低测试的轮次？（08-08-18）（获奖名单已公布）
在日常的测试工作当中，一个版本的发布常需要经过五轮或者六轮的测试，导致测试人员身心疲惫，工作积极性不同程度的下降。
为了改变这种现状，我们在项目管理或执行当中应该注意那些方面呢？期待各位同行的建议。

感谢会员okokokk提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至8月24日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	zhuzx	当当购物卡50元	25#
二等奖	archonwang	300论坛积分	10#
二等奖	阿七	300论坛积分	14#

作者: jiaozi 时间: 2008-8-18 17:45
以下说说我个人的看法，见笑了 :>
1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定；但是有一点是确定的，那就是当我们在做测试计划的时候，测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致。
我想五轮或者六轮的测试，最主要的是没有在测试之前做好测试计划吧。

3.如果提前订了测试轮次，但是程序一直有bug怎么办？来来回回测试，导致人员身心疲惫，如何解决？

引用《有效软件测试》：不管是哪个测试阶段，为软件测试执行周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是非常重要的。
以上所说的入口标准和出口标准应该标准化，而标准化的基础应该是经过若干项目考验的标准。测试人员要及早和开发人员讨论入口和出口准则。

举个样例说说出口标准的一部分：
a.已经执行了用来满足系统指定的功能和非功能性的需求的测试；
b.在测试结果中记录的所有的1级，2级和3级（导致运行中断的，紧急的和优先级的）软件问题都已经解决；
c.在测试结果中记录的所以的1级和2级（导致运行中断的，紧急的）软件问题都已经解决，同时报告的90%的3级问题也已经解决。

4.质量方针
现实中预算和进度都有一定的限度，一定存在一个测试必须结束和产品必须发行的时刻。在软件测试中，最困难的决定可能就是停止测试的时机。为了帮助作出这个决定，必须建立软件完成和发行的质量方针。比如说一万行代码中有多少缺陷，当低于这个量时，测试过程可以结束。

总的来说，无论是开发还是测试，都应该建立一个标准的工作流程。

作者: jiaozi 时间: 2008-8-18 17:48
标题: 回复 1# 的帖子
以下说说我个人的看法，见笑了 :>

1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定；但是有一点是确定的，那就是当我们在做测试计划的时候，测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致。
我想五轮或者六轮的测试，最主要的是没有在测试之前做好测试计划吧。

3.如果提前订了测试轮次，但是程序一直有bug怎么办？来来回回测试，导致人员身心疲惫，如何解决？

引用《有效软件测试》：不管是哪个测试阶段，为软件测试执行周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是非常重要的。
以上所说的入口标准和出口标准应该标准化，而标准化的基础应该是经过若干项目考验的标准。测试人员要及早和开发人员讨论入口和出口准则。

举个样例说说出口标准的一部分：
a.已经执行了用来满足系统指定的功能和非功能性的需求的测试；
b.在测试结果中记录的所有的1级，2级和3级（导致运行中断的，紧急的和优先级的）软件问题都已经解决；
c.在测试结果中记录的所以的1级和2级（导致运行中断的，紧急的）软件问题都已经解决，同时报告的90%的3级问题也已经解决。

4.质量方针
现实中预算和进度都有一定的限度，一定存在一个测试必须结束和产品必须发行的时刻。在软件测试中，最困难的决定可能就是停止测试的时机。为了帮助作出这个决定，必须建立软件完成和发行的质量方针。比如说一万行代码中有多少缺陷，当低于这个量，我们就可以视为可以结束测试。

总的来说，无论是开发还是测试，都应该建立一个标准的工作流程。

大家有好的看法和见解可以一起交流。

作者: goal1860 时间: 2008-8-18 18:55
个人觉得这个问题没有绝对避免的手段。从某种角度来讲软件测试甚至扩展到所有产品测试都必然具有重复枯燥的一面。我们能做的可以是一是减少重复的次数，二是降低每一轮测试的枯燥程度。后一种方式有点背离题目，但更有效。
要真正减少重复的次数没有太好的办法，只有增强质量控制，减少缺陷数目，重开缺陷数目和繁殖缺陷数目（由于修改缺陷的代码而引入的新缺陷），使缺陷数目快速收敛。另外就是提高每一轮尤其是头一轮的测试效率。好的测试用例设计能帮助减少测试数，提高效率。
倒是在降低测试枯燥度上我们有很多文章可以做。
1。用迭代开发模式，每次测新完成的一小块功能，但大多是新功能，不容易产生厌倦感，旧功能怎么办--
2。测试自动化。这个谁都知道，自动化测试省时省力，而且机器是不会厌倦的。
3。调整构建频度，精测和粗测相结合，用例要恰当分级。通常第一轮测试士气高涨，适合精测，以后对于风险不高的部分可以降级，测试详尽程度依次为：full test(100% test cases)>end to end test(基于场景)>regression test>happy path>smoke test>sanity check>build verification采用哪一种可以根据不同情况定义。
4。调整用例测试和探索测试的比例。执行用例枯燥乏味，而探索测试就有趣的多，可以更好地激发测试人员的积极性和创造力。通过思索找到潜在的“高深“缺陷对于测试人员来说是很有成就感的。从项目的角度来说也很有意义，一些项目里由于杀虫剂效应很大部分缺陷都是通过随机测试或者探索测试找到的。
5。轮换分工。

呵呵，先想了那么多。

作者: goal1860 时间: 2008-8-19 09:23
斑竹大人，我不知道为什么我昨天的帖子没有被贴出来，有什么问题么？

作者: lisilin 时间: 2008-8-19 11:42
说说自己的愚见，为什么测试的轮次会增加，版本会很多呢，造成这个原因产生的原因可能有两种
1、是测试的遗漏，并不可能一次发现所有的bug，并且是每次都有新的bug产生，开发总改不完，以致很多版本已经产生还有新的bug发现
2、是由于开发修改的问题又带来新的问题，还有可能是根本就没有修改，或者没有经过详细的单元测试
第一个问题的解决方式需要注意下面几点
A、测试的系统的业务需要熟悉。作为一个资深的测试人员必须考虑的比较细腻，尽量杜绝功能点的漏测的情况，发现漏测要及时总结得失，不断的提高，争取更早的在测试的版本就发现bug
B、加强测试用例的评审。对于测试用例的rewiew至少需要开发，需求一同进行，查漏补缺，好的测试用例是保证测试质量的基础
C、需加强回归测试的覆盖率。在时间充裕的情况下，每次回归测试最好覆盖所有的内容，这部分可以借助测试工具，同时少不了手工回归一些问题
第二个问题的解决方式需要注意下面几点
A、控制bug的reopen和版本的冒烟不通过次数。增强开发人员单元测试的意识，开发完的模块，自己首先要有一个自测的过程，修改完的bug也应该经过自测再发给测试人员版本去测试，这个可以考虑在bug的reopen的个数数量收集和冒烟测试不通过上有一个指标，和开发人员绩效挂钩，也就是说如果开发人员不自测，自然reopen的bug会增多，冒烟测试不通过的几率也会增大。
B、修改bug的人员最好由熟悉代码的人员完成。并不是所有的人都可以修改bug，bug最好由对系统熟悉并且对此模块代码熟悉的开发来完成，如果由其他人来完成，往往对代码理解的不够透彻。经常会引来更大的问题，使软件变的更加脆弱。
这是我的一点看法，如果还有其他的欢迎补充，说的不对的也请大家指出。

作者: jiuquanzi 时间: 2008-8-19 13:45
TO： jiaozi
我有几点不明白，请赐教：
1、“测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致”：这是一种理想的情况，我认为在绝大多数的情况下，测试轮次包括测试天数都会因项目的变化而变化。就我现在在的这个项目来说，客户会时不时地提出做整套的回归测试；这并不在我们的计划范围内，但我们必须做。

2、一般情况,项目会对整个项目的测试有入口及出口标准。这个标准是用于每个ITERATION或是整个项目交付时，对这个项目的一个标准。
所以我不清楚这个入口及出口标准如何能影响测试轮次？
假设我们按这个标准来，如果1-3级的软件问题解决了，我们就不需要再回归测试了吗？ 4-5级的软件问题就不需要去发现吗？

可能我也有一些误解，请大家拍砖。

原帖由 jiaozi 于 2008-8-18 17:45 发表
以下说说我个人的看法，见笑了 :>
1. 首先要明确一个问题：软件版本在测试阶段中测试的轮次不是无休止的持续进行。
2. 其次，究竟是需要测试几轮？
大前提是每个公司应该对基本的测试轮次都有相应的目标和规定； ...

作者: 江南飞雪 时间: 2008-8-19 13:47
个人认为有三个方面：
第一，从需求上来说，有可能客户不断的提出新的需求，或者说是改需求，所以需要从需求上把关
第二，编写代码的质量，即程序员方面的原因引起的：程序员写完程序没有自检，也不管改好了没，直接丢给测试人员，或者说程序员的代码水平比较差，一些处理的不够好，而测试人员是黑盒测试有可能造成只是发现表象，真正的原因没有找到，埋下了隐患。
第三，测试方面引起的原因：测试管理方面的流程不规范，比如测试用例写的不够完整，或者根本没有写测试用例，随便测，这就很容易造成测试的不够详细，测试执行的不够认真等，BUG没有完整记录等等
第四，管理上引起的：主要是版本管理混乱，这个是最严重的问题，边测边改简直是一件太恐怖的事情，但我想很多单位可能都有这样的原因
改进的方面就是针对以上三个方面，另外我觉的重要的一点就是绩效要和管理挂钩，如money，只有这个大家可能才是真正的比较在乎的

只要关系到money我想没有几个会跟它过意不去的

作者: jiuquanzi 时间: 2008-8-19 13:55
标题: 十分赞成这个观点！
我们公司也因为回归测试太频繁，也在找相应地减少的方法，但是至今的成效并不大。
所以也是往提高测试人员的兴趣为主，同时也注重各个成员对整个项目的整体把握。

原帖由 goal1860 于 2008-8-18 18:55 发表
个人觉得这个问题没有绝对避免的手段。从某种角度来讲软件测试甚至扩展到所有产品测试都必然具有重复枯燥的一面。我们能做的可以是一是减少重复的次数，二是降低每一轮测试的枯燥程度。后一种方式有点背离题目，但更 ...

作者: archonwang 时间: 2008-8-19 14:29
呵呵，不同的系统其回归测试的相关策略是不同的。现就该问题说明下个人的一些观点：
1. 自动化回归测试的确可以缓解这种问题，但是仅限于由这个必要和实力进行该项工作的公司。很多公司在项目开发上比较少使用这种方式，是因为这种方式的初期投入巨大且成效并不一定很好（受限于很多的因素，如开发流程是否规范、文档资料的是否完备等因素），另外，其实施成本高过手工回归很多倍（可能是手工测试投入的5倍以上）——不论在人员素质上，管理成本上，还是实施周期上。如果不是一种长期的、可延续性的项目或产品，则无法突出其效能，甚至是浪费有限资源在一个无底洞上。另一个缺点也是很明显的，则是该项工作往往滞后开发很多，需求的变更、编码设计的变化对其影响更甚。除此之外，目前的自动化回归测试技术还存在僵化、死板的问题，目前还没有一套比较成熟、灵活的框架可以适应所有的系统来完成对应的自动化开发，仅限于某一类特定框架、某一种特定类型而论。

2. 可采用迭代的开发模式来减少测试次数——我觉得几乎不可能。从开发模式上来说，频繁进行集成的确有助于提高系统的代码质量，提高集成的效率，但是从测试方面来说，该问题的实质并没有得到缓解。标准RUP的生命周期是集成不断，测试不断的生命周期，该周期内，只要一次正式发布，则必然有一次正式的测试过程，无论其质量是否已经真正提高了，该过程无法省略，也绝不可能省略。这种方式的有效性需要基于设计的模块间低耦合度才能达到其应有的效能，但是问题是现代的大型系统往往都是相对耦合度较高的系统，其模块间接口、系统间接口繁杂，必然导致测试工作量成倍增加，我觉得，若是这种情况，倒是应该考虑第一点的自动化测试说明，但是手工测试依然无法避免，至少要一次。讲到这里，相信大家都明白，开发模式无论如何变化，其最终的测试工作的简化是基于开发的具体流程而不是开发模式的好坏。

3. 版本管理。这个方法可能是被认为是最有效的办法，但是对于一个需求不断变化的系统而言，实现其版本管理的实质应该是对需求范围的阶段性实现进行管理的广义定义，而不是单纯意义上对代码、文档、模型、发布等内容上的管理。讲白了，版本管理的方法可能更多的是治标而不是治本。光靠这个方法还不能完全实现测试效率的提升。

个人觉得提升测试效率，降低测试轮次需要多方协作，数种方法组合才可能真正有效，必须针对特定的开发模式，系统架构、当前的阶段以及可用的有效资源，着实确定各项方案策略，结合实际的管理现状才有可能达成该项目标，否则的话，往往疲于奔命，劳苦不堪，却无任何成果可言。

[ 本帖最后由 archonwang 于 2008-8-19 14:45 编辑 ]

作者: archonwang 时间: 2008-8-19 14:40
标题: 回复 7# 的帖子
呵呵，7#的回复很现实啊。说点自己的看法
1. 关于三方协同。真的很难，几乎不可能（除非一个人可以同时担任这三个角色），这几个角色中总会有几个角色会妥协或退让，进而达成一种协同一致。——但是这个仅仅是谅解，并不是真正的一致哦~~

2. 有没有标准对测试轮次的确有影响，但我觉得是必要条件，不是充分条件，这项不是决定性的。往往更多的情况下标准是个参照，更何况，对标准的理解人人有异，仅能做个大概而不能绝对。很多问题最后还是必须集体讨论最终决定的。

3. 回归测试需不需要不是任何一个人说了算，而是在开发过程或维护过程中，出于责任规避，利益获得等缘由，为保障现有功能/业务做出的一种相对理性的选择。标准在这里是什么，仅仅是参考。一个参考如何决定选择的结果？大家以为如何？

作者: 不杀捕杀 时间: 2008-8-19 14:59
一般来说，测试过程是繁琐的，测试人员疲惫是正常的。
如果实在要减少工作次数而且效率提高的话，可以在以下几个方面多下点功夫。
第一，准备要充足全面。
第二，需求一定明白清楚。
第三，及时记录Bug以及采用轮班制，但是最好还是一起来，这样子才能发现更多的问题。
第四，回归测试时要留心，不要漏掉错误。
第五，最后，最重要的一点，即使没有完成，也不要让测试人员过多的加班加点。
为人Boss者，以德服众，才能有立足天下的资本嘛。

作者: jiaozi 时间: 2008-8-19 17:26
标题: 回复 7# 的帖子
TO: jiuquanzi
你提到的问题都很好，我做了以下的解释，如果有不对的地方请指出。
1.以软件外包的项目为例，“测试负责人和技术经理，项目经理三方对测试的轮次，以及测试的天数已经达成一致”这种情况是要做到的。从项目开始报价开始，我们所开发的软件应该就有了明确的生命期，即版本release的时间。那么作为测试负责人等三方应该会制定有效的项目开发计划或测试计划，计划包括测试用例的设计周期以及测试的轮次和时间。当已经得到项目变化的通知后，测试负责人就要及时的更改测试计划，包括人员以及任务的分配。

“客户会时不时地提出做整套的回归测试；这并不在我们的计划范围内，但我们必须做”，这个问题我想说明的是，回归测试在我们做测试计划的时候已经包含了，而且在项目的前期，我们应该和客户达成共识，有关会对回归测试的具体工作。如果客户时不时的提出一些我们没有计划的工作，那么作为测试负责人是需要和项目经理沟通，将这个情况反映，协商出一个好的解决办法。客户虽然是上帝，但是要求应合理。

2.有关测试的入口和出口标准，我想说明的是：
控制测试的入口标准，是保证程序版本的稳定，并且是测试周期的基础。
控制测试的出口标准，测试组能确定测试工作完成的时间，测试资源以及人员是否充分。

我举出的一些出口标准，只是一些个人的看法，针对不同的项目可以有不同的标准，但是制定标准是必须的。

回归测试是在测试的后期必须做到的测试，验证缺陷是否解决，保证交货版本的质量。并不是不需要回归测试。

我们作为一名测试人员，当然是希望发现更多的问题，使得交出的版本几乎没有问题，但是“大家都明白测试本身并不能产生出高质量的产品---测试的质量是不可能成为产品质量的”。在程序员保证开发质量的同时，我们测试制定有效的测试计划，考虑问题全面。

我把自己的一些工作体会和大家分享，有说的不好地方，请大家指出哦。 *_*

[ 本帖最后由 jiaozi 于 2008-8-20 09:44 编辑 ]

作者: 阿七 时间: 2008-8-19 17:45
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 编辑 ]

作者: rolei 时间: 2008-8-20 09:39
标题: 怎样有效降低测试的轮次？
降低测试轮次的唯一方法是提高每一轮测试的有效性。

一个版本从提交测试到最终的发布经过五、六轮的测试很正常的事情，没有什么大惊小怪的，反倒让我担心的是这几轮测试测试人员身心疲惫，并且影响到工作的积极性，这样的结果会不会影响到最终的测试质量。

一个完整生命周期的产品或是项目，从功能测试、集成测试、系统测试、发布测试再到客户验收，这可能是一个相当长的时间过程，这一系列过程中所完成的测试版本怕不止这五、六个版本而已，所有测试版本的制定都会在测试计划中表现，是由测试规模的大小来决定的。

如果问题所提到的版本发布指的是从一个版本提交到能够真正展开测试，需要经过五、六轮的反复，那么就应当考虑版本提交质量的问题了。

问题的解决方法，一方面要提高开发人员的送测版本的质量。这个需要和开发人员达成共识，得到开发人员的承诺。（入口条件）

其次需要辅助相应的测试流程，并严格执行。流程是规范彼此的操作，应保证执行的有效性。
1）保证计划的正确制定和执行。如果测试反复超过计划预期，则会减少测试的时间，无法保证测试质量。有效的报告问题测试执行中的问题，不仅仅是系统存在的问题，还包括测试执行中所出现的风险和问题。
2）保证测试的入口和出口的质量。测试入口是要求提交测试系统的质量，出口是保证最终测试交付物的测试质量。高质量的提交测试系统是实现有效测试的重要前提，不是任何一个送交的系统都能够测试的，需要在展开测试前验证送交系统的可测试性（不管你是用送测试单还是彼此之间的约定，可测试性一定是需要验证的，好像有人叫冒烟测试来着）
3）有效测试版本控制。每一轮的测试版本应当是有效而稳定的，有针对性的测试会提高整体的测试质量。提交测试系统的质量不高，要考虑是不是提交系统的单元测试和自测度是否有效的执行了，适时叫停是个不错的选择。
4）不断改进。除了发现系统的BUG，要不断发现测试现有工作方法、流程所存在的问题缺陷，不断的改进，提高整体的测试效率和测试质量（出口质量）

最后需要提高大家的质量意识。质量免费，质量不是某一个人或是某一些人的事，彼此的质量意识和有效协作才是保证最终质量的根本所在。

总之，摆正自己的位置，不焦不躁，始终使自己保持一个良好的工作和精神状态。
一切从自身做起，严格执行自己的工作职责，不断改进自己的工作，用自己专业的工作态度影响周围的同事。

作者: hjjlearning 时间: 2008-8-20 16:50
我的回答，请看，，
我答：怎样有效降低测试的轮次？
http://www.51testing.com/?18049/ ... e_itemid_90664.html

作者: 高跟鞋跳舞 时间: 2008-8-20 17:40
标题: 回复 14# 的帖子
总结的非常好

作者: kelly4911 时间: 2008-8-21 01:42
我是一个即将迈进测试行业的新手，我提出我的想法，如果觉得幼稚千万别见笑啊
我觉得可以在回归测试阶段做一个测试的度量，这样可以知道大概在什么时候能结束回归测试，发布新的版本
比如我们可以通过度量得到一些数据，然后制定一个BUG的跟踪曲线，通过对这条曲线的跟踪来决定是否还要进行新一轮测试
如果这条曲线处于一个收敛的状态，如果达到一个公司的基线的标准则可以考虑结束测试，发布新的版本

作者: zrg9399 时间: 2008-8-21 10:29
还是那几条
1、控制需求变更，这次版本不是必须引入的功能，可以在2期项目中加入
2、控制代码质量，采用冒烟测试，不合格的版本打回
3、提高测试质量，在一个版本里尽量发现尽可能多问题，不能抱有侥幸心理，还有下一个版本呢

[ 本帖最后由 zrg9399 于 2008-8-21 10:31 编辑 ]

作者: 张帆Test 时间: 2008-8-21 10:41
标题: 个人意见
一个项目回归测试多次，公司怕的就是风险；
为了减少风险，他就让测试的进行多次测试；
为了减少测试，也就要从需求开始，每个需求都进行评审，软件开发每个阶段流程都进行评审；预防bug；避免发现bug；

[ 本帖最后由张帆Test 于 2008-8-21 10:43 编辑 ]

作者: zhaoping 时间: 2008-8-21 11:02
不讲许多空话，只谈我的一点体会：
1、测试的粒子大小决定了多轮测试的复杂程度，这一点是不让测试员崩溃的前提，每一个的每一阶段的劳动成果都应该得到尊重。
在每一轮测试中，测试计划，测试方案，测试用例、测试环境和测试脚本可复用性是起重要作用的。
在开发设计过程中现在提倡低藕合性，在测试过程中也要注意这一点。所以测试用例的设计和测试脚本的设计也是要相当的功力的。
在每一轮的测试过程中只要把修改的部分和可能影响的部分重新设计测试用例和测试脚本，没有修改的或者可能没有影响的部分做回归测试。
2、在管理中适当总结每个小版本的修改部分的原因和可能引起的原因进行分析，适当地评估因为不同的版本的测试所需要的工时。每个BUG修改后，修改的开发一定要指明是什么原因造成的，有可能影响的功能点是什么（这一点就关系到BUG的管理规范了）。
3、在实际测试过程中，每一轮的测试不可能是全面的测试，应该具体指出第一轮的测试目标，第二轮的，最后一轮的测试目标。
在以住的项目中，一般是第一轮进行全面的系统的测试，第二版本进行BUG回归测试，第三版本进行重点功能的测试，。。。。。。。。。最后一个版本进行全面的验收。进入全面验收时的目标是发现可能影响发布的BUG。
4、如果是因为需求发生变更，测试人员一定要及时反馈因为变更而造成的影响。不能说不能发生变更，只能说应该尽可能地避免，所以一次需求变更，一定要把负作用让上层听到。

作者: fengbin20 时间: 2008-8-21 11:47
个人认为这种问题产生的原因有
1.需求在随意的更改。
2.冒烟测试没有通过，导致许多问题遗留在后期。
3.测试和开发没有形成一个完整的流程。
4.版本控制出现问题。
5.测试用例出现遗漏。

以上仅仅是我个人的观点，有什么不对的，请大家多多指教。

作者: datarnd 时间: 2008-8-21 11:55
觉得这个问题，理论上可以解决，但在实际操作上难度很大！

作者: whlpzmc 时间: 2008-8-21 12:12
百家争鸣啊！以下个人拙见，如有不对之处请勿进行人身攻击。
我觉得作为一名测试人员，对业务的熟悉和产品的了解要有一定的深度，因为所有的产品不可能100%的测试到，在测试过程中必须做到取重避轻。就像是我们在测试过程中的一些很好的策略。其次，回归测试是不可能避免的，但是测试人员一次一次这样的回归测试，是不是有点像杀虫剂效应，难免会产生麻痹的意识。所以我觉得自动化测试可以更好的为我们服务，把我们有限的精力投入到设计分析中去，执行不过是人员的问题。

作者: zhuzx 时间: 2008-8-21 12:37
标题: 怎样有效降低测试的轮次？
软件测试的轮次多少，大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下，谈谈我们团队的做法，希望同行继续补充指正：

1.让研发团队的领导重视测试：

测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直就是轻而易举的事情。

2.测试团队和开发团队的独立性：

国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个Bug，也就安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。

3.细化送测标准，建立完善的测试规范：

测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试平凡发布版本，不是什么新鲜事。目前，我们公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也能够有效的减少测试的次数。

4.测试部门建立详尽的预测试标准：

如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。

5.保持测试和开发独立的测试环境：

大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，我也去掉了绩效考核中“对无效的Bug”的考核项，大家终于可以放心的提缺陷了。

6.重视单元测试，提高被测软件质量：

很多时候，测试部门和开发部门单元测试比较马虎或应付客户了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现，加之项目进度的压力，给公司也带来了较大的经济负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。

7.重视测试用例的评审，提高测试用例的质量：

就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。

8.部门员工进行模块交叉测试，避免漏测提高测试效率：

测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。

9.加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：

加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗？特别是测试半天都没发现Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。

10.严格控制需求变更的流程，减少后期的需求变动：

在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。

作者: zzhix 时间: 2008-8-21 13:18
标题: 非常赞同25#的说法
zhuzx，好久没有看到你答题目了，您讲的很精彩，很详细！！希望以后多参加51testing的答题活动，让我们学习学习，呵呵！！

作者: qiyan 时间: 2008-8-21 13:36
标题: zhuzx楼主，你太强了，居然心有灵犀呢？
你讲的1、4、6、8、9这几点都非常适用，很有效。我很有同感，你太牛了。我的经验是：一般测试就3轮就OK了。

补充个人的意见：
开发人员开发模块，自测试的仔细程度，很大程度上也影响版本的测试次数。

作者: Celery 时间: 2008-8-21 14:36
1.需求明确。每次需求变更都要落实到书面上，并通知相关人。
2.提高开发人员的质量意识，做好单元测试。
3.测试case详细，全面。
4.对于每次迭代都要重复测试的功能，最好用自动化测试。
5.有一个完整的开发流程和测试流程。并且保证相应软件文件完整。

作者: chuming 时间: 2008-8-21 15:50
标题: 25楼的朋友回答比较详细、经典
很佩服您的回答，概括能力挺强，是一块当领导的料！！！

添加一些我的观点：
个人觉的可以冲配置管理上下功夫，限制版本Release的次数，不知道如何？

作者: cc87311 时间: 2008-8-21 15:53
标题: 我的观点
1。感觉首先是需求方面不要频繁更改
在需求分析的阶段  需求工程师可以控制
最根本问题是客户  无法控制
2。测试阶段测试人员在编写用例的时候合并同类项以及用例之间的合并（例：GUI测试用例和功能测试用例合并）
这个在编写用例的阶段  测试人员可以控制
但对编写用例的测试人员对业务相当熟悉并且有一定的工作经验
3。对任何版本的测试  首先做预测试
测试人员可控制
4。环境的搭建上一定要按照客户的操作环境搭建  有可能的话  测试数据用客户的原始数据
客户的操作环境    测试人员可控制
客户的原始数据    因为面向的用户不一样  所以客户的原始数据未必会给你（例：银行）
不可控制

这些都是本人能想到的因为我还是个新手  所以有些观点很不成熟  希望大家能多多指教。

作者: testxxh 时间: 2008-8-21 22:48
标题: 提点偶的一些看法啊
我觉得如果是作为第三方的测试，要相对好一些，因为测试的对象是确定的了，那这样测试计划、测试执行都相对稳定一些；那这样的情况下，关键是要看测试的入口以及出口标准的制定了。

   对于一个明确的小项目，因为项目的启动、试运行、初验、终验标准都是固定的，这样对于一个项目测试，关键是要看项目的目标，以及开发的整体进度，在开发的过程中注意模块测试已经部分功能、流程的集成测试；这样来说，测试轮次的执行关键是要看整体项目完成后的集成测试效果；一定程度上是要看开发的质量；

   但，对于一个时间沿线较长的项目较大的软件产品来说，测试的轮次有时要根据产品提交的时间来定：一般来说，如果是对于时间比较宽裕的项目，那回归测试应该根据系统的功能做大的划分，对人员做好分工，交叉测试，查漏补缺，这样可以在降低测试轮次的同时，提高测试效率。

   对于，一个系统功能更新较快，而现场需求较急的情况，在这种情况下，根本没有时间做完整的测试，这时，应该根据程序修改的内容（虽然不用做白盒测试，但是在看代码的基础上，可以判断某处修改的影响），对产品的模块做风险性，对高风险的模块，做尽可能全的回归测试，保证系统功能的正确性。

   由于时间的关系，我就先写这么多，期待大家的精彩做答，相互促进喽。

作者: zhangaibing 时间: 2008-8-22 08:45
以上总结很好

作者: jiaozi 时间: 2008-8-22 10:05
大家总结的都很好，我一定要好好学习啊。

作者: uestc 时间: 2008-8-22 10:12
标题: 高瞻远瞩的测试思维，非高手莫及
上轮每周一问中看到了sun_0910经理的精彩回答，今天又看到了zhuzx高瞻远瞩的测试思维方式，真是好极了！！！唯有送3朵鲜花表示敬意！！！

添加一点我的想法，我是新手请勿见笑，还请高手指点：
好像“冒烟测试”和zhuzx中的“预测试”好像是一个吧，只是不同的叫法对吧！！！
麻烦zhuzx高手指点迷津，本人非常感谢！！！

作者: happybbh2008 时间: 2008-8-22 10:33
标题: 降低有效测试的轮次
要降低有效测试的轮次需要多方面进行解决:
1、软件管理：
1）项目管理：在项目管理中要求测试人员尽早从需求阶段介入到项目，保证测试人员对产品有深入的了解
2）配置管理：a.要做到有效的版本管理，避免因版本混乱而导致测试工作的重复；
         b.要做到有效的变更管理，每一次变更要有效控制，并让测试人员也清楚
3）测试管理：测试工作要有计划性，制定比较合理的测试计划
2、人员素质：
公司软件管理方面得到有效保证后，人员的素质就是重要的影响因素：
1）、测试人员：写出覆盖全面的测试用例，做到有的放矢，提高测试质量
2）、开发人员：a.提交测试工件时需要进行自测，提高软件质量b.对软件构架要深入了解，避免修改当前BUG时影响其它功能模块
               或是没有修改彻底，使回归测试的轮次增加。
3、自动化水平的提高：自动化水平也是比较重要的因素，对于回归测试使用自动化工具可以全面将回归涉及到的功能模块全面测试，提高测
                  试效率。

作者: zhuzx 时间: 2008-8-22 12:39
标题: 回复34楼的朋友，不知道是否满意，请版主保留：
首先感谢34楼朋友送的鲜花。
下面是预测试与冒烟测试的资料
1. 什么是软件预测试？

      预测试的概念：当软件产品转入到软件测试部门开始系统测试之前，开展软件预测试，由软件测试人员验证被测试软件的基本功能是否正常，从而保证系统测试不会由于软件基本功能的缺陷而挂起。软件预测试是软件测试可以正常进行的一种保证手段。

2. 软件预测试的必要性，何种软件项目和软件产品需要软件预测试？

      必要性：软件预测试在软件产品开发测试流程中，是必不可少的一个环节，如果，缺少了软件预测试环节很可能导致软件测试被异常挂起。

      软件预测试适用于哪些软件项目：软件企业只要有独立的软件开发部门和软件测试部门，就应该由软件预测试的环节，与软件项目类型没有必然联系。

3. 软件预测试的基本流程，参与预测试的人员角色划分、预测试阶段划分等等

      (1) 由软件测试人员根据配置管理员发布的最新版本报告，到配置管理库上获取被测试版本的代码。

      (2) 软件测试人员在编译环境上编译代码，如果代码编译通过，继续下一步，否则版本被返回，由软件开发人员修改相关问题，重新发布版本。

      (3) 用版本库上提供的被测试软件安装包，在软件测试环境上开始基本功能测试。如果基本功能未通过测试，由开发人员修改相关问题，重新发布版本。

      (4) 软件预测试还需要查验开发软件提供的相关文档，比如开发人员的版本验证报告、用户说明书、操作手册等等。

4.什么是冒烟测试：

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

作者: zynuage 时间: 2008-8-22 13:00
1选取一组测试用例中最有效的
2 利用最少的步骤突显出软件的问题
3减少冗余

作者: uestc 时间: 2008-8-22 14:31
标题: zhuzx非常感谢您无私的帮助，您是当今的活雷锋！！
刚看了的预测试与冒烟测试的相关理论受益匪浅，非常感谢zhuzx热心的教导。

作者: 阿里吧吧 时间: 2008-8-22 15:47
标题: 大道理外的补充
无废话.
1.别想单纯的减少回归测试次数.为了最终质量,公司是不会因为你累不累的就减少次数的.
2.把关注点放在流程上,放在过程控制上,才能在最后少背点锅,少做点重复劳动.
3.自动化工具可以适当引入,我估计Test Manager也很同意这样,大家都喜欢省力,
4.按工业化标准,规格(需求)是严格控制不可随意更改的.若不能规范,...放正心态吧

作者: spair6 时间: 2008-8-23 12:01
<<在日常的测试工作当中，一个版本的发布常需要经过五轮或者六轮的测试，导致测试人员身心疲惫，工作积极性不同程度的下降。
为了改变这种现状，我们在项目管理或执行当中应该注意那些方面呢？期待各位同行的建议。>>

这个也涉及到开发人员的问题，如果开发人员在修复bug时，关联到其他的模块，产生连锁反应，对测试人员来说是毁灭性的打击。所以在做项目需求时就应该把测试和开发人员安排在一起，然后对相关人员进行培训，尽量保持代码规范，和测试用例全覆盖，保证第一轮测试的完全覆盖性。

如果有实力的话，可以考虑使用自动化测试工具，在最后几轮测试的过程中，只做BUG修复验证，其余的回归测试和大范围的快速测试交给机器去做。当然这样会增加很多成本。

还有就是有些开发人员经常修复一两个bug就打个安装包发过来交给测试人员。我觉得这是测试人员最不能接受的。有时一天会发三五个build，这个我觉得是测试人员最不耐烦的。应该注意一下。

作者: tian910 时间: 2008-8-25 13:49
标题: 送给25#的兄弟
刚在51testing上注册。很辛苦的看完了全部的内容，发现您特别的能干，文字功底和总结能力都不错。答题相当经典，没有一问有了您的参与，相信会更加精彩。

本人也很想认识您，和您结交朋友？如果您愿意：
下面是我得MSN: tian910@hotmail.com，加我时请注明，谢谢！！

作者: tian910 时间: 2008-8-25 13:50
标题: 送给25#的“兄弟”或“姐妹”
刚在51testing上注册。很辛苦的看完了全部的内容，发现您特别的能干，文字功底和总结能力都不错。答题相当经典，每周一问有了您的参与，相信会更加精彩。

本人也很想认识您，和您结交朋友？如果您愿意：
下面是我得MSN: tian910@hotmail.com，加我时请注明，谢谢！！

作者: happybbh2008 时间: 2008-8-26 17:17
标题: 回复 1# 的帖子
怎么没有公布获奖名单？

作者: 思渝 时间: 2008-9-11 12:25
标题: 降低测试的好方法原来来源于这里
降低测试的好方法原来来源于这里

作者: w阿思 时间: 2011-12-12 16:30
收获颇丰啊！

作者: 米娣 时间: 2013-9-24 18:28
学习了，这些正式当前需要的，谢谢

作者: Zgi46Z 时间: 2013-11-24 14:24
楼主万岁，万万岁，哈哈哈哈，谢谢了

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