戴明循環(huán)在敏捷軟件質(zhì)量管理中的應(yīng)用方法研究

孫子謙 王雅琴 黃明明

1(山東農(nóng)業(yè)大學(xué)信息科學(xué)與工程學(xué)院 山東 泰安 271018)2(甲骨文軟件研究開發(fā)中心(北京)有限公司 北京 100193)

?

戴明循環(huán)在敏捷軟件質(zhì)量管理中的應(yīng)用方法研究

孫子謙1,2王雅琴1*黃明明1

1(山東農(nóng)業(yè)大學(xué)信息科學(xué)與工程學(xué)院 山東 泰安 271018)2(甲骨文軟件研究開發(fā)中心(北京)有限公司 北京 100193)

敏捷軟件過程憑借對變更的適應(yīng)能力被越來越多的軟件企業(yè)采用，同時(shí)敏捷開發(fā)對軟件質(zhì)量管理也提出很大挑戰(zhàn)。針對敏捷開發(fā)過程在軟件質(zhì)量保證中的特點(diǎn)，以實(shí)際項(xiàng)目為例提出一種基于戴明循環(huán)的軟件測試過程。這種測試過程對軟件測試流程實(shí)行自反饋方式的改進(jìn)，提高了軟件測試的有效性，降低了資源開銷，使軟件測試過程能夠適應(yīng)敏捷開發(fā)需要。

戴明循環(huán) 軟件質(zhì)量 敏捷過程 軟件測試 質(zhì)量管理

0 引 言

“敏捷”是隨著信息產(chǎn)業(yè)的發(fā)展，為了適應(yīng)新的生存環(huán)境而產(chǎn)生的概念。上個(gè)世紀(jì)末，敏捷制造已經(jīng)在制造業(yè)中為世界廣泛接受[1]。隨著信息技術(shù)和軟件產(chǎn)業(yè)的發(fā)展，人們希望軟件能夠更靈活、更準(zhǔn)確地適應(yīng)業(yè)務(wù)環(huán)境和需求的變化。在這種情況下，“敏捷”的概念被引入到軟件行業(yè)中來[2]。1998年Aoyama在文獻(xiàn)[3]中首次提出了敏捷軟件過程的概念，此后逐漸成為一種潮流而被越來越多的企業(yè)采用。自引入敏捷概念以來，敏捷軟件過程已經(jīng)受到諸多研究人員和工程技術(shù)人員的重視。由于其思想是“面向人”的靈活過程[4]，因而質(zhì)量管理顯得尤為重要。

戴明循環(huán)是工業(yè)產(chǎn)品質(zhì)量管理領(lǐng)域得到廣泛認(rèn)可的管理理論。由于軟件不是一種實(shí)體產(chǎn)品，其質(zhì)量管理與工業(yè)產(chǎn)品有較大的差異。因而戴明循環(huán)理論并不能照搬到軟件質(zhì)量管理過程中。

1 戴明循環(huán)和敏捷軟件質(zhì)量管理

1.1 戴明循環(huán)

戴明循環(huán)又叫PDCA循環(huán)。在20世紀(jì)30年代，美國的Shewhart提出了PDCA循環(huán)的概念。PDCA循環(huán)將整個(gè)質(zhì)量管理劃分為計(jì)劃、執(zhí)行、檢查和處理四個(gè)階段[6]。后來，戴明對PDCA循環(huán)理論進(jìn)行了完善，并在日本進(jìn)行了大量推廣實(shí)踐，此后在企業(yè)質(zhì)量管理中得到了廣泛應(yīng)用。同時(shí)，PDCA也成為活動(dòng)進(jìn)行的常用工作流程[7]。

PDCA是一個(gè)自反饋式循環(huán)往復(fù)的過程，且在PDCA的各個(gè)階段內(nèi)部還能進(jìn)行子循環(huán)，以解決該階段的問題。

單次PDCA循環(huán)的示意如圖1所示。

圖1 一次PDCA循環(huán)示意圖

