基于GJB5000A的項(xiàng)目全生命周期軟件測(cè)試實(shí)踐與分析*

王詩(shī)琹,李 彬,盧 葉

（中國(guó)電子科技集團(tuán)公司第三十研究所，四川 成都 610041）

基于GJB5000A的項(xiàng)目全生命周期軟件測(cè)試實(shí)踐與分析*

王詩(shī)琹,李 彬,盧 葉

（中國(guó)電子科技集團(tuán)公司第三十研究所，四川 成都 610041）

軟件測(cè)試作為檢驗(yàn)軟件產(chǎn)品質(zhì)量最有效的方法，已成為軟件工程領(lǐng)域中一個(gè)非常重要的研究熱點(diǎn)?；贕JB5000A三級(jí)實(shí)施標(biāo)準(zhǔn)，分析軟件開(kāi)發(fā)和測(cè)試的關(guān)系，介紹項(xiàng)目全生命周期的軟件測(cè)試步驟，提出滿足GJB5000A三級(jí)標(biāo)準(zhǔn)的軟件測(cè)試方法，旨在將測(cè)試工作與項(xiàng)目開(kāi)發(fā)過(guò)程緊密結(jié)合，開(kāi)發(fā)與測(cè)試工作交替進(jìn)行，并貫穿于項(xiàng)目開(kāi)發(fā)的全過(guò)程，為準(zhǔn)備或正在實(shí)施GJB5000A三級(jí)的項(xiàng)目提供滿足軍用標(biāo)準(zhǔn)的測(cè)試指南。

軟件測(cè)試；生命周期；質(zhì)量；軟件工程

0 引 言

隨著國(guó)防科學(xué)技術(shù)快速發(fā)展和高新武器裝備跨越發(fā)展，裝備的復(fù)雜程度日益增高。武器裝備的功能結(jié)構(gòu)和系統(tǒng)集成越來(lái)越復(fù)雜，技術(shù)難度越來(lái)越大，質(zhì)量特性內(nèi)涵越來(lái)越豐富。自2010年11月1日起，由國(guó)務(wù)院﹑中央軍委頒布施行最新的《武器裝備質(zhì)量管理?xiàng)l例》（第582號(hào)），對(duì)裝備質(zhì)量和管理工作提出了更高的要求。因此，需要運(yùn)用更科學(xué)的質(zhì)量管理方法和更先進(jìn)的質(zhì)量管理手段，提高武器裝備質(zhì)量水平。

然而，產(chǎn)品的質(zhì)量是“設(shè)計(jì)”出來(lái)的。各軍工裝備承制單位主要依據(jù)軍用軟件研制能力成熟度模 型（Capability Maturity Model for Military Software Development-GJB5000A）來(lái)控制和加強(qiáng)軟件產(chǎn)品質(zhì)量。軟件測(cè)試作為保證產(chǎn)品質(zhì)量的主要手段，在軟件工程化實(shí)施過(guò)程中尤為重要。

軟件測(cè)試涉及到項(xiàng)目研制生產(chǎn)的各個(gè)階段。項(xiàng)目成員由于分工不同，對(duì)測(cè)試的側(cè)重點(diǎn)有所不同。開(kāi)發(fā)人員需重點(diǎn)掌握需求分析階段﹑軟件設(shè)計(jì)階段﹑軟件實(shí)現(xiàn)階段的測(cè)試方法；測(cè)試人員需重點(diǎn)掌握單元測(cè)試階段﹑組裝測(cè)試階段的測(cè)試方法；售后服務(wù)人員需重點(diǎn)掌握系統(tǒng)集成階段﹑用戶試用階段﹑售后維護(hù)階段的測(cè)試方法。本文將打破傳統(tǒng)的單線測(cè)試技術(shù)和方法，基于GJB5000A中對(duì)測(cè)試的相關(guān)要求及規(guī)定，結(jié)合項(xiàng)目全生命周期模型，對(duì)軟件測(cè)試進(jìn)行全面分析。

1 軟件測(cè)試與開(kāi)發(fā)過(guò)程的關(guān)系

