前言：中文期刊網精心挑選了軟件測試報告范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。

軟件測試報告范文1

【關鍵詞】軟件測試 測試報告 測試流程

1 引言

軟件測試是軟件開發過程的重要組成部分，是用來確認一個產品的品質或性能是否符合開發之前所提出的要求。對軟件需求分析、設計規格說明和編碼的最終復審，某種程度上測試工作的好壞直接影響了軟件產品的交付和用戶的滿意度。因此，如何做好測試工作，使測試在軟件工程中順利進行，輔助軟件開發工作是我們每個軟件人員應該考慮的問題。

2 軟件測試的目的

（1）確認軟件的質量，確認軟件做了你所期望的事情，確認軟件以正確的方式來做了這個事件。

（2）提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。

（3）軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

3 軟件測試的對象

軟件測試并不等于程序測試。軟件測試應該貫穿整個軟件定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟件測試的對象。

4 軟件測試流程

軟件測試工作并不是在軟件代碼開發完畢后才開始的，這一點是很多軟件人員的誤區，需要明確一下，它其實是在項目進入軟件實現階段就開始了，項目進入軟件實現階段的時候，就應該啟動軟件測試工作了。

下面根據筆者的測試經驗，詳細闡述一下軟件測試的流程、每個階段需要做的工作及整個測試過程產生的文檔。

4.1 計劃與設計階段

4.1.1 召開測試啟動會議

當項目進入軟件實現階段（編碼），測試經理召集項目經理、開發經理開會確定測試交接時間，開發團隊與測試團隊交接測試內容，對測試目標達成一致，商討測試計劃的可行性，統一項目組的目標和測試的工作重點。進行規模預估并成立測試團隊，完成《測試計劃》和《測試方案》。

4.1.2 設計測試用例

明確了測試需求和測試計劃，在需求分析文檔確立基線以后，測試組需要針對測試需求編寫全部測試用例，在實際的測試中，測試用例將是唯一實施標準。

4.2 實施測試階段

4.2.1 實施測試用例

實施測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。當測試用例全部編寫完成后，測試工程師根據測試計劃中分配給自己的測試任務，實施相應的測試用例，并記錄測試結果。

4.2.2 填寫測試記錄

測試人員在進行具體的測試工作時，需要將測試內容填寫在測試記錄表中，直到所有的測試執行工作結束。

4.2.3 提交BUG清單

在具體的測試過程中，測試人員發現BUG后，需要將BUG記錄在清單里，并及時提交給測試經理。

4.2.4 提交測試報告

在約定的測試周期完成之后，測試工程師需要總結此測試的結果，編寫測試報告。測試工程師根據此輪測試的結果，編寫測試報告，主要應包含以下內容：

（1）測試報告的版本。

（2）測試的人員和時間。

（3）測試所覆蓋的缺陷――測試組在這輪測試中所有處理的缺陷， 不僅要寫出覆蓋缺陷的總數，還要寫明這些缺陷的去向。

（4）上一版本活動缺陷的數量。

（5）經過此輪測試，所有活動缺陷的數量及其狀態分類。

（6）測試評估――寫明在這一版本中，哪些功能被實現了，哪些還沒有實現，這里只需寫明和上一版本不同之處即可。

（7）急待解決的問題――寫明當前項目組中面臨的最優先的問題，可以重復提出。

在每輪測試結束之后應盡快將符合標準的測試報告發給測試經理。

4.3 總結階段

測試工作結束或即將結束時，測試組就要開始著手準備進行總結的工作。

4.3.1 編寫測試總結報告

在測試結束之后，測試經理編寫測試報告，對測試進行總結，并且提交給項目經理，為產品的后續工作提供重要的信息支持。

測試經理根據測試的結果及測試工程師提交的測試報告編寫測試總結報告，測試總結報告必須包含以下重要內容：

（1）測試資源概述―多少人、多長時間。

（2）測試結果摘要―分別描述各個測試需求的測試結果，產品實 現了哪些功能點，哪些還沒有實現。

（3）缺陷分析―按照缺陷的屬性分類進行分析。

（4）測試需求覆蓋率―原先列舉的測試需求的測試覆蓋率，可能 一部分測試需求因為資源和優先級的因素沒有進行測試，那么 在這里要進行說明。

（5）測試評估―從總體對項目質量進行評估。

（6）測試組建議―從測試組的角度為項目組提出工作建議。

4.3.2 測試驗收

