測試報(bào)告缺陷分析精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的測試報(bào)告缺陷分析主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：測試報(bào)告缺陷分析范文

關(guān)鍵詞：　自動(dòng)化測試；面向業(yè)務(wù)；自動(dòng)化測試框架

0　引言

傳統(tǒng)自動(dòng)化測試，通常針對被測系統(tǒng)特點(diǎn)專項(xiàng)開發(fā)自動(dòng)化測試腳本，當(dāng)系統(tǒng)功能變更頻繁時(shí)，自動(dòng)化測試維護(hù)成本很大；測試資產(chǎn)不便于統(tǒng)一的管理，重要測試資產(chǎn)不便于積累和復(fù)用；另外，自動(dòng)化測試對測試人員的開發(fā)技術(shù)要求，限制了自動(dòng)化測試的大規(guī)模普及和推廣。為此，本文給出了一種業(yè)務(wù)與技術(shù)分析、腳本與數(shù)據(jù)分離的面向業(yè)務(wù)的測試框架BOSATF（Business　Oriented　Software　Automated　Testing　Framework）。

1　BOSATF架構(gòu)設(shè)計(jì)

1.1　架構(gòu)設(shè)計(jì)原則

業(yè)務(wù)邏輯和測試腳本分離：框架提供協(xié)同工作平臺(tái)，業(yè)務(wù)人員設(shè)計(jì)業(yè)務(wù)組件和業(yè)務(wù)流，自動(dòng)化測試技術(shù)人員關(guān)注具體自動(dòng)化腳本的開發(fā)，兩個(gè)角色分工明確、高效配合。

測試腳本和測試數(shù)據(jù)分離：腳本和數(shù)據(jù)分別獨(dú)立構(gòu)建，同一測試腳本適用不同的測試數(shù)據(jù)，并使得腳本和數(shù)據(jù)的變更對整個(gè)測試工程的維護(hù)量降到最低。

框架功能模塊高內(nèi)聚低耦合：分層架構(gòu)設(shè)計(jì)，模塊內(nèi)功能專一，模塊間功能獨(dú)立，在滿足自動(dòng)化測試框架基本功能需求的基礎(chǔ)上，減少框架維護(hù)工作量。

1.2　分層架構(gòu)設(shè)計(jì)

BOSATF由資源層、構(gòu)建層、控制層、服務(wù)層和基礎(chǔ)函數(shù)層等五大組件構(gòu)成。

資源層提供框架運(yùn)行過程中所需要自動(dòng)化測試腳本、測試用例、測試數(shù)據(jù)和業(yè)務(wù)流程。各類資源邏輯上互相獨(dú)立。

構(gòu)建層負(fù)責(zé)資源層調(diào)度和管理，實(shí)現(xiàn)腳本、數(shù)據(jù)、用例、業(yè)務(wù)流程的統(tǒng)一管理，為構(gòu)建層提供一致。

控制層協(xié)調(diào)構(gòu)建層基礎(chǔ)服務(wù)，遵循測試執(zhí)行計(jì)劃和測試機(jī)群管理規(guī)則，按照計(jì)劃分配測試資源，保證測試執(zhí)行有序進(jìn)行。

服務(wù)層主要功能有日志信息的收集、缺陷的管理、測試過程中錯(cuò)誤場景的恢復(fù)以及測試報(bào)告的生成。

基礎(chǔ)函數(shù)層主要提供框架運(yùn)行過程所需要的通用功能，包括日志管理、字符串格式轉(zhuǎn)換、身份證號生成、保費(fèi)校驗(yàn)和移動(dòng)設(shè)備控件識(shí)別等功能。

2　BOSATF功能模塊

2.1　測試用例管理

采用“業(yè)務(wù)流程分析法”，遵循“合并”和“拆分”原則，把手工測試案例轉(zhuǎn)化成自動(dòng)化測試案例，并建立映射關(guān)系，明確手工測試和自動(dòng)化測試的對應(yīng)關(guān)系，讓測試人員實(shí)時(shí)掌握自動(dòng)化測試進(jìn)度，以便及時(shí)制定和調(diào)整測試執(zhí)行方案。

實(shí)現(xiàn)自動(dòng)化測試用例和成熟測試管理工具的互聯(lián)互通，實(shí)現(xiàn)測試用例的導(dǎo)入、導(dǎo)出和多模式測試用例管理功能。

2.2　測試數(shù)據(jù)的管理

部分中間業(yè)務(wù)流程測試數(shù)據(jù)的準(zhǔn)備時(shí)間占總測試周期的30%。針對這個(gè)問題，框架支持測試數(shù)據(jù)自動(dòng)生成功能。根據(jù)被測功能特點(diǎn)，定制測試數(shù)據(jù)生成策略，批量自動(dòng)生成測試數(shù)據(jù)。

框架同時(shí)提供“一次性數(shù)據(jù)”解決方案。針對部分業(yè)務(wù)模塊測試數(shù)據(jù)無法恢復(fù)的情況，框架記錄測試歷史數(shù)據(jù)，避免數(shù)據(jù)的重復(fù)使用。

2.3　業(yè)務(wù)流程定義模塊

該模塊提供了可視化業(yè)務(wù)流程定義功能，降低了框架使用的技術(shù)難度。通過該模塊，測試人員無需關(guān)注技術(shù)細(xì)節(jié)，只需要從業(yè)務(wù)人員視角定義業(yè)務(wù)操作流程，實(shí)現(xiàn)自動(dòng)化測試腳本的自動(dòng)組裝。

2.4　測試執(zhí)行管理

測試執(zhí)行管理模塊調(diào)用測試腳本、測試用例、測試數(shù)據(jù)、業(yè)務(wù)流程定義等相關(guān)服務(wù)，分配硬件執(zhí)行機(jī)器資源，執(zhí)行測試計(jì)劃。同時(shí)，收集測試執(zhí)行過程信息，為服務(wù)層的缺陷管理、測試報(bào)告管理提供基礎(chǔ)數(shù)據(jù)依據(jù)。

2.5　場景恢復(fù)模塊

目的是在出現(xiàn)故障的情況下能盡快的恢復(fù)系統(tǒng)，保證能快速、準(zhǔn)確地正?；謴?fù)測試場景。根據(jù)故障的不同，明確地定義恢復(fù)的策略，制定不同的恢復(fù)機(jī)制，確保自動(dòng)化測試在可預(yù)知風(fēng)險(xiǎn)前提下，快速恢復(fù)測試場景，按計(jì)劃執(zhí)行測試案例，保證測試進(jìn)度。

2.6　缺陷管理模塊

該模塊采用與常用缺陷管理工具（QC、BugFree、JIRA）集成的辦法，提供對發(fā)現(xiàn)缺陷的管理功能。支持缺陷狀態(tài)的自定義，實(shí)現(xiàn)缺陷的自動(dòng)提交，測試處理進(jìn)度的自動(dòng)追蹤。

2.7　測試報(bào)告模塊

以測試執(zhí)行過程日志記錄為基礎(chǔ)，結(jié)合測試計(jì)劃、測試執(zhí)行管理等基礎(chǔ)信息，提供多模式（TXT，Excel，Word，PDF）測試報(bào)告生成功能。

2.8　測試機(jī)群管理模塊

該模塊在實(shí)現(xiàn)自動(dòng)化測試框架基本功能基礎(chǔ)上，結(jié)合虛擬化IT運(yùn)維趨勢，開發(fā)了基于虛擬機(jī)技術(shù)的機(jī)群管理模塊。

測試機(jī)群從職責(zé)上劃分為五類：自動(dòng)化控制調(diào)度服務(wù)器、資產(chǎn)管理服務(wù)器、資產(chǎn)備份服務(wù)器、測試執(zhí)行機(jī)群及公共函數(shù)服務(wù)器。

3　結(jié)論

針對傳統(tǒng)自動(dòng)化測試框架不足之處，結(jié)合實(shí)際工作需求，提出了一種面向業(yè)務(wù)的軟件自動(dòng)化測試框架-BOSATF。它獨(dú)立于自動(dòng)化測試實(shí)施過程，作為專題項(xiàng)目開展工作，實(shí)現(xiàn)了業(yè)務(wù)流程管理和技術(shù)實(shí)現(xiàn)的分離，降低了自動(dòng)化測試成本，提高了自動(dòng)化測試大規(guī)模推廣的技術(shù)可行性。

該框架在實(shí)現(xiàn)自動(dòng)化測試框架基本功能基礎(chǔ)上，結(jié)合虛擬化IT運(yùn)維趨勢，開發(fā)了基于虛擬機(jī)的機(jī)群管理模塊。同時(shí)，框架提供了開放式集成接口，為與成熟的軟件測試管理工具互通集成提供了途徑。

實(shí)踐證明，該自動(dòng)化測試框架功能豐富、擴(kuò)展便捷，有效降低了自動(dòng)化測試難度，提高了測試工作效率。

參考文獻(xiàn)：

[1]丁祥武、張欽、韓朱忠，SQL測試用例集的自動(dòng)生成[J].計(jì)算機(jī)應(yīng)用與軟件，2012，29（8）：185-188.

[2]黃彪賢、熊建斌、李振坤，金融軟件功能自動(dòng)化測試的分析及應(yīng)用，計(jì)算機(jī)工程與設(shè)計(jì)，2012，　33（2）：787-790.

第2篇：測試報(bào)告缺陷分析范文

【關(guān)鍵詞】計(jì)算機(jī)軟件；軟件測試；生命周期；BSS系統(tǒng)；IT系統(tǒng)

1 引言

通信行業(yè)通常有三個(gè)相對獨(dú)立的IT系統(tǒng)：OSS運(yùn)營支撐系統(tǒng)、BSS業(yè)務(wù)支撐系統(tǒng)、管理支撐系統(tǒng)。其中，BSS是通信行業(yè)對外向客戶直接服務(wù)的系統(tǒng)，管理著企業(yè)的各類客戶資料，為各類客戶提供業(yè)務(wù)受理和計(jì)費(fèi)服務(wù)。BSS系統(tǒng)做得好壞，直接牽涉到最終用戶對通信業(yè)務(wù)的使用。要保證BSS系統(tǒng)的質(zhì)量，就需要在BSS系統(tǒng)的各個(gè)環(huán)節(jié)把好質(zhì)量關(guān)。

本文的研究任務(wù)就是通過軟件測試環(huán)節(jié)提高BSS系統(tǒng)軟件的效率，從而大大提高企業(yè)的信息化服務(wù)水平，使業(yè)務(wù)支撐部門對業(yè)務(wù)部門進(jìn)行強(qiáng)有力的支撐。

2 軟件測試研究基礎(chǔ)

軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進(jìn)行功能和性能測試，甚至根據(jù)需要編寫不同的測試工具，設(shè)計(jì)和維護(hù)測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進(jìn)行分析和評估。軟件測試貫穿整個(gè)軟件系統(tǒng)的生命周期中，為保證服務(wù)質(zhì)量，軟件測試要經(jīng)過開發(fā)過程中的單元測試，集成測試，以及軟件交付后的確認(rèn)測試，系統(tǒng)測試，驗(yàn)收測試，還有軟件使用后的回歸測試。如圖所示：

2.1 單元測試

單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動(dòng)，在單元測試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。單元測試不僅僅是作為無錯(cuò)編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。

2.2 集成測試

集成測試，也叫組裝測試或聯(lián)合測試，是單元測試的邏輯擴(kuò)展。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作。

2.3確認(rèn)測試

確認(rèn)測試又稱有效性測試。有效性測試是在模擬的環(huán)境下，運(yùn)用黑盒測試的方法，驗(yàn)證被測軟件是否滿足需求規(guī)格說明書列出的需求。任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致。

2.4 系統(tǒng)測試

系統(tǒng)測試是將已經(jīng)確認(rèn)的軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測試和確認(rèn)測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。

2.5 驗(yàn)收測試

驗(yàn)收測試是系統(tǒng)開發(fā)生命周期方法論的一個(gè)階段，這時(shí)相關(guān)的用戶和獨(dú)立測試人員根據(jù)測試計(jì)劃和結(jié)果對系統(tǒng)進(jìn)行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。驗(yàn)收測試是部署軟件之前的最后一個(gè)測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。

2.6 回歸測試

伴隨著軟件生命周期中的任何一個(gè)階段，還有一個(gè)重要的測試環(huán)節(jié)是回歸測試。只要軟件發(fā)生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發(fā)現(xiàn)了錯(cuò)誤并做了修改，也有可能是因?yàn)樵诩苫蚓S護(hù)階段加入了新的模塊。

3 案例分析及研究

3.1 驗(yàn)收測試在通信行業(yè)BSS系統(tǒng)中的應(yīng)用研究

