徐東　張曉雯　楊健　劉海見

摘 要：本文對當(dāng)前的測試模型、CMM（Capability Maturity Model，能力成熟度模型）與工作流技術(shù)進(jìn)行了研究和分析，提出了在CMM軟件開發(fā)過程中，采用改進(jìn)型H過程模型進(jìn)行軟件測試，該模型能很好地解決CMM測試管理環(huán)境中的測試流程定義、解釋執(zhí)行和監(jiān)控等相關(guān)問題，在測試過程中始終貫穿著敏捷思想，對中小型軟件開發(fā)的測試有著很好的適用性。

關(guān)鍵詞：軟件測試；敏捷；H模型；CMM；工作流

中圖分類號： TP311.52 文獻(xiàn)標(biāo)識碼：A

1 引言（Introduction）

隨著軟件產(chǎn)品需求的增長與軟件開發(fā)能力的增強(qiáng)，軟件質(zhì)量問題亦變得尤為重要。近年來，以軟件測試為中心的軟件質(zhì)量保障技術(shù)在軟件開發(fā)中得到迅猛發(fā)展，已成為必不可少的軟件質(zhì)量保障手段。軟件開發(fā)是一個(gè)系統(tǒng)工程，軟件測試的目標(biāo)是力求以最少的人力、物力、財(cái)力、開發(fā)時(shí)間，盡可能多地檢測、分析、預(yù)測出軟件開發(fā)中潛在的各種錯(cuò)誤和缺陷。一個(gè)好的軟件測試模型和測試方法是有效實(shí)施軟件測試的基礎(chǔ)，將直接影響測試結(jié)果的準(zhǔn)確性和有效性。

為提高測試模型的有效性，本文闡述了在基于CMM的項(xiàng)目開發(fā)過程中，研究一種基于工作流技術(shù)的較為高效的軟件測試模型及軟件測試流程。該模型及測試流程能合理地將測試過程劃分為各個(gè)測試階段，并有效實(shí)施測試各階段中的測試活動(dòng)，使測試工作覆蓋整個(gè)軟件項(xiàng)目的開發(fā)生命周期。

2 CMM概述（CMM summarize）

自20世紀(jì)70年代中期以來，隨著軟件開發(fā)行業(yè)的不斷發(fā)展，軟件開發(fā)規(guī)模越來越大，而軟件開發(fā)質(zhì)量卻越來越難以保證，因而出現(xiàn)了嚴(yán)重的軟件危機(jī)。提高計(jì)算機(jī)軟件產(chǎn)品的生產(chǎn)率和質(zhì)量成為了軟件工程領(lǐng)域研究的一個(gè)焦點(diǎn)，探索新的軟件開發(fā)方法和軟件測試技術(shù)勢在必行。1987年前后，美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所的Watts Humphrey等人，為了進(jìn)一步提高軟件開發(fā)質(zhì)量，提出了軟件過程、軟件能力成熟度等級等概念及SW-CMM，即目前簡稱的CMM（Software Capability Maturity Model軟件能力成熟度模型）。

CMM可以科學(xué)地評價(jià)軟件開發(fā)單位的軟件能力成熟等級，客觀地反映其軟件在開發(fā)水平，同時(shí)，CMM能幫助軟件開發(fā)單位進(jìn)行軟件能力自檢，促使軟件在開發(fā)過程不斷完善和改進(jìn)。這種內(nèi)外共用的評價(jià)機(jī)制，確保了軟件開發(fā)質(zhì)量，提高了軟件開發(fā)效率。在軟件開發(fā)領(lǐng)域，CMM已經(jīng)越來越受到重視。

CMM共分為5個(gè)級別，以目前業(yè)界的通行標(biāo)準(zhǔn)，軟件質(zhì)量可用每千行源代碼所包含的Bug數(shù)來衡量。在CMM各等級中，一級11.95個(gè)，二級5.52個(gè)，三級2.39個(gè)，四級0.92個(gè)，而五級則只有0.32個(gè)[1，2]，可見，隨著CMM級別的提高，軟件開發(fā)的可靠性也有了數(shù)量級的改進(jìn)。目前，在參加了CMM認(rèn)定的中小軟件開發(fā)單位中，大多數(shù)通過CMM二級或三級。

