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


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

我個人專職做自動化測試有一段時間了,期間看了很多資料,遇到了很多“坑”,也學習到了很多技能,可以說是收獲滿滿。

這篇博客,聊聊我個人對自動化測試的一些延展思考(只列出思考點,具體分析后續更新)。。。

之前博客的傳送門:

淺談UI自動化測試

淺談接口自動化測試

聊聊自動化測試框架

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

 

一、為什么要開展自動化

系統越來越復雜,線上問題越來越多,手動回歸效率低

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

覆蓋率,還是覆蓋率

性能問題越發突出

安全問題冒頭

 

二、功能測試的不足之處

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

手動回歸工作量大,覆蓋率不足

發布上線的產品質量無法保障,一切靠評估

生產事故導致加班,被迫快速“迭代”來解決問題

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

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

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

 

三、開展自動化需要面對的問題

1、集成的復雜度

多協議支持和相互調用

多個系統之間的集成

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

不同環境、平台的賬號管理

2、溝通成本及復雜度

前端、后台、運維、架構、DBA之間的溝通成本

解決重復造輪子的問題

變動通知需要及時溝通(開發&測試、前端&后台、依賴API的變動、不同業務線)

3、安全性問題

敏感信息的配置脫敏

端口、服務的安全性

4、流程問題

流程是否標准化

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

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

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

5、環境獨立和隔離

版本一致性

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

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

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

配置、打包、提交、發布自動化,專人化

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

6、自動化實施管理

日志管理

腳本、日志定備防災

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

自動化的管理流程

7、數據構造

同步生產數據

備份還原數據

特征數據查找

數據構造平台

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

8、服務治理

進程管理

日志監控

版本跟蹤

專人處理

 

四、如何解決上述的問題

1、團隊

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

冒煙不通過打回

立即修復失敗的構建

定時溝通,“吐槽大會”

2、開發

靜態代碼檢查

確定合理適宜的開發規范

提高代碼構建的頻次

單元測試不通過不提交

定時code review

認真填寫changelog

分支、集成合並必須回歸

3、測試

豐富測試類型,比如對比測試、性能測試、安全測試等

提高測試響應速率

提高回歸覆蓋率

提高回歸效率

提高穩定性

降低回歸成本

 

五、建立評價模型

1、團隊

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

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

2、開發

不同階段的CI頻率

code review頻率、覆蓋率

千行代碼BUG率

尋找你的第83行代碼

3、測試

不同階段不同測試類型的占比、覆蓋率、測試時間

優先級划分、構建穩定性

線上BUG率

 

六、自動化實施的原則

針對重點業務進行回歸

針對穩定業務(環境、需求)較早投入腳本開發,減輕后期維護成本

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

自動化無法減少人力成本,而是為了加快測試結果反饋速率,提升測試質量

錄制回放只是雞肋,可視化並不是一個很好的做法

盡可能讓開發參與自動化,而非功能測試人員

 

七、總結

部署自動化

測試服務化

完善質量保障和評估體系

提高執行和監管機制

 

八、延伸

單點登錄、權限管理

測試服務化

 

以上為我個人對自動化的一些理解和思考,如有更好的建議,請評論指出,不勝感激。。。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM