问题
1.测试测人力少，转测质量不过关打回往往会压缩测试时间，得不偿失
2.开发人员经验不齐，经验年限少的开发往往考虑场景不全，造成严重BUG偏多，线上质量差
3.修改完BUG后觉得没问题，直接打状态 或者不知道可能影响哪里，缺少回归自测
基于项目中实际遇到的质量问题，提出这几个问题，作为改进方向，发起开发自测规范
原因分析
问题1，没有提供自测用例，或者自测用例不完整，导致自测不过关，如果打回去重新开发，浪费时间和精力，造成延期
问题2，有经验的开发往往开发往往考虑场景比较全，但是刚入职不熟悉的往往会考虑不全，这时候提出的BUG往往是异常场景考虑不周导致的，
问题3，很多开发往往只会在提测前做自测，却忽略了修改BUG后的自测，导致重新打开的BUG增多
采取措施
那么身为测试的我们，是需要对上述几种情况做预防和质量推进，在最近几个版本迭代中，逐步推进以下几个关键措施，以及提高开发自测的能力，进击吧开发自测。
大体的一个优化方向为前-中-后三个维度进行预防和规避
前置：
自测用例基本每个版本都是提供，但是往往不尽人意，追其原因，在于测试同学给开发同学的自测用例，往往都是主功能用例，也称冒烟用例，这只能保证转测时候是交付软件是完整的，却不能本质提高覆盖度，一些异常的场景开发可能想不到。测试用例评审可以取到一定作用，但是如果时间过长或者开发不重视，成效还是比较小。
改进：除了提供自测用例，还需要提供完整用例，具体做法如下(我们采用xmind导图方式提供自测点):
上面这幅图是通过图形标记的方式提供自测，？代表要自测，！代表需要注意的异常分支，但是不用自测，一般完成自测后改个状态即可
那么通过增加！需要留意的异常分支，只要求开发同学回忆一下是否有实现即可，这个好处是不需要执行自测用例，成本较低，但是缺避免了一些冒烟之后一些异常场景没有考虑到的情况。
中置：
其实这点体现在回归BUG的时候，重复打开BUG的针对性优化措施。回归BUG一般步骤除了开发修改完后重置状态为已解决，并列上修改点外，测试在验证之前，同样可以提供自测点，比如：
这样开发修复BUG之后可以知道自己应该自测哪些方面
后置：
最后面，其实是一个反馈机制，规矩大家都懂，但是缺的是能够给在你迷糊的时候给予提醒的人。同样，后置其实是对质量的一个回溯，并且作为代码质量的一个反馈机制，我一般的做法是在测试报告中体现前中置的自测结果，比如测试报告会加入几个字段：
自测通过率：90%
重复BUG打开数量：3，占比 20%
严重BUG数量：5，占比 10%
如果是针对迭代项目
自测通过率 总数 重复BUG打开数量 占比 严重BUG数量，占比 占比
这样版本质量就基本一目了然，也作为一种反馈让对应的开发指导自己的代码质量。
成果验证
待长期观察，总体趋势良好
