DevOps 的目標(biāo)是以更快的方式交付軟件。如今,越來越多的企業(yè)正努力通過 DevOps 實(shí)踐提高生產(chǎn)力,加快發(fā)布周期。然而在DevOps 實(shí)踐中,開發(fā)人員專注于功能創(chuàng)建,而業(yè)務(wù)領(lǐng)導(dǎo)者則專注于交付,測試的重要性常常被忽略。這就導(dǎo)致,雖然交付過程的其他方面得到了簡化和加速,測試卻成為了軟件交付的瓶頸。
軟件交付的最大阻礙
GitLab 曾經(jīng)發(fā)起一項針對開發(fā)者和工程師的調(diào)查。調(diào)查發(fā)現(xiàn),有 52% 的受訪者認(rèn)為,與開發(fā)過程的其他部分相比,測試造成的延遲更多。
DevOps Review 也得出了相同的結(jié)論,63% 的受訪者表示,“測試”是導(dǎo)致軟件延遲交付的第一大因素。該調(diào)查主要針對實(shí)施 DevOps 企業(yè)的 IT 部門領(lǐng)導(dǎo)者。第二大阻礙軟件交付的因素是“計劃”,不過只有 32% 的受訪者如此認(rèn)為,遠(yuǎn)遠(yuǎn)低于站隊“測試”的人群。
軟件生產(chǎn)過程中的主要障礙在哪里?
為什么測試是一個如此可怕的瓶頸? 測試咨詢公司 Tricentis 的創(chuàng)始人 Wolfgang Platz 經(jīng)過調(diào)查后,總結(jié)了以下原因:
絕大多數(shù)測試(超過 80%)仍然是手動執(zhí)行的——在大型企業(yè)中甚至更多。
正在構(gòu)建、維護(hù)和執(zhí)行的測試用例中,大約 67% 是多余的,對工作沒有任何價值。
在具有重要測試自動化的企業(yè)中,測試人員將 17% 的時間用于處理誤報,另外 14% 的時間用于額外的維護(hù)任務(wù)。
超過一半的測試人員每周花費(fèi) 5 到 15 個小時處理測試數(shù)據(jù)(數(shù)據(jù)的平均等待時間約為2 周)。
84% 的測試經(jīng)常因測試環(huán)境訪問受限而延遲,測試環(huán)境的平均等待時間為32天。
從開始到結(jié)束——包括計劃、實(shí)施和測試,執(zhí)行回歸測試套件平均需要 16.5 天,但敏捷沖刺平均需要兩周時間。
現(xiàn)在,被測應(yīng)用程序平均與 52 個相關(guān)系統(tǒng)交互——這意味著單個端到端事務(wù)可以跨越從微服務(wù)和 API 到各種移動和瀏覽器界面、打包應(yīng)用程序(SAP、Salesforce、Oracle、ServiceNow…… )、自定義/遺留應(yīng)用程序和大型機(jī)。
如何破解測試難題?
隨著軟件發(fā)布變得越來越頻繁,采用傳統(tǒng)的測試方式已經(jīng)跟不上開發(fā)節(jié)奏。企業(yè)應(yīng)該怎么做,才能確保,測試不是軟件交付的瓶頸,而是更快的催化劑。
Forrester 的一項研究發(fā)現(xiàn),成功實(shí)踐 DevOps/敏捷開發(fā)的企業(yè),有一些共同點(diǎn),比如通過自動化端到端功能測試等方式將軟件測試轉(zhuǎn)變?yōu)槌掷m(xù)測試。還有很關(guān)鍵的一點(diǎn)是,它們會對關(guān)鍵測試和 QA 流程,如測試用例設(shè)計、功能測試、測試數(shù)據(jù)管理等,進(jìn)行高度自動化。
這些企業(yè)證實(shí)了,有效、連續(xù)、自動化的測試方式要遵循這幾大要點(diǎn):
(1)盡早介入測試
測試或軟件 QA,一直以來都是軟件交付難題的最后一部分。在發(fā)布周期結(jié)束時測試和發(fā)現(xiàn)錯誤是常態(tài)。但這帶來了問題,因為間隔了一段時間后,開發(fā)人員可能不記得問題出現(xiàn)的背景,修復(fù)這些缺陷、改變設(shè)計和重新開發(fā)功能會導(dǎo)致更多的時間花在重新測試和回歸負(fù)載上,造成開發(fā)效率低下。因此,在軟件開發(fā)的的各個階段,越早進(jìn)行測試,就能越早發(fā)現(xiàn)錯誤并且修復(fù)它們。測試帶來的反饋還可以幫助開發(fā)流程向前推進(jìn)。
(2)測試用例自動化
在 PractiTest 和 Tea-Time with Testers 最近的一項調(diào)查中,軟件測試團(tuán)隊發(fā)現(xiàn),過去已經(jīng)足夠好的手動流程已經(jīng)跟不上交付步伐。盡管 85% 的受訪者表示他們的公司使用自動化,但只有 19% 的受訪者在超過 50% 的測試用例中使用自動化。
如果出現(xiàn)測試任務(wù)耗時、重復(fù)、停機(jī)時間長,人工測試容易出現(xiàn)錯誤,需求、測試或任務(wù)風(fēng)險低、穩(wěn)定等情況,測試用例應(yīng)該自動化。
不過要注意,在測試用例自動化過程中,單元測試應(yīng)該放在首位,其次是集成測試和功能測試。因為單元測試是最快的測試方法,更容易調(diào)試,修復(fù)成本很低,因此把單元測試作為自動化的最高優(yōu)先級。而集成測試主要測試接口或模塊,能夠提供反饋,確保一切都按預(yù)期工作,放在第二位。
(3)回歸測試自動化
回歸測試意味著軟件測試可以驗證最近的更改——無論是程序還是代碼——沒有對軟件的現(xiàn)有功能產(chǎn)生負(fù)面影響。利用測試自動化和持續(xù)測試工具來完成回歸測試,可以讓團(tuán)隊專注于新功能以及創(chuàng)新。在流程的早期揭示缺陷,可以降低風(fēng)險以及開發(fā)人員修復(fù)它們所需的時間。
很多的回歸測試自動化工具都可以跨 Web、移動、桌面、大型機(jī)、ERP、相關(guān)模擬器等進(jìn)行測試,可以輕松添加或更新測試用例,快速運(yùn)行端到端回歸測試,縮短測試周期、滿足最后期限和減少所需資源,同時提高軟件可靠性,為公司帶來巨大優(yōu)勢。
(4)做好測試數(shù)據(jù)管理
測試數(shù)據(jù)很重要,因為整個測試套件(包括手動測試和自動化測試)中的各種測試都需要測試數(shù)據(jù)。良好的測試數(shù)據(jù)可讓驗證常見或高價值用戶轉(zhuǎn)化歷程、測試邊緣用例、重現(xiàn)缺陷以及模擬錯誤。由于測試自動化可以更快、更頻繁地執(zhí)行測試,因此團(tuán)隊還必須擁有工具來管理所創(chuàng)建的大量數(shù)據(jù)。
工具或平臺必不可少
利用特定的工具實(shí)現(xiàn)測試自動化是必不可少的。這個工具可以是一個簡單的測試框架,比如 Jest,也可以是一個特殊的軟件框架,比如 Selenium,甚至可以是一整個平臺——它可以幫助你完成你所想要做的一切。
一個好的工具會告訴你,自動化測試并沒有那么難。近期,飛算發(fā)布了飛算SoFlu全自動測試平臺,該平臺有三大功能特性:
1.測試生命周期管理。它提供測試用例管理、測試用例評審、測試計劃跟蹤和測試報告生成等測試生命周期管理相關(guān)功能;
2.測試數(shù)據(jù)管理。全自動測試平臺基于測試腳本與測試數(shù)據(jù)分離的思路,方便研發(fā)測試協(xié)同、方便自動化測試中的測試數(shù)據(jù)使用,支持 UI、接口等自動化工具快速可重復(fù)地使用;
3.精準(zhǔn)回歸測試。它在項目測試時,可以自動識別所有變動的接口,自動查找接口關(guān)聯(lián)的所有測試用例,進(jìn)行精準(zhǔn)回歸測試。
曾經(jīng),飛算云智總裁陳定瑋對測試耗時長深有感觸:“以前,我們公司流傳過一句話:開發(fā)多久,測試就要多久。如果開發(fā)三個月,那么測試就要三個月。這樣,半年就過去了。因此,整個成本非常高。并且產(chǎn)品、開發(fā)和測試人員的思維模式和視角不同,溝通難度不小,最終搞得大家怨聲載道。"
現(xiàn)在,他帶領(lǐng)團(tuán)隊開發(fā)的自動化測試平臺幾乎解決了測試中遇到的大部分問題。
比如,在進(jìn)行性能則試前,必須先做好性能測試的搭建工作,一般包括硬件環(huán)境、軟件環(huán)境及網(wǎng)絡(luò)環(huán)境,這往往需要配置和開發(fā)工程師來協(xié)助完成。而在飛算SoFlu全自動測試平臺,僅需要一個測試人員,即使是一個新手,也完全可以搞定,因為資源池具備支持虛擬機(jī)模式,測試人員可以自己搭建虛擬機(jī)環(huán)境,在平臺上通過選擇虛擬機(jī)的類型來對接口進(jìn)行性能測試。
測試是軟件開發(fā)生命周期的重要組成部分,測試“托后腿”折射出來的,可能是整個開發(fā)過程的管理問題。
飛算也看到了這一點(diǎn),因此,不僅開發(fā)了全自動測試平臺,還推出了全自動開發(fā)平臺,未來還將推出全自動運(yùn)維平臺,它們將共同組成飛算 SoFlu 全自動軟件工程平臺。通過飛算 SoFlu ,可以管理從需求、研發(fā)、測試、部署、上線到運(yùn)維的整個軟件生命周期,真正實(shí)現(xiàn)了軟件工程開發(fā)、測試、運(yùn)維全流程自動化。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