傳統(tǒng)的軟件測(cè)試，可以簡(jiǎn)單描述為如圖1所示。開(kāi)發(fā)人員完成任務(wù)后，交付給測(cè)試人員。這種模式下，測(cè)試人員不能及早發(fā)現(xiàn)需求階段的缺陷，且測(cè)試工作的開(kāi)展也已滯后，無(wú)法實(shí)現(xiàn)對(duì)產(chǎn)品質(zhì)量有效的過(guò)程控制和分析，總體進(jìn)度也可能會(huì)由于返工問(wèn)題而拖延。

圖1 傳統(tǒng)交付測(cè)試

全生命周期軟件測(cè)試與開(kāi)發(fā)活動(dòng)的關(guān)系，如圖2所示。

圖2 全生命周期軟件測(cè)試流程

如圖2所示，整個(gè)軟件生命周期（SDLC）可分為三條角色主線和四個(gè)階段。三條角色主線分別為開(kāi)發(fā)﹑QA﹑測(cè)試（文中主要講解測(cè)試）；四個(gè)階段分別為需求階段﹑開(kāi)發(fā)階段﹑發(fā)布階段﹑日常運(yùn)營(yíng)。

對(duì)于產(chǎn)品而言，每次版本迭代都會(huì)經(jīng)歷需求﹑開(kāi)發(fā)﹑發(fā)布三個(gè)階段，最后推向日常運(yùn)營(yíng)。此外，發(fā)布階段并不表示終止。如果發(fā)布階段產(chǎn)生設(shè)計(jì)變更需求，則將回到需求階段和開(kāi)發(fā)階段，完成更改后，再重新發(fā)布。這是一個(gè)不斷迭代的過(guò)程。

測(cè)試人員貫穿于這四個(gè)階段（每個(gè)階段也有開(kāi)發(fā)人員﹑QA人員對(duì)應(yīng)的活動(dòng)），主要開(kāi)展的測(cè)試工作歸納如下。

（1）需求階段

在確定軟件開(kāi)發(fā)可行的情況下，設(shè)計(jì)開(kāi)發(fā)人員將詳細(xì)分析軟件需要實(shí)現(xiàn)的各個(gè)功能。需求階段至關(guān)重要，將為整個(gè)軟件開(kāi)發(fā)項(xiàng)目的成功打下基礎(chǔ)。同樣，需求也是在整個(gè)軟件開(kāi)發(fā)過(guò)程中不斷變化和深入的。因此，必須制定需求變更計(jì)劃來(lái)應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。此階段，測(cè)試人員需參與需求分析，挖掘用戶描述得較含混的內(nèi)容，參考經(jīng)驗(yàn)庫(kù)，對(duì)估算的開(kāi)發(fā)時(shí)間提出質(zhì)疑，而描述也會(huì)隨著需求的變更變化。

（2）開(kāi)發(fā)階段

此階段主要根據(jù)需求分析的結(jié)果，對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì)，并將設(shè)計(jì)結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在軟件設(shè)計(jì)完成后，測(cè)試人員需進(jìn)行嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過(guò)程中存在的問(wèn)題并加以糾正。整個(gè)測(cè)試過(guò)程分單元測(cè)試﹑組裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。此階段，測(cè)試人員需提出詳細(xì)的測(cè)試計(jì)劃，并嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試，以減少測(cè)試的隨意性；需進(jìn)行功能要點(diǎn)確認(rèn)，判斷是否滿足需求階段提出的指標(biāo)；設(shè)計(jì)測(cè)試用例，并對(duì)用例進(jìn)行評(píng)審；組織測(cè)試探索，發(fā)布燃盡圖；總結(jié)開(kāi)發(fā)缺陷，提出解決方案，并向缺陷經(jīng)驗(yàn)庫(kù)作出貢獻(xiàn)；通過(guò)不斷積累，提升開(kāi)發(fā)自測(cè)質(zhì)量；參與集成測(cè)試階段的測(cè)試，持續(xù)反饋問(wèn)題。

（3）發(fā)布階段及日常運(yùn)營(yíng)

這兩個(gè)階段都屬于用戶使用階段，是軟件生命周期中變化不大但持續(xù)時(shí)間最長(zhǎng)的兩個(gè)階段。在軟件開(kāi)發(fā)完成并投入使用后，由于用戶試用后產(chǎn)生的問(wèn)題反饋﹑實(shí)際使用環(huán)境變化等因素，需要對(duì)軟件進(jìn)行持續(xù)維護(hù)和修改。此時(shí)，售后服務(wù)人員將與測(cè)試人員配合。售后人員收集用戶反饋的問(wèn)題和提出的改進(jìn)建議，測(cè)試人員據(jù)此編制測(cè)試報(bào)告﹑缺陷分析統(tǒng)計(jì)報(bào)告﹑版本問(wèn)題反饋報(bào)告，并向開(kāi)發(fā)人員提出改進(jìn)建議。開(kāi)發(fā)人員完成設(shè)計(jì)更改后，測(cè)試人員進(jìn)行回歸測(cè)試和確認(rèn)，最后再次進(jìn)行發(fā)布并投入運(yùn)行。