測試驗收工作是在以上工作全部結束后，測試經理對測試的過程、效果進行驗收，簽發測試驗收報告，宣布測試結束。由測試經理進行測試驗收，驗收內容包括：

（1）測試效果驗收―測試是否達到預期目的。

（2）測試文檔驗收―測試過程文檔是否齊全，符合標準。

（3）測試評估―從總體對測試的質量進行評估。

（4）測試建議―對本次測試工作指出不足，需要在以后工作中改 進的地方。

（5）宣布測試結束―測試組成員簽字宣布本次測試結束。

4.3.3 測試歸檔

測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸檔，主要包括測試計劃、測試用例、測試報告、驗收報告等。這些文檔的編寫保障了測試的順利進行，同時作為整個測試項目的痕跡，被保留下來，供查閱。

參考文獻

[1]佟偉光.軟件測試[M].北京：人民郵電出版，2008.

[2]Rex Black.測試流程管理[M].北京：北京大學出版社，2001.

[3]Robert V.Binder著，華慶一等譯.面向對象系統的測試[M].北京：人民郵電出版社，2001.

[4]Mark Fewster， Dorothy Graham著，舒智勇等譯.軟件測試自動化技術與實例詳解[M].北京：電子工業出版社，2000.

[5]Karl E.Wiegers著，陸麗娜，王忠民，王志敏譯.軟件需求[M].北京：機械工業出版社，2000.

軟件測試報告范文2

 

 

一、 測試組組成測試組由測試組長和測試工程師組成。

二、 測試組工作職責負責理解軟件產品的功能要求，搭建配套的測試環境，然后 對其進行系統測試，檢查軟件有沒有錯誤 (Bug)，決定軟件是否 具有穩定性 (Robustness)，并寫出相應的測試用例、各階段測試 報告。

（一）  測試組長工作職責： 

1、 協調測試組與各個項目組之間的流程及工作關系；

 

2、 對各個項目的測試工作進行統籌安排，并對各個項目的 測試工作進行計劃、分工和管理；

3、 定期或不定期與各個項目負責人溝通項目進度，隨時了 解項目進展情況；

4、 對測試組成員的日常工作進行評審考核；

 

5、 定期或不定期向部門總監匯報工作情況；

 

6、 參與日常的軟件測試工作。

 

（二）  測試工程師工作職責： 

1、 仔細閱讀項目規格說明、設計文檔、使用說明書等，充 分掌握軟件的性能、特點、使用方法、業務流程等，協 助測試組長制定項目的測試計劃；

2、 依據項目要求，搭建相應的測試環境，維護測試設備；

 

3、按照測試計劃編寫測試用例，保證測試用例合理有效；

 

4、 根據測試計劃及測試案例，執行測試，并根據產品特點 及測試要求，實施集成測試、系統測試等，及時發現軟 件缺陷，評估軟件的特性與缺陷；

5、 詳細記錄測試過程，編寫測試報告和對測試結果進行分 析，通過測試，掌握軟件具有的能力、缺陷、局限等， 對軟件質量給出評價性的結論與意見，整理測試文檔， 填寫軟件測試報告,編寫測試總結，為軟件開發成果提供 總結性意見；

6、 配合研發部門各項軟件產品，并詳細編寫產品 通知單；

7、 完成上級及部門其他領導交辦的臨時任務。

三、 測試組工作流程測試組的工作與項目開發進度緊密相關，所以測試的工作流 程依據開發進度分階段進行大致分為以下幾個階段：

（一）  計劃和設計階段 

1、 項目組成立時，確定項目需求及項目設計方案，了解軟 件產品的主體功能及實現目的；

2、 項目經理下發測試預通知，通知內容包括：正式交接測 試時間、測試規模預計估算等信息；

3、 召開測試啟動會議，會議內容包括：開發團隊與測試組 交接測試內容，對測試目標達成一致，商討測試計劃，

 

統一項目組的目標和測試的工作重點；

 

4、 編寫測試計劃及相關文檔，依據測試啟動會議中確定的 目標和重點，結合項目經理下發的《測試任務書》，編寫

《測試計劃書》（見附件一）。計劃書的內容應該包括：

 

l測試需求：需要測試組測試的范圍，估算出測試所花 費的人力資源和各個測試需求的測試優先級；

l測試方案：整體測試的測試方法和每個測試需求的測 試方法；

l測試資源：本次測試所需要的人力、軟件、硬件及技 術資源；

l   測試組角色：明確測試組人員的工作內容及相關職責；

l里程碑：明確項目進行過程中的測試組應該關注的里 程碑；

