如今，随着移动互联网的浪潮越翻越涌，移动APP测试工作的现状已经成了那本“家家难念“的经。不管公司大小，不管测试哪种类型的APP，让广泛测试者苦不堪言的就属重复性最多，测试工作量最大的功能测试。而这个系列文章将逐一解构一些问题。
这个系列第一篇文章已经对测试如何驱动开发进行自测进行了阐述。
这第二篇就来聊聊大公司的研发团队中测试&开发的内耗：
相信现在在大公司或者曾经在大公司待过的同学都有过这样的经历。在功能测试中对测试人员绩效评定的最主要标准就是bug产出。而对测试人员的惩罚则可能来自于线上问题的回溯。这里实际有两个比较大的问题，一个是对bug的沟通上；另外一个是对偶现bug的评估。
1.对测试员来说，工作主要的时间是产出bug，而不是和开发撕逼。而开发人员通常由于管理项目比较多，又或者直接不想接问题，会在bug单来来回回询问或推诿多次。更多的情况则是希望测试人员提供更多的证据，或者“你再在新的一个版本上验证呢”。
答：TestBird的在线功能测试平台，在功能测试过程记录操作的截图水印、记录app移动端的所有性能数据和日志。几乎可以提供全量的数据证据，让开发人员找不到借口再找测试人员打太极。而开发人员在此平台完全可以自测，而将修复后的bug一起提交回归
2.关于偶现bug的处理，根据墨菲定律，偶现bug通常会在产品发布后在用户侧出现。在有些公司有严格的研发流程，涉及到某些在发布后产生的重大问题，将回溯到测试人员。测试人员对于偶现问题也非常头痛，复现条件无法找到，偶现一次两次的时候收集的信息不足，无法提供佐证。而这些通常给了开发人员借口将bug关闭，在用户侧发生问题后回溯到就成了测试人员的责任。
答：在TestBird的在线功能测试平台进行测试，全程捕捉测人员的操作和日志，即使只出现一次的问题，也能有证据证明问题的存在，而让开发人员无法再关闭该问题。从而推动开发人员定位问题，减少上线发布后问题，也减少质量回溯到测试人员。
（1）操作截图
展开全文
（2）性能数据
（3）定位日志