java研发自测报告_开发自测方法探讨

开发自测被多个团队实践，开发自测的效果也是不一而足的，具体怎么样的开发自测方式是更好的，每个人都有自己的观点和看法，这里说说自己对开发自测的方法的一些探讨。

一、传统研发流程的弊病

在讨论开发自测之前，我们先看看未进行开发自测的研发流程

从这个流程可以看出：

1、开发和测试处于两条线，开发实现功能，测试确保开发实现功能是正常的。

2、对于项目质量的保证工作都在开发编码完成后进行，虽然有时候可能开发完成一部分编码后测试就可以进行测试了。

3、项目质量的保证完全由测试负责，开发只管实现功能

这个流程最容易出现的问题是：

1、测试介入时间较晚，bug修复成本大。

2、开发提测的版本不稳定，Bug多，因为开发不对质量负责，开发自认为实现了功能或者说修改了bug，至于实现或者修复bug是否有影响开发并不关心，导致一个功能或者bug反复修改，反复测试，沟通成本高，容易导致项目延期

3、如果开发延期提交测试，测试时间被压缩， 项目上线质量不高，事实上，在产品过程中这种情况经常出现。

4、测试和开发对立，开发认为测试做的都是低级工作却总是找自己麻烦，而测试觉得开会没有做好产品，代码质量低。

不论从测试效率还是项目质量来说，开发不参与测试对产品/项目来说是没有好处的，于是经历过这些痛苦之后，开始强调开发自测。

二、开发自测的不同需求

通常情况下，我们要求开发自测，开发会同意自测，他们的做法是在提交测试代码之前，本地的程序调通，主线流程可以走通，然后告诉测试说，已经做过测试了，没有任何的测试设计，没有任何的测试结果，这样的开发自测，虽然可以降低一部分显而易见的bug数量，但是对于产品的质量或者风险并没有降低多少。

理想中的开发自测，希望开发对于编写的每个方法都有测试方法，对于每个uc都有正常流程，异常流程的测试，希望开发可以像测试一样去思考，可以像测试一样的耐心细致，发散思维，有明确的测试过程和结果，并且能够对产品的质量负责。可是开发并不这么想，他们认为，系统设计，技术架构，追求高技术的代码才是他们的首要工作，他们实现了产品的需求，他们的工作算是