测试的工作内容有哪些？该如何处理工作中遇到的bug？ -凯发app官网

作为一个测试人员，我们平时的工作其实是很多的，包括以下但不限于：文章源自玩技e族-https://www.playezu.com/20857.html

文章源自玩技e族-https://www.playezu.com/20857.html

当然这不是最全的，有些牛逼的测试人员能够做比这些还多的工作。也会有没有这么多的，那原因应该无外乎几种：文章源自玩技e族-https://www.playezu.com/20857.html

1、测试人力充足：人力足够就可以把测试的工作进行细分，不用一个人去负责很多的任务，有钱就是任性。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

2、自动化&测试工具成熟：这个很厉害了，把能够自动化的全部自动化、测试内容工具化，减少人力的浪费，但需要很高的测试技术底蕴。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

3、加班：这个不说了就...文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

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

 文章源自玩技e族-https://www.playezu.com/20857.html

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

 文章源自玩技e族-https://www.playezu.com/20857.html

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

下图是我们这几个迭代的内测bug数量统计：文章源自玩技e族-https://www.playezu.com/20857.html

文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

可以看到吧，每迭代的bug下降趋势还是蛮明显的。需要说明下，正是迭代v1.1让我决定了需要做bug分析，因为bug数在这个迭代中达到了骇人的314个，致使测试人员在整个迭代中一直在报bug和验证bug，凶猛的吃时间怪兽。文章源自玩技e族-https://www.playezu.com/20857.html

有问题不怕，就怕视而不见。面对v1.1这314个bug，我们做了第一次bug分析，分析结果如下：文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

1、本迭代由于需求过多，只能分3期开发，每期2周（我们之后的迭代就是2周），而且只能在3期全部完成开发测试后才能发布。所以造成bug总数多。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

2、开发执行提测准入case（后文统一称呼为ac，acceptance criteria）不合格，一些提测的交付物甚至连流程都走不通。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

3、ac粒度太粗，只是主流程，分支流程覆盖不够，即使开发通过也会出现很多明显bug文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

4、分期开发，模块开发每期拆分不合理，耦合度较高，造成后期的开发影响了前期的功能，造成回归bug增多。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

5、技术评估时漏了一个功能模块，导致临上线才发现并开发，由于时间紧，慌乱中又贡献了很多bug。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

6、服务环境配置问题。文章源自玩技e族-https://www.playezu.com/20857.html

针对v1.1的分析结果，我们采取了一些措施：文章源自玩技e族-https://www.playezu.com/20857.html

• 对产品经理：提供需求时需要考虑成本，尽量将需求控制在2周之内，需求需要和开发&测试一起评估，如有超出需要根据情况减少或更改需求。
• 对开发人员：合理拆分需求，进行技术评估，人员分配任务时尽量解耦，避免冲突发生；加大自测的力度，每次提测需要严格通过ac；保证服务质量，完善服务监控。
• 对测试人员：编写ac时实时反馈产品问题；缩小ac粒度，增加ac中分支流程覆盖。

 文章源自玩技e族-https://www.playezu.com/20857.html

那之后实践的结果怎么样呢？从v1.2和v1.3上我们可以发现确实有改观，但是在2周内产生大于60个bug还是很多的，所以我们在这2个迭代也做了bug分析，主要的结论是：文章源自玩技e族-https://www.playezu.com/20857.html

• 自测不够，ac里面明确的点提测后并没有通过。
• 原型缺少某些共识的说明，比如输入框中文本格式的样式及规则等，导致开发的交付物存在各种不一致。

• 对产品经理：提供高保真的产品原型；对于产品设计共识，输出共识文档供开发和测试使用。
• 对开发人员：加大自测的力度，每次提测需要严格通过ac。

 文章源自玩技e族-https://www.playezu.com/20857.html

好了，那就可以再实践了。v1.4结果出来后，有点失望，还是不低。没办法，继续分析吧。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

自测不够，ac里面明确的点提测后并没有通过。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

好吧，看来我们能够入手的点就是开发自测了。所以v1.4之后我们的措施是：文章源自玩技e族-https://www.playezu.com/20857.html

技术负责人负责提测前和相关开发一起过一遍ac，通过后才能提测；在过ac的过程中技术负责人要将遇到的问题记录下来，方便日后在开发团队中提高自测质量。文章源自玩技e族-https://www.playezu.com/20857.html

 文章源自玩技e族-https://www.playezu.com/20857.html

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

 文章源自玩技e族-https://www.playezu.com/20857.html

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

 文章源自玩技e族-https://www.playezu.com/20857.html

从实践的结果来看，通过bug分析来降低迭代bug数量的方法还是非常有效的，而且测试团队也已经感受到了它给我们带来的红利，让我们在测试团队改进提升的道路上能够走得更稳更远。文章源自玩技e族-https://www.playezu.com/20857.html