軟件測(cè)試重點(diǎn)

軟件測(cè)試定義(dìngyì)的兩面性

評(píng)價(jià)一個(gè)程序或系統(tǒng)的特性或能力并確定是否達(dá)到預(yù)期的結(jié)果測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而針對(duì)某個(gè)程序或系統(tǒng)的執(zhí)行過程軟件測(cè)試正向思維－驗(yàn)證軟件正常工作逆向思維－假定軟件有錯(cuò)誤在設(shè)計(jì)規(guī)定的環(huán)境下運(yùn)行軟件的所有功能，直至全部通過。尋找容易犯錯(cuò)誤的地方(dìfāng)和系統(tǒng)的薄弱環(huán)節(jié)，試圖破壞系統(tǒng)，直至找不出問題。共六十一頁軟件測(cè)試的定義(dìngyì)SWEBOK3.0的定義

：從一個(gè)通常是無限的執(zhí)行域（集合）中選擇合適的、有限的測(cè)試用例，對(duì)程序(chéngxù)所期望的行為進(jìn)行動(dòng)態(tài)驗(yàn)證的活動(dòng)過程。共六十一頁1.4軟件測(cè)試和軟件開發(fā)的關(guān)系(guānxì)讓人誤解(wùjiě)的瀑布模型需求分析和定義系統(tǒng)設(shè)計(jì)詳細(xì)功能設(shè)計(jì)編碼單元測(cè)試功能測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試測(cè)試用戶需求驗(yàn)證系統(tǒng)非功能特性驗(yàn)證功能驗(yàn)證代碼驗(yàn)證構(gòu)建過程驗(yàn)證過程共六十一頁軟件(ruǎnjiàn)質(zhì)量

的內(nèi)涵IEEE：

質(zhì)量是系統(tǒng)、部件或過程滿足明確需求客戶或用戶需要或期望的程度不同軟件質(zhì)量：軟件產(chǎn)品具有(jùyǒu)滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性(IEEESTD729)軟件質(zhì)量：軟件產(chǎn)品滿足 使用要求的程度

共六十一頁不同(bùtónɡ)的分類按測(cè)試的對(duì)象或范圍分類，如單元測(cè)試、文檔測(cè)試、系統(tǒng)測(cè)試等）按測(cè)試目的分類，如功能測(cè)試、回歸測(cè)試、性能測(cè)試、可靠性測(cè)試、安全性測(cè)試和兼容性測(cè)試等根據(jù)測(cè)試過程中被測(cè)軟件是否被執(zhí)行，分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試根據(jù)是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)(shíxiàn)算法來完成測(cè)試，可分為白盒測(cè)試和黑盒測(cè)試共六十一頁2.4靜態(tài)測(cè)試(cèshì)和動(dòng)態(tài)測(cè)試(cèshì)根據(jù)程序是否運(yùn)行，測(cè)試分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試；靜態(tài)測(cè)試包括對(duì)軟件產(chǎn)品的需求和設(shè)計(jì)規(guī)格(guīgé)說明書的評(píng)審、對(duì)程序代碼的審查以及靜態(tài)分析等；動(dòng)態(tài)測(cè)試通過真正運(yùn)行程序發(fā)現(xiàn)錯(cuò)誤，通過觀察代碼運(yùn)行過程來獲取系統(tǒng)行為、變量實(shí)時(shí)結(jié)果、內(nèi)存、堆棧、線程以及測(cè)試覆蓋度等各方面信息，來判斷系統(tǒng)是否存在問題，或者通過有效的測(cè)試用例，對(duì)應(yīng)的輸入輸出關(guān)系來分析被測(cè)程序的運(yùn)行情況，以發(fā)現(xiàn)缺陷。SWEBOK3.0中把靜態(tài)測(cè)試內(nèi)容放在“質(zhì)量管理”模塊中。共六十一頁2.4主動(dòng)測(cè)試(cèshì)和被動(dòng)測(cè)試(cèshì)測(cè)試人員被測(cè)試對(duì)象發(fā)送接收接收/檢查發(fā)送/響應(yīng)主動(dòng)測(cè)試被測(cè)試對(duì)象運(yùn)行環(huán)境發(fā)送接收/響應(yīng)測(cè)試人員接收/監(jiān)控被動(dòng)測(cè)試共六十一頁2.5黑盒測(cè)試(cèshì)和白盒測(cè)試(cèshì)功能測(cè)試數(shù)據(jù)驅(qū)動(dòng)(qūdònɡ)測(cè)試結(jié)構(gòu)測(cè)試邏輯驅(qū)動(dòng)測(cè)試

