第一篇：軟件測試技術(shù)-實(shí)驗(yàn)報(bào)告內(nèi)容格式

課程名稱：《軟件測試技術(shù)》

實(shí)驗(yàn)名稱：《使用LoadRunner 進(jìn)行性能測試》

實(shí)驗(yàn)?zāi)繕?biāo)：

1、掌握LR的測試過程；

2、掌握LR中 Visual User Generator（以下簡稱VuGen）、Controller和Analysis三個(gè)組件的具體使用。

實(shí)驗(yàn)要求：

采用LR 自帶的HP WEBTours應(yīng)用程序，進(jìn)行性能測試。

實(shí)驗(yàn)過程：

1、錄制LR 自帶的HP WEBTours應(yīng)用程序腳本，錄制內(nèi)容包括自動(dòng)進(jìn)入到WEB TOURS 網(wǎng)站，進(jìn)行登錄（已經(jīng)注冊成功），登錄成功后，再定一張票，定票后，輸入信用卡信息，然后退出登錄，完成后，點(diǎn)擊停止錄制；（具體過程自己描述）

2、生成腳本；

（具體過程自己描述）

3、回放腳本；

（具體過程自己描述）

4、插入事件，分別在登錄前和登錄成功后、訂票前和訂票成功后四個(gè)位置插入一個(gè)事件；

（具體過程自己描述）

5、啟動(dòng)Controller，配置場景，選擇場景類型為Goal—Oriented Scenario；（具體過程自己描述）

6、生成分析報(bào)告。

（具體過程自己描述）

參照《LoadRunner結(jié)果分析說明》文檔進(jìn)行分析，了解系統(tǒng)瓶頸在什么地方，需要改進(jìn)，實(shí)驗(yàn)完成。

實(shí)驗(yàn)心得：

要求不得少于200字。

第二篇：軟件測試實(shí)驗(yàn)報(bào)告

軟件質(zhì)量保證與測試

2016 ~ 2017學(xué)年

第二學(xué)期

學(xué)

院 計(jì)算機(jī)科學(xué)技術(shù)

專

業(yè) 軟件工程 學(xué)

號(hào)

140521221 姓

名 蒲鳳 指導(dǎo)教師王鵬

目錄

一、單元測試.......................................................1 1.1實(shí)驗(yàn)?zāi)康?.....................................................1 1.2實(shí)驗(yàn)環(huán)境......................................................1 1.3實(shí)驗(yàn)原理......................................................1 1.4實(shí)驗(yàn)內(nèi)容......................................................1 1.4.1 C#單元測試................................................1 1.4.2 測試用例..................................................4 1.5實(shí)驗(yàn)結(jié)果......................................................5 1.6實(shí)驗(yàn)總結(jié)......................................................6 1.6.1插件安裝...................................................6 1.6.2心得體會(huì)...................................................6 1.6.3單元測試意義...............................................6

二、LOADRUNNER性能測試.............................................7 2.1實(shí)驗(yàn)?zāi)康?.....................................................7 2.2實(shí)驗(yàn)環(huán)境......................................................7 2.3實(shí)驗(yàn)原理......................................................7 2.4實(shí)驗(yàn)內(nèi)容......................................................7 2.4.1 HP LoadRunner錄制腳本.....................................7 2.4.2 HP LoadRunner腳本測試場景設(shè)計(jì)及分析......................17 2.5實(shí)驗(yàn)結(jié)果.....................................................33 2.6實(shí)驗(yàn)分析.....................................................34 2.7實(shí)驗(yàn)總結(jié).....................................................34

三、反編譯........................................................36 3.1實(shí)驗(yàn)?zāi)康?....................................................36 3.2實(shí)驗(yàn)環(huán)境.....................................................36 3.3實(shí)驗(yàn)原理.....................................................36 3.4實(shí)驗(yàn)內(nèi)容.....................................................36 3.4.1 Net Refelector反編譯.....................................36 3.5實(shí)驗(yàn)結(jié)果.....................................................40 3.6實(shí)驗(yàn)總結(jié).....................................................41 3.6.1心得體會(huì)..................................................41

I 3.6.2 對(duì)軟件安全性的看法.......................................41

四、SQL注入.......................................................42 4.1實(shí)驗(yàn)?zāi)康?....................................................42 4.2實(shí)驗(yàn)環(huán)境.....................................................42 4.2實(shí)驗(yàn)原理.....................................................42 4.3實(shí)驗(yàn)內(nèi)容.....................................................42 4.3.1 sql注入..................................................42 4.4實(shí)驗(yàn)結(jié)果.....................................................52 4.5實(shí)驗(yàn)總結(jié).....................................................54 4.5.1心得體會(huì)..................................................54 4.5.2 SQL注入危害..............................................54

五、禪道項(xiàng)目管理的BUG管理模塊使用................................55 5.1實(shí)驗(yàn)?zāi)康?....................................................55 5.2實(shí)驗(yàn)環(huán)境.....................................................55 5.3實(shí)驗(yàn)原理.....................................................55 5.4實(shí)驗(yàn)內(nèi)容.....................................................55 5.4.1禪道項(xiàng)目管理的bug管理模塊使用............................55 5.5實(shí)驗(yàn)結(jié)果.....................................................67 5.6實(shí)驗(yàn)總結(jié).....................................................68

II

一、單元測試

1.1實(shí)驗(yàn)?zāi)康?/p>

1.能夠使用編程工具進(jìn)行單元測試。

2.檢查代碼實(shí)現(xiàn)是否符合設(shè)計(jì)，盡早發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤。3.發(fā)現(xiàn)在編碼過程中引入的錯(cuò)誤，跟蹤需求和設(shè)計(jì)的實(shí)現(xiàn)是否一致。

1.2實(shí)驗(yàn)環(huán)境

環(huán)境：vs2013

1.3實(shí)驗(yàn)原理

主要采用白盒技術(shù)，檢查模塊控制結(jié)構(gòu)的某些特殊路徑，期望覆蓋盡可能多的出錯(cuò)點(diǎn)。

1.4實(shí)驗(yàn)內(nèi)容

1.4.1 C#單元測試

1.新建一個(gè)類庫項(xiàng)目，并為其中的類為BinaryTree.構(gòu)建二叉樹并添加前序遍歷方法。如圖1-1所示。