3 工作流技術(shù)（Workflow technology）

工作流管理技術(shù)擁有可分離性、可重用性等特點(diǎn)，有著獨(dú)特的業(yè)務(wù)邏輯與過程邏輯。為了進(jìn)一步提高產(chǎn)品生產(chǎn)率，工作流技術(shù)已經(jīng)被逐步應(yīng)用于過程自動(dòng)化以及應(yīng)用系統(tǒng)集成中。在軟件開發(fā)領(lǐng)域中引入工作流技術(shù)與工作流管理系統(tǒng)，不但能夠降低軟件開發(fā)風(fēng)險(xiǎn)，而且能夠使業(yè)務(wù)流程的實(shí)現(xiàn)代碼集中統(tǒng)一，不再是散落在各種各樣的系統(tǒng)中，加快應(yīng)用開發(fā)，代碼更容易維護(hù)，提高對迭代開發(fā)的支持。在工作流管理系統(tǒng)中，可以較容易地部署新業(yè)務(wù)流程，通常采用迭代的方式開發(fā)，因此，把工作流技術(shù)應(yīng)用在敏捷開發(fā)與測試中，能增強(qiáng)有效性，使開發(fā)風(fēng)險(xiǎn)更低[3]。

4 軟件測試過程模型和選取策略（Software testing process model and selection strategy）

目前，比較常用的軟件測試過程模型主要有 V 模型、W模型等。

V模型清晰地描述了測試和開發(fā)過程各個(gè)階段之間的對應(yīng)關(guān)系，是最具代表意義的測試模型。但V模型容易讓人認(rèn)為測試只能在軟件開發(fā)之后進(jìn)行，其原因是，V模型把系統(tǒng)開發(fā)過程劃分為具有固定邊界的不同階段。同時(shí)，V模型也沒有明確測試設(shè)計(jì)，使得直到最終的驗(yàn)收測試階段才發(fā)現(xiàn)軟件開發(fā)初期的錯(cuò)誤，造成更大的開發(fā)代價(jià)。

W模型雖說在V模型基礎(chǔ)上有改進(jìn)。但實(shí)質(zhì)上，V模型和W模型所出現(xiàn)的問題也都是相似的，兩者都認(rèn)為軟件開發(fā)是需求、設(shè)計(jì)、編碼等固定行為和活動(dòng)，這類項(xiàng)目中，所有開發(fā)和測試人員都要按照事先定義好的軟件開發(fā)順序開展工作。而實(shí)際上，軟件開發(fā)不可避免地會產(chǎn)生階段性需求變動(dòng)，文檔亦要求時(shí)時(shí)更新，軟件開發(fā)活動(dòng)在大部分時(shí)間內(nèi)可以交叉，這樣V模型和W模型就難以實(shí)施，二者只適用于那些需求非常明確的項(xiàng)目。

H模型較好地體現(xiàn)了敏捷測試原則，提倡“盡早測試”“全程測試”“獨(dú)立測試”和“迭代測試”。H模型運(yùn)行中，只要測試準(zhǔn)備活動(dòng)完成了，測試執(zhí)行活動(dòng)就可以開始，其測試流程可以是任意的開發(fā)流程，其他流程的進(jìn)展可以及時(shí)地觸發(fā)測試就緒點(diǎn)。H模型很好地解決W、V模型存在的問題，達(dá)到更好的測試效果。H模型對軟件測試過程作了定義，將軟件測試過程劃分為測試需求、策劃、設(shè)計(jì)、執(zhí)行、總結(jié)五個(gè)階段，如圖1所示。

