我現在的工作有一大部分也是app測試，雖然自己是app開發出身，但是在測試上還是跌入了很多大坑，畢竟二者還是有很大不同，所處的角度也是不一樣的。而開發轉測試中，我認為較難的也是一個角度的轉換，以一個開發者的角度去測試，往往會忽略很多問題。 　　在記錄app測試走過的那些坑之前，先總結下app測試的工作主要有哪些： 　　1.功能測試，無論是什麼軟體產品，必不可少的就是功能測試。我們需要測試這款app產品的功能是否完善，是否符合客戶需求，是否符合使用者正常體驗。而功能測試最重要的一點也是測試案例的設計，這個抽個時間單獨總結下。案例設計的是否全面，覆蓋率是否高決定了這款產品功能強弱。作為一名開發，需要在開發過程中考慮邏輯實現中的種種情況，根據不同的情況做不同的處理，而這種考慮往往以正向考慮為主，即使用者在正常使用情況下會進行哪些操作，從而產生什麼樣的問題。作為一名測試不能單單從正向流程考慮，使用者在各種情況下的各種操作要絞盡腦汁想到並設計相應的測試案例，才能保證app功能的完善。因此在app測試流程中要做到： 　　1）需求評審——知道要測試的是什麼，測試的範圍 　　2）案例設計——根據需求文件及產品原型設計測試案例 　　3）案例評審——換一名測試人員對測試案例進行評審，檢視有沒有漏掉的案例場景，評審案例是否正確。 　　4）案例執行——對測試案例執行測試，覆蓋測試案例。 　　2.app客戶端效能測試

。這個效能測試主要關注的引數有：多高的cpu，記憶體，耗電量，流量，還有app的安裝耗時和啟動耗時。其實在實際工作中這個做的是沒有那麼全面的。我們正常測試過程中比較關注的是app的安裝耗時和啟動耗時（wifi下的啟動，4G下的啟動，3G下的啟動）。還有一個需要關注的是運營商的測試，之前曾經遇到的問題是在移動下沒有問題，但是在聯通下就有問題，這個也是需要關注下的，當然這種問題有時候不是開發人員及測試人員能夠把控的。但是像記憶體，流量什麼的是需要特別關注的，在我們的工作中，我們在app中的zip包超過500k的在測試環境是特別彈出提示框提醒的，需要找開發確認這個地方為什麼會需要放置這麼大的檔案。 　　3.適配相容性測試。記得之前在群裡有人問怎麼進行相容性測試啊，然後都一致回答，買買買，買各種型號的手機

，哈哈。在平時的測試工作中，我們公司因為測試團隊是比較大的，因此我們也是會不斷更新市面上主流的機型，但是不可能做到全面的。我們都是在主流機型上測試通過就可以發版上線的，如果遇到生產問題，我們是特別進行處理。藉助真機或者去百度雲測等測試平臺，藉助他們提供的服務復現問題，解決問題。但這種問題解決起來是比較棘手的，像是ios還好說，一般關注ios系統版本及尺寸就可以了，這些問題都可以進行相應的適配。但是安卓裝置由於太過於廣泛，往往處理一些問題還需要聯絡廠商，比較麻煩，因此我認為這類測試不需要專門的進行相容性測試，這樣做的意義不是很大。真要做的話可以找下相關的三方平臺做下。 　　4.弱網路測試。上面也提到過客戶端效能測試的時候要關注安裝耗時和啟動耗時，其中就需要進行弱網路測試。但是在我們實際工作中並沒有進行專門的弱網路測試，原因也是這種測試可控性較差，不穩定，得到的測試結果沒有很大的借鑑意義。因此在我們實際工作，一般是有特殊需求才會進行測試下，但是得出的測試結果也並不理想。我之前進行app開發的時候，會有對不同網路狀況下的不同處理。 　　5.耗電量測試。包括app使用過程中的耗電測試以及後臺執行掛起設定的耗電測試。手機裝置在滿電的時候，這個App能玩多久；App每小時的耗電是多少；App在某個場景掛機10分鐘耗電量是多少等等。 　　6.安全性測試。這個應該說是一個很重要的測試，自己還沒有深入研究過安全測試

，這個涉及到地方就比較多了，安全協議，資訊加密等等。 　　這些是自己實際工作中遇到的一些測試，我認為這個也是根據不同產品從而產生不同的測試，並沒有一個標準規定一個app測試需要進行哪些方面的測試，這個要根據實際需求成本控制等等進行選擇的。 　　來談下app測試中的那些坑。。。 　　1.web，客戶端，服務端三者的恩怨情仇。現在主流的app都不會是純原生的客戶端，而是和web相結合的，那樣在進行測試的時候一定要考慮全面，web的修改，客戶端的修改，服務端的修改，會對哪些地方產生影響一定要理清思路。 　　2.測試環境的使用。測試環境沒有問題不會代表生產環境就沒有問題，產生問題的原因是多方面的，因此儘可能的在測試環境測試全面，不要讓問題出現在生產環境。 　　3.與開發，需求的溝通。這個是比較重要的，一些功能的實現可能在某些細節與需求設計有所不同，在這種情況下不要輕易將問題放過，容易背鍋（血淚教訓）。不能單方面的聽取開發意見或者需求意見，要明確問題是否存在，是否形成缺陷。 　　4.無影響測試。在實際工作中遇到過的一個問題，開發將一個介面修改了，測試人員只測試了一個邏輯中該介面的呼叫，而沒有找下開發問下這個介面到底涉及哪些業務邏輯，這就會造成其它地方的缺陷的產生，這個一定要注意，測試到一個bug，不要盲目檢視修改完成後這個業務能否正常使用，一定要了解到他到底修改了什麼，根據修改的東西再去設計測試案例然後執行。 　　以後還會遇到很多坑。。。。。到時候再補充吧