本案中，軟件上線前，要經(jīng)過初驗(yàn)和終驗(yàn)，初驗(yàn)是對軟件的初次驗(yàn)收，根據(jù)合同要求，初驗(yàn)時(shí)一般要滿足的條件是，軟件程序在一定的范圍內(nèi)上線試運(yùn)行，并在試運(yùn)行過程中故障率不超過一定的范圍。初驗(yàn)過程中，使用人員對軟件進(jìn)行充分的使用，盡量多的遍歷所有的分支點(diǎn)，對軟件開發(fā)商提出更詳細(xì)的需求改造要求，軟件廠家在此階段都會(huì)盡可能快地做出修改，并提交給使用人員。這樣重復(fù)多次，直到達(dá)到初驗(yàn)要求，項(xiàng)目會(huì)繼續(xù)推廣到更大的范圍。大范圍使用后，使用人員會(huì)隨之增多，必將會(huì)碰到更大更多的問題，在經(jīng)過軟件廠家的修改優(yōu)化，達(dá)到軟件程序穩(wěn)定運(yùn)行的效果，此時(shí)，項(xiàng)目才滿足終驗(yàn)條件。終驗(yàn)后，軟件廠家會(huì)維護(hù)一段時(shí)間，簽訂長期的維護(hù)合同。

根據(jù)這種情況，驗(yàn)收測試是在軟件程序的初驗(yàn)和終驗(yàn)都要涉及到的。測試目的都是盡量查找軟件的漏洞以便得以修改，測試的方法是功能測試涉及較多一點(diǎn)。BSS系統(tǒng)驗(yàn)收測試的目的是確認(rèn)系統(tǒng)是否滿足產(chǎn)品需求規(guī)格說明和技術(shù)合同的相關(guān)規(guī)定，繼而能否滿足企業(yè)應(yīng)用需求。一般需要通過實(shí)施預(yù)定的測試計(jì)劃和測試執(zhí)行活動(dòng)，確認(rèn)系統(tǒng)的功能需求、性能需求和文檔需求。BSS系統(tǒng)是較復(fù)雜的大規(guī)模系統(tǒng)，其驗(yàn)收測試具體包括：安裝測試、功能測試、界面測試、性能測試、文檔測試、負(fù)載壓力測試、恢復(fù)測試、安全性測試、兼容性測試等。

BSS系統(tǒng)的驗(yàn)收測試一般由使用人員來做，且必須做到對每個(gè)細(xì)節(jié)和關(guān)鍵指標(biāo)的反復(fù)測試。它的測試技術(shù)方法不僅有上述提到的幾種測試，還需要一些白盒測試，避免實(shí)現(xiàn)當(dāng)前功能的情況下影響到其他模塊。它的測試用例，需要反復(fù)推算，尋找到最佳用例，以盡多的遍歷各測試節(jié)點(diǎn)，對程序、數(shù)據(jù)、文檔都要做到細(xì)致的測試。

根據(jù)以上分析，驗(yàn)收測試涉及BSS系統(tǒng)的各環(huán)節(jié)內(nèi)容。其中，最主要要審核的內(nèi)容就是根據(jù)軟件的需求分析，檢驗(yàn)要交付的軟件系統(tǒng)是否滿足需求分析中的內(nèi)容。具體來說，根據(jù)驗(yàn)收測試方法和它所屬的狀態(tài)及重要性，在BSS系統(tǒng)中，驗(yàn)收測試的審核內(nèi)容，可以用以下文檔驗(yàn)收來體現(xiàn)。

軟件開放商應(yīng)向企業(yè)項(xiàng)目組成員提供以下文檔：《軟件需求分析書》、《驗(yàn)收測試計(jì)劃》和《項(xiàng)目驗(yàn)收準(zhǔn)則》、《測試用例設(shè)計(jì)》、《測試環(huán)境標(biāo)準(zhǔn)》、《測試報(bào)告》、《測試結(jié)果分析》、《缺陷報(bào)告》、《驗(yàn)收測試報(bào)告》、《使用說明》或《操作文檔》、《試運(yùn)行報(bào)告》。另外，使用人員根據(jù)軟件廠家提供的上述文檔，挑選重要的測試項(xiàng)，組織使用人員重新編寫測試用例并進(jìn)行測試，編寫客戶方自己的《驗(yàn)收測試計(jì)劃》、《驗(yàn)收測試報(bào)告》、《驗(yàn)收測試結(jié)果及分析》。根據(jù)《驗(yàn)收測試結(jié)果及分析》組織項(xiàng)目成員討論是否驗(yàn)收此項(xiàng)目。

驗(yàn)收測試流程圖：

根據(jù)上述要求，在本案例中，驗(yàn)收測試方面存在以下不足：

第一、《驗(yàn)收測試計(jì)劃》和《項(xiàng)目驗(yàn)收準(zhǔn)則》沒有專門的文檔。如果我們能在需求分析書完成后能夠定制獨(dú)立的《驗(yàn)收測試計(jì)劃》和《項(xiàng)目驗(yàn)收準(zhǔn)則》，則更有利于我們做好驗(yàn)收測試工作，做好終驗(yàn)工作。第二、沒有《缺陷報(bào)告》，程序的開發(fā)總要伴隨著缺陷的產(chǎn)生，雖然開放人員在逐漸的解決這些缺陷問題，但總有一些問題解決不了。第三、甲方對驗(yàn)收測試重視不足，沒有獨(dú)立的《驗(yàn)收測試計(jì)劃》、《驗(yàn)收測試報(bào)告》、《驗(yàn)收測試結(jié)果及分析》，沒有獨(dú)立的驗(yàn)收文檔，對結(jié)果也沒有做分析。第四、在驗(yàn)收測試整個(gè)過程中，甲方過于依賴乙方。整個(gè)流程以乙方提供驗(yàn)收文檔為主，甲方雖驗(yàn)收了文檔等資料，但并沒有根據(jù)資料編制驗(yàn)收測試方案，也沒有做驗(yàn)收測試報(bào)告及分析，只是在乙方提供驗(yàn)收測試文檔中根據(jù)驗(yàn)收測試用例進(jìn)行了測試。

在實(shí)際運(yùn)用中，首先要重視軟件測試的重要性，另外不能過于依賴軟件開發(fā)商，要建立企業(yè)自己的IT人員測試組，對軟件進(jìn)行詳盡的各方面的測試。

3.2 回歸測試在通信行業(yè)BSS系統(tǒng)中的應(yīng)用研究

實(shí)際工作中，回歸測試需要反復(fù)進(jìn)行，當(dāng)測試者一次又一次地完成相同的測試時(shí)，這些回歸測試將變得非常令人厭煩，為了支持多種回歸測試策略，可以運(yùn)用自動(dòng)測試工具，以便滿足達(dá)到不同回歸測試目標(biāo)的要求。

通信行業(yè)BSS系統(tǒng)的回歸測試特別頻繁，每月的應(yīng)用變更幾十例，有新增的功能，也有變更的功能，還有修復(fù)的功能。這些變更都需要回歸測試來驗(yàn)證功能是否達(dá)到需求的要求。根據(jù)軟件特性，進(jìn)行的回歸測試大都需要結(jié)合軟件模塊自身的功能，手工完成驗(yàn)證，并且不同的模塊的回歸測試方法也可能不同。進(jìn)行回歸測試時(shí)，不但檢驗(yàn)新增模塊的功能是否實(shí)現(xiàn)，還要驗(yàn)證是否影響了周邊其他模塊的功能，同時(shí)檢查整個(gè)大的模塊的功能是否正常，也就是考察軟件自身的功能和兼容性。

4總結(jié)與展望

實(shí)踐證明：將軟件測試的方法引入通信行業(yè)的BSS系統(tǒng)中，在軟件測試的各個(gè)環(huán)節(jié)都能夠詳細(xì)和規(guī)范的記錄測試相關(guān)信息，使管理層能夠方便的掌握到整個(gè)軟件的問題、配置、變更、等環(huán)節(jié)的信息，為領(lǐng)導(dǎo)決策提供了強(qiáng)有力的支持，達(dá)到了軟件使用的目的。大幅提高了系統(tǒng)的軟件維護(hù)效率和整個(gè)BSS系統(tǒng)的準(zhǔn)確性，使BSS系統(tǒng)對企業(yè)的業(yè)務(wù)能夠快速高效的支撐。

參考文獻(xiàn)

[1]（美）馬瑟著.王峰，郭長國，陳振華等譯.軟件測試基礎(chǔ)教程[M].北京：機(jī)械工業(yè)出版社，2011.

[2]陳能技.軟件測試技術(shù)大全[M].北京：人民郵電出版社，2011.

第3篇：測試報(bào)告缺陷分析范文

關(guān)鍵詞：軟件測試；性能測試；LoadRunner

中圖分類號：TP306　文獻(xiàn)標(biāo)識(shí)碼：A　文章編號：1672-3198(2009)12-0296-02

1　軟件性能測試

根據(jù)測試的目的和內(nèi)容的不同，性能測試主要包括以下方面：

(1)負(fù)載測試：確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。

(2)強(qiáng)度測試：確定在系統(tǒng)資源特別低的條件下軟件系統(tǒng)運(yùn)行情況。

(3)容量測試：在用戶可接受的響應(yīng)范圍內(nèi)，確定系統(tǒng)可處理同時(shí)在線的最大用戶數(shù)。

(4)壓力測試：通過確定一個(gè)系統(tǒng)的瓶頸或者最大使用極限的測試。

(5)疲勞強(qiáng)度測試：以系統(tǒng)穩(wěn)定運(yùn)行情況下能夠支持的最大并發(fā)用戶數(shù)或者日常運(yùn)行用戶數(shù)，持續(xù)執(zhí)行一段時(shí)間業(yè)務(wù)，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)處理最大工作強(qiáng)度性能的過程。

(6)大數(shù)據(jù)量測試：大數(shù)據(jù)量測試側(cè)重點(diǎn)在于數(shù)據(jù)的量上，包括獨(dú)立的數(shù)據(jù)量測試和綜合數(shù)據(jù)量測試。獨(dú)立的數(shù)據(jù)量測試針對某些系統(tǒng)存儲(chǔ)，傳輸、統(tǒng)計(jì)、查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量測試，而綜合數(shù)據(jù)量測試一般和壓力性能測試、負(fù)載性能測試、疲勞性能測試相結(jié)合。

2　軟件性能測試流程

2.1　測試方案設(shè)計(jì)

在軟件性能測試的初始階段，首先應(yīng)對業(yè)務(wù)模型和系統(tǒng)架構(gòu)進(jìn)行調(diào)研，收集測試需求。然后生戚性能測試計(jì)劃。業(yè)務(wù)調(diào)研和系統(tǒng)調(diào)研，需要性能測試團(tuán)隊(duì)提前了解被測試項(xiàng)目的業(yè)務(wù)功能和系統(tǒng)架構(gòu)。其間。開發(fā)部門應(yīng)協(xié)助提供被測系統(tǒng)相關(guān)的文檔和說明，如系統(tǒng)總體介紹、系統(tǒng)規(guī)格書、用戶使用手冊、網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖和系統(tǒng)配置說明、關(guān)鍵服務(wù)器及應(yīng)用部署與配置等文檔。通過和業(yè)務(wù)部門協(xié)商明確本次測試針對哪些業(yè)務(wù)行為，制定此次測試的目標(biāo)，細(xì)化測試的關(guān)注點(diǎn)和性能指標(biāo)要求。通過以上內(nèi)容制定詳細(xì)的測試方案，并制定詳細(xì)測試計(jì)劃和各階段目標(biāo)。

2.2　測試環(huán)境的搭建

測試環(huán)境的搭建分為軟硬測試系統(tǒng)的環(huán)境搭建和測試相關(guān)的數(shù)據(jù)準(zhǔn)備工作。環(huán)境搭建包括被測試系統(tǒng)的硬件環(huán)境建立和軟件應(yīng)用系統(tǒng)建立及基礎(chǔ)數(shù)據(jù)環(huán)境建立。保障被測試系統(tǒng)的業(yè)務(wù)可用性和功能的正確性，包括測試系統(tǒng)(如被測試項(xiàng)目的操作系統(tǒng)、中間件、數(shù)據(jù)庫、壓力測試控制臺(tái)、壓力測試發(fā)起工具等)的環(huán)境搭建、軟件的安裝；測試環(huán)境的網(wǎng)絡(luò)環(huán)境建立(如開放防火墻和網(wǎng)關(guān)等)；最后進(jìn)行測試環(huán)境可用性驗(yàn)證。測試數(shù)據(jù)準(zhǔn)備包括測試應(yīng)用系統(tǒng)基礎(chǔ)數(shù)據(jù)準(zhǔn)備，即需要按性能測試規(guī)模要求，準(zhǔn)備足夠的、一定規(guī)模的基礎(chǔ)數(shù)據(jù)，通常采用全量恢復(fù)生產(chǎn)數(shù)據(jù)的方式以達(dá)到和生產(chǎn)環(huán)境數(shù)據(jù)一致性的要求。

2.3　測試場景開發(fā)

測試場景開發(fā)指測試程序(腳本)的開發(fā)。測試程序(腳本)的開發(fā)是對被測系統(tǒng)的用戶業(yè)務(wù)行為進(jìn)行模擬、錄制、編程、參數(shù)化、腳本定制和調(diào)式等一系列工作，以使測試程序(腳本)可以真實(shí)模擬實(shí)際生產(chǎn)中的業(yè)務(wù)交易行為，并通過對程序中參數(shù)的配置實(shí)現(xiàn)對并發(fā)數(shù)、思考時(shí)間等屬性的準(zhǔn)確控制。