在一輪循環(huán)中，計(jì)劃階段包括目標(biāo)的確定與過程的指定，通常按照5W1H進(jìn)行歸納，即做什么(What)、為什么(Why)、誰(Who)、什么時(shí)間(When)地點(diǎn)(Where)以及如何做(How)。執(zhí)行階段并不是簡單地接收并執(zhí)行Plan階段所制定的計(jì)劃，而是要按照計(jì)劃進(jìn)行實(shí)施，并對實(shí)施過程進(jìn)行監(jiān)控，使整個(gè)活動(dòng)按照預(yù)期計(jì)劃進(jìn)行，達(dá)到Plan階段的目標(biāo)。檢查階段后來被戴明改為研究階段[8]，主要任務(wù)是根據(jù)計(jì)劃與執(zhí)行過程的監(jiān)管結(jié)果，對執(zhí)行的結(jié)果進(jìn)行分析和評估。處理階段接收檢查階段的結(jié)論，總結(jié)經(jīng)驗(yàn)納入標(biāo)準(zhǔn)化，并解決檢查階段所發(fā)現(xiàn)的問題，將檢查結(jié)果傳遞給下一輪的計(jì)劃，作為計(jì)劃階段的輸入。通過上述四個(gè)階段從而完成整個(gè)自反饋過程。每完成一次戴明循環(huán)，質(zhì)量水平就得到一次改進(jìn)，最終促進(jìn)產(chǎn)品質(zhì)量以螺旋方式上升。

1.2 敏捷軟件質(zhì)量管理

敏捷軟件過程有諸多不同的類型，在國內(nèi)比較廣為人知的有XP、Scrum等[1]。2001年2月，這些不同方法的創(chuàng)始人成立了Agile聯(lián)盟，并正式將該類方法統(tǒng)稱為Agile[9]，即敏捷。

敏捷的價(jià)值觀是[10]：

人及交流的作用勝過過程和工具；

可運(yùn)行的軟件勝過復(fù)雜的文檔；

客戶的協(xié)作勝過合同協(xié)商；

響應(yīng)變更勝過固守計(jì)劃。

敏捷是適應(yīng)性的，而非預(yù)測性的開發(fā)方法。盡管敏捷過程在適應(yīng)需求變化方面廣泛受到軟件領(lǐng)域歡迎，但由于敏捷軟件開發(fā)強(qiáng)調(diào)“面向人”的靈活性，缺乏統(tǒng)一的質(zhì)量標(biāo)準(zhǔn)與策略。而大多數(shù)敏捷軟件過程的研究主要圍繞軟件的開發(fā)過程，敏捷開發(fā)中的軟件測試過程沒有受到足夠關(guān)注，因而缺乏對軟件測試過程的獨(dú)立的指導(dǎo)。文獻(xiàn)[4]中還指出，敏捷開發(fā)過程中質(zhì)量監(jiān)控過程不夠標(biāo)準(zhǔn)化，當(dāng)項(xiàng)目較復(fù)雜或工作量較大時(shí)缺乏統(tǒng)一的質(zhì)量標(biāo)準(zhǔn)，難以保證進(jìn)度。

2 基于戴明循環(huán)的軟件測試過程

與傳統(tǒng)軟件開發(fā)過程相比，敏捷過程由于更注重適應(yīng)性，因而具有更高的不可預(yù)測性，對軟件質(zhì)量管理過程提出了更高要求。敏捷過程中的Scrum方法源于對迭代式面向?qū)ο箝_發(fā)方法的改進(jìn)，受到諸多公司的應(yīng)用。本文借鑒敏捷開發(fā)實(shí)踐[11]，結(jié)合戴明循環(huán)理論，對軟件質(zhì)量管理過程提出如下方法。

Scrum方法包括三個(gè)過程：計(jì)劃和設(shè)計(jì)、沖刺、交付和鞏固。整個(gè)流程如圖2所示。

圖2 Scrum方法過程示意圖

在一次Scrum過程中，首先Scrum團(tuán)隊(duì)需要從產(chǎn)品需求中篩選出本次沖刺最需要解決的問題，形成沖刺需求。在此過程中，由于軟件質(zhì)量保障小組需要參與的任務(wù)不明顯，軟件質(zhì)量保障過程應(yīng)進(jìn)行戴明循環(huán)的檢查階段和處理階段。

與軟件工程層次的戴明循環(huán)不同，在軟件測試子過程的管理中，檢查階段不僅要對更高層次戴明循環(huán)的狀況進(jìn)行分析檢查，更主要的是找出測試過程本身所存在的問題，分析并找到其根本原因，形成強(qiáng)化經(jīng)驗(yàn)，使測試過程更符合待測軟件的特性。此外，處理階段將著重解決檢查階段發(fā)現(xiàn)的問題，對測試用例、測試腳本等進(jìn)行改進(jìn)，從而使下一輪測試能夠更完備。

