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

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

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

　　一般的研发流程是这样的：

　　1、需求分析

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

　　2、分析设计

　　分析设计其实就是UC设计及技术方案设计，在这个阶段，测试完全可以参与UC设计，技术方案设计，了解开发的设计思路，根据UC及设计进行测试策略的设计，比如项目需要用到哪些测试类型，不同的测试类型具体怎么做，是否需要针对特定的测试类型进行测试框架的开发，有哪些测试场景，这些测试场景的测试是否需要特定的测试数据。当测试参与分析设计并且将针对这个需求的测试思路和开发进行沟通，那么开发不但对如何实现需求有了清晰的思路，对如何测试需求也有了清晰的思路，这样开发在实现需求的时候，就会考虑会有哪些业务场景，会有哪些异常情况，会有哪些测试点，谈不上是测试驱动开发，但是对于业务场景的全面性，对于程序代码的可测性都是非常好的帮助，而且对于后面具体测试类型的开发自测展开也是非常有好处的。

　　3、单元测试

　　技术方案确定后，开发完全进入了编码阶段，这个时候，开发最烦思路被打断，但是，我们通常都会要求开发写单元测试，理由是，首先，一个方法有测试代码证明这个方法是按照预期方式进行的，其次也需要确保这个方法被其他方法调用时能够正常调用，开发会认同单元测试由开发编写，也会对对一些的简单方法，写一个正常流程的测试方法，但是往往开发写了测试代码，准备了测试数据，只保证在测这个方法的时候，测试代码是可运行的，而一旦测试数据被改动了，或者程序有改动，测试方法便无法执行了，而对于那些需要依赖外部环境或者第三方接口的方法，开发几乎是不会去写测试代码的，这样，开发虽然写了单元测试代码，但是单元测试代码是不可用的，对开发来说是浪费时间，对测试来说，让开发做单元测试，结果却没有效果。

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

　　4、代码review

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

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