客戶需求事件驅(qū)動(dòng)輸入輸出共六十一頁功能測(cè)試（黑盒）完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試人員針對(duì)軟件直接進(jìn)行測(cè)試，檢查系統(tǒng)功能是否按照需求規(guī)格說明書的規(guī)定正常(zhèngcháng)使用、是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而輸出正確的結(jié)果，檢查相應(yīng)的文檔是否采用了正確的模板、是否滿足規(guī)范要求。發(fā)現(xiàn)的缺陷類型：有錯(cuò)誤的功能或遺漏了某項(xiàng)功能；不能正確接收輸入數(shù)據(jù)，輸出錯(cuò)誤結(jié)果；功能操作邏輯不合理、不夠方便；界面出錯(cuò)、扭曲或不美觀；安裝過程中出現(xiàn)問題，安裝步驟不清晰、不夠靈活；系統(tǒng)初始化問題。共六十一頁結(jié)構(gòu)(jiégòu)測(cè)試（白盒）已知產(chǎn)品內(nèi)部工作過程，清楚最終生成軟件產(chǎn)品的計(jì)算機(jī)程序結(jié)構(gòu)及語句，按照程序內(nèi)部結(jié)構(gòu)測(cè)試程序，測(cè)試程序內(nèi)部的變量狀態(tài)、邏輯結(jié)構(gòu)、運(yùn)行路徑等，檢查程序中的每條通路是否都能按預(yù)定要求正確工作，檢查程序內(nèi)部動(dòng)作或運(yùn)行是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否按規(guī)定正常進(jìn)行。白盒測(cè)試原則在執(zhí)行測(cè)試時(shí)，先考慮各個(gè)分支被覆蓋(fùgài)；再考慮完成所有邏輯條件分別為真值和假值的測(cè)試；如果有更高質(zhì)量要求，測(cè)試對(duì)象流程圖中所有獨(dú)立路徑至少被運(yùn)行一次；檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)，注意上下文的影響，以確保其測(cè)試的有效性。共六十一頁黑盒與白盒比較(bǐjiào)功能測(cè)試的置信，結(jié)構(gòu)(jiégòu)測(cè)試的度量特點(diǎn)測(cè)試依據(jù)方法舉例黑盒測(cè)試不給程序需求規(guī)格說明等價(jià)類劃分白盒測(cè)試給出程序程序邏輯覆蓋共六十一頁測(cè)試階段（SDLC)共六十一頁軟件測(cè)試階段(jiēduàn)輸入和輸出階段輸入輸出需求分析需求定義,市場(chǎng)分析文檔,相關(guān)技術(shù)文檔市場(chǎng)需求分析會(huì)議記要,功能設(shè)計(jì),技術(shù)設(shè)計(jì)設(shè)計(jì)審查市場(chǎng)需求文檔,技術(shù)設(shè)計(jì)文檔

測(cè)試計(jì)劃,測(cè)試用例功能驗(yàn)證代碼完成文件包,功能詳細(xì)設(shè)計(jì)說明書最終技術(shù)文檔完整測(cè)試用例,完備的測(cè)試計(jì)劃,缺陷報(bào)告,功能驗(yàn)證測(cè)試報(bào)告系統(tǒng)測(cè)試代碼修改后的文件包完整測(cè)試用例,完備的測(cè)試計(jì)劃

