自動化測試的障礙

原文地址

原文與2018年5月發表於Dzone中DevOps欄目。

業內專家認爲，具備人工測試的企業文化是阻礙自動化測試進展的最大障礙。爲了收集當前和將來自動化測試狀態的看法，咱們詢問了來自27家公司的31位高管，「您認爲阻礙自動化測試的最多見問題是什麼？」 下面是他們告訴咱們的：

企業文化

• 在開發進展和質量保證之間，公司仍然沒有明確的指望。 須要編寫脆弱的功能和單元測試，以便它們可以在不中斷的狀況下跟進變化。測試用例隨着時間的推移持久耐用。瞭解爲何測試會中斷，可以肯定須要作些什麼才能使測試更具彈性。
• 首先必須擁有與相似的測試基礎架構，您能夠在其中捕獲問題並可以正確地通知開發人員。此時，須要明確的策略，以肯定在檢測到迴歸時執行的操做：分配給誰修復它們，解決它們與完成其餘任務的速度有多快，模糊迴歸會發生什麼（代碼錯誤或測試錯誤） ）等，咱們已經看到了一個常常性功能障礙類型中的幾個組織：他們已經創建了一個自動化測試系統，可是從破碎測試的噪音淹沒了從工做的測試信號，因此你們忽略的測試系統。 這比沒有自動化測試基礎設施更糟糕。必須積極維護測試和圍繞它們的人員流程，不然您最終會遇到這種特殊的功能障礙。
• 傳統軟件和平臺。 客戶端嘗試使用雲原生但仍與大型機接口。工程文化：質量保證被視爲次要的，這是一個落後的觀念。培養開發團隊的良好的心態。恰當使用正確的工具很重要，不會浪費開發人員的時間。
• 若是研發與自動化團隊之間的溝通不良，那麼這可能會對新的自動化流程產生不利影響。當咱們所有同步時，技術（自動化）將成功。另外一個問題是自動化基礎設施，它必須足夠靈活，可以接受產品開發方面的任何變動，從而將維護工做降至最低。
• 讓公司內化並定義他們想要優化的業務指標。 更多關於結果而不是產出和與商業價值的關係。 多個獨立的孤立方法，可在單個組織中進行測試。 Unicorns具備高度分佈的隔離組件。變化的影響是零，你沒有筒倉問題。改變遺留系統的合規性和風險是一項挑戰。
• 靜態掃描不提供覆蓋率。不保證質量範圍。不要暴露實際的測試覆蓋率。隨着DevOps將人們彙集在一塊兒，咱們能夠看到安全性和測試須要讓他們一塊兒工做所需的孤島。

手動測試

• 在使用手動流程的狀況下，人們須要接受再培訓。就像DevOps同樣。文化問題：須要再培訓。把普通的手工測試工程師成編寫測試程序的工程師。SDLC中的許多其餘流程已經自動化並加速，所以QC不會減慢流程。
• 從手動轉爲自動化。 學習如何編寫測試，手動測試的將來會怎麼樣？培訓和教育方面。而後進行測試並集成到DevOps管道中。公司進行測試但不看結果。時間或環境依賴的事情可能會有更多的問題。
• 舊式測試人員沒法適應，擁抱，自動化測試和人工智能（AI）。技術覆蓋須要跟上網站變得更加動態，UI更加直觀，面部識別和指紋。使用自動化完成測試的執行。
• 徹底的手工測試QA測試工程師發展的一個瓶頸。

其餘

