在測試過程中，除了版本本身功能的修改外，還存在環(huán)境的變化，比如移動端會時不時的出來一個新的系統(tǒng)。由市場的使用率來看，一般人類都比較喜歡嘗鮮，同時 根據(jù)測試規(guī)范需要有一定的系統(tǒng)匹配率，所以測試人員對新的系統(tǒng)都會全面的進行版本測試。因為有效類的內(nèi)容比較多，而項目時間又有限，一般不同的人會根據(jù)自 己的習慣進行優(yōu)先測試，而個人喜歡把一些其它系統(tǒng)不支持軟件還是能正常使用的內(nèi)容在新系統(tǒng)中跑一下，看是否會出現(xiàn)異常。不巧，在一次android新出來 的4.4系統(tǒng)中，為了驗證音樂識別功能，點擊添加一首無法匹配的本地歌曲到歌單，提示程序崩潰。
　　問題出現(xiàn)了，而且是大問題，如果說書的話，本人一定會吊足各位看官的胃口，對你們說欲知問題緣由，請聽下回分解。NO，NO，NO，我們不來這套，我們直 接切入主題--為啥會崩潰？拿著手機，保存著崩潰現(xiàn)場找到對應的研發(fā)人員進行問題分解：先看是否測試資源有問題？歌曲正常。再看功能代碼是否有異常？邏輯 等都正常。那是什么緣由造了這個bug？后來對比發(fā)現(xiàn)被測軟件在其它系統(tǒng)做同類操作都正常，android4.4系統(tǒng)出問題，難道是 android4.4系統(tǒng)跟其它系統(tǒng)有區(qū)別？經(jīng)過一步步的分解，發(fā)現(xiàn)在android新虛擬機art下，NDK方法 FindClass 不能再使用通用的類型簽名 java/lang/Object作為參數(shù)獲取 java類別，這導致之前NDK編譯的so中部分FindClass方法失效，導致軟件異常。
　　原因找到了，那么bug的解決方案容易多了，方法是將程序中所有使用通用的類型簽名 java/lang/Object作為參數(shù)的FindClass方法的參數(shù) 修改為正確的類型簽名。
　　經(jīng)過這個bug的發(fā)現(xiàn)－解決，讓我們不得不深思，像類似這種開源軟件的使用，應該采取怎么樣的策略呢？是否需要考慮風險性？應該如何采取策略以保證確認對市場上新系統(tǒng)的及時跟進？