H模型雖然兼顧效率和靈活性，但它沒有提出具體的應(yīng)用模型，而單純的理論測試模型只能實(shí)現(xiàn)對軟件測試過程進(jìn)行抽象描述，因此必然存在有未被此測試模型涉及的特性，而工作流技術(shù)能很好地解決測試管理環(huán)境中的測試流程定義、測試流程解釋執(zhí)行和監(jiān)控等相關(guān)問題，從而實(shí)現(xiàn)預(yù)期的業(yè)務(wù)目標(biāo)?；贖模型的理論，將工作流引入到H模型中，重新對軟件測試的流程進(jìn)行系統(tǒng)的分析，提出一種適用CMM軟件項(xiàng)目開發(fā)的軟件測試流程，并構(gòu)造出一個(gè)以任務(wù)分配為驅(qū)動(dòng)的CMM軟件測試管理應(yīng)用模型。

5 基于工作流的CMM軟件測試H模型（The CMMsoftware testing H model based on workflow）endprint

CMM在提高軟件開發(fā)質(zhì)量方面的作用已經(jīng)得到廣泛認(rèn)可，但CMM只是對項(xiàng)目開發(fā)提出了要求，至于具體實(shí)施過程，還需要更加行之有效的實(shí)施方法、技術(shù)和工具的支持，為使開發(fā)業(yè)務(wù)過程的部分或全部實(shí)現(xiàn)自動(dòng)執(zhí)行，引入工作流技術(shù)。

5.1 工作流元模型[3]

工作流管理聯(lián)盟定義的過程元模型PDM（Process Definition Meta-mode）的結(jié)構(gòu)， 定義工作流語義模型的構(gòu)造和規(guī)則，描述工作流模型內(nèi)部包含的各個(gè)對象以及對象之間的關(guān)系和屬性，如圖2所示。

5.2 CMM軟件測試H模型

在CMM開發(fā)模式下，結(jié)合可行性和易用性，以H模型為基礎(chǔ)，結(jié)合工作流技術(shù)，針對CMM中小軟件開發(fā)的實(shí)際工作情況，在原有研究基礎(chǔ)上建立軟件測試管理應(yīng)用模型[4]，如圖3所示。

這個(gè)模型中，軟件開發(fā)與測試并發(fā)執(zhí)行，構(gòu)成H模型結(jié)構(gòu)，核心部件為工作流引擎，它負(fù)責(zé)執(zhí)行任務(wù)分配，該模型強(qiáng)調(diào)盡早測試等敏捷軟件測試原則，其測試基本流程為：

（1）測試用例。由測試及設(shè)計(jì)人員共同建立合格的測試用例庫，作為測試任務(wù)分配的對象。

（2）工作流引擎。測試工作流引擎由任務(wù)分配觸發(fā)，制定相關(guān)工作流各階段的測試方案，并由專家進(jìn)行測試方案評審，評審?fù)ㄟ^后，由測試員進(jìn)行測試執(zhí)行。若測試結(jié)果無錯(cuò)誤，則執(zhí)行相關(guān)的測試評估與度量，填寫相關(guān)文檔，相關(guān)測試用例關(guān)閉；若測試有錯(cuò)誤則產(chǎn)生相關(guān)缺陷。

（3）缺陷審核。產(chǎn)生的缺陷如果經(jīng)審核是一個(gè)待修正缺陷，則作為修正的任務(wù)分配對象。

（4）缺陷修正。任務(wù)分配觸發(fā)缺陷修正工作流引擎，由軟件設(shè)計(jì)人員進(jìn)行修正執(zhí)行，修正確認(rèn)完成后進(jìn)入回歸測試。待回歸測試的缺陷又成為任務(wù)分配的新對象。

（5）迭代測試。回歸測試再次觸發(fā)工作流引擎，回到（2）迭代執(zhí)行，如此往復(fù)直至無缺陷并關(guān)閉。

5.3 測試任務(wù)分配

依照計(jì)劃、執(zhí)行、檢查、調(diào)整的原則進(jìn)行測試任務(wù)的分配，要求在執(zhí)行任何測試前必須有相應(yīng)的測試計(jì)劃和測試用例，明確測試活動(dòng)以及測試評估所需要的時(shí)間和資源，然后進(jìn)行測試人員安排和測試任務(wù)分配等[5]。如圖4所示。

