您好,登錄后才能下訂單哦!
一、首先,需要分析當前項目是否適合自動化測試:
測試需求明確,不會頻繁變動
回歸測試為主的項目
軟件系統界面穩定,變動少
每次迭代需要在多平臺(或多OS、多Browser)上運行重復的case。
軟件維護支持周期長
手工測試無法模擬的場景。如壓力測試、并發測試等
具備基礎的自動化測試平臺
二、以下是曾經參與過的一個項目的自動化測試框架
實現了自動更新代碼、編譯、打包、部署、重啟服務、定時執行腳本任務,日志報告輸出,自動發送郵件通知。
在自動化開始前需要確定預期,需要達到怎樣的目的。而不是抽象的減少人力成本,盡可能多地發現Bug或節省時間等等。自動化測試應該是發現那些可以被工具化自動化的重復性活動而后實現的,并非100%的Case都可以自動化,測試人員的經驗,邏輯判斷和探索性的測試方法都不能被有效自動化。
在一般的項目中,需要保證被測版本的基本質量,可以進行大量的功能測試和壓力測試。
(1)發現環境層級的缺陷。
項目系統測試階段發現的很多缺陷,都會聽到開發人員自測時沒問題的,甚至在本地測試時無此缺陷 ,直接將Bug打回,標注為無法重現。這就是環境問題了,曾經遇到過一個一級菜單點選時導致子菜單錯亂的問題(與其他一級菜單的子菜單混淆顯示了)。經排查才知是,開發將菜單的坐標值寫死了,導致換環境后無法正常識別菜單信息。這是典型的環境問題,只有通過復測才能發現。另一種就是開發自測時是在本地,而自己機器上利用管理員權限部署了一些安裝包或工具,自測時也無法清楚地知道被測版本是否依賴了這些包或工具。而部署到測試環境時才發現一些問題。類似于以上的問題如果及時構建了被測版本,且自動執行了基本功能,會在正式測試前發現這些環境問題,而不是等到系統測試階段才去排查 。
(2)盡快發現集成階段的錯誤。
集成測試階段的缺陷若未暴露出或不影響到正常流程,無法確定錯誤是哪個開發人員負責的模塊,同時開發人員因時間問題,不能測試出大部分的潛在的集成缺陷 ,導致部署到系統測試階段暴露出的錯誤,無疑更增加了開發測試的時間。如果每次構建都可以自動化執行到基本功能 ,使開發能及時地發現集成錯誤 ,同時也可彌補單元測試的不足,快速提供系統級的測試反饋。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。