圖1-1 2.創(chuàng)建單元測試。在方法名上右擊，然后單擊“Generate Unit Test”選項(xiàng)，打開對(duì)話框。如圖1-2所示。

圖1-2 3.選擇方法，為新建項(xiàng)目命名。如圖1-3所示。

圖1-3 4.然后在解決方案管理中就多了相應(yīng)的BinaryTree Tests解決方案。如圖1-4所示。

圖1-4 打開測試菜單->窗口->測試資源管理器，如圖1-5所示。

圖1-5 5.在測試試圖，右鍵運(yùn)行要測試的方法，在測試結(jié)果窗口中查看測試結(jié)果，運(yùn)行測試之前。如圖1-6所示。

圖1-6 1.4.2測試用例

1.設(shè)置測試參數(shù)。如圖1-7，1-8所示。

圖1-7

圖1-8 2.運(yùn)行之后。如圖1-9所示。

圖1-9 1.5實(shí)驗(yàn)結(jié)果

經(jīng)過測試，ResultEqualTest1，ResultEqualTest2均未通過測試，調(diào)整參數(shù)，重新測試,測試結(jié)果如下，如圖1-10所示。：

圖1-10 1.6實(shí)驗(yàn)總結(jié)

1.6.1插件安裝

在vs2013進(jìn)行單元測試之前，需要按照手動(dòng)添加插件。選擇工具-擴(kuò)展和更新，搜索并安裝Unit Test Generator。1.6.2心得體會(huì)

本次測試設(shè)計(jì)涉及預(yù)期測試需求，實(shí)驗(yàn)結(jié)果符合預(yù)期。單元測試幫助開發(fā)人員編寫代碼，提升質(zhì)量，減少bug；提升反饋速度，減少重復(fù)工作，提高開發(fā)效率；保證最后的代碼不會(huì)破壞之前的代碼功能，同時(shí)讓代碼維護(hù)更容易，有助于改進(jìn)代碼質(zhì)量和設(shè)計(jì)。1.6.3單元測試意義

單元測試集中注意力與程序的基本組成部分，首先保證每個(gè)單元測試通過，才能使下一步把單元組成部分組裝成部件并測試其正確性具有基礎(chǔ)。單元是整個(gè)軟件的構(gòu)成基礎(chǔ)，只有保證零部件一樣，這個(gè)設(shè)備的質(zhì)量才有基礎(chǔ)，單元的質(zhì)量也是整個(gè)軟件質(zhì)量的基礎(chǔ)。因此，單元測試的效果會(huì)直接影響到軟件的后期測試，最終在很大程度上影響到產(chǎn)品的質(zhì)量。同時(shí)，單元規(guī)模較小，復(fù)雜性較低，因而發(fā)現(xiàn)錯(cuò)誤后容易隔離和定位，有利于調(diào)試工作。

二、LoadRunner性能測試

2.1實(shí)驗(yàn)?zāi)康?/p>

1.掌握LoadRunner的使用方法。2.能夠使用LoadRunner進(jìn)行負(fù)載測試

3.學(xué)會(huì)用LoadRunner設(shè)計(jì)場景并嘗試，并分析測試結(jié)果。

2.2實(shí)驗(yàn)環(huán)境

環(huán)境：HP LoadRunnner

2.3實(shí)驗(yàn)原理

LoadRunner進(jìn)行負(fù)載測試通常有五個(gè)階段組成：

計(jì)劃、腳本創(chuàng)建、場景定義、場景執(zhí)行和結(jié)果分析。

(1)計(jì)劃負(fù)載測試：定義性能測試要求，例如并發(fā)用戶的數(shù)量、典型業(yè)務(wù)流程和所需相應(yīng)時(shí)間。

(2)創(chuàng)建Vuser腳本：將最終用戶活動(dòng)捕獲到自動(dòng)腳本中。(3)定義場景:使用LoadRunnerControlller設(shè)置負(fù)載測試環(huán)境。(4)運(yùn)行場景：通過LoadRunnerControlller驅(qū)動(dòng)、管理和監(jiān)控負(fù)載測試。(5)分析結(jié)果：使用LoadRunnerAnalysis創(chuàng)建圖和報(bào)告并評(píng)估性能。

2.4實(shí)驗(yàn)內(nèi)容

2.4.1HP LoadRunner錄制腳本

1.啟動(dòng)服務(wù)。如圖2-1所示。

圖2-1 2.登錄自帶網(wǎng)站W(wǎng)ebTours，并注冊。如圖2-2所示。

圖2-2 填寫注冊信息，如圖2-3，2-4所示。

圖2-3

圖2-4 注冊成功，如圖2-5所示。

圖2-5

3.打開Loadrunner，點(diǎn)擊新建腳本打開VuGen。如圖2-6所示。

圖2-6 新建腳本，如圖2-7所示。

圖2-7

4.新建腳本，選擇協(xié)議。如圖2-8所示。

圖2-8 5.選擇瀏覽器，設(shè)置所測web的地址。如圖2-9所示。

圖2-9 6.點(diǎn)擊左下角Options按鈕，進(jìn)入錄制環(huán)境設(shè)置界面。如圖2-10，2-11所示。

圖2-10

圖2-11

7、模擬用戶操作開始錄制腳本。如圖2-12所示。

圖2-12 用戶操作如下，模擬用戶訂票。如圖2-13所示。

圖2-13 8.結(jié)束錄制，生成腳本。如圖2-14所示。

圖2-14 9.回放腳本，驗(yàn)證腳本是否正確。如圖2-15所示。

圖2-15 回放結(jié)果，如圖2-16所示。

圖2-16 10.增加事務(wù)，并命名。如圖2-17所示。

圖2-17 給事務(wù)命名，如圖2-18所示。

圖2-18 查看事務(wù)，如圖2-19所示。

圖2-19 11.參數(shù)化。在腳本中找到需要參數(shù)化的值，例如登錄名和登錄密碼。如圖2-20所示。

圖2-20 2.4.2HP LoadRunner腳本測試場景設(shè)計(jì)及分析

1.導(dǎo)入腳本，打開controller。如圖2-21所示。

圖2-21 2.選擇文件路徑。如圖2-22所示。