• 曾經有一段時間人們不相信測試。如今再也不是這種狀況了，單純地前端測試是不多人作的事情。如今能夠作視覺差別了，自信地對CSS進行更改。整個系統看一下代碼評論中的截圖，以便測試整個堆棧。
• 向左轉。用於進行手動測試，但轉向100％自動化。這其中須要更多技術技能。手動測試儀學習所需技能只需幾天時間。Selenium使用人們熟悉的通用web測試框架。接受和開發易於構建測試套件，同時構建應用程序以確保該功能沒有錯誤。接入CI / CD管道進行部署。
• 一旦咱們肯定了價值驅動因素，那麼咱們就會遇到能夠跨越兩個或三個家庭的阻礙者：1.技能組合 - 完成這項工做（自動化和編程）很困難，調整指望和計劃; 2.基礎設施的穩定性 - DevOps，測試（20％漏報）; 3.對覆蓋的理解在當今世界中測試真實用戶環境意味着什麼？不一樣的預期，幫助理解和自動化，以及沒法克服結果產生的噪音量。測試的數量和生成的數據量，智能分析，快速放大，看看出了什麼問題。
• 緊跟瀏覽器和平臺的全部變化，以及如何管理和使用測試工具生成的全部數據。
• 影響自動安全測試的主要問題有兩個：第一個主要問題是表現不許確的結果。若是證實這些結果很是困難，開發人員將忽略自動化測試結果。第二個主要問題是開發人員工具中缺少有價值的集成測試。安全團隊繼續經過GRC系統記錄，管理和分散其安全數據。開發人員不會說GRC。他們說JIRA，TFS，Trello等。
• 這很難說。可能有更多用於編寫可測試代碼的設計模式或標準。使人不安的是，即便像Salesforce這樣的現代軟件工具提供商或像Apple這樣的大品牌也沒有考慮「可測試性設計」，以便使測試自動化變得更容易。第二件事是關於大學和學院的軟件測試的更多教育。大學傾向於專一於軟件開發而不是教授測試技能。這使得培養可靠的軟件測試人員面臨挑戰 - 特別是在自動化領域。
• 天天快速的技術進步。須要關注更新。轉到新版本的測試和代碼。不要將更新推遲到之後的階段。1.具備新框架，技術，編寫應用程序的方法的動態應用程序。因爲底層應用程序發生變化，測試變得不穩定 咱們構建了一個測試來解決這個問題。2.須要技術自動化。編寫代碼並不老是那麼容易。咱們經過無代碼自動化解決問題，所以非技術團隊成員能夠自動啓動和運行。3.經過Web，移動和桌面應用程序實現高測試覆蓋率。須要多種工具和工具才能協同工做。肯定哪些環境很重要。
• 須要工具成爲DevOps工具鏈的組成部分。使用許多工具進行交付過程（Jenkins，JIRA，Slack，GitHub）甚至但願將AI測試視爲其中的一部分。想要一個全面，自動化，可見的交付流程來分享來自不一樣工具的反饋。另外一個可以在整個組織內共享反饋的能力 - 單元，組件，集成，端到端測試到部署。沒有辦法分享他們分享的東西，協做很是重要。數字化轉型高管也但願參與這一過程，全部人都看到並互相學習。
• 報告首先是最重要的。一堆自動化工具但沒有超越Jenkins或Bamboo以外更好的環境查看分析測試結果，只知道報告。自動化缺少QA參與，自動化缺少智能，沒法識別您須要的覆蓋範圍和需求可追溯性。須要端到端的單元測試 - 使用不一樣工具集的不一樣自動化集。
• 人們尚未徹底理解失敗的問題及其影響。從硬件世界到軟件世界，具備深厚網絡技能的人不瞭解事情的變化。第一波網絡測試自動化有一些失敗。
• 客戶利用CI / CD中的Selenium必須讓開發人員編寫測試。自動化測試是產品開發背後的緣由，由於開發人員沒法編寫測試。咱們的平臺使測試可以用英語而不是代碼編寫。它使客戶可以利用他們的資源。
• 我認爲我見過影響自動化測試的最多見問題是過分依賴它。全部關於未知數的自動化測試仍然是驗證/測試您已識別的事物的有效且有用的方法。這多是您所看到的問題，以及您正在嘗試優化的工做流程。它不管如何都沒法驗證您的代碼的實際用戶交互或代碼自己如何在您未預見的地方進行交互。因此，若是你不知道它，你就不能爲它編寫測試。過分依賴自動化測試，或靜態使用自動化測試而不進行更新，多是真正的挑戰。你想讓它成爲你不斷更新和評估的東西，「我是否正在測試正確的東西？」 並且您須要使用工具，例如功能管理，

技術類文章精選

1. java一行代碼打印心形
2. Linux性能監控軟件netdata中文漢化版
3. 接口測試代碼覆蓋率（jacoco）方案分享
4. 性能測試框架
5. 如何在Linux命令行界面愉快進行性能測試
6. 圖解HTTP腦圖
7. 如何測試機率型業務接口
8. httpclient處理多用戶同時在線
9. 將swagger文檔自動變成測試代碼
10. 五行代碼構建靜態博客
11. httpclient如何處理302重定向

非技術文章精選

1. 爲何選擇軟件測試做爲職業道路?
2. 成爲傑出Java開發人員的10個步驟
3. 寫給全部人的編程思惟
4. 自動化測試的障礙

公衆號地圖 ☢️ 一塊兒來~FunTester