怎样有效降低测试的轮次？（08-08-18）（获奖名单已公布）

fishy

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

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

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

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

Zgi46Z

楼主万岁，万万岁，哈哈哈哈，谢谢了

米娣

学习了，这些正式当前需要的，谢谢

w阿思

收获颇丰啊！

思渝

降低测试的好方法原来来源于这里

happybbh2008

怎么没有公布获奖名单？

tian910

刚在51testing上注册。很辛苦的看完了全部的内容，发现您特别的能干，文字功底和总结能力都不错。答题相当经典，每周一问有了您的参与，相信会更加精彩。

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

tian910

刚在51testing上注册。很辛苦的看完了全部的内容，发现您特别的能干，文字功底和总结能力都不错。答题相当经典，没有一问有了您的参与，相信会更加精彩。

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

spair6

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


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

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

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

阿里吧吧

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

uestc

刚看了的预测试与冒烟测试的相关理论受益匪浅，非常感谢zhuzx热心的教导。

zynuage

1选取一组测试用例中最有效的
2 利用最少的步骤突显出软件的问题
3减少冗余

zhuzx

首先感谢34楼朋友送的鲜花。
下面是预测试与冒烟测试的资料
1. 什么是软件预测试？

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

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

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

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

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

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

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

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

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

4.什么是冒烟测试：

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

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

happybbh2008

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

uestc

上轮每周一问中看到了sun_0910经理的精彩回答，今天又看到了zhuzx高瞻远瞩的测试思维方式，真是好极了！！！唯有送3朵鲜花表示敬意！！！

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

jiaozi

大家总结的都很好，我一定要好好学习啊。

zhangaibing

以上总结很好

testxxh

我觉得如果是作为第三方的测试，要相对好一些，因为测试的对象是确定的了，那这样测试计划、测试执行都相对稳定一些；那这样的情况下，关键是要看测试的入口以及出口标准的制定了。

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

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


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

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

cc87311

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

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

chuming

很佩服您的回答，概括能力挺强，是一块当领导的料！！！

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