講究竟什么敏捷測試海量資源

本文由簡悅SimpRead轉(zhuǎn)碼，原文地址2013年，在本文由簡悅SimpRead轉(zhuǎn)碼，原文地址2013年，在InfoQ發(fā)表了相同標題的文章，但這篇文章是全新而作。在回答“究竟什么是敏捷測試”之雖然我聽不到你的回答，但還是先提醒你回憶一下著名的敏捷宣言和12項敏捷開發(fā)原則，帶著這些回合敏捷價值觀，哪些又違反了敏捷開發(fā)原則，最后我們一起來分析案例，并回答“究竟什么是敏捷測試”這個案例來自一家國內(nèi)的公司，這家公司的產(chǎn)品主要是基于Android系統(tǒng)的智能終端。故事發(fā)生在年前，即2013先給大家介紹一下案例背景，公司的軟件研發(fā)部門下屬有四個開發(fā)部門和一個龐大的測試部門，其中，一個負責各種研發(fā)工具開發(fā)的部門也隸屬于測試部門。開發(fā)人員和測試人員比例幾乎是1:1，開發(fā)部門的職責是按照負責的功能模塊劃分的，而測試部門負責軟件系統(tǒng)級別的所有測試，包括功能測試、性能測試、安全性測試、可靠性測試、兼容性測試等。當時采用的是傳統(tǒng)的瀑布式開發(fā)模式，即V碼編寫和產(chǎn)品測試被明確地分成了兩個階段，如圖1所示：1V1.這里所用到的工具包括：分布式的代碼版本控制工具Git+代碼審查工具Gerrit+持續(xù)集成工具Jenkins+自研的基于MonkeyRunner的自動化測試框架?；贕it+Gerrit+Jenkins，開發(fā)部門已經(jīng)過程中，工具鏈沒有問題，自動構(gòu)建和自動部署也沒有問題，問題就出在自動化測試上。一個產(chǎn)品的手工測試用例大概是1000個，但是能轉(zhuǎn)化為自動化腳本并且放在集成環(huán)境里執(zhí)行的用例，在很長時間內(nèi)只有100多個，只實現(xiàn)了版本驗證，即我們通常所說的“冒煙測試”員提交代碼，觸發(fā)的自動化測試達到的覆蓋率非常有限，即使這個集成環(huán)境能夠支持持續(xù)驗證，所有人都覺得很雞肋。就是邊開發(fā)邊測試，期望通過這個縮短產(chǎn)品開發(fā)周期。就是邊開發(fā)邊測試，期望通過這個縮短產(chǎn)品開發(fā)周期。開發(fā)部門按照ScrumTeam進行劃分，按照3:1的比例招聘了測試工程師。一開始沒想明白他們到底需他們在Scrumeam里的主要工作包括：手工測試；一遍遍按照開發(fā)的要求復現(xiàn)bug；給開發(fā)人員打位或者軟件集成到一起不工作時，手工測試則沒法進行。多了，無非體現(xiàn)在報的bug多了，測試部門看重的是需求的覆蓋率，人自然減不下來。所以，在一次改組中，領(lǐng)導宣布所有的測試人員都轉(zhuǎn)到測試部門，要求測試部門減掉相應(yīng)數(shù)量的測試外包。Scrumeam可以向測試部門要求按3:1的比例配備測試人員。測試部門能夠了解Scrumeam測試范圍，減少了重復測試。改組之后，人數(shù)倒是減下來了，但是仍然以手工測試為主，因為組織架構(gòu)的變更，開發(fā)和測試經(jīng)常因為誰對開發(fā)階段的測試說了算而爭論不休，開發(fā)和測試變得更加涇渭分明，關(guān)系更緊張了。開發(fā)部門。良好的轉(zhuǎn)變是：每個Scrumeam開始由一名資深測試工程師擔任estOwner，負責制定程師進行開發(fā)能力的培養(yǎng)。一開始單元測試的覆蓋率幾乎是0，開發(fā)人員只管寫代碼和修復測試人員提交的缺陷。由于持續(xù)集成和果。開發(fā)也答應(yīng)做，但是整整一年未見成效，原因是：忙，沒有單元測試的經(jīng)驗和技能。測試部門意識到自動化的重要性，但是部門只有5%意采取末位淘汰制替換10%式，在一年之后自動化測試工程師的比例終于達到了25%化測試在API和UI測試的覆蓋率終于看到明顯提高，但是在整體需求覆蓋率上也沒有超過30%，而且單元測試的缺失依然是硬傷，沒有開發(fā)人員的參與，測試總在UI層折騰，當然是事倍功半。敏捷測試的彼岸，更不用說，產(chǎn)品的質(zhì)量和測試的效率得到顯著的提升。那究竟什么是敏捷測試呢？可以肯定的是，“敏捷測試”是為了適應(yīng)敏捷開發(fā)而特別設(shè)計的一套完整的軟件測試解決方案。這個解決方案應(yīng)該能夠支持持續(xù)交付，涵蓋所需的、正確的價值觀、思維方式、測試流程、一系列優(yōu)秀的測試實踐和更合適的測試環(huán)境、自動化測試框架和工具。敏捷測試可以采用目前已有的各種測試方式、方法，以及傳統(tǒng)測試相比側(cè)重有敏捷測試應(yīng)該具有“敏捷宣言”所倡導的價值觀，為此我們可以按照“敏捷宣言”的格式，寫出如下的“敏與開發(fā)協(xié)作測試勝于測試分工與測試工具可運行的測試腳本勝于寫在紙上的測試用例從客戶角度來理解測試需求勝于從已定義的需求來判定測試結(jié)果基于上下文及時調(diào)整測試策略勝于遵守測試計劃敏捷測試強調(diào)“敏捷測試應(yīng)該具有“敏捷宣言”所倡導的價值觀，為此我們可以按照“敏捷宣言”的格式，寫出如下的“敏與開發(fā)協(xié)作測試勝于測試分工與測試工具可運行的測試腳本勝于寫在紙上的測試用例從客戶角度來理解測試需求勝于從已定義的需求來判定測試結(jié)果基于上下文及時調(diào)整測試策略勝于遵守測試計劃敏捷測試強調(diào)“與開發(fā)協(xié)作”、“自動化測試”、“客戶思維”和“動態(tài)的測試策略調(diào)整”那我們回過頭來，再看看上面的案例，至少第1、2條，他們沒做到：測試人員沒有得到足夠的重視和“沒有開發(fā)人員的參與，測試總在UI層折騰，當然是事倍功半”“觸發(fā)的自動化測試達到的覆蓋率非常有限人員不合格。在執(zhí)行過程中，缺乏測試策略，沒有強調(diào)從客戶的需求出發(fā)和動態(tài)地調(diào)整測試策略。敏捷開發(fā)還有1212發(fā)的基本要求，例如：如何支撐或協(xié)助“持續(xù)不斷地、盡早交付有價值的軟件如何擁抱變化——“欣然面對需求變化，即使在開發(fā)后期也一樣開發(fā)，并和開發(fā)緊密協(xié)作，測試才不會成為敏捷開發(fā)的“絆腳石”?；诿?/p>