當(dāng)測試任務(wù)發(fā)起人發(fā)起一項(xiàng)測試任務(wù)后，將該任務(wù)將傳遞給測試任務(wù)承接人，由承接人進(jìn)行任務(wù)處理。承接人完成任務(wù)處理后，交還給測試任務(wù)發(fā)起人確認(rèn)，如果測試任務(wù)確實(shí)已完成，由測試任務(wù)發(fā)起人關(guān)閉該測試任務(wù)。如圖5所示。

5.4 測試用例缺陷狀態(tài)變遷

把測試用例分靜態(tài)和動(dòng)態(tài)兩種狀態(tài)，這樣可以支持多輪測試。當(dāng)一個(gè)測試用例經(jīng)過任務(wù)分配后，測試用例狀態(tài)則由靜態(tài)轉(zhuǎn)為動(dòng)態(tài)，在該模型中，只有動(dòng)態(tài)測試用例才參與真正的測試。動(dòng)態(tài)測試用例主要包括測試用例的狀態(tài)信息、測試報(bào)告內(nèi)容、測試結(jié)果確認(rèn)等信息，可用NO Run（尚處在設(shè)計(jì)階段或尚未被執(zhí)行）、Passed（已成功）、Failed（已失敗）、 Blocked（設(shè)計(jì)出問題）四個(gè)狀態(tài)來跟蹤測試用例的執(zhí)行情況，而靜態(tài)測試用例只包括測試邏輯和測試數(shù)據(jù)。

軟件缺陷的產(chǎn)生可能發(fā)生在軟件生命周期的每個(gè)階段，而且這種軟件缺陷可能是由上一個(gè)階段的工作失誤造成，所以，對軟件缺陷實(shí)行跟蹤管理在整個(gè)軟件開發(fā)過程中都是非常必要的。在理想狀態(tài)下，能夠根據(jù)測試人員的預(yù)定要求，在測試之前對軟件缺陷的狀態(tài)以及缺陷狀態(tài)之間的流換路徑進(jìn)行設(shè)置[6]。

缺陷狀態(tài)周期分成可分為六個(gè)態(tài)，分別是open態(tài)、working態(tài)、verify態(tài)、cancel態(tài)、defer態(tài)和close態(tài)。其中open態(tài)標(biāo)識新出現(xiàn)的缺陷或沒被修改的缺陷；working態(tài)標(biāo)識軟件開發(fā)人員正在修改和糾正的缺陷；verify態(tài)標(biāo)識軟件設(shè)計(jì)人員已修改完缺陷，并請求結(jié)果驗(yàn)證；close態(tài)標(biāo)識缺陷已被修正，否則將其狀態(tài)重置為open態(tài)；cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報(bào)的一個(gè)存在的缺陷；defer態(tài)說明，如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價(jià)過高，如果該缺陷的優(yōu)先級不高，則缺陷修正可以推遲。如圖6所示。

6 結(jié)論（Conclusion）

基于工作流的CMM軟件測試H模型將測試過程從開發(fā)過程中適當(dāng)?shù)某橄蟪鰜?，作為一個(gè)獨(dú)立的過程進(jìn)行管理，在CMM規(guī)則框架下較好地體現(xiàn)了盡早、全面、全過程、迭代測試等敏捷測試思想。該模型能很好地解決CMM測試管理環(huán)境中的測試流程定義、解釋執(zhí)行和監(jiān)控等相關(guān)問題，使整個(gè)測試過程更加清晰，節(jié)約了開發(fā)時(shí)間，使測試活動(dòng)更加合理，有效保證整個(gè)軟件產(chǎn)品的質(zhì)量，對中小型軟件開發(fā)的測試有著很好的適用性。

參考文獻(xiàn)（References）

[1] 俞磊，等.基于CMM-3的軟件測試過程模型的研究[J].計(jì)算機(jī)與數(shù)字工程，2011（7）：79-82.