2 全生命周期軟件測(cè)試活動(dòng)

2.1 需求階段測(cè)試

在需求階段，開(kāi)發(fā)人員進(jìn)行用戶故事分析和評(píng)估時(shí)，QA人員保證并確認(rèn)需求活動(dòng)符合管理過(guò)程，管理用戶故事評(píng)審和需求變更。測(cè)試人員的主要實(shí)踐包括：參與用戶故事分析，挖掘故事含混性。

在sprint會(huì)議上，對(duì)用戶故事進(jìn)行分析，檢查功能性需求和非功能性需求是否描述清晰。其中，可以將非功能性需求作為驗(yàn)收要點(diǎn)，如一個(gè)用戶故事——“客戶希望提高響應(yīng)時(shí)間”。測(cè)試人員應(yīng)當(dāng)協(xié)助開(kāi)發(fā)人員消除故事的含混性“提高什么的響應(yīng)時(shí)間和響應(yīng)時(shí)間為多少”。因此，可以建議修改為“客戶信息普通查詢返回結(jié)果的響應(yīng)時(shí)間為5 s內(nèi)”，說(shuō)明在“客戶信息”模塊進(jìn)行“普通查詢”操作，返回結(jié)果的時(shí)間在5 s內(nèi)。這個(gè)陳述句已經(jīng)清晰表達(dá)，也達(dá)到消除含混性的效果。同樣，測(cè)試人員可以編寫(xiě)提高查詢效率的用戶故事“客戶在信息查詢模塊進(jìn)行普通查詢，能夠在5 s內(nèi)返回結(jié)果”“備注：5 s為非功能性需求，也是驗(yàn)收要點(diǎn)”。

sprint會(huì)議上，開(kāi)發(fā)人員根據(jù)經(jīng)驗(yàn)出牌（團(tuán)隊(duì)自己定義的規(guī)則，用撲克牌）估算時(shí)間，當(dāng)給出最終結(jié)果的時(shí)候，測(cè)試人員應(yīng)當(dāng)對(duì)其進(jìn)行質(zhì)疑。測(cè)試人員借鑒歷史經(jīng)驗(yàn)庫(kù)，分析開(kāi)發(fā)人員在某方面的技能如何﹑該模塊曾經(jīng)產(chǎn)生過(guò)何種程度的缺陷﹑修復(fù)缺陷的消耗時(shí)間是多少等，綜合考慮，提出疑問(wèn)，使開(kāi)發(fā)估算最終的時(shí)間盡可能考慮這些因素。當(dāng)然，測(cè)試人員能夠質(zhì)疑的一個(gè)前提，是測(cè)試人員具備相關(guān)開(kāi)發(fā)經(jīng)驗(yàn)。

可見(jiàn)，在需求階段，測(cè)試人員要發(fā)揮作用，減少含混性需求引入到開(kāi)發(fā)階段，同時(shí)要協(xié)助開(kāi)發(fā)人員做好時(shí)間估算。

2.2 開(kāi)發(fā)階段測(cè)試

在開(kāi)發(fā)階段，開(kāi)發(fā)人員進(jìn)行架構(gòu)評(píng)審，功能要點(diǎn)確認(rèn)，編碼開(kāi)發(fā)，單元測(cè)試，開(kāi)發(fā)自測(cè)，代碼評(píng)審，Bug Fix；QA人員管理評(píng)審活動(dòng)和文檔產(chǎn)物。測(cè)試人員的主要實(shí)踐如下。

2.2.1 功能要點(diǎn)確認(rèn)