l文檔報告：確定在項目測試過程中需要提交的測試計 劃，測試報告等；

l測試計劃編寫完畢后，需提交給全體項目組成員，由 項目成員綜合評審后，確定最終《測試計劃書》（見 附件二）。項目經理要以此為依據，跟蹤監控項目測 試進度，評估測試計劃的可行性，完整性，并且在項 目結束后評估測試質量。

5、 設計測試用例，依據《測試計劃書》相關內容，根據每 一步測試計劃編寫全部的測試用例，測試用例必須能滿

 

足全部的測試需求。

 

（二）  測試實施階段 

1、 實施測試用例，測試工程師依據《測試計劃書》中分配 的測試任務和測試用例，實施相應的測試工作，并詳細 記錄測試過程及結果。

2、 提交測試報告，在實施測試用例的過程中，依據記錄的 測試過程和結果，填寫《測試報告書》，并由測試組長審 批后，上報項目經理。項目經理安排開發組修改相應的 軟件產品。測試報告內容包括：測試產品版本、測試人 員、測試時間、測試過程、產品運行BUG、產品缺陷狀態、 急待解決的問題。

3、 回歸測試，接到開發組的回歸測試通知后，測試組重新 拷貝修改后的最新版本，進行回歸測試。回歸測試的用 例屬于測試用例的一部分或者全部測試用例，但不能超 出測試用例的范圍。

（三）  測試總結階段 

1、 編寫測試總結報告：回歸測試全部通過完成后，由測試 組長整理填寫《測試總結報告》，報告主要內容包括： 測試資源描述——參與測試人數，耗用測試時間； 測試結果摘要——描述各個測試需求的測試結果和功能 實現情況； 缺陷分析——按照缺陷的屬性分類進行分析；

測試需求覆蓋率——如果在測試過程中未覆蓋到的測試 需求，在此應詳細說明原因； 測試評估——對此次項目質量進行評估； 測試組建議——從測試組角度為項目組提出工作建議。

2、 測試驗收：項目經理收到測試組長提交的測試總結報告 后，對此次測試工作進行驗收。驗收內容包括：測試效 果驗收、測試文檔驗收、測試工作評估、測試工作建議， 簽字驗收后，宣布此次測試結束。

3、 測試文檔歸檔：測試驗收結束后，對測試過程中涉及到 的各種標準文檔進行歸類、存檔。相關文檔包括：測試 任務書、測試計劃書、測試用例、測試報告書、測試總 結報告、測試驗收報告等。

 

 

（四）  產品階段 

軟件測試報告范文3

關鍵詞： 軟件測試； 自動化； 自動化測試； 測試工具； 可擴展標記語言技術

中圖分類號： TP 31文獻標識碼： Adoi： 10.3969/j.issn.10055630.2013.02.004

引言隨著計算機應用日益普及和深化，用戶對軟件的需求越來越多，對軟件要求也總是在不斷變化[1]。AutoCAD產品在軟件國際化的過程中，每次修改都需要對大量的測試用例進行反復測試，還要在不同語言版本的操作系統平臺上測試，這就使得該項目的測試工作極為繁瑣。軟件自動化測試作為保證軟件質量和可靠性的關鍵技術手段，正日益受到廣泛的重視。但如何進行測試，如何提高測試的質量和效率，仍然是許多人深感困擾的問題[2]。根據對AutoCAD軟件測試項目研究與實踐的體會，介紹軟件自動化測試技術的概述、基本過程和實現。結合實用的Silk Test工具以及可擴展標記語言技術（extensible markup language，XML），給出整個自動化測試框架。1自動化測試概述整個自動化測試平臺包含兩部分：測試平臺和服務器平臺。測試平臺包含不同語言版本或者不同操作系統的平臺；服務器平臺主要含有源代碼版本管理庫和測試結果的關系數據庫[3]。一個規范化的軟件自動化測試過程通常包括以下幾個基本的測試活動：（1）自動化測試用例選擇對于Silk Test工具而言，它對Java的支持很好，所以如果是多模塊、多軟件測試，首先要盡量選擇和Java相關的部分來設計用例[4]。（2）自動化測試環境準備開啟windows遠程控制，設置文件的擴展名可見，安裝待測試AutoCAD系列產品，安裝測試過程所需的自動化測試軟件（Silk Test軟件）等等一系列配置。光學儀器第35卷

第2期商林霞，等：基于XML的軟件自動化測試