[2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實(shí)現(xiàn)[D].西安：西安理工大學(xué)，2007.

[3] 趙瑞東，等.工作流與工作流管理技術(shù)綜述[J].科技信息，2007（8）：105-107.

[4] 張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導(dǎo)刊，2013（2）：24-26.

[5] 鄭小軍，等.基于工作流技術(shù)的軟件測試流程定義與監(jiān)控[J].計(jì)算機(jī)應(yīng)用研究，2007（2）：43-45.

[6] 吳慧韞.基于工作流的軟件測試管理系統(tǒng)研究與設(shè)計(jì)[D].南昌：南昌大學(xué)，2005.

作者簡介：

徐 東（1972-），男，碩士，講師.研究領(lǐng)域：計(jì)算機(jī)視覺與人工智能、計(jì)算機(jī)教育.endprint

CMM在提高軟件開發(fā)質(zhì)量方面的作用已經(jīng)得到廣泛認(rèn)可，但CMM只是對項(xiàng)目開發(fā)提出了要求，至于具體實(shí)施過程，還需要更加行之有效的實(shí)施方法、技術(shù)和工具的支持，為使開發(fā)業(yè)務(wù)過程的部分或全部實(shí)現(xiàn)自動(dòng)執(zhí)行，引入工作流技術(shù)。

5.1 工作流元模型[3]

工作流管理聯(lián)盟定義的過程元模型PDM（Process Definition Meta-mode）的結(jié)構(gòu)， 定義工作流語義模型的構(gòu)造和規(guī)則，描述工作流模型內(nèi)部包含的各個(gè)對象以及對象之間的關(guān)系和屬性，如圖2所示。

5.2 CMM軟件測試H模型

在CMM開發(fā)模式下，結(jié)合可行性和易用性，以H模型為基礎(chǔ)，結(jié)合工作流技術(shù)，針對CMM中小軟件開發(fā)的實(shí)際工作情況，在原有研究基礎(chǔ)上建立軟件測試管理應(yīng)用模型[4]，如圖3所示。

這個(gè)模型中，軟件開發(fā)與測試并發(fā)執(zhí)行，構(gòu)成H模型結(jié)構(gòu)，核心部件為工作流引擎，它負(fù)責(zé)執(zhí)行任務(wù)分配，該模型強(qiáng)調(diào)盡早測試等敏捷軟件測試原則，其測試基本流程為：

（1）測試用例。由測試及設(shè)計(jì)人員共同建立合格的測試用例庫，作為測試任務(wù)分配的對象。

（2）工作流引擎。測試工作流引擎由任務(wù)分配觸發(fā)，制定相關(guān)工作流各階段的測試方案，并由專家進(jìn)行測試方案評審，評審?fù)ㄟ^后，由測試員進(jìn)行測試執(zhí)行。若測試結(jié)果無錯(cuò)誤，則執(zhí)行相關(guān)的測試評估與度量，填寫相關(guān)文檔，相關(guān)測試用例關(guān)閉；若測試有錯(cuò)誤則產(chǎn)生相關(guān)缺陷。

（3）缺陷審核。產(chǎn)生的缺陷如果經(jīng)審核是一個(gè)待修正缺陷，則作為修正的任務(wù)分配對象。

（4）缺陷修正。任務(wù)分配觸發(fā)缺陷修正工作流引擎，由軟件設(shè)計(jì)人員進(jìn)行修正執(zhí)行，修正確認(rèn)完成后進(jìn)入回歸測試。待回歸測試的缺陷又成為任務(wù)分配的新對象。

（5）迭代測試。回歸測試再次觸發(fā)工作流引擎，回到（2）迭代執(zhí)行，如此往復(fù)直至無缺陷并關(guān)閉。

5.3 測試任務(wù)分配

依照計(jì)劃、執(zhí)行、檢查、調(diào)整的原則進(jìn)行測試任務(wù)的分配，要求在執(zhí)行任何測試前必須有相應(yīng)的測試計(jì)劃和測試用例，明確測試活動(dòng)以及測試評估所需要的時(shí)間和資源，然后進(jìn)行測試人員安排和測試任務(wù)分配等[5]。如圖4所示。

當(dāng)測試任務(wù)發(fā)起人發(fā)起一項(xiàng)測試任務(wù)后，將該任務(wù)將傳遞給測試任務(wù)承接人，由承接人進(jìn)行任務(wù)處理。承接人完成任務(wù)處理后，交還給測試任務(wù)發(fā)起人確認(rèn)，如果測試任務(wù)確實(shí)已完成，由測試任務(wù)發(fā)起人關(guān)閉該測試任務(wù)。如圖5所示。

