「乾貨」5種最常見的移動應用程式測試錯誤方式，如何規避？

想你的應用程式沒有bug? 注意了,近一半的問題都是客戶發現的。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

為什麼不是開發人員發現這些缺陷呢? 都怪糟糕的測試，實際上一些流行的測試策略是會破壞你的應用程式的。

幸運的是糟糕的測試是很容易避免的。這裡有五種最常見的移動應用程式測試錯誤方式以及如何去做的例子。

1、公測

當應用程式進行公測，開發商釋出警告，啟動程式，看發生什麼。但本質上，實際使用者做了beta版的測試者。

為何要避免

有幾個理由可以說明公測是危險的，首先，你無法控制使用者體驗。你只是釋出了一個應用程式，但是不知道如何響應客戶動作，網路環境以及市場需求。 這是一個巨大的風險，如果你的使用者體驗糟糕的話，你的應用程式口碑和你的品牌形象都會受到傷害。 其次，公測沒有一個系統的方法來記錄和解決問題。即使再忠實的客戶也不可能讓他們用一致的方式報告崩潰和其他問題。 一些開發商用僱傭測試人員來為他們的應用程式做出反饋，來作為變通手段。

那麼問題是？

所有的應用程式測試者，無論是有組織的使用者還是眾包僱員，都是在不受控制，可變條件下使用應用程式的。導致在德國連線3G網路當機的原因與在巴西使用LTE導致當機的原因並沒有什麼關係。 所以不要把你的程式拋在那些有可能你無法跟蹤發生了什麼的地方，更不用說解決那些肯定會出現的問題了。

2、接入點對映

歡迎使用接入點對映，一個理論上確實非常好的測試想法。

開發商僱傭測試人員（哦哦，我們已經排除了一個壞的開始）來進行公測。

但是無論何時何地，測試者都是透過繞特定區域街道開車或步行，來觀察在不同位置以及網路中的執行情況，而不是使用應用程式。

為何要避免

接入點對映要比公測稍微可控，但是條件仍然不理想。

即使你僱傭了大量的測試人員在他們自己所在城市和社群進行接入點對映測試，但他們終端使用者體驗還是對應他們各自的條件。

在應用程式使用中涉及的位置，裝置以及網路建立的一個個個性化的體驗，只適用於這個人在特定的某天時間。

換句話說，從在週三下午的托萊多使用3G網路進行應用程式測試的Bob那裡收集的任何資料，都不適用於在週三上午舊金山使用Wi-fi連線網路的Suzie。

接入點對映測試是一個卑鄙的測試方法，因為能感覺到不同條件下真實人的真實資料是不錯的，問題是，這些條件不能適用於所有使用者，導致這個方法只能是部分有效。

3、去頻寬

一旦你意識到任何形式的公測都是不可依賴的時候，就是進入實驗室模仿在受控環境條件下的真實條件的時候了。

許多開發商以及企業進入測試實驗室但是走的不夠遠，進行所謂什麼“部分模擬測試”。模擬獲取了一些，但不是所有影響應用的真實世界條件。

為何要避免

部分模擬往往忽略了重要的環境因素，建立不完整的測試並沒有捕捉到全方位的使用者體驗。

考慮到網路頻寬，應用程式通常是在靜態頻寬的條件下進行測試，但現實生活中，頻寬卻很少是靜態的。使用者可以在 3G 和 4G 網路，4G 網路和 Wi-Fi 之間互相切換來感受不斷波動的訊號強度。

延遲也是一個很重要的因素——對於很多應用程式效能這也是主要決定因素。與移動環境的其他方面一樣，延遲是高度動態的。這取決於很多因素，如路由器等網路裝置間的訊號交換，編碼技術，和網路協議。

既然現實世界的移動環境是如此的不同，那麼在實驗室中建立靜態條件來測試移動應用程式還有一定價值的。

4. 忽略抖動

在一個移動應用程式測試環境中抖動很難作為代表，靜態變數的頻寬或延遲更容易建立。因此一些測試淡化抖動值。

為何要避免