缺陷報(bào)告缺陷狀態(tài)報(bào)告項(xiàng)目階段報(bào)告確認(rèn)測(cè)試代碼凍結(jié)文件包確認(rèn)測(cè)試用例缺陷狀態(tài)報(bào)告缺陷報(bào)告審查版本審查版本發(fā)布代碼發(fā)布文件包測(cè)試計(jì)劃?rùn)z查清單當(dāng)前版本已知問題的清單版本發(fā)布報(bào)告共六十一頁需求(xūqiú)和設(shè)計(jì)審查測(cè)試人員參與產(chǎn)品需求分析和系統(tǒng)設(shè)計(jì)，認(rèn)真閱讀(yuèdú)有關(guān)文檔，真正理解客戶的需求和技術(shù)上的設(shè)計(jì)，檢查需求說明書對(duì)產(chǎn)品描述的準(zhǔn)確性、一致性等，檢查系統(tǒng)設(shè)計(jì)的合理性和可測(cè)試性等共六十一頁單元測(cè)試單元測(cè)試的對(duì)象是程序系統(tǒng)中的最小單元---類、函數(shù)、模塊或組件上，在編碼階段進(jìn)行，針對(duì)每個(gè)模塊進(jìn)行測(cè)試，主要通過白盒測(cè)試方法，從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，檢查程序模塊或組件的已實(shí)現(xiàn)的功能與定義的功能是否一致、以及編碼中是否存在錯(cuò)誤。多個(gè)模塊可以平行地、對(duì)立地測(cè)試，通常要編寫驅(qū)動(dòng)模塊和樁模塊。單元測(cè)試一般由編程人員和測(cè)試人員共同完成，而以開發(fā)人員為主單元測(cè)試包括代碼(dàimǎ)評(píng)審，代碼(dàimǎ)評(píng)審可以發(fā)現(xiàn)程序50%～70%代碼的缺陷。共六十一頁集成(jíchénɡ)測(cè)試集成測(cè)試，也稱組裝測(cè)試、聯(lián)合測(cè)試、子系統(tǒng)測(cè)試，在單元測(cè)試的基礎(chǔ)上，將模塊按照設(shè)計(jì)要求組裝起來(qǐlái)同時(shí)進(jìn)行測(cè)試，主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的模塊之間問題兩種集成方式：一次性集成方式和漸增式集成方式。共六十一頁功能測(cè)試功能測(cè)試一般須在完成集成測(cè)試后進(jìn)行，而且是針對(duì)應(yīng)用系統(tǒng)進(jìn)行測(cè)試。功能測(cè)試是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應(yīng)具有(jùyǒu)的功能，從用戶角度來進(jìn)行功能驗(yàn)證，以確認(rèn)每個(gè)功能是否都能正常使用。共六十一頁系統(tǒng)(xìtǒng)測(cè)試系統(tǒng)測(cè)試是將軟件放在整個(gè)計(jì)算機(jī)環(huán)境下，包括軟硬件平臺(tái)、某些支持軟件、數(shù)據(jù)和人員(rényuán)等，在實(shí)際運(yùn)行環(huán)境下進(jìn)行一系列的測(cè)試，包括用戶界面、各種操作、不同的數(shù)據(jù)輸入輸出、存儲(chǔ)測(cè)試、負(fù)載測(cè)試、災(zāi)難恢復(fù)測(cè)試、安全測(cè)試、可靠性測(cè)試和性能測(cè)試等。共六十一頁驗(yàn)收測(cè)試(cèshì)

