问题：
1、我们平常在修改bug的时候，很有可能会遇到修改一些通用的业务方法，A业务的问题修复了，B、C的问题又冒出来了这种问题。
2、还有可能一轮测试改完了，改出新的bug这种情况，那么可能后续就需要二轮，三轮这种测试还不一定能解决。但是这种人力测试，需要每个功能都去测到，而且你也不知道你写的这行代码会不会影响到全局的业务。
我考虑了两种方法
1、集成测试，项目完成，写一下集成测试，保证代码功能能够正确运行，而且二次修复时，依然可以使用，保证不会影响整体模块
2、做自动化测试，避免人力重复去点击测试
我们公司的同事说这两种方法都不太合适，因为首先我们是项目制的，我们把项目交付了就算结束了，而且写集成测试这种是需要时间成本的，而且很多开发也不高兴写这个东西。然后自动化测试也不行，还是因为项目制的问题，我们毕竟不是做产品，不需要那么细致。最后总结了一下，其实也没有什么其他好的办法，只有说设计阶段和修复阶段尽量详细一点（后来想了下，这种方法是有一定道理的，但是对于业务流程大而且绕的项目里，最后设计的压力和修复的压力还是落到开发头上的）
就想问一下各位怎么看的，能不能给点意见什么的
嗯，作为一个开发，站在开发的角度来回答下下这个问题
首先，公用方法的修改是需要慎重的，这个就需要在自测上下功夫，不能因为a功能修改了公用方法导致b功能出现bug
其次，如果出现开发自测不到位，产生这种修复的新bug，这个是要测试去回归问题的，，，为什么测试流程要分为 dev -uat -master好几轮测试，就是为了规避这种问题
其实究其根因还是开发的问题，当然产生的问题后边所有的返工成本都是要开发区付出的
一个好的开发人员尽力避开这种连环bug是基本的素养
你们公司难道没有专门的测试吗？测试主要干的就是编写自动化测试脚本，手动点击界面测试出现bug，提交给开发去修改，编写用例测试文档，操作手册等等
自动化测试要写，手动点击也要做，很多错误都是逻辑性错误，自动化测试只保证你们的接口没问题，不保证多项操作不出问题，你们项目交付前也必须不停的测试功能，都没问题了才可以交付，如果不认真细致，产品那里也会给你们反馈让你们做
总之你们如果没有专门的测试，就应该成立一个测试部或者你们那里一个部门添加几个测试人员，发现问题不能及时解决最后麻烦的还是你们
您好，我是有问必答小助手，您的问题已经有小伙伴帮您解答，感谢您对有问必答的支持与关注！