\
今天，本不打算写东西的 。看到测试群，很多Tester在抱怨，一个版本，测了100多个Bug 等 。\
有必要聊几句 。
\
首先，
1个版本，100多个Bug，肯定是不正常的 。
\
还记得，那套理论么？Bug修复时间越晚，成本越高 。
\
如下，从搜索引擎随便搜了一张图（数据合理性暂且忽略，参考即可） 。
\
1个版本，提测后，100多个Bug，什么概念 ？（见如上图的第三阶段 ，自行对比下） 。
\
那怎么避免此类问题 ？ （ 嗯，本文主要想写这点，怎么样让提测Bug少点 ）
（作者： 老徐，isTester.com）
解决方案：
建立严格的准入标准 ，见之前文章：
\
其实，文章里面写的挺详细的 ，包含 研发自测、冒烟测试、转测资料&说明&流程 等。
\
上面文章有的，今天就不重复阐述了（大周末的，避免浪费阅读时间） 。
\
如果严格按这个逻辑执行，一个「两周一迭代的版本」，Bug控制在30内，是没问题的（具体还得看团队的磨合情况，及项目的类型、项目复杂度等） 。
\
\
接下来，说点异常情况 ：
\
01
\
很多情况下，如上这套逻辑，是推行不下去的 。
理论很美好，现实很残酷（很多团队，那不是一般的乱；遇到问题，先不去想着解决本质问题，而是直接先来个996再说，如果还不能解决，997试试 …）。
\
如果实在无法推行研发自测、严格的准入标准 。
那么，IDO老徐 的建议是：
提Bug时，先提主要Bug即可，先修复一轮；
待提交新版本后，再提细节Bug 。提太多Bug，浪费提交录入的时间，开发查阅，也费时间 。
\
\
02
（作者： 老徐，isTester.com）
来自某同学的提问：“研发开发进度慢到吐，工期不能按时交工，测试该怎么做？ 我如果要催，该怎么催，关键人家也在工作，也没在闲着，就是忙，工作进度是他们自己定的，脑子疼。 ”
\
如上，
很多时候，就是由于这种预估时间不准，最后上线时间定死，草草了事 。把未开发完成的半成品提交给测试，最后导致1个版本100+ Bug的情况 。
\
对于此种情况，普通测试能做啥 ？
“把现状，在项目群里，同步团队，说明没按时提测即可 。其他的，普通测试做不了 。”
\
\
如果在普通测试的基础上，想往前推进一步呢 ？
（作者： 老徐，isTester.com）
1. 这种属于任务拆分不合理（或者过于乐观，亦或技术障碍没提前预研），导致工时评估不准。
第一步，先去把任务拆分到1D颗粒度（需研发老大来推动这个事）
\
2. 每日站会进度同步，遇到的阻塞性障碍，及时解决；设置项目关键节点 ，有问题，及时抛风险 。
如上，先玩这两点，再观察一下 。
\
End 。
\
先聊这些，周末了，文章尽量短点 。
最后 ，
这几天，老徐花了十几个小时，把之前的测试资料，进行分类调整、文章调整、格式调整，进入V2.0时代，阅读体验更佳、资料质量更佳，公号「简尚」后台，回复“测试资料”阅读之 。
\
文 / IDO老徐
2019.10.18 深圳
