UI自動化測試、介面測試等自動化測試策略
- 2019 年 12 月 25 日
- 筆記
內容梗概
1、介紹UI測試、介面測試、單元測試主要內容
2、每種測試花費時間討論
UI測試【Selenium】
UI測試是最接近軟體真實用戶使用行為的測試類型。通常是模擬真實用戶使用軟體的行為，即模擬用戶在軟體介面上的各種操作，並驗證這些操作對應的結果是否正確。
介面測試【API測試】
API測試，主要針對的是各模組暴露的介面，通常採用灰盒測試方法。首先以黑盒方式設計如何調用API的測試用例，同時在測試執行過程中統計程式碼覆蓋率，然後根據程式碼覆蓋率情況來補充更多、更有針對性的測試用例。
單元測試
單元測試，屬於白盒測試的範疇，通常由開發工程師自己完成，越早發現缺陷其修復成本越低。
每種測試的優缺點
一、UI自動化測試
大家所在公司都屬於互聯網公司，最大的特點就是快——產品需要不停的迭代，迭代時間基本在15天左右。
UI自動化測試的優點是，能夠實際模擬真實用戶的行為，直接驗證軟體的商業價值；缺點是用例的維護和執行代價很大。另外，UI自動化測試的穩定性問題，是長期以來阻礙GUI測試發展的重要原因。
在快速迭代的情況下，頁面的改動可能會很頻繁，而UI自動化測試本身基於頁面元素，前端小小的改動可能需要測試的大大改。
二、介面測試
相比於UI自動化測試，介面測試更穩定，更具有價值。
- 效率。介面測試是通過測試數據驗證請求【request】與響應【response】是否符合預期。因此，介面測試開發和調試的效率會比ui自動化測試高很多。
- 穩定性。如果介面改動，那基本屬於業務重新設計。所以介面測試用例執行的穩定性很高。
- 實用性。UI自動化測試驗證的主要是頁面顯示，而介面測試驗證的主要是數據。在當前開發水平下，功能測試基本可以完全驗證頁面顯示的問題，所以UI測試有點類似於「這些沒問題了，為了保證一直沒問題，所以要寫UI自動化，每天去執行」。介面測試則是對介面返回數據的驗證，開發在開發新的介面時涉及到介面互相的調用，中間難免出現比如數據類型、key-value不匹配的情況，因此在實用性考慮，介面測試實用性更高。
三、單元測試
船長所在的互聯網公司單元測試是由開發完成的，在時間緊張的情況下，我們一般會出一個開發自測文檔，只需要開發完成小量的單元測試設計。事實也是如此，開發因為任務在身，寫好介面後大多不願意寫大量單元測試。所以單元測試需要根據公司不同而定。
時間討論
鑒於上述原因，我們在做非功能測試時，可以利用UI自動化測試，覆蓋產品主要或者說關鍵流程【包含兼容性測試】，也就是說只要保證主要流程不出錯，剩下的即使有了問題也不會影響產品的正常使用。把時間更多的放在介面測試用例的設計和實現上，保證數據的準確性。單元測試則可以根據公司情況選擇時間分配。
