DevOps 的目標是以更快的方式交付軟件。如今,越來越多的企業(yè)正努力通過 DevOps 實踐提高生產力,加快發(fā)布周期。然而在DevOps 實踐中,開發(fā)人員專注于功能創(chuàng)建,而業(yè)務領導者則專注于交付,測試的重要性常常被忽略。這就導致,雖然交付過程的其他方面得到了簡化和加速,測試卻成為了軟件交付的瓶頸。

軟件交付的最大阻礙

GitLab 曾經發(fā)起一項針對開發(fā)者和工程師的調查。調查發(fā)現(xiàn),有 52% 的受訪者認為,與開發(fā)過程的其他部分相比,測試造成的延遲更多。

DevOps Review 也得出了相同的結論,63% 的受訪者表示,“測試”是導致軟件延遲交付的第一大因素。該調查主要針對實施 DevOps 企業(yè)的 IT 部門領導者。第二大阻礙軟件交付的因素是“計劃”,不過只有 32% 的受訪者如此認為,遠遠低于站隊“測試”的人群。

軟件生產過程中的主要障礙在哪里?

為什么測試是一個如此可怕的瓶頸? 測試咨詢公司 Tricentis 的創(chuàng)始人 Wolfgang Platz 經過調查后,總結了以下原因:

絕大多數(shù)測試(超過 80%)仍然是手動執(zhí)行的——在大型企業(yè)中甚至更多。

正在構建、維護和執(zhí)行的測試用例中,大約 67% 是多余的,對工作沒有任何價值。

在具有重要測試自動化的企業(yè)中,測試人員將 17% 的時間用于處理誤報,另外 14% 的時間用于額外的維護任務。

超過一半的測試人員每周花費 5 到 15 個小時處理測試數(shù)據(jù)(數(shù)據(jù)的平均等待時間約為2 周)。

84% 的測試經常因測試環(huán)境訪問受限而延遲,測試環(huán)境的平均等待時間為32天。

從開始到結束——包括計劃、實施和測試,執(zhí)行回歸測試套件平均需要 16.5 天,但敏捷沖刺平均需要兩周時間。

現(xiàn)在,被測應用程序平均與 52 個相關系統(tǒng)交互——這意味著單個端到端事務可以跨越從微服務和 API 到各種移動和瀏覽器界面、打包應用程序(SAP、Salesforce、Oracle、ServiceNow…… )、自定義/遺留應用程序和大型機。

如何破解測試難題?

隨著軟件發(fā)布變得越來越頻繁,采用傳統(tǒng)的測試方式已經跟不上開發(fā)節(jié)奏。企業(yè)應該怎么做,才能確保,測試不是軟件交付的瓶頸,而是更快的催化劑。

Forrester 的一項研究發(fā)現(xiàn),成功實踐 DevOps/敏捷開發(fā)的企業(yè),有一些共同點,比如通過自動化端到端功能測試等方式將軟件測試轉變?yōu)槌掷m(xù)測試。還有很關鍵的一點是,它們會對關鍵測試和 QA 流程,如測試用例設計、功能測試、測試數(shù)據(jù)管理等,進行高度自動化。

這些企業(yè)證實了,有效、連續(xù)、自動化的測試方式要遵循這幾大要點:

(1)盡早介入測試

測試或軟件 QA,一直以來都是軟件交付難題的最后一部分。在發(fā)布周期結束時測試和發(fā)現(xiàn)錯誤是常態(tài)。但這帶來了問題,因為間隔了一段時間后,開發(fā)人員可能不記得問題出現(xiàn)的背景,修復這些缺陷、改變設計和重新開發(fā)功能會導致更多的時間花在重新測試和回歸負載上,造成開發(fā)效率低下。因此,在軟件開發(fā)的的各個階段,越早進行測試,就能越早發(fā)現(xiàn)錯誤并且修復它們。測試帶來的反饋還可以幫助開發(fā)流程向前推進。

(2)測試用例自動化

在 PractiTest 和 Tea-Time with Testers 最近的一項調查中,軟件測試團隊發(fā)現(xiàn),過去已經足夠好的手動流程已經跟不上交付步伐。盡管 85% 的受訪者表示他們的公司使用自動化,但只有 19% 的受訪者在超過 50% 的測試用例中使用自動化。

如果出現(xiàn)測試任務耗時、重復、停機時間長,人工測試容易出現(xiàn)錯誤,需求、測試或任務風險低、穩(wěn)定等情況,測試用例應該自動化。

