楊娜+嚴(yán)振亞


摘要:近年來Scrum已經(jīng)逐漸成為主流的敏捷開發(fā)方法被廣泛采用,但測試環(huán)節(jié)卻經(jīng)常得不到有效的重視,軟件質(zhì)量無法得到保障。本文在Scrum方法的基礎(chǔ)上,通過在每次迭代過程中加入單元測試流、系統(tǒng)測試流和QA控制流,從三個不同的維度對軟件產(chǎn)品的質(zhì)量進(jìn)行驗(yàn)證與控制,并與每次迭代周期同步完成測試用例庫的積累和完善。通過使用本方法可以有效的減少后續(xù)測試用例的編寫投入成本,縮短軟件產(chǎn)品的交付時(shí)間,并顯著提高最終軟件產(chǎn)品的質(zhì)量。
關(guān)鍵詞:軟件工程;過程改進(jìn);軟件測試;敏捷;scrum
中圖分類號:TP311.5 文獻(xiàn)標(biāo)識碼:A 文章編號:1007-9416(2017)01-0051-03
Abstract:In recent years, Scrum has gradually become the mainstream of agile development methods are widely used, but the test link is often not effective attention, software quality can not be guaranteed. In this paper, on the basis of Scrum method, by adding a unit test in each iteration process flow, system test flow and QA flow control, from three different dimensions for verification and control of the quality of software products, and each iteration cycle synchronization complete test case library accumulation and improvement. Using this method can effectively reduce the input cost of subsequent test cases, shorten the delivery time of software products, and significantly improve the quality of the final software products.
Key Words:software engineering;process improvement;software test;agile;scrum
Scrum敏捷開發(fā)方法經(jīng)過多年的理論完善與市場驗(yàn)證,逐漸發(fā)展為一套流程完備、過程清晰且具有高可操作性的軟件開發(fā)方法體系。由于它可以快速適應(yīng)用戶的需求變更,并且能夠通過迭代的方式持續(xù)交付可運(yùn)行的系統(tǒng),因此非常適合當(dāng)前對軟件產(chǎn)品迅速變化、持續(xù)改進(jìn)的市場需求,被眾多的軟件開發(fā)組織接納并采用[1]。
但在使用Scrum方法開發(fā)軟件的過程中,與其配合的測試環(huán)節(jié)卻經(jīng)常得不到足夠的重視,通常只由開發(fā)人員進(jìn)行模塊自測或測試工程師憑經(jīng)驗(yàn)對系統(tǒng)功能進(jìn)行測試。由于缺少傳統(tǒng)軟件工程中的測試用例和測試計(jì)劃,導(dǎo)致測試過程隨意性較大,同時(shí)也無法對增量產(chǎn)生的軟件產(chǎn)品進(jìn)行有效的回歸測試,造成軟件質(zhì)量無法得到保障[2]。
本文針對以上問題,通過對Scrum方法進(jìn)行改進(jìn),提出了一種適合于Scrum敏捷開發(fā)的測試模型。它將每次迭代周期與“單元測試流”、“系統(tǒng)測試流”和“QA控制流”緊密集成,將開發(fā)人員和測試人員的工作量平均分配不同的流程節(jié)點(diǎn),并通過測試用例的“復(fù)用庫”實(shí)現(xiàn)測試用例復(fù)用管理,使用測試用例“回歸庫”完成對迭代增量軟件產(chǎn)品的回歸測試。通過本方法改進(jìn)可以有效的規(guī)范敏捷測試流程,提高測試用例的復(fù)用程度和軟件產(chǎn)品的質(zhì)量。
1 Scrum方法簡介
Scrum方法的核心思想是使用一種簡單且有效的方法對軟件開發(fā)過程進(jìn)行管理,它拋棄了傳統(tǒng)軟件過程中大量的文檔和復(fù)雜的過程,提倡團(tuán)隊(duì)成員之間密切配合,快速響應(yīng)用戶的需求變化。Scrum方法將軟件開發(fā)過程劃分為若干個迭代周期,每個周期開始之前開發(fā)團(tuán)隊(duì)和客戶一起規(guī)劃本次應(yīng)該完成的內(nèi)容,在隨后的迭代周期中完成相應(yīng)的軟件開發(fā)[3-4]。在開發(fā)過程中團(tuán)隊(duì)成員每天都要召開“站立會議”,匯報(bào)前一天的開發(fā)進(jìn)度和遇到的問題,并安排當(dāng)天的工作內(nèi)容[5]。在一個迭代周期結(jié)束后,團(tuán)隊(duì)向用戶提交一個可以正常運(yùn)行的軟件系統(tǒng),作為本次迭代的交付物,經(jīng)過多次這樣迭代開發(fā)后產(chǎn)品最終滿足用戶的需求(圖1)。Scrum敏捷開發(fā)非常強(qiáng)調(diào)“人”的作用,同時(shí)又不排斥過程管理,并認(rèn)為過程是將人的精力集中于結(jié)果的組織化結(jié)構(gòu),反過來這種組織化結(jié)構(gòu)將引導(dǎo)工作,并影響產(chǎn)品和組織中人的關(guān)系發(fā)展[6]。
2 敏捷測試方法及其改進(jìn)
2.1 敏捷測試定義
敏捷測試在當(dāng)前軟件開發(fā)方法體系中并沒有一個明確的定義,通常認(rèn)為敏捷測試是指與敏捷開發(fā)過程相配合,能夠快速擁抱變化并及時(shí)響應(yīng)用戶需求變更,同時(shí)還要適應(yīng)敏捷開發(fā)的價(jià)值觀的測試過程的測試方法[7-8]。在測試執(zhí)行過程中需要不停的進(jìn)行迭代,以便調(diào)整測試的重點(diǎn)和目標(biāo),還要以用戶價(jià)值為核心,從使用者的角度對系統(tǒng)的功能需求與非功能需求進(jìn)行驗(yàn)證,最終為用戶提供符合要求的軟件產(chǎn)品。
2.2 基于Scrum方法的敏捷測試過程改進(jìn)
本過程改進(jìn)是在原有的Scrum敏捷方法中增加了3條以質(zhì)量為核心的工作流,分別從單元模塊測試、系統(tǒng)集成測試和QA質(zhì)量保障三個方面對每次迭代的產(chǎn)品進(jìn)行質(zhì)量驗(yàn)證,保障本次發(fā)布給用戶的最終產(chǎn)品滿足規(guī)定的質(zhì)量標(biāo)準(zhǔn)(圖2)。
2.2.1 單元測試流
單元測試流需要項(xiàng)目開發(fā)人員參與,主要工作集中在Scrum迭代的開發(fā)環(huán)節(jié)。考慮到在敏捷開發(fā)過程中盡量控制項(xiàng)目的邊界范圍,因此建議使用“測試驅(qū)動開發(fā)”(TDD)的方式進(jìn)行操作。即在明確要開發(fā)某個功能的基礎(chǔ)上,根據(jù)用戶的需求先編寫出測試代碼滿足這些測試用例,接下來再開發(fā)業(yè)務(wù)代碼使這些測試用例能夠順利通過驗(yàn)證,逐步完成軟件的全部功能[9-11]。
為了能夠讓單元測試用例盡可能復(fù)用,減少編寫重復(fù)用例帶來的資源浪費(fèi),需要為這些測試用例建立一個“復(fù)用TDD用例庫”[12-13]。在確定用例時(shí)首先需要在復(fù)用庫中查找是否存在可以復(fù)用的資源,如果存在這樣的資源則直接在復(fù)用庫中取出使用,或根據(jù)實(shí)際情況對被復(fù)用用例進(jìn)行微調(diào)后再使用。如果不存在能夠被復(fù)用的測試用例資源,則需要開發(fā)人員編寫一個新的用例,并將這個用例使用在單元測試過程中。對于新編寫的用例需要在本次迭代過程中進(jìn)行評審,以確定是否具有復(fù)用性。評審人員通常由開發(fā)團(tuán)隊(duì)的程序員、設(shè)計(jì)人員和項(xiàng)目技術(shù)負(fù)責(zé)人共同組成,從用例的功能、用途、適用性、通用性等幾個方面對其進(jìn)行評審。對于復(fù)用性較高的單元測試用例,需要將期加入到“復(fù)用TDD用例庫”以備未來迭代過程中重復(fù)使用,如果用例復(fù)用性不高,則只在本次測試中使用。
除了復(fù)用用例庫外,還需要為項(xiàng)目建立一個“回歸TDD用例庫”。每次測試使用的測試用例都需要加入到回歸庫中,方便在后續(xù)迭代過程中對系統(tǒng)進(jìn)行回歸測試,確保每次增加的功能不會對已有代碼產(chǎn)生不良的影響[14]。
2.2.2 系統(tǒng)測試流
系統(tǒng)測試是在功能層面上對軟件進(jìn)行測試,主要驗(yàn)證系統(tǒng)的功能特性與非功能特性是否符合要求。在系統(tǒng)測試流中需要軟件測試團(tuán)隊(duì)的人員參與,由他們負(fù)責(zé)編寫測試用例并對系統(tǒng)進(jìn)行驗(yàn)證。參與時(shí)機(jī)為每次迭代過程中制定本次開發(fā)周期的“產(chǎn)品功能列表”工作節(jié)點(diǎn),這時(shí)周期性的軟件功能已經(jīng)明確,測試人員即可以著手規(guī)劃本次的功能測試用例。
根據(jù)Scrum開發(fā)的特點(diǎn),也要盡可能的提高功能測試用例的可復(fù)用性,因此需要建立“復(fù)用功能測試用例庫”。具體操作流程與單元測試近似,測試人員在編寫功能測試用例時(shí)首先到復(fù)用庫中查找用例,如果存在可以使用的測試用例則直接取出后使用,如果不存在則需要手動編寫新的測試用例。新編寫的測試用例需要在本次迭代過程中,由測試人員、測試負(fù)責(zé)人共同進(jìn)行評審,如果用例具備較高的可復(fù)用性,則可加入“復(fù)用功能測試用例庫”以備后續(xù)的迭代過程中重復(fù)使用。
功能測試層面同樣需要進(jìn)行回歸測試,因此還需要為系統(tǒng)測試流建立一個“回歸功能測試”用例庫。每次迭代過程中的測試用例都需要加入到此庫,在后續(xù)的開發(fā)過程中進(jìn)行回歸測試,確保代碼不會受到不良影響。
2.2.3 QA控制流
QA人員在軟件開發(fā)團(tuán)隊(duì)中主要負(fù)責(zé)質(zhì)量保證工作,包括建立保障制度體系、過程改進(jìn)、指導(dǎo)項(xiàng)目實(shí)施、項(xiàng)目活動評審、審核工作產(chǎn)品、進(jìn)行缺陷預(yù)防、實(shí)現(xiàn)質(zhì)量目標(biāo)等一系列的工作[15]。在Scrum敏捷開發(fā)過程中“QA控制流”是一條貫穿整個迭代過程的質(zhì)量控制流程,這個過程需要QA質(zhì)量保證部門的人員參與,根據(jù)組織對軟件產(chǎn)品的質(zhì)量定義使用過程監(jiān)控、過程改進(jìn)等手段對開發(fā)過程進(jìn)行影響與干預(yù),保證軟件產(chǎn)品的質(zhì)量。
在每次迭代完成后,QA部門會對本次開發(fā)過程進(jìn)行評審,其中主要包括開發(fā)和測試兩部分。如開發(fā)過程的合規(guī)性、代碼規(guī)范性、是否按照組織的要求對程序進(jìn)行注釋,是否包括“序言性”注釋等,除此之外還需要對測試流程、用例入庫評審過程、回歸測試執(zhí)行時(shí)機(jī)和結(jié)果等方面進(jìn)行評價(jià)。
以上3個測試流分別從實(shí)現(xiàn)層、功能層、過程層三個維度對Scrum開發(fā)模型進(jìn)行質(zhì)量驗(yàn)證和控制,從一次迭代周期的功能確定,到代碼開發(fā)和最后的產(chǎn)品交付,每個環(huán)節(jié)都有相應(yīng)的質(zhì)量驗(yàn)證的方法相配合。不同角色的人員也被分配的相應(yīng)的節(jié)點(diǎn),工作內(nèi)容相互銜接與配合,形成一套完整、獨(dú)立的質(zhì)量保證機(jī)制。
2.3 過程改進(jìn)后的優(yōu)勢
2.3.1 測試環(huán)節(jié)快速響應(yīng)需求變更
在使用Scrum敏捷方法開發(fā)軟件的過程中,通常會以4周時(shí)間為一個迭代周期,在這期間團(tuán)隊(duì)成員會針對已明確定義的軟件功能進(jìn)行開發(fā),迭代結(jié)束后再考慮下一個周期需要開發(fā)的內(nèi)容。這時(shí)用戶需求發(fā)生變化的概率非常大,每個迭代周期都有可能加入新的需求,甚至?xí)灰笮薷囊验_發(fā)完成的軟件功能。改進(jìn)后的測試工作能夠在每次迭代時(shí)進(jìn)行適應(yīng)性調(diào)整,以滿足不斷變化的軟件需求[16]。
2.3.2 能夠增量完善測試用例庫
使用Scrum方法開發(fā)軟件時(shí),需求是一個逐漸增加的過程,任何一次迭代都不能表現(xiàn)出系統(tǒng)的功能全貌。改進(jìn)后的測試流程可以適應(yīng)這種增量模式,在每一個迭代周期中都要產(chǎn)生相應(yīng)的測試用例,并在每個開發(fā)周期結(jié)束后將其合并到回歸測試用例庫。產(chǎn)品交付前需要對軟件進(jìn)行回歸測試以確保本次迭代開發(fā)沒有破壞已有的系統(tǒng)功能,此時(shí)增量積累的測試用例庫即可做為回歸測試的依據(jù),不僅提高了測試的準(zhǔn)確度也可以顯著減少測試人員的工作強(qiáng)度。
2.3.3 全員參與測試過程,加強(qiáng)質(zhì)量觀念
在敏捷測試過程,不僅要求測試團(tuán)隊(duì)參與測試過程,開發(fā)人員也需要對自己完成的功能進(jìn)行單元測試。每個功能開發(fā)完成后,首先由開發(fā)人員對本功能模塊從程序邏輯、代碼路徑覆蓋、環(huán)路復(fù)雜度、模塊接口、參數(shù)傳遞等多個層面完成單元測試,通過測試后再交由測試團(tuán)隊(duì)使用“黑盒測試”的方法由功能層面對模塊進(jìn)行測試。使用這種方法能夠讓軟件的開發(fā)人員和測試人員密切配合,共同參與到產(chǎn)品質(zhì)量保證過程中,實(shí)現(xiàn)了全員參與測試、全員關(guān)注質(zhì)量的管理目標(biāo)。改進(jìn)后的測試流程在敏捷測試的每個工作節(jié)點(diǎn)都有相應(yīng)的測試驗(yàn)證環(huán)節(jié),并合理的將不同角色分配到這些節(jié)點(diǎn),使團(tuán)隊(duì)中的每位成員都能夠參與質(zhì)量保證過程。
2.3.4 為自動化測試工具提供數(shù)據(jù)支持
由于Scrum敏捷開發(fā)方法周期較短,要求在最快的時(shí)間里為用戶提供可以運(yùn)行的軟件產(chǎn)品,因此不能在測試環(huán)節(jié)上耗費(fèi)太多的時(shí)間。通過對測試過程的改進(jìn),能夠逐步積累回歸測試用例,此時(shí)可以配合使用自動化工具來提高軟件測試的效率和質(zhì)量,同時(shí)還可以有效的降低測試人的員的工作強(qiáng)度。
3 結(jié)語
本方法改進(jìn)是在Scrum敏捷開發(fā)的基礎(chǔ)上,通過引入單元測試流、系統(tǒng)測試流和QA控制流,從三個不同的維度對產(chǎn)品質(zhì)量進(jìn)行測試和保障。這種改進(jìn)方式在保持敏捷開發(fā)特性的前提下提高了交付軟件產(chǎn)品的質(zhì)量,并通過多次迭代過程逐漸積累和完善復(fù)用測試用例庫,減少后續(xù)測試用例的編寫成本,縮短軟件產(chǎn)品的交付時(shí)間,提高用戶的滿意度。
參考文獻(xiàn)
[1]劉雪萍,段學(xué)東.敏捷開發(fā)與CMMI融合探討[J].硅谷,2012(7):3-4.
[2]劉慧玲,王申申,陳曉軍.Scrum敏捷方法在快速開發(fā)中的實(shí)踐及改進(jìn)[J].電腦知識與技術(shù),2012,08(21):5168-5169.
[3]陳瑩.瀑布式開發(fā)流程與SCRUM開發(fā)流程的分析與優(yōu)化[J].信息與電腦,2016,11:123-124.
[4]張孟.敏捷開發(fā)中原則與過程的分析與研究[J].科技傳播,2013(2):197-198.
[5]張思凱.結(jié)合CMMI的Scrum敏捷軟件開發(fā)研究[J].電子技術(shù)與軟件工程,2015(9):66-66.
[6]杜敏成.基于Scrum敏捷開發(fā)思想的軟件開發(fā)過程管理[J].軟件導(dǎo)刊,2015,14(10):12-14.
[7]李逆,吳艷陽.敏捷開發(fā)中的軟件測試研究[J].軟件導(dǎo)刊,2016,15(4):16-19.
[8]劉夢飛,徐偉.運(yùn)用敏捷思想改進(jìn)軟件測評流程[J].軟件導(dǎo)刊,2014(11):10-12.
[9]張曉靜.敏捷測試在移動App開發(fā)中的研究與應(yīng)用[J].電子科學(xué)技術(shù),2015,2(2):211-213.
[10]陳希,徐明昆.測試驅(qū)動開發(fā)在軟件開發(fā)中的研究與實(shí)踐[J].軟件,2012,33(12):177-181.
[11]彭振龍.測試驅(qū)動開發(fā)與軟件質(zhì)量保證探析[J].泉州師范學(xué)院學(xué)報(bào),2013,31(6):90-93.
[12]陳迪舸.芻議測試驅(qū)動開發(fā)在軟件開發(fā)中的作用[J].電子技術(shù)與軟件工程,2016(7):60-60.
[13]芮素娟.可復(fù)用測試用例研究[J].電腦知識與技術(shù).2013,9(14):3308-3310.
[14]劉沅斌.基于共性分析的軟件測試用例復(fù)用技術(shù)研究[J].中國管理信息化.2016,19(13):177-180.
[15]成亞玲,李健,彭湘華.回歸測試用例優(yōu)化選擇研究綜述[J].湖南工業(yè)職業(yè)技術(shù)學(xué)院學(xué)報(bào).2015(2):13-20.
[16]計(jì)平,王文濤.GJB5000A體系下的軟件QA研究[J].信息技術(shù)與信息化,2016(5):123-125.