Xmind是一個(gè)非常好用的腦圖工具，通常在開(kāi)發(fā)人員進(jìn)行編碼前，測(cè)試人員會(huì)針對(duì)需求處理的用戶故事，與開(kāi)發(fā)人員進(jìn)行確認(rèn)，修正理解偏差，確保需求理解一致。例如，如圖3所示，圖中的某軟件模塊腦圖用例提出，測(cè)試人員與開(kāi)發(fā)人員需共同對(duì)測(cè)試要點(diǎn)﹑測(cè)試用例﹑測(cè)試目標(biāo)﹑風(fēng)險(xiǎn)進(jìn)行性評(píng)估，給出最終的功能要點(diǎn)，并將其作為編碼依據(jù)，為下一步設(shè)計(jì)工作做好準(zhǔn)備。

圖3 腦圖用例模板

2.2.2 測(cè)試用例設(shè)計(jì)

測(cè)試人員需根據(jù)設(shè)計(jì)方案提出用例ID﹑用例名稱﹑測(cè)試目的﹑測(cè)試級(jí)別﹑測(cè)試環(huán)境﹑前提條件﹑測(cè)試步驟﹑預(yù)期結(jié)果﹑設(shè)計(jì)人員名單。在設(shè)計(jì)測(cè)試故事點(diǎn)時(shí)，可使用DSL（Domain Specific Language）﹑infoq文章（敏捷測(cè)試之借力DSL），對(duì)測(cè)試用例進(jìn)行描述。這主要包括三個(gè)基本要素（Feature﹑Scenario﹑Example）和兩個(gè)補(bǔ)充要素（xmind﹑Requirement）。

Feature：把測(cè)試分類到某個(gè)模塊，并對(duì)這個(gè)特性本身的業(yè)務(wù)目的進(jìn)行相關(guān)描述，引入業(yè)務(wù)目標(biāo)，傳遞業(yè)務(wù)知識(shí)。

Scenario：標(biāo)明這個(gè)Feature的測(cè)試場(chǎng)景，可以使用文字描述步驟，或者使用xmind腦圖。

Example：引出具體的數(shù)據(jù)表格，把用到的數(shù)據(jù)展示出來(lái)，避免相同步驟導(dǎo)致測(cè)試數(shù)據(jù)的變化而重復(fù)若干遍工作，造成冗余。

Xmind：腦圖文件，展示測(cè)試故事點(diǎn)。

Requirement：關(guān)聯(lián)需求管理系統(tǒng)中提出的需求id。

2.2.3 用例評(píng)審

用例評(píng)審需堅(jiān)持同行評(píng)審的原則，主要在測(cè)試組內(nèi)進(jìn)行，負(fù)責(zé)該任務(wù)的開(kāi)發(fā)人員也會(huì)參與。簡(jiǎn)單來(lái)說(shuō)，就是對(duì)測(cè)試用例進(jìn)行查漏補(bǔ)缺的工作。

2.2.4 測(cè)試探索

測(cè)試人員在進(jìn)行“功能要點(diǎn)確認(rèn)”和“用例評(píng)審”后，為保證測(cè)試場(chǎng)景的覆蓋率，需要再進(jìn)行測(cè)試探索。在開(kāi)發(fā)人員完成雛形后，使用探索式測(cè)試的策略，對(duì)功能基本流程進(jìn)行有目的的快速走查，挖掘功能不確定的地方和補(bǔ)充測(cè)試場(chǎng)景，避免不確定的因素拖延到開(kāi)發(fā)階段后期，造成返工。其中，功能測(cè)試﹑Bug Tracking﹑回歸測(cè)試﹑系統(tǒng)測(cè)試﹑驗(yàn)收測(cè)試都是日常測(cè)試工作的所需環(huán)節(jié)。

2.2.5 燃盡圖發(fā)布

測(cè)試人員還有一項(xiàng)重要工作，就是每日發(fā)布燃盡圖，讓團(tuán)隊(duì)了解當(dāng)前進(jìn)度情況，總結(jié)問(wèn)題所在，尋求耗時(shí)超過(guò)預(yù)期時(shí)間任務(wù)的解決辦法。圖6為測(cè)試人員記錄的某界面軟件模塊開(kāi)發(fā)任務(wù)進(jìn)度燃盡圖。縱軸表示總工時(shí)數(shù)，橫軸表示計(jì)劃天數(shù)，虛線表示計(jì)劃完成的基準(zhǔn)，實(shí)線表示實(shí)際剩余工時(shí)。

由圖4可知，某界面軟件模塊開(kāi)發(fā)任務(wù)進(jìn)度燃盡圖的圖形特點(diǎn)。

圖4 某界面軟件模塊開(kāi)發(fā)任務(wù)進(jìn)度燃盡圖

第一，剩余工時(shí)在計(jì)劃基準(zhǔn)上方，代表進(jìn)度有所延遲，應(yīng)抓緊進(jìn)度。發(fā)現(xiàn)此類問(wèn)題，需要分析總結(jié)，原則是保證交付時(shí)間，對(duì)相應(yīng)任務(wù)進(jìn)行調(diào)整，發(fā)現(xiàn)任務(wù)粒度太大，該拆分的繼續(xù)拆分；對(duì)于重構(gòu)需要慎重，不要過(guò)度深入重構(gòu)，給測(cè)試帶來(lái)額外工作量，影響整個(gè)進(jìn)度。對(duì)于整個(gè)版本而言，只有開(kāi)發(fā)﹑測(cè)試在承諾的時(shí)間內(nèi)完成任務(wù)，才是真正完成，而僅僅開(kāi)發(fā)完成交付算不上成功。

第二，剩余工時(shí)與計(jì)劃基準(zhǔn)接近，代表進(jìn)展良好，繼續(xù)保持。此時(shí)也需要查看在這種進(jìn)度下，優(yōu)先級(jí)高的任務(wù)是否得到時(shí)間保證，而不是因?yàn)樘幚硗旰?jiǎn)單任務(wù)使燃盡圖長(zhǎng)得好看。實(shí)際中，往往有開(kāi)發(fā)人員喜歡挑任務(wù)，把簡(jiǎn)單易做﹑優(yōu)先級(jí)高的任務(wù)先完成。因?yàn)檫@些總在預(yù)期內(nèi)能夠完成，所以前期燃盡圖的趨勢(shì)看起來(lái)沒(méi)有問(wèn)題。因此，要點(diǎn)使跟蹤和控制開(kāi)發(fā)中后期的進(jìn)度。

2.2.6 缺陷經(jīng)驗(yàn)庫(kù)

每個(gè)團(tuán)隊(duì)都存在開(kāi)發(fā)/測(cè)試新人和開(kāi)發(fā)/測(cè)試?yán)先?。?dāng)測(cè)試人員與開(kāi)發(fā)新人進(jìn)行需求確認(rèn)時(shí)，還需要進(jìn)行缺陷經(jīng)驗(yàn)教訓(xùn)的提醒，兩者共同編寫(xiě)缺陷總結(jié)報(bào)告，供后續(xù)開(kāi)發(fā)人員借鑒。

例如，圖5為某界面軟件的缺陷總結(jié)報(bào)告。報(bào)告中，對(duì)界面軟件的構(gòu)造﹑時(shí)間控件﹑查詢條件﹑發(fā)送功能﹑接口﹑賬戶名﹑頁(yè)面等功能和性能模塊的缺陷進(jìn)行了分類描述。

圖5 某界面軟件缺陷總結(jié)

2.2.7 提升開(kāi)發(fā)自測(cè)質(zhì)量

測(cè)試人員可在開(kāi)發(fā)過(guò)程中提供相關(guān)檢查單（Checklist），幫助開(kāi)發(fā)人員在編碼過(guò)程中關(guān)注開(kāi)發(fā)自測(cè)的要點(diǎn)，從而提升質(zhì)量。例如，表1為某界面軟件的測(cè)試檢查單，測(cè)試人員對(duì)界面控件﹑下拉框﹑文本輸入﹑按鈕功能﹑界面布局﹑查詢等功能進(jìn)行檢查，并提出改進(jìn)建議。

2.2.8 持續(xù)集成

基于成熟的測(cè)試工具，如持續(xù)集成（Jenkins）平臺(tái)，做到快速構(gòu)建開(kāi)發(fā)代碼，自動(dòng)單元測(cè)試化，來(lái)提高開(kāi)發(fā)代碼的效率和質(zhì)量。Jenkins是目前業(yè)內(nèi)最流行的快速持續(xù)集成工具之一，其穩(wěn)定的性能和豐富的擴(kuò)展性，使很多團(tuán)隊(duì)都優(yōu)先選擇它作為項(xiàng)目的主要支持工具。

