5、集成测试

　　我们做的接口测试，无论是service的接口测试还是web层的接口测试其实就是集成测试，因为都需要依赖一定的外部环境，比如数据库，比如其他系统提供的接口，接口测试一般是在开发编码完成以后进行，要进行开发自测，接口测试可以提前进行，在开发进行设计的时候，产品/项目需要几个接口，这些接口需要哪些参数，实现什么功能其实已经是确定好了的，那么根据接口的定义，测试可以提前进行接口测试的准备，比如接口测试用例的设计，测试环境搭建，测试数据准备，根据这些内容看是否需要为产品，项目的接口测试开发新的接口测试的框架，这些都可以在开发进行编码的时候完成。

　　开发编码完成后，或者开发一两个接口提测后，测试可以先行进行接口测试，理顺测试环境，等开发编码都完成后，集中开发/测试的力量，一鼓作气将接口测试完成，编码对开发来说不是什么难事，如果开发准备好了测试环境，有测试用例，有测试框架，开发完成接口测试的速度还是相当快的。

　　这里需要说明的是，开发可能会觉得单元测试做了，怎么还要做接口测试，单元测试和接口测试关注的重点不一样，所以并没有重复之说，而且，单元测试和接口测试是最底层，成本最低，且最容易自动化的测试手段，而且也是以开发最擅长的编码方式进行。

　　开发写接口测试，并不是说接口测试的工作也完全由开发来做，接口测试应该是开发和测试共同配合来完成，分别发挥各自的优势又能分别学习各自的优势。通过接口测试，开发可以学习测试思维，测试技巧，而开发也可以从开发那边学习到开发技巧，更重要的是，做好了接口测试，在后续系统测试阶段，就算是发现了bug，修改了代码，通过跑单元测试和接口测试代码，完全可以第一时间回归到改动是否影响了其他代码，而不用非要等功能测试的时候才能验证。

　　6、页面自动化

　　进入系统测试阶段，开发的主要工作变成了修改bug，工作变得相对轻松了，而传统意义上的测试工作真正开始了，测试的工作开始繁重，如果前期的单元测试，接口测试做的出色的话，这个阶段发现的bug可能更多的集中于前端bug或者就是需求变更，前端bug的预防减少，涉及到前端测试的内容，暂时不进行讨论，真正功能性的bug是相对较少的，这个时候开发可以做什么，可以做页面自动化的脚本编写。编码是开发擅长的，只要开发掌握了自动化测试框架，知道哪些用例需要写自动化脚本，开发写自动化脚本是非常快速的。至于开发自动化框架的培训可以在项目需求阶段进行，自动化测试用例的抽取可以在测试设计阶段完成。

　　这样，在项目测试阶段，单元测试，接口测试在持续的进行，可以快速发现，定位代码变化引起的问题，降低沟通成本，增加开发空余时间用来写自动化脚本，等项目测试完成后，页面自动化脚本又可以基本完成，立体的一套自动化测试体系初步构建完成，在这个过程中，开发和测试密切配合降低了无谓的沟通成本，提高了产出效率，增强了项目的质量。

　　7、项目维护

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

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

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