5.4 測試用例缺陷狀態(tài)變遷

把測試用例分靜態(tài)和動(dòng)態(tài)兩種狀態(tài)，這樣可以支持多輪測試。當(dāng)一個(gè)測試用例經(jīng)過任務(wù)分配后，測試用例狀態(tài)則由靜態(tài)轉(zhuǎn)為動(dòng)態(tài)，在該模型中，只有動(dòng)態(tài)測試用例才參與真正的測試。動(dòng)態(tài)測試用例主要包括測試用例的狀態(tài)信息、測試報(bào)告內(nèi)容、測試結(jié)果確認(rèn)等信息，可用NO Run（尚處在設(shè)計(jì)階段或尚未被執(zhí)行）、Passed（已成功）、Failed（已失敗）、 Blocked（設(shè)計(jì)出問題）四個(gè)狀態(tài)來跟蹤測試用例的執(zhí)行情況，而靜態(tài)測試用例只包括測試邏輯和測試數(shù)據(jù)。

軟件缺陷的產(chǎn)生可能發(fā)生在軟件生命周期的每個(gè)階段，而且這種軟件缺陷可能是由上一個(gè)階段的工作失誤造成，所以，對軟件缺陷實(shí)行跟蹤管理在整個(gè)軟件開發(fā)過程中都是非常必要的。在理想狀態(tài)下，能夠根據(jù)測試人員的預(yù)定要求，在測試之前對軟件缺陷的狀態(tài)以及缺陷狀態(tài)之間的流換路徑進(jìn)行設(shè)置[6]。

缺陷狀態(tài)周期分成可分為六個(gè)態(tài)，分別是open態(tài)、working態(tài)、verify態(tài)、cancel態(tài)、defer態(tài)和close態(tài)。其中open態(tài)標(biāo)識新出現(xiàn)的缺陷或沒被修改的缺陷；working態(tài)標(biāo)識軟件開發(fā)人員正在修改和糾正的缺陷；verify態(tài)標(biāo)識軟件設(shè)計(jì)人員已修改完缺陷，并請求結(jié)果驗(yàn)證；close態(tài)標(biāo)識缺陷已被修正，否則將其狀態(tài)重置為open態(tài)；cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報(bào)的一個(gè)存在的缺陷；defer態(tài)說明，如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價(jià)過高，如果該缺陷的優(yōu)先級不高，則缺陷修正可以推遲。如圖6所示。

6 結(jié)論（Conclusion）

基于工作流的CMM軟件測試H模型將測試過程從開發(fā)過程中適當(dāng)?shù)某橄蟪鰜?，作為一個(gè)獨(dú)立的過程進(jìn)行管理，在CMM規(guī)則框架下較好地體現(xiàn)了盡早、全面、全過程、迭代測試等敏捷測試思想。該模型能很好地解決CMM測試管理環(huán)境中的測試流程定義、解釋執(zhí)行和監(jiān)控等相關(guān)問題，使整個(gè)測試過程更加清晰，節(jié)約了開發(fā)時(shí)間，使測試活動(dòng)更加合理，有效保證整個(gè)軟件產(chǎn)品的質(zhì)量，對中小型軟件開發(fā)的測試有著很好的適用性。

參考文獻(xiàn)（References）

[1] 俞磊，等.基于CMM-3的軟件測試過程模型的研究[J].計(jì)算機(jī)與數(shù)字工程，2011（7）：79-82.

