自動化測試

自動化測試主要是為了解決專案中頻繁的迭代回歸，每次執行手工測試耗時耗力，用於解放手工測試者在這部分業務邏輯上面耗費的時間，轉而投入到更有用的測試，比如異常測試，隨機測試，對新需求的測試。

分層的自動化測試思想：

單元測試（unit）：它可以通過mock框架，模擬各種異常場景，外部依賴最少，且可以做到測試粒度到最小的一種測試方法。也因為依賴少，可方便隨時隨地執行，也讓問題排查很簡單。這是一切測試的地基。

介面測試（service）：這裡要求測試人員對系統的結構和系統間的排程非常清楚，同時要了解介面邏輯關係，否則介面測試**很容易遺漏一些異常場景。這一層由於含有一些業務邏輯和多介面的乙個整合，所以相對單元測試來說，多了一些外界依賴，導致問題定位不會有單元測試層那麼準確。因此投入會比單元測試多一些。

頁面測試（ui）：是常見的黑盒自動化測試場景。它最接近使用者真實場景，也容易發現問題，但它的實現成本最高且太容易受外部依賴，影響指令碼成功率，所以處在金字塔的頂端，但它不是金字塔的全部。自動化測試的劣勢，其中80%都是因為ui自動化。

以上就是分層自動化的主體三層，由此可見，分層自動化測試倡導的就是，將系統分層，不同層次用合適的自動化方法進行測試的一種測試策略

什麼樣的專案適合自動化測試？

1、專案周期長

2、需求變更不頻繁

3、自動化測試指令碼可以重複使用

4、系統中的測試物件基本可以正常識別

一般滿足上面三個條件就可以進行自動化測試。

影響自動化測試能夠正常執行的一些因素，所以專案一開始時就要制定好測試計畫，確認專案是否適合執行自動化測試：

a>專案進度壓力大;

b>被測系統軟體開發不規範，穩定性差

c>編寫指令碼的測試人員自動化技能不足

d>需求頻繁變更

e>專案團隊資源不夠

自動化測試用例的設計原則：

1、自動化測試用例的範圍往往是核心業務流程或者重複執行率較高的

2、自動化測試用例的選擇一般以正向為主

3、不是所有的手工用例都可以用來執行手工用例

4、自動化測試用例必須要保證可以回歸原點，執行完後讓被測系統狀態回歸初始狀態，保證下一次的正常秩序

5、自動化測試沒必要每一步都寫預期結果，只有準備在測試指令碼中設定檢查點的步驟才有預期結果，如果每一步都寫預期結果，會有非常大的**量