&安裝測(cè)試驗(yàn)收測(cè)試(cèshì)的目的是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作，驗(yàn)證軟件的功能和性能及其他特性如同用戶所合理期待的那樣。驗(yàn)收測(cè)試一般要求在實(shí)際的用戶環(huán)境上進(jìn)行，并和用戶共同完成。Αlpha（α）測(cè)試和Beta（β）測(cè)試共六十一頁進(jìn)一步彰顯(zhānɡxiǎn)全過程測(cè)試共六十一頁4.1.3W模型(móxíng)共六十一頁4.1.2TMapTMap(TestManagementApproach，測(cè)試管理方法)是一種結(jié)構(gòu)化的、基于風(fēng)險(xiǎn)策略的測(cè)試方法體系,目的能更早地發(fā)現(xiàn)缺陷，以最小的成本、有效地、徹底地完成測(cè)試任務(wù)，以減少軟件發(fā)布后的支持成本。TMap所定義的測(cè)試生命周期由計(jì)劃和控制、準(zhǔn)備、說明(shuōmíng)、執(zhí)行和完成等階段組成參考(cānkǎo)：/Home/共六十一頁TMap描述(miáoshù)的生命周期模型共六十一頁TMap基本(jīběn)內(nèi)容一個(gè)基于風(fēng)險(xiǎn)的測(cè)試方法基于風(fēng)險(xiǎn)的測(cè)試策略，來有效的分配測(cè)試投入在測(cè)試規(guī)劃的各個(gè)時(shí)間(shíjiān)點(diǎn)進(jìn)行商業(yè)投入共六十一頁TMap三大(sāndà)基石與軟件開發(fā)生命周期一致的測(cè)試活動(dòng)生命周期（L）；堅(jiān)實(shí)的組織融合（O）正確的基礎(chǔ)設(shè)施(jīchǔshèshī)和工具（I）可用的技術(shù)（T）流程人/項(xiàng)目測(cè)試環(huán)境技術(shù)共六十一頁TMapNEXT之背景(bèijǐng)測(cè)試的獨(dú)立性

和開發(fā)更緊密(jǐnmì)的融合更多種類的測(cè)試組織，包括測(cè)試工廠BDTM,BusinessDrivenTestManagement新的測(cè)試方法、技術(shù)，特別測(cè)試設(shè)計(jì)方法測(cè)試的基礎(chǔ)設(shè)施、支持流程測(cè)試估算、風(fēng)險(xiǎn)分析增加測(cè)試類型共六十一頁TMapNEXT/en/tmap-next業(yè)務(wù)驅(qū)動(dòng)測(cè)試管理方法BDTM結(jié)構(gòu)化的測(cè)試流程完整(wánzhěng)的工具包自適應(yīng)的測(cè)試方法共六十一頁單元測(cè)試的定義(dìngyì)定義

單元測(cè)試是對(duì)軟件基本的組成單元進(jìn)行(jìnxíng)獨(dú)立的測(cè)試時(shí)機(jī)

單元測(cè)試和編碼是同步進(jìn)行，但在TDD中，強(qiáng)調(diào)測(cè)試在先，編碼在后。單元測(cè)試一般由開發(fā)人員完成,QA人員輔助.概念模塊、組件、單元

共六十一頁單元測(cè)試的目標(biāo)(mùbiāo)目標(biāo):單元模塊被正確編碼信息能否正確地流入和流出單元在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤，全局變量在單元中的處理和影響為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作單元的運(yùn)行能否做到滿足特定(tèdìng)的邏輯覆蓋共六十一頁任務(wù)１:模塊獨(dú)立執(zhí)行(zhíxíng)路徑測(cè)試檢查每一條獨(dú)立執(zhí)行路徑的測(cè)試，并保證每條語句被至少執(zhí)行一次。Checklist:

誤解或用錯(cuò)了算符優(yōu)先級(jí)混合(hùnhé)類型運(yùn)算變量初值錯(cuò)精度不夠表達(dá)式符號(hào)錯(cuò)其它共六十一頁任務(wù)(rènwu)2:局部數(shù)據(jù)結(jié)構(gòu)測(cè)試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:

不適合或不相容的類型說明變量無初值變量初始化或默認(rèn)值有錯(cuò)不正確(zhèngquè)的變量名或從來未被使用過出現(xiàn)上溢或下溢和地址異常其它共六十一頁任務(wù)(rènwu)３:模塊接口測(cè)試檢查模塊接口是否正確checklist:輸入的實(shí)際參數(shù)與形式參數(shù)是否一致(個(gè)數(shù)、屬性、量綱)調(diào)用其他模塊的實(shí)際參數(shù)與被調(diào)模塊的形參是否一致。