圖2-22 3.進(jìn)入初始界面。如圖2-23所示。

圖2-23 4.為了設(shè)置集合點(diǎn)，取消默認(rèn)勾選框，添加腳本。如圖2-24所示。

圖2-24 5.確定，進(jìn)入場景設(shè)置界面。如圖2-25所示。

圖2-25 6.設(shè)置場景，選擇初始化。如圖2-26所示。

圖2-26 7.打開運(yùn)行時(shí)設(shè)置，設(shè)置迭代次數(shù)。如圖2-27所示。

圖2-27 8.設(shè)置迭代參數(shù)為2。如圖2-28所示。

圖2-28 9.點(diǎn)開Miscellaneous,設(shè)置Continueon error，使錯(cuò)誤發(fā)生時(shí)可繼續(xù)執(zhí)行。如圖2-29所示。

圖2-29 10.設(shè)計(jì)集合點(diǎn)。如圖2-30所示。

圖2-30 設(shè)置當(dāng)所有虛擬用戶都到達(dá)集合點(diǎn)才釋放，模擬多用戶同時(shí)進(jìn)行某一操作的情況。選中policy。如圖2-31所示。

圖2-31 11.設(shè)置policy。如圖2-32所示。

圖2-32 12.點(diǎn)擊運(yùn)行，進(jìn)入運(yùn)行時(shí)監(jiān)控界面。如圖2-33所示。

圖2-33 13.點(diǎn)擊運(yùn)行場景。如圖2-34所示。

圖2-34 14.觀察運(yùn)行結(jié)果。如圖2-35，2-36，2-37，2-38，2-39所示。

圖2-35

圖2-36

圖2-37

圖2-38

圖2-39 15.設(shè)置場景運(yùn)行時(shí)Windows資源監(jiān)控圖。如圖2-40所示。

圖2-40 點(diǎn)擊添加。如圖2-41，2-42所示。

圖2-41

圖2-42 運(yùn)行時(shí)Windows資源監(jiān)控圖截圖如下。如圖2-43所示。

圖2-43 16.打開分析器，形成分析結(jié)果。如圖2-44，2-45所示。

圖2-44

圖2-45 17.分析器自動(dòng)形成分析結(jié)果。如圖2-46，2-47，2-48，2-49，2-50所示。

圖2-46

圖2-47 18.點(diǎn)開監(jiān)控的圖表，根據(jù)需要合并圖表以便更好地分析。

圖2-48

圖2-49

圖2-50 19．添加Windows資源監(jiān)控圖表。如圖2-51，2-52所示。

圖2-51

圖2-52 20.添加頁面分析結(jié)果圖表。如圖2-53所示。

圖2-53 21.生成測試報(bào)告。如圖2-54所示。

圖2-54 生成測試報(bào)告中。如圖2-55所示。

圖2-55 生成測試報(bào)告，如圖2-56所示。

圖2-56 2.5實(shí)驗(yàn)結(jié)果

回放驗(yàn)證。如圖2-57所示。

圖2-57

生成測試報(bào)告，點(diǎn)擊內(nèi)容，如圖2-58所示。

圖2-58 2.6實(shí)驗(yàn)分析

通過測試報(bào)告可以看出，最多能夠創(chuàng)建10個(gè)vuser，平均吞吐量是14320字節(jié)每分，平均每秒點(diǎn)擊數(shù)量約為10次。同時(shí)可以通過以下方式使被測系統(tǒng)所受壓力減輕,從如下方面進(jìn)行綜合調(diào)解:將測試腳本中think time值加大并在控制臺(tái)中按比例實(shí)現(xiàn),此處think time指在transaction外部的時(shí)間；Controller中Run-Time Setting的Pacing設(shè)置值加大；虛擬用戶登錄時(shí)使用遞增策略，間隔稍長。

2.7實(shí)驗(yàn)總結(jié)

LoadRunner，是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過以模擬上千萬用戶實(shí)施并發(fā)負(fù)載及實(shí)時(shí)性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner能夠?qū)φ麄€(gè)企業(yè)架構(gòu)進(jìn)行測試。企業(yè)使用LoadRunner能最大限度地縮短測試時(shí)間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。LoadRunner可適用于各種體系架構(gòu)的自動(dòng)負(fù)載測試，能預(yù)測系統(tǒng)行為并評(píng)估系統(tǒng)性能。學(xué)會(huì)了使用LoadRunner錄制腳本。基本的流程是啟動(dòng)服務(wù)器、注冊、錄制腳本及進(jìn)行參數(shù)化設(shè)置。設(shè)計(jì)涉及場景的搭建和測試，通過Lordrunner進(jìn)行腳本測試，同時(shí)能夠生成相應(yīng)的圖表，直觀的反應(yīng)了測試結(jié)果。Lordrunner作為專業(yè)的性能測試工具,通過模擬成千上萬的用戶對(duì)被測應(yīng)用進(jìn)行操作和請求,在實(shí)驗(yàn)室環(huán)境中精確重現(xiàn)生產(chǎn)環(huán)境中任意可能出現(xiàn)的業(yè)務(wù)壓力,然后通過在測試過程中獲取的信息和數(shù)據(jù)來確認(rèn)和查找軟件的性能問題,分析性能瓶頸。

三、反編譯

3.1實(shí)驗(yàn)?zāi)康?/p>

1.學(xué)會(huì)如何使用反編譯工具對(duì)程序進(jìn)行反編譯。2.能夠使用.NetRefelector進(jìn)行反編譯。

3.2實(shí)驗(yàn)環(huán)境

環(huán)境：.Net Refelector,VS2008 3.3實(shí)驗(yàn)原理