2.4　測試執(zhí)行

測試執(zhí)行是在測試方案的制定、測試環(huán)境準(zhǔn)備、測試場景開發(fā)工作正確完成的基礎(chǔ)上進(jìn)行的。

2.5　測試報(bào)告和分析

性能測試報(bào)告和結(jié)果分析是在測試執(zhí)行完成以后，對性能數(shù)據(jù)進(jìn)行采集結(jié)果收集工作和針對性能測試過程中暴露的問題進(jìn)行分析的階段。性能測試報(bào)告是對性能測試過程中的監(jiān)控結(jié)果以及報(bào)表進(jìn)行匯總，按照一定的模板整理出的一份結(jié)論性文檔。開發(fā)團(tuán)隊(duì)和性能測試團(tuán)隊(duì)?wèi)?yīng)依據(jù)對性能測試實(shí)施過程中監(jiān)控和記錄的數(shù)據(jù)和表格，分析系統(tǒng)中存在的性能問題和程序缺陷。并有針對性的在報(bào)告中闡述問題、分析原因、提出解決或優(yōu)化方案。

2.6　回歸測試

回歸測試是開發(fā)部門在性能測試報(bào)告的基礎(chǔ)上針對軟件的性能或者效率缺陷進(jìn)行優(yōu)化或者修復(fù)，為了驗(yàn)證優(yōu)化的效果而進(jìn)行的再測試。

3　軟件性能測試工具LoadRunner

作為軟件質(zhì)量控制中的重要一環(huán)，性能測試已經(jīng)越來越受到軟件開發(fā)商和用戶的重視，成為軟件測試的重中之重。性能測試通常在系統(tǒng)測試階段執(zhí)行，常常與強(qiáng)度測試結(jié)合起來，一般需要使用測試工具。一個(gè)優(yōu)秀的軟件測試工具，不僅可以輔助測試工作，滿足科學(xué)測試的基本要求；而且可以自動(dòng)化測試過程，節(jié)約大量的時(shí)間、成本、人員和資源，提高軟件產(chǎn)品的質(zhì)量。目前市場上主要使用的測試工具有微軟公司的WAS(Web Application Stress Tool)、Compuware公司的QALoad、RadView公司的WebRunner、HP(Mercury)公司的LoadRunner。下面以LoadRunner為例。介紹軟件測試工具的工作流程。

LoadRunner是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過模擬上千萬用戶實(shí)施并發(fā)負(fù)載及實(shí)時(shí)性能檢測來確認(rèn)和查找問題，能夠?qū)φ麄€(gè)企業(yè)架構(gòu)進(jìn)行測試。通過使用LoadRunner，企業(yè)能夠最大限度的縮短測試時(shí)間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的周期。LoadRunner能支持廣泛的協(xié)議和技術(shù)，功能比較強(qiáng)大，可以為特殊環(huán)境提供特殊的解決方案。LoadRunner由下面三部分組成：Virtual UserGenerator用來錄制腳本、編輯腳本Controller用來布置測試場景、執(zhí)行測試場景；Analysis用來對測試結(jié)果進(jìn)行分析。

用LoadRunner進(jìn)行負(fù)載測試的流程通常由五個(gè)階段組成：計(jì)劃、腳本創(chuàng)建、場景定義、場景執(zhí)行、監(jiān)視執(zhí)行和結(jié)果分析。

(1)計(jì)劃負(fù)載測試：定義性能測試要求，例如并發(fā)用戶的數(shù)量、典型業(yè)務(wù)流程和所響應(yīng)時(shí)間；根據(jù)軟件項(xiàng)目相關(guān)需求，定義相關(guān)測試的細(xì)節(jié)，撰寫性能測試報(bào)告。

(2)創(chuàng)建Vuser腳本：將最終用戶活動(dòng)捕獲到自動(dòng)腳本中LoadRunner的腳本是C語言代碼，LoadRunner有自己的一整套函數(shù)接口，可以供外部調(diào)用。腳本可分INIT、ACTION、END三部分，其中：INIT部分可以理解為初始部分。ACTION可以理解為事務(wù)部分，也是測試的主體，END是退出結(jié)束。

當(dāng)錄制完一個(gè)基本的用戶腳本后，在正式使用前我們還需要完善測試腳本，增強(qiáng)腳本的靈活性。一般情況下，我們通過以下幾種方法來完善測試腳本。插人事務(wù)、插入結(jié)合點(diǎn)、插入注解、參數(shù)化輸入。

(3)定義場景：使用LoadRunner Controller設(shè)置測試環(huán)境；錄制好腳本之后，就可以把腳本加入到場景里面去了，這里首先介紹一下LR的場景類型，LR有2種大的場景類

型。

①M(fèi)anual Scenario：該項(xiàng)要完全手動(dòng)的設(shè)置場景，這項(xiàng)下面還可以設(shè)置為每一個(gè)腳本分配要運(yùn)行的虛擬用戶的百分比，可在Controller的Scenario菜單下設(shè)置。

②Goal―Oriented Scenario,如果你的測試計(jì)劃是要達(dá)到某個(gè)性能指標(biāo)，比如：每秒多少點(diǎn)擊。每秒多少transae，tions，能到達(dá)多少VU，某個(gè)Transaction在某個(gè)范圍VU(5D。一1000)內(nèi)的反應(yīng)時(shí)間等等，那么就可以使用面向目標(biāo)的場景。

(4)設(shè)置場景：

Design：設(shè)計(jì)測試場景的靜態(tài)部分，設(shè)置模擬用戶生成器、模擬用戶數(shù)量、模擬用戶組等。

Run：設(shè)計(jì)測試的動(dòng)態(tài)部分，主要指添加性能計(jì)數(shù)器，在腳本運(yùn)行的過程中可以通過這些計(jì)數(shù)器反饋的數(shù)據(jù)。

建立了測試場景后，我們可以對Edit_Schedule進(jìn)行設(shè)置，設(shè)置測試開始執(zhí)行的時(shí)問，對于手動(dòng)設(shè)計(jì)的測試還可以設(shè)定它的持續(xù)時(shí)間，以及何時(shí)起用或禁止調(diào)用模擬用戶。

(5)運(yùn)行場景：通過LoadRunner Controller驅(qū)動(dòng)、管理和監(jiān)控負(fù)載測試。

設(shè)置完畢后，點(diǎn)擊“開始方案”運(yùn)行場景。在運(yùn)行過程中，可以監(jiān)視各個(gè)服務(wù)器的運(yùn)行情況(DataBase Server、WebServer等)。監(jiān)視場景通過添加性能計(jì)數(shù)器來實(shí)現(xiàn)，下列數(shù)據(jù)需要特別關(guān)注：

①M(fèi)emory：Available Mbytes物理內(nèi)存的可用數(shù)(單位Mbytes)至少要有10％的物理內(nèi)存值。

⑦Processor：Processor Time CPU使用率。這是查看處理器飽和狀況的最佳計(jì)數(shù)器。顯示所有CPU的線程處理時(shí)間。如果一個(gè)或多個(gè)處理器的該數(shù)值持續(xù)超過90％，則表示此測試的負(fù)載對于目前的硬件過于沉重。為多處理器服務(wù)器添加該計(jì)數(shù)器的O到x個(gè)實(shí)例。

③Processor Queue Length：是指處理列隊(duì)中的線程數(shù)，小于2。處理器瓶頸時(shí)會(huì)導(dǎo)致該值持續(xù)大于2。

④Context Switches/sec；如果切換次數(shù)到5000*CPU個(gè)數(shù)和i0000*CPU個(gè)數(shù)中，說明它忙于切換線程。

⑤Network Interface：Bytes Total/sec為發(fā)送和接收字節(jié)的速率，包括幀字符在內(nèi)。判斷網(wǎng)絡(luò)連接速度是否是瓶頸，可以用該計(jì)數(shù)器的值和目前網(wǎng)絡(luò)的帶寬比較。

第4篇：測試報(bào)告缺陷分析范文

【關(guān)鍵詞】戶籍管理系統(tǒng)；S.S.H（Struts，Hibernate，Spring）；JAVA；JSP

1系統(tǒng)實(shí)現(xiàn)

1.1對應(yīng)的程序代碼