不考慮流媒體需求，冒著嚴重到令人失望的終端使用者體驗的風險（更不用說失去潛在的收入和推薦）去測試你的應用程式。

當評價應用程式是如何執行的時候，需要考慮兩個關鍵領域：如何讓程式自身進行操作以及如何在特定網路上進行程式操作。換一種方式，忽略抖動就意味著忽略網路效能。

歸功於頻寬，影片特別容易抖動，流媒體質量很大程度上受位置，網路型別，服務提供商和其他等因素的影響。

5. 純功能檢測

純功能檢測是開發者只測試應用程式那些功能性的元素，並沒有將效能納入到測試過程中去。

為何要避免

一個移動應用程式的成功不單隻基於功能。

一個應用程式的功能必須做什麼（就是說，當某個功能被選中或者某個按鈕被按下時發生什麼）。一個應用程式的執行，另一方面，是要做的怎樣（就是說，在一個特定網路上使用時要如何快速的反應）。

測試當使用者發出命令時會發生什麼是功能測試，測試應用程式如何快速響應要求，從另一方面是效能測試。

為獲得整體應用程式能力的一個三維檢視，功能和效能兩個都必須進行測試。

你當然希望應用程式功能正常，測試功能而不測試效能將永遠得不到你的應用程式可能（或不能）給你的全部畫面。正如我們迄今所看到的，整體應用程式的效能很大程度受外界因素的影響，如網路效能。

這就意味著，為建立最準確的測試可能，功能，效能和外部的影響都要考慮在內。

一定要考慮一下的內容：

• 什麼網路條件是被虛擬化了的？

• 那些條件是基於實際網路的麼？

• 你模擬了多個網路條件了麼？

• 你代表的是分散式使用者群麼？

最後一點至關重要，功能測試往往忽視需要虛擬化不同使用者的不同限制條件。

基於雲的移動應用程式測試也應謹慎，請記住，功能雲測試只是提供一個單一定位視點，並不代表整個使用者群。雲測試也不能對真實的使用者如何在網路上使用應用程式給出準確的畫像，因為雲連線往往比家庭或者其他網路的速度更快。

要採取哪些措施

所以如果要公測的話，靜態頻寬測試，部分模擬，純功能測試要避免。那怎麼在往市場推出應用程式前進行準確的測試呢？

1、做功課 

在測試你的應用程式前有很多工作要做。 你首先要非常瞭解影響功能，效能和使用者體驗的各種因素。 研究網路條件，基礎設施，使用者位置，以及一旦開始就需要考慮在內的其他環境條件。 

對於如何，何時，何地使用你的應用程式才能幫助你建立一個虛擬的能準確代表真實世界使用者體驗的測試環境，要有一個徹底的三維理解。

2、去虛擬 

建立虛擬條件包括前一步中發現的所有因素。 建立包含使用者在現實生活中所經歷的各種各樣的變化的虛擬網路條件是非常重要的。 

你建立的虛擬網路與功能效能工具應該能夠無縫整合，用來進一步提高測試的真實性與可靠性。

3、分析與最佳化

接下來是分析你的結果的時候了。尋找功能和效能兩方面的故障，以及可以歸因於網路故障的任何錯誤的解決方法。

最後，開發系統來測試分析最佳化你的應用程式。

做正確的移動應用測試

為了確保你的移動應用程式的效能最佳，關鍵是要建立一個能準確反映現實世界條件的測試環境。

• 不推出未經事先測試的應用程式

• 不要浪費時間與金錢在接入點對映上

• 請記住現實世界中的頻寬是可變的

• 考慮影片網路可能會影響應用程式的功能和效能

• 永遠要對功能和效能進行測試

• 深入研究影響你終端使用者的環境因素

• 建立三維，真實世界的測試環境

• 分析你的測試結果，並持續最佳化系統

考慮到在現實條件下你的應用程式的功能和執行，透過模擬所有這些虛擬測試條

件，你就可以準確有效的預測你的應用程式一旦推出使用者體驗如何。

最後：

可以到我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！