如何通過5個(gè)步驟快速實(shí)現(xiàn)質(zhì)量

---

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

每個(gè)人都想要質(zhì)量更高，速度更快的軟件。從競爭加劇和市場壓力，功能和復(fù)雜性增加到對產(chǎn)品質(zhì)量、安全性和可靠性的更高期望，對現(xiàn)代軟件開發(fā)團(tuán)隊(duì)的需求是巨大的。敏捷開發(fā)方法之所以經(jīng)常被人們追捧，是因?yàn)樗型麑ψ兓龀龈玫捻憫?yīng)，并更好地滿足客戶需求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

利用應(yīng)用程序依賴項(xiàng)的服務(wù)虛擬化，可以在開發(fā)生命周期的更早階段進(jìn)行自動(dòng)化API測試。自動(dòng)化程度的提高和漏洞的早期發(fā)現(xiàn)對于成功至關(guān)重要。提早進(jìn)行API測試有助于發(fā)現(xiàn)系統(tǒng)的關(guān)鍵方面，例如性能和體系結(jié)構(gòu)健全性。這也是安全測試的重要階段。

5.利用變化影響分析來加速敏捷

通過基于每個(gè)構(gòu)建的變更影響分析來加速敏捷開發(fā)，以了解每次新迭代引入的風(fēng)險(xiǎn)的詳細(xì)信息。變更影響分析提供的分析對于使測試僅集中于絕對需要測試的內(nèi)容而不是其他方面使用的shot彈槍方法至關(guān)重要。

只有通過基于數(shù)據(jù)的明智決策，才能進(jìn)行真正的連續(xù)測試。使開發(fā)團(tuán)隊(duì)專注于最少的測試集，以確保每次迭代都覆蓋適當(dāng)?shù)姆秶@是使敏捷性回歸敏捷開發(fā)方法的關(guān)鍵。

改善之路

毫不奇怪，最好的入門方法是檢查測試金字塔，然后評(píng)估項(xiàng)目當(dāng)前的位置。是否有基于每個(gè)構(gòu)建運(yùn)行的自動(dòng)化單元測試的堅(jiān)實(shí)基礎(chǔ)？是否有盡可能多的產(chǎn)品API經(jīng)過自動(dòng)化測試？是否使用虛擬化？測試是否依賴于一套復(fù)雜的手動(dòng)UI測試套件，這些套件要等到系統(tǒng)即將完成后才能運(yùn)行？改進(jìn)之路基于構(gòu)建適當(dāng)?shù)臏y試金字塔，自動(dòng)化以及數(shù)據(jù)收集和分析。

現(xiàn)代軟件開發(fā)團(tuán)隊(duì)承受的巨大壓力使按時(shí)按規(guī)范構(gòu)建產(chǎn)品變得困難。諸如敏捷開發(fā)之類的新開發(fā)方法已幫助團(tuán)隊(duì)專注于為客戶構(gòu)建正確的東西，但是項(xiàng)目仍為時(shí)已晚且容易出錯(cuò)，而測試是繼續(xù)困擾現(xiàn)代開發(fā)方法的開發(fā)的關(guān)鍵方面。要獲得重大改進(jìn)，請采用自動(dòng)化單元測試的堅(jiān)實(shí)基礎(chǔ)，并盡早（通常通過服務(wù)虛擬化）執(zhí)行API測試。而且不要忘記，通過使用來自高級(jí)軟件測試分析的數(shù)據(jù)來驅(qū)動(dòng)測試管理，測試結(jié)果會(huì)大大改善。