一、目前开发工作现状：

　　1、开发拿到模块后做配置、写基类、写业务实现方法、添加/修改表字段，其中做的新配置其他开发可共享，写的基类如果测试通过，其他开发可添加自己的业务逻辑方法、可继承写新类。做配置、写基类、添加类是公共开发任务，这占其中一半的开发时间，业务逻辑方法实现只占每个开发任务的一半时间。所以基础工作交互多，可参考**编写的编辑器、附件等。***的新配置。

　　2、为了代码健壮、可维护性更强，开发过程中不断优化、重构类和方法。把这种类和方法推广到项目组，为项目后期维护、后期扩展绞尽脑汁写了可行的方法，详情可参考**写的增删改查基类等。

　　3、开发收到bug修复请求后，除了修改bug还会对周边业务做修改、优化，同时会修改大量其他人的代码以修改潜藏bug。

　　二、如果用bug考核开发后可能的几种情况：

　　1、测试人员现阶段可以实现业务逻辑测试、可用性测试等，测试过程中，发现的问题只是表面功能错误，大多bug并不确定是业务逻辑错误、或者调用基类错误还是配置错误，导致bug归属问题不清楚，如果测试要细分要做大量工作：包括与开发沟通、与需求沟通，并做大量的验证工作准确定位是那部分问题，这样测试工作无形中增加了，开发修复bug时间无形中增加了，进度被延误了。

　　2、开发为了减少bug，只写简单的代码实现功能，至于高可靠性的代码理念会被搁置一边。

　　3开发为了减少bug，修复bug时只做此bug的修复，与此bug有交互的方法置之不理，怕再次引起其他bug；

　　4、开发为了减少bug，修复bug时，周边有关联的业务逻辑隐藏问题，刻意再隐藏起来，让此bug暂时不会复现。

　　5、开发为了减少bug，精力只放在减少、隐藏bug上，开发工作的创新、可维护性、健壮性被抛之脑后。

　　6、开发为了减少自身bug数量，会抄袭相关的bug少的业务实现方法，代码冗余对项目质量无任何好处。

　　7、开发为了bug减少，对项目质量理念产生变化，认为只有减少bug才是正确的工作方法，而忽略了开发技术人员对创新技术、提高高可靠性、可维护性、质量佳的追求理念。

　　8、测试花费大量时间准确定位bug源头，但也有定位不准确的时候，导致开发bug数量多。开发与之引起冲突，开发之间相互推诿bug，长时间会影响团队关系，从而工作氛围不佳、人人自危。

　　9、测试如果要准确定位，要做大量定位、统计工作，从而花费大量时间。但目前只有1个在编测试、7个开发人员、两个不同项目组，导致测试任务加重，两个项目后期统计bug工作量增大，后期招新人也会产生资源花费。

　　10、测试人员对深层业务逻辑、数据、甚至配置测试执行时需要花费几天时间造数据、配置工具来测试深层次问题。为了多找bug，响应bug考核，测试人员就多找表面肤浅问题、因为深层次问题需要时间和大量工作，但不会发现大量bug，所以测试人员可能会多发现表面小问题来应付考核，但这些小问题有的不用修复，又浪费了开发时间。

　　三、Bug考核导致的几个后果：

　　1、开发创新思维被限制，写部分代码会变成他们避免、隐藏bug的过程；

　　2、部分公共基类编写、配置工作无人做，大家各做各的，生怕出问题算到自己头上，导致代码可维护性差、冗余代码多。

　　3、测试工作量加大，但不一定发现对项目质量有帮助的问题；

　　4、开发团队、测试团队、团队内部关系搞僵，开发任务不再是个创新、使用优化方法、有成就感的技术活，而是做好表面应付考核的活。

　　四、目前开发对代码质量的把控方法：

　　1、写业务逻辑同时优化基类、方法，从而避免冗余、增强代码可维护性；

　　2、相同业务逻辑尽量抽出来作为基类，其他相同业务继承此基类，规范开发逻辑；

　　3、配置NUnit做单元测试，实现提交的业务逻辑底层数据的正确；

　　4、发布版本前自测，自测避免基本业务逻辑、需求缺失、基本功能bug的产生。

版权声明：本文出自 sql2003 的51Testing软件测试博客：http://www.51testing.com/?96155

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。