![](http://static.javashuo.com/static/loading.gif)
衆所周知,測試的技能要求再也不簡單,自動化測試做爲軟件測試的主流發展方向。爲了收集當前和將來自動化測試狀態的看法,咱們詢問了來自27家公司的31位高管,「自動化測試解決了哪些現實問題?」 這是他們告訴咱們的:html
受訪者
優勢
- 簡而言之,自動化測試對於1)節省時間很是寶貴- 由於測試全天候自動運行; 2)報告 - 咱們得到每日看法; 3)一致性和準確性:手動測試周期可能致使錯誤,而自動化測試每次都能得到準確的結果; 4)省錢 ; 5)減小資源,例如手動測試人員; 6)全覆蓋測試。
- 1) 管道的通常轉換,從每一年發佈一次到每一年17-20次。 解決測試和QA瓶頸問題。咱們與客戶合做,經過多種測試類型的自動化來推進這些轉換。2) 汽車和健康領域的下一代數字化轉型,具備獨特的用例,可實現自動化,測試和覆蓋。該鏈接的汽車 是他們的#3垂直。它能夠測試從應用程序到後端服務器以及鏈接到後端的完整用戶體驗。它有益於健康從提供藥物到以數字方式管理消費,並對您如何以及什麼時候消費藥物負責。咱們在雲中建立虛擬化患者。公司可使用鏈接的設備跟蹤它們。咱們向移動應用報告並向患者提供可見性並向醫生報告。物聯網是下一代數字化轉型。
- 最初的用例是自動化測試 - 固件測試5000次,線性測試耗時。咱們在一系列機器上分發測試。自動化測試縮短了週期時間。它有助於在集羣中運行Selenium測試的UI測試,以加速Selenium測試。 Selenium Grid是實現此目的的一種方法。
- 做爲測試雲平臺, 咱們使客戶可以在各類瀏覽器和設備上進行測試。 咱們還提供調試工具,例如如何從瀏覽器中提取JS控制檯日誌和硬件文件。咱們幫助客戶發現錯誤並快速解決。縮小規模,咱們的大客戶天天都要運行數萬次測試,而且可能會被信息和數據所淹沒。咱們引入了分析來對數據進行排序,以找出瓶頸和錯誤的根本緣由。更成熟的公司正在從內部Selenium網格轉向遷移到雲,由於他們沒有他們想要的平臺覆蓋範圍 - 測試Mac,Safari和iOS。如何得到更好的報道。很難用常綠瀏覽器維護。咱們爲他們這樣作。天天數千次測試的錯誤率。硒多是一個棘手的協議。不想花費全部時間來追逐錯誤。提升速度。咱們對每次拉力測試或提交進行測試,所以,咱們須要站起來100個節點,以便更快地向開發人員提供反饋。若是你沒有網格,你須要進入CI的世界。花更多時間在最佳實踐上 - 測試編寫和框架 - 若是您沒有專業知識來採用測試框架並以高水平的並行性進行優化。
- 傳統安全團隊沒法在DevOps世界中擴展。 自動 安全 測試是容許這些團隊擴展的關鍵。安全團隊須要與開發人員密切合做,但這種溝通方式必須經過自動化測試。那些在開發生命週期內直接利用自動安全測試的安全團隊有更強的能力與Agile和DevOps開發商店保持同步。
- 自動化測試使您能夠更自信地 提供修復和功能。所以,它加速了開發並容許更快地推出新版本 - 這對基本上每一個行業都有影響,從生物技術到國防。
- 必須驗證涉及大量數據的複雜方案時,自動化測試相當重要 。 例如,咱們有一位 航空公司 客戶使用咱們的軟件來確保他們的網絡預訂系統正常運行。咱們在測試用例中支持嵌套循環的能力解決了他們驗證多個源和目標點的數據的獨特問題。咱們有另外一位客戶正在使用咱們的解決方案來測試控制手持式醫療設備的移動應用程序 。他們的應用必須完美運行,所以100%的測試覆蓋率相當重要。自動化測試可幫助他們提供高質量的產品。
- 咱們經過自動化測試從單片微服務轉向 大規模微服務。您必須這樣作才能擴展和溝通。咱們在平常工做環境中使用它。每一段進行測試的代碼都有90%的代碼覆蓋率。
- 1)向左移動 - 一個擁有大型QA團隊的客戶端最終用於執行測試。一旦他們意識到須要儘早測試,他們就會在編寫應用程序代碼時開始編寫測試。QA團隊成爲工程團隊的一員。核心測試在SDLC的早期進行。咱們**可以更快地發佈(50%)而且代碼質量自動提升,而且因爲在週期早期發現錯誤而致使成本降低。 **
- 公司的增值正在 幫助客戶成爲雲原生開發者。專一於業務邏輯,以開闢更普遍的測試可能性。採用業務邏輯並在具備單元測試框架的模擬環境中運行。嵌入式測試看起來像J2EE測試。可使用全部傳統的Java測試框架。
- 1)跨瀏覽器測試,2)跨設備測試,3)迴歸測試UI / UX,4)本地化測試 - 確保以全部語言進行測試。 在微服務和操做系統發生變化的動態技術領域,擴展測試,擴展到後期製做 - 監控和持續測試。經過全天候監控,咱們幫助公司克服這個問題。
- 若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069,羣內會有不按期的發放免費的資料連接,這些資料都是從各個技術網站蒐集、整理出來的,若是你有好的學習資料能夠私聊發我,我會註明出處以後分享給你們。
- DevOps和敏捷實踐測試人員被認爲是有價值的。 咱們爲質量保證團隊提供看法,所以他們能夠影響從開始到生產的質量。 查看分析,瞭解錯誤或人員對質量的負面影響。咱們爲他們提供了一個空間,由於咱們從自動化和測試工具中收集指標,並提供總體分析,以儘早提升質量。咱們提供需求可追溯性矩陣 - 有效和無效的熱圖。從邏輯的角度看待覆蓋範圍。這個處理要求很複雜,而且有不少錯誤。提供覆蓋的智能概念。
- 在發佈以前,測試正在運行,一般會遇到不少複雜的代碼級錯誤。使用雙因素身份驗證代碼破壞了用戶登陸。自動測試捕獲的 錯誤,並在發佈以前修復。在另外一個案例中,公共共享連接被打破。從長到短的URL被更改了。二者都是經過自動化測試捕獲的
- 使用腳本技術,您沒法管理對測試腳本的更改。在敏捷或DevOps進程的頻率和節奏。能夠用一個sprint來作兩個或三個sprint來執行測試。 使用基於模型的方法,您能夠實時更改和執行更改,由於它是無代碼的。 具備測試基礎結構的客戶端接近其應用程序的三倍代碼。因爲您正在使用代碼行,所以必須經過更改腳原本跟上更改的代碼。咱們使用抽象模型更新代碼。
- 真實世界的問題包括可以確保您在開發過程當中實際運行測試,並確保您不會錯過它們或跳過它們。 現代自動化測試具備代碼清潔等優勢。 它實際上能夠評估語法。它能夠驗證註釋以確保註釋實際插入代碼中。它能夠確保您實際上在代碼庫中實現良好的開發實踐和良好的編碼實踐。自動化測試更多的是測試已經構建或已經簽入的代碼,而不是正在運行的代碼。之前,你不能把責任歸還給開發者。這是過去幾年中自動化測試真正改變的另外一件事 - 自動化測試如今將更多的測試責任放在開發人員本身身上,而不是這個獨立且獨特的QA或QE團隊。這就是許多正在轉變爲持續交付模式的團隊所發生的事情。大多數人從瀑布到敏捷到持續交付 - 他們的任務實際上變得不一樣,由於測試自己已集成到您的代碼簽入過程當中。轉換所暗示的一點是,您並不真正須要此質量保證或質量工程組織,或者您沒有以相同的方式利用它們。
工業
- 對於金融服務和醫療保健等高度監管行業的公司而言,更快,更安全的結果是 使用持續測試來指出須要培訓以得到速度的地方。
- 自動化測試使客戶可以檢查健康情況的正確性 - 醫療保健公司 每隔15到20分鐘運行一次。病毒掃描程序中止工做 - 無聲地失敗。次日早上,Ops可以看到問題所在,而不是三到四個月。一位客戶正在使用工具來知足審計要求。它提供數據點和響應查詢的能力以及可致使合規性上升或降低的可追溯性。
- 咱們有一個新的 視頻播放器,新的iOS,15%的錯誤率。它如何初始化播放器有一個簡單的錯誤。它減小到不到百分之一。
- 零售,銀行和保險等電子商務公司擁有產品或服務目錄。網站是動態的,個性化的,而且能夠從世界各地訪問。客戶須要在他們的店面上進行快速測試。正在對網站進行快速和按期的更改。其餘人則擁有 移動應用程序,航空公司,銀行,客戶須要使用的應用程序,以確保在各類設備上進行測試以瞭解功能的工做原理。測試設備的功能。擁有移動應用的Tech公司能夠運做 Twitter 是一個大客戶。
- 一家大型電信公司正在使用AI來解決測試問題。 2號門的承包商必須返回3號門,以肯定要測試的測試腳本數量以及須要批准的FTE數量。咱們給了他一種自動生成模型的方法,他能夠指定相對於模型的測試,而且他能夠本身進行測試,由於一切都是自動化的。他的邊緣通過了屋頂。
- Rabobank在荷蘭 - 500個分支機構,使用敏捷需求設計師實現測試用例自動化的巨大價值。效率提升30%。金融服務在測試腳本建立方面減小了70%。Auto Trader將整合時間從三天縮短到三小時。他們節省了567個工時,或每一個版本2.5我的,並避免了300,000美圓的測試硬件和軟件成本。他們將缺陷減小了25%。使用咱們的連續測試平臺與 電子商務零售商合同推出新的Rhianna生產線 兩個月準備促銷和最終設計,五天進行負載測試。基於SaaS的平臺以10倍的速度進行了測試,在Rhianna發佈有關該產品的推文後,該網站的處理時間超過18小時。
- 咱們與聯邦政府合做, 並覆蓋其遺留系統,以識別潛在的漏洞。
- 諾基亞 接到客戶,網絡服務提供商,北美全部蜂窩電話塔(200,000)的電話,下面有硬件來管理無線傳輸。有時他們須要更新從4G到5G。咱們須要更新解決方案以在部署以前知足需求測試,而後在現場進行監控。設計,驗證,構建,部署。
- 算法交易公司。在構建徹底自動化的CI / CD管道流程時,他們將使用Jenkins嵌入咱們的解決方案併成爲生態系統的一部分,所以在簽入代碼時,它能夠轉移到測試並決定他們想要運行哪一個測試。結果在30分鐘內。它被反饋到CI / CD工具中以肯定下一步是什麼。若是它沒有經過,該工具會將代碼推送到錯誤跟蹤系統JIRA,而後將其發送回開發人員,而後從新測試失敗的內容。徹底集成到CI / CD中。
- 金融服務將應用程序 應用於API,以更快地發佈行爲驅動的設計框架。有一個模板化的測試開發人員能夠編寫以涵蓋安全性。
其餘
- 一般,編寫代碼更改的自動化測試所花費的時間多於本身進行更改所需的時間,所以在編寫測試時可能很難得到支持。可是,自動化測試能夠爲您提供:1)更頻繁,更快速,可重複且可靠的測試運行。這是由於一旦測試自動化,運行它的成本是最低的。除此以外,自動化測試不容易因人爲錯誤而致使失敗。2)持續反饋,從而對您的代碼更改充滿信心。這樣能夠實現更長的交付週期,並使團隊可以實現持續集成和交付。3)正如Martin Fowler所說,「若是有什麼事情會受到傷害,那就更頻繁地去作」。因爲幾個因素,自動化測試可能會出現片狀,其中一個因素是產品不夠耐用。擁有編寫自動化測試的文化將使您的代碼更易於測試。