大家好角塑，我是阿薩蔫磨。最近幾年，敏捷開發(fā)特別火圃伶，和敏捷開發(fā)對應(yīng)的敏捷測試是什么呢堤如？ 今天阿薩簡單給大家聊一聊。

現(xiàn)代開發(fā)團(tuán)隊(duì)如何在開發(fā)的同時(shí)進(jìn)行測試窒朋，將測試人員合并到開發(fā)團(tuán)隊(duì)中搀罢，并在每次產(chǎn)品迭代中創(chuàng)建持續(xù)的反饋循環(huán)，以將質(zhì)量“內(nèi)置”到他們的代碼中侥猩。

敏捷團(tuán)隊(duì)一般都要求在幾周內(nèi)向客戶發(fā)布新特性榔至，而不是幾個(gè)月或幾年。質(zhì)量對于敏捷方法來說是至關(guān)重要的欺劳，因?yàn)樗闹饕P(guān)注點(diǎn)是滿足客戶的需求唧取。敏捷測試的最大挑戰(zhàn)在于如何隨著開發(fā)速度的提高而快速而全面地測試功能。

什么是敏捷測試?

敏捷測試在開發(fā)項(xiàng)目開始時(shí)開始划提，涉及到測試和開發(fā)之間的持續(xù)集成兵怯。傳統(tǒng)開發(fā)模式下，測試是在編碼階段之后的獨(dú)立活動;在敏捷中腔剂，測試是連續(xù)的媒区，將測試人員置于產(chǎn)品所有者和開發(fā)人員之間。敏捷測試創(chuàng)建了一個(gè)持續(xù)的反饋循環(huán)掸犬，幫助開發(fā)人員改進(jìn)他們的代碼袜漩。

敏捷測試的特點(diǎn):

1. 與產(chǎn)品負(fù)責(zé)人溝通——測試人員與產(chǎn)品負(fù)責(zé)人互動，以明確建立項(xiàng)目期望湾碎，因此他們可以幫助開發(fā)人員與產(chǎn)品開發(fā)里程碑以及設(shè)計(jì)圖保持一致并滿足客戶需求宙攻。

2.與開發(fā)人員密切互動—測試與開發(fā)過程相關(guān)聯(lián)。測試人員是開發(fā)團(tuán)隊(duì)的一部分介褥，他們報(bào)告可能影響用戶的質(zhì)量問題座掘，并建議如何改進(jìn)解決方案。

3. 整個(gè)團(tuán)隊(duì)都參與到質(zhì)量保證中——整個(gè)團(tuán)隊(duì)都對質(zhì)量充滿熱情柔滔，開發(fā)人員為更好的測試過程構(gòu)建單元測試用例溢陪，并提高審計(jì)的質(zhì)量。開發(fā)人員還遵循測試人員對測試需求和代碼改進(jìn)的建議睛廊。

敏捷測試原則

指導(dǎo)敏捷測試的主要原則有八個(gè):

1.持續(xù)測試——敏捷團(tuán)隊(duì)定期執(zhí)行測試形真，以確保產(chǎn)品在不斷地發(fā)展。測試與開發(fā)一起進(jìn)行超全。

2. 持續(xù)反饋——測試人員為團(tuán)隊(duì)成員提供持續(xù)的反饋咆霜。成員定期收到關(guān)于質(zhì)量而不是需求的反饋邓馒。

3. 全員質(zhì)量負(fù)責(zé)——包括整個(gè)團(tuán)隊(duì)的測試人員、開發(fā)人員和業(yè)務(wù)分析人員都在測試軟件蛾坯。

4. 快速反饋——業(yè)務(wù)團(tuán)隊(duì)參與每一次迭代;持續(xù)的反饋減少了獲得開發(fā)工作反饋的時(shí)間光酣。