（3）自動化測試腳本開發Silk Test自動化測試工具支持簡單的捕獲同放功能，但是這并不是自動化測試。測試工具直接錄制產生的腳本是不能直接使用的，所以對于利用Silk Test工具編寫的腳本來說，通常是通過捕獲對話框圖形，抓到測試對象。然后利用Silk Test所提供的4Test語言來添加函數、控制結構等[5]。 （4）自動化測試報告生成分析腳本運行的結果是否符合要求，決定每個用例自動化測試是否通過。對測試結果進行分類整理，生成測試報告。對于不能通過的測試結果要進行分析、記錄和通報，方便相關的測試人員和開發人員了解測試結果。2自動化測試系統過程為了取得自動化測試效率和效益的最大化，現選取當前最適合自動化的測試用例。例如自動化測試腳本編寫異常復雜的用例、運行自動化測試腳本很難發現軟件缺陷的用例等等，都可以不運用自圖1自動化測試系統實現框圖

Fig.1Automation testing system

realization block diagram動化測試，而運用手動測試代替。同時在兩個測試版本的間歇進行新的腳本的開發，當有了一定數量的腳本之后，就讓腳本運行起來，發揮作用[6]。現只要保證自動化運行的環境足夠充足，那么每個測試版本所需的時間就會足夠短，節省了大量的人力。軟件自動化測試是一個極為復雜的過程。在不同的測試環境下，測試的流程也會有所不同。一般都要根據實際情況，制定相應的測試流程。從軟件測試對象出發，軟件自動化測試系統實現框圖，如圖1所示。對于不同語言版本的本地化測試，測試過程大體是相似的。首先根據AutoCAD軟件的功能特征選擇和設計測試用例，然后就是由測試用例編寫測試腳本，接著就是將這些測試腳本作為輸入運行程序，將通過測試得到的結果與先得到的英語版本的結果進行比較，最后就是將兩者的比較結果寫成測試報告，軟件開發者根據測試報告再決定對軟件如何處理[7]。3系統實現

3.1腳本生成根據測試設計中的每個測試用例，利用 Silk Test軟件進行編程，完成自動化測試腳本。腳本編寫完成，進行不斷地調試，直至完成的腳本符合測試用例驗證的要求。編程語言是4Test語言，整個腳本的思路是基于AutoCAD軟件對話框對象來實現的。函數中執行圖像錄像功能的語句，把整個自動化測試的windows平臺界面上的執行過程錄制下來，方便判斷軟件是否存在缺陷。針對每個自動化測試的測試用例，編寫測試腳本。每個測試用例都有數個測試確認點，測試腳本要保證每個測試確認點都能被執行自動化測試，生成測試結果。測試腳本程序示例如下：

3.2結果信息讀取軟件本地化測試的對象是本地化的軟件，需要在本地語言的操作系統上進行。以Windows中文語言操作平臺為例，用Silk Test工具運行該對話框對應的測試腳本，生成XML的結果信息文件，該XML記錄了該對話框上的所有信息：文字信息、控件位置信息、控件屬性信息。圖2中所示的AutoCAD軟件對話框的XML部分信息示例如下：

在獲取對話框信息之后，接著就要進行XML結果的分析。讀取XML文件信息的程序片段為：

其中，利用XPath的路徑表達式來選取XML文檔中的節點或者節點集[8]。如要讀取出對話框的標題信息“選擇樣板”，則正確的XPath語句是“/DIALOG/CONTROL[1]/Texts_LIST/@Texts_00000”。類似地，對話框上各控件的位置、大小、屬性等信息都可獲取到。如圖2中的截斷錯誤，都用紅色線框標示出來，提升了后期錯誤分析的效率。

3.3結果對比國際化軟件自動化測試包括軟件國際化測試和軟件本地化測試。軟件的國際化測試一般是英語版本的測試，必須在本地化測試之前進行。首先進行國際化軟件測試有助于判斷軟件國際化的設計程度，確定軟件支持的國家區域，以及本地化是否容易[9]。本地化測試過程中，以源程序軟件結果（標準英語版本）作為本地化軟件的主要參考。運行英語版本和本地化版本的結果比較程序，本地化版本對話框都將與標準英語版本對話框的各項信息進行對比。經對比本地化軟件存在缺陷時有三大類情況：（1）本地化軟件對話框的某項XML信息（控件的位置、大小、屬性等）是空值；（2）本地化軟件對話框的某項信息值的長度和標準英語版本的不一致；（3）本地化軟件對話框的某項信息內容（控件的位置、大小、屬性等）和標準英語版本的不一致。結果比較程序的部分示例：