此平臺(tái)可靈活定制自動(dòng)化測(cè)試，團(tuán)隊(duì)成員通過(guò)登陸平臺(tái)Web界面，按照需求任意選擇部署在平臺(tái)上的自動(dòng)化測(cè)試包﹑目標(biāo)測(cè)試環(huán)境﹑測(cè)試集和測(cè)試用例，提交定制化的自動(dòng)化執(zhí)行請(qǐng)求。執(zhí)行結(jié)束后，系統(tǒng)自動(dòng)發(fā)郵件給予通知。此外，不同人員的請(qǐng)求可以實(shí)現(xiàn)并行執(zhí)行；所有的自動(dòng)化執(zhí)行歷史記錄都可以保存在平臺(tái)上，可以通過(guò)Web方式隨時(shí)查閱；支持豐富的插件，用戶可以按照需求進(jìn)行選擇安裝和配置，以實(shí)現(xiàn)生成執(zhí)行狀態(tài)表格，自動(dòng)部署/更新自動(dòng)化測(cè)試包等高級(jí)功能。

負(fù)責(zé)單元測(cè)試﹑集成測(cè)試﹑自動(dòng)化測(cè)試（Selenium）的開(kāi)發(fā)人員，都會(huì)收到失敗構(gòu)建的郵件。這種方式可確保單元測(cè)試﹑集成測(cè)試﹑自動(dòng)化測(cè)試的有相關(guān)人員同時(shí)關(guān)注，并共同維護(hù)。

測(cè)試人員主要需反饋的問(wèn)題如下：

①Code coverage：團(tuán)隊(duì)要求代碼覆蓋率在80%以上；

②Test success：團(tuán)隊(duì)要求測(cè)試成功率在100%；

③Duplication：團(tuán)隊(duì)要求代碼重復(fù)率在10%以下；

④Violations：團(tuán)隊(duì)要求Major類別的代碼規(guī)則缺陷在20以下；

⑤開(kāi)發(fā)團(tuán)隊(duì)必須保證每個(gè)環(huán)境的質(zhì)量目標(biāo)，才能夠保證整個(gè)的質(zhì)量目標(biāo)。

可見(jiàn)，測(cè)試人員與開(kāi)發(fā)人員是協(xié)助關(guān)系，類似于質(zhì)量天枰的兩邊，任何一邊的工作沒(méi)有做好，天枰都將失去平衡。

表1 某界面軟件測(cè)試checklist

2.3 發(fā)布階段測(cè)試

在發(fā)布階段，開(kāi)發(fā)人員需完成線上申請(qǐng)﹑線上部署﹑服務(wù)監(jiān)控等工作；QA人員主要負(fù)責(zé)管理評(píng)審活動(dòng)和文檔產(chǎn)物。測(cè)試人員的主要實(shí)踐如下。

2.3.1 測(cè)試報(bào)告

完成驗(yàn)收測(cè)試，提供測(cè)試報(bào)告，給出測(cè)試數(shù)據(jù)度量。

例如：

①測(cè)試發(fā)現(xiàn)缺陷總數(shù)：測(cè)試過(guò)程中產(chǎn)生的去除狀態(tài)為“無(wú)效”“不用改”的缺陷數(shù)目；

②測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)：測(cè)試過(guò)程中產(chǎn)生的并去除狀態(tài)為“無(wú)效”“不用改”的﹑且嚴(yán)重性為“Major”和“Critical”的缺陷總數(shù)目；

③測(cè)試發(fā)現(xiàn)缺陷修復(fù)數(shù)：測(cè)試過(guò)程中產(chǎn)生的狀態(tài)為“已關(guān)閉”的缺陷數(shù)量；

④未解決缺陷數(shù)：去除狀態(tài)為“無(wú)效”“不用改”“關(guān)閉”的缺陷總數(shù)；

⑤缺陷修復(fù)率：（測(cè)試發(fā)現(xiàn)缺陷的修復(fù)數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100%；

⑥嚴(yán)重缺陷率：（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100%；

⑦嚴(yán)重缺陷修復(fù)率：（已修復(fù)的嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）×100%；

⑧測(cè)試需求覆蓋率：已測(cè)試需求個(gè)數(shù)÷需求總數(shù)×100%。

2.3.2 缺陷統(tǒng)計(jì)分析報(bào)告

