SDK開發經驗之測試

本來計劃測試作為版本的一個内容來說，結果發現版本廢話有點多，太長了；而且測試要點也挺多的就還是分開了。在這裡主要介紹一些與測試相關的内容。

關于提測流程

在關于版本的總結中，已經說了

對于一個版本提測，要有一個專門的提測流程。對于一些重點項還該有具體的說明（結合自身實際制定了一個提測前的版本checkList）。

讓版本提測有一個标準化的提測流程，隻有流程化了才能減少出錯的機會，提高版本品質，降低開發和測試的工作量。

當然，對于我們來說，這個相對比較簡單，内部有專門的系統去管理版本的提測，是以就已經有了一定的流程。我們的重點就變成了一些重點項的檢查。目前的提測流程主要包括三部：

出自測版本包，根據版本功能完成功能自測和一些基礎的自動化測試。 這可以了解為先消除一些最基本的問題，用一些自動化工具先檢查一邊。
檢查版本提測前重點檢查項并記錄結果。這是提測前最重要的一環。 這也是保證版本出現低級錯誤的關鍵，我們根據一次次爬坑的經驗總結了一系列的檢查項（後面專門說明）。開發者可以根據自身需要制定自己的流程。
準備版本更新說明：這裡要詳細列舉這次版本變更的内容以及對應的測試方法。 有時候有些功測試雖然知道需求，但是她并不知道怎麼測試，寫清楚詳細的步驟有助于他們初步了解這個功能的具體實作。
出包、确定最終的版本代碼tag，送出測試。 一般前兩步确認沒有問題以後，這一步幾乎花不了多少時間。

接下來我會把上面四個流程中比較重要的環節再介紹一下：

功能自測和提測前驗證

早期，我們這一步幾乎沒有，這一步主要就是本地先驗證下ant打包是不是正确，而具體的新功能自測和驗證是放在checkList裡面。後來我們做了一些基于UI的自動化測試，然後我們就把基礎功能的自動化測試和mokeny性能測試提前到這裡。所有工作通過一個腳本完成。下面就是某個SDK的出包驗證和自動化測試的一個批處理程式。裡面通過ant生成最終版本包，然後配合自動化測試完成一些版本正式提測前的基本功能驗證。

call ant
call copy .\docs\AGSDKTest.apk .\bin
cd .\bin
adb uninstall com.example.agsdkdemo.test
adb install AGSDKTest.apk

adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
call adb shell am instrument -w com.example.agsdkdemo.test/ android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
adb shell monkey -p com.example.agsdkdemo 100 -v

adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0t_svnlocal.apk
call adb shell am instrument -w com.example.agsdkdemo.test/android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
adb shell monkey -p com.example.agsdkdemo 10000 -v

adb uninstall com.example.agsdkdemo
adb install AGSDKSample-test-inner.apk
call adb shell am instrument -w com.example.agsdkdemo.test/android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-test-inner.apk
adb shell monkey -p com.example.agsdkdemo 10000 -v

echo "succ" & pause>nul

複制

關于提測前重點檢查項

之是以制定版本釋出的checkList，就是因為經常會因為一些很小的問題而影響版本的品質。畢竟每次送出測試前需要确認的問題很多，例如功能驗證、開發過程中一些臨時增加的一些斷點、為了配合開發做的一些調整等等。一個有效的checkList可以協助我們梳理所有容易犯低級錯誤的地方。這裡就列舉一下我們的checkList并做一個簡單的說明。先列舉一個完整的：

推薦做法之新版本、回歸版本提測：

提測前版本相關重點檢查項目: 

	對比TAPD需求單和BUG單, 确定是否完成所有需求以及所有BUG修複
	自己根據TAPD需求單上的需求跑過一遍自測
	檢查文檔是否對應新增的添加了功能接入說明
	檢查VERSION.md是否說明了所有更新内容
	檢查MSDK/assets/ 下面的msdkconfig.test.ini  msdkconfig.debug.ini 是否正确設定。可選子產品是否有開關完全關閉
	檢查版本号配置是否正确
	檢查第三方sdk的版本是否正确
	保證自動化測試所有接口通過
	版本通過金剛審計
	按照冒煙測試測試用例完成冒煙測試
	
