今天我们组唯一的一个美少女战士,在组内做经典bug分享,故事的内容大致如下,我们在收集由我们的工具发现了经典bug,我们的newmonkey就发现了一个。 我们派出了我们的妹子去问开发。开发哥对妹子说,只要进去这个用fragment做的搜索界面就会crash了,因为这个自定义的fragment没有的无参数的构造函数。这就是你提的这个bug单的成因。
开始的时候我们的妹子默默的相信了。辛亏我们一个身经百战的男同事提醒,看下我们monkey的操作日志能对上开发说的重现步骤吗?亲,你欺骗了我们妹子对你的信任呀,根本对不上。省略百字排查过程,最终发现原来是因为在fragment的界面横竖屏切换了,导致原来的fragment被destory然后再重新create,重新create是系统使用默认的反射方法来调用fragment的一个无参构造函数,而这个构造函数在我们自定义的fragment中居然木有了。。结果就crash了。前者没有发生crash是应用代码调用,后者发生因为是完全不同的系统代码调用。
想一想:
清晰的重现步骤非常重要,因为这个才能够帮助测试,可以去理解问题发生的原因,去做对应的回归测试,甚至是建立对应的流程,工具去让发现问题的效率和成本更低,例如建立静态检查的规则。如果马马虎虎随随便便告诉一个根本不可能重现的重现步骤,不仅让测试没办法重现问题,也没办法提升自我去理解更多,问题也只会重复出现,团队效率只会越来越低。。不过光埋怨没有用,世界上,总会有不愿不能或者不想去告诉缺陷原因的开发,面对每一个bug,包括他的解决方案,我们必须抱着一颗怀疑的心,打破砂锅问到底的心,去看待去理解这些方案。
网友评论