測(cè)試人員還需對(duì)當(dāng)前版本的缺陷進(jìn)行統(tǒng)計(jì)分析。缺陷種類分為關(guān)鍵缺陷﹑主要缺陷﹑中等缺陷﹑輕微缺陷，并按軟件的功能模塊分別進(jìn)行統(tǒng)計(jì)。表2為測(cè)試人員給某界面軟件提出的缺陷統(tǒng)計(jì)表，按9個(gè)功能模塊進(jìn)行統(tǒng)計(jì)。其中，關(guān)鍵缺陷數(shù)0個(gè)﹑主要缺陷數(shù)5個(gè)﹑中等缺陷數(shù)10個(gè)﹑輕微缺陷數(shù)27個(gè)，并橫向統(tǒng)計(jì)出每個(gè)單一模塊的缺陷總數(shù)。

表2 某界面軟件缺陷統(tǒng)計(jì)表

根據(jù)軟件缺陷統(tǒng)計(jì)表自動(dòng)生成柱狀統(tǒng)計(jì)圖表，如圖6所示，可直觀看出此軟件的缺陷分布情況，即主要集中在輕微缺陷上。

圖6 某界面軟件缺陷柱狀分布

測(cè)試人員需和開(kāi)發(fā)人員共同分析缺陷來(lái)源，并按團(tuán)隊(duì)統(tǒng)計(jì)出關(guān)鍵缺陷﹑主要缺陷﹑中等缺陷﹑輕微缺陷的來(lái)源，如表3所示。

表3 某界面軟件缺陷來(lái)源統(tǒng)計(jì)表

最后，測(cè)試人員將缺陷問(wèn)題反饋給開(kāi)發(fā)人員進(jìn)行修改，并完成回歸測(cè)試，按缺陷狀態(tài)計(jì)算出測(cè)試度量數(shù)據(jù)，如表4所示。結(jié)果顯示，某界面軟件的缺陷總數(shù)為42，回歸測(cè)試后已關(guān)閉缺陷40個(gè)，嚴(yán)重缺陷數(shù)全部關(guān)閉，缺陷修復(fù)率為95%，嚴(yán)重缺陷修復(fù)率為100%。

2.3.3 測(cè)試進(jìn)度和問(wèn)題分析

通過(guò)對(duì)某界面軟件的缺陷統(tǒng)計(jì)表﹑來(lái)源統(tǒng)計(jì)表和缺陷狀態(tài)表的統(tǒng)計(jì)數(shù)據(jù)綜合分析，得出以下結(jié)論：從BUG嚴(yán)重級(jí)別分布來(lái)看，Major級(jí)別以上的BUG 占12%，比重不高，說(shuō)明大部分的主要功能已經(jīng)實(shí)現(xiàn)。其中，在sonar定義級(jí)別的缺陷主要集中在代碼規(guī)范和單元測(cè)試覆蓋率，說(shuō)明代碼質(zhì)量有待提高；版本測(cè)試的前期時(shí)間較充足，后期隨著開(kāi)發(fā)提交完成的功能點(diǎn)增多，BUG數(shù)量增多，剩余測(cè)試時(shí)間變得緊張；在版本測(cè)試期間，發(fā)現(xiàn)測(cè)試環(huán)境存在1次代碼被覆蓋﹑2次因開(kāi)發(fā)人員操作失誤影響測(cè)試執(zhí)行的情況，故需要QA加強(qiáng)配置管理的監(jiān)督工作。

可見(jiàn)，測(cè)試人員應(yīng)當(dāng)持續(xù)反饋﹑改進(jìn)﹑總結(jié)每個(gè)版本發(fā)生的問(wèn)題（不管是缺陷，還是過(guò)程中出現(xiàn)的），并對(duì)缺陷進(jìn)行分析，總結(jié)規(guī)律，幫助開(kāi)發(fā)人員建立良好習(xí)慣，改進(jìn)代碼的質(zhì)量。

2.4 日常運(yùn)營(yíng)階段測(cè)試

日常運(yùn)營(yíng)階段并不表示項(xiàng)目已經(jīng)進(jìn)入終止階段，即使需求﹑開(kāi)發(fā)﹑發(fā)布階段的活動(dòng)已完成，只要還在為用戶提供服務(wù)，項(xiàng)目的日常運(yùn)營(yíng)活動(dòng)就將存在。開(kāi)發(fā)人員需要按事件觸發(fā)時(shí)機(jī)進(jìn)行生產(chǎn)故障登記；QA人員要對(duì)日常運(yùn)營(yíng)活動(dòng)進(jìn)行維護(hù)和管理。

測(cè)試人員的主要實(shí)踐如下。

第一，版本問(wèn)題反饋和改進(jìn)提議。對(duì)日常運(yùn)營(yíng)發(fā)生的問(wèn)題，總結(jié)反饋，提出改進(jìn)建議，并且跟蹤實(shí)施。

表4 某界面軟件缺陷狀態(tài)表

第二，生產(chǎn)故障分析。協(xié)助開(kāi)發(fā)排查生產(chǎn)故障，避免測(cè)試場(chǎng)景的遺漏。

3 結(jié) 語(yǔ)

軟件開(kāi)發(fā)工作，從開(kāi)發(fā)初期的問(wèn)題定義及規(guī)劃，到各個(gè)階段任務(wù)的有效推動(dòng)，需做到層層相扣。而軟件測(cè)試作為軟件開(kāi)發(fā)過(guò)程中的關(guān)鍵環(huán)節(jié)，把握著軟件的質(zhì)量，在項(xiàng)目全生命周期中發(fā)揮著至關(guān)重要的作用。本文提出的全生命周期軟件測(cè)試實(shí)踐，強(qiáng)調(diào)貫穿每個(gè)階段的測(cè)試活動(dòng)，并嚴(yán)格遵循GJB5000A標(biāo)準(zhǔn)要求，為實(shí)施三級(jí)標(biāo)準(zhǔn)的項(xiàng)目提供完整的測(cè)試流程。但不論是開(kāi)發(fā)還是測(cè)試，要理解雙方的活動(dòng)價(jià)值，保證每個(gè)環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量。

參考文獻(xiàn)：

[1] 葉嫻.淺談?dòng)?jì)算機(jī)軟件工程化管理[J].電子世界,2014(08):261.

YE Xian.Discussion on Computer Software Engineering Management[J].Electronic World,2014(08):261.

[2] 肖云.淺析計(jì)算機(jī)軟件工程的管理和應(yīng)用[J].電腦知識(shí)與技術(shù),2016(12):88-89.

XIAO Yun.Analysis on the Management and Application of Computer Software Engineering[J].Compu ter Knowledge and Technology,2016(12):88-89.

[3] 何寧.淺談?dòng)?jì)算機(jī)軟件工程化管理[J].信息系統(tǒng)工程,2014(10):58.

HE N ing.D iscussion on Com pu ter So ftware Engineering Management[J].In formation Systems Engineering,2014(10):58.

[4] 中國(guó)人民解放軍總裝備部.軍用軟件研制能力成熟度模型（GJB5000A）[S].2008.

General Armament Department of the People's Liberation Army.Capability Maturity Model for Military Software Development-GJB5000A[S].2008.

Practice and Analysis of Project Life-Cycle Software Test based on GJB5000A

WANG Shi-qin, LI Bin, LU Ye

(No.30 Institute of CETC, Chengdu Sichuan 610041, China)

As one of the most effective methods for testing the quality of software products, software testing now becomes a very important research focus in the field of software engineering. This paper, based on the implementation of GJB5000A three standards, analyzes the relationship of between software development and testing, describes the software testing procedures of project life-cycle, propose the software testing methods in satisfying GJB5000A three standards. For purpose to closely integrate test and project development process, the development and the testing work are alternately carried out throughout the whole process of project development, thus provide a testing guidance satisfying military standard for preparing to implement or being implemented GJB5000A three-standard projects.

software test; life cycle; quality; software engineering

TP311.5

A

1002-0802(2016)-11-1567-08

10.3969/j.issn.1002-0802.2016.11.029

王詩(shī)琹（1984—），女，學(xué)士，工程師，主要研究方向?yàn)镚JB5000A三級(jí)標(biāo)準(zhǔn)實(shí)施管理﹑嵌入式設(shè)備硬件設(shè)計(jì)與測(cè)試；

李 彬（1979—），男，學(xué)士，工程師，主要研究方向?yàn)橛?jì)算機(jī)科學(xué)技術(shù)﹑軟件測(cè)試與集成；

盧 葉（1982—），女，學(xué)士，工程師，主要研究方向?yàn)橥ㄐ偶夹g(shù)﹑品牌推廣與市場(chǎng)策劃。

2016-07-10；

2016-10-25 Received date:2016-07-10;Revised date:2016-10-25