自動化測試在測試部門的策略

【就本公司的一篇論述,每個公司不同情況也不同】

先說軟件測試工作的本質意義是什麼?保證軟件質量?肯定不是!測試不能保證軟件質量,開發纔是。軟件測試的目的是展示軟件質量狀況.

自動化測試的概念:

計算機軟件,替代人類簡單記錄、識別、分析結果的工具,在軟件過程中,爲了保障軟件的可靠性、可用性、健壯性以及高性能,便出現了“測試自動化”這個概念

似乎自動化測試是個趨勢,把人爲驅動的測試行爲轉換爲以機器驅動爲主,由測試人員根據測試用例規程一步步的執行動作驗證結果,同時,還能節省時間和測試效率。但是,自動化測試的收益並不是看上去的那麼美,以筆者這些年的自動化測試經驗和結合大公司的同事朋友交流的來看

自動化的弊端:

  • 人員
    • 較高的學習成本,同時核心人員的流失會導致整個自動化測試項目的工作停滯
  • 需求
    • 頻繁的需求變更以及UI變化給測試腳步的維護成本帶來直線上升,目前android測試國內大都基於UI測試方向,這是顯而易見的弊端
  • 成本
    • 收費的工具可能好用點,但是也需要學習,且市場上的人員大都來自開源軟件,免費的則需要二次開發
    • 錄製回放的工具最不靠譜
    • 首次運行的腳步最費成本,後期由於需求以及UI改動的成本是最關鍵的部分,即開發和維護成本都很高
  • 時間
    • 短期項目,自動化收益會遠遠大於成本
  • 不是所有測試case都能自動化
  • 自動化不是所有測試階段都適合
  • 自動化也需要專業的設備支撐,比如功耗測試,溫度等硬件相關的
  • 發現的問題會非常少,大部分在運行一次就發現了(穩定性測試除外)

自動化的優點:

  • 速度:跑的比人工快,速度優勢
  • 重複性:跑的比人工測試多,覆蓋的與人工不同,多在重複性
  • 長時間:24小時可以執行,人不能不睡覺
  • 可能會省錢

自動化測試其實就是一種測試手段而已,測試手段部分初級中級或高級,也不是那麼高大上,完全不需要仰視或附和,手工測試也是行之有效的測試手段,跟自動化測試本質上無區別。雖然說自動化測試並不是看上去的那麼高大上,但是有個好處,就是幫助測試人員有機會深入瞭解軟件。

測試講究的是測試全面性,所以自動化測試的考慮要從它的適用性來考慮,不能搞自動化而上馬

自動化的適用範圍:

迴歸測試,兼容性測試,穩定性測試,壓力測試,性能測試,接口測試,端到端測試

迴歸測試: buildcheck/smoke測試等需要做build檢查結果,快速給個反饋,強調的是反饋及時,不是覆蓋全面,是非常basic的功能

兼容性:代表的是Android CTS,這裏的兼容性除了CTS之外,還要檢查國內的TOP100應用和遊戲測試

穩定性:長時間反覆24小時不間斷執行,可以發現應用或系統在長時間運行後的累積問題,諸如內存泄露等

壓力測試:針對接口或應用的某一關鍵動作進行的大批量或快速的動作序列,android上用monkey隨機性測試有效發現彌補人工發現不了的空指針或其他異常情況。

性能測試:主要是服務器接口性能的測試,通常使用loadrunner/jmeter等工具模擬高併發測試服務器性能能夠承受到多少,終端的有CPU,內存的檢測

接口測試:主要用於RESTFUL API接口測試,對端到端應用比較適合,對後臺管理系統等也比較適合的測試類型,脫離了UI是非常好的測試。

端到端的測試:是結合接口測試以及終端測試的特點,讓兩者有機的結合起來

自動化測試的趨勢:

自動化測試要結合自動化持續集成,讓測試持續進行

測試用例設計:要根據項目情況,哪些適合提出來做自動化,不能讓自動化成本比人工更高

代碼走查(靜態檢查):

開源的有CheckStyle,PMD,FindBugs,靜態的商業大名鼎鼎的Coverity,還有Fortify等

接口測試:

通常需要接口文檔,常用與端到端的測試過程中

用戶界面:

這個通常最難,並不是難寫,是難於維護,變化太快,成本太高

所以目前很多公司爲了降低成本引入了“遍歷測試” 即遍歷菜單樹的方式,比monkey壓力要小,並且只點擊有意義的控件,一般用於兼容性和穩定性檢查。

 

目前終端自動化測試的有:

build check/smoke等迴歸測試,應用兼容性測試,壓力monkey測試,MTBF穩定性測試,應用壓力測試

半自動化(依賴工具和人工運行和檢查)的有:

功耗測試,續航測試,性能測試

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章