技術爲輔，思惟主導

----中國移動互聯網測試開發大會有感

      昨日應領導之要求參加了由TesterHome主辦的中國移動互聯網測試開發大會，說實話我原本不喜歡參加這類大會的，由於通常這類大會不少時候都類型於作廣告。咱們公司有一個產品A,這個產品有什麼功能，能解決什麼問題，吹噓一番，而後要使用咱們的產品不是辦會員，就是要去購買。而後換一我的，再去介紹產品B,一樣的思路，到頭來沒有什麼收穫。不過昨天的大會仍是出乎個人意料呢，不能說收穫滿滿吧，仍是開闊了思路，增長了很多見識。

如今就我我的的感觸總結一下，僅供你們參考。

一，    保持傳統，廣告宣傳

      傳統的這類大會都會有很多公司來介紹本身的產品，本次也不例外，介紹了很多相似的東西，如：Google Mobile Testing,工信終端操做系統測試評，華爲雲測試，去哪兒去測試體系，以及所打的廣告騰訊WeTest,TestI雲測試平臺，還有百度MTC雲測試中心等等。

       此類關注提供測試平臺，測試服務的公司在很早的時候就出現了，但是市場前景並很差。具體緣由我沒有太過關注，就我我的分析：這類公司的客戶通常是小的創業公司，他們沒有太多的財力去組建本身的測試團隊，而又須要保證本身產品的質量通常會供助於此類平臺或是公司。而稍微有能力的公司都會組建本身的測試團隊，一是出於商業機密和安全考慮，還沒有投入市場的產品就交給第三方來測試，這是不妥的。二是，產品，開發和測試都是本身的團隊，優化和修改起來也比較快捷，而不用等第三方的測試結果。

       這類廣告通常不會有相應的設計思路分析，只會瞭解到有什麼相應的功能 ，酷玄的界面和詳細的報表，這卻是能夠借鑑的。不也不用太介意此類的分享，聽聽便可。

二，    深刻分析，全面測試

       當我看了下午各個會場的分享目錄後，第一感受是：其實你們作的東西都差很少嘛，接口測試，UI測試，持續集成，好像也沒有太多新鮮的東西。可是我也要去學習一下，看一下一樣的東西你們是怎麼作的。聽過以後發現本身仍是有點兒淺薄的，具體表現以下：

（1）接口測試

      一般咱們作接口測試是經過python requests模塊來編寫相關的代碼，加上unittest模塊，HTMLTestRunner來進行檢測和生成報告。若是作的大一些兒，就是編寫接口自動化測試平臺，進行接口文檔管理，測試用例生成，用例集管理，日誌記錄和環境切換等功能。我的感受仍是不錯的，至少比僅僅寫代碼高級多了。聽了搜狗和餓了嗎他們作的接口自動化測試，感受仍是有不少須要考慮的地方：

Ø  環境切換方法的不一樣：我是經過在執行服務器上添加相應的host來進行切換；而他們是經過對測試環境進行相應IP,域名配置，解析請求的DNS來進行環境的切換。

Ø  測試數據來源的不一樣：一般的接口測試數據是經過數據文件，如TestNG的dataprovider或是數據文件XML來提供；固然也有經過mock平臺來提供的。而他們主要是經過mock平臺來提供數據，正向的數據經過mock線上接口，逆向數據能夠修改mock數據提供。也有分析請求日誌來解析相應的測試參數數據，進行進行測試。

Ø  測試用例生成不一樣：一般的接口測試用例都是本身經過相應的編碼語言來編寫的，不過感受目前的測試平臺的開發趨勢和市場上其餘產品愈來愈相似了。操做越簡化越好，經過簡單的點擊幾個，填寫幾個數據就能完成相應的測試操做。因此測試用例也趨向於自動生成，經過填寫參數與預期結果，自動生成測試用例；還有就是他們分享的經過解析線上請求日誌來自動生成測試用例，總之就是操做越少越好。

Ø  後續統計操做：在我平常作的接口自動化過程當中，若是用例出錯會記錄相應的出錯日誌，以便查看報告的時候排查錯誤；沒有作相應的統計工做。如今其餘公司在接口自動化的時候，對報錯日誌執行結果作了相應的統計與展現。

（2）UI自動化測試

      移動端自動化測試，主流仍是經過Appium, Robotium, UIAutomator等開源框架，接口用例也是經過java或是python編寫相應的自動化測試用例。也有經過相應的錄製工具進行測試用例錄製，然後改寫而成，自動化的檢測也是設置相應的檢測點，檢測預期結果。而如去哪兒網的移動端自動化測試，作的就比較有特點：