不過要注意,在測試用例自動化過程中,單元測試應該放在首位,其次是集成測試和功能測試。因為單元測試是最快的測試方法,更容易調試,修復成本很低,因此把單元測試作為自動化的最高優(yōu)先級。而集成測試主要測試接口或模塊,能夠提供反饋,確保一切都按預期工作,放在第二位。

(3)回歸測試自動化

回歸測試意味著軟件測試可以驗證最近的更改——無論是程序還是代碼——沒有對軟件的現(xiàn)有功能產生負面影響。利用測試自動化和持續(xù)測試工具來完成回歸測試,可以讓團隊專注于新功能以及創(chuàng)新。在流程的早期揭示缺陷,可以降低風險以及開發(fā)人員修復它們所需的時間。

很多的回歸測試自動化工具都可以跨 Web、移動、桌面、大型機、ERP、相關模擬器等進行測試,可以輕松添加或更新測試用例,快速運行端到端回歸測試,縮短測試周期、滿足最后期限和減少所需資源,同時提高軟件可靠性,為公司帶來巨大優(yōu)勢。

(4)做好測試數(shù)據(jù)管理

測試數(shù)據(jù)很重要,因為整個測試套件(包括手動測試和自動化測試)中的各種測試都需要測試數(shù)據(jù)。良好的測試數(shù)據(jù)可讓驗證常見或高價值用戶轉化歷程、測試邊緣用例、重現(xiàn)缺陷以及模擬錯誤。由于測試自動化可以更快、更頻繁地執(zhí)行測試,因此團隊還必須擁有工具來管理所創(chuàng)建的大量數(shù)據(jù)。

工具或平臺必不可少

利用特定的工具實現(xiàn)測試自動化是必不可少的。這個工具可以是一個簡單的測試框架,比如 Jest,也可以是一個特殊的軟件框架,比如 Selenium,甚至可以是一整個平臺——它可以幫助你完成你所想要做的一切。

一個好的工具會告訴你,自動化測試并沒有那么難。近期,飛算發(fā)布了飛算SoFlu全自動測試平臺,該平臺有三大功能特性:

1.測試生命周期管理。它提供測試用例管理、測試用例評審、測試計劃跟蹤和測試報告生成等測試生命周期管理相關功能;

2.測試數(shù)據(jù)管理。全自動測試平臺基于測試腳本與測試數(shù)據(jù)分離的思路,方便研發(fā)測試協(xié)同、方便自動化測試中的測試數(shù)據(jù)使用,支持 UI、接口等自動化工具快速可重復地使用;

3.精準回歸測試。它在項目測試時,可以自動識別所有變動的接口,自動查找接口關聯(lián)的所有測試用例,進行精準回歸測試。

曾經,飛算云智總裁陳定瑋對測試耗時長深有感觸:“以前,我們公司流傳過一句話:開發(fā)多久,測試就要多久。如果開發(fā)三個月,那么測試就要三個月。這樣,半年就過去了。因此,整個成本非常高。并且產品、開發(fā)和測試人員的思維模式和視角不同,溝通難度不小,最終搞得大家怨聲載道。"

現(xiàn)在,他帶領團隊開發(fā)的自動化測試平臺幾乎解決了測試中遇到的大部分問題。

比如,在進行性能則試前,必須先做好性能測試的搭建工作,一般包括硬件環(huán)境、軟件環(huán)境及網絡環(huán)境,這往往需要配置和開發(fā)工程師來協(xié)助完成。而在飛算SoFlu全自動測試平臺,僅需要一個測試人員,即使是一個新手,也完全可以搞定,因為資源池具備支持虛擬機模式,測試人員可以自己搭建虛擬機環(huán)境,在平臺上通過選擇虛擬機的類型來對接口進行性能測試。

測試是軟件開發(fā)生命周期的重要組成部分,測試“托后腿”折射出來的,可能是整個開發(fā)過程的管理問題。

飛算也看到了這一點,因此,不僅開發(fā)了全自動測試平臺,還推出了全自動開發(fā)平臺,未來還將推出全自動運維平臺,它們將共同組成飛算 SoFlu 全自動軟件工程平臺。通過飛算 SoFlu ,可以管理從需求、研發(fā)、測試、部署、上線到運維的整個軟件生命周期,真正實現(xiàn)了軟件工程開發(fā)、測試、運維全流程自動化。

（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）