问题背景：目前公司较小，测试人力不足，因此对于质量这一块目前没有更多的管理。因此有的开发人员的开发质量会不高，经常会有重复性的低级问题出现。虽然说足额写问题站在开发人员的角度上，不是什问题或者大问题，但是对于一个打算上线的系统来说却是致命问题。
解决办法：整理并实施开发人员测试规范。1、这是一个基本的测试库，里面的Bug都是多次的Bug，不能再犯。2、写清楚开发人员要自己单元测试的基本逻辑和情况。
问题提出背景：
开发人员在开发程序过程中，总是会有一些相同的Bug并非是因为自己发现不了，而是因为不够重视。而测试人员或者项目经理总是在一些低级问题上与开发人员斗法，无法集中优势兵力发现更多的业务逻辑上的Bug。因此我想着是否升级。
问题的危害：
1、 重复的低质量Bug不利于开发人员成长，当然也很容易危害测试人员(项目经理)心理健康。
2、 重复的低质量会增加测试人员的工作量，也就是增加开发工作量 J
3、 重复的低质量的Bug会增加回归测试的时间。
4、 不利于整个团队的成长，不利于项目质量的长久提高。
问题的解决：
任何以流程存在的过程都是可以优化的。
看看我们开发-测试的一般流程。
从上图可以看出，工作量是由回归的次数和每次回归Bug单中Bug的数量来决定的，而这两个都是可以在开发过程中改变的，也就是我们要改进的方向。
对于回归次数的控制很多公司依靠测试工具和改进测试方法来提高效率（测试可以改进的地方）；而Bug数量的控制更多的是依靠“Bug绩效考核”（开发可以改进的地方）。因为主题的原因，我们只讨论第二种情况。
推行“Bug考核机制”？？？就目前来看是不太现实的，因为测试人员稀缺、地域原因等等。当然我们不能就此作罢，不走寻常路的我们需要另外一种方式：——推行开发人员自测规范。大致的意思是：有开发人员、测试人员共同总结一些特别、特别共性基础的Bug（表现形式为一些公用的测试用例），开发人员开发完毕之后，要保证自己的程序至少能通过这些用例的测试。如果没有达到，可以采用测试人员或者项目经理问责制度……
如何实施（建议性）：
1、 各个项目组总结基础的共性问题，测试部总结共性问题，得到一个基础Bug库。
2、 经过各个项目组、测试部筛选，达成共识，得到一个试行版的规范。
3、 每隔一个月（或者更长时间）更新依次规范。
4、 项目组内部对不合规范的程序进行公示。