個(gè)數(shù)、屬性、量綱全程變量的定義在各模塊是否一致。外部輸入、輸出文件(wénjiàn)、緩沖區(qū)、錯(cuò)誤處理其它共六十一頁任務(wù)(rènwu)４:單元邊界條件測(cè)試檢查(jiǎnchá)臨界數(shù)據(jù)處理的正確性Checklist:

普通合法數(shù)據(jù)的處理。普通非法數(shù)據(jù)的處理。邊界值內(nèi)合法邊界數(shù)據(jù)的處理。邊界值外非法邊界數(shù)據(jù)的處理。其它共六十一頁任務(wù)(rènwu)5:單元容錯(cuò)測(cè)試預(yù)設(shè)的各種出錯(cuò)處理是否正確有效。Checklist:

輸出的出錯(cuò)信息難以理解記錄的錯(cuò)誤與實(shí)際不相符異常(yìcháng)處理不當(dāng)未提供足夠的定位出錯(cuò)的信息其它共六十一頁任務(wù)6：內(nèi)存(nèicún)分析內(nèi)存泄漏會(huì)導(dǎo)致系統(tǒng)運(yùn)行的崩潰；測(cè)量?jī)?nèi)存的使用情況，了解程序內(nèi)存分配的真實(shí)情況；系統(tǒng)崩潰前發(fā)現(xiàn)內(nèi)存泄漏錯(cuò)誤；發(fā)現(xiàn)內(nèi)存分配錯(cuò)誤，并精確顯示發(fā)生(fāshēng)錯(cuò)誤時(shí)的上下文情況，指出發(fā)生(fāshēng)錯(cuò)誤的原由。共六十一頁驅(qū)動(dòng)程序(chéngxù)和樁程序(chéngxù)運(yùn)行單元程序有時(shí)需要基于被測(cè)單元的接口，開發(fā)相應(yīng)(xiāngyīng)的驅(qū)動(dòng)模塊和樁模塊。驅(qū)動(dòng)模塊（drive）:對(duì)底層或子層模塊進(jìn)行測(cè)試所編寫的調(diào)用這些模塊的程序。樁模塊（stub）：對(duì)頂層或上層模塊進(jìn)行測(cè)試時(shí)所編寫的替代下層模塊的程序。共六十一頁集成測(cè)試(cèshì)的模式漸增式測(cè)試模式與非漸增式測(cè)試模式非漸增式測(cè)試模式：先分別測(cè)試每個(gè)模塊(mókuài)，再把所有模塊(mókuài)按設(shè)計(jì)要求放在一起結(jié)合成所要的程序，如大棒模式。漸增式測(cè)試模式：把下一個(gè)要測(cè)試的模塊同已經(jīng)測(cè)試好的模塊結(jié)合起來進(jìn)行測(cè)試，測(cè)試完以后再把下一個(gè)應(yīng)該測(cè)試的模塊結(jié)合進(jìn)來測(cè)試。各自的優(yōu)缺點(diǎn)共六十一頁漸增式測(cè)試模式需要編寫的軟件較多，工作量較大，而非漸增式測(cè)試模式開銷小。漸增式測(cè)試模式發(fā)現(xiàn)模塊間的接口錯(cuò)誤早；而非漸增式測(cè)試模式晚。非漸增式測(cè)試模式發(fā)現(xiàn)錯(cuò)誤，較難診斷；而使用漸增式測(cè)試模式，如果發(fā)生錯(cuò)誤則往往和最近(zuìjìn)加進(jìn)來的那個(gè)模塊有關(guān)。漸增式測(cè)試模式測(cè)試更徹底。漸增式測(cè)試模式需要較多的機(jī)器時(shí)間。使用非漸增式測(cè)試模式，可以并行測(cè)試。優(yōu)缺點(diǎn)共六十一頁大棒集成(jíchénɡ)方法(Big-bangIntegration)采用大棒集成方法(fāngfǎ),先是對(duì)每一個(gè)子模塊進(jìn)行測(cè)試（單元測(cè)試階段），然后將所有模塊一次性的全部集成起來進(jìn)行集成測(cè)試。因?yàn)樗械哪K一次集成的，所以很難確定出錯(cuò)的真正位置、所在的模塊、錯(cuò)誤的原因。這種方法并不推薦在任何系統(tǒng)中使用，適合在規(guī)模較小的應(yīng)用系統(tǒng)中使用。共六十一頁自頂向下和自底向上集成(jíchénɡ)方法共六十一頁自頂向下法(Top-downIntegration)自頂向下法的主要(zhǔyào)優(yōu)缺點(diǎn)共六十一頁優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：不需要測(cè)試驅(qū)動(dòng)程序，能夠在測(cè)試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能夠在早期發(fā)現(xiàn)上層模塊的接口錯(cuò)誤。缺點(diǎn)：需要樁程序，可能遇到于此想聯(lián)系的測(cè)試?yán)щy，低層關(guān)鍵模塊中的錯(cuò)誤發(fā)現(xiàn)的比較晚，而且用這種方法在早期不能充分開展(kāizhǎn)人力。共六十一頁自底向上法

