软件开发过程不规范的项目组中，这种情况是非常常见的。2001年，我接触过的一个公司，它刚刚成立
软件测试部，当时的测试部遇到的情况和上面讲的几乎如出一辙，搞得测试员叫苦不迭，开发部的程序员也天天抱怨头疼。
H5K1{(s W'l%a0具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：
C`uYj
[ K}03k#I4\ I
_ ~:K;PA0|0×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
]4e+jp ql!l H0F!Gu,B(i4Z _m-[0×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；51Testing软件测试网9oO;n(W#@Tp!TPL
TQ:E;Z Rw"^po'Z0×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
~N0XFwA8W'}0N"C"KQ'G3e0×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build VerificationTest），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；51Testing软件测试网o3Mt1Ej e+XG
51Testing软件测试网b
L^G
j RO6w? a×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
O Z r r,ToI0k N
P n"A0×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
hRV$O \;J'OH9@ IY00~ m;u2y%H
z1l;F+v1b y0×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。51Testing软件测试网 QF ur }5E"WM
51Testing软件测试网1D)y l!vg'[*z要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。51Testing软件测试网*v C's~0]z3X7d
A%~w*P Z3cr/S6r0=============================================51Testing软件测试网&I
Q D](K6U^7T \
1、通过管理制度约束，要有明确的版本打回的考核制度，把版本打回次数与开发人员的考核指标挂钩，并有一定的惩罚措施，这样才能使开发提高提交版本的质量，从而使提交版本可测试。51Testing软件测试网
_n'D;V.\
6F'wp3n5i02、通过清晰，明确的流程保证，如提交测试的版本要有一定的测试准入条件，没有达到准入条件的一律打回处理，不能浪费更多的时间测试一个不可测试的版本。针对版本所规划的需求未实现这一问题，可以增加需求验证这一环节，这个环节的验证不会要求很细，但是可以规划的需求已全部实现，或实现的功能与需求规划是一致的，这样提交到测试环节的版本，我们就可以按计划开展比较详细的测试。
%f)B:q+K jB!X&q/u
k051Testing软件测试网,n0W^9Qh
3、通过一些方法和策略保证。把测试分级，一个版本的提交，通过几个级别的测试，然后再确定是否全面投入测试，1级的可以定义为运行BVT或一些预测试，例如正确执行安装，运行等测试用例，这些是最基本的用例，通过后再运行2级用例，定义为一些基本功能和主要流程类的用例，运行通过后再按计划展开全面的测试，避免盲目的投入造成测试资源的浪费和做无用功。前2个级别的测试完全可以通过自动化来实现，这样的话可以夜间进行，既提升了效率，也不会对进度有太大影响。51Testing软件测试网 NR%C#r
r @1c
51Testing软件测试网%H)o G2i"g8fu
总之，我认为制度，流程，方法结合，可以把风险和影响降到最低，但最终的根本还在于整个研发团队的质量意识和团队精神，这两方面都比较强的话，再加以健全的流程和制度，包括这个问题的许多问题都可以迎刃而解了。
===============================================
1、制定合理的版本发布计划，并加强版本控制管理；
d1^ s5o|8\6Z ^02、版本发布时有开发负责人编写详细的软件变更说明；
+`H-c O | M$V[03、开发人员应该加强单元测试和冒烟测试；51Testing软件测试网,e4r ABb:{V
4、测试部跟开发部协商拒绝测试的标准；
z"c4oV(`9Hp;^3Qq05、公司高层应该将软件版本发布的质量纳入部门绩效考核