5. 高水平的軟件質(zhì)量團(tuán)隊(duì)——高水平的軟件質(zhì)量團(tuán)隊(duì)測試軟件，以確保代碼干凈緊湊脉课。通過定期的軟件測試救军，問題和漏洞可以很容易地在開發(fā)的同一迭代中被發(fā)現(xiàn)和修復(fù)。

6. 可重用的清單——文檔較少的團(tuán)隊(duì)使用可重用的清單下翎。敏捷開發(fā)關(guān)注的是當(dāng)前的客戶需求缤言，而不是全面的、文檔化的需求和說明视事。

7. 提前評估——測試驅(qū)動的測試人員在實(shí)現(xiàn)時(shí)評估產(chǎn)品胆萧，而不是在實(shí)現(xiàn)之后評估產(chǎn)品(就像傳統(tǒng)測試方法的情況一樣)。

8. 客戶滿意度——客戶在開發(fā)過程中接觸到他們的產(chǎn)品俐东。他們可以在開發(fā)過程中調(diào)整和更新需求跌穗。測試可以修改為更新的需求。

什么是敏捷測試象限?

Image

敏捷測試可以使用由Janet Gregory和Lisa Crispin創(chuàng)建的象限系統(tǒng)進(jìn)行簡化虏辫。象限為測試提供了一種分類蚌吸，可以幫助測試人員回答諸如“要運(yùn)行哪個(gè)測試?”，“什么時(shí)候運(yùn)行測試?”和“如何運(yùn)行測試?”

象限1:與代碼質(zhì)量相關(guān)的測試砌庄，包括自動化測試羹唠，如單元測試和組件測試。

象限2:專注于產(chǎn)品業(yè)務(wù)相關(guān)方面的測試娄昆，通常是手動和自動功能測試佩微。這些包括原型、功能測試和場景的測試示例萌焰。

象限3 ：這個(gè)象限為象限1和象限2中的測試提供反饋哺眯。團(tuán)隊(duì)、業(yè)務(wù)所有者甚至客戶都以現(xiàn)實(shí)的方式使用產(chǎn)品來測試用戶體驗(yàn)和衡量業(yè)務(wù)結(jié)果扒俯。

象限4:測試非功能性需求奶卓，包括安全性、兼容性和穩(wěn)定性撼玄。象限4中使用的測試包括壓力夺姑、性能和基礎(chǔ)結(jié)構(gòu)測試。

使用敏捷測試象限來定義測試策略

在計(jì)劃一個(gè)新版本或沖刺時(shí)互纯，可以使用以下流程來確定要關(guān)注哪些測試:

作為一個(gè)團(tuán)隊(duì)瑟幕，通過每個(gè)象限，并根據(jù)沖刺計(jì)劃和產(chǎn)品路線圖確定需要哪種類型的測試留潦。

1. 與客戶討論質(zhì)量標(biāo)準(zhǔn)——在現(xiàn)階段對他們來說什么是最重要的?例如只盹，如果產(chǎn)品具有所需的功能，但不夠穩(wěn)定兔院，則關(guān)注象限4殖卑。如果缺少關(guān)鍵的特性，那么就關(guān)注象限2坊萝。

2. 了解誰可以執(zhí)行所需的測試孵稽。作為Scrum團(tuán)隊(duì)的一員，你是否具備所需的專業(yè)知識?如果不是十偶，你是否需要從其他團(tuán)隊(duì)或顧問那里招募專家?例如菩鲜，性能和安全測試需要特殊的專業(yè)知識。

3.是否擁有執(zhí)行測試所需的工具和基礎(chǔ)設(shè)施?例如惦积，測試可能需要一個(gè)云上的測試環(huán)境接校，測試可以自動啟動它。需要將構(gòu)建此環(huán)境作為sprint的一部分狮崩，或者了解誰可以提供該環(huán)境蛛勉。

4. 你有測試所需的數(shù)據(jù)嗎?如果沒有，請與產(chǎn)品負(fù)責(zé)人或用戶一起構(gòu)建一個(gè)詳細(xì)的用戶故事睦柴，并要求他們提供測試可以使用的實(shí)際測試數(shù)據(jù)诽凌。

