自動化測試想要順利開展,管理者需要做具體的規划。下文是之前為自動化測試項目啟動會梳理的思路,算是一個草稿。筆者在自動化開展工作上也是一個探路者,希望在這方面有成功經驗的同行不吝賜教。
本文檔要闡釋的問題
-
自動化測試開展的必要性(自動化測試要解決的問題,自動化測試能做哪些工作?預期收益)
-
自動化測試要哪些投入,人、時間和資源。如何分工?
-
自動化測試開展的里程碑,輸出物
-
自動化測試要如何跟我們現有流程相結合
-
從哪些方面避免自動化測試工作的失敗? 需要避免的陷阱
-
自動化的測試目標,測試的用途是什么?怎樣幫助發現程序錯誤?發現什么程序錯誤?測試需要理解產品的用戶領域嗎?
-
測試自動化的目的
-
迅速監測出新版本中的不穩定變更
-
盡可能迅速暴露回歸程序錯誤
-
快速報告問題,因為這會使程序錯誤修改更容易
快速修改會使代碼穩定,使代碼穩定會節省時間(不會有多人在相同程序錯誤上浪費時間),並促進通過重新分析或者其他工作改進代碼結構,並解決不穩定代碼問題。如果代碼基礎大體是穩定的,並有很強的自動化測試包,則程序員可以嘗試以較低的風險做更大的變更。項目團隊還可以通過調整產品的范圍和發布時間,迅速抓住市場機會。
以下是加速開發的兩個例子:
自動化冒煙測試:在有限的時間內,廣泛的檢驗產品的功能。如果關鍵功能不能正常運行,或關鍵程序錯誤還沒有被清除,測試小組就不必浪費時間安裝或測試該版本了。解決這些問題對程序員來說也是同樣緊急的事情。
自動化單元測試:這些測試也會使測試過程流暢、避免回退,並保持開發動力。這些測試有更大的測試集,針對的是被測產品功能中的下層功能和類。
自動化措施和冒煙測試的最大價值,在於可以由任何人在任何時候運行。作為開發過程的一部分,自動的運行這些測試。開發這樣的測試有助於個體程序員創建一些只包含了一個或者少量變更的微版本。如果其中一個微版本失效,程序員會知道應該檢查什么地方。如果微版本沒有問題,會向程序員提供更大的版本,其中包含了所有程序員包含的所有的變更,這種版本出現問題的可能性也更低。這對於項目非常有好處。
自動化測試要做什么?能做什么?
POS
功能回放測試 自定義腳本在真機回放; 詳細的日志、截圖、屏幕錄像。
負載測試: 例如模擬幾百上千人同事使用被測軟件;
性能基准測試: 通過自動化測試,在每次運行時都捕獲時間度量參數。通過收集這些度量參數,按時間順序觀察,就會發現性能退化現象。 資源利用基准,如內存或外村的使用,也可以通過同樣的方法獲得。
深度性能測試 精准獲取App多維度性能參數; 模擬典型使用場景及狀態; 全面獲得啟動時長、電量、流量、CPU、內存等。
耐力測試: 被測系統長期運行,用於發現內存泄漏、棧破壞、指針越界和類似的錯誤 配置測試 適配各種機型,同時捕獲性能數據; 記錄測試過程中完整日志、截圖、錄像; 捕獲CPU、內存、流量、電量等性能數據; 定位閃退、crash、ANR等問題。
安全漏洞掃描 掃描權限漏洞、靜態漏洞、運行漏洞等。 組合錯誤 競爭條件
VM后台、SYS
以后補充
windows pos
以后補充
接口自動化
參考接口自動化實施方案
自動化測試應用階段
接口自動化
冒煙測試,系統測試,線上回歸(監測),詳情參考接口自動化實施方案
UI自動化
自動化冒煙測試,自動化單元測試,系統測試,線上回歸(監測)
單元自動化
后期規划
自動化測試環境
壓測、自動化、本機
自動化測試規划-里程碑
任務(android) | 時間 | 責任人 | 里程碑 | 輸出物 |
---|---|---|---|---|
自動化用例篩選及評審 | 2天 | 遲 | 否 | 《自動化測試用例列表》 |
新增自動化用例編寫及調試 | --- | --- | --- | |
線上、預上線自動化測試賬號、測試數據准備 | --- | --- | --- | |
自動化框架使用指導文檔及培訓 | --- | --- | --- | |
自動化測試套的規划及實現,區分冒煙、全功能、性能基准等 | --- | --- | --- | |
自動化執行(各個設備×各個版本的性能基准數據) | --- | --- | --- | |
框架維護及優化 | --- | --- | --- | |
知識積累總結 | --- | --- | --- | |
框架編寫、框架維護、腳本編寫、測試執行的標准化、規范化 | --- | --- | --- |
任務(接口) | 時間 | 責任人 | 里程碑 | 輸出物 |
---|---|---|---|---|
預上線賬號准備、接口測試數據准備審 | 2天 | 遲 | 否 | |
測試用例編寫 | --- | --- | --- | |
接口自動化使用文檔及培訓 | --- | --- | --- | |
接口自動化執行根據實際情況和回歸情況 | --- | --- | --- | |
框架維護以及優化 | --- | --- | --- |
測試套規划
跟隨功能測試用例的測試套進行。良好的測試套件有多方面的用處:
-
良好的測試套支持對產品新版本的測試;
-
良好的測試套在新的軟件平台上可以很方便的驗證產品的功能;
-
良好的測試套支持每天晚上開始的軟件每日構造過程;
-
甚至開發人員在代碼 check in 之前,用良好的測試套驗證代碼的正確性。
項目討論-自動化覆蓋率
-
項目中符合自動化測試的部分有哪些?(目標和范圍 scope, 准入准出標准)
1. 穩定的需求點、變動較少的頁面2. 每日構建后的測試驗證 daily build3. 比較頻繁的回歸測試4. 需要在多平台上運行的相同測試案例、組合遍歷型的測試、大量的重復任務
-
自動化用例在整個項目的測試用例的覆蓋率
1. 一般的要求 50% +2. 重點的要求 80% +
-
根據項目的具體要求,變動特別大的項目需要額外單獨考慮覆蓋率
-
根據項目中的歷史bug,按照bug重現步驟編寫用例
-
根據測試用例,評估可以自動化的部分
-
在自動化測試時考慮什么樣的程序錯誤沒有被發現
團隊建設 崗位職責
建立自動化測試的組,理想狀態下有4個人員,測試開發、中高級自動化測試工程師、2個初級自動化工程師;目前有2個人,未來還會在組內培養2個(兼職)。
測試經理:
在開發編碼之前,對測試自動化作了整體設計,推動測試自動化開發的順利開展
識別並修改測試套中的所有問題
規划自動化方向,提供需求,如要求自動化工程師為某項測試任務研發工具、腳本
測試開發:
基本工作:
自動化框架的建設,確定自動化框架的設計模式、第三方代碼工具的封裝、中間公共模塊的設計和調用
測試用例、測試套件的管理和執行
測試報告和測試結果的輸出(文件輸出和郵件通知)
提供自動化測試程序的安裝文檔和使用文檔。
保證自動化測試是符合一般測試執行人員的思維習慣的
長期規划:
搭建持續集成服務器的環境,進行持續交付和自動化的冒煙測試等。
測試工具編寫。
安全測試(以后單獨一個專題,本次細說)
培訓的任務:
需要將設計的框架以及封裝的驅動,對其他成員進行培訓。
保證測試執行人員能夠理解測試結果,並能夠正確分析失敗的測試執行結果
中高級自動化測試工程師:
配合測試開發人員,實施測試框架的建設。主要負責中間公共模塊的實現和實例化等,以及部分高難度和流程復雜的自動化用例腳本編寫和調試等工作。
提交及跟蹤自動化測試發現的bug。
初級自動化測試工程師:
根據中間公共模塊的設計,進行實例化公共模塊、方法組合,實現自動化用例腳本的編寫。
提交及跟蹤自動化測試發現的bug。
功能測試人員:
提供具體測試任務相關的咨詢,並且提供測試自動化的需求。
幫助檢驗所開發自動化測試是否有用、可理解和可信賴。
程序員
參與評審自動化測試的體系結構
規划程序架構,提供加入產品可測試機制的更多機會
幫助自動化測試工程師開發用例設計網頁等輔助工具。
技術方案
Android pos
技術方案:APPium
Appium是一個開源、跨平台的測試框架,可以用來測試原生及混合的移動端應用。Appium支持IOS、Android及FirefoxOS平台。Appium使用WebDriver的json wire協議,來驅動Apple系統的UIAutomation庫、Android系統的UIAutomator框架。Appium對IOS系統的支持得益於Dan Cuellar’s對於IOS自動化的研究。Appium也集成了Selendroid,來支持老android版本。
Appium支持Selenium WebDriver支持的所有語言,如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure,或者Perl語言,更可以使用Selenium WebDriver的Api。Appium支持任何一種測試框架。如果只使用Apple的UIAutomation,我們只能用javascript來編寫測試用例,而且只能用Instruction來運行測試用例。同樣,如果只使用Google的UIAutomation,我們就只能用java來編寫測試用例。Appium實現了真正的跨平台自動化測試。
appium選擇了client-server的設計模式。只要client能夠發送http請求給server,那么的話client用什么語言來實現都是可以的,這就是appium及webdriver如何做到支持多語言的;
接口自動化
技術方案:Python
首先技術工具是免費的,Python的工具用PyCharm社區版。利用比較簡潔的Python語言進行自動化測試,對於人員的學習成本來講比較實用,學習時間短,有優勢。
另外Python自帶的unittest單元測試框架可以很方便的實現自動化用例的設計和執行以及自動化用例套件的管理等任務。Python是純面向對象的語言,后續也可以過渡到Java + Selenium進行更加豐富的自動化測試。 此外,可以選擇Jenkins作為持續集成服務器,配合Python+Selenium的方案進行自動化冒煙測試。
性能測試
技術方案:Jmeter、 LoadRunner、自寫腳本
源代碼管理
代碼,以及測試套的管理、分享機制。
文檔管理
保存路徑在git
header 1 | header 2 |
---|---|
接口測試實施方案 | |
接口測試詳細設計 | |
POS自動化詳細設計 | |
性能測試實施指導手冊 |
測試交付物
性能測試計划、報告模板參考:
自動化測試計划、報告模板參考:
代碼編寫規范
編寫人:
完成時間:
可能遇到的問題
幾個使自動化測試項目陷入困境的因素:
-
自動化測試時間不充足:自動化也要盡早介入,爭取保持與開發周期同步,而不是與測試周期同步。
-
缺乏清晰的目標:有很多好的理由去開展自動化測試工作,諸如自動化測試可以節省時間,使測試更加簡單,提高測試的覆蓋率,可以讓測試人員保持更好的測試主動 性。但是,自動化測試不可能同時滿足上述的目標。不同的人員對自動化測試有不同的希望,這些希望應該提出來,否則很可能面對的是失望。
-
缺乏經驗:嘗試測試自己的程序的初級的程序員經常采用自動化自動化測試。由於缺乏經驗,很難保證自動化測試的順利開展。
-
更新換代頻繁:測試自動化往往需要花費很多時間學習的,當自動化測試更新換代頻繁的時候,你就喪失了剛剛學習到的自動化測試經驗。
-
不關注測試工作中的實際情況:很多人發現實現產品的自動化測試比測試本身更有趣。在很多軟件項目發生這樣的情況,自動化工程師不參與到軟件測試的具體活動中。由於測試的自動化與測試的人為割裂,導致很多自動化對軟件測試並沒有太大的幫助。
-
關注於技術:如何實現軟件的自動化測試是一個很吸引人的技術問題。不過,過多的關注如何實現自動化測試,導致忽略了自動化測試方案是否符合測試需要。
-
其他:在測試還遠沒有開始的時候,問題就已經潛伏在軟件中了。軟件測試不過是發現了這些潛伏的問題而已。就測試本身而言,測試是一件很困難的工 作。當在修改過的軟件上一遍接一遍的測試時,測試人員變得疲勞起來。測試什么時候后結束?當按照計划的安排,軟件應該交付的時候,測試人員的絕望變得尤其強烈。如果不需要測試,那該有多好呀!在這種環境中,自動化測試可能是個可以選擇的解決方法。但是,自動化測試卻未必是最好的選擇,他不是一個現實的解決方法,更像是一個希望。
-
如何保證需求變更后,能夠及時提供更新后的自動化測試?如果自動化測試與需求變更無法同步,那么自動化測試的效果就無法保證了,測試人員就不願意花費時間學習如何使用新的測試工具和如何診斷測試工具上報的錯誤。關注項目里程碑,自動化測試工程師可以保持與開發周期同步,而不是與測試周期同步。
自動化測試需要的支持
開發幫忙開發頁面--接口測試用例編寫 自動化測試線上--整理需要的場景,評估需要哪些表加標記 硬件資