Bottom-upIntegration

自底向上法的主要(zhǔyào)優(yōu)缺點(diǎn)共六十一頁優(yōu)缺點(diǎn)：

與自頂向下模式(móshì)剛好相反共六十一頁三明治集成(jíchénɡ)方法(SandwichIntegration)采用三明治方法的優(yōu)點(diǎn)是：它將自頂向下和自底向上的集成方法有機(jī)地結(jié)合起來，不需要(xūyào)寫樁程序因?yàn)樵跍y(cè)試初自底向上集成已經(jīng)驗(yàn)證了底層模塊的正確性。采用這種方法的主要缺點(diǎn)是：在真正集成之前每一個(gè)獨(dú)立的模塊沒有完全測(cè)試過。共六十一頁改善的三明治集成(jíchénɡ)方法改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個(gè)模塊得到(dédào)單獨(dú)的測(cè)試，使測(cè)試進(jìn)行得比較徹底。共六十一頁幾種集成方法性能(xìngnéng)的比較自底向上自頂向下混合策略大棒三明治改進(jìn)三明治集成早早早晚早早基本程序能工作時(shí)間晚早早晚早早需要驅(qū)動(dòng)程序是否是是是是需要樁程序否是是是是是工作并行性中低中高中高特殊路徑測(cè)試容易難容易容易中等容易計(jì)劃與控制容易難難容易難難共六十一頁系統(tǒng)(xìtǒng)測(cè)試系統(tǒng)測(cè)試：將經(jīng)過集成測(cè)試后的軟件，作為計(jì)算機(jī)系統(tǒng)的一部分，與計(jì)算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺(tái)等系統(tǒng)元素結(jié)合起來，在真實(shí)運(yùn)行環(huán)境下對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的嚴(yán)格有效的測(cè)試來發(fā)現(xiàn)軟件的潛在問題，保證系統(tǒng)的正常運(yùn)行。目的：充分運(yùn)行系統(tǒng)，驗(yàn)證整個(gè)系統(tǒng)是否滿足功能和非功能性的質(zhì)量(zhìliàng)需求。非功能性測(cè)試是系統(tǒng)測(cè)試中更為關(guān)鍵的任務(wù)！共六十一頁回歸測(cè)試的目的所做的修改達(dá)到了預(yù)定的目的，如錯(cuò)誤得到了改正，新功能(gōngnéng)得到了實(shí)現(xiàn)，能夠適應(yīng)新的運(yùn)行環(huán)境等；不影響軟件原有功能的正確性。6.2回歸(huíguī)測(cè)試一旦程序某些區(qū)域被修改了，就可能影響其它區(qū)域，導(dǎo)致受影響的區(qū)域出現(xiàn)新的缺陷（回歸缺陷）。如果這時(shí)沒有回歸測(cè)試，產(chǎn)品就帶著這樣的回歸缺陷被發(fā)布出去了，造成嚴(yán)重后果?；貧w測(cè)試就是為了發(fā)現(xiàn)回歸缺陷而進(jìn)行的測(cè)試。共六十一頁什么是性能(xìngnéng)測(cè)試？性能測(cè)試(cèshì)（performancetest）就是為了發(fā)現(xiàn)系統(tǒng)性能問題或獲取系統(tǒng)性能相關(guān)指標(biāo)而進(jìn)行的測(cè)試。一般在真實(shí)環(huán)境、特定負(fù)載條件下，通過工具模擬實(shí)際軟件系統(tǒng)的運(yùn)行及其操作，同時(shí)監(jiān)控性能各項(xiàng)指標(biāo)，最后對(duì)測(cè)試結(jié)果進(jìn)行分析來確定系統(tǒng)的性能狀況。共六十一頁性能測(cè)試(cèshì)目標(biāo)

