敏捷和DevOps通常是作為一種以更少的資源來更快地完成軟件的方式而出售的。但是質(zhì)量呢？在本文中，學(xué)習(xí)如何通過連續(xù)測試快速實現(xiàn)質(zhì)量。

每個人都想要質(zhì)量更高，速度更快的軟件。從競爭加劇和市場壓力，功能和復(fù)雜性增加到對產(chǎn)品質(zhì)量、安全性和可靠性的更高期望，對現(xiàn)代軟件開發(fā)團隊的需求是巨大的。敏捷開發(fā)方法之所以經(jīng)常被人們追捧，是因為它有望對變化做出更好的響應(yīng)，并更好地滿足客戶需求。

但是，敏捷和DevOps經(jīng)常被作為一種用更少的資源來更快地完成軟件的方式而出售，盡管這并不是故意的。實際上，隨著多達70％的IT項目失敗或未達到目標，精明的開發(fā)團隊正在尋求改善其開發(fā)實踐，以便他們不僅可以成功完成項目，而且可以為未來的迭代和產(chǎn)品創(chuàng)建可重復(fù)的流程。在本文中，我們將討論如何實現(xiàn)敏捷和迭代方法所需的敏捷性，而不僅要獲得最終產(chǎn)品，還要達到和超過質(zhì)量和安全性目標的產(chǎn)品。

持續(xù)測試是快速質(zhì)量的答案

事實證明，測試既是問題所在，也是更快地獲得更好質(zhì)量的解決方案。在敏捷過程中，可以縮減許多開發(fā)步驟，以便創(chuàng)建合理的功能來進行設(shè)計和實現(xiàn)；但是，集成新功能存在風險，測試范圍尚不清楚。正如我在上一篇文章中談到的那樣，測試是軟件團隊在采用敏捷方法時費勁的關(guān)鍵原因之一。團隊失去了他們追求的敏捷性，因為他們陷入了過多或不足的測試困境。

持續(xù)測試被視為解決采用DevOps和敏捷開發(fā)的軟件團隊所面臨問題的解決方案。 Wikipedia將持續(xù)測試定義為“……作為軟件交付管道的一部分執(zhí)行自動測試的過程，以獲取與候選軟件版本相關(guān)的業(yè)務(wù)風險的即時反饋。”盡管定義簡單明了，但隨著時間的推移進行連續(xù)測試并對其進行優(yōu)化是完全另一回事，而這就是我今天將重點介紹的內(nèi)容。

將您的冰淇淋蛋筒變成金字塔

理想的測試金字塔定義了在項目上投入時間和精力的最佳位置。在理想的金字塔中，您將寶貴的時間和精力投入到金字塔基礎(chǔ)上的全面的單元測試套件中，該單元測試由API和服務(wù)測試支持，而在金字塔的頂部，數(shù)量較少的系統(tǒng)和基于GUI的測試。

但是，這個金字塔經(jīng)常被倒置為所謂的冰淇淋蛋筒。團隊在易碎和復(fù)雜的系統(tǒng)級GUI測試上花費了很多時間和精力，這些測試需要實現(xiàn)和集成完整的功能-導(dǎo)致在SDLC的早期階段無法連續(xù)執(zhí)行測試。成功進行連續(xù)測試的關(guān)鍵是融化冰激凌，并專注于創(chuàng)建可在開發(fā)人員實施新功能時連續(xù)執(zhí)行的自動化單元和API測試。

通過連續(xù)測試快速實現(xiàn)質(zhì)量的五個步驟

1.建立單元測試的基礎(chǔ)

通過自動化創(chuàng)建，執(zhí)行和維護測試的過程，為單元測試奠定基礎(chǔ)。只有使單元測試的工作更易于創(chuàng)建和維護，開發(fā)團隊才能對所有組件采用項目范圍內(nèi)的單元測試。

在測試創(chuàng)建、執(zhí)行和管理中均采用測試自動化，從而擴展了當前的單元測試套件，以包含盡可能多的產(chǎn)品代碼。

2.避免依賴后期UI中心測試

避免依賴于后期的、脆弱的、以用戶界面為中心的測試，這只會導(dǎo)致診斷和修復(fù)最耗時，最昂貴。與其專注于自動化所有手動測試場景，不如為單元和API測試打下堅實的基礎(chǔ)，以確保與UI進行通信的體系結(jié)構(gòu)首先是牢固的。

盡管系統(tǒng)級測試仍然很重要并且是必需的，但它不應(yīng)該是第一位的。現(xiàn)在也不是時候發(fā)現(xiàn)關(guān)鍵的體系結(jié)構(gòu)、性能和安全性問題。軟件團隊可以通過建立單元和API測試的堅實基礎(chǔ)來減少對這些UI和系統(tǒng)測試的依賴。通過遵循此處的其他建議，應(yīng)在系統(tǒng)級測試開始之前對許多系統(tǒng)進行充分的驗證。

確保還使用靜態(tài)分析來分析整個代碼庫，包括舊代碼和第三方代碼，以幫助檢測測試可能遺漏的錯誤和安全漏洞。靜態(tài)分析對于執(zhí)行項目編碼標準也很重要。

3.了解整個測試金字塔的代碼覆蓋率

了解整個金字塔的上下代碼覆蓋范圍以及對需求/用戶故事的可追溯性，因為沒有它，開發(fā)團隊就不會真正知道測試過什么和沒有測試過什么。另外，不了解測試范圍意味著不知道要在金字塔的每個級別上測試什么，這意味著即使是很小的更改也需要進行大量測試，這會使整個過程陷入困境。請參閱我以前的有關(guān)基于變更的測試的文章。

4.通過服務(wù)虛擬化向左移動

利用應(yīng)用程序依賴項的服務(wù)虛擬化，可以在開發(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ǔ)？是否有盡可能多的產(chǎn)品API經(jīng)過自動化測試？是否使用虛擬化？測試是否依賴于一套復(fù)雜的手動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)鍵方面。要獲得重大改進，請采用自動化單元測試的堅實基礎(chǔ)，并盡早（通常通過服務(wù)虛擬化）執(zhí)行API測試。而且不要忘記，通過使用來自高級軟件測試分析的數(shù)據(jù)來驅(qū)動測試管理，測試結(jié)果會大大改善。