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. 项目维护

　　产品发布了，并不意味着产品的结束，各种新的需求都会以日常的形式来进行，日常有大有小，而针对日常的测试也应该视日常大小而进行，一些小的，简单的日常完全可以由开发自己开发并测试完成，通过前面在项目中的自测过程，开发对测试流程非常的属性了，小日常完全可以应付，并且当开发认为没有测试去测试的时候，自测会更加认证，而对于一些大日常的测试，则可以参考前面整个的流程进行开发自测的展开。其实，在项目维护阶段，针对不同的子应用或者模块，可以形成模块开发负责制，每个模块，应用都有一个开发进行负责，负责人对自己负责模块的需求，开发，质量保证都需要了解，这样可以增加开发的质量意识，降低变化引起的风险。

　　开发自测看起来很美好，但是实施起来却存在，首先，开发会排斥进行测试，其次，开发做测试会比较随意喜欢一次性的测试，第三，开发会认为自己的测试不专业，还需要测试进行测试浪费资源。因为这些原因，开发自测不是一蹴而的，需要不断的推进，为开发自测提供基础支持，让开发养成自测的习惯，并且意识到自测对于保证项目质量，提高效率的重要性，只有开发从心底愿意进行自测，开发测试才算是真正运行有效的。

　　开发自测的目的并不是增加开发的工作量，降低测试的工作量，而是要弱化开发/测试的角色，降低开发/测试的对立，通过开发和测试的共同努力，扬长避短，形成一套立体的质量保证体系。