敏捷測試中的7大挑戰(zhàn)以及如何解決它們

敏捷開發(fā)過程的連續(xù)性帶來了一些嚴(yán)重的測試挑戰(zhàn):

1. 需求變更

有時(shí)，管理層會在sprint期間更改需求或刪除故事坦敌，即使這在敏捷/Scrum框架中是不鼓勵的侣诵。這意味著已經(jīng)完成一半的工作需要被丟棄或修改，這意外地改變了測試的范圍狱窘。

如何解決:

測試人員應(yīng)該能夠根據(jù)變化的情況做出反應(yīng)并修改他們的過程杜顺，因?yàn)樵诿艚蓓?xiàng)目中，變化是很常見的训柴。當(dāng)需求發(fā)生變化時(shí)哑舒，測試人員應(yīng)該分享盡可能多的信息，包括他們已經(jīng)進(jìn)行了哪些測試幻馁，以及應(yīng)用程序的哪些區(qū)域還沒有被測試洗鸵。這可以幫助團(tuán)隊(duì)理解如何在不損害發(fā)布質(zhì)量的情況下對sprint進(jìn)行所需的更改。

2. 信息不足

負(fù)責(zé)開發(fā)用戶故事的產(chǎn)品負(fù)責(zé)人可能對新功能有一個(gè)想法仗嗦，但可能不知道具體細(xì)節(jié)膘滨。這意味著他們不能寫出一套好的接受標(biāo)準(zhǔn)。如果缺少關(guān)于需求的信息稀拐，測試人員就不能構(gòu)建全面的測試用例火邓。

如何解決:

測試人員不需要深入的需求來開始測試，他們可以從提出高級場景開始，測試故事的想法铲咨，并與產(chǎn)品負(fù)責(zé)人確認(rèn)它們躲胳。測試可以在沒有關(guān)于特性的完整細(xì)節(jié)的情況下進(jìn)行∠死眨可以創(chuàng)建高級測試場景坯苹，即使細(xì)節(jié)發(fā)生了變化。

3.連續(xù)測試

測試并不局限于開發(fā)過程的一部分摇天，而是在開發(fā)階段之前開始的持續(xù)活動粹湃。這就產(chǎn)生了一個(gè)重大的挑戰(zhàn)，因?yàn)闇y試人員需要在編碼開始之前泉坐，或者在編碼進(jìn)行時(shí)为鳄，就開始為特性構(gòu)建測試。

如何解決:

為了讓測試人員的工作更輕松腕让，backlog中的用戶描述應(yīng)該在sprint計(jì)劃期間進(jìn)行擴(kuò)展孤钦。測試人員、開發(fā)人員和產(chǎn)品負(fù)責(zé)人應(yīng)該共同定義每個(gè)故事的細(xì)節(jié)记某，然后編寫有效的驗(yàn)收標(biāo)準(zhǔn)司训。

團(tuán)隊(duì)?wèi)?yīng)該確保每個(gè)故事都有足夠的接受標(biāo)準(zhǔn)，并且在開發(fā)工作開始之前液南，故事的上下文被普遍理解壳猜。這使得在早期開始創(chuàng)建測試成為可能，這些測試可以在特性代碼完成時(shí)實(shí)現(xiàn)滑凉。

4. 技術(shù)技能

在敏捷環(huán)境中工作的測試人員需要精通技術(shù)统扳，用Selenium或類似的框架幫助開發(fā)人員進(jìn)行API測試、集成測試和腳本UI自動化檢查畅姊。具有探索性或手動測試背景的測試人員進(jìn)入敏捷世界將遇到陡峭的學(xué)習(xí)曲線咒钟。

如何解決:

