原創(chuàng)|使用教程|編輯:鄭恭琳|2021-01-20 14:27:44.153|閱讀 224 次
概述:敏捷和DevOps通常是作為一種以更少的資源來更快地完成軟件的方式而出售的。但是質(zhì)量呢?在本文中,學習如何通過連續(xù)測試快速實現(xiàn)質(zhì)量。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關(guān)鏈接:
敏捷和DevOps通常是作為一種以更少的資源來更快地完成軟件的方式而出售的。但是質(zhì)量呢?在本文中,學習如何通過連續(xù)測試快速實現(xiàn)質(zhì)量。
每個人都想要質(zhì)量更高,速度更快的軟件。從競爭加劇和市場壓力,功能和復雜性增加到對產(chǎn)品質(zhì)量、安全性和可靠性的更高期望,對現(xiàn)代軟件開發(fā)團隊的需求是巨大的。敏捷開發(fā)方法之所以經(jīng)常被人們追捧,是因為它有望對變化做出更好的響應,并更好地滿足客戶需求。
但是,敏捷和DevOps經(jīng)常被作為一種用更少的資源來更快地完成軟件的方式而出售,盡管這并不是故意的。實際上,隨著多達70%的IT項目失敗或未達到目標,精明的開發(fā)團隊正在尋求改善其開發(fā)實踐,以便他們不僅可以成功完成項目,而且可以為未來的迭代和產(chǎn)品創(chuàng)建可重復的流程。在本文中,我們將討論如何實現(xiàn)敏捷和迭代方法所需的敏捷性,而不僅要獲得最終產(chǎn)品,還要達到和超過質(zhì)量和安全性目標的產(chǎn)品。
事實證明,測試既是問題所在,也是更快地獲得更好質(zhì)量的解決方案。在敏捷過程中,可以縮減許多開發(fā)步驟,以便創(chuàng)建合理的功能來進行設計和實現(xiàn);但是,集成新功能存在風險,測試范圍尚不清楚。正如我在上一篇文章中談到的那樣,測試是軟件團隊在采用敏捷方法時費勁的關(guān)鍵原因之一。團隊失去了他們追求的敏捷性,因為他們陷入了過多或不足的測試困境。
持續(xù)測試被視為解決采用DevOps和敏捷開發(fā)的軟件團隊所面臨問題的解決方案。 Wikipedia將持續(xù)測試定義為“……作為軟件交付管道的一部分執(zhí)行自動測試的過程,以獲取與候選軟件版本相關(guān)的業(yè)務風險的即時反饋?!北M管定義簡單明了,但隨著時間的推移進行連續(xù)測試并對其進行優(yōu)化是完全另一回事,而這就是我今天將重點介紹的內(nèi)容。
理想的測試金字塔定義了在項目上投入時間和精力的最佳位置。在理想的金字塔中,您將寶貴的時間和精力投入到金字塔基礎上的全面的單元測試套件中,該單元測試由API和服務測試支持,而在金字塔的頂部,數(shù)量較少的系統(tǒng)和基于GUI的測試。
但是,這個金字塔經(jīng)常被倒置為所謂的冰淇淋蛋筒。團隊在易碎和復雜的系統(tǒng)級GUI測試上花費了很多時間和精力,這些測試需要實現(xiàn)和集成完整的功能-導致在SDLC的早期階段無法連續(xù)執(zhí)行測試。成功進行連續(xù)測試的關(guān)鍵是融化冰激凌,并專注于創(chuàng)建可在開發(fā)人員實施新功能時連續(xù)執(zhí)行的自動化單元和API測試。
1.建立單元測試的基礎
通過自動化創(chuàng)建,執(zhí)行和維護測試的過程,為單元測試奠定基礎。只有使單元測試的工作更易于創(chuàng)建和維護,開發(fā)團隊才能對所有組件采用項目范圍內(nèi)的單元測試。
在測試創(chuàng)建、執(zhí)行和管理中均采用測試自動化,從而擴展了當前的單元測試套件,以包含盡可能多的產(chǎn)品代碼。
2.避免依賴后期UI中心測試
避免依賴于后期的、脆弱的、以用戶界面為中心的測試,這只會導致診斷和修復最耗時,最昂貴。與其專注于自動化所有手動測試場景,不如為單元和API測試打下堅實的基礎,以確保與UI進行通信的體系結(jié)構(gòu)首先是牢固的。
盡管系統(tǒng)級測試仍然很重要并且是必需的,但它不應該是第一位的。現(xiàn)在也不是時候發(fā)現(xiàn)關(guān)鍵的體系結(jié)構(gòu)、性能和安全性問題。軟件團隊可以通過建立單元和API測試的堅實基礎來減少對這些UI和系統(tǒng)測試的依賴。通過遵循此處的其他建議,應在系統(tǒng)級測試開始之前對許多系統(tǒng)進行充分的驗證。
確保還使用靜態(tài)分析來分析整個代碼庫,包括舊代碼和第三方代碼,以幫助檢測測試可能遺漏的錯誤和安全漏洞。靜態(tài)分析對于執(zhí)行項目編碼標準也很重要。
3.了解整個測試金字塔的代碼覆蓋率
了解整個金字塔的上下代碼覆蓋范圍以及對需求/用戶故事的可追溯性,因為沒有它,開發(fā)團隊就不會真正知道測試過什么和沒有測試過什么。另外,不了解測試范圍意味著不知道要在金字塔的每個級別上測試什么,這意味著即使是很小的更改也需要進行大量測試,這會使整個過程陷入困境。請參閱我以前的有關(guān)基于變更的測試的文章。
4.通過服務虛擬化向左移動
利用應用程序依賴項的服務虛擬化,可以在開發(fā)生命周期的更早階段進行自動化API測試。自動化程度的提高和漏洞的早期發(fā)現(xiàn)對于成功至關(guān)重要。提早進行API測試有助于發(fā)現(xiàn)系統(tǒng)的關(guān)鍵方面,例如性能和體系結(jié)構(gòu)健全性。這也是安全測試的重要階段。
5.利用變化影響分析來加速敏捷
通過基于每個構(gòu)建的變更影響分析來加速敏捷開發(fā),以了解每次新迭代引入的風險的詳細信息。變更影響分析提供的分析對于使測試僅集中于絕對需要測試的內(nèi)容而不是其他方面使用的shot彈槍方法至關(guān)重要。
只有通過基于數(shù)據(jù)的明智決策,才能進行真正的連續(xù)測試。使開發(fā)團隊專注于最少的測試集,以確保每次迭代都覆蓋適當?shù)姆秶@是使敏捷性回歸敏捷開發(fā)方法的關(guān)鍵。
毫不奇怪,最好的入門方法是檢查測試金字塔,然后評估項目當前的位置。是否有基于每個構(gòu)建運行的自動化單元測試的堅實基礎?是否有盡可能多的產(chǎn)品API經(jīng)過自動化測試?是否使用虛擬化?測試是否依賴于一套復雜的手動UI測試套件,這些套件要等到系統(tǒng)即將完成后才能運行?改進之路基于構(gòu)建適當?shù)臏y試金字塔,自動化以及數(shù)據(jù)收集和分析。
現(xiàn)代軟件開發(fā)團隊承受的巨大壓力使按時按規(guī)范構(gòu)建產(chǎn)品變得困難。諸如敏捷開發(fā)之類的新開發(fā)方法已幫助團隊專注于為客戶構(gòu)建正確的東西,但是項目仍為時已晚且容易出錯,而測試是繼續(xù)困擾現(xiàn)代開發(fā)方法的開發(fā)的關(guān)鍵方面。要獲得重大改進,請采用自動化單元測試的堅實基礎,并盡早(通常通過服務虛擬化)執(zhí)行API測試。而且不要忘記,通過使用來自高級軟件測試分析的數(shù)據(jù)來驅(qū)動測試管理,測試結(jié)果會大大改善。
將您的冰淇淋蛋筒變成金字塔
通過連續(xù)測試快速實現(xiàn)質(zhì)量的五個步驟
改善之路
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn