• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

      CMM軟件測試H模型研究

      2014-09-24 20:02:26徐東張曉雯楊健劉海見
      軟件工程 2014年4期
      關(guān)鍵詞:工作流軟件測試

      徐東 張曉雯 楊健 劉海見

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

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

      中圖分類號: TP311.52 文獻標(biāo)識碼:A

      1 引言(Introduction)

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

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

      2 CMM概述(CMM summarize)

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

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

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

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

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

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

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

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

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

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

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

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

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

      5.1 工作流元模型[3]

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

      5.2 CMM軟件測試H模型

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

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

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

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

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

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

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

      5.3 測試任務(wù)分配

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

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

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

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

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

      缺陷狀態(tài)周期分成可分為六個態(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è)計人員已修改完缺陷,并請求結(jié)果驗證;close態(tài)標(biāo)識缺陷已被修正,否則將其狀態(tài)重置為open態(tài);cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報的一個存在的缺陷;defer態(tài)說明,如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價過高,如果該缺陷的優(yōu)先級不高,則缺陷修正可以推遲。如圖6所示。

      6 結(jié)論(Conclusion)

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

      參考文獻(References)

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

      [2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實現(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].計算機應(yīng)用研究,2007(2):43-45.

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

      作者簡介:

      徐 東(1972-),男,碩士,講師.研究領(lǐng)域:計算機視覺與人工智能、計算機教育.endprint

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

      5.1 工作流元模型[3]

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

      5.2 CMM軟件測試H模型

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

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

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

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

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

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

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

      5.3 測試任務(wù)分配

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

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

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

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

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

      缺陷狀態(tài)周期分成可分為六個態(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è)計人員已修改完缺陷,并請求結(jié)果驗證;close態(tài)標(biāo)識缺陷已被修正,否則將其狀態(tài)重置為open態(tài);cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報的一個存在的缺陷;defer態(tài)說明,如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價過高,如果該缺陷的優(yōu)先級不高,則缺陷修正可以推遲。如圖6所示。

      6 結(jié)論(Conclusion)

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

      參考文獻(References)

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

      [2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實現(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].計算機應(yīng)用研究,2007(2):43-45.

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

      作者簡介:

      徐 東(1972-),男,碩士,講師.研究領(lǐng)域:計算機視覺與人工智能、計算機教育.endprint

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

      5.1 工作流元模型[3]

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

      5.2 CMM軟件測試H模型

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

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

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

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

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

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

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

      5.3 測試任務(wù)分配

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

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

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

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

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

      缺陷狀態(tài)周期分成可分為六個態(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è)計人員已修改完缺陷,并請求結(jié)果驗證;close態(tài)標(biāo)識缺陷已被修正,否則將其狀態(tài)重置為open態(tài);cancel態(tài)標(biāo)識的是由測試人員發(fā)現(xiàn)并填報的一個存在的缺陷;defer態(tài)說明,如果該缺陷在當(dāng)前條件下修正則系統(tǒng)代價過高,如果該缺陷的優(yōu)先級不高,則缺陷修正可以推遲。如圖6所示。

      6 結(jié)論(Conclusion)

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

      參考文獻(References)

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

      [2] 鄭曉霞.基于CMM的工作流管理系統(tǒng)的研究與實現(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].計算機應(yīng)用研究,2007(2):43-45.

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

      作者簡介:

      徐 東(1972-),男,碩士,講師.研究領(lǐng)域:計算機視覺與人工智能、計算機教育.endprint

      猜你喜歡
      工作流軟件測試
      基于OBE的軟件測試課程教學(xué)改革探索
      計算機教育(2020年5期)2020-07-24 08:53:20
      航天軟件測試模型構(gòu)建與應(yīng)用
      軟件(2020年3期)2020-04-20 01:45:34
      EXCEL和VBA實現(xiàn)軟件測試記錄管理
      電子制作(2018年16期)2018-09-26 03:27:18
      關(guān)于軟件測試技術(shù)應(yīng)用與發(fā)展趨勢研究
      電子測試(2017年15期)2017-12-18 07:19:20
      基于工作流2.0的智慧教室設(shè)計與研究
      工作流在電力生產(chǎn)管理信息系統(tǒng)中的設(shè)計和應(yīng)用
      “奔向共贏、做到最好”行業(yè)信息化研究方法論
      價值工程(2016年32期)2016-12-20 15:51:16
      個性化計算機輔助教學(xué)系統(tǒng)的設(shè)計與實現(xiàn)
      商情(2016年39期)2016-11-21 09:57:19
      工作流技術(shù)在醫(yī)療信息整合工程中的應(yīng)用分析
      基于工作流的水運應(yīng)急信息管理平臺設(shè)計 
      常熟市| 玉环县| 大埔县| 万州区| 乐都县| 宁晋县| 太仆寺旗| 类乌齐县| 驻马店市| 内丘县| 扶绥县| 包头市| 平阳县| 海阳市| 西昌市| 新昌县| 安乡县| 吉隆县| 库尔勒市| 三河市| 北流市| 洛浦县| 互助| 普陀区| 公安县| 云安县| 临沧市| 榕江县| 嘉祥县| 威海市| 湖北省| 黔西县| 广元市| 吴川市| 邹城市| 靖西县| 古丈县| 当阳市| 常德市| 垣曲县| 双江|