反編譯的主要思想：將特定的機(jī)器代碼，即我們的“源程序”，先翻譯為低級(jí)的中間代碼，然后再根據(jù)特定的高級(jí)語言將中間代碼翻譯為高級(jí)程序。反編譯器也有前端和后端。前端是一個(gè)機(jī)器依賴的模塊，句法分析二進(jìn)制程序、分析其指令的語義、并且生成該程序的低級(jí)中間表示法和每一子程序的控制流向圖。通用的反編譯機(jī)器是一個(gè)與語言和機(jī)器無關(guān)的模塊，分析低級(jí)中間代碼，將它轉(zhuǎn)換成對(duì)任何高級(jí)語言都可接受的高級(jí)表示法，并且分析控制流向圖的結(jié)構(gòu)、把它們轉(zhuǎn)換成用高級(jí)控制結(jié)構(gòu)表現(xiàn)的圖。最后，后端是一個(gè)目標(biāo)語言依賴的模塊，生成目標(biāo)語言代碼。反編譯的過程中要使用一些工具：把二進(jìn)制程序裝入內(nèi)存，對(duì)這一程序做句法分析或反匯編，以及反編譯或者分析該程序來生成高級(jí)語言程序。這個(gè)過程借助編譯器和庫的簽名來識(shí)別特定的編譯器和庫子程序。只要在二進(jìn)制程序中識(shí)別出編譯器簽名，就不去反編譯這些編譯器啟動(dòng)代碼(start-up)和庫子程序：對(duì)于前者，從最后的目標(biāo)程序去掉啟動(dòng)代碼的那些例程，反編譯器從主(main)程序入口點(diǎn)開始分析；對(duì)于后者，那些子程序用其庫函數(shù)名代替。

3.4實(shí)驗(yàn)內(nèi)容

3.4.1Net Refelector反編譯

1.啟動(dòng).NETRefelector(在所有程序中找到RedGate文件夾)找到安裝文件，點(diǎn)擊運(yùn)行。如圖3-1所示。

圖3-1 2.選擇文件，打開可執(zhí)行文件。如圖3-2所示。

圖3-2 選擇文件路徑。如圖3-3所示。

圖3-3

3.導(dǎo)入工程截圖如下。如圖3-4所示。

圖3-4 4.相關(guān)函數(shù)和類，如圖3-5所示。

圖3-5 5.選中工程，導(dǎo)出源碼。如圖3-6所示。

圖3-6 6.選擇導(dǎo)出文件路徑。如圖3-7所示。

圖3-7 7.選中反編譯程序，點(diǎn)擊運(yùn)行。如圖3-8所示。

圖3-8 3.5實(shí)驗(yàn)結(jié)果

反編譯成功，如圖3-9所示。

圖3-9

3.6實(shí)驗(yàn)總結(jié)

3.6.1心得體會(huì)

本次實(shí)驗(yàn)通過反編譯工具進(jìn)行了反編譯，完成了從可執(zhí)行文件到源碼的轉(zhuǎn)換，學(xué)會(huì)了如何使用.NET Refelector反編譯工具。3.6.2 對(duì)軟件安全性的看法

軟件安全（Software Security）就是使軟件在收到惡意攻擊的情形下依然能夠繼續(xù)正確運(yùn)行及確保軟件被在授權(quán)范圍內(nèi)合法使用的思想。軟件安全性分析任務(wù)包含于軟件生存周期的若干活動(dòng)中，是針對(duì)軟件的安全性質(zhì)量，作為這些活動(dòng)的補(bǔ)充。軟件安全性分析作為開發(fā)中軟件的質(zhì)量的重要保證，關(guān)系到軟件的獲取、供應(yīng)、開發(fā)、運(yùn)行和維護(hù)，已得到專業(yè)人士的高度重視。并且現(xiàn)在，軟件安全性分析任務(wù)的各項(xiàng)細(xì)節(jié)執(zhí)行都寫入了國軍標(biāo)，被安全相關(guān)軟件的需方、供方、開發(fā)者、維護(hù)者以及獨(dú)立的評(píng)價(jià)者使用。規(guī)范化將推進(jìn)軟件安全性分析的進(jìn)程，使更多的開發(fā)和評(píng)測單位遵循標(biāo)準(zhǔn)化文件，督促開發(fā)團(tuán)隊(duì)采取相應(yīng)的技術(shù)手段，以軟件測試作為輔助。同樣，軟件安全性分析標(biāo)準(zhǔn)也會(huì)在推進(jìn)的過程中，得到不斷地發(fā)展。

四、SQL注入

4.1實(shí)驗(yàn)?zāi)康?/p>

1.明白SQL注入原理。2.能夠進(jìn)行簡單的SQL注入。

4.2實(shí)驗(yàn)環(huán)境

環(huán)境：VS2013，SQL Server Management Studio 4.2實(shí)驗(yàn)原理

SQL注入即是指web應(yīng)用程序?qū)τ脩糨斎霐?shù)據(jù)的合法性沒有判斷，攻擊者可以在web應(yīng)用程序中事先定義好的查詢語句的結(jié)尾上添加額外的SQL語句，以此來實(shí)現(xiàn)欺騙數(shù)據(jù)庫服務(wù)器執(zhí)行非授權(quán)的任意查詢，從而進(jìn)一步得到相應(yīng)的數(shù)據(jù)信息。

4.3實(shí)驗(yàn)內(nèi)容

4.3.1 sql注入

1.點(diǎn)擊SQL SERVERR２。如圖4-1所示。

圖4-1 登陸數(shù)據(jù)庫，如圖4-2所示。

圖4-2 ２.創(chuàng)建數(shù)據(jù)庫SQLTEST。如圖4-3，4-4所示。

圖4-3

圖4-4 ３.創(chuàng)建表UserLogin。如圖4-5所示。

圖4-5 設(shè)置主鍵如下，如圖4-6所示。

圖4-6 設(shè)置成功，截圖如下。如圖4-7所示。

圖4-7 輸入表名。如圖4-8所示。

圖4-8 4.選中表，編輯前200行。如圖4-9所示。

圖4-9 5.編輯測試數(shù)據(jù)，如圖4-10所示。

圖4-10 6.打開VS2013，新建項(xiàng)目。如圖4-11所示。

圖4-11 選中Asp.net Web應(yīng)用程序。如圖4-12所示。

第三篇：《軟件測試技術(shù)》課程總結(jié)報(bào)告

《軟件測試技術(shù)》課程總結(jié)報(bào)告

班級(jí)：姓名：學(xué)號(hào)：

一、課程概述

二、課程實(shí)訓(xùn)項(xiàng)目

三、課程知識(shí)點(diǎn)總結(jié)

四、收獲和體會(huì)

第四篇：軟件測試技術(shù)面試總結(jié)

軟件測試就是為了發(fā)現(xiàn)程序中的錯(cuò)誤而分析和執(zhí)行程序的過程?！拍?/p>