public class User implements Serializable{

private static final long serialVersionUID= 7141419035239709511L；

private long id；

1.1登錄界面

登陸窗體用于接受用戶的用戶名/密碼輸入，判斷是否合法。如果是合法用戶，釋放該窗體并調(diào)出Frmver窗體；否則信息提示無此用戶。

實(shí)現(xiàn)此功能的代碼如下。首先從獲取從頁面輸入的用戶名和密碼，然后調(diào)用userDao.selectBean方法，從數(shù)據(jù)庫里取出該條記錄進(jìn)行判斷，如果該條記錄存在，則說明用戶登陸成功，同時(shí)把用戶信息存在session里面方便調(diào)用，如果記錄為空，則跳轉(zhuǎn)到登陸頁面，同時(shí)提醒用戶錯(cuò)誤信息。

public String login（）throws IOException {HttpServletRequest request= ServletActionContext.getRequest（）；

Stringusername= request.getParameter（"username"）；

Stringpassword= request.getParameter（"password"）；

this.setUrl（"main.jsp"）；

return "redirect"；}

1.2戶籍對應(yīng)的程序代碼

public class Huji implements Serializable{

private static final long serialVersionUID = 7141419035239709511L；

private long id；

private String qianrushijian；private String qianchushijian；

1.3戶籍管理界面

代碼如下：

public String hujilist（）{

HttpServletRequest request = ServletActionContext.getRequest（）；

request.setAttribute（"hujibianhao"，hujibianhao）；}

1.4用戶管理窗體

用戶管理代碼如下：

public String userlist（）{

HttpServletRequest request = ServletActionContext.getRequest（）；

return SUCCESS；

}

通過userDao.selectBeanList方法來調(diào)用數(shù)據(jù)庫的查詢方法來查到符合條件的記錄，在通過request.setAttribute方法把查詢到的記錄傳到顯示的頁面。同時(shí)通過this.setUrl（"user/userlist.jsp"）；方法指定傳回到具體指定的是哪個(gè)JSP頁面。通過這樣實(shí)現(xiàn)對數(shù)據(jù)查詢功能的實(shí)現(xiàn)，同時(shí)在該用戶列表頁面定義了對戶籍信息的增加，修改，刪除等操作。

1.5戶口注銷

注銷記錄對應(yīng)的程序代碼：

public class Zhuxiao implements Serializable{

private static final long serialVersionUID = 7141419035239709511L；

private long id；

private int type；

2 系y測試與運(yùn)行

2.1測試概述

2.1.1測試目的

本測試報(bào)告是簡單戶籍管理系統(tǒng)的測試報(bào)告，目的在于分析測試結(jié)果，描述系統(tǒng)是否有戶籍管理的功能。

2.1.2測試內(nèi)容

利用白盒測試黑盒測試相結(jié)合的方式

測試平臺(tái)：Windows XP操作系統(tǒng)。

測試工具：Microsoft Visual Basic中文版。

2.2測試分析

系統(tǒng)包括查詢管理、戶管理、個(gè)人戶口管理三大部分。

實(shí)現(xiàn)的基本功能有：

（1）實(shí)現(xiàn)戶籍的查詢，可分為普通用戶查詢和內(nèi)部管理員的查詢，普通用戶只能 查詢基本信息和修改密碼，如身份證號、出生日期等。

（2）實(shí)現(xiàn)戶籍的修改，包括戶口的修改以及個(gè)人信息的修改。

（3）實(shí)現(xiàn)個(gè)人戶口管理，包括個(gè)人戶口的新建和遷入遷出。

（4）關(guān)于管理，包括個(gè)人戶口注銷和戶口注銷等，同時(shí)需注明注銷原因、證明材 料等。

本論文設(shè)計(jì)并且實(shí)現(xiàn)一個(gè)基于web技術(shù)的戶籍管理系統(tǒng)，故而系統(tǒng)主要以j2EE作為開發(fā)基礎(chǔ)，主要使用了struts2+spring+hibernate等多種框架的結(jié)合使用，本人認(rèn)為今后的研究主要在以下幾個(gè)方面做出努力：

（1）系統(tǒng)各個(gè)功能模塊的設(shè)計(jì)還需要實(shí)踐的檢驗(yàn)，比如在戶籍管理部門進(jìn)行試運(yùn)行，用戶使用系統(tǒng)后反饋意見，在使用當(dāng)中不斷返現(xiàn)功能設(shè)計(jì)缺陷、新功能的添加等等。

（2）進(jìn)一步設(shè)計(jì)針對戶籍檔案海量的存儲(chǔ)方案。

參考文獻(xiàn)：

[1]馮巧立.我國戶籍制度改革研究[D].吉林大學(xué)，2010

[2]陳大雷.戶籍管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].山東大學(xué)，2009

[3]王鳳振.基于web的居民戶籍管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].天津大學(xué)，2012

作者簡介：

第5篇：測試報(bào)告缺陷分析范文

關(guān)鍵詞：軟件開發(fā)文檔；項(xiàng)目質(zhì)量；Offshore；概要設(shè)計(jì)；詳細(xì)設(shè)計(jì)；文檔規(guī)范化；軟件開發(fā)文檔標(biāo)準(zhǔn)化

中圖分類號：TP311.5

1 軟件開發(fā)文檔的重要性

影響軟件項(xiàng)目進(jìn)度、成本、質(zhì)量的因素主要是“過程、人、技術(shù)”[1]。而規(guī)范的過程管理，包括軟件開發(fā)過程的文檔規(guī)范及標(biāo)準(zhǔn)化便于開發(fā)過程中準(zhǔn)確地交流信息以及軟件項(xiàng)目交付后的維護(hù)工作，因此可以提高軟件開發(fā)的效率和質(zhì)量、改進(jìn)軟件開發(fā)過程。

文檔既然是多人進(jìn)行項(xiàng)目開發(fā)相互溝通及共享信息的媒體，它就是項(xiàng)目所必須的、可重用的、文檔的質(zhì)量也是評價(jià)項(xiàng)目質(zhì)量的一部分，而且最重要的是文檔是否與源代碼保持一致很重要。

軟件項(xiàng)目的開發(fā)是個(gè)團(tuán)隊(duì)化作業(yè)復(fù)雜的過程，團(tuán)隊(duì)成員間的溝通很重要。目前軟件開發(fā)項(xiàng)目面臨的挑戰(zhàn)是：很多的軟件開發(fā)環(huán)境，應(yīng)用平臺(tái)也很復(fù)雜，有的需求又要在多語言環(huán)境下運(yùn)行。因此保證軟件項(xiàng)目成功的較為重要的一個(gè)因數(shù)之一是軟件開發(fā)過程及其文檔的規(guī)范化管理。文檔是軟件產(chǎn)品的一部分，文檔在軟件設(shè)計(jì)人員、軟件開發(fā)人員、軟件維護(hù)人員及用戶之間起到橋梁的作用。特別是外包開發(fā)的過程中設(shè)計(jì)人員與編程人員往往不在一個(gè)辦公地點(diǎn)，對系統(tǒng)功能要求的理解除電視會(huì)議，聊天工具，電話等語言視頻溝通外，文檔的溝通很重要，按規(guī)范制作文檔的過程也就是按照軟件開發(fā)的規(guī)范編制軟件的過程。

既然文檔在設(shè)計(jì)及開發(fā)的過程中能在多人多種角色間起到橋梁的作用外，它的編制就必須有助于程序員在編程前能夠理解設(shè)計(jì)書定義的功能定義，有助于項(xiàng)目管理人員監(jiān)督和管理軟件的開發(fā)過程。此外，產(chǎn)品交付后要有助于用戶了解軟件的工作和操作，有助于系統(tǒng)維護(hù)人員對系統(tǒng)軟件進(jìn)行有效的維護(hù)、修改和功能追加，因此文檔的編制不僅非常重要還必須要保證一定的質(zhì)量。

2 軟件開發(fā)文檔

軟件開發(fā)文檔的種類很多。主要有：功能要求，需求分析，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，軟件測試計(jì)劃，軟件測試報(bào)告，軟件用戶手冊，數(shù)據(jù)庫設(shè)計(jì)，項(xiàng)目可行性分析，項(xiàng)目計(jì)劃，問題管理，項(xiàng)目進(jìn)度管理，項(xiàng)目總結(jié)等許多文檔。軟件開發(fā)規(guī)范（GB 8566-88），軟件產(chǎn)品開發(fā)文件編制指南（GB 8567-88）。

如下開發(fā)工程階段需要的文檔（見表1）：

表1 軟件開發(fā)工程階段的文檔示例

概要設(shè)計(jì) 詳細(xì)設(shè)計(jì) 單元測試 集成測試 系統(tǒng)測試 軟件交付

概要設(shè)計(jì)說明書 詳細(xì)設(shè)計(jì)書 單元測試計(jì)劃 集成測試設(shè)計(jì)書 系統(tǒng)測試計(jì)劃 用戶安裝手冊

DB設(shè)計(jì)說明書 單元測試報(bào)告 集成測試報(bào)告 系統(tǒng)測試報(bào)告 用戶使用指南

3 設(shè)計(jì)書樣式

3.1 用什么文檔編輯軟件書寫設(shè)計(jì)書。發(fā)達(dá)國家的軟件業(yè)很重視文檔，盡管目前敏捷開發(fā)被一切企業(yè)和開發(fā)團(tuán)隊(duì)所接受，但不可否認(rèn)，對需求相對明確，離岸的開發(fā)方式下，大部分的項(xiàng)目目前還是較多地采用瀑布式的開發(fā)方式。

實(shí)踐證明，用Excel書寫設(shè)計(jì)書比用Word書寫更加靈活和高效。本人參與開發(fā)的項(xiàng)目中，絕大部分設(shè)計(jì)書都是用Excel書寫的，Excel特別適用于圖形及表格的表達(dá)方式。而且項(xiàng)目的經(jīng)驗(yàn)是盡量使用圖形及表格的方式來記述設(shè)計(jì)定義，溝通理解的準(zhǔn)確率較高。

3.2 文檔的結(jié)構(gòu)、語言表述及術(shù)語。文檔結(jié)構(gòu)的裝訂順序?yàn)榉饷妗⑿拚臍v、正文、附錄說明。文檔中的層次番號也要統(tǒng)一，清晰的層次便于閱讀。語言的表達(dá)方式在外包的開發(fā)方式中很重要，因設(shè)計(jì)人員與開發(fā)人員通常不在一個(gè)辦公地點(diǎn)。特別是離岸外包的方式，設(shè)計(jì)人員與開發(fā)人員是不同的母語。因此設(shè)計(jì)書的語言描述應(yīng)盡量使用簡單句型，不要使用雙重否定，語言描述要清晰準(zhǔn)確盡量不要有二義性。事實(shí)上開發(fā)中出現(xiàn)的錯(cuò)誤在一定比例上是由于設(shè)計(jì)書的理解錯(cuò)誤所造成的。因此語言的表達(dá)應(yīng)盡量使用數(shù)學(xué)邏輯符號，因?yàn)橹挥袛?shù)學(xué)符號是跨不同語言的，不易產(chǎn)生理解錯(cuò)誤。如下（見表2）。實(shí)踐證明，僅用語言來表達(dá)，往往易產(chǎn)生理解錯(cuò)誤，用數(shù)學(xué)符號及數(shù)學(xué)邏輯符號的溝通最準(zhǔn)確。此外在圖形或表格旁同時(shí)追記語言描述比單單僅用語言來描述其溝通效率更高。

表2 數(shù)學(xué)表達(dá)示例

數(shù)學(xué)表達(dá)

A≠zero and A≠space

B=0 and C=0

D=zero or D=space

X0

日付yyyy0401

術(shù)語的標(biāo)準(zhǔn)化可提高溝通準(zhǔn)確度和效率的同時(shí)還能提高書寫詳細(xì)設(shè)計(jì)及測試報(bào)告書的文檔質(zhì)量。因?yàn)樵谕獍_發(fā)中，不能保證所有參與開發(fā)人員的外語水平很高或在同一個(gè)水平上。因此整理術(shù)語詞典，供大家查詢與參考是一個(gè)很好的方法。

將業(yè)務(wù)術(shù)語整理為詞典表，在離岸外包開發(fā)中，比較難的是理解客戶的業(yè)務(wù)及其術(shù)語，隨著業(yè)務(wù)范圍的擴(kuò)大，經(jīng)驗(yàn)的積累，不斷豐富詞典，對開發(fā)人員迅速理解設(shè)計(jì)書能提供很大的幫助。

3.3 制定編碼規(guī)范及命名規(guī)約。事實(shí)上軟件開發(fā)中，代碼中的注釋也可以理解為是軟件的一部分文檔，而且是很重要的文檔。規(guī)范化代碼中的注釋其本身就是項(xiàng)目質(zhì)量的一部分，因?yàn)樵谀壳暗能浖_發(fā)中，人員的交替是很常見的，好的代碼注釋，對他人修改程序，特別是系統(tǒng)上線后的項(xiàng)目維護(hù)都很重要。

制定編碼規(guī)范的目的是保證不同開發(fā)人員的代碼風(fēng)格基本一致，降低開發(fā)人員流動(dòng)可能導(dǎo)致的項(xiàng)目風(fēng)險(xiǎn)；強(qiáng)調(diào)代碼的可理解性，強(qiáng)化代碼注釋。

例如函數(shù)部分的記述規(guī)則：

'----------------------------------------------------------------

' 概要

' xxxxx

' 參數(shù)的說明

' ARG1 ： 參數(shù)1

' ARG2 ： 參數(shù)2

' 功能說明

' 使用方法說明

' 返回值

' xx 型

' 補(bǔ)充說明

' xxxxx

'----------------------------------------------------------------

變量、常量、函數(shù)、畫面控件及按鈕等都應(yīng)有命名規(guī)則。變量的命名規(guī)則（見表3）

表3 數(shù)據(jù)命名規(guī)則

數(shù)據(jù)類型 字首 例如

布爾型（Boolean） bln blnxxx

字節(jié)型（Byte） byt bytxxxData

Collection對象 col colxxx

貨幣類型（Currency） cur curxxx

日期類型（Date） dtm dtmStart

3.4 設(shè)計(jì)書的構(gòu)成。以下是設(shè)計(jì)書的Sheet頁的構(gòu)成示例（見圖4）。

表4 設(shè)計(jì)書的樣例

封面 修改履歷 功能概要 畫面切換關(guān)系 畫面設(shè)計(jì) 處理流程?處理內(nèi)容 DB更新 輸入?輸出文件 報(bào)表格式 輔助說明

無論是概要設(shè)計(jì)還是詳細(xì)設(shè)計(jì)，每本設(shè)計(jì)書要有以下的內(nèi)容：封面、修改履歷、功能概要、畫面的切換關(guān)系、畫面設(shè)計(jì)、處理流程?處理內(nèi)容、DB更新、輸入輸出文件、報(bào)表格式、輔助說明。

一個(gè)功能的設(shè)計(jì)書的應(yīng)盡量集中在一個(gè)Excel文檔中表達(dá)，這樣可提高查找信息的效率，縮短理解設(shè)計(jì)書的時(shí)間。如果分散在幾個(gè)文檔的話，不易查找信息。因?yàn)榫幊淌莻€(gè)腦力工作并且側(cè)重邏輯思維的過程，理解設(shè)計(jì)書的過程中如果還需要參照其他文檔的話則思路很容易被打斷。

另外一些設(shè)計(jì)的細(xì)節(jié)也盡量在文檔中體現(xiàn)，不然開發(fā)者與設(shè)計(jì)者要溝通確認(rèn)很浪費(fèi)時(shí)間。為節(jié)省書寫設(shè)計(jì)文檔的時(shí)間，一些不同功能、不同畫面所共同的地方可以提煉到一個(gè)共同的設(shè)計(jì)書中。這樣也便于文檔的變更修改與維護(hù)。

比如（見表5）是一種畫面項(xiàng)目的定義格式。登錄數(shù)據(jù)時(shí)畫面的項(xiàng)目是否要做必須輸入的檢查？打開畫面時(shí)初期光標(biāo)應(yīng)放在哪個(gè)項(xiàng)目的位置上？該項(xiàng)目的顯示文字的位數(shù)？這些細(xì)節(jié)都應(yīng)該明確。在設(shè)計(jì)之前就將設(shè)計(jì)書的文檔格式標(biāo)準(zhǔn)化，設(shè)計(jì)人員應(yīng)該考慮什么？應(yīng)該明確什么？就很清晰。

一個(gè)軟件項(xiàng)目的成功與失敗，往往不僅限于功能實(shí)現(xiàn)了就可以了，許多情況是細(xì)節(jié)決定成敗。實(shí)施文檔等標(biāo)準(zhǔn)化，可以避免漏記、提高溝通的準(zhǔn)確度從而提高效率及提高質(zhì)量。盡管規(guī)范化的文檔不能完全保證設(shè)計(jì)的質(zhì)量，設(shè)計(jì)的質(zhì)量主要還要依據(jù)設(shè)計(jì)書的正確性如何？依據(jù)設(shè)計(jì)出來的系統(tǒng)是否能滿足最終客戶的真正需求。但規(guī)范化的設(shè)計(jì)文檔可以提高溝通效率和溝通的質(zhì)量。

表5 畫面項(xiàng)目設(shè)計(jì)樣例

必須輸入 項(xiàng)目名稱 畫面顯示位數(shù) 新創(chuàng)建 編輯 參照 初始顯示值 登錄時(shí)的檢查條件 數(shù)據(jù)取得源 備注

擔(dān)當(dāng)者 20 I I O 初期光標(biāo) I：輸入項(xiàng)目

O：輸出項(xiàng)目

