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