3.4結果分析在實際的項目測試過程中，每一步都有很具體的內容。例如在報告測試結果的同時，實際上還包含了對測試結果的統計和分析，測試工程師通過對結果進行分析來判斷是否存在缺陷，將缺陷上傳至Test Desk網站進行管理。表1對話框界面的典型錯誤類型

Tab.1Typical error type of dialog user interface

軟件測試報告范文4

關鍵詞 計量自動化系統；性能測試；優化

中圖分類號 TP311 文獻標識碼 A 文章編號 1673-9671-(2012)072-0112-01

隨著科學技術的不斷進步，電力自動化程度越來越高，特別現場電能量數據終端、大客戶負荷控制終端、配變計量監測終端和集抄終端抄表系統的運行，更是讓遠程控制變成了現實，但是，這些遠程系統是不是存在漏洞，各模塊能不能協同作用，是不是存在沖突，能不能傳輸完整的數據、能不能對數據進行系統的分析等問題也向系統提出了要求，在這種情況下，認真進行電力行業各種自動化系統軟件性能測試解析與優化，確保四分線損、供電質量、停電統計、預購電管理、錯峰管理、負荷控制、拉合閘管理等功能模塊之間能夠協調有序進行，對于維護電力系統的正常運行，提高電力行業的綜合競爭能力具有非常重要的現實意義。

1 計量自動化系統性能測試的目的

通過對計量自動化系統性能的測試不但可以發現軟件存在的漏洞和缺陷，而且還可以驗證系統軟件在各種情況下的運行能力。電力用戶的不斷增加也給系統軟件運行提出了要求，系統所能夠承受的最大用戶量也是電力行業必須充分了解的問題，通過計量自動化系統性能測試就可以解決這個問題。同時，通過針對性的系統軟件測試還可以實現系統軟件的性能優化，使系統軟件能夠在不同的條件下都能夠穩定運行。

2 計量自動化系統性能測試的內容

在計量自動化系統運行過程中，軟件的運行環境、軟件的響應時間、軟件長期運行的穩定性、軟件所能支持的最大并發數以及系統在一定時間內所能夠處理的信息量等內容都會給系統運行造成一定的影響，因此在進行計量自動化系統性能測試的過程中，就必須針對上面容易給系統造成影響的內容進行精確的性能測試，以避免軟件的不啟動、誤操作或者非正常運行等狀況發生。在測試過程中，我們主要是通過現場模擬，使用自動化測試工具對電力系統負載正常、負載異常以及峰值等階段進行測試，從而判斷計量自動化系統的各項性能指標是不是能夠達到標準。

3 計量自動化系統性能測試解析與優化

作為一款系統軟件行為與性能的測試產品，Load Runner主要包括VuGen（虛擬用戶發生器）、Pressure regulation（壓力調度）、Controller（監控中心）、Load Generator（壓力生成器）、Analysis（結果分析工具）等。通過Load Runner就能夠完成對計量自動化系統性能進行測試。其常規測試步驟如下：

1）對計量自動化系統性能進行測試，針對軟件的運行環境、軟件的響應時間、軟件長期運行的穩定性、軟件所能支持的最大并發數以及系統在一定時間內所能夠處理的信息量等內容對系統運行造成的影響進行測試。

2）在操作計量自動化系統的前提條件下，通過VuGen記錄生成相關虛擬用戶腳本。

3）對腳本進行修改，確保腳本能夠實現我完整回放。

4）在Controller內根據測試內容進行測試場景配制。其內容主要包括，電力虛擬用戶數目、運行參數、電力用戶的增長方式、軟件測試的循環方式、安全退出、軟件監視指標等。

5）執行測試。Controller通過Load Generator對被測試的系統軟件產生一定的壓力，施加一定的行為，然后對系統在測試過程中的數據進行收集，然后將數據傳遞到Controller，并讓Controller進行數據匯總。

6）通過Analysis對匯總的數據進行分析，并在數據分析的基礎上進行優化方案設計。

7）進行優化測試。盡管計量自動化系統模塊眾多，并且各模塊執行的動作不同，但是進行軟件測試和優化的程序大致相同，現在以采集模塊的優化和測試進行說明。

4 制定采集模塊作性能測試方案

4.1 確定采集模塊作測試場景

采集模塊作測試場景主要是模擬系統軟件的實際運行場景，其主要內容包括運行參數、軟件測試的循環方式、安全退出、軟件監視指標等。在測試場景確定的過程中，要盡可能選擇和采集模塊作在實際運行過程中比較相似的接受四個數據終端數據的任務并發測試場景，從而充分了解采集模塊作極限運行狀態下的運行狀況。

