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

　　一、传统研发流程的弊病

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

　　从这个流程可以看出

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

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

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

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

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

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

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

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

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

　　二、开发自测的不同需求

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

　　理想中的开发自测，希望开发对于编写的每个方法都有测试方法，对于每个uc都有正常流程，异常流程的测试，希望开发可以像测试一样去思考，可以像测试一样的耐心细致，发散思维，有明确的测试过程和结果，并且能够对产品的质量负责。可是开发并不这么想，他们认为，系统设计，技术架构，追求高技术的代码才是他们的首要工作，他们实现了产品的需求，他们的工作算是完成了，他们会写点单元测试，或者他们想了解测试是怎么做的， 也会去做一些测试的工作，这些或许只是他们的业余工作或者爱好而已。当测试要求他们写单元测试，接口测试，写测试报告的时候，他们会表现的非常的反感，为了不扩大事态，测试只好对开发自测的结果不做评定，依然还按照既有的方式进行测试。

　　测试期望的开发自测和开发自认为的自测是完全不同的，也可以说，会有对立的一面，但是我们都知道bug越早发现，解决的成本越低，风险也越小。如果都在测试过程中测试，都有测试去测试，那么测试发现的bug要确认，提到缺陷管理库中，开发看到bug再模拟场景，查看代码，修复，然后再提交测试，验证，通过后再关闭bug，这个过程中的沟通，确认，还有打开一系列系统的时间是非常浪费的，而且开发也不希望自己在专心做事情的时候被打扰。

　　三、不同类型的开发自测探讨

　　了解了测试和开发对开发自测不同的需求后，对于测试，还需要了解测试的种类，通俗的来说，测试可以分为单元测试，接口测试，系统测试，单元测试主要是针对单个方法的测试，接口测试更多的是集成测试，而系统测试，则是站在用户使用场景，对整个系统进行测试，而无论是单元测试，接口测试，还是系统测试，都可以进行自动化测试。

　　针对不同的测试类型，开发自测的方法也是不同的，下面逐一探讨。

　　一般的研发流程是这样的

　　1. 需求分析

　　针对一个需求，开发考虑的是如何实现这个需求，或许这个需求可能不合理，但是，测试首先要考虑的是，这个需求是否符合用户的习惯，然后再考虑如何去测试这个需求，在需求评审阶段，针对某个需求，要进行充分的交流，确保开发和测试对需求的理解是一致的，并且这个需求是有必要实现的，重复的需求讨论对理解整个需求实现的目的，实现的方法都有重要的价值，这也算是一种开发自测。