3.5 設(shè)計(jì)書的變更管理。由于在軟件項(xiàng)目的開發(fā)過程中，存在許多不可預(yù)料的因素，如：初期用戶的需求不明確，開發(fā)過程中需求不斷地變化。因?yàn)檫@些變更的發(fā)生不可避免，所以對變更的管理就十分重要。項(xiàng)目的實(shí)踐證明，除了上述要規(guī)范化項(xiàng)目開發(fā)用文檔外，在開發(fā)過程中，在不斷發(fā)生設(shè)計(jì)變更的情況下，要嚴(yán)格保證設(shè)計(jì)文檔與代碼的一致性。

1992年卡內(nèi)基-梅隆大學(xué)的ChristineM.Neuwirth等人，就如何在協(xié)同寫作環(huán)境中發(fā)現(xiàn)和報(bào)告變更的問題，集中討論了三個(gè)方面的問題[2]：（1）應(yīng)該報(bào)告哪些變更？（2）如何表示變更信息？（3）報(bào)告變更信息的界面應(yīng)該如何設(shè)計(jì)？

在已開始編碼后，發(fā)生設(shè)計(jì)書變更時(shí)，設(shè)計(jì)者要評估所涉及到的DB數(shù)據(jù)表以及相關(guān)畫面的相關(guān)項(xiàng)目，并在設(shè)計(jì)書中明確標(biāo)記出來。首先文檔的履歷中要明記變更履歷，在變更履歷中要明記變更的Sheet頁。在每個(gè)變更的Sheet頁中，所變更的文字要用醒目的顏色例如紅色，或用醒目的背景色。刪掉的文字部分用刪除線，追加的記述要用醒目的文字顏色，同時(shí)變更的文檔本身要版本，放在相關(guān)人員都能看到的地方。此外，最好要有變更管理臺(tái)帳，跟蹤變更的對應(yīng)情況。最后最重要的是設(shè)計(jì)書的變更與代碼的變更一定要保持一致。始終保證設(shè)計(jì)書的有效性。

4 實(shí)際開發(fā)案件中設(shè)計(jì)書規(guī)范化對項(xiàng)目影響的分析

如下（圖1）所示，設(shè)計(jì)書書寫的易讀性如何，對最后項(xiàng)目的整體質(zhì)量有一定的影響。設(shè)計(jì)書書寫的不規(guī)范，可讀性差的話，勢必在理解設(shè)計(jì)的過程中，花費(fèi)很多時(shí)間去溝通確認(rèn)，此外也容易帶來理解的誤差。分析交付產(chǎn)品后的缺陷來看，其中一定比例的問題原因是設(shè)計(jì)書理解錯(cuò)誤所造成的。

圖1 實(shí)際開發(fā)案件部分影響質(zhì)量因素的分析結(jié)果

5 結(jié)束語

（1）實(shí)踐證明，項(xiàng)目開發(fā)文檔的規(guī)范化及標(biāo)準(zhǔn)化一定程度上可提高項(xiàng)目的成功率及質(zhì)量。（2）項(xiàng)目開發(fā)文檔的規(guī)范化可提高文檔的可讀性，提高溝通的效率。特別是控制變更及其對應(yīng)文檔的變更，始終保證設(shè)計(jì)書與代碼的一致性，盡管不是保證項(xiàng)目是否能成功的決定條件，但卻是能保證項(xiàng)目成功的必要條件之一。

參考文獻(xiàn)：

[1]陳紹文，精益思想-人，過程和技術(shù)的集成[J].CAD/CAM與制造業(yè)信息化，2002（07）.

[2]胡斌.變更信息管理機(jī)制及其在PDM變更管理中的應(yīng)用[J].中國全文學(xué)位數(shù)據(jù)庫，2004.

第6篇：測試報(bào)告缺陷分析范文

摘 要：隨著計(jì)算機(jī)的廣泛應(yīng)用和計(jì)算機(jī)科學(xué)技術(shù)的不斷發(fā)展，計(jì)算機(jī)系統(tǒng)的組成也相應(yīng)發(fā)生了許多變化，計(jì)算機(jī)軟件的主導(dǎo)作用愈加明顯。軟件工程的進(jìn)一步發(fā)展，給軟件測試及測試管理帶來很大幫助。本文簡要介紹了軟件測試管理的概念、計(jì)劃、活動(dòng)、功能、周期、工作量模型及其應(yīng)用。

關(guān)鍵詞：軟件測試管理；軟件過程；軟件質(zhì)量

1 軟件測試管理的系統(tǒng)活動(dòng)

實(shí)踐證明，對軟件進(jìn)行測試管理可及早發(fā)現(xiàn)錯(cuò)誤，避免大規(guī)模返工，降低軟件開發(fā)費(fèi)用，為確保最終件質(zhì)量符合要求，必須進(jìn)行測試與管理。對于不同企業(yè)的不同類產(chǎn)品、同一企業(yè)的不同類產(chǎn)品、或不同企業(yè)的同一類產(chǎn)品，其各階段結(jié)果的形式與內(nèi)容都會(huì)有很大的不同。所以對于軟件測試管理我們除了要考慮測試管理開始的時(shí)間、測試管理的執(zhí)行者、測試管理技術(shù)如何有助于防止錯(cuò)誤的發(fā)生、測試管理活動(dòng)如何被集成到軟件過程的模型中之外，還必須在測試之前，制訂詳細(xì)的測試管理計(jì)劃，充分實(shí)現(xiàn)軟件測試管理的主要功能，縮短測試管理的周期。

2.1軟件測試管理計(jì)劃

一個(gè)成功的測試開始于一個(gè)全面的測試管理計(jì)劃。因此，在每次測試之前應(yīng)做好詳細(xì)的測試管理計(jì)劃：

首先應(yīng)該了解被測對象的基本信息，選擇測試的標(biāo)準(zhǔn)級別，明確測試管理計(jì)劃標(biāo)識(shí)和測試管理項(xiàng)。在定義了被測對象的測試管理目標(biāo)、范圍后必須確定測試管理所使用的方法，即提供技術(shù)性的測試管理策略和測試管理過程。在測試管理計(jì)劃中，管理者應(yīng)該全面了解被測試對象的系統(tǒng)方法、語言特征、結(jié)構(gòu)特點(diǎn)、操作方法和特殊需求等，以便確定必要的測試環(huán)境，包括測試硬件/軟件及測試環(huán)境的建立等等。由于任何一個(gè)軟件不可能沒有缺陷、系統(tǒng)運(yùn)行時(shí)不出現(xiàn)故障，所以在測試管理計(jì)劃中還必須考慮到一些意外情況，也就是說，當(dāng)問題發(fā)生時(shí)應(yīng)如何處理。因?yàn)闇y試管理具有一定難度，所以對測試管理者應(yīng)進(jìn)行必要的測試設(shè)計(jì)、工具、環(huán)境等的培訓(xùn)。最后，還必須確定認(rèn)可和審議測試管理計(jì)劃的負(fù)責(zé)人員。

2.2軟件測試管理過程

我們對測試過程中每個(gè)狀態(tài)進(jìn)行記錄、跟蹤和管理，并提供相關(guān)的分析和統(tǒng)計(jì)功能，生成和打印各種分析統(tǒng)計(jì)報(bào)表。通過對詳細(xì)記錄的分析，形成較為完整的軟件測試管理文檔，保障軟件在開發(fā)過程中，避免同樣的錯(cuò)誤再次發(fā)生，從而提高軟件開發(fā)質(zhì)量。

2.3軟件測試管理內(nèi)容

具體的測試管理內(nèi)容有：

測試計(jì)劃管理：單元測試、集成測試和系統(tǒng)測試的測試計(jì)劃的錄入、修改、刪除、查詢和打印。

測試用例管理： 測試用例的編號、增加、刪除、修改、拷貝和查詢；對測試用例的測試情況進(jìn)行管理，測試狀態(tài)包括：未測試、測試中、已測試，測試結(jié)果為：通過、未實(shí)現(xiàn)、存在問題等。

問題報(bào)告管理：問題報(bào)告處理流程（問題報(bào)告整改報(bào)告）、實(shí)現(xiàn)問題報(bào)告與測試案例的關(guān)聯(lián)。

測試報(bào)告管理：生成單元測試、集成測試和系統(tǒng)測試的測試報(bào)告。

項(xiàng)目管理：對項(xiàng)目、項(xiàng)目中模塊、用戶及權(quán)限進(jìn)行管理。

通信管理模塊：把測試計(jì)劃、測試用例等測試信息分發(fā)給各測試，同時(shí)接收各測試傳送來的測試結(jié)果。

測試：測試負(fù)責(zé)把測試需求信息接收給測試工具進(jìn)行測試，并把測試結(jié)果發(fā)送給測試管理工程數(shù)據(jù)庫中。

除了以上這些，在測試管理過程中還應(yīng)對人員和環(huán)境資源進(jìn)行管理。

軟件測試管理人員：為了實(shí)現(xiàn)軟件測試管理，需要組成一個(gè)專門的測試管理隊(duì)伍，隊(duì)伍中的人員都能夠勝任他們所擔(dān)任的角色是很重要的。另外，還需確認(rèn)每種角色的人員應(yīng)具有必要的權(quán)利以完成他們的責(zé)任。同時(shí)為了能夠獲得很高的效率，每個(gè)測試管理參與者又都應(yīng)最大限度地發(fā)揮出其最大的技術(shù)能力。

環(huán)境資源包括硬件資源和軟件資源，它們是提供測試管理的基礎(chǔ)。每類資源都可以用四個(gè)特征來說明：資源描述、可用性說明、需要該資源的時(shí)間、及該資源被持續(xù)使用的時(shí)間。

2.4軟件測試管理的主要功能

測試控制對象的編輯和管理：該部分主要是為各測試階段的控制對象提供一個(gè)完善的編輯和管理環(huán)境。

測試流程控制和管理：測試流程的控制和管理是基于科學(xué)的流程和具體的規(guī)范來實(shí)現(xiàn)的，整個(gè)過程避免了測試人員和開發(fā)設(shè)計(jì)人員之間面對面的交流，減少了以往測試和開發(fā)之間難免的摩擦和矛盾，提高了工作效率。

統(tǒng)計(jì)分析和決策支持：在系統(tǒng)建立的測試工程數(shù)據(jù)庫的基礎(chǔ)上，進(jìn)行合理的統(tǒng)計(jì)分析和數(shù)據(jù)挖掘。

2.5軟件測試管理周期

任何程序，無論大小，都可能會(huì)有錯(cuò)誤發(fā)生。每一個(gè)新版本都需要進(jìn)行新特性的測試和其他特性的一些回歸測試。

測試管理人員在接受一個(gè)測試管理任務(wù)后，除了要制定周密的測試管理計(jì)劃，還要進(jìn)行測試方案管理；并且對測試人員所做的測試活動(dòng)予以記錄，做好測試流程的管理。同時(shí)，對發(fā)現(xiàn)的缺陷予以標(biāo)識(shí)，一方面反饋給提交測試的人員；另一方面將存在的問題和缺陷存入案例庫，直至測試通過。

2.6軟件測試管理工作量模型的提出

軟件測試管理所花費(fèi)的工作量一般用于：測試、人員、文檔料等方面的管理。參考Belady和Lehman模型，我們認(rèn)為軟測試管理工作量模型可以是：

M=P+K×e×p（c-d）+O

其中：M―總的軟件測試管理工作量；

P―軟件測試工作量；

K―軟件測試管理經(jīng)驗(yàn)常數(shù)；

c―軟件測試管理復(fù)雜程度；

d―軟件測試管理人員對軟件的熟悉程度的參數(shù)；

O―由于不確定因素而帶來的額外工作量。

從模型可以看出，如果軟件測試管理的方法不好（即軟件測試管理過程過于復(fù)雜），或者軟件測試管理人員對軟件不熟悉，不能充分發(fā)揮他們的技術(shù)能力，那么軟件測試管理的工作量或成本將指數(shù)地增加。

3軟件測試管理的應(yīng)用

軟件測試是一個(gè)完整的體系，主要由測試規(guī)劃、測試設(shè)計(jì)、測試實(shí)施、資源管理等相互關(guān)聯(lián)、相互作用的過程構(gòu)成。軟件測試管理系統(tǒng)可以對各過程進(jìn)行全面控制。具體的實(shí)現(xiàn)過程如下：

1）按照國際質(zhì)量管理標(biāo)準(zhǔn)，建立適合本單位的軟件測試管理體系，以提高本單位開發(fā)的軟件質(zhì)量，并降低軟件開發(fā)及維護(hù)成本；

2）建立、監(jiān)測和分析軟件測試過程，以有效地控制、管理和改進(jìn)軟件測試過程，監(jiān)測軟件質(zhì)量，從而確定交付或軟件的時(shí)間；

3）制定合理的軟件測試管理計(jì)劃，設(shè)計(jì)有效的測試案例集，以盡可能發(fā)現(xiàn)軟件缺陷。并組織、管理和應(yīng)用龐大的測試案例集；

