在測試過程中，除了版本本身功能的修改外，還存在環境的變化，比如移動端會時不時的出來一個新的系統。由市場的使用率來看，一般人類都比較喜歡嘗鮮，同時 根據測試規范需要有一定的系統匹配率，所以測試人員對新的系統都會全面的進行版本測試。因為有效類的內容比較多，而項目時間又有限，一般不同的人會根據自 己的習慣進行優先測試，而個人喜歡把一些其它系統不支持軟件還是能正常使用的內容在新系統中跑一下，看是否會出現異常。不巧，在一次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的發現－解決，讓我們不得不深思，像類似這種開源軟件的使用，應該采取怎么樣的策略呢？是否需要考慮風險性？應該如何采取策略以保證確認對市場上新系統的及時跟進？
