作为一个测试人员，我们平时的工作其实是很多的，包括以下但不限于：

测试工作.png

　　当然这不是最全的，有些牛逼的测试人员能够做比这些还多的工作。也会有没有这么多的，那原因应该无外乎几种：

　　1、测试人力充足：人力足够就可以把测试的工作进行细分，不用一个人去负责很多的任务，有钱就是任性。

　　2、自动化&测试工具成熟：这个很厉害了，把能够自动化的全部自动化、测试内容工具化，减少人力的浪费，但需要很高的测试技术底蕴。

　　3、加班：这个不说了就...

　　在这里，我们就说第二种，因为我们都希望我们的测试团队是往这个方向发展的。其实以前发过很多关于测试自动化还有测试工具的文章了，也就是要在这个方向上行进的证明。但是，想归想，一个团队，尤其是小型公司的互联网测试团队，往往都承受着测试人力紧缺的压力。就拿我们来说，目前我们对于技术部门开发人员和测试人员的比例控制是5:1，也就是1个测试人员在1迭代时间内要能够具备承受5个开发人员交付物测试的压力。以目前的迭代速度，再进行自动化或者测试工具等项目的开发的进度会很慢。所以，我们要找到能够争取时间的点，来让我们有更多的时间做测试的改进优化。

　　接下来就是找能够争取时间的点了。在这个上面我们采用了测试流程记录的方式，就是把测试在一个迭代中做的工作的每一步的开始时间&结束时间记录下来，发现除了测试本身时间占比很多外，本迭代内测BUG验证也是很吃时间的。而内测BUG验证的时间又直接受BUG数量的影响，所以，分析后我们就把希望放在了减少迭代内测BUG的数量上。

　　测试小伙伴们应该知道的，想降低迭代内测BUG的数量，不简简单单是测试人员想想就可以的，因为BUG的产生原因多种多样，或源于产品需求的不确定，或源于开发的不认真，或源于测试用例的不正确，或源于各方信息的不对称等等等等。所以，解铃还须系铃人，如果想降低BUG数，那就需要好好地分析BUG的产生原因，而分析的数据就来源于我们的迭代BUG中。

　　下图是我们这几个迭代的内测BUG数量统计：

BUG.png

　　可以看到吧，每迭代的BUG下降趋势还是蛮明显的。需要说明下，正是迭代v1.1让我决定了需要做BUG分析，因为BUG数在这个迭代中达到了骇人的314个，致使测试人员在整个迭代中一直在报BUG和验证BUG，凶猛的吃时间怪兽。

　　有问题不怕，就怕视而不见。面对v1.1这314个BUG，我们做了第一次BUG分析，分析结果如下：

　　1、本迭代由于需求过多，只能分3期开发，每期2周（我们之后的迭代就是2周），而且只能在3期全部完成开发测试后才能发布。所以造成BUG总数多

　　2、开发执行提测准入case（后文统一称呼为AC，Acceptance Criteria）不合格，一些提测的交付物甚至连流程都走不通

　　3、AC粒度太粗，只是主流程，分支流程覆盖不够，即使开发通过也会出现很多明显BUG

　　4、分期开发，模块开发每期拆分不合理，耦合度较高，造成后期的开发影响了前期的功能，造成回归BUG增多

　　5、技术评估时漏了一个功能模块，导致临上线才发现并开发，由于时间紧，慌乱中又贡献了很多BUG

　　6、服务环境配置问题

　　针对v1.1的分析结果，我们采取了一些措施：

　　对产品经理：提供需求时需要考虑成本，尽量将需求控制在2周之内，需求需要和开发&测试一起评估，如有超出需要根据情况减少或更改需求。

　　对开发人员：合理拆分需求，进行技术评估，人员分配任务时尽量解耦，避免冲突发生；加大自测的力度，每次提测需要严格通过AC；保证服务质量，完善服务监控。

　　对测试人员：编写AC时实时反馈产品问题；缩小AC粒度，增加AC中分支流程覆盖。

　　那之后实践的结果怎么样呢？从v1.2和v1.3上我们可以发现确实有改观，但是在2周内产生大于60个BUG还是很多的，所以我们在这2个迭代也做了BUG分析，主要的结论是：

　　自测不够，AC里面明确的点提测后并没有通过

　　原型缺少某些共识的说明，比如输入框中文本格式的样式及规则等，导致开发的交付物存在各种不一致

　　针对v1.2和v1.3的分析结果，我们采取的措施是：

　　对产品经理：提供高保真的产品原型；对于产品设计共识，输出共识文档供开发和测试使用

　　对开发人员：加大自测的力度，每次提测需要严格通过AC

　　好了，那就可以再实践了。v1.4结果出来后，有点失望，还是不低。没办法，继续分析吧。

　　自测不够，AC里面明确的点提测后并没有通过

　　好吧，看来我们能够入手的点就是开发自测了。所以v1.4之后我们的措施是：

　　技术负责人负责提测前和相关开发一起过一遍AC，通过后才能提测；在过AC的过程中技术负责人要将遇到的问题记录下来，方便日后在开发团队中提高自测质量。

　　在此之后，我们可以很明显的看到，v1.5 - v1.7的BUG数量有了非常明显的减少。当然，这些版本的需求量其实是有些下降的，但是我要说的是，其实我们的迭代时间也在下降，也就是从2周降到了1周，甚至在v1.7时是3天。当然有些小伙伴要说了，开发做了自测，那不是测试的本职工作吗？对不起，我对于这一点实在不能苟同，请记住，作为提供产品中的一环，开发是要对自己的交付物负责的。

　　再说下v1.8，这也是一个很好的案例收集。因为我们在v1.8进行了技术优化（解决了前期迭代中没有时间解决的技术债），但是由于没有给开发提供相应的AC，导致了回归BUG数量很多。所以对于未来再有技术优化时，开发需要先定义好需要优化的模块，然后由测试给出AC，开发自测通过后再提测。

　　从实践的结果来看，通过BUG分析来降低迭代BUG数量的方法还是非常有效的，而且测试团队也已经感受到了它给我们带来的红利，让我们在测试团队改进提升的道路上能够走得更稳更远。