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

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

第1篇：測試報告缺陷分析范文

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

0　引言

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

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

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

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

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

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

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

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

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

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

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

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

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

2　BOSATF功能模塊

2.1　測試用例管理

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

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

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

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

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

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

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

2.4　測試執(zhí)行管理

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

2.5　場景恢復(fù)模塊

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

2.6　缺陷管理模塊

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

2.7　測試報告模塊

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

2.8　測試機群管理模塊

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

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

3　結(jié)論

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

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

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

參考文獻：

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

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

第2篇：測試報告缺陷分析范文

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

1 引言

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

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

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

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

2.1 單元測試

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

2.2 集成測試

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

2.3確認測試

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

2.4 系統(tǒng)測試

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

2.5 驗收測試

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

2.6 回歸測試

伴隨著軟件生命周期中的任何一個階段，還有一個重要的測試環(huán)節(jié)是回歸測試。只要軟件發(fā)生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發(fā)現(xiàn)了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊。

3 案例分析及研究

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

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

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

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

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

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

驗收測試流程圖：

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

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

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

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

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

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

4總結(jié)與展望

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

參考文獻

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

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

第3篇：測試報告缺陷分析范文

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

中圖分類號：TP306　文獻標識碼：A　文章編號：1672-3198(2009)12-0296-02

1　軟件性能測試

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

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

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

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

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

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

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

2　軟件性能測試流程

2.1　測試方案設(shè)計

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

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

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

2.3　測試場景開發(fā)

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

2.4　測試執(zhí)行

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

2.5　測試報告和分析

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

2.6　回歸測試

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

3　軟件性能測試工具LoadRunner

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

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

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

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

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

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

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

型。

①Manual Scenario：該項要完全手動的設(shè)置場景，這項下面還可以設(shè)置為每一個腳本分配要運行的虛擬用戶的百分比，可在Controller的Scenario菜單下設(shè)置。

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

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

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

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

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

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

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

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

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

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

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

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

第4篇：測試報告缺陷分析范文

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

1系統(tǒng)實現(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窗體；否則信息提示無此用戶。

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

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方法把查詢到的記錄傳到顯示的頁面。同時通過this.setUrl（"user/userlist.jsp"）；方法指定傳回到具體指定的是哪個JSP頁面。通過這樣實現(xiàn)對數(shù)據(jù)查詢功能的實現(xiàn)，同時在該用戶列表頁面定義了對戶籍信息的增加，修改，刪除等操作。

1.5戶口注銷

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

public class Zhuxiao implements Serializable{

private static final long serialVersionUID = 7141419035239709511L；

private long id；

private int type；

2 系y測試與運行

2.1測試概述

2.1.1測試目的

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

2.1.2測試內(nèi)容

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

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

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

2.2測試分析

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

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

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

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

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

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

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

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

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

參考文獻：

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

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

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

作者簡介：

第5篇：測試報告缺陷分析范文

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

中圖分類號：TP311.5

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

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

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

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

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

2 軟件開發(fā)文檔

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

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

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

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

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

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

3 設(shè)計書樣式

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

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

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

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

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

A≠zero and A≠space

B=0 and C=0

D=zero or D=space

X0

日付yyyy0401

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

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

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

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

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

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

' 概要

' xxxxx

' 參數(shù)的說明

' ARG1 ： 參數(shù)1

' ARG2 ： 參數(shù)2

' 功能說明

' 使用方法說明

' 返回值

' xx 型

' 補充說明

' 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è)計書的構(gòu)成。以下是設(shè)計書的Sheet頁的構(gòu)成示例（見圖4）。

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

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

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

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

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

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

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

表5 畫面項目設(shè)計樣例

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

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

O：輸出項目

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

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

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

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

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

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

5 結(jié)束語

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

參考文獻：

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

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

第6篇：測試報告缺陷分析范文

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

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

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

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

2.1軟件測試管理計劃

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

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

2.2軟件測試管理過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5軟件測試管理周期

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

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

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

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

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

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

P―軟件測試工作量；

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

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

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

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

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

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

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

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

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

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

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

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

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

4總 結(jié)

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

參考文獻

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

第7篇：測試報告缺陷分析范文

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

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

一、當前嵌入式武控計算機軟件測試中面臨的問題

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

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

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

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

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

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

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

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

（二）測試特征研究

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

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

（一）基本宿主機的測試

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

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

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

（二）基本目標機的測試

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

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

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

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

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

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

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

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

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

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

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

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

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

五、總結(jié)

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

參考文獻：

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

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

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

第8篇：測試報告缺陷分析范文

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

DOIDOI：10.11907/rjdk.162329

中圖分類號：G434

文獻標識碼：A文章編號：1672-7800（2016）012-0197-03

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第9篇：測試報告缺陷分析范文

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

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

一、工程咨詢的特點

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

二、軟件測試的目的

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

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

三、軟件測試幾點看法

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

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

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

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

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

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