+基本知識(shí)+軟件開發(fā)過程-定義-計(jì)劃-實(shí)現(xiàn)-穩(wěn)定化-部署

+軟件開發(fā)模型(四種典型的模型)

+瀑布模型

-概述：包括計(jì)劃，需求分析，設(shè)計(jì)，編碼，測試，運(yùn)行維護(hù)六個(gè)階段。六個(gè)階段自上而下、相互銜接，以固定的次序進(jìn)行。

-特點(diǎn)：1.階段的順序性和依賴性；2.文檔驅(qū)動(dòng)； 3.推遲實(shí)現(xiàn)的觀點(diǎn)；4.質(zhì)量保證。-缺點(diǎn)：不適合需求模糊的系統(tǒng)

+原型模型-概述：先建立一個(gè)能夠反映用戶需求的原型系統(tǒng)，使得用戶和開發(fā)者可以對(duì)目標(biāo)系統(tǒng)的概貌進(jìn)行評(píng)價(jià)和判斷，然后對(duì)原型系統(tǒng)進(jìn)行反復(fù)的擴(kuò)充、改進(jìn)、求精，最終建立符合用戶需求的目標(biāo)系統(tǒng)。

-特點(diǎn)：1.快速開發(fā)工具；2.循環(huán)； 3.低成本。

-分類：按照對(duì)原型的處理方式，可以分為漸進(jìn)型和拋棄型。

+增量模型

-概述：在增量模型中每個(gè)階段都生成軟件的一個(gè)可發(fā)布版本，階段交錯(cuò)進(jìn)行，版本逐漸完善。

-同原型模型的最大區(qū)別在于，在原型模型中每個(gè)階段發(fā)布一個(gè)原型而在增量模型中則完成一個(gè)正式版本。+螺旋模型

-概述：適用于大型軟件的開發(fā)，它將瀑布模型和快速原型模型結(jié)合起來，并加入了風(fēng)險(xiǎn)分析。

-特點(diǎn)：1.每個(gè)階段都包括制定計(jì)劃，風(fēng)險(xiǎn)分析，實(shí)施工程，評(píng)審四個(gè)階段；

2.開發(fā)過程迭代進(jìn)行，每迭代一次螺旋線增一周，工程前進(jìn)一個(gè)層次，系統(tǒng)生成一個(gè)新版本，投入新的時(shí)間成本，最終得到客戶滿意的版本。

-軟件測試從需求開始：現(xiàn)代的軟件測試將測試滲入到軟件開發(fā)的各個(gè)階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實(shí)上，在計(jì)劃、需求、設(shè)計(jì)階段，測試人員便已經(jīng)開始了他們的工作，如：了解軟件需求，編寫測試計(jì)劃，搭建測試環(huán)境。

-測試用例

-三要素：前提條件和操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果。

-必須以需求為依據(jù)。

-軟件測試分類

-是否關(guān)注軟件結(jié)構(gòu)和算法

-黑盒測試：基于軟件需求的測試方法。

-白盒測試：基于軟件內(nèi)部設(shè)計(jì)和程序?qū)崿F(xiàn)的測試方法。

-是否執(zhí)行被測試軟件

-動(dòng)態(tài)測試：在測試過程中執(zhí)行被測試軟件的測試方法。

-靜態(tài)測試：------------不----------------------。

-基于不同的測試階段：

-單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅(qū)動(dòng)程序，采用白盒測試的方法，一般由 開發(fā)人員完成。

-集成測試：將一些“構(gòu)件”集成在一起時(shí)測試他們是否能正常運(yùn)行，構(gòu)件可以是程序模塊，也可以是

客戶機(jī)-服務(wù)器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結(jié)合的方式，通常由 開發(fā)人員承擔(dān)。

-系統(tǒng)測試：測試軟件系統(tǒng)是否符合所有的需求，包括功能性測試和非功能性測試。一般由

獨(dú)立的測試

人員完成，通常采用黑盒測試方法。

-驗(yàn)收測試：(α、β)與系統(tǒng)測試類似，但由客戶或最終用戶執(zhí)行，測試軟件是否符合需求規(guī)格說明書。

-回歸測試：指在軟件開發(fā)過程中，每次錯(cuò)誤被修正后或軟件的功能、環(huán)境發(fā)生變化后進(jìn)行的測試。

-軟件測試的三個(gè)步驟：

-測試計(jì)劃：測試人員首先對(duì)需求進(jìn)行分析，最終定義一個(gè)測試集合，通過刻畫和定義測試發(fā)現(xiàn)需求中的問題，然后根據(jù)軟件需求同測試主管制定并確認(rèn)“測試計(jì)劃”。

-測試設(shè)計(jì)和開發(fā)：軟件測試人員根據(jù)軟件需求和軟件設(shè)計(jì)說明書完成測試用例的設(shè)計(jì)和必要的測試驅(qū)動(dòng) 程序的開發(fā)。

-執(zhí)行測試：需要做的工作包括搭建測試環(huán)境、運(yùn)行測試、記錄測試結(jié)果、報(bào)告軟件缺陷、跟蹤軟件缺陷、分析測試結(jié)果，必要時(shí)進(jìn)行回歸測試。

-測試工程師的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術(shù)

-Critical /'kritikEl/專注于發(fā)現(xiàn)問題

-Comprehensive /.kCmpri'hensiv/ 注意細(xì)節(jié)

-Considerate /kEn'sidErit/能夠和開發(fā)人員很好的交談

+職業(yè)素質(zhì)-責(zé)任心-學(xué)習(xí)能力-懷疑精神-溝通能力-專注力-洞察力-團(tuán)隊(duì)精神-注重積累 +制定測試計(jì)劃的五個(gè)步驟：-分析和測試軟件需求-定義測試策略

-定義測試環(huán)境

-定義測試管理

-編寫和審核測試計(jì)劃

如果在需求分析階段發(fā)現(xiàn)并結(jié)果問題需要花費(fèi)$1，則在設(shè)計(jì)階段解決同樣的問題需花費(fèi)$5，在編碼階段需$10，交付后解決同樣的問題需花費(fèi)$200?！皆鐪y試越好-在需求分析過程中測試人員需要進(jìn)行如下工作：