4）在軟件測試管理過程中，管理者、程序員、測試員（含有關(guān)客戶人員）協(xié)同工作，及時(shí)解決發(fā)現(xiàn)軟件問題；

5）對于軟件測試中發(fā)現(xiàn)的大量的軟件缺陷，進(jìn)行合理的分類以分清輕重緩急。同時(shí)進(jìn)行原因分析，并做好相應(yīng)的記錄、跟蹤和管理工作；

6）建立一套完整的文檔資料管理體系。因?yàn)?，軟件測試管理很大程度上是通過對文檔資料的管理來實(shí)現(xiàn)的。軟件測試每個(gè)階段的文檔資料是以后階段的基礎(chǔ)，又是對前面階段的復(fù)審。

4總 結(jié)

軟件質(zhì)量優(yōu)劣直接影響著計(jì)算機(jī)應(yīng)用的深度和V度。因而科學(xué)地對軟件進(jìn)行測試和進(jìn)行軟件測試管理是十分必要的。我們認(rèn)為軟件測試管理已變得越來越重要，我們也將運(yùn)用測試管理工具，對目前正在進(jìn)行的中間件、構(gòu)件庫以及嵌入式軟件測試等科研課題和一些中、大型軟件項(xiàng)目進(jìn)行有序的測試管理，使我們的工作更有特色。所以，只有科學(xué)地進(jìn)行測試管理，才能促進(jìn)軟件開發(fā)、測試單位重視全面質(zhì)量管理、促進(jìn)軟件測試管理隊(duì)伍的成長、促進(jìn)軟件質(zhì)量的提高、進(jìn)一步推動(dòng)軟件測試行業(yè)產(chǎn)業(yè)化過程。

參考文獻(xiàn)

[1] 鄭人杰，計(jì)算機(jī)軟件測試技術(shù)，清華大學(xué)出版社，1992.

第7篇：測試報(bào)告缺陷分析范文

【關(guān)鍵詞】嵌入式 軟件測試 關(guān)鍵技術(shù)

軟件測試是在計(jì)算機(jī)軟件的基礎(chǔ)上發(fā)展起來的，就是在特定條件下對軟件程序進(jìn)行操作，發(fā)現(xiàn)其中存在的問題，實(shí)現(xiàn)對軟件質(zhì)量的評估，為程序的改進(jìn)提供依據(jù)。嵌入式武控計(jì)算機(jī)軟件測試與普通商用軟件測試的原則基本一致，但是由于該種軟件的運(yùn)行環(huán)境比較特殊，要想成功完成測試，就必須為其提供相應(yīng)的硬件環(huán)境。

一、當(dāng)前嵌入式武控計(jì)算機(jī)軟件測試中面臨的問題

現(xiàn)階段，嵌入式計(jì)算機(jī)技術(shù)不斷得到快速發(fā)展，這在很大程度上促使其在社會(huì)生活各個(gè)領(lǐng)域內(nèi)的應(yīng)用也越來越廣泛，且該系統(tǒng)中軟件系統(tǒng)比重及軟件架構(gòu)呈現(xiàn)越來越復(fù)雜的趨勢，引起業(yè)界不斷提升對軟件運(yùn)行可靠性的高度關(guān)注。嵌入式系統(tǒng)是計(jì)算機(jī)、通信、自動(dòng)化控制等技術(shù)高度整合而且產(chǎn)生的產(chǎn)物。嵌入式系統(tǒng)是計(jì)算機(jī)、通信、自動(dòng)化控制技術(shù)三者結(jié)合的產(chǎn)物，在現(xiàn)代計(jì)算機(jī)軟件測試中，得到了較為廣泛的應(yīng)用。武控計(jì)算機(jī)軟件測試過程中，由于其所處環(huán)境較為特殊，軟件測試面臨著較大的困境，如何對這一問題進(jìn)行有效解決，關(guān)系到了武控計(jì)算機(jī)軟件的發(fā)展和應(yīng)用。首先是測試模型的建立問題，要根據(jù)軟件特征建立靈活的、適應(yīng)性強(qiáng)的測試模型，這樣才能對整個(gè)測試過程進(jìn)行正確指導(dǎo)。這不僅要求技術(shù)人員具備較強(qiáng)的專業(yè)知識(shí)，同時(shí)要具備豐富的軟件測試經(jīng)驗(yàn)。

其次是仿真測試平臺(tái)的建立問題，通常情況下測試平臺(tái)的測試任務(wù)是非常艱巨的，且一般都采用實(shí)裝環(huán)境。實(shí)際運(yùn)用過程中發(fā)現(xiàn)，這種環(huán)境存在很多約束，例如，軟件和硬件都是通用設(shè)置，修改起來非常麻煩，這樣在進(jìn)行一些安全性測試時(shí)，軟件無法正常注入，可能會(huì)導(dǎo)致測試不充分，測試結(jié)果不準(zhǔn)確。

第三是內(nèi)存泄露問題，該種軟件的運(yùn)行內(nèi)存有限，一旦發(fā)生內(nèi)存泄露問題，就會(huì)對系統(tǒng)正常運(yùn)行造成影響，嚴(yán)重者可能會(huì)直接導(dǎo)致系統(tǒng)崩潰。在對源代碼進(jìn)行檢查，確定泄露原因時(shí)，一般都需要依靠人工，一方面是檢查量太大，給工作人員帶來較大壓力；另一方面是無法對內(nèi)存分配進(jìn)行動(dòng)態(tài)監(jiān)控，導(dǎo)致測試不充分。

第四是靜態(tài)測試中存在難題，靜態(tài)測試包括很多具體內(nèi)容，不僅要對源代碼的規(guī)則進(jìn)行檢查，同時(shí)需要對各個(gè)度量元進(jìn)行檢查，測試結(jié)果可能不完全準(zhǔn)確，因此需要技術(shù)人員對以上檢測內(nèi)容進(jìn)行進(jìn)一步分析。要求測試人員在分析過程中不斷積累經(jīng)驗(yàn)，完善代碼檢查單，這樣才能在降低工作量的前提下提高測試結(jié)果的準(zhǔn)確性。

最后是覆蓋率測試方面的問題，嵌入式武控計(jì)算機(jī)軟件應(yīng)用時(shí)不僅要具備較高的可靠性，同時(shí)要滿足安全性需求。只有測試充分，才能滿足以上要求，測試過程中盡量使所有程序語句都被執(zhí)行，總結(jié)來說就是要保證測試的覆蓋率。實(shí)際對嵌入式武控計(jì)算機(jī)軟件測試過程中經(jīng)常出現(xiàn)測試覆蓋率不足的問題，其中的某些源代碼語句沒有被執(zhí)行，沒有發(fā)現(xiàn)潛藏在其中的BUG，留下安全風(fēng)險(xiǎn)。測試時(shí)如何提升覆蓋率是技術(shù)人員必須要思考的問題。

二、嵌入式武控計(jì)算機(jī)軟件測試環(huán)境以及特征分析

（一）測試環(huán)境分析

對于嵌入式軟件來說，一般測試環(huán)境主要有三類，每種都有自身的優(yōu)點(diǎn)和缺點(diǎn)：首先是全仿真模擬測試環(huán)境，這種環(huán)境最大的優(yōu)點(diǎn)就是使用起來非常靈活，可以根據(jù)測試需要對數(shù)據(jù)輸入進(jìn)行設(shè)置，且硬件成本不高，可以完成所有的功能性測試和接口測試。缺點(diǎn)是無法實(shí)現(xiàn)性能、余量以及強(qiáng)度測試，且測試過程與實(shí)際運(yùn)用存在一定差距；二是半實(shí)裝仿真測試環(huán)境，這種測試環(huán)境同樣具備較高的靈活性，硬件成本也不高，可以完成所有類型的測試。缺點(diǎn)是測試過程也與實(shí)際運(yùn)用存在一定差距；三是全實(shí)裝測試環(huán)境，這種環(huán)境最大的優(yōu)點(diǎn)就是可以與實(shí)際運(yùn)行環(huán)境保持一致，但是無法輸入異常數(shù)據(jù)，且硬件成本相對較高，大面積應(yīng)用不太切合實(shí)際。根據(jù)運(yùn)行環(huán)境的優(yōu)缺點(diǎn)以及嵌入式武控計(jì)算機(jī)軟件測試要求，本文選擇半實(shí)裝仿真測試環(huán)境。

（二）測試特征研究

與普通軟件測試相比，嵌入式軟件表現(xiàn)出以下幾個(gè)不同特征：首先是軟件要硬件的關(guān)聯(lián)性較大，軟件高Q合于其所運(yùn)行的計(jì)算機(jī)系統(tǒng)，因此其只能在特定的主機(jī)上運(yùn)行，軟件是否能夠按照預(yù)期實(shí)現(xiàn)自身功能、性能，與其所處的硬件環(huán)境有直接關(guān)系。因此，在應(yīng)用這種軟件之前，需要做好配套硬件準(zhǔn)備；其次，該種軟件對實(shí)時(shí)性有較高要求，一般要求在規(guī)定的毫秒級時(shí)間內(nèi)完成任務(wù)，如果任務(wù)較多，則需要按照系統(tǒng)規(guī)定處理時(shí)間順序。為了提高運(yùn)行的可靠性，運(yùn)行過程中不允許出現(xiàn)內(nèi)存泄露問題，因此除了常規(guī)測試以外，還必須對內(nèi)存泄露進(jìn)行測試；第三，為了確保軟件對運(yùn)行環(huán)境的適應(yīng)性，還要在不同強(qiáng)度下開展測試，包括高溫以及強(qiáng)磁場等特殊環(huán)境；最后，該種軟件在開發(fā)過程中采用的是交叉式，開發(fā)程序一般是在通用PC機(jī)上，而軟件開發(fā)完成以后則需要在特定目標(biāo)機(jī)上運(yùn)行，這就是為什么該種軟件測試要更加復(fù)雜的原因，這種復(fù)雜不僅體現(xiàn)在方法上，同時(shí)體現(xiàn)在技術(shù)上。

三、嵌入式武控計(jì)算機(jī)軟件測試方法及關(guān)鍵技術(shù)

（一）基本宿主機(jī)的測試

首先是靜態(tài)分析，分析之前要建立代碼檢查表，表中反應(yīng)的是代碼規(guī)則，檢查表的建立要將軟件編寫規(guī)范作為依據(jù)。然后使用特定的靜態(tài)分析工具對源代碼進(jìn)行檢測，得到分析報(bào)告。如果發(fā)現(xiàn)源代碼中有不符合規(guī)范的地方，要對其進(jìn)行適當(dāng)修正。

其次是代碼審查，審查時(shí)要將以下內(nèi)容作為依據(jù)：一是軟件需求規(guī)格內(nèi)容，二是數(shù)學(xué)模型內(nèi)容，三是通信口協(xié)議文件。以此確定程序是否與需求一直，明確代碼是否按照正確的邏輯表達(dá)，同時(shí)確認(rèn)代碼是否可讀，根據(jù)以上內(nèi)容生成審查報(bào)告。

最后是代碼走查，要建立一個(gè)代碼走查小組，小組中不僅要包含軟件測試人員，同時(shí)要包括軟件開發(fā)人員。準(zhǔn)備好測試用例，要求這些用例具有代表性，代碼走查小組要扮演計(jì)算機(jī)角色，按照程序來執(zhí)行邏輯，同時(shí)執(zhí)行測試用例，這樣就可以發(fā)現(xiàn)被測軟件程序中存在的問題，生成走讀報(bào)告。實(shí)踐證明，代碼走查在基本宿主機(jī)的測試中發(fā)揮重要作用，可以發(fā)現(xiàn)軟件程序中存在的缺陷，有效提高軟件質(zhì)量。統(tǒng)計(jì)表明，在這一環(huán)節(jié)發(fā)現(xiàn)的軟件缺陷占整個(gè)軟件測試中缺陷的40%以上，最高可以達(dá)到60%。

（二）基本目標(biāo)機(jī)的測試

首先是覆蓋率測試，對源代碼進(jìn)行分析插樁，一般使用Mccabe測試工具。之后編譯該程序，一般使用Tonado工具。完成編譯以后將其下載到目標(biāo)機(jī)上，將所有測試用例在該目標(biāo)機(jī)上執(zhí)行，對測試過程中的覆蓋率情況進(jìn)行觀察，然后再對測試數(shù)據(jù)進(jìn)行分析，得到被測試程序的覆蓋情況。如果覆蓋率沒有達(dá)到標(biāo)準(zhǔn)要求，需要繼續(xù)添加測試用例，如果代碼性質(zhì)為不可達(dá)代碼，則需要對不可能覆蓋情況進(jìn)行確認(rèn)，最后得到準(zhǔn)確的覆蓋率測試報(bào)告。

其次是內(nèi)存泄露測試，這是武控計(jì)算機(jī)軟件測試與普通軟件測試中的最大差別，需要對軟件中的內(nèi)存情況以及測試情況進(jìn)行跟蹤，一般需要使用兩個(gè)工具，一是TestBed，二是Klockwork。需要對跟蹤結(jié)果進(jìn)行分析，一旦發(fā)現(xiàn)內(nèi)存泄露，要生成相應(yīng)的內(nèi)存泄露報(bào)告，報(bào)告中還要包含內(nèi)存出錯(cuò)情況。

