軟件評測師教程筆記之第2章軟件測試基礎(chǔ)

第2章軟件測試基礎(chǔ) 1、什么是軟件測試 測試（test）被當作一個常規(guī)的檢驗產(chǎn)品質(zhì)量的生產(chǎn)活動。測試的含義為“為檢驗產(chǎn)品是否滿意需求為目標”。 “軟件測試”的經(jīng)典定義是在規(guī)定條件下對程序進行操作，以發(fā)覺錯誤，對軟件質(zhì)量進行評估。 軟件是由文檔、數(shù)據(jù)以及程序組成的，那么軟件測試就應(yīng)當是對軟件形成過程的文檔、數(shù)據(jù)以及程序進行的測試，而不僅僅是對程序進行的測試。 2、什么是軟件質(zhì)量 ISO9126中定義的“軟件質(zhì)量”是：軟件滿意規(guī)定或潛在用戶需求特性的總和。 ISO14598中“軟件質(zhì)量”定義是：軟件特性的總和，軟件滿意規(guī)定或潛在用戶需求的實力。 ISO9126定義的軟件質(zhì)量包括“內(nèi)部質(zhì)量”、“外部質(zhì)量”、“運用質(zhì)量”三部分。也就是說，“軟件滿意規(guī)定或潛在用戶需求的實力”要從軟件在內(nèi)部、外部和運用中的表現(xiàn)來衡量。 3、軟件測試是在規(guī)定條件下對程序進行操作，以發(fā)覺錯誤，對軟件質(zhì)量進行評估。 4、軟件質(zhì)量定義是：軟件特性的總和，軟件滿意規(guī)定或潛在用戶需求的實力。 軟件質(zhì)量包括：內(nèi)部質(zhì)量、外部質(zhì)量、運用質(zhì)量三個部分。 5、軟件測試與質(zhì)量保證的區(qū)分： 質(zhì)量保證（QA）質(zhì)量保證的重要工作通過預(yù)防、檢查與改進來保證軟件質(zhì)量。QA采納“全面質(zhì)量管理”和“過程改進”的原理開展質(zhì)量保證工作。關(guān)注軟件質(zhì)量的檢查與測量。 軟件測試也與軟件開發(fā)過程緊密相關(guān)，關(guān)切的不是過程的活動，而是對過程的產(chǎn)物以及開發(fā)出的軟件進行剖析。測試員要“執(zhí)行”軟件，對過程中的產(chǎn)物開發(fā)文檔和源代碼進行走查，運行軟件，以找出問題，報告質(zhì)量。對測試中發(fā)覺的問題的分析、追蹤和回來測試。軟件測試是保證軟件質(zhì)量的一個重要環(huán)節(jié)。 6、軟件測試目的 測試目的三個觀點： 測試是程序的執(zhí)行過程，目的在于發(fā)覺錯誤； 一個好的測試用例在于能發(fā)覺至今未發(fā)覺的錯誤； 一個勝利的測試是發(fā)覺了至今未發(fā)覺的錯誤的測試； 測試的目的，是想以最少的人力、物力和時間找出軟件潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷 提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造居的隱患所帶來的商業(yè)風險。 測試是對軟件質(zhì)量的度量與評價，以驗證軟件的質(zhì)量滿意用戶的需求的程度，為用戶選擇與接受軟件供應(yīng)有力的依據(jù)。 7、軟件測試原則 全部的軟件測試都應(yīng)追溯到用戶需求。 應(yīng)當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座左銘。 完全測試是不行能的，測試須要終止。     在有限的時間和資源條件下，軟件趨于完備，是不行能的。主要有三個緣由：     軟件入量太大；     輸出結(jié)果太多；     路徑組合太多。 測試無法顯示軟件潛在的缺陷 充分留意測試中的群集現(xiàn)象。 程序員應(yīng)避開檢查自己的程序。 盡量避開測試的隨意性。（應(yīng)當從工程的角度去理解軟件測試，它是有組織、有支配、步驟的活動。） 8、軟件測試對象 依據(jù)軟件定義，軟件包括程序、數(shù)據(jù)和文檔，所以軟件測試并不僅僅是程序測試。 在軟件編碼結(jié)束后，對編寫的每一個程序模塊進行測試，稱為模塊測試或單元測試。 在模塊集成后，對集成在一起模塊組件，有時稱為部件，進行測試，稱為集成測試。 在集成測試后，須要檢測與證明軟件是否滿意軟件需求說明書中規(guī)定的要求，稱為確認測試。 將整個程序模塊集成為軟件系統(tǒng)，安裝在運行環(huán)境下，對硬件、網(wǎng)絡(luò)、操作系統(tǒng)及支撐平臺構(gòu)成的整體系統(tǒng)進行測試，稱為系統(tǒng)測試。 軟件錯誤中，屬于需求分析和軟件設(shè)計的錯誤約為64%，屬于程序編寫的錯誤僅占36%。 驗證（verification）是保證軟件正的確現(xiàn)特定功能的一系列活動和過程，目的是保證軟件生命周期中的每一個階段的成果滿意上一個階段所設(shè)定的目標。 確認（validation）是保證軟件滿意用戶需求的一系列的活動和過程，目的是在軟件開發(fā)完成后保證軟件與用戶需求相符合。 驗證與確認都屬于軟件測試，它包括對軟件分析、設(shè)計以及程序的驗證和確認。 需求分析、概要設(shè)計、具體設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、具體設(shè)計規(guī)格說明以及源程序，都應(yīng)成為“軟件測試”的對象。在軟件編碼結(jié)束后，對編寫的每一個程序模塊進行測試，稱為“模塊測試”或“單元測試”；在模塊集成后，對集成在一起的模塊組件，有時也可稱為“部件”，進行測試，稱為“集成測試”；在集成測試后，須要檢測與證明軟件是否滿意軟件需求說明書中規(guī)定的要求，稱為“確認測試”。將整個程序模塊集成為軟件系統(tǒng)，安裝在運行環(huán)境下，對硬件、網(wǎng)絡(luò)、操作系統(tǒng)及支撐平臺構(gòu)成的整體系統(tǒng)進行測試，稱為“系統(tǒng)測試”。 測試過程按4個步驟進行，即單元測試、集成（組裝）測試、確認測試和系統(tǒng)測試。 9、軟件測試分類 依據(jù)開發(fā)階段劃分軟件測試可分為：單元測試、集成測試、系統(tǒng)測試、確認測試和驗收測試。 單元測試：單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位——程序模塊進行正確性檢驗的測試工作。其目的在于檢查每個程序單元能否正的確現(xiàn)具體設(shè)計說明中的模塊功能、性能、接口和設(shè)計約束等要求，發(fā)覺各模塊內(nèi)部可能存在的各種錯誤。單元測試須要從程序的內(nèi)部結(jié)構(gòu)動身設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。 集成測試：也叫組裝測試。通常在單元測試的基礎(chǔ)上，將全部的程序模塊進行有序的、遞增的測試。集成測試是檢驗程序單元或部件的接口關(guān)系，逐步集成為符合概要設(shè)計要求的程序部件或整個系統(tǒng)。 確認測試：就是通過檢驗和供應(yīng)客觀證據(jù)，證明軟件是否滿意特定預(yù)期用途的要求。確認測試是檢測與證明軟件是否滿意軟件需求說明書中規(guī)定的要求。 系統(tǒng)測試：它是為驗證和確認系統(tǒng)是否達到其原始目標，而對集成的硬件和軟件系統(tǒng)進行的測試。系統(tǒng)測試是在真實或模擬系統(tǒng)運行的環(huán)境下，檢查完整的程序系統(tǒng)能否（包括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺等）正確配置、連接，并滿意用戶需求。 驗收測試：依據(jù)項目任務(wù)書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，確定是否接收或拒收系統(tǒng)。 l 依據(jù)開發(fā)階段劃分 Ø 單元測試。 單元測試又稱模塊測試，是針對程序模塊進行正確性檢驗的測試工作。 Ø 集成測試 集成測試也叫組裝測試。通常在單元測試的基礎(chǔ)上，將全部的程序模塊進行有序的、遞增的測試。集成測試是檢驗程序或部件的接口關(guān)系，逐步集成為符合概要設(shè)計要求的程序部件或整個系統(tǒng)。 冒煙測試也叫驗證測試、提交測試。 Ø 確認測試 確認測試是通過檢驗和供應(yīng)客觀證據(jù)，證明軟件是否滿意特定預(yù)期用途的需求。確認測試是檢測與證明軟件是否滿意軟件需求說明書中規(guī)定的要求。 Ø 系統(tǒng)測試 系統(tǒng)測試是為驗證和確認系統(tǒng)是否達到其原始目標，而對集成的硬件和軟件系統(tǒng)進行的測試。系統(tǒng)測試是在真實或模擬系統(tǒng)運行的環(huán)境下，檢查完整的程序系統(tǒng)能否和系統(tǒng)（包括硬件、外設(shè)、網(wǎng)絡(luò)和系統(tǒng)軟件、支持平臺等）正確配置、連接、并滿意用戶需求。 Ø 驗收測試 依據(jù)項目任務(wù)書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，確定是否接收或拒收系統(tǒng)。 l 依據(jù)測試實施組織劃分 依據(jù)測試實施組織劃分，軟件測試可分為開發(fā)方測試、用戶測試（Beta測試）、第三方測試。 （1）開發(fā)方測試 通常也叫“驗證測試”或“α測試”。驗證測試是在軟件開發(fā)環(huán)境下，由開發(fā)者檢測與證明軟件的實現(xiàn)是否滿意軟件設(shè)計說明或軟件需求說明的要求。主要是指在軟件開發(fā)完成以后，開發(fā)方對要提交的軟件進行全面的自我檢查與驗證，可以和軟件的“系統(tǒng)測試”一并進行。 （2）用戶測試 在用戶的應(yīng)用環(huán)境下，用戶通過運行和運用軟件，檢測與核實軟件實現(xiàn)是否符合自己預(yù)期的要求。用戶測試不是指用戶的“驗收測試”，而是指用戶的運用性測試，由用戶找出軟件的應(yīng)用過程中發(fā)覺的軟件的缺陷與問題，并對運用質(zhì)量進行評價。 （3）第三方測試 介于軟件開發(fā)方和用戶方之間的測試組織的測試。一般狀況下是在模擬用戶真實應(yīng)用環(huán)境下，進行軟件確認測試。 l 依據(jù)測試技術(shù)劃分 依據(jù)測試技術(shù)劃分：白盒測試、黑盒測試、灰盒測試。也可劃分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試是指不運行程序，通過人工對程序和文檔進行分析與檢查：靜態(tài)測試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測試事實上是對軟件中的需求說明書、設(shè)計說明書、程序源代碼等進行非運行的檢查，靜態(tài)測試包括：走查、符號執(zhí)行、需求確認等。動態(tài)測試是指通過人工或運用工具運行程序進行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。 （1）白盒測試 通過對程序內(nèi)部結(jié)構(gòu)的分析、檢測來找尋問題。了解程序結(jié)構(gòu)和處理過程，檢查是否全部的結(jié)構(gòu)及路徑都是正確的，檢查軟件內(nèi)部動作是否依據(jù)設(shè)計說明的規(guī)定正常進行。 （2）黑盒測試 通過軟件的外部表現(xiàn)來發(fā)覺其缺陷和錯誤。黑盒測試法把測試對象看成一個黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序界面處進行測試，它只是檢查程序是否依據(jù)需求規(guī)格說明書的規(guī)定正常實現(xiàn)。 （3）灰盒測試 灰盒測試關(guān)注輸出對于輸入的正確性 Ø 靜態(tài)測試 它是指不運行程序，通過人工對程序和文檔進行分析與檢查； 靜態(tài)測試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測試事實上是對軟件中的需求說明書、設(shè)計說明書、程序源代碼等進行非運行檢查， 靜態(tài)測試包括：走查、符號執(zhí)行、需求確認等。 Ø 動態(tài)測試 它是指通過人工或運用工具運行程序進行檢查、分析程序的執(zhí)行狀態(tài)和程序的外部表現(xiàn)。 Ø 白盒測試 又稱結(jié)構(gòu)測試。通過對程序內(nèi)部結(jié)構(gòu)的分析、檢測來找尋問題。 Ø 黑盒測試 通過軟件的外部表現(xiàn)來發(fā)覺其缺陷和錯誤。它是在程序界面處進行測試，它只是檢查樣序是否依據(jù)需求規(guī)格說明書的規(guī)定正常實現(xiàn)。 10、軟件測試過程模型 Ø V模型 它反映了測試活動與分析和設(shè)計的關(guān)系，從左到右，描述了基本的開發(fā)過程和測試行為，特別明確地標明白測試過程中存在的不同級別，并且清晰地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系，如圖所示，圖中的箭頭代表了時間方向，左邊下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊上升的部分，即各測試過程的各個階段。 V模型指出，單元和集成測試是驗證的程序設(shè)計，檢測程序的執(zhí)行是否滿意軟件設(shè)計的要求； 系統(tǒng)測試應(yīng)當驗證系統(tǒng)設(shè)計，檢測系統(tǒng)功能、性能的質(zhì)量特性是否達到系統(tǒng)設(shè)計的指標； 測試員和用戶進行軟件的確認測試和驗收測試，追溯軟件需求說明書進行測試，以確定軟件的實現(xiàn)是否滿意用戶需求或合同的要求。 V模型存在肯定的局限性，它僅僅是測試過程作為在需求分析、概要設(shè)計、具體設(shè)計及編碼后的一個階段。需求分析階段隱藏的問題始終到后期的驗收測試才被發(fā)覺。 V模型的軟件測試策略既包括低層測試又包括了高層測試，低層測試是為了源代碼的正確性，高層測試為了使整個系統(tǒng)滿意用戶的需求。 Ø W模型 1、W模型建立 V模型的局限性在于沒有明確地說明早期的測試，不能體現(xiàn)“盡早地和不斷地進行軟件測試”的原則。在V模型中增加軟件各開發(fā)階段應(yīng)同步進行的測試，被演化為一種W模型，因為事實上開發(fā)是“V”，測試也是與此相并行的“V”?；凇氨M早地和不斷地進行軟件測試”的原則， 優(yōu)點： 測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計同樣要測試。 體現(xiàn)“盡早地和不斷地進行軟件測試”的原則。 在V模型中增加軟件和開發(fā)階段應(yīng)同步進行的測試。 局限性： 軟件開發(fā)和測試保持一種線性的前后關(guān)系，須要有嚴格的指令表示上一階段完全結(jié)束，才可正式起先下一個階段。這就無法支持迭代、自發(fā)性以及變更調(diào)整。 2、W模型應(yīng)用 它強調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計同樣要測試。只要相應(yīng)的開發(fā)活動完成，我們就可以起先執(zhí)行測試，可以說，測試與開發(fā)是同步進行的，有利于盡早地發(fā)覺問題。以需求為例，需求分析一完成，我們就可以對需求進行測試，而不是等到最終才進行針對需求的驗收測試。 參加前期工作的測試者可以預(yù)先估計問題和難度，這將可以顯著地削減總體測試時間，加快項目進度。 依據(jù)W模型的要求，一旦有文檔供應(yīng)，就要剛好確定測試條件，以及編寫測試用例。 W模型也是有局限性。W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動。同樣的，軟件開發(fā)和測試保持一種線性的前后關(guān)系，須要有嚴格的指令表示上一階段完全結(jié)束，才可正式起先下一個階段。這樣就無法支持迭代、自發(fā)性以及變更調(diào)整。 Ø H模型 1、H模型建立 它將測試活動獨立出來，形成一個完全獨立的流程，將測試打算活動和測試執(zhí)行活動清晰地體現(xiàn)出來。 2、H模型應(yīng)用 軟件測試不僅僅指測試的執(zhí)行，還包括很多其他的活動。 軟件測試是一個獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行。 軟件測試要盡早打算，盡早執(zhí)行。 軟件測試是依據(jù)被測物的不同而分層次進行的。不同層次的測試活動可以是依據(jù)某個次序先后進行的，但也可能是反復(fù)的。 在H模型中，軟件測試模型是一個獨立的流程，貫穿于整個產(chǎn)品周期，與其他流程并發(fā)地進行。 Ø 其他模型 1、 X模型 該模型定位了探究性測試。 Marick對V模型最主要指責是V模型無法引導(dǎo)項目全部過程。他認為一個模型必需能處理開發(fā)的全部方面，包括交接、頻繁重復(fù)的集成以及需求文檔的缺乏等。 2、前置測試模型 它是一個將測試和開發(fā)緊密結(jié)合的模型，該模型供應(yīng)了輕松的方式，可使你的項目加快速度。 前置測試模型體現(xiàn)了以下的要點： （1）開發(fā)和測試相結(jié)合；前置測試模型將開發(fā)和測試的生命周期整合在一起，標識了項目生命周期從起先到結(jié)束之間的關(guān)鍵行為。 （2）對每一個交付內(nèi)容進行測試；每一個交付的開發(fā)結(jié)果都必需通過肯定的方式進行測試。 （3）在設(shè)計階段進行測試支配和測試設(shè)計；設(shè)計階段是作測試支配和測試設(shè)計的最好時機。 （4）測試和開發(fā)結(jié)合在一起；前置測試將測試執(zhí)行和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼——測試——編碼——測試的方式來體現(xiàn)。 （5）讓驗收測試和技術(shù)測試保持相互獨立。驗收測試應(yīng)當獨立于技術(shù)測試，這樣可以供應(yīng)雙重的保險，以保證設(shè)計及程序編碼能夠符合最終用戶的需求。 10、軟件生命周期測試策略 Ø 軟件開發(fā)與軟件測試 軟件開發(fā)的過程是一個自頂向下，逐步細化的過程。 測試過程則是依照相反的依次支配自底向上，逐步集成的過程。 Ø 軟件測試策略 測試過程按4個步驟進行，即單元測試、集成（組裝）測試、確認測試和系統(tǒng)測試。 1、測試信息流 測試過程須要以下三類輸入： 軟件配置：包括軟件需求規(guī)格說明、軟件設(shè)計規(guī)格說明、源代碼等。 測試配置：包括測試支配、測試用例、測試驅(qū)動程序等。測試配置只是軟件配置的一個子集。 測試工具： 2、分析設(shè)計階段 分析設(shè)計階段的測試工作是評審與測試相結(jié)合的過程，主要包括需求說明書評測、概要設(shè)計說明書、具體設(shè)計說明書評測以及軟件編碼規(guī)范評測等。 編制良好的需求說明書8條原則： 功能與實現(xiàn)分別； 要求運用面對處理的規(guī)格說明語言； 描述該目標軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式； 規(guī)格說明必需包括系統(tǒng)運行的環(huán)境； 系統(tǒng)規(guī)格說明必需是一個相識的模型； 規(guī)格說明必需是可操作的； 規(guī)格說明必需容許不完備性并允許擴充； 規(guī)格說明必需局部化和松散的耦合。 （1）需求說明書評測 需求說明書是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、具體的功能和行為描述、性能需求和設(shè)計約束的說明、性能需求和設(shè)計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。 需求說明書評測內(nèi)容： 系統(tǒng)定義的目標是否與用戶的要求一樣。 系統(tǒng)需求分析階段供應(yīng)的文檔資料是否齊全。 文檔中的全部描述是否完整、清晰、精確地反映用戶要求； 與全部其他系統(tǒng)成份的重要接口是否都已經(jīng)描述； 被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定； 全部圖表是否清晰，在不補充說明時能否理解； 主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明； 軟件的行為和它必需處理的信息、必需完成的功能是否一樣； 設(shè)計的約束條件或限制條件是否符合實際； 是否考慮了開發(fā)的技術(shù)風險； 是否考慮過軟件需求的其他方案； 是否考慮過將來可能會提出的軟件需求； 是否具體制定了檢驗標準，它們能否對系統(tǒng)定義是否勝利進行確認； 有沒有遺漏、重復(fù)或不一樣的地方； 用戶是否審查了初步的用戶手冊或原型； 項目開發(fā)支配中的估算是否受到了影響。 （1）需求說明書評測 編制良好的需求說明書8條原則。 原則1：功能與實現(xiàn)分別，即描述要“做什么”而不是“怎樣實現(xiàn)”。 原則2：要求運用面對處理的規(guī)格說明語言，探討來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個行為模型，從而得到“做什么”的規(guī)格說明。 原則3：假如目標軟件只是一個大系統(tǒng)中的一個元素，那么整個系統(tǒng)也包括在規(guī)格說明的描述之中。 原則4：規(guī)格說明必需包括系統(tǒng)運行的環(huán)境。 原則5：系統(tǒng)規(guī)格說明必需是一個相識的模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。 原則6：規(guī)格說明必需是可操作的。 原則7：規(guī)格說明必需容許不完備性并允許擴充。 原則8：規(guī)格說明必需局部化和松散的耦合。 需求說明書的框架。 需求說明書是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、具體的功能和行為描述、性能需求和設(shè)計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。 需求說明書評測內(nèi)容。 需求說明書評測作為需求分析階段工作的復(fù)查手段，應(yīng)當對功能的正確性、完整性和清晰性，以及其他需求賜予評測。評測的主要內(nèi)容是： （1）系統(tǒng)定義的目標是否與用戶的要求一樣； （2）系統(tǒng)需求分析階段供應(yīng)的文檔資料是否齊全； （3）文檔中的全部描述是否完整、清晰，精確地反映用戶要求； （4）與全部其他系統(tǒng)成份的重要接口是否都已經(jīng)描述； （5）被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定； （6）全部圖表是否清晰，在不補充說明時能否理解； （7）主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明； （8）軟件的行為和它必需處理的信息、必需完成的功能是否一樣； （9）設(shè)計的約束條件或限制條件是否符合實際； （10）是否考慮了開發(fā)的技術(shù)風險； （11）是否考慮過軟件需求的其他方案； （12）是否考慮過將來可能會提出的軟件需求； （13）是否具體制定了檢驗標準，它們能否對系統(tǒng)定義是否勝利進行確認； （14）有沒有遺漏、重復(fù)或不一樣的地方； （15）用戶是否審查了初步的用戶手冊或原型； （16）項目開發(fā)支配中的估算是否受到了影響。 （2）概要設(shè)計說明書評測 設(shè)計說明書的框架 設(shè)計說明書的框架內(nèi)容： （1）可追溯性 （2）接口 （3）風險 （4）好用性 （5）技術(shù)清晰度 （6）可維護性 （7）質(zhì)量 （8）各種選擇方案 （9）限制 （10）其他具體問題 為評測設(shè)計是否達到目標，必需建立衡量設(shè)計的技術(shù)標準。如下： 主要評測內(nèi)容： 可追溯性；接口；風險；好用性；技術(shù)清晰度；可維護性；質(zhì)量；各種選擇方案；限制；其他具體問題。 （1）設(shè)計出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的限制； （2）設(shè)計出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件成分之間的限制； （3）設(shè)計應(yīng)當既包含數(shù)據(jù)抽象，也包含過程抽象； （4）設(shè)計應(yīng)當建立具有獨立功能特征的模塊； （5）設(shè)計應(yīng)當建立能夠降低模塊與外部環(huán)境之間困難連接的接口； （6）設(shè)計應(yīng)當依據(jù)軟件需求分析獲得的信息，建立可驅(qū)動、可重復(fù)的方法。 （3）具體設(shè)計說明書評測 與概要設(shè)計說明書基本相同。 （4）軟件編碼規(guī)范評測 程序事實上也是一種供人閱讀的文章，有一個文章的風格問題。程序良好的風格表現(xiàn)在源程序文檔化、數(shù)據(jù)說明的方法、語句結(jié)構(gòu)的輸入/輸出方法這四個方面，軟件編碼規(guī)范評測也是圍繞這四個方面綻開。 源程序文檔化 （1）符號名的命名。符號名即標識符，包括模塊名、變量名、常量名、標號名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。 （2）程序的注釋。注釋分為序言性注釋和功能性注釋。 （3）標準的書寫格式。 數(shù)據(jù)說明 （1）數(shù)據(jù)說明的次序應(yīng)當規(guī)范化。 （2）說明語句中變量支配有序化。 （3）運用注釋說明困難數(shù)據(jù)結(jié)構(gòu)。 語句結(jié)構(gòu) 在設(shè)計階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個語句則是編碼階段的任務(wù)。語句構(gòu)造力求簡潔、干脆，不能為了片面追求效率而使語句困難化。 輸入和輸出 輸入和輸出信息是與用戶的運用干脆相關(guān)的。輸入和輸出的方式和格式應(yīng)當盡可能便利用戶的運用?？隙ㄒ荛_因設(shè)計不當給用戶帶來的麻煩。因此，在軟件需求分析階段和設(shè)計階段，就應(yīng)基本確定輸入和輸出的風格。系統(tǒng)能否被用戶接受，有時就取決于輸入和輸出的風格。不論是批處理的輸入/輸出方式，還是交互式的輸入/輸出方式，在設(shè)計和程序編碼時都應(yīng)考慮下列原則。 輸入和輸出 在設(shè)計和程序編碼時都應(yīng)考慮下列原則。 （1）對全部的輸入數(shù)據(jù)都要進行檢驗，識別錯誤的輸入，以保證每個數(shù)據(jù)的有效性； （2）檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態(tài)信息； （3）使輸入的步驟和操作盡可能簡潔，并保持簡潔的輸入格式； （4）輸入數(shù)據(jù)時，應(yīng)允許運用自由格式輸入； （5）應(yīng)允許缺省值； （6）輸入一批數(shù)據(jù)時，最好運用輸入結(jié)束標記，而不要由用戶指定輸入數(shù)據(jù)數(shù)目； （7）在交互式輸入時，要在屏幕上運用提示符，明確提示交互輸入的懇求，指明可運用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結(jié)束時，也要在屏幕上給出狀態(tài)信息； （8）當程序設(shè)計語言對輸入/輸出格有嚴格要求時，應(yīng)保持輸入格式與輸入語句要求的一樣性； （9）給全部的輸出加注解，并設(shè)計輸出報表格式。 3、開發(fā)階段 （1）單元測試 單元測試的內(nèi)容： 在進行單元測試時，測試者須要依據(jù)具體設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采納白盒測試的測試用例，輔之黑盒測試的測試用例。 使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。這要求對全部的局部的和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分，都要進行桌面檢查和嚴格的代碼審查。 在單元測試中進行的測試工作如圖2-9所示，須要在五個方面對所測模塊進行檢查。 在進行單元測試時，測試者須要依據(jù)具體設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采納白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。這要求對全部的局部的和全局的數(shù)據(jù)結(jié)構(gòu)、外部接口和程序代碼的關(guān)鍵部分，都要進行桌面檢查和嚴格的代碼審查。 1）模塊接口測試 在單元測試的起先，應(yīng)對通過所測模塊的數(shù)據(jù)流進行測試。 假如數(shù)據(jù)不能正確地輸入和輸出，就談不上進行其他測試。為此，對模塊接口可能須要如下的測試項目： 調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、依次上是否匹配； 所測模塊調(diào)用子模塊時，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個數(shù)、屬性、依次上是否匹配； 是否修改了只作輸入用的形式參數(shù)； 輸出給標準函數(shù)的參數(shù)在個數(shù)、屬性、依次上是否正確； 全局量的定義在各模塊中是否一樣； 限制是否通過形式參數(shù)來傳送。 2）局部數(shù)據(jù)結(jié)構(gòu)測試 設(shè)計測試用例以檢查以下各種錯誤： 不正確或不一樣的數(shù)據(jù)類型說明； 運用尚未賦值或尚未初始化的變量； 錯誤的初始值或錯誤的缺省值； 變量名拼法錯或書寫錯； 不一樣的數(shù)據(jù)類型。 3）路徑測試 常見的不正確計算有：運算的優(yōu)先次序不正確或誤會了運算的優(yōu)先次序； 運算的方式錯，即運算的對象彼此在類型上不相容； 算法錯； 初始化不正確； 運算精度不夠； 表達式的符號表示不正確。 4）錯誤處理測試 比較完善的模塊設(shè)計要求能預(yù)見出錯的條件，并設(shè)置適當?shù)某鲥e處理，以便在一旦程序出錯時，能對出錯程序重做支配，保證其邏輯上的正確性。模塊和錯誤處理功能包含有錯誤或缺陷： 出錯的描述難以理解； 出錯的描述不足以對錯誤定位，不足以確定出錯的緣由； 顯示的錯誤與實際的錯誤不符； 對錯誤條件的處理不正確； 在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預(yù)等。 5）邊界測試 單元測試步驟： 驅(qū)動模塊（driver）相當于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，最終輸出實測結(jié)果。 樁模塊（stub）也叫存根模塊。用以代替所測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不須要把子模塊全部功能都帶進來，但不允許什么事情也不做。 （2）集成測試 集成測試也叫做組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，須要將全部模塊依據(jù)概要設(shè)計說明書和具體設(shè)計說明書的要求進行組裝。 組成時須要考慮的問題： 1）在把各個模塊連接起的時候，穿越模塊接口的數(shù)據(jù)是否會丟失； 2）一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響； 3）各個子功能組合起來，能否達到預(yù)期要求的父功能； 4）全局數(shù)據(jù)結(jié)構(gòu)是否有問題； 5）單個模塊的誤差累積起來，是否會放大，以至達到不能接受的程度。 子系統(tǒng)的集成測試稱為部件測試，它所做的工作是要找出組裝后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一樣。 模塊組裝成為系統(tǒng)的方式。 模塊組裝成為系統(tǒng)的方式有兩種：一次性組裝方式和增殖式組裝方式。 1）一次性組裝方式 它是一種非增殖式組裝方式，也叫做整體拼裝。運用這種方式，首先對每個模塊分別進行模塊測試，再把全部模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。 2）增殖式組裝方式 這種組裝方式又稱漸增式組裝，是首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)，在組裝的過程中邊連接邊測試，以發(fā)覺連接過程中產(chǎn)生的問題。最終通過增殖逐步組裝成為要求的軟件系統(tǒng)。 自頂向下的增殖方式。步驟如下：首先以主模塊作為所測模塊兼驅(qū)動模塊，全部直屬于主模塊的下屬模塊全部用樁模塊代替，對主模塊進行測試。再采納深度優(yōu)先或廣度優(yōu)先的策略，用實際模塊替換相應(yīng)的樁模塊，再用樁模塊代替它們的干脆下屬模塊，與已測試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)。然后，進行回來測試（即重新執(zhí)行以前做過的全部測試或部分測試），解除組裝過程中引新的錯誤的可能。最終，推斷是否全部的模塊都已組裝到系統(tǒng)中。 自頂向下的增殖方式在測試過程中較早地驗證了主要的限制和推斷點。在一個功能劃分合理的程序模塊結(jié)構(gòu)中，推斷經(jīng)常出現(xiàn)在較高的層次里，因而，能夠較早地遇到這種問題。 假如選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能，可先對邏輯輸入的分支進行組裝和測試，檢查和克服潛藏的錯誤和缺陷，驗證其功能的正確性，就為其后對主要加工分支的組裝和測試供應(yīng)了保證。 自底向上的增殖方式。 提高測試效率。 進行集成測試時，測試者應(yīng)當確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。關(guān)鍵模塊至少應(yīng)具有以下幾種特征之一： 滿意某些軟件需求； 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層限制模塊）； 較困難、較易發(fā)生錯誤； 有明確定義的性能要求。 在做回來測試時，也應(yīng)當集中測試關(guān)鍵模塊的功能。 集成測試的組織和實施。 集成測試是一種正規(guī)測試過程，必需細心支配，并與單元測試的完成時間協(xié)調(diào)起來。在制定測試支配時，應(yīng)考慮如下因素： （1）采納何種系統(tǒng)組裝方法來進行集成測試。 （2）集成測試過程中連接各個模塊的依次。 （3）模塊代碼編制和測試進度是否與集成測試的依次一樣。 （4）測試過程中是否須要特地的硬件設(shè)備。 集成測試完成的標記。 集成測試完成的標記主要有以下幾項。 （1）勝利地執(zhí)行了測試支配中規(guī)定的全部集成測試。 （2）修正了所發(fā)覺的錯誤。 （3）測試結(jié)果通過了特地小組的評審。 集成測試須要提交的文檔有集成測試支配、集成測試規(guī)格說明書和集成測試分析報告。 （3）確認測試 確認測試的任務(wù)是驗證軟件的功能和性能及其他特性是否與用戶的要求一樣。對軟件的功能和性能要求在軟件需求規(guī)格說明中明確規(guī)定。確認測試一般包括有效性測試和軟件配置復(fù)查，確認測試一般由獨立的第三方測試機構(gòu)進行。 進行有效性測試。 有效性測試是在模擬的環(huán)境下，運用黑盒測試的方法，驗證所測軟件是否滿意需求規(guī)格說明書列出的要求。 在全部軟件測試的測試用例運行完后，全部的測試結(jié)果可以分為兩類。 （1）測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的部分功能或性能特征與需求規(guī)格說明書相符合，從而接受了這部分程序。 （2）測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一樣，因此要為它提交一份問題報告。 軟件配置復(fù)查。 （4）系統(tǒng)測試 系統(tǒng)測試是將通過集成測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際或模擬運行（運用）環(huán)境下，對計算機系統(tǒng)進行一系統(tǒng)列測試。 （5）驗收測試 4、軟件驗證與確認（V&V）過程 軟件的V&V過程是確定依據(jù)規(guī)定的軟件過程開發(fā)的產(chǎn)品是否符合活動的要求，軟件是否滿意它的預(yù)期用途和用戶須要。軟件的V&V過程包括軟件產(chǎn)品和過程的分析、評價、評審、審核、評估和測試。 軟件測試活動是軟件V&V過程的一個組成部分。軟件測試過程的任務(wù)與管理也要符合軟件V&V過程的有關(guān)規(guī)定。 （1）V&V基本概念 驗證（Verfication）：通過檢查和供應(yīng)客觀證據(jù)，證明規(guī)定的需求已滿意。 確認（Validation）：通過檢查和供應(yīng)客觀證據(jù)，證明預(yù)期用途的需求是否得到滿意。 獨立驗證和確認：由在技術(shù)、管理和財務(wù)上與開發(fā)組織有規(guī)定程度獨立性的組織執(zhí)行的V&V過程。 （2）軟件V&V過程 軟件生存周期的V&V過程框架。 軟件開發(fā)過程的V&V概述。 （3）軟件V&V過程中的測試 測試過程。 需求V&V活動中的測試。 2.8軟件失效分類與管理 軟件失效分類 軟件錯誤（software error） 軟件缺陷（software defect） 軟件故障（software fault） 軟件失效（software failure） 軟件失效機理可描述為：軟件錯誤è軟件缺陷è軟件故障è軟件失效 （1）軟件錯誤是指在軟件生存期內(nèi)的不希望或不行接受的人為錯誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生?？梢?，軟件錯誤是一種人為過程，相對于軟件本身，是一種外部行為。 （2）軟件缺陷存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不行接受的偏差。其結(jié)果是軟件運行于某一特定條件時出現(xiàn)軟件故障，這時稱軟件缺陷激烈。 （3）軟件故障是指軟件運行過程中出現(xiàn)的一種不希望或不行接受的內(nèi)部狀態(tài)。 （4）軟件失效是指軟件運行時產(chǎn)生的一種不希望或不行接受的外部行為結(jié)果。 錯誤的廣義定義是：不正確的事務(wù)和行為。 錯誤是在系統(tǒng)運行時，引起或可能潛在地引起失效的缺陷，是一種面對開發(fā)概念。 軟件缺陷： （1）軟件未達到產(chǎn)品說明書中標明的功能； （2）軟件出現(xiàn)了產(chǎn)品說明書中指明的不會出現(xiàn)的錯誤； （3）軟件功能超出了產(chǎn)品說明書指明的范圍； （4）軟件未達到產(chǎn)品說明書雖未指出應(yīng)達到的目標； （5）軟件測試人員認為軟件難以理解、不易運用、運行速度慢，或最終用戶認為不好運用。 產(chǎn)品說明書是軟件缺陷的第一來源，也就出自于軟件需求說明書本身的問題。 設(shè)計方案（軟件設(shè)計說明書）是軟件缺陷其次來源。 缺陷與錯誤分布 缺陷與錯誤嚴峻性和優(yōu)先級 軟件存在的缺陷與錯誤會帶來軟件失敗的風險，重要軟件故障與失效會導(dǎo)致重大經(jīng)濟損失與災(zāi)難。給軟件缺陷與錯誤劃分嚴峻性和優(yōu)先級的通用原則是： （1）表示軟件缺陷所造成的危害的惡劣程度； （2）優(yōu)先級表示修復(fù)缺陷的重要程度和次序； 嚴峻級： 嚴峻：系統(tǒng)崩潰、數(shù)據(jù)丟失、數(shù)據(jù)毀壞 較嚴峻：操作性錯誤、錯誤結(jié)果、遺漏功能 一般：小問題、錯別字、UI布局、罕見故障 建議：不影響運用的瑕疵或更好的實現(xiàn) 優(yōu)先級： 最高優(yōu)先級：馬上修復(fù)，停止進一步測試 次高優(yōu)先級：在產(chǎn)品發(fā)布之前必需修復(fù) 中等優(yōu)先級：假如時間允許應(yīng)當修復(fù) 最低等優(yōu)先級：可能會修復(fù)，但是也能發(fā)布 軟件錯誤跟蹤管理 軟件測試的主要目的在于發(fā)覺軟件存在的錯誤（Bug），如何處理測試中發(fā)覺的錯誤，將干脆影響到測試的效果。只有正確、快速、精確地處理這些錯誤，才能消退軟件錯誤，保證要發(fā)布的軟件符合需求設(shè)計的目標。 在實際的軟件測試過程中，每個BUG都要經(jīng)過測試、確認、修復(fù)、驗證等的管理過程，這是軟件測試的重要環(huán)節(jié)。 作為一個錯誤跟蹤管理系統(tǒng)，須要正確記錄錯誤信息和錯誤處理信息的全部內(nèi)容。 （1）BUG記錄信息 主要包括以下幾項內(nèi)容。 測試軟件名稱 測試版本號 測試人名稱 測試事務(wù) 測試軟件和硬件配置環(huán)境 發(fā)覺軟件錯誤的類型 錯誤的嚴峻等級 具體步驟 必要的附圖 測試注釋 （2）BUG處理信息 處理者姓名 處理時間 處理步驟 錯誤記錄的當前狀態(tài) 2、軟件錯誤的狀態(tài) 新信息（New）：測試中新報告的軟件BUG 打開（Open）：被確認并安排給相關(guān)開發(fā)人員處理。 修正（Fixed）：開發(fā)人員已完成修正，等待測試人員驗證。 拒絕（Declined）拒絕修改BUG 延期（Deferred）：不在當前版本修復(fù)的錯誤，下一步修復(fù)。 關(guān)閉（Closed）：BUG已被修復(fù)。 3、錯誤管理流程 4、錯誤流程管理原則 2.9白盒測試 2.10黑盒測試 黑盒測試也稱為功能測試，它是通過測試來檢測每個功能是否都能正常運用。在完全不考慮內(nèi)部結(jié)構(gòu)和內(nèi)部特性的狀況下，在程序接口進行測試，它只檢查程序功能是否依據(jù)需求說明書的規(guī)定正常運用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。主要針對軟件界面和軟件功能進行測試。 黑盒測試法留意于測試軟件的功能需求，主要試圖發(fā)覺下列幾類錯誤。 功能不正確或遺漏 界面錯誤 數(shù)據(jù)庫訪問錯誤 性能錯誤 初始化和終止錯誤 黑盒測試用例設(shè)計方法包括等價類劃分法、邊界值分析法、錯誤推想法、因果圖法、判定表驅(qū)動法、正交試驗設(shè)計法、功能圖法等。 2.11自動化測試 自動化測試的基本概念 自動化測試的定義：通過測試工具或其他手段，依據(jù)測試工程師的預(yù)定支配對軟件產(chǎn)品進行自動的測試，它是軟件測試的一個重要的組成部分，它能夠完成很多手工無法完成或難以實現(xiàn)的一些測試。正確、合理地實施自動化測試，能夠快速、全在財對軟件進行測試，從而提高軟件質(zhì)量，節(jié)約經(jīng)費，縮短產(chǎn)品發(fā)布周期。 自動化測試的優(yōu)勢與局限 1、自動化測試的優(yōu)勢 避開重復(fù)測試，同時，還能完成大量手工無法完成的測試工作，如并發(fā)用戶測試、大數(shù)據(jù)量測試、長時間運行牢靠性測試等，優(yōu)點： 提高測試質(zhì)量 提高測試效率，縮短測試工作時間 提高測試覆蓋率 執(zhí)行手工測試不能完成的測試任務(wù) 更好地重現(xiàn)軟件缺陷的實力 更好地利用資源 增進測試人員與開發(fā)人員之間的合作伙伴關(guān)系 以下項目和環(huán)境中更適合運用自動化測試工具： 須要反復(fù)進行的工作 負載壓力測試 測試人員和開發(fā)人員有效合作借助測試管理工具，會取得事半功倍的效果。 若須要進行測試系統(tǒng)后臺或者內(nèi)部的性能特性，進而進行故障定位和性能調(diào)優(yōu)。 2、自動化測試的局限性 定制型項目 周期很短的項目 業(yè)務(wù)規(guī)則困難的對象 人體感觀與易用性測試 不穩(wěn)定的軟件 涉及物理交互 選擇合適的自動化測試工具 1、自動化測試工具分類 自動化測試工具分以下幾類： 負載壓力測試工具 功能測試工具 白盒測試工具 網(wǎng)絡(luò)測試工具 測試管理工具 測試協(xié)助工具 2、自動化測試應(yīng)用策略 在測試過程中應(yīng)用測試工具主要有以下幾個目的： 提高測試質(zhì)量； 削減測試過程中的重復(fù)勞動； 實現(xiàn)測試自動化，解決手工測試不能解決的問題。 選擇合適的自動化測試工具 建議以下幾個方面來權(quán)衡： （1）功能 報表功能 測試工具的集成實力 操作系統(tǒng)和開發(fā)工具的兼容性 （2）價格 （3）測試工具的長期投資考慮 測試工具的引入： 確定測試工具的應(yīng)用時機； 確定測試重點； 確定測試目標和指標； 充分利用測試工具的優(yōu)勢； 加強對測試工程師的技能培訓(xùn)； 功能自動化測試 1、測試原理 測試自動化測試工具基本上都是實行錄制回放的方式來模擬用戶的實際操作。在軟件操作中點擊圖形用戶界面上的對象時，測試工具會用一種類C或其他的腳本語言（TSL）生成一個測試腳本，該腳本記錄了你的操作過程，然后測試工具就可回放剛才的操作過程。測試工具實行兩種錄制模式： （1）環(huán)境推斷模式 這種模式依據(jù)你選取的圖形用戶界面對象（如窗體、清單、按鈕等），把你對軟件的操作動作錄制下來，每一次你對被測軟件進行操作，測試腳本語言會記錄并描述你選取的對象和你的操作動作。當你進行錄制時，測試工具會對你選取的每個對象做惟一描述并寫入相應(yīng)的文件中?；胤艜r，測試工具從指定文件中讀取對象描述，并在被測軟件中查找符合這些描述的對象并模擬用戶運用鼠標選取該對象、用鍵盤輸入數(shù)據(jù)的操作。 （2）模擬模式 這種模式記錄鼠標點擊、鍵盤輸入和鼠標在二維平面上的精確運動軌跡。執(zhí)行測試時，測試工具讓鼠標依據(jù)軌跡運行。 通常狀況下，其實施測試必需經(jīng)驗的幾個操作步驟如下： 創(chuàng)建腳本。你可以通過錄制、編程或兩者同用的方式創(chuàng)建測試腳本。測試工具可以自動記錄你的操作并生成所需的腳本代碼，你還可以干脆修改測試腳本以滿意各種困難測試的需求，錄制測試時，在須要檢查軟件反應(yīng)的地方插入檢查點。在這個過程中，測試工具會自動捕獲數(shù)據(jù)，并將該數(shù)據(jù)作為期望結(jié)果儲存下來。 調(diào)試腳本：腳本錄制或編輯結(jié)束后，在調(diào)試模式下運行腳本。并可以設(shè)置中斷點來監(jiān)測變量，限制對象識別和隔離錯誤。 執(zhí)行測試：腳本調(diào)試結(jié)束后，便可以在檢驗?zāi)Ｊ较聹y試被測軟件。 結(jié)果分析：每次測試結(jié)束，測試工具都會把測試狀況顯示在測試結(jié)果報告中。 負載壓力自動化測試 負載測試是為了證明在與產(chǎn)品（預(yù)期）規(guī)模等同的數(shù)據(jù)庫中處理給定的事務(wù)懇求的容量下，系統(tǒng)功能與性能是否與需求規(guī)格說明中規(guī)定的，可接受的響應(yīng)時間一樣的測試過程。而壓力測試則是使客戶機在大容量狀況下運行的測試過程，目的是查看應(yīng)用將在何時何處出現(xiàn)中斷，即識別系統(tǒng)的薄弱環(huán)節(jié)。 負載壓力測試工具基本上都是實行錄制回放的方式來模擬用戶的實際操作的，而且測試工具一般都會有一個后臺代理進程，通過該代理進程，測試工具可以監(jiān)視并獲得在各種通信協(xié)議下應(yīng)用系統(tǒng)的客戶與服務(wù)器的通信信息，測試工具會用一類C或者其他的腳本語言（TSL）生成一個測試腳本，該腳本記錄了你對服務(wù)器的懇求過程，然后測試工具就可以回放剛才的訪問過程，接收服務(wù)器的響應(yīng)，當然你也可以用手工編程生成這個腳本。 同時，限制臺還可以通過服務(wù)器上開啟的遠程RPC服務(wù)，獲得相關(guān)的資源運用信息，最終還可以收集測試數(shù)據(jù)。 在進行測試腳本錄制與安排的過程中，應(yīng)遵循如下幾個原則。 腳本越小越好。 選擇負載壓力最高的業(yè)務(wù)功能進行測試。 選擇所須要的操作進行錄制。 測試工具模擬多用戶并發(fā)訪問可以有以下兩種方式： 進程回放模式； 線程回放模式； 操作步驟如下： 協(xié)議選擇： 創(chuàng)建測試腳本： 參數(shù)化測試數(shù)據(jù) 創(chuàng)建虛擬用戶，設(shè)定負載方案 執(zhí)行測試 結(jié)果分析