此后進(jìn)入Scrum的沖刺過程。該過程中，開發(fā)團(tuán)隊(duì)將針對沖刺需求進(jìn)行實(shí)現(xiàn)。此時(shí)質(zhì)量保障小組需要進(jìn)行戴明循環(huán)的計(jì)劃階段，根據(jù)本次沖刺的沖刺需求，以及開發(fā)團(tuán)隊(duì)在開發(fā)過程中的文檔、進(jìn)度等，參照以往測試的經(jīng)驗(yàn)，結(jié)合上一輪測試的結(jié)果，利用5W1H的思想，對測試所需環(huán)境進(jìn)行籌備并制定測試計(jì)劃。測試計(jì)劃需要具有明確的可執(zhí)行性，并應(yīng)當(dāng)在測試計(jì)劃中具有可以進(jìn)行過程監(jiān)控的指標(biāo)。

Scrum的交付和鞏固階段時(shí)，軟件質(zhì)量保障小組將按照計(jì)劃階段所制定測試計(jì)劃，執(zhí)行相關(guān)測試用例，對交付物進(jìn)行測試。此外還需要對執(zhí)行過程進(jìn)行過程監(jiān)控，完成測試任務(wù)并記錄發(fā)現(xiàn)的軟件缺陷，撰寫所需測試報(bào)告。匯總對執(zhí)行過程的監(jiān)控結(jié)果并為檢查階段準(zhǔn)備數(shù)據(jù)。

結(jié)合戴明循環(huán)后的整個(gè)Scrum過程如圖3所示。

圖3 Scrum與戴明循環(huán)結(jié)合示意圖

與現(xiàn)存主流的軟件質(zhì)量管理過程不同，該過程作為整個(gè)敏捷開發(fā)中軟件測試子過程，注重對軟件測試過程本身的反饋和完善，提高軟件測試的執(zhí)行質(zhì)量，進(jìn)一步達(dá)到有效提高軟件質(zhì)量的目的。

3 應(yīng)用實(shí)例

作者在甲骨文軟件研究開發(fā)中心工作期間，在團(tuán)隊(duì)中分析并使用了該過程。

作者所在的Solaris Desktop團(tuán)隊(duì)主要負(fù)責(zé)Solaris系統(tǒng)的桌面應(yīng)用程序開發(fā)及測試。整個(gè)團(tuán)隊(duì)采用Scrum的敏捷開發(fā)方法。產(chǎn)品每2周為一個(gè)沖刺，每個(gè)沖刺都有不同的桌面應(yīng)用被更新。開發(fā)部門在完成更新后，會交給發(fā)行工程師將整個(gè)桌面環(huán)境進(jìn)行打包。發(fā)行工程師在完成打包后，會將軟件包的存儲路徑發(fā)送郵件給測試團(tuán)隊(duì)。自動(dòng)化測試框架在收到郵件后會自動(dòng)觸發(fā)安裝、測試等操作，并在完成自動(dòng)化測試后將結(jié)果發(fā)送到測試團(tuán)隊(duì)的郵件列表。之后軟件質(zhì)量工程師進(jìn)行結(jié)果的檢查以及運(yùn)行手動(dòng)測試部分。

隨著產(chǎn)品的不斷更新，觀察到測試的耗時(shí)在逐漸增長。在該背景下，團(tuán)隊(duì)開始采用戴明循環(huán)的方法進(jìn)行測試過程的管理。對于整個(gè)自動(dòng)化過程的首次循環(huán)過程中，更多的是將問題逐步明確。在計(jì)劃與執(zhí)行階段，首先修改整個(gè)測試的測試計(jì)劃，在測試計(jì)劃中添加了對測試過程的監(jiān)控要求，從而為檢查階段提供必要的信息獲取途徑。執(zhí)行階段仍按照以往的經(jīng)驗(yàn)完成整個(gè)測試過程，并記載所需時(shí)間。檢查階段分析整個(gè)測試過程的關(guān)鍵路徑，如圖4所示。

圖4 關(guān)鍵路徑分析

