【正文】 同時，感謝所有任課老師和所有同學(xué)在這 三 年來給自己的指導(dǎo)和幫助，是他們教會了我專業(yè)知識，教會了我如何學(xué)習(xí)，教會了我如何做人。 ○12 王軼辰，軟件測試從入門到精通 [M].北京：電子工業(yè)出版社， 20xx 版，第 380 頁 。 ○ 6 ○ 7 張路 ,軟件性能測試和可靠性測試 .高等教育出版社， 20xx 版，第 175~184 頁 。 ○ 2 朱少民 ,全程軟件測試 [M].北京 :電子工業(yè)出版社 ,20xx 版，第 275 頁 。 [13]蔡開元，可靠性工程基礎(chǔ) [M]，北京：清華大學(xué)出版社， ， 1995 版，第 228 頁 。 [8] 何國偉 ,王緯 .軟件可靠性 [M].北京 :國防大學(xué)出版社 ,1998 版 第 200~300 頁 。 [3]袁玉宇 .軟件測試與質(zhì)量保證 [M].北京 :北京郵電大學(xué)出版社 ,20xx 版，第 382 頁 。 對性能測試的目標(biāo)、分析與性能測試工具進(jìn)行了解釋，明確了測試了目的。目前，軟件測試最核心的技術(shù)是用例技術(shù)，用例是當(dāng)前承載這種規(guī)則和技術(shù)的唯一手段。插人事務(wù)、插入結(jié)合點、插入注解、參數(shù)化輸入。腳本可分 INIT、ACTION、 END 三部分，其中： INIT 部分可以理解為初始部分。 LoadRunner 由下面三部分組成： Virtual UserGenerator 用來錄制腳本、編輯腳本Controller 用來布置測試場景、執(zhí)行測試場景； Analysis 用來對測試結(jié)果進(jìn)行分析。 LoadRunner 是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。一個優(yōu)秀的軟件測試工具，不僅可以輔助測試工作，滿足科學(xué)測試的基本要求；而且可以自動化測試過程，節(jié)約大量的時間、成 本、人員和資源，提高軟件產(chǎn)品的質(zhì)量。開 發(fā)團隊和性能測試團隊?wèi)?yīng)依據(jù)對性能測試實施過程中監(jiān)控和記錄的數(shù)據(jù)和表格，分析系統(tǒng)中存在的性能問題和程序缺陷。一般來說，性能急劇下降區(qū)的起始點（也稱性能拐點 ）就是性能瓶頸出現(xiàn)的地方，此時進(jìn)一9 步分析資源利用率就可以找到造成性能瓶頸的原因 [13]。而該指標(biāo)對于性能分析和性能調(diào)優(yōu)有重要的參考意義。所謂性能下降曲線，就是指性能指標(biāo)隨用戶的增加而變化的曲線，由于性能總體來說是隨用戶數(shù)的增加而下降的，故稱為性能下降曲 線。人們一般 不把調(diào)試看做測試的一個環(huán)節(jié)，但測試的確應(yīng)該為調(diào)試提供更多幫助，否則即使發(fā)現(xiàn)軟件中有錯誤也不得不發(fā)布包含錯誤的軟件。由于性能缺陷的揭示必須基于整個系統(tǒng)的運行，此時的性能測試一般是伴隨系統(tǒng)測試進(jìn)行的。 在對邊界值設(shè)計測試用例時應(yīng)遵循以下基本原則： 1) 若輸入條件規(guī)定了值的范圍，則應(yīng)取剛達(dá)到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)； 2) 若輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)； 3) 若程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個原則作為測試數(shù)據(jù)； 4) 若程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試數(shù)據(jù)。 邊界值分析法 邊界值分析法用于列出單元功能、輸入、狀態(tài)及控制的合法邊界值和非法邊界值，對數(shù)據(jù)進(jìn)行測試，檢查用戶輸入的信息、返回結(jié)果以及中間計算結(jié)果是否正確。等價類可分為有效等價類和無 效等價類。每一子集合代的代表性數(shù)據(jù)在測試中的作用都是等效于這一子集合中的其他值。 BUG 管理階段是功能測試中非常重要的階段，只有將發(fā)現(xiàn)的缺陷處理好，才能真正改善軟件功能質(zhì)量。 BUG 管理 BUG 管理階段是對已發(fā)現(xiàn)的軟件缺陷進(jìn)行確認(rèn)、上報、跟蹤、回歸的過程 [10]。建立出的測試用例集可 以作為執(zhí)行測試時每一步操作的依據(jù)，并記錄測試執(zhí)行的結(jié)果以備分析缺陷情況使用。 6 因此，測試需求分析階段就 是對用戶需求的理解過程，通過研究需求分析文檔把用戶想要哪些功能摸清，把用戶對于每個功能想要達(dá)到的目標(biāo)摸清，就完成了測試需求的分析。圖 24 給出一個性能測試的過程模型 —— 性能測試通用模型（ Performance Testing General Model,PTGM） ,該模型的實質(zhì)是將針對功能測試的自動化測試模型進(jìn)行適當(dāng)調(diào)整，以適應(yīng)性能測試的需要，在第四章中進(jìn)行詳細(xì)介紹 [9] 圖 24 PTGM 模型示意圖 3. 功能性 測試方法 功能性測試流程 功能性測試按步驟可劃分為 7 個部分，即獲取測試系統(tǒng)、測試方法選定、進(jìn)行測試需求分析、功能點分解、建立測試用例、測試執(zhí)行、 BUG 管理。 圖 23 基于 V 模型的功能測試 V 模型是標(biāo)準(zhǔn)的軟件開發(fā)模型，具備完善的各類設(shè)計與文檔，功能測試階段具有自己獨立的測試參考標(biāo)準(zhǔn) —— 概要設(shè)計，因此在進(jìn)行功能測試的時候只需要分析概要設(shè)計中對軟件功能的描述，即可對系統(tǒng)進(jìn)行測試 [6]。 V 模型中的功能測試被定義在了整個軟件開發(fā)過程的后半部分，它強調(diào)了測試活動與軟件設(shè)計間的關(guān)系，將軟件實現(xiàn)和驗證有機的結(jié)合起來，以確保較高的軟件質(zhì)量。 根據(jù)以上分析，基于原型模型的功能測試應(yīng)如圖 22 所示。因此為了做到有計劃有針對性，在不同軟件開發(fā)模式下都應(yīng)當(dāng)有相對應(yīng)的軟件開發(fā)模型，使得測試工作能夠滿足整個軟件制造流程的風(fēng)格要求，并且能與各階段順暢銜接。 圖 21 顯示了功能測試 與性能測試 在軟件測試過程中的定位，及測試進(jìn)行的順序。 軟件的功能性測試是在單元測試與集成測試完成后進(jìn)行的一項檢驗軟件功能是否符合預(yù)期要求及功能正確性的測試過程 [7]。 5. 對功能測試與性能測試方法進(jìn)行總結(jié)，并結(jié)合在實習(xí)單位測試功能中總結(jié)經(jīng)驗教訓(xùn) 2 功能 性 測試基本理論 軟 件功能測試的定義 早期的測試?yán)碚撏ǔＪ褂煤诤袦y試的概念定義功能性測試，但經(jīng)過測試技術(shù)的不斷發(fā)展，僅以功能性測試作為黑盒測試的全部過程已經(jīng)不能滿足軟件質(zhì)量的要求，因此功能性測試的內(nèi)容被更加細(xì)化，目標(biāo)及其定義也變得更加明確。 1. 介紹課題來源、研究背景、國內(nèi)外研究現(xiàn)狀以及論文的目標(biāo)與主要內(nèi)容。然而，無論是傳統(tǒng)還是最新的軟件測 試?yán)碚摵图夹g(shù)，在軟件測試管理、測試過程的理解和實施方法上仍然存在著局限性，因此，在實施測試過程改進(jìn)的工作中，不能 直接照搬他人的成功經(jīng)驗，要結(jié)合所在組織和具體項目研究適用有 的 改進(jìn)方法。近年來，國外 在軟 件測試過程方面的理論和技術(shù)上均有了很大的發(fā)展，形成了一套較為完善的 [3]軟件測試過程技術(shù)和管理理論體系，測試方法與手段日趨成熟和多樣化。壓力測試是通過確定一個 系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試 。因此功能測試行為必須能夠加以量化，才能真正保證軟件功能的 質(zhì)量。因此為了滿足 這樣的要求，應(yīng)運而生了軟件功能性測試技術(shù) 與軟件性能性測試技術(shù) [1]。 軟件功能性是為了發(fā)現(xiàn)軟件功能錯誤而執(zhí)行程序的過程，因此軟件功能性測試目的就是盡可能多地發(fā)現(xiàn)并改正軟件中的功能錯誤，以提高軟件質(zhì)量。研究了軟件系統(tǒng)性能測試的整體的流程，并結(jié)合自動化測試工具 LoadRunner，對軟件性能測試的相關(guān)信息進(jìn)行了分析。理論上軟件本身的缺陷都可在功能性測試階段被暴露，因此軟件功能性測試方法是提高軟件可靠性及軟件質(zhì)量最有效、最直接的方法之一。 本文對軟件功能測試的概念以及主要的實現(xiàn)方法進(jìn)行了研究。 [關(guān)鍵詞 ] 功能性測試 ， 測試流程 ， 性能測試 ， 測試工具