Google atest的使用

【前言】

Google Android Compatibility Test包含有 CTS、VTS、GTS、STS等（統稱為XTS），另外還有TVTS及Smoke Test等等。通常開發人員要參與SOC适配的前期開發、SQA階段（包括XTS的主觀）及XTS客觀測試等，這些階段也是可以并行的。

【atest簡介】Android AOSP Code裡已經包含有CTS和VTS，為atest的使用奠定基礎(GTS/STS不适用)，module developer在commit方案之前，可以在本地用atest跑下對應CTS/VTS的module/class/method是否pass，不用等到SQA階段CTS/VTS fulltest去掃是否有fail，縮短bug上報-debug-解決-驗證-關閉等SQA測試周期，友善module developer自己跟進check問題=zh-cn

本地AOSP code環境裡，source build/envsetup.sh; lunch 之後，adb connect device，即可準備運作atest測試：

• atest -s “ip:5555" moduleName
• atest -s “ip:5555" className
• atest -s “ip:5555" className#methodName

更多使用方法參考如上連結。通常第一次運作測試的話需要時間較長，要編譯出atest相關tool及testcase apk等，後面在跑的話就比較快了。

【atest使用】

基于CTS/VTS Compatibility Test，還是很友善的。參考：https://source.android.google.cn/compatibility/tests/development/atest?authuser=0&hl

【atest的優缺點】

• 優點：使用簡單，基于本地code，容易debug，不用去配置測試環境和下載下傳CTS/VTS tool。
• 缺點：基于AOSP code，通常soc拿到的是初版aosp的code，後續更新的話，CTS/VTS這部分可能很少更新到，是以CTS/VTS就會比較舊。Google 釋出的Compatibility Test Tool都是基于最新的代碼編譯的，是以atest會落後Google釋出的CTS/VTS release tool(有些問題是Tool的issue，就需要用最新的Tool來測)。GTS/STS不能使用atest，因為沒有sourcecode。