1)理解需求，參與審核需求文檔；

2)理解項(xiàng)目的目標(biāo)、限制，了解用戶的應(yīng)用背景；

3)編寫測試計(jì)劃；

4)準(zhǔn)備測試資源。

+需求測試

-需求測試測試的對(duì)象是主意而不是代碼，針對(duì)文檔進(jìn)行測試。

+好的需求文檔的特征-具有清晰的格式和文檔結(jié)構(gòu)-需求的內(nèi)容正確-需求的內(nèi)容完整-需求具有可行性需求的必要性

-對(duì)不同的需求優(yōu)先等級(jí)進(jìn)行定義-描述明確-可證性和可測試性-可修改性-可追蹤-需求文檔被及時(shí)更新

+需求測試內(nèi)容

-需求文檔是否符合公司的格式要求

-是否正確

-要保證需求文檔中所描述的內(nèi)容是真實(shí)可靠的-這是“真正的”需求嗎？描述的產(chǎn)品是否是要開發(fā)的產(chǎn)品？

-需求是否完備？第一個(gè)發(fā)布的版本是否需要更多的功能？列出的需求可以減少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可實(shí)現(xiàn)？如：需求設(shè)想的設(shè)備是否比實(shí)際運(yùn)行的要快？需求要求的內(nèi)存、I/0設(shè)備是否太多？

需求的輸入或輸出設(shè)備要求的分辨率是否要求過高？

-需求是否合理？在開發(fā)進(jìn)度、開發(fā)費(fèi)用、產(chǎn)品性能、可靠性和內(nèi)存使用之間存在著平衡關(guān)系。

-需求是否可測？對(duì)于軟件測試人員來說判斷需求是否可測是這個(gè)過程中最重要的工作。+需求測試方法-復(fù)查review-走查walkthrough-審查inspection

+測試策略的內(nèi)容

-確定測試范圍 軟件是無法被完全測試的-確定測試方法 不同的系統(tǒng)需要不同的測試方法

-定義測試標(biāo)準(zhǔn) 入口標(biāo)準(zhǔn)，暫停和繼續(xù)的標(biāo)準(zhǔn)，出口標(biāo)準(zhǔn)等

+軟件測試結(jié)束的標(biāo)準(zhǔn)

-基于測試用例的使用規(guī)則

1)構(gòu)造測試用例（由相關(guān)人員進(jìn)行評(píng)審）

2)執(zhí)行測試用例中，當(dāng)測試用例的不通過率達(dá)到20%則拒絕繼續(xù)測試，待開發(fā)人員修正軟件后再繼續(xù)。

3)當(dāng)功能性測試用例通過率達(dá)到100%，非功能性測試用例通過率達(dá)到90%時(shí)，允許正常結(jié)束。

-基于“測試期缺陷密度”規(guī)則

--------------含義：對(duì)軟件測試一個(gè)CPU小時(shí)發(fā)現(xiàn)的缺陷數(shù)，比較適用于系統(tǒng)測試-基于“運(yùn)行期缺陷密度”規(guī)則

--------------含義：把軟件運(yùn)行一個(gè)CPU小時(shí)發(fā)現(xiàn)的缺陷數(shù)，比較適用于驗(yàn)收測試注：一個(gè)階段的出口標(biāo)準(zhǔn)!=下一個(gè)階段的入口標(biāo)準(zhǔn)

系統(tǒng)測試結(jié)束的標(biāo)準(zhǔn)!=軟件的發(fā)布標(biāo)準(zhǔn)

發(fā)布標(biāo)準(zhǔn)!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價(jià)是企業(yè)普遍關(guān)注的問題，可通過

a.減少冗余和無價(jià)值的測試；

b.減少測試階段(萬般無奈下)

+測試環(huán)境

-基本內(nèi)容：設(shè)備環(huán)境、軟件環(huán)境、數(shù)據(jù)環(huán)境

-需考慮的因素-計(jì)算機(jī)平臺(tái)-操作系統(tǒng)-瀏覽器-軟件支持平臺(tái)-外圍設(shè)備-網(wǎng)絡(luò)環(huán)境-其他專用設(shè)備

-搭建測試環(huán)境時(shí)的配置原則：-使用的頻度或范圍-實(shí)效的可能性-最大限度的模擬真實(shí)環(huán)境 +測試管理 由于測試工程中設(shè)計(jì)的人員、活動(dòng)、工具是很多的，在制定測試計(jì)劃時(shí)需要對(duì)這些因素進(jìn)行管理

-選擇缺陷管理工具和測試管理工具

-定義工作進(jìn)度

-建立風(fēng)險(xiǎn)管理計(jì)劃

+可能遇到的風(fēng)險(xiǎn)

·由于設(shè)計(jì)、編碼階段出現(xiàn)大量質(zhì)量問題，導(dǎo)致測試工作量時(shí)間增加

·開始測試時(shí)所需的硬件、軟件沒有準(zhǔn)備好

·未能完成對(duì)測試人員的技術(shù)培訓(xùn)

·測試時(shí)的人力資源安排不足

·測試過程中，發(fā)生了大量的需求變更

·測試過程中，項(xiàng)目的開發(fā)計(jì)劃被大幅度調(diào)整

·不能及時(shí)準(zhǔn)備好測試所需的環(huán)境

·不能及時(shí)準(zhǔn)備好測試數(shù)據(jù)

+風(fēng)險(xiǎn)管理的過程

·識(shí)別風(fēng)險(xiǎn)

·評(píng)估風(fēng)險(xiǎn)

·制定對(duì)策

·跟蹤風(fēng)險(xiǎn)

+測試設(shè)計(jì)與開發(fā)

+總體設(shè)計(jì)

-投入產(chǎn)出：測試設(shè)計(jì)的輸入是測試計(jì)劃，輸出是評(píng)審過的測試用例集合-定義設(shè)計(jì)目標(biāo)遵循的原則

-清楚地說明沒項(xiàng)測試的目標(biāo)

-使每項(xiàng)測試的目標(biāo)單一，可以對(duì)應(yīng)到規(guī)格說明書中的一項(xiàng)需求

-只說明測試應(yīng)該完成什么工作，而不說明如何完成-流程：總體設(shè)計(jì)-開發(fā)測試用例-評(píng)審測試用例