從分析中發(fā)現(xiàn)，由于為了保障整個(gè)測試過程的完備性，自動(dòng)化測試過程與手動(dòng)驗(yàn)證、手動(dòng)測試過程必須使用同一個(gè)測試環(huán)境。而整個(gè)自動(dòng)化過程必須獨(dú)占整個(gè)測試環(huán)境且具有最長的時(shí)間開銷，因而自動(dòng)化測試過程為整個(gè)過程的關(guān)鍵路徑。進(jìn)一步對比以往的自動(dòng)化測試結(jié)果發(fā)現(xiàn)，自動(dòng)化測試過程耗時(shí)還受到待測軟件包的影響，并隨著軟件包的不斷更新，自動(dòng)化測試的耗時(shí)一直在增長。因此在處理階段對自動(dòng)化測試的記錄進(jìn)行了分析和總結(jié)，并將自動(dòng)化測試過程作為下一輪循環(huán)的優(yōu)化重點(diǎn)。在后一輪循環(huán)過程中，在原計(jì)劃中增加了對自動(dòng)化測試的記錄，并在檢查階段發(fā)現(xiàn)，自動(dòng)化測試的某些測試失敗比例比較高，并有部分自動(dòng)化測試由于環(huán)境原因無法一次完成，自動(dòng)化框架會對該部分觸發(fā)第二次測試。這不僅給后期的手動(dòng)驗(yàn)證工作增加了負(fù)擔(dān)，而且花費(fèi)了大量額外時(shí)間開銷。通過進(jìn)一步分析發(fā)現(xiàn)，部分待測軟件包由于具有細(xì)微的特性變化，導(dǎo)致其測試完成后對環(huán)境的更改與預(yù)期不同，而在測試腳本的設(shè)計(jì)過程中沒有針對該類情況進(jìn)行容錯(cuò)處理。

在發(fā)現(xiàn)上述問題后，仍采用戴明循環(huán)的方法，逐步在循環(huán)過程中修復(fù)了部分自動(dòng)化測試腳本，并提高了測試腳本的魯棒性，使整個(gè)測試逐步適應(yīng)新的產(chǎn)品，有效降低了整個(gè)測試過程的時(shí)間成本，如表1所示。

表1 應(yīng)用戴明循環(huán)前后自動(dòng)化測試狀態(tài)比較

我們也針對具體測試對象應(yīng)用了戴明循環(huán)。Solaris Desktop團(tuán)隊(duì)負(fù)責(zé)Solaris平臺上Firefox的編譯、測試等。在每次Firefox發(fā)布ESR版本后，我們都要對新版本進(jìn)行編譯與測試。計(jì)劃階段在新的ESR版本發(fā)行后隨之開始。在該階段，要將新的版本與上一個(gè)ESR版本進(jìn)行對比，找出其新的特性，針對這些特性增加新的測試用例，并獲取Firefox最新的自動(dòng)化測試套件，針對Solaris系統(tǒng)進(jìn)行配置。在執(zhí)行階段，將按照計(jì)劃階段的輸出，運(yùn)行相應(yīng)的測試用例，并將測試結(jié)果和日志信息保留進(jìn)行分析。檢查階段，會詳細(xì)分析測試的每一個(gè)結(jié)果與測試日志。在自動(dòng)化測試腳本中，對于專門針對Windows操作系統(tǒng)或者M(jìn)ac OS操作系統(tǒng)的特性變更，該部分在Solaris系統(tǒng)上不適用，因此在分析結(jié)果并找出該類測試用例以及測試步驟后在處理階段將該測試刪除；部分測試用例只有針對Windows或者Linux操作系統(tǒng)的描述，不能直接在Solaris系統(tǒng)環(huán)境中運(yùn)行，對于該類自動(dòng)化測試，會在處理階段對腳本逐步進(jìn)行改善。經(jīng)過幾輪循環(huán)后，針對Firefox的自動(dòng)化測試腳本會變得更加適合團(tuán)隊(duì)的測試需要。

在不斷的循環(huán)過程中，測試過程的有效性也得到了不斷提高。定義由Desktop團(tuán)隊(duì)發(fā)現(xiàn)的桌面系統(tǒng)的故障數(shù)量為I1，故障管理系統(tǒng)中桌面系統(tǒng)的故障總數(shù)量為I2。其比值可以有效反映測試的有效性，即E=I1∶I2。根據(jù)故障管理系統(tǒng)中的數(shù)據(jù)，E的值在采用戴明循環(huán)之后出現(xiàn)了上升趨勢，如表2所示。

表2 測試有效性變化

在質(zhì)量管理過程中采用戴明循環(huán)半年后，每一輪循環(huán)的人員開銷由采用前的12人/天降低到6人/天，團(tuán)隊(duì)的工作效率提升了1倍。

4 結(jié) 語