[2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實(shí)現(xiàn)[D].西安：西安理工大學(xué)，2007.

[3] 趙瑞東，等.工作流與工作流管理技術(shù)綜述[J].科技信息，2007（8）：105-107.

[4] 張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導(dǎo)刊，2013（2）：24-26.

[5] 鄭小軍，等.基于工作流技術(shù)的軟件測試流程定義與監(jiān)控[J].計(jì)算機(jī)應(yīng)用研究，2007（2）：43-45.

[6] 吳慧韞.基于工作流的軟件測試管理系統(tǒng)研究與設(shè)計(jì)[D].南昌：南昌大學(xué)，2005.

作者簡介：

徐 東（1972-），男，碩士，講師.研究領(lǐng)域：計(jì)算機(jī)視覺與人工智能、計(jì)算機(jī)教育.endprint

CMM在提高軟件開發(fā)質(zhì)量方面的作用已經(jīng)得到廣泛認(rèn)可，但CMM只是對項(xiàng)目開發(fā)提出了要求，至于具體實(shí)施過程，還需要更加行之有效的實(shí)施方法、技術(shù)和工具的支持，為使開發(fā)業(yè)務(wù)過程的部分或全部實(shí)現(xiàn)自動(dòng)執(zhí)行，引入工作流技術(shù)。

5.1 工作流元模型[3]

工作流管理聯(lián)盟定義的過程元模型PDM（Process Definition Meta-mode）的結(jié)構(gòu)， 定義工作流語義模型的構(gòu)造和規(guī)則，描述工作流模型內(nèi)部包含的各個(gè)對象以及對象之間的關(guān)系和屬性，如圖2所示。

5.2 CMM軟件測試H模型

在CMM開發(fā)模式下，結(jié)合可行性和易用性，以H模型為基礎(chǔ)，結(jié)合工作流技術(shù)，針對CMM中小軟件開發(fā)的實(shí)際工作情況，在原有研究基礎(chǔ)上建立軟件測試管理應(yīng)用模型[4]，如圖3所示。

這個(gè)模型中，軟件開發(fā)與測試并發(fā)執(zhí)行，構(gòu)成H模型結(jié)構(gòu)，核心部件為工作流引擎，它負(fù)責(zé)執(zhí)行任務(wù)分配，該模型強(qiáng)調(diào)盡早測試等敏捷軟件測試原則，其測試基本流程為：

（1）測試用例。由測試及設(shè)計(jì)人員共同建立合格的測試用例庫，作為測試任務(wù)分配的對象。

（2）工作流引擎。測試工作流引擎由任務(wù)分配觸發(fā)，制定相關(guān)工作流各階段的測試方案，并由專家進(jìn)行測試方案評審，評審?fù)ㄟ^后，由測試員進(jìn)行測試執(zhí)行。若測試結(jié)果無錯(cuò)誤，則執(zhí)行相關(guān)的測試評估與度量，填寫相關(guān)文檔，相關(guān)測試用例關(guān)閉；若測試有錯(cuò)誤則產(chǎn)生相關(guān)缺陷。

（3）缺陷審核。產(chǎn)生的缺陷如果經(jīng)審核是一個(gè)待修正缺陷，則作為修正的任務(wù)分配對象。

（4）缺陷修正。任務(wù)分配觸發(fā)缺陷修正工作流引擎，由軟件設(shè)計(jì)人員進(jìn)行修正執(zhí)行，修正確認(rèn)完成后進(jìn)入回歸測試。待回歸測試的缺陷又成為任務(wù)分配的新對象。

（5）迭代測試?；貧w測試再次觸發(fā)工作流引擎，回到（2）迭代執(zhí)行，如此往復(fù)直至無缺陷并關(guān)閉。

5.3 測試任務(wù)分配

依照計(jì)劃、執(zhí)行、檢查、調(diào)整的原則進(jìn)行測試任務(wù)的分配，要求在執(zhí)行任何測試前必須有相應(yīng)的測試計(jì)劃和測試用例，明確測試活動(dòng)以及測試評估所需要的時(shí)間和資源，然后進(jìn)行測試人員安排和測試任務(wù)分配等[5]。如圖4所示。

當(dāng)測試任務(wù)發(fā)起人發(fā)起一項(xiàng)測試任務(wù)后，將該任務(wù)將傳遞給測試任務(wù)承接人，由承接人進(jìn)行任務(wù)處理。承接人完成任務(wù)處理后，交還給測試任務(wù)發(fā)起人確認(rèn)，如果測試任務(wù)確實(shí)已完成，由測試任務(wù)發(fā)起人關(guān)閉該測試任務(wù)。如圖5所示。

5.4 測試用例缺陷狀態(tài)變遷