隨后是確認(rèn)測試，這一測試過程必須在目標(biāo)機(jī)環(huán)境下進(jìn)行，這與該種軟件對硬件環(huán)境的獨(dú)特要求有關(guān)。無論是接口、功能以及性能的實(shí)現(xiàn)，都需要特定的硬件環(huán)境作為支持。仍舊需要提前設(shè)計(jì)、收集相應(yīng)的測試用例，對軟件是否滿足需求進(jìn)行驗(yàn)證，最后生成測試報(bào)告。

四、嵌入式武控計(jì)算機(jī)軟件測試過程模型的建立及應(yīng)用

（一）測試過程模型的特征分析

一般情況下，測試過程模型如果能夠滿足測試需要，一般都具備以下幾個(gè)特征：首先，在分析并確認(rèn)測試需求時(shí)，必須要對每個(gè)需求都進(jìn)行透徹分析，同時(shí)要求技術(shù)人員真確理解這些需求，盡量發(fā)現(xiàn)軟件需求中存在的錯(cuò)誤；其次，在評價(jià)、審核軟件體系結(jié)構(gòu)的過程中要同步建立起一個(gè)性能工程模型，以此判斷軟件的結(jié)構(gòu)是否可以滿足軟件性能要求?？偨Y(jié)以往的軟件測試經(jīng)驗(yàn)，我們會(huì)發(fā)現(xiàn)基本結(jié)構(gòu)不合理是造成軟件性能問題的主要因素，與編碼的效率并無多大關(guān)系；第三，要根據(jù)各個(gè)軟件開發(fā)階段的特征選擇合適的測試方法，在宿主與目標(biāo)測試中間做好平衡；第四，過程模型建立時(shí)，可以引入自動(dòng)化測試工具，實(shí)現(xiàn)測試過程的自動(dòng)化，這樣不僅可以提高測試效率，同時(shí)可以提升測試結(jié)果的準(zhǔn)確性；最后，發(fā)現(xiàn)軟件缺陷并完成修正以后，要對影響域進(jìn)行分析，并根據(jù)測試需要設(shè)計(jì)新的測試用例，完成回歸測試過程，這一環(huán)節(jié)的主要目的是防止修正過程引入新錯(cuò)誤，保證修正環(huán)節(jié)的有效性。

（二）典型軟件測試模型分析及選擇

目前經(jīng)常使用的軟件測試模型主要有V、W、X、H四種，每種模型都有自身的優(yōu)點(diǎn)和缺點(diǎn)。鑒于本文測試過程模型的建立是基于V型和W型的基礎(chǔ)上，因此先對這兩種模型進(jìn)行分析，并提出了改造方法。

（1）V模型分析。該種模型是在開發(fā)瀑布模型的基礎(chǔ)上發(fā)展起來的，模型中的流程采用從左到右的方式，清楚的描述了不同開發(fā)級別以及測試級別，并且明確表達(dá)了各個(gè)階段之間的關(guān)系。V模型最大的優(yōu)點(diǎn)就是將測試明確劃分級別，提高了對測試的重視程度，將軟件開發(fā)過程和測試過程一一對應(yīng)起來。其缺點(diǎn)有以下幾個(gè)：首先，測試工作之后于軟件編碼工作，前者是在后者徹底完成以后才正式開始，這就使很多技術(shù)人員對測試工作形成錯(cuò)誤的理解，認(rèn)為其是軟件開發(fā)工作的最后一步，降低了該項(xiàng)工作的獨(dú)立性，如果早期開發(fā)的結(jié)構(gòu)中存在很大缺陷，就會(huì)造成不可挽回的損失；其次，模型中采用左右分支的形式，導(dǎo)致軟件開發(fā)與測試表現(xiàn)出一種線性關(guān)系，各個(gè)階段的測試工作不能同時(shí)開展；最后，這種模型將重點(diǎn)放在發(fā)現(xiàn)測試階段的問題上，忽視了回歸測試，對軟件進(jìn)行修正以后，很有可能引入新問題。

（2）W模型分析。該種模型是在V模型的基礎(chǔ)上發(fā)展起來的，我們可以將其理解為兩個(gè)“V”過程，分別代表著開發(fā)和測試過程。這種方式提高了測試過程的獨(dú)立性，不再將其作為軟件開發(fā)的一個(gè)環(huán)節(jié)，測試的全面性也有所提升，除了檢驗(yàn)程序代碼之外，還添加了軟件需求測試環(huán)節(jié)。同時(shí)，這種模型強(qiáng)調(diào)了軟件測試的盡早性，一般開發(fā)、一邊測試，及時(shí)發(fā)現(xiàn)結(jié)構(gòu)缺陷并修正。但是W模型也有自身缺陷，所有階段被劃分的非常清晰，必須嚴(yán)格按照要求順序開展需求分析、軟件設(shè)計(jì)以及編碼工作等，這就表示其不支持迭代，不能根據(jù)實(shí)際情況進(jìn)行自發(fā)性調(diào)整。我們知道嵌入式武控計(jì)算機(jī)軟件開發(fā)項(xiàng)目中經(jīng)常出現(xiàn)需求變更情況，導(dǎo)致其缺乏完善的設(shè)計(jì)文檔。

（3）模型改進(jìn)。通過以上分析我們會(huì)發(fā)現(xiàn)，傳統(tǒng)的軟件測試中普遍存在這些問題：測試過程沒有從開發(fā)過程中完全獨(dú)立出來，開發(fā)與測試過程無法同時(shí)展開，或者是程序不具備自我調(diào)整能力。這些都嚴(yán)重影響了測試作用的發(fā)揮，因此，在對傳統(tǒng)模型進(jìn)行改造時(shí)，要重點(diǎn)考慮這些內(nèi)容。V模型和W模型雖然都有缺點(diǎn)，但是在實(shí)際軟件測試中的應(yīng)用仍舊非常廣泛，為了提供這兩種模型的適應(yīng)性，可以從以下幾個(gè)方面做出改進(jìn)：首先，可以將測試活動(dòng)定義為過程，并對測試流程進(jìn)行詳細(xì)說明，之后擴(kuò)展測試對象，明確測試中的各方面要求；其次，不僅要將軟件開發(fā)與測試過程一一對應(yīng)，保證二者之間的同步性，同時(shí)要保證各個(gè)測試階段可以同時(shí)進(jìn)行；第三，將回歸測試添加到模型中去，避免修正后的程序中出現(xiàn)新問題；最后，要考慮到嵌入式模型本身的特征，使過程模型可以滿足嵌入式軟件的測試需要。

（三）嵌入式武控計(jì)算機(jī)軟件測試過程模型的應(yīng)用

將改進(jìn)后的模型應(yīng)用于嵌入式武控計(jì)算機(jī)軟件測試中，會(huì)發(fā)現(xiàn)其優(yōu)于傳統(tǒng)模型。首先，設(shè)計(jì)初期就同步開展需求評審工作，將開發(fā)目標(biāo)與用戶需求保持一致，同時(shí)及時(shí)發(fā)現(xiàn)設(shè)計(jì)缺陷并修正，避免不必要的損失；其次，系統(tǒng)結(jié)構(gòu)設(shè)計(jì)階段同步建立性能工程模型，對軟件性能進(jìn)行分析，而不是等到軟件已經(jīng)設(shè)計(jì)完成后再去發(fā)現(xiàn)這些問題；第三，由于模型中添加了回歸測試環(huán)節(jié)，對于修正后的部分重新進(jìn)行檢測，要求設(shè)計(jì)新的測例，通過動(dòng)態(tài)執(zhí)行保證修正的科學(xué)性，有效防止新的缺陷影響軟件質(zhì)量；第四，測試系統(tǒng)參與軟件的設(shè)計(jì)與評審工作，可以有效避免，可以提升設(shè)計(jì)的合理性，對設(shè)計(jì)、開發(fā)以及測試任務(wù)進(jìn)行合理劃分。最后，采用自動(dòng)化的測試方式可以大大提升測試效率和質(zhì)量，保證測試結(jié)果的全面性和準(zhǔn)確性。

五、總結(jié)

嵌入式武控計(jì)算機(jī)軟件要求在特定主機(jī)上運(yùn)行，這就為測試工作帶來麻煩。本文主要分析了針對這種軟件的測試方法，對V模型和W模型進(jìn)行改造，將改造后的模型應(yīng)用于實(shí)際測試中，可以有效提高測試質(zhì)量和效率，因此認(rèn)為該種測試模型值得推廣應(yīng)用。

參考文獻(xiàn)：

[1]苗中華，陸鳴超.基于虛擬儀器技術(shù)的采棉機(jī)智能監(jiān)控系統(tǒng)開發(fā)與應(yīng)用[J].農(nóng)業(yè)工程學(xué)報(bào)，2014.

[2].王金波，張濤.基于故障注入的嵌入式軟件安全性測試框架及實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用研究，2012.

[3]劉利枚，汪文勇.嵌入式軟件測試方法與技術(shù)[J].計(jì)算機(jī)與現(xiàn)代化，2005.

第8篇：測試報(bào)告缺陷分析范文

關(guān)鍵詞：高等職業(yè)教育；課程設(shè)計(jì)；校企合作；軟件測試

DOIDOI：10.11907/rjdk.162329

中圖分類號：G434

文獻(xiàn)標(biāo)識(shí)碼：A文章編號：1672-7800（2016）012-0197-03

0 引言

隨著軟件技術(shù)在社會(huì)各領(lǐng)域的廣泛應(yīng)用，人們開始越來越關(guān)注軟件產(chǎn)品質(zhì)量，軟件測試作為軟件質(zhì)量保證的重要途徑也因此受到行業(yè)領(lǐng)域的關(guān)注與重視，軟件測試崗位的就業(yè)前景也變得越來越好。在《國務(wù)院關(guān)于加快發(fā)展現(xiàn)代職業(yè)教育的決定》中，提出“深化產(chǎn)教融合、校企合作”[1]。隨著技術(shù)的發(fā)展、產(chǎn)業(yè)結(jié)構(gòu)調(diào)整的不斷加快，持久深入的校企合作已經(jīng)逐漸成為高職院校課程開發(fā)質(zhì)量的關(guān)鍵要素之一。

《軟件測試基礎(chǔ)》課程大多在高職院校的計(jì)算機(jī)類專業(yè)中開設(shè)，但是普遍存在著課程內(nèi)容更新慢，教學(xué)方法、手段陳舊，課程評價(jià)考核單一的問題，導(dǎo)致學(xué)生學(xué)習(xí)興趣不大，學(xué)習(xí)效果不佳。該課程在蘇州健雄職業(yè)技術(shù)學(xué)院是軟件技術(shù)專業(yè)的一門專業(yè)基礎(chǔ)課，該院與上海博為峰軟件技術(shù)股份有限公司、上海澤眾軟件科技有限公司等從事軟件測試的IT企業(yè)緊密合作，對課程進(jìn)行了一系列建設(shè)和改革，培養(yǎng)了一大批軟件測試人才，受到企業(yè)的一致認(rèn)可。

1 以工作過程為導(dǎo)向的課程設(shè)計(jì)

課程組成員結(jié)合計(jì)算機(jī)等級考試、計(jì)算機(jī)軟件專業(yè)技術(shù)資格考試和國際軟件測試資質(zhì)認(rèn)證（ISTQB）的考試大綱，以及行業(yè)、企業(yè)對軟件測試員的人才需求，與企業(yè)專家共同確定本課程的目標(biāo)為：使學(xué)生了解軟件測試的發(fā)展前景，掌握測試的基礎(chǔ)知識(shí)，了解測試用例的概念、意義；能夠搭建測試環(huán)境，掌握常用的黑盒、白盒用例設(shè)計(jì)方法，能夠進(jìn)行簡單的手動(dòng)功能測試并撰寫測試報(bào)告與缺陷報(bào)告；了解常用的自動(dòng)化測試工具、性能測試工具，理解測試工具的原理，了解測試管理的概念與流程等。

本課程以軟件測試工程師的工作過程為導(dǎo)向，按照軟件技術(shù)專業(yè)培養(yǎng)目標(biāo)與高職學(xué)生的特點(diǎn)，將測試基礎(chǔ)知識(shí)、相關(guān)技術(shù)方法、測試管理貫穿在整個(gè)測試流程中，從而構(gòu)建測試各階段所需的知識(shí)與技能。在課程中以“虛擬公司”作為組織形式，在運(yùn)作過程中充分體現(xiàn)職業(yè)教育行為導(dǎo)向和職業(yè)性原則。行為導(dǎo)向，即創(chuàng)造師生互動(dòng)的仿真情境，使學(xué)生通過自主協(xié)作式學(xué)習(xí)方式，反復(fù)操練，從而形成符合企業(yè)要求的行為方式和職業(yè)能力。職業(yè)性原則，即要求實(shí)訓(xùn)目標(biāo)和就業(yè)目標(biāo)高度一致[2]。學(xué)院與企業(yè)共建實(shí)訓(xùn)平臺(tái)，通過具體工程項(xiàng)目及案例素材，使用測試管理工具從測試需求建起，測試模塊劃分、測試用例設(shè)計(jì)、測試用例執(zhí)行、缺陷管理，加強(qiáng)學(xué)生對測試管理工具的使用。

