测试过程中如何应对频繁的版本变更?(最佳答案 转)

1、通过管理制度约束，要有明确的版本打回的考核制度，把版本打回次数与开发人员的考核指标挂钩，并有一定的惩罚措施，这样才能使开发提高提交版本的质量，从而使提交版本可测试。

2、通过清晰，明确的流程保证，如提交测试的版本要有一定的测试准入条件，没有达到准入条件的一律打回处理，不能浪费更多的时间测试一个不可测试的版本。针对版本所规划的需求未实现这一问题，可以增加需求验证这一环节，这个环节的验证不会要求很细，但是可以规划的需求已全部实现，或实现的功能与需求规划是一致的，这样提交到测试环节的版本，我们就可以按计划开展比较详细的测试。

3、通过一些方法和策略保证。把测试分级，一个版本的提交，通过几个级别的测试，然后再确定是否全面投入测试，1级的可以定义为运行BVT或一些预测试，例如正确执行安装，运行等测试用例，这些是最基本的用例，通过后再运行2级用例，定义为一些基本功能和主要流程类的用例，运行通过后再按计划展开全面的测试，避免盲目的投入造成测试资源的浪费和做无用功。前2个级别的测试完全可以通过自动化来实现，这样的话可以夜间进行，既提升了效率，也不会对进度有太大影响。

总之，我认为制度，流程，方法结合，可以把风险和影响降到最低，但最终的根本还在于整个研发团队的质量意识和团队精神，这两方面都比较强的话，再加以健全的流程和制度，包括这个问题的许多问题都可以迎刃而解了。

1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件版本发布的质量纳入部门绩效考核；

1.公司领导们（特别是研发部领导）对软件测试不注重或者注重的程度不高；
2.测试部内部没有对此问题向公司提出自己的见解和解决的办法，没有和研发部达成一定的共识（多交流才是解决问题的办法），测试部要有公司领导做后盾，由研发部领导在场，制定硬性措施，强制研发人员配合测试部的工作；
3.在产品初期，研发人员对产品没有做冒烟测试而直接提交给测试人员进行测试，这样测试人员虽然能发现大量的BUG，但是研发也会提交更多的测试版本，他们修改后甚至没有做过测试而直接提交给测试人员测试；
4.测试人员的基本素质和测试态度起码不够坚强，研发人员没有站在测试人员的角度去考虑，要让他们时刻意识到“边测边改、边改边测”的办法是行不通的，测试人员更要杜绝“边测边改、边改边测”的不规范现象；
5.当测试人员在测试中发现问题，在向研发人员确认此问题时没有提醒研发人员“不要修改版本”或“不要动服务器”之类的话，要时刻提醒他们，久而久之他们也会养成一个不在测试完毕不向更新程序的习惯；