4.2 確定監視指標

在測試過程中，必須認真監視和服務器相對應的軟件性能計數器，其監視的結果就是監視指標，通過監視指標不但能夠進行結果分析，而且還可以尋找導致發生性能問題的根源。

5 執行采集模塊性能測試方案

5.1 搭建采集模塊性能測試環境

首先，要按照測試方案搭建一個獨立、無病毒、相似性強的采集模塊運行環境，然后安裝調試采集模塊，安裝Load Runner；其次，準備測試數據。為了保證測試數據的合理性，測試數據通常從電力部門獲取，如果是自己準備的數據，要分析數據的合理性，避免出現大量的垃圾信息，其數據必須確保軟件能夠按照流程正常運行。再次，在測試數據準備完成后，要及時進行數據庫的備份。

5.2 編寫或者錄制測試腳本

測試腳本的生成既能夠通過編寫完成，又能夠通過測試工具進行錄制。不管是上述兩種方式中的哪一種，所生成的測試腳本必須有效，這也就是說測試腳本能夠充分反映系統軟件的實際運行狀況。

5.3 測試場景的布置

按照測定方案進行測試場景的布置。

5.4 執行測試

要想準確判斷軟件的實際運行能力，必須通過一定強度的測試，準確測定EAC（即電能量數據遙測終端）、集抄終端、負控終端和配變終端的使用效率，運行速度、穩定性。

在測試過程中，要認真測試不同壓力下采集程序的定時采集數據的能力，以及負控、配變、集抄終端的主動連接和采集數據的能力；來自于每一個終端上報信息的時間、數據量以及數據的質量；任務調度程序和采集傳輸服務程序任務調度分發能力和負載均衡能力。

認真比對不同壓力下信息采集的工作效率，進而對整個模塊做出準確的判斷，然后在測定系統各個模塊的基礎上實現對系統的測試。在測試過程中，不管是哪一個環節，都必須采用統一的標準，糾正任何一點偏差，否則就會導致測試失敗。同時，還要注意外部環境對測試結果在成的影響。

6 生成并分析測試報告

測試報告是整個測試的結論性文件。系統開發人員要對測試報告中的相關數據進行分析，認真查找模塊中存在的問題以及缺陷。在這個過程中，首先必須認真篩選出測試數據中的典型數據，然后認真分析數據，查找隱含在數據中的模塊問題；其次，要認真分析問題發生的原因，在找出原因的基礎上提出合理的解決或者優化方案。

7 小結

總之，通過軟件性能測試，可以發現存在于計量自動化系統中的缺陷和漏洞，并進行糾正，這樣就可以確保電力系統的遠程控制的正常進行，真正實現電力計量自動化。

參考文獻

[1]李軍鋒,任世鶴.軟件可靠性及其測試分析[J].軟件導刊,2010,09(08).

軟件測試報告范文5

關鍵詞:軟件測試;案例教學;教學內容

中圖分類號:TP311 文獻標識碼:A文章編號:1009-3044(2010)09-2275-02

Teaching Methods of Software Testing Technology

GAO Zhi-sheng

(School of Mathematic and Computer, Xihua University, Chengdu 610039, China)

Abstract: Software testing is a course that teaches the software testing methods and means. Case teaching methods that runs through the whole software testing process with a single case is proposed. The corresponding teaching contents and experiment requirements are also introduced. Through the teaching methods, the studying interesting, the initiative and the capability of finishing the practical software testing projects are really improved.

Key words: software testing; case teaching; teaching contents

軟件開發過程中的質量問題是關系到軟件和軟件組織生存的重大問題,得到了越來越多的重視。目前在高校的軟件工程專業普遍開設有軟件測試相關課程。但是在具體教學實踐中,教師普遍感覺到有許多不如意的地方[1],具體表現在教學內容與具體應用脫節,學生對軟件測試認識有誤區,學生學習積極性不強、認為軟件測試是文字性課程,軟件測試過程如何展開,如何選擇測試工具,如何在教學中貫徹軟件測試管理思想等。

近年來關于怎樣進行軟件測試教學,引起了相關專家的重視和討論[1-4]。本文在總結前人的經驗基礎上,結合作者近幾年在軟件測試技術課程教學中的實踐提出了以一個具體項目案例貫穿整個教學過程,理論與實踐緊密結合的教學方法。

1 教學的目的和教學方法

