[开发自测方法探讨.docxVIP

开发自测方法探讨开发自测被多个团队实践，开发自测的效果也是不一而足的，具体怎么样的开发自测方式是更好的，每个人都有自己的观点和看法，这里说说自己对开发自测的方法的一些探讨。一、传统研发流程的弊病在讨论开发自测之前，我们先看看未进行开发自测的研发流程。从这个流程可以看出：1.开发和测试处于两条线，开发实现功能，测试确保开发实现功能是正常的。2.对于项目质量的保证工作都在开发编码完成后进行，虽然有时候可能开发完成一部分编码后测试就可以进行测试了。3.项目质量的保证完全由测试负责，开发只管实现功能。这个流程最容易出现的问题是：1.测试介入时间较晚，bug修复成本大。2.开发提测的版本不稳定，Bug多，因为开发不对质量负责，开发自认为实现了功能或者说修改了bug，至于实现或者修复bug是否有影响开发并不关心，导致一个功能或者bug反复修改，反复测试，沟通成本高，容易导致项目延期。3.如果开发延期提交测试，测试时间被压缩，项目上线质量不高，事实上，在产品过程中这种情况经常出现。4.测试和开发对立，开发认为测试做的都是低级工作却总是找自己麻烦，而测试觉得开发没有做好产品，代码质量低。不论从测试效率还是项目质量来说，开发不参与测试，对产品/项目来说是没有好处的，于是经历过这些痛苦之后，开始强调开发自测。二、开发自测的不同需求通常情况下，我们要求开发自测，开发会同意自测，他们的做法是在提交测试代码之前，本地的程序调通，主线流程可以走通，然后告诉测试说，已经做过测试了，没有任何的测试设计，没有任何的测试结果，这样的开发自测，虽然可以降低一部分显而易见的bug数量，但是对于产品的质量或者风险并没有降低多少。理想中的开发自测，希望开发对于编写的每个方法都有测试方法，对于每个uc都有正常流程，异常流程的测试，希望开发可以像测试一样去思考，可以像测试一样的耐心细致，发散思维，有明确的测试过程和结果，并且能够对产品的质量负责。可是开发并不这么想，他们认为，系统设计，技术架构，追求高技术的代码才是他们的首要工作，他们实现了产品的需求，他们的工作算是完成了，他们会写点单元测试，或者他们想了解测试是怎么做的，也会去做一些测试的工作，这些或许只是他们的业余工作或者爱好而已。当测试要求他们写单元测试，接口测试，写测试报告的时候，他们会表现得非常的反感，为了不扩大事态，测试只好对开发自测的结果不做评定，依然还按照既有的方式进行测试。测试期望的开发自测和开发自认为的自测是完全不同的，也可以说，会有对立的一面，但是我们都知道bug越早发现，解决的成本越低，风险也越小。如果都在测试过程中测试，都由测试去测试，那么测试发现的bug要确认，提到缺陷管理库中，开发看到bug再模拟场景，查看代码，修复，然后再提交测试，验证，通过后再关闭bug，这个过程中的沟通，确认，还有打开一系列系统的时间是非常浪费的，而且开发也不希望自己在专心做事情的时候被打扰。三、不同类型的开发自测探讨了解了测试和开发对开发自测不同的需求后，对于测试，还需要了解测试的种类，通俗的来说，测试可以分为单元测试，接口测试，系统测试，单元测试主要是针对单个方法的测试，接口测试更多的是集成测试，而系统测试，则是站在用户使用场景，对整个系统进行测试，而无论是单元测试，接口测试，还是系统测试，都可以进行自动化测试。针对不同的测试类型，开发自测的方法也是不同的，下面逐一探讨。一般的研发流程是这样的1. 需求分析针对一个需求，开发考虑的是如何实现这个需求，或许这个需求可能不合理，但是，测试首先要考虑的是，这个需求是否符合用户的习惯，然后再考虑如何去测试这个需求，在需求评审阶段，针对某个需求，要进行充分的交流，确保开发和测试对需求的理解是一致的，并且这个需求是有必要实现的，重复的需求讨论对理解整个需求实现的目的，实现的方法都有重要的价值，这也算是一种开发自测。2.分析设计分析设计其实就是UC设计及技术方案设计，在这个阶段，测试完全可以参与UC设计，技术方案设计，了解开发的设计思路，根据UC及设计进行测试策略的设计，比如项目需要用到哪些测试类型，不同的测试类型具体怎么做，是否需要针对特定的测试类型进行测试框架的开发，有哪些测试场景，这些测试场景的测试是否需要特定的测试数据。当测试参与分析设计并且将针对这个需求的测试思路和开发进行沟通，那么开发不但对如何实现需求有了清晰的思路，对如何测试需求也有了清晰的思路，这样开发在实现需求的时候，就会考虑会有哪些业务场景，会有哪些异常情况，会有哪些测试点，谈不上是测试驱动开发，但是对于业务场景的全面性，对于程序代码的可测性都是非常好的帮助，而且对于后面具体测试类型的开发自测展开也是非常有好处的。3. 单元测试技术方案确定后，开发完全进入了编码阶段，这个时候，开发最烦思路被打断，但是，我们通常都