在测试过程中，除了版本本身功能的修改外，还存在环境的变化，比如移动端会时不时的出来一个新的系统。由市场的使用率来看，一般人类都比较喜欢尝鲜，同时 根据测试规范需要有一定的系统匹配率，所以测试人员对新的系统都会全面的进行版本测试。因为有效类的内容比较多，而项目时间又有限，一般不同的人会根据自 己的习惯进行优先测试，而个人喜欢把一些其它系统不支持软件还是能正常使用的内容在新系统中跑一下，看是否会出现异常。不巧，在一次android新出来 的4.4系统中，为了验证音乐识别功能，点击添加一首无法匹配的本地歌曲到歌单，提示程序崩溃。
　　问题出现了，而且是大问题，如果说书的话，本人一定会吊足各位看官的胃口，对你们说欲知问题缘由，请听下回分解。NO，NO，NO，我们不来这套，我们直 接切入主题--为啥会崩溃？拿着手机，保存着崩溃现场找到对应的研发人员进行问题分解：先看是否测试资源有问题？歌曲正常。再看功能代码是否有异常？逻辑 等都正常。那是什么缘由造了这个bug？后来对比发现被测软件在其它系统做同类操作都正常，android4.4系统出问题，难道是 android4.4系统跟其它系统有区别？经过一步步的分解，发现在android新虚拟机art下，NDK方法 FindClass 不能再使用通用的类型签名 java/lang/Object作为参数获取 java类别，这导致之前NDK编译的so中部分FindClass方法失效，导致软件异常。
　　原因找到了，那么bug的解决方案容易多了，方法是将程序中所有使用通用的类型签名 java/lang/Object作为参数的FindClass方法的参数 修改为正确的类型签名。
　　经过这个bug的发现－解决，让我们不得不深思，像类似这种开源软件的使用，应该采取怎么样的策略呢？是否需要考虑风险性？应该如何采取策略以保证确认对市场上新系统的及时跟进？