專訪內容

                  51Testing老師,能夠做一下自我介紹么?
                  大家好,我是Tynam,意為太難,旨在提醒自己,沒有什么事情是可以輕易完成的,都需要耗費大量的時間和精力去努力。就像我選擇測試行業,歷經坎坷,前路漫長未知,我毅然會用盡畢生精力為之奮斗。

                  目前就職于西安葡萄城有限公司,擔任高級軟件測試工程師一職。在軟件測試行業中已經摸爬滾打了多年,有些測試經驗和自己獨到的見解。經常在各大測試論壇網站(博客園、測試窩、51測試圈、微信公眾號等)發布測試技術分享。

                  從進入測試行業起,就一直致力于測試技術的研究,特別是在自動化測試設計、框架搭建和開發上有深入的研究,根據這么多年的經驗積累著作了《Python web自動化測試入門與實戰》一書。

                  2020年初新冠疫情爆發后,IT行業出現頹縮,測試人員找工作困難,便暗思自己該做些什么,解決求職困難的問題。在與許多測試人員進行交流后,即刻決定寫一些測試人員面試的東西。到目前為止,尋問了多位測試大咖,咨詢了近百位測試小白,完成了《測試工程師面試秘笈》一書,在不久之后便可以和大家見面了。
                  展開更多
                  點擊收起
                  51Testingweb自動化測試除了大家熟知的功能測試外,還有哪些常見的測試類別?
                  web自動化測試最主要的就是對系統的功能測試,測試業務邏輯、功能模塊、鏈接、表單、 Cookies等。除此之外我們還可以通過web UI 自動化做很多方面的測試,例如以下方面:
                  • 兼容性測試:兼容性測試是web自動化測試的一大特色,可以在不同的操作系統平臺使用不同的瀏覽器對網站進行測試。例如分別在win10、win8系統上分別使用Chrome、IE瀏覽器測試。
                  • 易用性測試:易用性主要表現在頁面功能易于用戶使用,色彩搭配適合。例如可以測試圖片大小和位置、各種邊框、顏色、字體、背景色、按鈕大小等。我們還可以測試文本內容,檢測文字描述的正確性。例如title、字段說明等。
                  • 穩定性測試:是在一定的環境下、給定的時間內、測試系統可以正常運行。web自動化可以模擬用戶使用該系統,如果系統發生故障則可自動做記錄。
                  • 壓力測試:在理論上使用分布式可以模擬用戶給系統加壓進行壓力測試,但是有點麻煩,成本也大,一般沒有測試人員這樣使用。

                  使用web自動化我們可以做一些其他的測試,比如控件、插件的測試,例如項目中使用的日期控件。

                  總結:web自動化測試是最接近人行為操作的模擬測試,可以代替需要手工測試的許多重復工作,益處頗多。
                  展開更多
                  點擊收起
                  51Testing有很多人不知道該如何開始上手web自動化測試,對于手工測試人員而言,web自動化該如何入門?學習web自動化有什么前提條件嗎(前置技術能力,例如前端技術,數據庫,代碼)?對于前置技術需要掌握到什么程度?
                  我一直認為,自動化測試重在設計、構造的思想上,并不是什么技術。如果想入門自動化測試,首先要將自己做手工測試的那一套思想轉換成自動化測試思想。例如要如何設計才能讓測試用例不斷的重復的運行,降低測試用例之間依賴,數據怎么準備,怎么銷毀等。其次才是掌握一定的技術知識。下面給大家畫了一個圖作以簡單的說明。


                  以上只是簡單的入門知識點,如果需要想研究的透徹,則需要深入的學習,包括selenium源碼的研究。
                  展開更多
                  點擊收起
                  51Testingweb自動化測試工具和框架有哪些,企業中較為常用的有哪些,這些工具/框架的優勢是什么,又有哪些不足之處?
                  web自動化測試框架和工具有selenium、RobotFramework、QTP、Katalon Studio、IBM Rational Functional Tester、watir等等。目前最受歡迎的框架是selenium,使用率最高的工具是RobotFramework。下面簡單的介紹一下selenium和RobotFramework:

                  selenium
                  selenium是一系列基于web的自動化工具,提供一套測試函數,用于支持web自動化測試。能夠完成界面元素定位、窗口跳轉、結果比較,函數靈活,使用方便。

                  selenium具有以下優點:
                  • 具有很多工具:selenium IDE、Web Driver、Grid
                  • 免費、開源
                  • 支持多種編程語言:Java、C#、PHP、Python、Perl、Ruby
                  • 支持多種瀏覽器:Internet Explorer、Firefox、 Google Chrome
                  • 可以運行在多個平臺上:Windows、Mac、Linux
                  但也有不足,它僅針對web系統進行測試,像APP、exe程序等是不支持的。

                  RobotFramework
                  RobotFramework是一款python編寫的功能自動化測試框架。提供可視化界面,具備良好的可擴展性,支持關鍵字驅動,可以同時測試多種類型的客戶端或者接口,可以進行分布式測試執行。主要有以下優點:
                  • 易于使用,采用表格式語法,統一測試用戶格式
                  • 重用性好,可以采用現有關鍵字來組合新關鍵字
                  • 支持變量
                  • 支持創建基于數據驅動的測試用例
                  • 結果報告和日志采用HTML的格式,易于閱讀
                  • 提供標簽以分類和選擇將被執行的測試用例
                  • 平臺、應用無關
                  • 功能全面、支持協議級接口的測試,GUI界面的測試,數據庫的測試,移動APP的測試,命令行測試等
                  • 易于擴展,提供了簡單的api,用戶可以自定義的基于Python或者Java的測試庫
                  • 易于集成,提供了命令行接口和基于xml的輸出文件
                  • 可以與版本管理集成(Jenkins)
                  展開更多
                  點擊收起
                  51Testingselenium和RobotFramework都能用于web自動化測試,從您的角度而言,更傾向于哪一種,為什么?
                  兩者各有優缺點。selenium多在編程語言中使用,RobotFramework是可視化自動化測試工具中的一個經典。如果讓我推薦的話,我推薦selenium,然后再反過來研究RobotFramework。如果自學自動化測試的話,可以先從RobotFramework工具入手,理解自動化測試到底是怎么做的,做的是什么,畢竟熟悉工具比掌握一門語言要容易的多。有了理解之后再學習selenium,使用編程語言寫腳本。當對編程語言、selenium有一個深入的學習之后,再反推 RobotFramework的實現,研究RobotFramework都實現了什么,是怎么實現的,如此才能徹底理解RobotFramework。在此期間,可以嘗試寫一個簡易的、類似RobotFramework的自動化測試工具。
                  展開更多
                  點擊收起
                  51Testingweb自動化測試都有哪些設計模式,例如數據驅動(DDT), 頁面對象(PO),關鍵字驅動,行為驅動等,這些分別指什么,各自應用場景都有哪些?
                  自動化測試中有線性模型、模塊化驅動模型、數據驅動模型、關鍵字驅動模型和行為驅動模型。下面給大家分別介紹一下:

                  線性模型:
                  線性模型是指將錄制或編寫的腳本與應用程序的操作步驟對應起來,就像流水線工作一樣,每一個步驟對應一行或多行代碼。每一條流水線(每個測試腳本)都是相對獨立的,且不產生其他依賴與調用,這樣產生的腳本叫線性腳本。這是在自動化測試早期采用的一種測試模型,由于工作腳本是線性的,所以也叫線性模型。線性模型的每一個腳本都是獨立的,且幾乎沒有其他依賴和調用。開發成本比較高,而且代碼的復用性特別差。

                  應用場景:
                  • 可以快速編寫測試腳本。
                  • 完成某個操作流程。
                  • 需要每個腳本單獨運行。
                  • 初學自動化測試的人員使用。

                  ?模塊化驅動模型:
                  模塊化驅動測試借鑒了開發編程的模塊化思想,是將重復的代碼提取到一個公共的模塊,然后在需要的時候調用封裝好的公共模塊,如果項目某一個功能有變動,只需要變動相應的腳本,很大程度上提高了編寫腳本的效率。比如,登錄模塊就可以封裝在公共模塊中,一旦模塊中的元素定位有所變動或其他因素影響了模塊,只需要在封裝的模塊中進行調整對應,而不會影響到任何測試用例,機動性、靈活性非常強。維護簡單方便,模塊變動時只需要對相應的模塊封裝即可。

                  應用場景:
                  • 使用比較廣,目前絕大部分項目都在使用。
                  • 多人協作,分模塊開發腳本。
                  • 代碼可以重復使用。

                  數據驅動模型:
                  數據驅動是將測試數據和測試腳本分離,通過測試數據的改變驅動自動化的執行,從而產生不同的測試結果。簡單地說,就是數據的參數化,輸入不同的參數驅動程序執行,從而輸出不同的測試結果。數據的保存形式可以是列表、字典,也可以保存在 Excel、數據庫、xml 等外部文件中。這樣就能夠快速地應對測試系統中的大量數據,迅速創建出數百個測試迭代和排列。

                  應用場景:
                  • 可以快速創建大量的測試數據。
                  • 一套腳本,多個測試數據應對多個場景。

                  關鍵字驅動模型:
                  關鍵字驅動和數據驅動很相似,通過關鍵字的改變引起測試結果的改變,也稱為表格驅動測試或基于動作字的測試。關鍵字驅動模型將測試用例分為 4 個不同的部分:測試步驟、測試對象、測試對象操作和測試對象數據。
                  • 測試步驟:對測試步驟的一個動作描述,或者說是在測試對象上執行的動作描述。
                  • 測試對象:頁面中元素對象的名稱,例如郵箱、密碼和登錄等。
                  • 測試對象操作:測試對象上執行的動作名稱,例如單擊、打開瀏覽器、輸入等。
                  • 測試對象數據:數據是指對測試對象執行操作所需的值,例如“郵箱”字段的值為 “tynam@test.com”。

                  RobotFramework 工具就是遵循關鍵字驅動模型開發的一個功能強大的測試工具,其封裝了底層的代碼,提供給用戶獨立的圖像界面,以 “填表格” 形式編寫測試用例,降低了腳本的編寫難度。

                  應用場景:
                  • 通過可視化工具創建測試用例,適合編寫簡單的腳本。
                  • 項目穩定,測試人員易上手。

                  行為驅動模型:
                  行為驅動開發英文名為 Behave Driven Development,簡稱 BDD,是一種敏捷開發方法,主要是從用戶的需求出發強調系統行為。將此模型借鑒到自動化測試中稱其為行為驅動測試模型,它是一種通過使用自然描述語言確定自動化測試腳本的模型。用例的寫法基本和功能測試用例的寫法類似,具有良好協作的益處。這種測試模型使每個人都可以參與到行為開發中,而不僅僅是程序員。每個測試場景都是一個獨立的行為,以避免重復,并且已有的行為可以重復使用。

                  應用場景:
                  • 行為驅動模型的思想非常有價值,但是國內還不太流行,在真實的自動化項目中還沒有多少人使用。
                  • 人人都可以寫測試用例。
                  以上便是對五種自動化模型的簡單介紹。對于這五種自動化模型的實現,有一個簡單的Demo可供大家參考,下載地址:https://github.com/tynam-yang/AutomatedTestModel
                  展開更多
                  點擊收起
                  51Testing企業中常見的web自動化分層框架有哪些,這樣設計的意義是什么?
                  之前和許多測試人員聊過這個問題,目前來說,企業中最常見的分層結構是模塊化思想,而它最好的體現便是page-object模型,即頁面對象模型。在項目實際應用中一般會分為三層:
                  • 對象庫層,頁面元素和一些特殊控件操作。
                  • 邏輯層,封裝好的功能用例模塊。
                  • 業務層,測試用例的操作。

                  如下圖,便是一個簡單的PO模型結構,大家可以進入 https://github.com/tynam-yang/AutomatedTestModel 選擇模塊化驅動模型文件夾查看Demo實例。

                  目錄文件說明:
                  • config: 配置文件。
                  • data: 測試數據。存放上傳數據,還可以細分,例如存放照片 image 目錄、 video 目錄等。
                  • download: 存放下載的數據。還可以細分,例如存放下載的照片 image 目錄、 video 目錄等。
                  • drivers: 驅動文件,存放瀏覽器驅動。
                  • log: 日志文件,存放項目執行過程中的產生的 .log 文件。
                  • report: 測試報告。
                  • test: 測試文件,存放測試腳本、測試用例等。
                    • common: 公用方法,項目相關的方法。
                    • pages: 以頁面為單位,每個頁面是一個 page。
                    • case: 測試用例。
                    • runner: 對測試用例進行組織。
                  • utils: 存放一些其他的方法。
                    • HTMLTestRunner.py: 生成測試報告時使用的文件。
                    • readConfig.py: 讀取配置文件的文件。
                    • run.py: 項目入口文件,主要是對 /test/runner 下組織的用例進行執行并且生成測試報告。
                    • run.py: 項目入口文件,主要是對 /test/runner 下組織的用例進行執行并且生成測試報告。
                    • run.py: 項目入口文件,主要是對 /test/runner 下組織的用例進行執行并且生成測試報告。
                    這樣做有諸多益處:
                    • 集中管理元素對象,便于應對元素的變化。
                    • 提高代碼重用性,結構更加清晰,維護代碼更容易。
                    • 后期維護方便,不需要重復的復制和修改代碼。
                  展開更多
                  點擊收起
                  51Testing根據您多年的經驗web自動化測試中遇到的痛點難點都有哪些?是否都有應對的可行策略?
                  我從以下幾個方面給大家說說在web自動化中會經常遇到的問題,以及解決方法:
                  1、需求不穩定,項目頻繁發生變更
                  這種問題要從兩方面進行分析,是整個項目不穩定還是局部功能不穩定。如果是整個項目不穩定,大部分頁面經常發生變動,那么這種項目不建議進行UI自動化測試。界面如果經常變動,腳本就需要重新編寫,界面需求頻繁的變更導致編寫腳本的速度趕不上需求的變化,那么 UI 自動化就顯的不是那么有意義。特別是現在許多公司都采用的是敏捷開發,項目周期短,更不太適合做UI自動化測試。如果是局部發生變化,那么建議先對穩定的內容做UI自動化測試,這樣可以減少手工測試的壓力。不穩定的部分打上標簽,待穩定后再進行UI自動化。

                  2、第三方控件,難以操作
                  如果遇到項目中引入了第三方控件,但是selenium難以操作,該怎么辦?例如日期控件。
                  這是一個很常見的問。如果是第三方的東西,我們需要查看它的文檔說明,接口說明等內容。然后根據文檔說明使用可以操作的語言(一般來說,web端的js都可以操作)進行封裝,使用時調用即可。例如日期控件我們可以封裝成的函數就是 date_operation(date),具體操作步驟需要根據具體場景而定。使用時我們直接調用,傳入需要輸入的值即可。

                  3、驗證碼難以識別
                  在很多類似登錄的地方都會存在驗證碼,這的確是一個很難解決的方法。當然可以通過去掉驗證碼、設置萬能驗證碼等方法通過測試。但這種方法對于系統來說明顯動了代碼,和實際環境中的有所差異。對于驗證碼問題通常有兩種解決方法,第一種,使用機器學習等方法寫腳本,識別驗證。但是對于測試人員要求比較高,訓練也需要花費很多時間。第二種,調用第三方接口,例如尖叫數據的驗證碼識別、阿里云視覺智能開放平臺,調用相關接口識別驗證碼。
                  展開更多
                  點擊收起
                  51Testing哪些項目適合web自動化,哪些不適合,為什么?結合您的經驗什么時候投入web自動化測試可行性更高?
                  UI 自動化測試其實就是模擬手工點擊,但它又不像測試人員一樣,可以帶著思考進行。因此它需要一定的規范,然后遵循這種規范寫自動化測試腳本,這樣才可以穩定、持續進行運行。所以UI自動化測試比較適合需求穩定且不頻繁變更、需要頻繁的回歸驗證、UI 界面穩定、界面控件定義規范可測試性強、開發維護周期長、進度壓力小的項目。對于需求不穩定、頁面發生頻繁變更、開發維護周期短、被測系統開發不規范、可測試性需求不明確的項目不太適合。

                  我們都知道,UI自動化測試比較適合做回歸、兼容性測試,對項目的穩定性要求比較高。因此,UI自動化適合在項目穩定后進行。一般都是在經過手工測試之后進行編寫腳本的。但是可以盡早提上日程,進行規劃。比如在開需求說明會的時候,將自動化測試提上日程,規劃模塊劃分等內容,在項目穩定后便可立即上手開發腳本。
                  展開更多
                  點擊收起
                  51Testing近幾年接口測試的熱門程度大有超越web自動化的趨勢,web自動化測試會被接口測試取代嗎?對比接口測試,web自動化測試的優勢有哪些?
                  web自動化是基于頁面上的測試,而接口測試是在數據交互上的操作,兩者不在一個層面上,所以不會有誰取代誰的情況。根據測試金字塔,我們可以發現接口測試比web UI測試產出的效益會更大,再之web自動化的開發和維護要比接口自動化測試繁瑣、費時,更費力,因此企業會不斷的提高接口自動化測試的權重,與此也會加大web自動化測試的投入,因為web操作直接面對的是客戶,容不得半點馬虎。

                  與接口測試相比,web自動化測試更能模擬出用戶的使用場景,全面覆蓋需求規格。我們都知道web自動化測試主要用于回歸測試和兼容性測試?;貧w測試是根據設計好的測試用例執行,web自動化就是模擬人為操作,結果可預期的測試,非常適合。兼容性測試是在不同平臺、不同瀏覽器中進行,web自動化可以進行這樣的操作。而接口測試就不能完成回歸、兼容性這樣的測試。
                  展開更多
                  點擊收起
                  亚洲欧洲自拍图片专区123_久久久精品人妻无码专区不卡_青青精品视频国产色天使_A免看的日黄亚洲