把測試用例分靜態(tài)和動(dòng)態(tài)兩種狀態(tài)，這樣可以支持多輪測試。當(dāng)一個(gè)測試用例經(jīng)過任務(wù)分配后，測試用例狀態(tài)則由靜態(tài)轉(zhuǎn)為動(dòng)態(tài)，在該模型中，只有動(dòng)態(tài)測試用例才參與真正的測試。動(dòng)態(tài)測試用例主要包括測試用例的狀態(tài)信息、測試報(bào)告內(nèi)容、測試結(jié)果確認(rèn)等信息，可用NO Run（尚處在設(shè)計(jì)階段或尚未被執(zhí)行）、Passed（已成功）、Failed（已失?。?、 Blocked（設(shè)計(jì)出問題）四個(gè)狀態(tài)來跟蹤測試用例的執(zhí)行情況，而靜態(tài)測試用例只包括測試邏輯和測試數(shù)據(jù)。

軟件缺陷的產(chǎn)生可能發(fā)生在軟件生命周期的每個(gè)階段，而且這種軟件缺陷可能是由上一個(gè)階段的工作失誤造成，所以，對軟件缺陷實(shí)行跟蹤管理在整個(gè)軟件開發(fā)過程中都是非常必要的。在理想狀態(tài)下，能夠根據(jù)測試人員的預(yù)定要求，在測試之前對軟件缺陷的狀態(tài)以及缺陷狀態(tài)之間的流換路徑進(jìn)行設(shè)置[6]。

缺陷狀態(tài)周期分成可分為六個(gè)態(tài)，分別是open態(tài)、working態(tài)、verify態(tài)、cancel態(tài)、defer態(tài)和close態(tài)。其中open態(tài)標(biāo)識新出現(xiàn)的缺陷或沒被修改的缺陷；working態(tài)標(biāo)識軟件開發(fā)人員正在修改和糾正的缺陷；verify態(tài)標(biāo)識軟件設(shè)計(jì)人員已修改完缺陷，并請求結(jié)果驗(yàn)證；close態(tài)標(biāo)識缺陷已被修正，否則將其狀態(tài)重置為open態(tài)；cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報(bào)的一個(gè)存在的缺陷；defer態(tài)說明，如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價(jià)過高，如果該缺陷的優(yōu)先級不高，則缺陷修正可以推遲。如圖6所示。

6 結(jié)論（Conclusion）

基于工作流的CMM軟件測試H模型將測試過程從開發(fā)過程中適當(dāng)?shù)某橄蟪鰜?，作為一個(gè)獨(dú)立的過程進(jìn)行管理，在CMM規(guī)則框架下較好地體現(xiàn)了盡早、全面、全過程、迭代測試等敏捷測試思想。該模型能很好地解決CMM測試管理環(huán)境中的測試流程定義、解釋執(zhí)行和監(jiān)控等相關(guān)問題，使整個(gè)測試過程更加清晰，節(jié)約了開發(fā)時(shí)間，使測試活動(dòng)更加合理，有效保證整個(gè)軟件產(chǎn)品的質(zhì)量，對中小型軟件開發(fā)的測試有著很好的適用性。

參考文獻(xiàn)（References）

[1] 俞磊，等.基于CMM-3的軟件測試過程模型的研究[J].計(jì)算機(jī)與數(shù)字工程，2011（7）：79-82.

[2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實(shí)現(xiàn)[D].西安：西安理工大學(xué)，2007.

[3] 趙瑞東，等.工作流與工作流管理技術(shù)綜述[J].科技信息，2007（8）：105-107.

[4] 張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導(dǎo)刊，2013（2）：24-26.

[5] 鄭小軍，等.基于工作流技術(shù)的軟件測試流程定義與監(jiān)控[J].計(jì)算機(jī)應(yīng)用研究，2007（2）：43-45.

[6] 吳慧韞.基于工作流的軟件測試管理系統(tǒng)研究與設(shè)計(jì)[D].南昌：南昌大學(xué)，2005.

作者簡介：

徐 東（1972-），男，碩士，講師.研究領(lǐng)域：計(jì)算機(jī)視覺與人工智能、計(jì)算機(jī)教育.endprint