Ø  用例自動生成，經過相應的測試工具進行測試用例錄製，而後經過相應的框架轉化成具體可執行用例。

Ø  圖片對比驗證：經過設置的檢測點是普通文字，至於圖片只檢測存在與否。而去哪兒則是經過保存屏幕截圖，對比兩個不一樣版本的相同頁面的截圖進行檢測；也能夠對要對比的圖片進行裁剪，然後指定對比的對象。這一點卻是思路奇特，圖片對比仍是比較複雜的。

Ø  後端數據對比：在錄製測試用例的時候，不擔保存相應的屏幕截圖，也保存相應接口的後端返回數據；檢測執行結果的時候，同時對比相關的數據。後端數據經過mock進行保存或是修改相應接口數據，修改接口數據爲異常數據，檢測頁面異常展現。

Ø  測試數據與執行機型對應存儲：在咱們編寫或是生成測試用例的時候，若是有座標定位的時候，每每由於執行機型不一樣而至測試用例兼容性較差。而去哪兒在自動生成測試用例的時候，對測試數據與執行機型作對應保存，執行時候比對機型而去取數據。這點兒作的很是巧妙，值得借鑑。

（3）專項測試要深刻

       在移動端測試的過程當中，對app須要進行專項測試，若是首屏加載時間 ，app下載，安裝時間，用電量等方面進行測試。咱們一般的作法是藉助於第三方工具，或是android studio等進行相關的測試；我沒有作過太多相關的測試，不過好像也沒有了解過太多的其餘方法。

       而騰訊在這方面的專項測試仍是比較厲害的，聽也仍是挺有感觸的：

Ø  安裝包瘦身：他們會從冗餘代碼或是jar包，方法數和代碼混淆，資源優化，極限壓縮和插件化等方面進行優化。這些方面已經超過咱們測試考慮的範圍，但是這些兒確實是優化的最好辦法。

Ø  啓動優化：從UI層優化，避免過分繪製，view延遲加載，佈局不合理，邏輯層優化，本地任務執行，網絡協議優化等方面進行相應的測試以提出優化建議。

Ø  電量測試方法，一般電量測試方法也是很是多的，咱們測試的時候也會用到。不過騰訊仍是提出了一個很是好的方法，直接調用android獲取電量信息的方法，用來展現咱們要檢測的應用的用電量以及獲取大量耗電的方法，此點卻是讓人眼前一亮。

       在咱們之後作專項測試的時候，不能只侷限於表面或是現成的工具；要深刻了解產生問題的緣由或是要測試對象的底層現象。然後再去作相應的信息彙總或是排查，以達到咱們測試的目的，迅速定位問題所在。

三，    結合自身，深入反思

        我作測試開發已經五年了，在工做過程當中也作了很多相關的東西，接口自動化測試，服務自動化測試，頁面自動化測試，測試平臺的開發，解決實際問題的腳本也寫過很多。結合咱們公司如今作的不少東西，也讓我提高了很多，對此我深懷感激。聽了此次大會分享，深入地感受到技術仍是那多麼技術，但是在經過不一樣的思惟方式，能夠設計出很是多獨具匠心的好東西的。同時也深深地感到本身有很多不足之處：

Ø  考慮問題不夠全面深刻。在解決具體的問題的時候，針對問題設計好了詳情的解決方案，也能很好地解決問題。不過對周邊相關的考慮不夠全面，若是沒有對執行數據，出錯信息進行相關的統計或是彙總。

Ø  缺少對困難的挑戰和深刻的探討。在作頁面自動化時候，一直認爲圖片對比比較困難，也就沒有再作深刻的探討，就只是判斷相應的圖片位是否存在。這只是一個例子，還有其餘的方面須要進行反思。

Ø  數據統計和展現方面欠缺。在作自動化測試或是其餘方面測試的時候，沒有作深刻的統計工做，還有就是展現統計結果，在這方面前端知識就比較欠缺，仍是須要設定相應的目標補充相關知識。

Ø  開闊眼界，時常補充新知識。在平時的工做中，因爲需求迭代比較快，積極響應需求，保質保量地完成工做。最近有點兒疏忽關注新知識的發展，這樣很差，致使思惟不夠開闊，對於解決具體的問題仍是有阻礙的，之後得改進。