5月底去杭州參加了一次阿里技術沙龍的活動，應會議組織者耿電兄的邀請去做了一個移動app測試的分享（詳見http://club.alibabatech.org）。有點被抓壯丁的感覺，主要是因為覺得我們團隊在無線測試方面的積累還很不夠，無論是相對於業界還是相對於公司內部的很多移動測試團隊。不過倒是很高興有這樣的機會去參加交流，因為要準備PPT，所以也“被逼”著去了解了很多方面的內容，並且在整理的過程中促使自己更加系統化的思考移動app測試的開展。同時，在會場的時候也和很多同行做了比較深入的交流，所以也很感謝阿里給大家提供了這樣好的交流的機會。 提起app的測試，特別是技術一點的測試，大家立馬想到的是各種app自動化的工具和技術，以及開展的方法。其實app的自動化只是測試中的一小部分，實際工作中我倒是建議把自動化放到第二階段，特別是針對於從網站延伸出來，在app測試上積累還不深的團隊，不要急著去弄自動化的工具和框架，而是先把一些基礎的東西做起來。這些東西對應整個app的質量，包括app本身的質量和整個運營的質量也許更有直接的影響和效果。 除了PPT裡面提到的，還有很多沒有列到裡面也值得去思考，因為PPT的角度更多從效能和服務的穩定性角度來看的。 下面是我們想到的一些方面，列出來給大家參考也歡迎討論。 從App的角度來看，其實和傳統的測試C/S架構的Client是一樣的，很多的方法和思路都可以用上。 1. App端的基本功能當然是我們必須考慮的，對很多團隊來說，這也是我們花費人力和時間比較多的地方。這些當然也是最基本的。如果只是從這個角度來看，app沒有什麼特別的，和其他C/S架構的程式的client是一樣的。 2. 相容和適配的問題。      這個也是app測試非常關注的問題。這裡的相容和適配包含了幾個方面：      - 硬體的適配。 比如硬體的效能，螢幕的大小，一些依賴的裝置比如GPS等。      - OS版本的相容，ios和android都有一樣的問題，比如如果用了一些新的API在老的系統上不支援會導致crash。      - 螢幕的解析度適配。移動裝置的解析度多種多樣，如果app沒有做比較合適的處理就可能會顯示不好，甚至影響功能的操作。      要做到比較好的覆蓋，這些都是很耗費時間的。現在想到的辦法主要有3種：      1. 自行購買或者借用裝置來實際驗證。 這個方法比較完整，但是受限於財力人力不可能做得很全面。      2. 一些第三方雲測試的解決方法，比如testin.cn這種，可以提供基本的執行情況和一些截圖，有助於擴大測試的範圍。      3. 比較白盒的方法。將不相容的地方整理出來，然後去分析我們的app中可能不相容的地方。這種方法可以避免像前面的方法一樣廣撒網碰運氣，但是對團隊的技術能力的要求比較高，前期也需要花費不少的時間。      當然，還有一個不是辦法是收集使用者的反饋，亡羊補牢。 3. app crash的問題      crash，或稱為閃退的原因有很多，針對這一部分出來分析和測試，還有一個很重要的是能收集到crash的問題，做事後的修補。所以需要確認我們的app有crash上報的能力，無論是公司內部的還是第三方的平臺，我們需要定期的知道外網的app crash的次數和crash的基本資訊，幫助我們定位和修復。 4. App端本身的效能分析，記憶體洩漏的分析。 5. 程式碼覆蓋率分析的方法也是很好的參考，無論是App端還是後臺服務端。 6. 灰度釋出的方案。保護app端釋出和提交app store的灰度，也可以是自動更新的提示的灰度。後臺服務端也可以做灰度，類似於網站的做法，不過要考慮和app的相容性。 先寫到這麼多吧，這一塊也是在持續的探索中。大家可能都會有一個感覺是有很多的事情要做，也可以做，但是我瞭解到的很多情況，app無論就團隊人員還是技術積累都是在發展中的階段，所以需要我們去做取捨優先做哪些。