戴明循環在敏捷軟件質量管理中的應用方法研究

孫子謙 王雅琴 黃明明

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

?

戴明循環在敏捷軟件質量管理中的應用方法研究

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

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

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

戴明循環 軟件質量 敏捷過程 軟件測試 質量管理

0 引 言

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

戴明循環是工業產品質量管理領域得到廣泛認可的管理理論。由于軟件不是一種實體產品，其質量管理與工業產品有較大的差異。因而戴明循環理論并不能照搬到軟件質量管理過程中。

1 戴明循環和敏捷軟件質量管理

1.1 戴明循環

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

PDCA是一個自反饋式循環往復的過程，且在PDCA的各個階段內部還能進行子循環，以解決該階段的問題。

單次PDCA循環的示意如圖1所示。

圖1 一次PDCA循環示意圖

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

1.2 敏捷軟件質量管理

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

敏捷的價值觀是[10]：

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

可運行的軟件勝過復雜的文檔；

客戶的協作勝過合同協商；

響應變更勝過固守計劃。

敏捷是適應性的，而非預測性的開發方法。盡管敏捷過程在適應需求變化方面廣泛受到軟件領域歡迎，但由于敏捷軟件開發強調“面向人”的靈活性，缺乏統一的質量標準與策略。而大多數敏捷軟件過程的研究主要圍繞軟件的開發過程，敏捷開發中的軟件測試過程沒有受到足夠關注，因而缺乏對軟件測試過程的獨立的指導。文獻[4]中還指出，敏捷開發過程中質量監控過程不夠標準化，當項目較復雜或工作量較大時缺乏統一的質量標準，難以保證進度。

2 基于戴明循環的軟件測試過程

與傳統軟件開發過程相比，敏捷過程由于更注重適應性，因而具有更高的不可預測性，對軟件質量管理過程提出了更高要求。敏捷過程中的Scrum方法源于對迭代式面向對象開發方法的改進，受到諸多公司的應用。本文借鑒敏捷開發實踐[11]，結合戴明循環理論，對軟件質量管理過程提出如下方法。

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

圖2 Scrum方法過程示意圖

在一次Scrum過程中，首先Scrum團隊需要從產品需求中篩選出本次沖刺最需要解決的問題，形成沖刺需求。在此過程中，由于軟件質量保障小組需要參與的任務不明顯，軟件質量保障過程應進行戴明循環的檢查階段和處理階段。

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

此后進入Scrum的沖刺過程。該過程中，開發團隊將針對沖刺需求進行實現。此時質量保障小組需要進行戴明循環的計劃階段，根據本次沖刺的沖刺需求，以及開發團隊在開發過程中的文檔、進度等，參照以往測試的經驗，結合上一輪測試的結果，利用5W1H的思想，對測試所需環境進行籌備并制定測試計劃。測試計劃需要具有明確的可執行性，并應當在測試計劃中具有可以進行過程監控的指標。

Scrum的交付和鞏固階段時，軟件質量保障小組將按照計劃階段所制定測試計劃，執行相關測試用例，對交付物進行測試。此外還需要對執行過程進行過程監控，完成測試任務并記錄發現的軟件缺陷，撰寫所需測試報告。匯總對執行過程的監控結果并為檢查階段準備數據。

結合戴明循環后的整個Scrum過程如圖3所示。

圖3 Scrum與戴明循環結合示意圖

與現存主流的軟件質量管理過程不同，該過程作為整個敏捷開發中軟件測試子過程，注重對軟件測試過程本身的反饋和完善，提高軟件測試的執行質量，進一步達到有效提高軟件質量的目的。

3 應用實例

作者在甲骨文軟件研究開發中心工作期間，在團隊中分析并使用了該過程。

作者所在的Solaris Desktop團隊主要負責Solaris系統的桌面應用程序開發及測試。整個團隊采用Scrum的敏捷開發方法。產品每2周為一個沖刺，每個沖刺都有不同的桌面應用被更新。開發部門在完成更新后，會交給發行工程師將整個桌面環境進行打包。發行工程師在完成打包后，會將軟件包的存儲路徑發送郵件給測試團隊。自動化測試框架在收到郵件后會自動觸發安裝、測試等操作，并在完成自動化測試后將結果發送到測試團隊的郵件列表。之后軟件質量工程師進行結果的檢查以及運行手動測試部分。

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

圖4 關鍵路徑分析

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

在發現上述問題后，仍采用戴明循環的方法，逐步在循環過程中修復了部分自動化測試腳本，并提高了測試腳本的魯棒性，使整個測試逐步適應新的產品，有效降低了整個測試過程的時間成本，如表1所示。

表1 應用戴明循環前后自動化測試狀態比較

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

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

表2 測試有效性變化

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

4 結 語

本文對戴明循環在敏捷軟件測試過程本身進行研究，并給出了在具體項目應用中戴明循環的執行策略。

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

在軟件質量保障中，戴明循環適用于產品功能相對穩定的項目，以及雖然產品功能持續變化，但敏捷開發的每個階段均能夠有充足時間進行軟件測試的項目中。在產品特性變化非常快，以及每日構建型的敏捷項目中，由于每輪測試難以受到有效的檢查以及改進，戴明循環難以得到有效的應用。

在此后的研究中，針對敏捷開發模式下產品特性劇烈變化的項目以及每日構建的項目軟件質量的保障與提升仍有待研究。

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

[2] 謝東強. 敏捷軟件開發的雙迭代模型[J].計算機應用與軟件,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管理在敏捷軟件開發中的應用[J]. 計算機系統應用,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]. 軟件學報,2006，17(8):1669-1680.

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

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

[9] 張敬周,錢樂秋,朱三元. Agile方法研究綜述[J]. 計算機應用與軟件,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。孫子謙，碩士生，主研領域：計算機網絡技術，Linux應用。王雅琴，教授。黃明明，碩士生。

TP311.5

A

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