测试过程中如何应对频繁的版本变更？（转载）

    主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：

×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；

 51Testing软件测试网f#\5p?7B+A2S+i"de

×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；

 51Testing软件测试网Re'ih4Xt
j!y0@E

×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；51Testing软件测试网k$F"W*G]2F
\O

 51Testing软件测试网/]|x^c \(vc

×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build VerificationTest），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；51Testing软件测试网 O*w } CU`"h L#o

×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；

 51Testing软件测试网 MId!aZ

×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。

×公司高层应该将软件版本发布的质量纳入部门绩效考核。

 51Testing软件测试网2{S+o9ch

×测试人员的基本素质和测试态度起码不够坚强，研发人员没有站在测试人员的角度去考虑，要让他们时刻意识到“边测边改、边改边测”的办法是行不通的，测试人员更要杜绝“边测边改、边改边测”的不规范现象；51Testing软件测试网`Q6{mF1b

 51Testing软件测试网3eyZ D![?K1T

×当测试人员在测试中发现问题，在向研发人员确认此问题时没有提醒研发人员“不要修改版本”或“不要动服务器”之类的话，要时刻提醒他们，久而久之他们也会养成一个不在测试完毕不向更新程序的习惯。

 51Testing软件测试网D PkJ{3m

×开发经理分配设计任务的时候，未进行设计优先级的划分，结果最基本和最重要的功能最后才设计出来。51Testing软件测试网(o?kBFS;M

 51Testing软件测试网/efy _b@

×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。

 51Testing软件测试网-jE vNj G+K?{r

   要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。