軟件測試技術課程是本校軟件工程專業的一門專業必修課程,通過軟件知識體系的學習,使學生了解軟件測試的發展現狀,認識軟件測試的重要性,掌握軟件測試的方法和技術,熟悉軟件測試過程管理,從而具有獨立承擔軟件測試項目的實施能力,具有測試計劃、管理、實現和軟件質量保障的能力[3]。

針對以上教學目的,我們在軟件測試技術教學過程中引入一個具體測試項目案例貫穿整個教學過程的教學方法。第一課時,我們組織學生自由進行分組,每組5個人左右,每組確定一個名稱。要求每個小組在課程的前幾周完成同一個模擬題目“大學圖書館管理系統”的軟件開發。系統完成后,然后各個小組交叉進行測試對方開發的軟件系統。隨著課程的進度,主要要求學生完成軟件系統的單元測試,集成測試,功能測試和系統測試。單一的案例貫穿整個軟件項目測試過程的案例教學方法的優點是:

1)軟件測試的前期課程有“Java EE編程技術”,同時我們選擇圖書館管理系統作為開發對象,學生從技術上和業務需求上都具備快速完成該系統的能力。

2)相同的開發對象,互相測試對方開發的系統,有利于形成競爭,有利于調動學生的學習積極性。同時也有利于教師對學生完成的結果進行點評和組織課堂討論。

3)整個軟件測試課程,學生能夠完成對一個具體項目的全部測試過程,有利于促進學生系統地掌握軟件測試的技術方法,組織和過程。

2 教學過程

我們的教學過程主要包括以下5個階段,最初的幾周主要講解軟件測試原理,同時這個階段學生主要完成指定項目,然后是4個主要的軟件測試技術:單元測試,集成測試,功能測試和性能測試。軟件測試課程也會講解其他如回歸,壓力等其它測試技術,下面是我們課程重點講授的內容和要求。

2.1 軟件測試原理

本階段主要講授軟件測試技術的基本概念,使學生掌握基本的軟件測試原理。包括軟件測試的重要性,軟件評測師的職業規劃,軟件質量的概念等基本概念,重點講授的內容是白盒測試及用例的設計和黑盒測試及用例的設計兩個章節。白盒測試主要包括邏輯覆蓋和基本路徑覆蓋兩種用例設計方法,邏輯覆蓋又分為語句、判定、條件、判定/條件、組合、路徑覆蓋等。黑盒測試的重點內容是等價類劃分,邊界值分析,因果圖,決策表和場景法。

本階段對學生的實踐要求是開發“大學圖書館管理系統”,由上課老師為學生統一提供系統的需求規格說明書,該系統的主要功能如圖1所示。要求學生結合對本校圖書借閱系統的使用和需求規格說明書,采用Java EE技術進行開發,系統采用典型的4層結構進行設計,如圖2所示,即運行在客戶端計算機上的客戶層組件、運行在Java EE服務器上的Web層組件、業務層組件和運行在EIS服務器上的企業信息系統(EIS)層軟件[4]。系統開發采用JSF+EJB3.0的架構,Glassfish為應用服務器,MySql提供數據庫服務。

2.2 單元測試

單元測試是對軟件最小組成單元的測試,是軟件開發過程中進行的最基本的測試。單元測試主要按照程序內部的結構測試程序,檢驗程序中的每條通路是否都能按預定要求正確工作。單元測試主要考慮各個模塊接口的輸入和輸出,模塊內部的數據結構,模塊的邊界條件,模塊的基本路徑和模塊的出錯處理。單元測試階段還講授代碼規范性檢查,代碼覆蓋率的檢查,代碼復雜度的計算和內存泄漏的檢查等。

完成單元測試的基本原理的學習后,要求學生交叉完成圖書館管理系統的單元測試,主要抽取系統中的核心函數進行測試。完成測試后要求每個小組提供單元測試計劃,單元測試用例和單元測試報告3個報告文檔。得到所有報告后,組織一次課堂討論,展示優秀小組的成果,分析原因總結經驗。單元測試工具要求采用JUnit,代碼規范和代碼質量分析采用Logitscope, Pruify用于分析代碼的內存問題。

2.3 集成測試

軟件各個單元通過單元測試之后,需要檢查各個單元之間的相互接口是否正確,就是集成測試。軟件集成測試主要考慮的問題是模塊間的數據傳遞是否正確,一個模塊的功能是否會對另一個模塊的功能產生錯誤的影響,全局數據結構是否有問題,塊組合起來的功能是否能滿足要求,集成后累積誤差是否被放大等[5]。關于軟件集成測試的原則、策略和用例設計等相關原理可參考其它相關文獻。

