移動app如何進行自動化和探索性測試

在測試設計時最主要依據的就是測試金字塔的測試結構。如果在專案臨近發布才開始測試並發現缺陷，這樣修復缺陷的成本就會很高，專案的進度也會很不確定。所以，就開發階段來說，如果把測試分層，在不同的開發階段都進行測試，能很大程度上緩解這些問題。

測試分層的優勢有以下幾點：

1．測試的成本

單元測試的開發成本要遠低於使用者介面測試，如果在使用者介面的測試中發現缺陷，修復缺陷的成本也是遠高於通過單元測試和元件測試的成本。

這裡的成本不單純是開發人員修復缺陷所需要的資源和時間，還包括缺陷修復後測試人員進行回歸測試所需要的資源和時間，以及專案延期等其他專案成本。

2．測試的效率

單元測試能很快地驗證很小的功能或者方法，且執行時間短，反饋更為及時。

3．缺陷定位的難易

單元測試失敗後，測試人員能夠很容易知道是被測試的特定功能或者方法不正確；而如果是使用者介面的缺陷，測試人員就需要花費更多的時間來進行排查，確定出現問題的功能模組，最後再進一步發現需要修復的功能和方法。

4．反映真實的業務需求

單元測試無法從全域性觀的角度了解系統模組之間的互動，也無法通過方法的組合幫助使用者完成業務目的；而由於使用者介面的測試描述的是從使用者角度出發的使用者使用場景，因此可以更容易地闡述使用者的行為和業務需求。

5．更加接近業務

使用者介面測試描述測試的層級更高，所以更接近業務；單元測試描述測試的層級更具體，所以更接近於實現。

從測試金字塔分層來看，不同層級的測試都很有必要，而我們也需要根據不同測試所處的層級及其特點來設計測試。

另外，實際測試設計時採用的測試金字塔具有更多更細節的分層。高層級的測試和低階別的測試相比，抽象程度更高，測試執行的時間更長，與更多的系統和模組有互動。反饋的週期更長，接近缺陷的成本也更高。

單元和元件測試的測試驅動開發tdd的基本迴圈步驟是：

1，測試失敗；

2，測試通過；

3，重構；

由於測試驅動開發是針對單元和元件測試所使用的開發技術，所以在進行單元和元件測試時，測試人員只需要了解並評審開發人員在單元和元件測試中覆蓋了哪些場景，並不需要完成其實現。

1．探索性測試是針對於指令碼測試提出的，但是兩者並不是針鋒相對的，而是相輔相成的。探索性測試，指令碼測試和自動化測試之間可以相互轉化，相輔相成。

2．探索性測試要求測試人員在執行測試時，如同使用者旅程一樣，首先設定好測試目標，然後規劃出一段時間，使用啟發式測試策略模型，通過測試人員的創造性思維，採取不同的測試路徑，來達到測試目標的測試方法。