程序员应该如何测试自己的程序代码(2)

　　单元测试是最基本的，也是最容易执行的，更是成本最低的一种测试方法，让开发做好单元测试，可以说是有了开发自测。开发不讨厌写代码，而且还擅长写代码，但是开发厌恶搭建测试环境准备测试数据，而这恰恰是测试擅长的，那么，可以考虑针对单元测试可以为开发做些什么。就单元测试来说，除了xunit，Mock是最好的单元测试工具，让开发掌握了mock技术，然后让开发了解单元测试思路，开发会爱上单元测试的，开发也希望自己写的代码有测试代码保证。关于单元测试，衡量的最常用的标准就是持续集成和代码覆盖率，让开发写单元测试代码，还要让开发能够对单元测试有成就感，当开发的单元测试代码每天都被构建并且将测试结果发送给开发，当有代码变动引起了单元测试构建，构建结果发现了bug，开发会认识到单元测试的价值，会热衷于进行单元测试，如果开发写的代码覆盖率很高，对开发来说，也是一种成就感。

　　4. 代码review

　　开发完成了单元测试，组织开发进行代码review也是非常有必要的，代码review不完全是为了找出代码中的错误，更重要的是可以让有经验的开发对代码的设计进行审查，降低代码的复杂度，耦合性，减少重复无用的代码，能够使得代码更好的和其他系统进集成，同时，测试参与代码review，可以对代码的可测性提出建议。

　　代码review看起来很美好，但是执行起来却绝非易事，因为开发实现了某个功能，review的时候却发现这种实现方式不是很美好，开发会觉得反正功能是可用的，等后面有时间再进行修改，这样的理由也无可厚非，但是，现在的修改可能只是一两个小时，后面的修改却是一两个日常，让开发或者开发TL意识到这种时间的差别，可能对代码review的接受程度会更高

　　5. 集成测试

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

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

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

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

　　6. 页面自动化

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

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

　　7. 项目维护

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

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

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

原文转自：http://www.ltesting.net