2 以工作項(xiàng)目為載體的學(xué)習(xí)情境創(chuàng)設(shè)

《軟件測試基礎(chǔ)》課程最好在第三學(xué)期開設(shè)，因?yàn)檫@時(shí)學(xué)生對軟件行業(yè)已有一定了解，并已具備初步的編程經(jīng)驗(yàn)，課程共計(jì)64學(xué)時(shí)。依據(jù)軟件測試的工作過程可以將課程劃分為6個(gè)學(xué)習(xí)情境，共15個(gè)工作任務(wù)，具體如表 1所示。

學(xué)習(xí)情境1中主要讓學(xué)生認(rèn)識(shí)缺陷并知道缺陷產(chǎn)生的原因，掌握軟件測試的定義、目的、分類和原則，熟悉V模型、W模型、H模型等軟件測試的常見模型；熟練掌握軟件質(zhì)量模型的分類和各個(gè)評價(jià)指標(biāo)，并明確軟件質(zhì)量與軟件測試之間的關(guān)系；會(huì)查詢互聯(lián)網(wǎng)中的招聘信息，分析軟件測試工程師的崗位職責(zé)及發(fā)展路徑，并盡早做好職業(yè)生涯規(guī)劃。

學(xué)習(xí)情境2中讓學(xué)生能夠明確軟件測試的依據(jù)，并閱讀需求規(guī)格說明書，理解測試需求的概念，會(huì)對測試需求進(jìn)行挖掘；能夠理解測試計(jì)劃的重要性，知道測試計(jì)劃的一般組成要素。

學(xué)習(xí)情境3中讓學(xué)生能夠理解黑盒測試、白盒測試、灰盒測試的基本概念及它們之間的區(qū)別與聯(lián)系；能夠靈活地運(yùn)用黑盒測試的常用方法，如等價(jià)類劃分、邊界值、決策表、因果圖、場景法、正交表等來設(shè)計(jì)測試用例；能夠靈活地運(yùn)用白盒測試的常用方法，如邏輯覆蓋法、基本路徑法等設(shè)計(jì)測試用例。

學(xué)習(xí)情境4中讓學(xué)生學(xué)會(huì)測試環(huán)境的搭建，如在虛擬機(jī)中部署PHP、JSP、.NET等應(yīng)用程序；理解單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的概念及基本流程，熟悉集成測試的策略，能夠使用JUnit 等工具來開展單元測試；能夠掌握缺陷的概念，會(huì)正確記錄缺陷，掌握缺陷報(bào)告的基本格式與內(nèi)容。

學(xué)習(xí)情境5中要讓學(xué)生理解測試總結(jié)的意義和重要性，并了解測試總結(jié)報(bào)告的格式與內(nèi)容。

學(xué)習(xí)情境6中能讓學(xué)生掌握手動(dòng)測試與自動(dòng)化測試的區(qū)別，了解自動(dòng)化測試、性能測試等工具的原理，初步掌握腳本的錄制和參數(shù)的設(shè)定，為后續(xù)課程的學(xué)習(xí)奠定基礎(chǔ)。

3 “互聯(lián)網(wǎng)+教育”方式的課程改革深化

3.1 利用雨課堂平臺(tái)實(shí)施線上線下混合教學(xué)

合理運(yùn)用互聯(lián)網(wǎng)新技術(shù)，由傳統(tǒng)教學(xué)向線上線下混合式教學(xué)方式轉(zhuǎn)變，打破以往學(xué)生學(xué)習(xí)時(shí)空的限制，按需學(xué)習(xí)，讓教育教學(xué)資源得到最大化共享。由于本課程概念較多，課程學(xué)習(xí)后還需通過工信部的考證，線上教學(xué)教師通過清華大學(xué)研制的雨課堂平臺(tái)將PPT課件、微課、測試等資料上傳至云空間，并推送到學(xué)生的移動(dòng)終端上，督促學(xué)生做好預(yù)習(xí)、復(fù)習(xí)工作，學(xué)生所有的學(xué)習(xí)行為數(shù)據(jù)均被自動(dòng)完整采集，有助于量化了解學(xué)生學(xué)習(xí)效果并把握學(xué)生學(xué)習(xí)軌跡[3]；傳統(tǒng)的線下面授，則重點(diǎn)解決學(xué)生的疑難困惑問題，提高教學(xué)效率。

3.2 改進(jìn)教學(xué)方法提高學(xué)生學(xué)習(xí)興趣

第9篇：測試報(bào)告缺陷分析范文

關(guān)鍵詞：工程咨詢 信息系統(tǒng) 軟件測試

信息是現(xiàn)代咨詢的基礎(chǔ)，工程咨詢業(yè)俗稱為“頭腦加工信息”的行業(yè)。在信息化建設(shè)不斷推進(jìn)的條件下，工程咨詢作為智力服務(wù)型企業(yè)，對信息化的需求日益增長。為了把咨詢業(yè)務(wù)做精、做強(qiáng)、做大，必須依靠現(xiàn)代科技手段和信息處理技術(shù)，建立企業(yè)內(nèi)部信息庫，挖掘信息資源，改變信息管理方式。把零散的、隨機(jī)的信息管理，轉(zhuǎn)變?yōu)橄到y(tǒng)的、可持續(xù)性的、能夠便捷查詢和充分共享的信息管理，實(shí)現(xiàn)咨詢依據(jù)可靠、信息來源充分、方法科學(xué)的現(xiàn)代咨詢發(fā)展目標(biāo)。工程咨詢信息系統(tǒng)，滿足了工程咨詢對信息化的需求，實(shí)現(xiàn)了項(xiàng)目管理及圖書等資料借閱的自動(dòng)化管理方式，建立的競爭情報(bào)管理系統(tǒng)實(shí)現(xiàn)了目標(biāo)信息的定時(shí)抓取，上傳企業(yè)內(nèi)部公告等多種功能。在開發(fā)一套好的工程咨詢信息系統(tǒng)過程中，軟件的測試是非常重要的，它對信息系統(tǒng)能否投入運(yùn)行起著至關(guān)重要的作用，軟件測試環(huán)節(jié)是保障軟件質(zhì)量的最后一道關(guān)鍵性關(guān)口。在軟件的測試中，一定要針對工程咨詢的特點(diǎn)，做好軟件的測試。

一、工程咨詢的特點(diǎn)

工程咨詢業(yè)是智力服務(wù)性行業(yè)，運(yùn)用多種學(xué)科知識(shí)和經(jīng)驗(yàn)、現(xiàn)代科學(xué)技術(shù)管理方法，遵循獨(dú)立、科學(xué)、公正的原則，為政府部門和投資者對經(jīng)濟(jì)建設(shè)和工程項(xiàng)目的投資決策與實(shí)施提供咨詢服務(wù)，以提高宏觀和微觀的經(jīng)濟(jì)效益。工程咨詢具有以下特點(diǎn)：工程咨詢業(yè)務(wù)范圍彈性很大，可以是宏觀的、整體的、全過程的咨詢，也可以是某個(gè)問題、某項(xiàng)內(nèi)容、某項(xiàng)工作的咨詢；每一項(xiàng)工程咨詢?nèi)蝿?wù)都是一次性的、單獨(dú)的任務(wù)、只有類似，沒有重復(fù)；工程咨詢是高度智能化的服務(wù)，需要多學(xué)科知識(shí)、技術(shù)、經(jīng)驗(yàn)、方法和信息的集成及創(chuàng)新；工程咨詢牽涉面廣；許多工程咨詢成果具有預(yù)測性、前瞻性；工程咨詢提供智力服務(wù)，咨詢成果屬非物質(zhì)產(chǎn)品。

二、軟件測試的目的

軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程；測試是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)誤；一個(gè)好的測試是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；一個(gè)成功的測試是發(fā)現(xiàn)了至今為止未發(fā)現(xiàn)的錯(cuò)誤的測試。

軟件測試的目的不僅僅是為了發(fā)現(xiàn)程序中存在的錯(cuò)誤，它還是軟件質(zhì)量保證至關(guān)重要的一個(gè)環(huán)節(jié)。軟件測試不同于程序員在代碼編寫完成后簡單的使用、調(diào)試，軟件測試需要遵循一定的原則，軟件測試的原則大致包括以下內(nèi)容：確定預(yù)期輸出是測試必不可少的一部分，程序員應(yīng)避免測試自己編寫的程序，程序設(shè)計(jì)機(jī)構(gòu)不應(yīng)測試自己的程序，徹底檢查每一個(gè)測試結(jié)果，對非法的和非預(yù)期的情況也要象對合法的預(yù)期輸入一樣編寫測試用例，檢查程序是否做了要它做的事僅僅是成功的一半，另一半是程序是否做了不要它做的事，除了真正沒有用的程序外，一定不要扔掉測試用例，一段程序中存在錯(cuò)誤的概率與在這段程序中已發(fā)現(xiàn)的錯(cuò)誤成比例，在規(guī)劃測試時(shí)，不要設(shè)想程序中不會(huì)查出錯(cuò)誤，所有的測試都應(yīng)當(dāng)追溯到用戶需求，應(yīng)該在測試工作真正開始前就開始計(jì)劃測試，測試應(yīng)該從“小規(guī)?！遍_始逐步轉(zhuǎn)到“大規(guī)?！保瑴y試發(fā)現(xiàn)錯(cuò)誤中80%的錯(cuò)誤屬于20%的程序模塊，窮舉測試是不可能的，但充分覆蓋程序邏輯是可能的，測試是一件非常復(fù)雜，具有創(chuàng)造性的和需要高度智慧的挑戰(zhàn)性任務(wù)。

三、軟件測試幾點(diǎn)看法

軟件測試作為軟件上線的最后關(guān)口，應(yīng)得到高度重視。但由于思想意識(shí)和歷史原因，出現(xiàn)重開發(fā)輕測試的現(xiàn)象，軟件測試成為制約軟件成功上線運(yùn)行的瓶頸。由于對軟件測試的重要性理解不夠，很多人認(rèn)為程序能夠運(yùn)行基本上就已經(jīng)成功，沒有必要進(jìn)行專門的測試，這些都是錯(cuò)誤的觀點(diǎn)。

軟件測試分為：單元測試（模塊測試），集成測試。在進(jìn)行所有的測試前，一定先要認(rèn)真閱讀各種相關(guān)文檔，同時(shí)制定測試計(jì)劃，同時(shí)進(jìn)行測試用例設(shè)計(jì)，在設(shè)計(jì)測試用例時(shí)，要對待測軟件進(jìn)行分析，設(shè)計(jì)合理的模型，制定測試用例。在測試進(jìn)行過程中，要根據(jù)實(shí)際情況修改或增加測試用例。

在測試完成后，要根據(jù)測試結(jié)果填寫《軟件測試問題跟蹤單》，在整個(gè)軟件測試完成后，要分析測試結(jié)果并編寫測試報(bào)告。在測試報(bào)告中要說明本次測試的結(jié)果，如各個(gè)等級的BUG的數(shù)目，在各個(gè)模塊中的分布情況及評語。在整個(gè)項(xiàng)目完成后，將測試工作所產(chǎn)生的所有文檔交文檔管理員歸檔。

軟件測試是為了擬制缺陷。作為衡量和評價(jià)的手段，測試是質(zhì)量控制的核心環(huán)節(jié)，除發(fā)現(xiàn)問題外，測試還有預(yù)防的潛力。

軟件測試是對軟件產(chǎn)品是否能夠滿足預(yù)期要求做出客觀的技術(shù)性評價(jià)。固然品質(zhì)是制造出來的，而不是檢驗(yàn)出來的。但是，軟件測試在明確和界定清楚測試與開發(fā)的關(guān)系時(shí)，不能簡單地把測試與開發(fā)看作是串行的過程。從工作流程看，測試應(yīng)當(dāng)從需求分析開始，測試不僅要與開發(fā)平行，而且從開始就以測試用例為需求立定客觀標(biāo)準(zhǔn)。從目前實(shí)際和發(fā)展趨勢看，規(guī)范化的軟件測試要盡早介入項(xiàng)目開發(fā)，介入越早，糾錯(cuò)越快，軟件質(zhì)量和效果可控越好。

面對信息化速度加快，全球化進(jìn)程加速，市場化程度加深，城市化趨勢加強(qiáng)所帶來的機(jī)遇和挑戰(zhàn)，一個(gè)信息系統(tǒng)軟件對工程咨詢機(jī)構(gòu)提高工作效率起著重要的作用，而軟件的測試又是對軟件能否成功上線運(yùn)行起著至關(guān)重要的作用，因此，工程咨詢業(yè)應(yīng)高度重視信息系統(tǒng)軟件的測試工作。