I.定義設(shè)計(jì)目標(biāo)

II.定義輸入說明

III.定義測試環(huán)境和配置

IV.測試設(shè)計(jì)文檔

V.開發(fā)測試用例

+測試用例

-概念：為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合。

+好的測試用例：

-容易發(fā)現(xiàn)軟件的錯(cuò)誤

-精確的重復(fù)某測試失敗的情景，可重復(fù)性

-清晰的定義一個(gè)或多個(gè)期望的結(jié)果

-沒有冗余

+測試用例的作用

-指導(dǎo)測試的實(shí)施

-作為編寫測試腳本的“設(shè)計(jì)規(guī)格說明書”

-評(píng)估測試標(biāo)準(zhǔn)的度量基準(zhǔn)

-分析缺陷的標(biāo)準(zhǔn)

+白盒測試用例設(shè)計(jì)

+設(shè)計(jì)方法

+邏輯覆蓋法

-語句覆蓋

-判定覆蓋

-條件覆蓋

-判定-條件覆蓋

-條件組合覆蓋

-路經(jīng)覆蓋

-基本路經(jīng)法

+輔助模塊設(shè)計(jì)

-驅(qū)動(dòng)模塊：相當(dāng)于被測程序的主程序。接受測試數(shù)據(jù)，把這些數(shù)據(jù)傳給被測模塊然后輸出實(shí)際測試結(jié)果。

-樁模塊：用于調(diào)用被測模塊調(diào)用的子模塊?？梢宰錾倭康臄?shù)據(jù)操作，不需要把子模塊的所有功能都帶進(jìn)來，但不容許什么都不做。

+黑盒測試用例設(shè)計(jì)

-等價(jià)類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上?！?/p>

-因果圖法彌補(bǔ)等價(jià)類和邊界值法的不足

-錯(cuò)誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實(shí)現(xiàn)，以保證測試是可重復(fù)的。+常見錯(cuò)誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時(shí)更新，不能正確反映數(shù)據(jù)狀態(tài)，甚至對(duì)用戶產(chǎn)生誤導(dǎo)。

·表達(dá)不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統(tǒng)可以自己得到的數(shù)據(jù)。

·為了得到某個(gè)設(shè)置或?qū)υ捒蛴脩舯仨氉鲈S多冗余的操作，如對(duì)話框嵌套太多。·不能記憶用戶的設(shè)置或操作習(xí)慣，使每次進(jìn)入系統(tǒng)用戶都需重新操作一次初始環(huán)境?！げ唤?jīng)用戶確認(rèn)就對(duì)系統(tǒng)或數(shù)據(jù)進(jìn)行了重大修改。

-形象類問題

·不符合用戶的操作習(xí)慣。如，快捷鍵定義不科學(xué)不實(shí)用，甚至無快捷鍵。

·不夠?qū)I(yè)，缺乏基本知識(shí)。

·界面中英文混雜，甚至拼寫錯(cuò)誤。

·說明書或幫助的排版格式不專業(yè)：中英文不對(duì)應(yīng)，標(biāo)點(diǎn)的半全角問題，沒有排版準(zhǔn)則?！そ缑嬖貐⒉畈积R，文字不能完全顯示。

－穩(wěn)定性問題

·不可重現(xiàn)的死機(jī)，或不斷申請但不能完全釋放資源，使系統(tǒng)性能越來越低。

·主系統(tǒng)和子系統(tǒng)使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時(shí)文件名、使用同樣的數(shù)據(jù)庫字段名或登陸帳號(hào)。

·不能重現(xiàn)的錯(cuò)誤，許多與代碼中的未初始化變量有關(guān)，有些與系統(tǒng)不檢查異常情況(網(wǎng)絡(luò)中斷、內(nèi)存申請

不成功、長時(shí)間無響應(yīng)等)有關(guān)。

-其他問題

·運(yùn)行時(shí)不檢查內(nèi)存、硬盤空間、數(shù)據(jù)庫等。

·無根據(jù)的假設(shè)用戶環(huán)境：硬件/網(wǎng)絡(luò)情況；有些動(dòng)態(tài)庫；假設(shè)網(wǎng)絡(luò)隨時(shí)都是聯(lián)通的?！ぬ峁┑陌姹編Р《?。

·提供錯(cuò)誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現(xiàn)場開放和修改，又沒有記錄和保留。

·版本中部分內(nèi)容或接口倒退，或出現(xiàn)版本管理混亂。

·有些選項(xiàng)永遠(yuǎn)都是灰的，或有些在該變灰時(shí)沒變灰。

+測試用例的評(píng)審

-測試或測試組件完全針對(duì)的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個(gè)測試步驟都有清楚描述的預(yù)期結(jié)果嗎？

+優(yōu)先級(jí)

+3級(jí)

優(yōu)先級(jí)1：此測試用例必須執(zhí)行-2：有時(shí)間就執(zhí)行-3：可以不執(zhí)行

+5級(jí)

1：此測試必須通過，否則產(chǎn)品發(fā)布存在危險(xiǎn)2：在發(fā)布前必須執(zhí)行3：時(shí)間允許就執(zhí)行4：此測試可以在下一次發(fā)布或發(fā)布后短期內(nèi)執(zhí)行5：可以不測試

第五篇：《軟件分析與測試》實(shí)驗(yàn)報(bào)告范例.doc

《軟件分析與測試》實(shí)驗(yàn)一：白盒測試實(shí)驗(yàn)報(bào)告

一、實(shí)驗(yàn)?zāi)康?、通過簡單程序白盒測試，熟悉測試過程，對(duì)軟件測試行程初步了解，并養(yǎng)成良好的測試習(xí)慣。

2、熟練掌握如何運(yùn)用基路徑測試方法進(jìn)行測試用例設(shè)計(jì)，進(jìn)行邏輯覆蓋率分析。

二、實(shí)驗(yàn)內(nèi)容<測試內(nèi)容的描述>

……

三、實(shí)驗(yàn)原理

白盒測試原理：分析程序的內(nèi)部邏輯結(jié)構(gòu)，選擇適當(dāng)?shù)母采w標(biāo)準(zhǔn)，設(shè)計(jì)測試用例，對(duì)主要路徑進(jìn)行盡可能多的測試。白盒測試測試用例一般采用邏輯覆蓋法進(jìn)行設(shè)計(jì)。