測試人員可以也應(yīng)該學(xué)習(xí)編程或腳本語言，如Javascript和Ruby若未。熟悉編程但缺乏實(shí)際經(jīng)驗(yàn)的測試人員可以向開發(fā)人員尋求幫助朱嘴。測試人員還可以學(xué)習(xí)自動化測試工具，如Selenium工具和JMeter粗合。

對于專門的測試領(lǐng)域萍嬉，例如性能、安全性或遵從性測試隙疚，團(tuán)隊(duì)?wèi)?yīng)該擁有具有相關(guān)專業(yè)背景的專門測試人員壤追，或者利用在這些領(lǐng)域具有豐富經(jīng)驗(yàn)的顧問。

5. 頻繁的回歸周期

開發(fā)人員經(jīng)常不斷地向產(chǎn)品添加功能供屉。這可能會導(dǎo)致先前特性的回歸行冰。測試人員使用回歸測試來識別這個(gè)問題并克服它溺蕉，但是手動回歸測試在快節(jié)奏的敏捷環(huán)境中是不切實(shí)際的。

另一個(gè)挑戰(zhàn)是悼做，現(xiàn)代web應(yīng)用程序在不同設(shè)備或?yàn)g覽器上的表現(xiàn)不同疯特。這將創(chuàng)建一個(gè)復(fù)雜的兼容性測試場景矩陣，需要對這些場景進(jìn)行測試贿堰，以確保應(yīng)用程序能夠正確地為所有用戶運(yùn)行辙芍。

如何解決:

敏捷測試人員依賴于自動化啡彬。他們使用單元測試來確保最近的更改沒有破壞代碼羹与，并使用Selenium和JMeter等工具來驗(yàn)證基本功能中沒有回歸。測試人員可以使用Docker或Selenium Grid在各種瀏覽器和機(jī)器上并行地管理和運(yùn)行他們的自動化測試庶灿。

6. 缺乏溝通

如果開發(fā)人員纵搁、測試人員和產(chǎn)品負(fù)責(zé)人之間缺乏溝通，敏捷測試就無法工作往踢。

如何解決:

應(yīng)該大力鼓勵團(tuán)隊(duì)內(nèi)部的直接溝通腾誉。開發(fā)人員、測試人員和產(chǎn)品負(fù)責(zé)人應(yīng)該定期面對面交談峻呕，以確保每個(gè)人都在同一頁面上利职。Scrum儀式，如站立會議瘦癌、沖刺計(jì)劃和回顧猪贪，有助于建立對沖刺范圍和目標(biāo)的共同理解。

7. 沒有質(zhì)量度量

今天的敏捷團(tuán)隊(duì)沒有單一的質(zhì)量度量讯私，他們可以用它來優(yōu)化和計(jì)劃測試工作热押。

有許多度量標(biāo)準(zhǔn)，如單元測試代碼覆蓋率斤寇、代碼行數(shù)(LOC)以及代碼的復(fù)雜性桶癣。但是沒有一個(gè)能夠提供關(guān)于在沖刺或發(fā)布中每個(gè)點(diǎn)的質(zhì)量的“我們所處的位置”的清晰圖片——產(chǎn)品的哪些部分工作得很好，哪些不太穩(wěn)定娘锁，質(zhì)量問題的風(fēng)險(xiǎn)更高牙寞。

大多數(shù)敏捷團(tuán)隊(duì)都在盲目飛行，只對生產(chǎn)失敗或bug做出反應(yīng)莫秆，卻無法主動關(guān)注存在最大質(zhì)量問題的產(chǎn)品領(lǐng)域间雀。

了解了敏捷測試的8大原則和7大挑戰(zhàn)之后，相信大家已經(jīng)對敏捷測試有了初步的了解馏锡。也歡迎大家日常測試中迅速使用起來真敏捷的方法雷蹂。

如果你覺得阿薩的文章對你有幫助，歡迎圍觀杯道，點(diǎn)贊和在看匪煌。謝謝大家责蝠。