關於自動化測試的些許思考

以前的博客，有介紹過關於UI和API自動化測試的一些內容，也聊了些自動化測試可能遇到的挑戰以及常見的一些自動化測試框架。

我我的專職作自動化測試有一段時間了，期間看了不少資料，遇到了不少「坑」，也學習到了不少技能，能夠說是收穫滿滿。

這篇博客，聊聊我我的對自動化測試的一些延展思考（只列出思考點，具體分析後續更新）。。。

以前博客的傳送門：

淺談UI自動化測試

淺談接口自動化測試

聊聊自動化測試框架

聊聊自動化測試路上遇到的挑戰

 

1、爲何要開展自動化

系統愈來愈複雜，線上問題愈來愈多，手動迴歸效率低

上線時間長，構建失敗率高，代碼提交頻繁，質量不高

覆蓋率，仍是覆蓋率

性能問題愈加突出

安全問題冒頭

 

2、功能測試的不足之處

手動測試的偶然性和不肯定性

手動迴歸工做量大，覆蓋率不足

發佈上線的產品質量沒法保障，一切靠評估

生產事故致使加班，被迫快速「迭代」來解決問題

測試粒度不夠、業務場景覆蓋不足

用例等文檔的維護及時性、有效性不足甚至缺失

解決方案：從數據、流程、環境多個方面來解決問題

 

3、開展自動化須要面對的問題

一、集成的複雜度

多協議支持和相互調用

多個系統之間的集成

多個測試執行任務和機器部署以及調度管理

不一樣環境、平臺的帳號管理

二、溝通成本及複雜度

前端、後臺、運維、架構、DBA之間的溝通成本

解決重複造輪子的問題

變更通知須要及時溝通（開發&測試、前端&後臺、依賴API的變更、不一樣業務線）

三、安全性問題

敏感信息的配置脫敏

端口、服務的安全性

四、流程問題

流程是否標準化

是否有統一的case管理和維護流程

是否有統一的項目管理流程

是否有自動化測試規範和最佳實踐

五、環境獨立和隔離

版本一致性

開發分支、開發集成————-docker、鏡像

測試分支、測試集成———— docker、鏡像

環境隔離、權限管理：開發、測試、UAT、灰度、生產

配置、打包、提交、發佈自動化，專人化

依賴高、實現難度大成本大的模塊：提供mock對象

六、自動化實施管理

日誌管理

腳本、日誌定備防災

自動化測試任務分發執行和測試報告

自動化的管理流程

七、數據構造

同步生產數據

備份還原數據

特徵數據查找

數據構造平臺

PS：腳本化、批量化、避免手工輸入的不肯定性

八、服務治理

進程管理

日誌監控

版本跟蹤

專人處理

 

4、如何解決上述的問題

一、團隊

CI和CD環境的搭建，管理、流程執行

冒煙不經過打回

當即修復失敗的構建

定時溝通，「吐槽大會」

二、開發

靜態代碼檢查

肯定合理適宜的開發規範

提升代碼構建的頻次

單元測試不經過不提交

定時code review

認真填寫changelog

分支、集成合並必須迴歸

三、測試

豐富測試類型，好比對比測試、性能測試、安全測試等

提升測試響應速率

提升迴歸覆蓋率

提升迴歸效率

提升穩定性

下降回歸成本

 

5、創建評價模型

一、團隊

根據問題嚴重程度設定響應和處理時間、速率

設定合理適宜的評價模型和機制，適時調整

二、開發

不一樣階段的CI頻率

code review頻率、覆蓋率

千行代碼BUG率

尋找你的第83行代碼

三、測試

不一樣階段不一樣測試類型的佔比、覆蓋率、測試時間

優先級劃分、構建穩定性

線上BUG率

 

6、自動化實施的原則

針對重點業務進行迴歸

針對穩定業務（環境、需求）較早投入腳本開發，減輕後期維護成本

自動化爲了保證功能完成可用，而不是多發現缺陷

自動化沒法減小人力成本，而是爲了加快測試結果反饋速率，提高測試質量

錄製回放只是雞肋，可視化並非一個很好的作法

儘量讓開發參與自動化，而非功能測試人員

 

7、總結

部署自動化

測試服務化

完善質量保障和評估體系

提升執行和監管機制

 

8、延伸

單點登陸、權限管理

測試服務化

 

以上爲我我的對自動化的一些理解和思考，若有更好的建議，請評論指出，不勝感激。。。