提測前代碼Review重點檢查項目: 

	釋出前跑一遍FindBugs, 解決工具發現的所有BUG, 确認無需解決的BUG提示必須注釋說明
	檢查資源檔案使用方式, 必須使用反射方式調用
	檢查Logcat列印的内容, 避免在Log中列印關鍵資訊
	檢查RDM打包版本号配置是否正确
	檢查避免使用寫死值和魔法數字，如果有，必須說明		确認所有TODO标簽已經完成, 沒有遺漏, 确定要遺留的問題必須注釋寫明原因		檢查相關的so是否都已經送出到SVN

複制

推薦做法之緊急版本提測：

提測前版本相關重點檢查項目:
 
	檢查文檔是否對應新增的添加了功能接入說明
	檢查VERSION.txt是否說明了所有更新内容
	檢查代碼中版本号配置是否正确
	檢查RDM打包版本号配置是否正确
	保證自動化測試所有接口通過
	對比TAPD需求單和BUG單, 确定是否完成所有需求以及所有BUG 已經修複
	确認所有TODO标簽已經完成, 沒有遺漏, 确定要遺留的問題必須注釋寫明原因
	檢查相關的so是否都已經送出到SVN
	按照冒煙測試測試用例完成冒煙測試
	
緊急版本一般都是bug修複，也不會有功能更新，也不會大的修改，是以隻是把一些容易忽視的地方确認一次就可以了。

複制

增加幾點說明吧：

由于版本會有提測版本，回歸版本或者緊急版本，是以我們對不同的版本也會有不同的ckecklist
checkList是我們為了提高版本品質而增加的，是以我們都會仔細核對，而不該是走個過場。
我們也會根據實際情況和測試協商對checkList做一些調整（這個list也是測試和我們根據經驗具體總結的）

接下來我會對新版本提測的list做一個介紹：

提測前版本相關重點檢查項目:

對比TAPD需求單和BUG單, 确定是否完成所有需求以及所有BUG修複。

TAPD是内部一個管理需求和bug的系統，這裡也就是說确認下這個版本計劃的内容是否都已經完成。并根據實際修改需求或者bug單的狀态。
自己根據TAPD需求單上的需求跑過一遍自測

第一步是确認所有的需求是否已經處理，而這裡就是驗證功能是否符合需求。這裡我們會把一開始流程中提到的第三步在這裡完成。邊驗證功能，邊整理提供給測試的測試方法。一般這一步由對應子產品的開發整理，然後彙總給版本負責人。
檢查文檔是否對應新增的添加了功能接入說明

我們的文檔使用wiki，而且我們一般會再版本提測時提前告知新版本的内容，友善遊戲提前了解。以前我們出現過版本發了，但是有一個子產品的文檔一直忘了寫上去，那時候還不是wiki，文檔是在版本包，為此還不得不再走一次打包提測的流程。是以直接增加進來。
檢查VERSION.md是否說明了所有更新内容

初衷和原因與上面的文檔一緻
檢查MSDK/assets/ 下面的msdkconfig.test.ini msdkconfig.debug.ini 是否正确設定。可選子產品是否有開關完全關閉

這個可以了解為對外提供的配置是否正确。我們的SDK給測試和最終釋出的包的配置并不一樣，是以需要确認不同環境對外釋出包的推薦配置是否正确，之前也遇到過某個預設關閉的開關再配置中寫為打開。結果有遊戲沒有留意直接拷貝過去，導緻功能被打開，但是遊戲并沒有接口權限，導緻遊戲接口被告警。
檢查版本号配置是否正确

這裡主要是檢查代碼中的版本号是否正确，我們為了確定版本号正确，有幾個保護機制。這個在關于版本号的SDK設計心得之版本号（點選檢視）會重點說明。
檢查第三方sdk的版本是否正确

由于我們的SDK還接入不少SDK，是以需要确認第三方的版本是否正确。同時也是為後面遊戲來咨詢做準備。
保證自動化測試所有接口通過

這裡是我們對于所有提供給遊戲使用的外部接口的一個JUnit test單元測試。隻是簡單的合法參數調用測試，沒有詳細的邊界和異常測試（這部分專業測試會做）。
版本通過金剛審計

金剛是一個内部漏洞掃描平台，我們會把demo應用送出平台來确認代碼沒有漏洞，這也是對外釋出的其中一環。
按照冒煙測試測試用例完成冒煙測試

這個是指一些通用功能的測試，為了提高版本品質，測試會要求我們先對一些通過功能的正常邏輯進行驗證（目前這部分我們已經通過自動化測試實作，測得時候盯着看，然後再看一遍日志就OK）

提測版本前代碼Review重點檢查項目:

釋出前跑一遍FindBugs, 解決工具發現的所有BUG, 确認無需解決的BUG提示必須注釋說明