本文對戴明循環(huán)在敏捷軟件測試過程本身進(jìn)行研究，并給出了在具體項(xiàng)目應(yīng)用中戴明循環(huán)的執(zhí)行策略。

由于敏捷開發(fā)更重視“面向人”的靈活性，在敏捷開發(fā)中引入戴明循環(huán)所帶來的提升作用，仍一定程度上受到人的主觀因素影響。

在軟件質(zhì)量保障中，戴明循環(huán)適用于產(chǎn)品功能相對穩(wěn)定的項(xiàng)目，以及雖然產(chǎn)品功能持續(xù)變化，但敏捷開發(fā)的每個(gè)階段均能夠有充足時(shí)間進(jìn)行軟件測試的項(xiàng)目中。在產(chǎn)品特性變化非?？?，以及每日構(gòu)建型的敏捷項(xiàng)目中，由于每輪測試難以受到有效的檢查以及改進(jìn)，戴明循環(huán)難以得到有效的應(yīng)用。

在此后的研究中，針對敏捷開發(fā)模式下產(chǎn)品特性劇烈變化的項(xiàng)目以及每日構(gòu)建的項(xiàng)目軟件質(zhì)量的保障與提升仍有待研究。

[1] 沈備軍,陳誠,居德華. 敏捷軟件過程的研究[J].計(jì)算機(jī)研究與發(fā)展,2002，39(11):1456-1463.

[2] 謝東強(qiáng). 敏捷軟件開發(fā)的雙迭代模型[J].計(jì)算機(jī)應(yīng)用與軟件,2012，29(6):176-178,198.

[3] Aoyama Mikio. Agile software process and its experience[C]//Proceedings of the 20th international conference on Software engineering (ICSE’98). IEEE Computer Society, 1998:3-12.

[4] 徐琳,陳荔,楊麗. 6 Sigma管理在敏捷軟件開發(fā)中的應(yīng)用[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用,2011，20(6):85-88,20.

[5] JingFeng Ning, Zhiyu Chen,Gang Liu. PDCA Process Application in the Continuous Improvement of Software Quality[C]//Proceedings of the 2010 International Conference on Computer, Mechatronics, Control and Electronic Engineering (CMCE). IEEE, 2010,1:61-65.

[6] 武占春,王青,李明樹. 一種基于PDCA的軟件過程控制與改進(jìn)模型[J]. 軟件學(xué)報(bào),2006，17(8):1669-1680.

[7] 王青,李明樹,劉霞.一種支持軟件過程控制和改進(jìn)的主動(dòng)度量模型[J].軟件學(xué)報(bào),2005,16(3):407-418.

[8] 黃飛雪,李志潔,孫效里. 基于PDCA的印度軟件質(zhì)量保證模型研究[J]. 哈爾濱工業(yè)大學(xué)學(xué)報(bào),2005，37(11):1583-1585.

[9] 張敬周,錢樂秋,朱三元. Agile方法研究綜述[J]. 計(jì)算機(jī)應(yīng)用與軟件,2002，19(6):1-9,54.

[10] Agile Alliance. The Agile Manifesto[EB/OL].http://www.agilealliance.org/the-alliance/the-agile-manifesto/.

[11] Agarwal A， Garg N K， Jain A. Quality assurance for Product development using Agile[C]//2014 International Conference on Optimization, Reliability and Information Technology (ICROIT),2014:44-47.

RESEARCH ON APPLYING DEMING CYCLE IN AGILE SOFTWARE QUALITY MANAGEMENT

Sun Ziqian1,2Wang Yaqin1*Huang Mingming1

1(CollegeofInformationScienceandEngineering,ShandongAgriculturalUniversity,Taian271018,Shandong，China)2(OracleSoftwareResearchandDevelopmentCenter(Beijing)Co.,Ltd.,Beijing100193,China)

Agile software process is adopted by more and more software companies with its ability to adapt to the rapid change, meanwhile the agile development also greatly challenges the software quality management. In light to the features of agile development process in software quality assurance, taking the practical project as the example we propose a Deming cycle-based software test process. This test process carries out the improvement in the way of self-feedback on software test flow, thus increases the effectiveness of software test and reduces the overhead in resources, and this enables the software test process to be capable of adapting to the requirement of agile development.

Deming cycle Software quality Agile process Software test Quality management

2015-07-22。孫子謙，碩士生，主研領(lǐng)域：計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)，Linux應(yīng)用。王雅琴，教授。黃明明，碩士生。

TP311.5

A

10.3969/j.issn.1000-386x.2016.11.002