接着上篇，压缩测试时间 ？
看这篇之前，建议先看，
“ 优秀的业务测试工程师 ” 应该是这样的 。
曾经，在星球「软件测试圈」，问了4个问题：
1、你所在公司，是否有研发自测环节 ？
2、这个自测范围和内容谁提供 ？每个提测版本，研发都自测哪些内容 ？
3、测试准入标准是什么 ？自测未通过的，如何处理 ？
4、测试通过标准（上线标准）
此文，分享一些参考做法 ，
001 研发自测
一般来说，都是需要「研发自测」的，
甚至有些项目，研发自测完，就可以直接上线，不需要测试同学的参与 。
那么「开发自测内容」，谁提供呢？提供哪些内容 ？
测试工程师，会根据自己的任务将对应的需求拆解功能点，然后输出冒烟测试的测试点（也可以是测试用例中的 P0/P1 Case），放在confluence平台（此处平台，很多，比如 TAPD / xmind文件也行 / Excel放在svn也行，方式不重要，团队内部协商即可），
这个文档作为研发自测范围和自测内容（至于这个文档是否需要经过评审？最好评审一下，跟开发、产品碰一碰），
测试的功能点可以写粒度也是比较大的点。
每一个提测版本，研发人员自测自己开发的功能点即可，保证主流程没有问题（基础的业务联调，那是必须的，否则，冒烟都通过不了） 。
补充，
实际跟N多测试同学沟通后，很多公司，是没有研发自测的，导致的结果就是，一个版本，提交了上百个BUG，非常恐怖 。
对于，一个版本，总共就几个Bug的同学，是无法理解的 。
提测版本质量烂、Bug多，效率低，且累，而且经常加班 。
写Bug要时间、录Bug要时间、改Bug要时间、验Bug要时间、重复写Bug要时间 ...
002 测试准入标准
1、手动执行冒烟测试用例，且都测试通过（打包时，自动执行新业务的接口自动化测试，以及已有业务的自动化接口测试，通过后，准入 。）
2、转测资料齐全
3、部署资料正确
4、SVN/Git（现在基本上没有SVN了）的代码提交记录正常有效
5、上次的问题修复率达到要求
参考文章：提测模板（测试申请单）
自测没通过的咋办 ？
版本打回，邮件通知全团队，
待提交新版本再测试，上线时间，顺延 。
如果，提测延期，上线时间，定死，咋办 ？
1. 加班，赶工 。
2. 实在搞不定的，参考下面的“通过标准”，最后的做法 。
003 测试通过标准
注：如下这段，来自妹纸“紫芸”，在「软件测试圈」的主题 。
近期上线的某个项目并未达到测试组管理规范设定的通过标准，但因市场等各种原因，算妥协发布了正式版。
对于这类项目的报告出具等很费心，因为遗留问题实在太多，不出具报告对自己不利，出具报告有违背起初设定的通过标准。
什么才是测试通过标准？以往常有听过领导问：“这个项目怎么就是测试通过了？”也常有开发问：“项目怎么才算通过测试？” 一系列的疑问，最好的解决方式是什么？
重新审视了测试通过标准，感觉本身有缺陷：太过完美，看似可量化，站在不同角色看，实则无法很好量化，如何优化测试通过标准？
当前功能测试方面使用的部分通过标准：
1、测试方案/用例覆盖程度：95%以上；
2、测试输出结果与预期输出之间的符合率：95%以上；
3、测试方案/用例的执行程度：100%；
4、缺陷处理情况：缺陷等级非常重要、重要（P0、P1）需全部关闭，一般、建议性缺陷<10%。开发和测试有争议的缺陷需要经项目小组讨论后决定是否需要修改（拉上产品经理、项目经理、业务方），若经讨论后确认可以忽略不改或因其他原因要在以后的版本中实现，则本次测试可以认为通过（这里非常重要：遗留的问题，一定要跟团队讨论，确定可遗留到下个版本，而且要在测试报告中，注明已知问题 & 风险）。
参考文章：聊聊「测试报告」(附 模板下载)