主要是為了提高版本品質，不過目前這部分用的比較少，有時候改動不是很大，版本比較着急就不會用（不過測試還是會基于jar掃描）
檢查資源檔案使用方式, 必須使用反射方式調用

這個是我們項目特有的，由于我們項目的代碼架構（這個我會在SDK設計心得之目錄結構和資源檔案（點選檢視）裡面說明）的特殊性，我們的SDK代碼如果調用資源，隻能通過反射擷取，是以我們要确認是否正确。
檢查Logcat列印的内容, 避免在Log中列印關鍵資訊

我們的logcat有一次直接把網絡請求加密前的内容列印了……你懂的
檢查RDM打包版本号配置是否正确

RDM是一個内部自動打包系統，我們SDK的最終版本會對比這個系統配置的版本和我們代碼中的版本，通過兩個版本的一緻性來確定版本的正确。
檢查避免使用寫死值和魔法數字，如果有，必須說明

關于寫死和魔法數字舉個例子。例如代碼中有個定時器，預設是半個小時執行一次。我們開發中為了測試效果可能會調整到1分鐘一次。如果版本周期比較長，可能最後就忘了修改這個數，一旦版本釋出以後就更麻煩了。

好吧，我還是不回避這個問題了，就舉自己的案例吧。當時我們某個版本忘了因為什麼，通路背景的域名不但配置檔案有，代碼也有，而且優先使用代碼中的，悲劇就這樣開始了。開發完測試的時候代碼用了測試環境的域名，功能正常。提測以後測試配置了測試環境的域名功能正常，也沒發現，然後正好那個版本比較着急用就沒灰階。釋出後第三天好幾個遊戲來問，無論怎麼配置都是測試環境……瞬間噶屁了。修改很簡單，但是因為沒有灰階，已經有比較多遊戲在更新了，隻能一個個去通知更換，然後被屌犯這麼腦殘的錯誤。

這個被坑過幾次，感觸頗深，不過這個可以配合todo标簽來避免。
确認所有TODO标簽已經完成, 沒有遺漏, 确定要遺留的問題必須注釋寫明原因

關于TODO我會在SDK那些事之SDK開發中的一些開發經驗（點選檢視）專門說，一定要看，是幹貨。TODO标簽的合理使用可以有效的解決很多問題。
檢查相關的so是否都已經送出到SVN

so檔案在win下（mac預設ignore好像也有）坑爹的SVN不會送出，有一次忘了就給漏了！！給漏了！！！漏了！！！

關于開發和測試的關系

上面啰啰嗦嗦說了一下我們目前版本提測的一些流程和提高版本品質的一些方法。下面就探讨一些沒那麼複雜（不過也挺複雜）的問題了。首先探讨一下開發和測試的關系。

可以明确開發和測試不應該是敵對關系，兩者的共同目标都是為了出一個高品質的版本。

是以開發不要覺得測試追債一樣，這個最重要。我們的測試有時候也會抓住一些小結不放，有時候也很不爽，但是很多時候還是有據可循，可以定位并說清楚的。

另外

對于某些新功能子產品，開發可以提供一些開發的設計思路給測試，協助測試完成測試用例的設計。

如果有遺漏，也不要沾沾自喜，還是要據實以告，否則萬一漏了某個分支就是大問題。

版本應該怎麼測試

這裡主要是列舉一些我們目前使用到的測試方法：

白盒

這裡主要是指

基于接口的測試，包括合法、非法參數、邊界值的測試，這部分内容是确定的，是以我們都通過自動化測試實作。還有一個是版本代碼比對。

我們的測試會比對目前版本與上個版本代碼的差異（當然有些是看不懂的，但是不影響了解整個流程）。其實讓測試看代碼我覺得是一件很好的事情，如果遇到有些緊急版本，一對比代碼就知道是怎麼改的，一眼勝千言。

黑盒

黑盒主要是指demo，我們會為遊戲提供一套我們的接口調用的demo（我會在SDK開發經驗之Demo和文檔（點選檢視）中描述demo的價值）。測試可以通過demo驗證一些具體的功能表現，目前我們通用的功能的基于UI的測試也都已經是通過自動化測試。

相容性

不用多說，Android的相容性和web前端的相容性沒啥差別。

性能測試

這個最好有，尤其是作為SDK，遊戲經常來問的最多的就是你們的包多大，加了以後對性能（CPU和記憶體）的占用量是多少等。這些有了才更專業啊。