教授完集成測試相關原理后,我們要求每個小組負責人組織完成系統的集成測試。集成測試以一個EJB、Servlet或者JSF為基本單元,工具選擇Cactus和HttpUnit。完成集成測試后要求每個小組提交集成測試計劃、集成測試設計文檔和集成測試分析報告。收齊所有小組成果,組織學生進行討論。

2.4 功能測試

功能測試就是對產品的各功能進行驗證,根據功能測試用例,逐項測試,檢查產品是否達到用戶要求的功能。主要考慮系統的各個功能,一般從軟件產品的界面、架構出發,按照需求編寫測試用例,測試產品時是否達到用戶使用的需求。本階段主要讓學生采用WinRunner完成系統的功能測試,進行功能測試之前首先完成測試計劃和測試用例的設計。然后完成WinRunner的6個步驟:識別程序的GUI,建立測試腳本,完善測試腳本,在新版應用程序執行測試腳本,分析測試結果和回報缺陷。

2.5 性能測試

典型的性能測試主要是從系統的響應時間、吞吐量、系統資源利用率、并發用戶數、HTTP事務處理數/秒、會話數/秒和連接建立時間等方面衡量系統的性能。性能測試主要有壓力測試,容量測試和強度測試等。針對圖書館管理系統的特點,我們要求學生理解性能測試的重要性和困難性,掌握性能測試的基本概念和技術。在此技術上,我們要求學生使用LoadRunner完成系統的壓力測試。主要步驟是測試需求分析,制定測試策略和方案(重點是設計測試場景),使用VuGen創建腳本,在Controller中創建場景,運行場景,分析結果。完成后提交測試策略和方案報告,腳本和圖書館管理系統壓力測試報告。

3 結論

一個合格的軟件評測師要求具有編程能力、開發能力、溝通能力、管理能力、逆向思維能力等多種能力。怎樣在大學軟件測試技術教學中培養既有理論又能實踐的軟件測試從業人員是本文研究的動機。我們提出的基于同一案例貫穿整個軟件測試技術教學過程的教學方法,通過學生互測對方開發的軟件系統,相互對比,相互促進同時組織課堂討論,有效營造了主動學習的氣氛,增強了學生的學習積極性,培養了學生主動思考問題的能力。該方法是一個值得借鑒的軟件測試技術教學方法。

參考文獻:

[1] 李繪卓,唐峻,范勇.基于案例的軟件測試實驗教學[J].電腦知識與技術,2009,27(5):7820-7821.

[2] 屠紅蕾.軟件測試教學的點滴體會[J].計算機教育,2008(10):124-125.

[3] 李亞.“軟件測試”教學探索與實踐[J].計算機教育,2008(6):14-15.

軟件測試報告范文6

關鍵詞：軟件測試；性能測試；LoadRunner

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

1　軟件性能測試

根據測試的目的和內容的不同，性能測試主要包括以下方面：

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

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

(3)容量測試：在用戶可接受的響應范圍內，確定系統可處理同時在線的最大用戶數。

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

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

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

2　軟件性能測試流程

2.1　測試方案設計

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

2.2　測試環境的搭建

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

2.3　測試場景開發

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

2.4　測試執行

測試執行是在測試方案的制定、測試環境準備、測試場景開發工作正確完成的基礎上進行的。

2.5　測試報告和分析

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

2.6　回歸測試

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

3　軟件性能測試工具LoadRunner

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

LoadRunner是一種預測系統行為和性能的負載測試工具。通過模擬上千萬用戶實施并發負載及實時性能檢測來確認和查找問題，能夠對整個企業架構進行測試。通過使用LoadRunner，企業能夠最大限度的縮短測試時間，優化性能和加速應用系統的周期。LoadRunner能支持廣泛的協議和技術，功能比較強大，可以為特殊環境提供特殊的解決方案。LoadRunner由下面三部分組成：Virtual UserGenerator用來錄制腳本、編輯腳本Controller用來布置測試場景、執行測試場景；Analysis用來對測試結果進行分析。

用LoadRunner進行負載測試的流程通常由五個階段組成：計劃、腳本創建、場景定義、場景執行、監視執行和結果分析。

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

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

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

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

型。

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

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

(4)設置場景：

Design：設計測試場景的靜態部分，設置模擬用戶生成器、模擬用戶數量、模擬用戶組等。

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

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

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

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

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

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

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

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

⑤Network Interface：Bytes Total/sec為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較。