語句覆蓋：選擇足夠的測試用例，使得程序中每個(gè)語句至少都能被執(zhí)行一次。

判定覆蓋：執(zhí)行足夠的測試用例，使得程序中每個(gè)判定至少都獲得一次“真”值和“假”值。

條件覆蓋：執(zhí)行足夠的測試用例，使得所有判定中的每個(gè)條件至少都獲得一次“真”值和“假”值。

判定/條件覆蓋：執(zhí)行足夠的測試用例，使得判定中每個(gè)條件取到各種可能的值，并使每個(gè)判定取到各種可能的結(jié)果。

條件組合覆蓋：執(zhí)行足夠的例子，使得每個(gè)判定中條件的各種可能組合都至少出現(xiàn)一次。

路徑覆蓋：路徑覆蓋是相當(dāng)強(qiáng)的邏輯覆蓋，它保證程序中每條可能的路徑都至少執(zhí)行一次。

四、實(shí)驗(yàn)步驟：

1、測試程序源代碼

……

2、測試程序流程圖

……

3、測試用例設(shè)計(jì)

……<要求分別使用語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合測試、路徑覆蓋（及完全覆蓋）方法設(shè)計(jì)測試用例>

4、測試用例分析

……<比較各種設(shè)計(jì)方法，給出結(jié)論>

五、總結(jié)與體會(huì)

……

《軟件分析與測試》實(shí)驗(yàn)二：黑盒測試實(shí)驗(yàn)報(bào)告

一、實(shí)驗(yàn)?zāi)康?、系統(tǒng)地學(xué)習(xí)和理解黑盒測試的基本概念、原理，掌握黑盒測試的基本技術(shù)和方法。

2、通過試驗(yàn)和應(yīng)用，要逐步提高和運(yùn)用黑盒測試技術(shù)解決實(shí)際測試問題的能力。

二、實(shí)驗(yàn)內(nèi)容<測試內(nèi)容的描述>

……

三、實(shí)驗(yàn)原理

黑盒測試原理：不考慮程序的內(nèi)部結(jié)構(gòu)與特性，只根據(jù)程序功能或程序的外部特性設(shè)計(jì)測試用例。

等價(jià)分類法：根據(jù)程序的I/O特性，將程序的定義域劃分為有限個(gè)等價(jià)區(qū)段 —“等價(jià)類”，從等價(jià)類中選擇出的用例，具有“代表性”。應(yīng)按照輸入條件（如輸入值的范圍，值的個(gè)數(shù)，值的集合，輸入條件必須如何）劃分為有效等價(jià)類和無效等價(jià)類。有效等價(jià)類，對(duì)于程序的規(guī)格說明是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。無效等價(jià)類，對(duì)于程序的規(guī)格說明，是不合理的，是沒有意義的輸入數(shù)據(jù)構(gòu)成的集合。

邊值分析法：選擇等價(jià)類的邊緣值作為測試用例，讓每個(gè)等價(jià)類的邊界都得到測試，選擇測試用例既考慮輸入亦考慮輸出。

決策表：在一些數(shù)據(jù)處理問題當(dāng)中，某些操作的實(shí)施依賴于多個(gè)邏輯條件的組合，即：針對(duì)不同邏輯條件的組合值，分別執(zhí)行不同的操作。最適合描述在多邏輯條件取值的組合所構(gòu)成的復(fù)雜情況下，分別執(zhí)行哪些不同的動(dòng)作。

因果圖法：一些程序的功能可以用判定表（或稱決策表）的形式來表示，并根據(jù)輸入條件的組合情況規(guī)定相應(yīng)的操作。它是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

四、實(shí)驗(yàn)步驟：

1、測試用例設(shè)計(jì)

……<要求分別使用等價(jià)分類法、方法邊值分析法、因果圖法、決策表設(shè)計(jì)測試用例>

2、測試用例分析

……<比較各種設(shè)計(jì)方法，給出結(jié)論>

五、總結(jié)與體會(huì)

……

《軟件分析與測試》實(shí)驗(yàn)三：測試自動(dòng)化實(shí)驗(yàn)報(bào)告

一、實(shí)驗(yàn)?zāi)康?、系統(tǒng)地學(xué)習(xí)和理解測試自動(dòng)化的基本概念，掌握測試自動(dòng)化的基本技術(shù)和方法。

2、通過試驗(yàn)和應(yīng)用，要逐步提高和運(yùn)用測試自動(dòng)化工具解決實(shí)際測試問題的能力。

二、實(shí)驗(yàn)內(nèi)容<測試內(nèi)容的描述>

……

三、實(shí)驗(yàn)環(huán)境

在Eclipse集成開發(fā)環(huán)境中使用JUnit來作為自動(dòng)化的功能測試工具。Eclipse本身集成了JUnit相關(guān)組件，并對(duì)JUnit的運(yùn)行提供了無縫的支持。

JUnit是一個(gè)開放源代碼的Java測試框架，用于編寫和運(yùn)行可重復(fù)的測試。他是用于單元測試框架體系xUnit的一個(gè)實(shí)例（用于java語言）。它包括以下特性：

1、用于測試期望結(jié)果的斷言（Assertion）

2、用于共享共同測試數(shù)據(jù)的測試工具

3、用于方便的組織和運(yùn)行測試的測試套件

4、圖形和文本的測試運(yùn)行器

Eclipse 是一個(gè)開放源代碼的、基于 Java 的可擴(kuò)展開發(fā)平臺(tái)。就其本身而言，它只是一個(gè)框架和一組服務(wù)，用于通過插件組件構(gòu)建開發(fā)環(huán)境。幸運(yùn)的是，Eclipse 附帶了一個(gè)標(biāo)準(zhǔn)的插件集，包括 Java 開發(fā)工具（Java Development Tools，JDT）。

四、實(shí)驗(yàn)步驟：

1、測試過程

……

2、測試分析

……

五、總結(jié)與體會(huì)

……

//注釋：

1、省略號(hào)為自定義部分,需要補(bǔ)充完整；

2、<>中內(nèi)容為說明文字部分；

3、其他文字要求都寫入報(bào)告中（包括 注釋1中的內(nèi)容）。