在過去的十年中,對軟件開發的需求已急劇發展。軟件已成爲公司得到競爭優點的關鍵優點,特別是若是您的公司屬於SaaS範疇。經過在SDLC中實施瀑布等傳統流程,組織如今正在向敏捷過渡,以便以更快的速度在市場上交付軟件。爲了應對RAD(快速應用程序開發),出現了許多新方法,例如CI / CD,DevOps,Shift左鍵測試,爲了更好地構建,開發和優化軟件交付。
即使如此,試圖同時保持質量和速度仍然是一個真正的挑戰,測試方法能夠幫助或下降整個加速過程。今天,咱們將探討在DevOps中進行連續測試的重要性。在本文中,將討論什麼是連續測試?還將幫助消除與連續測試有關的錯誤觀點。咱們還將探討DevOps中連續測試所涉及的挑戰,以及最佳實踐,以幫助您以專業人員的身份執行連續測試過程。前端
什麼是連續測試?
連續測試是端到端的質量維護過程,其中團隊不斷進行各類自動化測試。同時,分析與最新軟件開發相關的各類業務風險,併爲開發人員提供快速反饋。這種反饋有助於在早期階段識別缺陷和錯誤,並鼓勵開發人員在SDLC(軟件開發生命週期)的後續階段中優化其代碼。java
與在開發週期結束時交付結果的傳統測試方法不一樣,連續測試在多個階段進行,包括開發,集成,過渡環境和生產環境。連續測試可確保在開發過程當中儘早解決缺陷和問題,從而提升總體質量並節省大量時間和金錢。編程
連續測試的好處
常規測試技術在很大程度上取決於手動測試和須要按期更新的自動測試,這可能會阻礙交付過程的速度。這就是諸如敏捷,DevOps,持續集成和持續交付之類的現代方法論所探討的內容。後端
在DevOps中實施連續測試能夠經過如下方式取得成果:瀏覽器
- 持續風險分析:可能有一個版本的版本(候選發佈)經過全部可用測試,但沒有準備由業務負責人發佈,持續測試將在每一個階段評估這些風險。
- 牢記用戶體驗:連續測試是一個能夠輕鬆適應不斷變化的客戶要求的過程。經過根據客戶反饋在應用程序中進行不斷更新,將持續測試與DevOps集成在一塊兒能夠幫助使您的軟件變得更加健壯和穩定。從客戶的角度來看,您能夠靈活地編寫有效的測試用例。就用戶體驗進行正確的測試對於評估前端和後端全部相關技術的最終用戶體驗相當重要。
- 幫助安全性:持續測試創建了一個支持系統,該系統可確保應用程序免受意外更改和攻擊的安全性,這些更改和攻擊在部署後也可能會遇到。在加速的開發過程當中,即便在軟件出現故障的狀況下,它也能夠確保系統穩定且可恢復。
- 從一開始就進行持續集成:持續測試指望測試從開發過程的早期就被嵌入,而不是在發佈以前就進行處理。測試不斷集成到軟件交付管道和DevOps工具鏈中。
- 涵蓋功能和非功能測試:連續測試可模擬全部類型的功能測試,例如跨瀏覽器測試,迴歸測試,集成測試,API測試,單元測試;還有非功能性測試,例如可用性測試,安全性測試,可靠性測試,可伸縮性測試等等。
- 及時的反饋而不會形成任何瓶頸:連續測試會在交付管道的適當階段評估現代體系結構的每一層,並在交付管道的正確階段提供可行的反饋,而不會形成冗長的排隊。
- 節省時間,金錢和資源:及早發現bug不只能夠節省發佈窗口的資源,還能夠幫助您節省大量金錢和資源。持續測試經過使用諸如開發測試或左移測試之類的缺陷預防策略,減小了用於發現和修復缺陷的時間和資源。
與DevOps中的持續測試有關的錯誤觀點
- 「將致使測試人員失業」:測試人員對框架有一種見解:他們能夠看到客戶如何與之交互。儘管自動化的發展很是迅速,但它尚未達到徹底取代手動測試的水平。引入自動化的所有目的是爲手動測試人員提供更多的時間,以提出更有效的測試方案。仍然存在重要的手動活動,例如探索性測試和可用性測試,測試人員應該持續執行它們,這是他們工做的特徵。固然,他們須要得到做爲軟件測試人員的有效技能。
- 「只有測試人員才能爲連續測試作出貢獻」:連續測試的某些或所有部分對於任何類型的團隊及其團隊成員都是相當重要的。例如,讓測試人員與開發人員並肩做戰可能使他們可以建立高級的自動化測試套件。這樣,開發人員就有機會理解測試人員的觀點,而且測試人員還能夠學習和提升他們的測試自動化技能。
- 「連續測試意味着連續執行測試用例」:正如我已經解釋過的,連續測試還有不少其餘功能。它不只執行功能測試和非功能測試,並且連續測試還涵蓋了從左移(單元,組件,覆蓋範圍,綜合風險評估)到「右移」(監視/ APM,生產中的測試,客戶體驗,虛擬化測試)。
- 「連續測試和自動化測試是相同的」:經過自動化,企業正在嘗試實施敏捷的測試策略:「儘早測試,常常測試,處處測試」。冗長的測試腳本會自動執行並按期進行更新,藉助自動化測試工具,自動化測試可用於執行連續測試,從而減小了人工錯誤。可是,請記住,自動化測試和測試自動化稍有不一樣。經過測試自動化,確保經過管道進行整個交付過程的速度和效率。自動化測試能夠自動化,傳統的測試方法能夠自動化管理和跟蹤不一樣測試的整個過程。連續測試包括自動化測試和自動化測試,以保持質量和速度。自動化測試是連續測試的子集,不該將它們混淆。
DevOps中連續測試的挑戰
- 一次性鉅額投資:構建測試環境和創建自動化框架須要大量的專業知識和精力。得到測試自動化範圍的最大困難是與創建有效的自動化框架相關的時間和成本。爲了實現測試自動化項目,JIRA, Asana等全面的測試管理平臺簡化了此過程。
- 測試普遍的複雜體系結構:現代應用程序普遍分佈,敏捷和並行開發流程的採用正在增長,端到端功能測試一般要求訪問第三方服務或大型機,這些服務或大型機僅可用於容量有限或在不方便的時間。能夠經過使用服務虛擬化模擬缺乏或不存在依賴項的AUT(被測應用程序)交互來解決此問題。它還能夠用於確保各類測試運行中的數據,性能和行爲是一致的。
- 不可擴展的測試套件:團隊避免進行連續測試的另外一個緣由是其基礎架構的可伸縮性不足以連續運行測試套件。經過將測試集中於公司的優先級,拆分測試基礎並將測試與應用程序發佈自動化工具並行化,能夠解決此問題。
團隊之間缺少協調:尋找合適的熟練自動化專家也是一項挑戰。DevOps中的連續測試要求產品經理,開發人員和測試人員之間進行高度協調。協調是大多數公司奮鬥的領域。自古以來,它們之間就存在文化上的脫節。質量檢查團隊處於孤立狀態,能夠經過適當的員工敬業度策略和意識來解決。安全
成功在DevOps中進行連續測試的主要說明
- 建立強大的用戶故事:持續測試意味着從一開始就進行質量和粒度測試。確保得到良好的業務需求以開始開發。確保用戶故事是可測試的,並具備良好的接受標準,採用更具探索性的態度進行手動測試可能有助於得到良好的結果。
- 協做:從文化的角度來看,若是每一個人都表現出團隊的素質和合做,那麼在DevOps中進行連續測試就是成功的。在開始編碼或根據須要編寫測試以前,先描述測試用例。不管如何,開發人員和測試自動化架構師應共同努力,以確保優化用於測試自動化的代碼。團隊還可使用Slack之類的工具來合做測試結果,以加快反饋和調試速度。
- 保持簡單和邏輯:減小沒必要要的測試對象,例如普遍的測試計劃和測試用例,並減小測試等待時間。測試應該是一致的,增量的和可重複的;結果應可量化且有意義。
- 處處進行測試:測試必須在交付管道的全部階段進行,涵蓋整個環境的全部方面,不管是生產環境仍是QA環境。經過在每一個階段進行測試並不斷向開發人員提供反饋,能夠幫助提升軟件開發的質量。
- 自動化測試:自動化測試對在DevOps中成功實施連續測試起着重要做用。堅持測試自動化金字塔,並專一於自動化測試腳本以實現Web應用程序中的最新更新相當重要。不能實現100%的自動化,可是您可使過程自動化的程度越高,執行連續測試的速度就越快。
- 擁抱CI / CD(持續集成/持續交付):開發人員應採用持續集成-經過天天屢次將代碼集成到共享存儲庫(例如Bitbucket和GitHub)中。當使用CI服務器實施自動化測試時,每一個構建都會當即開始連續測試。警告,不管測試結果是否經過,均可以實時直接發送給開發團隊。經過按期集成,您能夠更輕鬆地快速檢測和定位錯誤。一旦完成全部測試,就能夠絕不猶豫地將更新持續交付生產。
- 選擇基於GUI的API:DevOps和Agile團隊以較短的發佈週期,快速的反饋循環和頻繁的更改而工做,很難維護GUI測試。GUI測試須要更長的時間來提供反饋,而且須要大量的返工。對於具備多層體系結構的現代應用程序,重要的是驗證後端服務和功能路徑。API測試更穩定,建議一樣使用。GUI測試僅限於系統測試,移動測試,黑盒測試;API測試涉及許多實踐,例如單元測試,功能迴歸測試,負載測試,安全測試,Web互操做性測試等等。
超越自動化的思考:就像人的大腦工做同樣,實施人工智能(AI)和設計智能機器(藉助IoT,量子計算,機器人等),對交付管道的每一個階段進行啓發式思考,能夠加速整個流程的發展。 SDLC。服務器
結論
爲了迅速行動並取得更快的結果,咱們必須保證咱們從一開始就製造正確的產品。修改產品以進行錯誤修復歷來都不是一件容易的事,由於後期在管道中發現的缺陷修復成本很高。相反,必須採用正確的方式進行測試,並使用同步的交付過程(CI / CD,DevOps),測試方法(API測試,服務虛擬化),穩定的測試平臺以及自動化測試的功能和非功能方面。架構
將團隊之間傳統的脫節融合在一塊兒,測試人員和開發人員能夠學習並執行具備適當專業知識的成功自動化腳本,並輕鬆優化軟件體系結構。框架
DevOps中的連續測試是持續質量的主要方法(並不是惟一方法)。這是經過持續交付向更高質量產品邁出的一步。工具
一旦在DevOps中實現了連續測試,就會出現一個理想的機會,能夠考慮採用不一樣的方法,這些方法不包括運行測試以識別缺陷或問題,而是能夠防止編碼。這樣,鼓勵開發人員從一開始就構建完好陷的最佳產品。
技術類文章精選
非技術文章精選