开发、技术、测试三方周期方法寻求

like405

现在我在测试方面碰到这样的情况
     正常流程是： 测试在测试过程中一发现BUG就反馈给技术人员，技术人员就反馈开发人员。开发修改好BUG后，测试在从头测试如果发现BUG又前面的流程处理。测试就是一发现BUG就反馈并修改后再从头测试
     现在问题是：
    1. 开发人员觉得一发现BUG就修改，这样会打断他们手头的工作，他们的意见是全部测试完毕后再一起修改，测试再重新测试一遍。如果再发现BUG，再一起修改。
     2.如果按开发人员这样处理，这样测试周期就比较长，这样技术人员接受不了，因为有些定制商务已跟客户确认了交期不能推迟，推迟交期对效益有影响。

   现在我是想问问各位前辈，有什么好的中间方法能解决上面的问题，在不改变周期的情况下，出一个比较合理的方案

   这个问题主要是大定制才会出现，比如：机器定制10以上的定制功能，如果全部测试完的话周期比较长，如果按测试现在的方法是发现问题就反馈修改后再从头测试。（这样如果在测试第三个功能时发现BUG，修改后直接从头开始测试，这样相当于后面7个功能未测试，这样周期上会短一点，但是开发人员就要一个一个的修改。）

   目前主要是固件测试+demo测试，因为客户在机器上定制了功能。所要测试后才能生产。

crarook

针对你的描述，发表下个人看法：

1. BUG修复优先级：让开发根据BUG的优先级修复。比如：影响测试整体进度的，必须马上修改；文字描述错误或者不影响整体测试进度的，可以推迟修复。
2. 回归测试策略改变（采用部分回归测试，最终可以做一轮全用例测试）：可以让开发做影响分析，分析BUG影响的功能，只测试变更影响的功能；
3. 项目验收时间：制定整体项目组的流程规范，需要测试、技术、开发之间默契配合，提前制定责任规则；比如：约定开发多长时间修复对应优先级的BUG；谁延误谁负责；
4. 其他：BUG管理上面流程简化、沟通加强（尽量当面或者电话沟通）；了解技术和开发的工作，尽量做到灰盒测试（帮助技术和开发快速定位问题，减少定位时间）；

另外，不清楚你们功能与功能之间的耦合性高不，如果不高的话，第三个功能出错了，就继续往后面测试；修复完第三个功能的BUG后，开发做影响分析，确定影响范围，回归测试就ok；全部测试完成后，可以最后来一轮全用例的回归；如果耦合性确实很高，那没办法了，就只能全部从头开始测试（理论上不可能，如果真是这样，那就是开发的设计模式有问题，直接让他们重新设计。。。哈哈）；