开发自测被多个团队实践，开发自测的效果也是不一而足的，具体怎么样的开发自测方式是更好的，每个人都有自己的观点和看法，这里说说自己对开发自测的方法的一些探讨。
一、传统研发流程的弊病
在讨论开发自测之前，我们先看看未进行开发自测的研发流程
从这个流程可以看出：
1、开发和测试处于两条线，开发实现功能，测试确保开发实现功能是正常的。
2、对于项目质量的保证工作都在开发编码完成后进行，虽然有时候可能开发完成一部分编码后测试就可以进行测试了。
3、项目质量的保证完全由测试负责，开发只管实现功能
这个流程最容易出现的问题是：
1、测试介入时间较晚，bug修复成本大。
2、开发提测的版本不稳定，Bug多，因为开发不对质量负责，开发自认为实现了功能或者说修改了bug，至于实现或者修复bug是否有影响开发并不关心，导致一个功能或者bug反复修改，反复测试，沟通成本高，容易导致项目延期
3、如果开发延期提交测试，测试时间被压缩， 项目上线质量不高，事实上，在产品过程中这种情况经常出现。
4、测试和开发对立，开发认为测试做的都是低级工作却总是找自己麻烦，而测试觉得开会没有做好产品，代码质量低。
不论从测试效率还是项目质量来说，开发不参与测试对产品/项目来说是没有好处的，于是经历过这些痛苦之后，开始强调开发自测。
二、开发自测的不同需求
通常情况下，我们要求开发自测，开发会同意自测，他们的做法是在提交测试代码之前，本地的程序调通，主线流程可以走通，然后告诉测试说，已经做过测试了，没有任何的测试设计，没有任何的测试结果，这样的开发自测，虽然可以降低一部分显而易见的bug数量，但是对于产品的质量或者风险并没有降低多少。
理想中的开发自测，希望开发对于编写的每个方法都有测试方法，对于每个uc都有正常流程，异常流程的测试，希望开发可以像测试一样去思考，可以像测试一样的耐心细致，发散思维，有明确的测试过程和结果，并且能够对产品的质量负责。可是开发并不这么想，他们认为，系统设计，技术架构，追求高技术的代码才是他们的首要工作，他们实现了产品的需求，他们的工作算是完成了，他们会写点单元测试，或者他们想了解测试是怎么做的， 也会去做一些测试的工作，这些或许只是他们的业余工作或者爱好而已。当测试要求他们写单元测试，接口测试，写测试报告的时候，他们会表现的非常的反感，为了不扩大事态，测试只好对开发自测的结果不做评定，依然还按照既有的方式进行测试。
测试期望的开发自测和开发自认为的自测是完全不同的，也可以说，会有对立的一面，但是我们都知道bug越早发现，解决的成本越低，风险也越小。如果都在测试过程中测试，都有测试去测试，那么测试发现的bug要确认，提到缺陷管理库中，开发看到bug再模拟场景，查看代码，修复，然后再提交测试，验证，通过后再关闭bug，这个过程中的沟通，确认，还有打开一系列系统的时间是非常浪费的，而且开发也不希望自己在专心做事情的时候被打扰。
三、不同类型的开发自测探讨
了解了测试和开发对开发自测不同的需求后，对于测试，还需要了解测试的种类，通俗的来说，测试可以分为单元测试，接口测试，系统测试，单元测试主要是针对单个方法的测试，接口测试更多的是集成测试，而系统测试，则是站在用户使用场景，对整个系统进行测试，而无论是单元测试，接口测试，还是系统测试，都可以进行自动化测试。
针对不同的测试类型，开发自测的方法也是不同的，下面逐一探讨。
一般的研发流程是这样的：
1、需求分析
针对一个需求，开发考虑的是如何实现这个需求，或许这个需求可能不合理，但是，测试首先要考虑的是，这个需求是否符合用户的习惯，然后再考虑如何去测试这个需求，在需求评审阶段，针对某个需求，要进行充分的交流，确保开发和测试对需求的理解是一致的，并且这个需求是有必要实现的，重复的需求讨论对理解整个需求实现的目的，实现的方法都有重要的价值，这也算是一种开发自测。
2、分析设计
分析设计其实就是UC设计及技术方案设计，在这个阶段，测试完全可以参与UC设计，技术方案设计，了解开发的设计思路，根据UC及设计进行测试策略的设计，比如项目需要用到哪些测试类型，不同的测试类型具体怎么做，是否需要针对特定的测试类型进行测试框架的开发，有哪些测试场景，这些测试场景的测试是否需要特定的测试数据。当测试参与分析设计并且将针对这个需求的测试思路和开发进行沟通，那么开发不但对如何实现需求有了清晰的思路，对如何测试需求也有了清晰的思路，这样开发在实现需求的时候，就会考虑会有哪些业务场景，会有哪些异常情况，会有哪些测试点，谈不上是测试驱动开发，但是对于业务场景的全面性，对于程序代码的可测性都是非常好的帮助，而且对于后面具体测试类型的开发自测展开也是非常有好处的。
3、单元测试
技术方案确定后，开发完全进入了编码阶段，这个时候，开发最烦思路被打断，但是，我们通常都会要求开发写单元测试，理由是，首先，一个方法有测试代码证明这个方法是按照预期方式进行的，其次也需要确保这个方法被其他方法调用时能够正常调用，开发会认同单元测试由开发编写，也会对对一些的简单方法，写一个正常流程的测试方法，但是往往开发写了测试代码，准备了测试数据，只保证在测这个方法的时候，测试代码是可运行的，而一旦测试数据被改动了，或者程序有改动，测试方法便无法执行了，而对于那些需要依赖外部环境或者第三方接口的方法，开发几乎是不会去写测试代码的，这样，开发虽然写了单元测试代码，但是单元测试代码是不可用的，对开发来说是浪费时间，对测试来说，让开发做单元测试，结果却没有效果。
单元测试是最基本的，也是最容易执行的，更是成本最低的一种测试方法，让开发做好单元测试，可以说是有了开发自测。开发不讨厌写代码，而且还擅长写代码，但是开发厌恶搭建测试环境准备测试数据，而这恰恰是测试擅长的，那么，可以考虑针对单元测试可以为开发做些什么。就单元测试来说，除了xunit，Mock是最好的单元测试工具，让开发掌握了mock技术，然后让开发了解单元测试思路，开发会爱上单元测试的，开发也希望自己写的代码有测试代码保证。关于单元测试，衡量的最常用的标准就是持续集成和代码覆盖率，让开发写单元测试代码，还要让开发能够对单元测试有成就感，当开发的单元测试代码每天都被构建并且将测试结果发送给开发，当有代码变动引起了单元测试构建，构建结果发现了bug，开发会认识到单元测试的价值，会热衷于进行单元测试，如果开发写的代码覆盖率很高，对开发来说，也是一种成就感。
4、代码review
开发完成了单元测试，组织开发进行代码review也是非常有必要的，代码review不完全是为了找出代码中的错误，更重要的是可以让有经验的开发对代码的设计进行审查，降低代码的复杂度，耦合性，减少重复无用的代码，能够使得代码更好的和其他系统进集成，同时，测试参与代码review，可以对代码的可测性提出建议。
代码review看起来很美好，但是执行起来却绝非易事，因为开发实现了某个功能，review的时候却发现这种实现方式不是很美好，开发会觉得反正功能是可用的，等后面有时间再进行修改，这样的理由也无可厚非，但是，现在的修改可能只是一两个小时，后面的修改却是一两个日常，让开发或者开发TL意识到这种时间的差别，可能对代码review的接受程度会更高。
5、集成测试
我们做的接口测试，无论是service的接口测试还是web层的接口测试其实就是集成测试，因为都需要依赖一定的外部环境，比如数据库，比如其他系统提供的接口，接口测试一般是在开发编码完成以后进行，要进行开发自测，接口测试可以提前进行，在开发进行设计的时候，产品/项目需要几个接口，这些接口需要哪些参数，实现什么功能其实已经是确定好了的，那么根据接口的定义，测试可以提前进行接口测试的准备，比如接口测试用例的设计，测试环境搭建，测试数据准备，根据这些内容看是否需要为产品，项目的接口测试开发新的接口测试的框架，这些都可以在开发进行编码的时候完成。
开发编码完成后，或者开发一两个接口提测后，测试可以先行进行接口测试，理顺测试环境，等开发编码都完成后，集中开发/测试的力量，一鼓作气将接口测试完成，编码对开发来说不是什么难事，如果开发准备好了测试环境，有测试用例，有测试框架，开发完成接口测试的速度还是相当快的。
这里需要说明的是，开发可能会觉得单元测试做了，怎么还要做接口测试，单元测试和接口测试关注的重点不一样，所以并没有重复之说，而且，单元测试和接口测试是最底层，成本最低，且最容易自动化的测试手段，而且也是以开发最擅长的编码方式进行。
开发写接口测试，并不是说接口测试的工作也完全由开发来做，接口测试应该是开发和测试共同配合来完成，分别发挥各自的优势又能分别学习各自的优势。通过接口测试，开发可以学习测试思维，测试技巧，而开发也可以从开发那边学习到开发技巧，更重要的是，做好了接口测试，在后续系统测试阶段，就算是发现了bug，修改了代码，通过跑单元测试和接口测试代码，完全可以第一时间回归到改动是否影响了其他代码，而不用非要等功能测试的时候才能验证。
6、页面自动化
进入系统测试阶段，开发的主要工作变成了修改bug，工作变得相对轻松了，而传统意义上的测试工作真正开始了，测试的工作开始繁重，如果前期的单元测试，接口测试做的出色的话，这个阶段发现的bug可能更多的集中于前端bug或者就是需求变更，前端bug的预防减少，涉及到前端测试的内容，暂时不进行讨论，真正功能性的bug是相对较少的，这个时候开发可以做什么，可以做页面自动化的脚本编写。编码是开发擅长的，只要开发掌握了自动化测试框架，知道哪些用例需要写自动化脚本，开发写自动化脚本是非常快速的。至于开发自动化框架的培训可以在项目需求阶段进行，自动化测试用例的抽取可以在测试设计阶段完成。
这样，在项目测试阶段，单元测试，接口测试在持续的进行，可以快速发现，定位代码变化引起的问题，降低沟通成本，增加开发空余时间用来写自动化脚本，等项目测试完成后，页面自动化脚本又可以基本完成，立体的一套自动化测试体系初步构建完成，在这个过程中，开发和测试密切配合降低了无谓的沟通成本，提高了产出效率，增强了项目的质量。
7、项目维护
产品发布了，并不意味着产品的结束，各种新的需求都会以日常的形式来进行，日常有大有小，而针对日常的测试也应该视日常大小而进行，一些小的，简单的日常完全可以由开发自己开发并测试完成，通过前面在项目中的自测过程，开发对测试流程非常的属性了，小日常完全可以应付，并且当开发认为没有测试去测试的时候，自测会更加认证，而对于一些大日常的测试，则可以参考前面整个的流程进行开发自测的展开。其实，在项目维护阶段，针对不同的子应用或者模块，可以形成模块开发负责制，每个模块，应用都有一个开发进行负责，负责人对自己负责模块的需求，开发，质量保证都需要了解，这样可以增加开发的质量意识，降低变化引起的风险。
开发自测看起来很美好，但是实施起来却存在，首先，开发会排斥进行测试，其次，开发做测试会比较随意喜欢一次性的测试，第三，开发会认为自己的测试不专业，还需要测试进行测试浪费资源。因为这些原因，开发自测不是一蹴而就的，需要不断的推进，为开发自测提供基础支持，让开发养成自测的习惯，并且意识到自测对于保证项目质量，提高效率的重要性，只有开发从心底愿意进行自测，开发测试才算是真正运行有效的。
开发自测的目的并不是增加开发的工作量，降低测试的工作量，而是要弱化开发/测试的角色，降低开发/测试的对立，通过开发和测试的共同努力，扬长避短，形成一套立体的质量保证体系。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