Performance

Testing獲取系統(tǒng)性能某些指標(biāo)(zhǐbiāo)數(shù)據(jù)為了驗(yàn)證系統(tǒng)是否達(dá)到用戶提出的性能指標(biāo)發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，優(yōu)化系統(tǒng)的性能共六十一頁壓力/負(fù)載(fùzài)測(cè)試壓力測(cè)試(cèshì)(Stresstest)，也稱為強(qiáng)度測(cè)試、負(fù)載測(cè)試。壓力測(cè)試是模擬實(shí)際應(yīng)用的軟硬件環(huán)境及用戶使用過程的系統(tǒng)負(fù)荷，長(zhǎng)時(shí)間或超大負(fù)荷地運(yùn)行測(cè)試軟件，來測(cè)試被測(cè)系統(tǒng)的性能、可靠性、穩(wěn)定性等。共六十一頁兩種負(fù)載(fùzài)類型

“Flat”測(cè)試:

對(duì)于一次給定(ɡěidìnɡ)的測(cè)試，應(yīng)該取響應(yīng)時(shí)間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然后在預(yù)定的時(shí)間段內(nèi)持續(xù)運(yùn)行。虛擬用戶的數(shù)量共六十一頁兩種負(fù)載(fùzài)類型

Ramp-up測(cè)試:

用戶是交錯(cuò)上升的（每幾秒增加一些新用戶）。ramp-up測(cè)試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因?yàn)橛捎谟脩舻脑黾邮敲看我徊糠?，系統(tǒng)的負(fù)載在不斷地變化。其優(yōu)點(diǎn)是，可以看出隨著系統(tǒng)負(fù)載的改變，測(cè)量值是如何改變的

據(jù)此選擇(xuǎnzé)要運(yùn)行的flat測(cè)試的范圍。共六十一頁安全性測(cè)試(cèshì)

想方設(shè)法截取或破譯口令；專門開發(fā)軟件來破壞系統(tǒng)的保護(hù)機(jī)制；故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；試圖(shìtú)通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過被保護(hù)信息的價(jià)值，此時(shí)非法侵入者已無利可圖。軟件安全性測(cè)試就是檢驗(yàn)系統(tǒng)權(quán)限設(shè)置有效性、防范非法入侵的能力、數(shù)據(jù)備份和恢復(fù)能力等，設(shè)法找出上述各種安全性漏洞共六十一頁功能性測(cè)試(cèshì)

vs.安全性測(cè)試功能性測(cè)試：軟件做它應(yīng)該做的事，驗(yàn)證正確的輸出不正確的輸出/行為/缺陷(Bug)安全性測(cè)試：軟件不做它不應(yīng)該做的事,應(yīng)用(yìngyòng)輸入驗(yàn)證,沒有不安全的事情發(fā)生在測(cè)試軟件系統(tǒng)中對(duì)危險(xiǎn)防止和危險(xiǎn)處理設(shè)施進(jìn)行的測(cè)試，以驗(yàn)證其是否有效

安全性缺陷（漏洞，脆