軟件測試重點(diǎn)

1、軟件測試定義的兩面性軟件測試定義的兩面性 評價(jià)一個(gè)程序或系統(tǒng)的特性或能力并確定是否達(dá)到預(yù)期的結(jié)果測試是為發(fā)現(xiàn)錯(cuò)誤而針對某個(gè)程序或系統(tǒng)的執(zhí)行過程軟軟件件測測試試正向思維正向思維驗(yàn)證軟件正常工作逆向思維逆向思維假定軟件有錯(cuò)誤在設(shè)計(jì)規(guī)定的環(huán)境下運(yùn)行軟件的所有功能，直至全部通過。尋找容易犯錯(cuò)誤的地方和系統(tǒng)的薄弱環(huán)節(jié)，試圖破壞系統(tǒng)，直至找不出問題。軟件測試的定義軟件測試的定義SWEBOK3.0的定義的定義 ：p從一個(gè)通常是無限的執(zhí)行域（集合）中選擇合適的、有限的測試用例，對程序所期望的行為進(jìn)行動(dòng)態(tài)驗(yàn)證的活動(dòng)過程。1.4 軟件測試和軟件開發(fā)的關(guān)系軟件測試和軟件開發(fā)的關(guān)系讓人誤解的瀑布模型讓人誤解的瀑布模型

2、需求分析和定義系統(tǒng)設(shè)計(jì)詳細(xì)功能設(shè)計(jì)編碼單元測試功能測試系統(tǒng)測試驗(yàn)收測試測試用戶需求驗(yàn)證系統(tǒng)非功能特性驗(yàn)證功能驗(yàn)證代碼驗(yàn)證構(gòu)建過程驗(yàn)證過程軟件質(zhì)量軟件質(zhì)量 的內(nèi)涵的內(nèi)涵IEEEIEEE： 質(zhì)量是系統(tǒng)、部件或過程滿足質(zhì)量是系統(tǒng)、部件或過程滿足明確需求客戶或用戶需要或期望的程度不同 p軟件質(zhì)量軟件質(zhì)量：軟件產(chǎn)品具有滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性(IEEE STD729) p軟件質(zhì)量軟件質(zhì)量：軟件產(chǎn)品滿足使用要求的程度 不同的分類不同的分類按測試的對象或范圍分類，如單元測試、文檔測試、系統(tǒng)測試等）按測試目的分類，如功能測試、回歸測試、性能測試、可靠性測試、安全性測試和兼容性測試等根據(jù)

3、測試過程中被測軟件是否被執(zhí)行，分為靜態(tài)測試和動(dòng)態(tài)測試根據(jù)是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法來完成測試，可分為白盒測試和黑盒測試2.4 靜態(tài)測試和動(dòng)態(tài)測試靜態(tài)測試和動(dòng)態(tài)測試 根據(jù)程序是否運(yùn)行，測試分為靜態(tài)測試和動(dòng)態(tài)測試； 靜態(tài)測試靜態(tài)測試包括對軟件產(chǎn)品的需求和設(shè)計(jì)規(guī)格說明書的評審、對程序代碼的審查以及靜態(tài)分析等； 動(dòng)態(tài)測試動(dòng)態(tài)測試通過真正運(yùn)行程序發(fā)現(xiàn)錯(cuò)誤，通過觀察代碼運(yùn)行過程來獲取系統(tǒng)行為、變量實(shí)時(shí)結(jié)果、內(nèi)存、堆棧、線程以及測試覆蓋度等各方面信息，來判斷系統(tǒng)是否存在問題，或者通過有效的測試用例，對應(yīng)的輸入輸出關(guān)系來分析被測程序的運(yùn)行情況，以發(fā)現(xiàn)缺陷。 SWEBOK 3.0中把靜態(tài)測試內(nèi)容放在“

4、質(zhì)量管理”模塊中。2.4 主動(dòng)測試和被動(dòng)測試主動(dòng)測試和被動(dòng)測試測試人員被測試對象發(fā)送接收接收/檢查發(fā)送/響應(yīng)主動(dòng)測試被測試對象運(yùn)行環(huán)境發(fā)送接收/響應(yīng)測試人員接收/監(jiān)控被動(dòng)測試2.5 黑盒測試和白盒測試黑盒測試和白盒測試功能測試功能測試數(shù)據(jù)驅(qū)動(dòng)測試數(shù)據(jù)驅(qū)動(dòng)測試 結(jié)構(gòu)測試結(jié)構(gòu)測試邏輯驅(qū)動(dòng)測試邏輯驅(qū)動(dòng)測試 客戶需求事件驅(qū)動(dòng)輸入輸出功能測試（黑盒）功能測試（黑盒） 完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試人員針對軟件直接進(jìn)行測試，檢查系統(tǒng)功能是否按照需求規(guī)格說明書的規(guī)定正常使用、是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而輸出正確的結(jié)果，檢查相應(yīng)的文檔是否采用了正確的模板、是否滿足規(guī)范要求。 發(fā)現(xiàn)的缺陷類型： 有

5、錯(cuò)誤的功能或遺漏了某項(xiàng)功能； 不能正確接收輸入數(shù)據(jù)，輸出錯(cuò)誤結(jié)果； 功能操作邏輯不合理、不夠方便； 界面出錯(cuò)、扭曲或不美觀； 安裝過程中出現(xiàn)問題，安裝步驟不清晰、不夠靈活； 系統(tǒng)初始化問題。結(jié)構(gòu)測試（白盒）結(jié)構(gòu)測試（白盒） 已知產(chǎn)品內(nèi)部工作過程，清楚最終生成軟件產(chǎn)品的計(jì)算機(jī)程序結(jié)構(gòu)及語句，按照程序內(nèi)部結(jié)構(gòu)測試程序，測試程序內(nèi)部的變量狀態(tài)、邏輯結(jié)構(gòu)、運(yùn)行路徑等，檢查程序中的每條通路是否都能按預(yù)定要求正確工作，檢查程序內(nèi)部動(dòng)作或運(yùn)行是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否按規(guī)定正常進(jìn)行。 白盒測試原則 在執(zhí)行測試時(shí)，先考慮各個(gè)分支被覆蓋； 再考慮完成所有邏輯條件分別為真值和假值的測試； 如果有更高質(zhì)

6、量要求，測試對象流程圖中所有獨(dú)立路徑至少被運(yùn)行一次； 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)，注意上下文的影響，以確保其測試的有效性。黑盒與白盒比較黑盒與白盒比較 功能測試的置信，結(jié)構(gòu)測試的度量特點(diǎn)測試依據(jù)方法舉例黑盒測試不給程序不給程序需求規(guī)格需求規(guī)格說明說明等價(jià)類劃等價(jià)類劃分分白盒測試給出程序給出程序程序程序邏輯覆蓋邏輯覆蓋測試階段測試階段（SDLC)軟件測試階段輸入和輸出軟件測試階段輸入和輸出階階 段段輸輸 入入 輸輸 出出 需求分析需求分析需求定義需求定義, 市場分析文檔市場分析文檔, 相關(guān)技相關(guān)技術(shù)文檔術(shù)文檔市場需求分析會(huì)議記要市場需求分析會(huì)議記要 , 功能設(shè)計(jì)功能設(shè)計(jì), 技術(shù)設(shè)計(jì)技術(shù)設(shè)計(jì)設(shè)計(jì)審查設(shè)計(jì)審查

7、 市場需求文檔市場需求文檔, 技術(shù)設(shè)計(jì)文檔技術(shù)設(shè)計(jì)文檔 測試計(jì)劃測試計(jì)劃, 測試用例測試用例功能驗(yàn)證功能驗(yàn)證 代碼完成文件包代碼完成文件包,功能詳細(xì)設(shè)計(jì)說功能詳細(xì)設(shè)計(jì)說明書明書最終技術(shù)文檔最終技術(shù)文檔完整測試用例完整測試用例,完備的測試計(jì)劃完備的測試計(jì)劃, 缺缺陷報(bào)告陷報(bào)告,功能驗(yàn)證測試報(bào)告功能驗(yàn)證測試報(bào)告系統(tǒng)測試系統(tǒng)測試代碼修改后的文件包代碼修改后的文件包 完整測試用例完整測試用例,完備的測試計(jì)劃完備的測試計(jì)劃 缺陷報(bào)告缺陷報(bào)告缺陷狀態(tài)報(bào)告缺陷狀態(tài)報(bào)告項(xiàng)目階段報(bào)告項(xiàng)目階段報(bào)告確認(rèn)測試確認(rèn)測試代碼凍結(jié)文件包代碼凍結(jié)文件包確認(rèn)測試用例確認(rèn)測試用例缺陷狀態(tài)報(bào)告缺陷狀態(tài)報(bào)告缺陷報(bào)告審查缺陷報(bào)告審查版

8、本審查版本審查版本發(fā)布版本發(fā)布 代碼發(fā)布文件包代碼發(fā)布文件包 測試計(jì)劃檢查清單測試計(jì)劃檢查清單當(dāng)前版本已知問題的清單當(dāng)前版本已知問題的清單版本發(fā)布報(bào)告版本發(fā)布報(bào)告需求和設(shè)計(jì)審查需求和設(shè)計(jì)審查測試人員參與產(chǎn)品需求分析和系統(tǒng)設(shè)計(jì)，認(rèn)真閱讀有關(guān)文檔，真正理解客戶的需求和技術(shù)上的設(shè)計(jì)，檢查需求說明書對產(chǎn)品描述的準(zhǔn)確性、一致性等，檢查系統(tǒng)設(shè)計(jì)的合理性和可測試性等單元測試單元測試單元測試單元測試的對象是程序系統(tǒng)中的最小單元-類、函數(shù)、模塊或組件上，在編碼階段進(jìn)行，針對每個(gè)模塊進(jìn)行測試，主要通過白盒測試方法，從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例，檢查程序模塊或組件的已實(shí)現(xiàn)的功能與定義的功能是否一致、以及編碼中是

9、否存在錯(cuò)誤。多個(gè)模塊可以平行地、對立地測試，通常要編寫驅(qū)動(dòng)模塊和樁模塊。單元測試一般由編程人員和測試人員共同完成，而以開發(fā)人員為主單元測試包括代碼評審，代碼評審可以發(fā)現(xiàn)程序50%70%代碼的缺陷。集成測試集成測試集成測試，也稱組裝測試、聯(lián)合測試、子系統(tǒng)測試，在單元測試的基礎(chǔ)上，將模塊按照設(shè)計(jì)要求組裝起來同時(shí)進(jìn)行測試，主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的模塊之間問題 兩種集成方式：一次性集成方式和漸增式集成方式。功能測試功能測試功能測試一般須在完成集成測試后進(jìn)行，而且是針對應(yīng)用系統(tǒng)進(jìn)行測試。功能測試是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應(yīng)具有的功能，從用戶角度來進(jìn)行功能驗(yàn)證，以確認(rèn)每個(gè)功能是否都能正常使用。

10、 系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試是將軟件放在整個(gè)計(jì)算機(jī)環(huán)境下，包括軟硬件平臺(tái)、某些支持軟件、數(shù)據(jù)和人員等，在實(shí)際運(yùn)行環(huán)境下進(jìn)行一系列的測試，包括用戶界面、各種操作、不同的數(shù)據(jù)輸入輸出、存儲(chǔ)測試、負(fù)載測試、災(zāi)難恢復(fù)測試、安全測試、可靠性測試和性能測試等 。驗(yàn)收測試驗(yàn)收測試 &安裝測試安裝測試驗(yàn)收測試驗(yàn)收測試的目的是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作，驗(yàn)證軟件的功能和性能及其他特性如同用戶所合理期待的那樣。驗(yàn)收測試一般要求在實(shí)際的用戶環(huán)境上進(jìn)行，并和用戶共同完成。lpha（）測試和Beta（）測試進(jìn)一步彰顯全過程測試4.1.3 W模型4.1.2 TMappTMap (Test Manag

11、ement Approach，測試管理方法)是一種結(jié)構(gòu)化的、基于風(fēng)險(xiǎn)策略的測試方法體系, 目的能更早地發(fā)現(xiàn)缺陷，以最小的成本、有效地、徹底地完成測試任務(wù)，以減少軟件發(fā)布后的支持成本。pTMap所定義的測試生命周期由計(jì)劃和控制、準(zhǔn)備、說明、計(jì)劃和控制、準(zhǔn)備、說明、執(zhí)行和完成等執(zhí)行和完成等階段組成參考： http:/ NEXT之背景p測試的獨(dú)立性 和開發(fā)更緊密的融合p更多種類的測試組織，包括測試工廠pBDTM, Business Driven Test Managementp新的測試方法、技術(shù)，特別測試設(shè)計(jì)方法p測試的基礎(chǔ)設(shè)施、支持流程p測試估算、風(fēng)險(xiǎn)分析p增加測試類型TMap NEXThttp:

12、/ 單元測試是對軟件基本的組成單元進(jìn)行獨(dú)立的測試p時(shí)機(jī) 單元測試和編碼是同步進(jìn)行，但在TDD中，強(qiáng)調(diào)測試在先，編碼在后。單元測試一般由開發(fā)人員完成,QA人員輔助.p概念 模塊、組件、單元模塊、組件、單元 單元測試的目標(biāo)p目標(biāo): 單元模塊被正確編碼p信息能否正確地流入和流出單元p在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤，全局變量在單元中的處理和影響p為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作p單元的運(yùn)行能否做到滿足特定的邏輯覆蓋任務(wù):模塊獨(dú)立執(zhí)行路徑測試檢查每一條獨(dú)立執(zhí)行路徑的測試，并保證每條語句被至少檢查每一條獨(dú)立執(zhí)行路徑的測試，并保證每條語句

13、被至少執(zhí)行一次。執(zhí)行一次。Checklist:p 誤解或用錯(cuò)了算符優(yōu)先級p 混合類型運(yùn)算p 變量初值錯(cuò) p 精度不夠 p 表達(dá)式符號錯(cuò) p 其它任務(wù)2:局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:p 不適合或不相容的類型說明p 變量無初值p 變量初始化或默認(rèn)值有錯(cuò)p 不正確的變量名或從來未被使用過p 出現(xiàn)上溢或下溢和地址異常p 其它任務(wù):模塊接口測試檢查模塊接口是否正確檢查模塊接口是否正確checklist:p輸入的實(shí)際參數(shù)與形式參數(shù)是否一致(個(gè)數(shù)、屬性、量綱)p調(diào)用其他模塊的實(shí)際參數(shù)與被調(diào)模塊的形參是否一致。 個(gè)數(shù)、屬性、量綱p全程變量的定義在各模塊是否一

14、致。p外部輸入、輸出p文件、緩沖區(qū)、錯(cuò)誤處理p其它任務(wù):單元邊界條件測試檢查臨界數(shù)據(jù)處理的正確性檢查臨界數(shù)據(jù)處理的正確性Checklist:p 普通合法數(shù)據(jù)的處理。p 普通非法數(shù)據(jù)的處理。p 邊界值內(nèi)合法邊界數(shù)據(jù)的處理。p 邊界值外非法邊界數(shù)據(jù)的處理。p 其它任務(wù)5: 單元容錯(cuò)測試預(yù)設(shè)的各種出錯(cuò)處理是否正確有效。預(yù)設(shè)的各種出錯(cuò)處理是否正確有效。Checklist:p 輸出的出錯(cuò)信息難以理解p 記錄的錯(cuò)誤與實(shí)際不相符p 異常處理不當(dāng)p 未提供足夠的定位出錯(cuò)的信息p 其它任務(wù)6：內(nèi)存分析p內(nèi)存泄漏會(huì)導(dǎo)致系統(tǒng)運(yùn)行的崩潰；p測量內(nèi)存的使用情況，了解程序內(nèi)存分配的真實(shí)情況；p系統(tǒng)崩潰前發(fā)現(xiàn)內(nèi)存泄漏錯(cuò)誤；

15、p發(fā)現(xiàn)內(nèi)存分配錯(cuò)誤，并精確顯示發(fā)生錯(cuò)誤時(shí)的上下文情況，指出發(fā)生錯(cuò)誤的原由。驅(qū)動(dòng)程序和樁程序運(yùn)行單元程序有時(shí)需要基于被測單元的接口，開發(fā)相應(yīng)的運(yùn)行單元程序有時(shí)需要基于被測單元的接口，開發(fā)相應(yīng)的驅(qū)動(dòng)模塊和樁模塊。驅(qū)動(dòng)模塊和樁模塊。p驅(qū)動(dòng)模塊（drive）:對底層或子層模塊進(jìn)行測試所編寫的調(diào)用這些模塊的程序。p樁模塊（stub）：對頂層或上層模塊進(jìn)行測試時(shí)所編寫的替代下層模塊的程序。集成測試的模式漸增式測試模式與非漸增式測試模式漸增式測試模式與非漸增式測試模式非漸增式測試模式非漸增式測試模式：先分別測試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求放在一起結(jié)合成所要的程序，如大棒模式。漸增式測試模式漸增式測試模式

16、：把下一個(gè)要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個(gè)應(yīng)該測試的模塊結(jié)合進(jìn)來測試。各自的優(yōu)缺點(diǎn)各自的優(yōu)缺點(diǎn)漸增式測試模式需要編寫的軟件較多，工作量較大，而非漸增式測試模式開銷小。漸增式測試模式發(fā)現(xiàn)模塊間的接口錯(cuò)誤早；而非漸增式測試模式晚。非漸增式測試模式發(fā)現(xiàn)錯(cuò)誤，較難診斷；而使用漸增式測試模式，如果發(fā)生錯(cuò)誤則往往和最近加進(jìn)來的那個(gè)模塊有關(guān)。漸增式測試模式測試更徹底。漸增式測試模式需要較多的機(jī)器時(shí)間。使用非漸增式測試模式，可以并行測試。優(yōu)缺點(diǎn)大棒集成方法(Big-bang Integration)采用大棒集成方法采用大棒集成方法,先是對每一個(gè)子模塊進(jìn)行測試（單元測試階段）

17、，先是對每一個(gè)子模塊進(jìn)行測試（單元測試階段），然后將所有模塊一次性的全部集成起來進(jìn)行集成測試然后將所有模塊一次性的全部集成起來進(jìn)行集成測試 。因?yàn)樗械哪K一次集成的，所以很難確定出錯(cuò)的真正位置、所在的模塊、錯(cuò)誤的原因。這種方法并不推薦在任何系統(tǒng)中使用，適合在規(guī)模較小的應(yīng)用系統(tǒng)中使用。 自頂向下和自底向上集成方法 自頂向下法(Top-down Integration) 自頂向下法的主要優(yōu)缺點(diǎn)自頂向下法的主要優(yōu)缺點(diǎn)優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：不需要測試驅(qū)動(dòng)程序，能夠在測試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能 ，而且能夠在早期發(fā)現(xiàn)上層模塊的接口錯(cuò)誤。缺點(diǎn)：需要樁程序，可能遇到于此想聯(lián)系的測試?yán)щy，低層關(guān)鍵模塊中的

18、錯(cuò)誤發(fā)現(xiàn)的比較晚，而且用這種方法在早期不能充分開展人力。自底向上法 Bottom-up Integration 自底向上法的主要優(yōu)缺點(diǎn)自底向上法的主要優(yōu)缺點(diǎn)優(yōu)缺點(diǎn)：與自頂向下模式剛好相反三明治集成方法(Sandwich Integration) 采用三明治方法的優(yōu)點(diǎn)是：它將自頂向下和自底向上的集成方法有機(jī)地結(jié)合起來，不需要寫樁程序因?yàn)樵跍y試初自底向上集成已經(jīng)驗(yàn)證了底層模塊的正確性。采用這種方法的主要缺點(diǎn)是：在真正集成之前每一個(gè)獨(dú)立的模塊沒有完全測試過。改善的三明治集成方法改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個(gè)模改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個(gè)模塊得到單

19、獨(dú)的測試，使測試進(jìn)行得比較徹底塊得到單獨(dú)的測試，使測試進(jìn)行得比較徹底 。幾種集成方法性能的比較 自底向上自底向上 自頂向下自頂向下 混合策略混合策略大棒大棒三明治三明治改進(jìn)三明治改進(jìn)三明治集成集成早早早早早早晚晚早早早早基本程序能工作時(shí)間基本程序能工作時(shí)間晚晚早早早早晚晚早早早早需要驅(qū)動(dòng)程序需要驅(qū)動(dòng)程序是是否否是是是是是是是是需要樁程序需要樁程序否否是是是是是是是是是是工作并行性工作并行性中中低低中中高高中中高高特殊路徑測試特殊路徑測試容易容易難難容易容易容易容易中等中等容易容易計(jì)劃與控制計(jì)劃與控制容易容易難難難難容易容易難難難難系統(tǒng)測試p系統(tǒng)測試：系統(tǒng)測試：將經(jīng)過集成測試后的軟件，作為計(jì)算機(jī)

20、系統(tǒng)的將經(jīng)過集成測試后的軟件，作為計(jì)算機(jī)系統(tǒng)的一部分，與計(jì)算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺(tái)等系一部分，與計(jì)算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺(tái)等系統(tǒng)元素結(jié)合起來，在真實(shí)運(yùn)行環(huán)境下對計(jì)算機(jī)系統(tǒng)進(jìn)行一統(tǒng)元素結(jié)合起來，在真實(shí)運(yùn)行環(huán)境下對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的嚴(yán)格有效的測試來發(fā)現(xiàn)軟件的潛在問題，保證系統(tǒng)系列的嚴(yán)格有效的測試來發(fā)現(xiàn)軟件的潛在問題，保證系統(tǒng)的正常運(yùn)行。的正常運(yùn)行。p目的：目的：充分運(yùn)行系統(tǒng)，驗(yàn)證整個(gè)系統(tǒng)是否滿足功能和非功充分運(yùn)行系統(tǒng)，驗(yàn)證整個(gè)系統(tǒng)是否滿足功能和非功能性的質(zhì)量需求。能性的質(zhì)量需求。p非功能性測試是系統(tǒng)測試中更為關(guān)鍵的任務(wù)！非功能性測試是系統(tǒng)測試中更為關(guān)鍵的任務(wù)！回歸測試的目的

21、回歸測試的目的 p 所做的修改達(dá)到了預(yù)定的目的，如錯(cuò)誤得到了改正，新功能得到了實(shí)現(xiàn)，能夠適應(yīng)新的運(yùn)行環(huán)境等；p 不影響軟件原有功能的正確性。6.2 回歸測試 一旦程序某些區(qū)域被修改了，就可能影響其它區(qū)域，導(dǎo)致受影響的區(qū)域出現(xiàn)新的缺陷（回歸缺陷）。如果這時(shí)沒有回歸測試，產(chǎn)品就帶著這樣的回歸缺陷被發(fā)布出去了，造成嚴(yán)重后果?；貧w測試就是為了發(fā)現(xiàn)回歸缺陷而進(jìn)行的測試。什么是性能測試？什么是性能測試？性能測試性能測試（performance test）就是為了發(fā)現(xiàn)系統(tǒng)性能問題或獲取系統(tǒng)性能相關(guān)指標(biāo)而進(jìn)行的測試。一般在真實(shí)環(huán)境真實(shí)環(huán)境、特定負(fù)載特定負(fù)載條件下，通過工具模擬工具模擬實(shí)際軟件系統(tǒng)的運(yùn)行及其操作

22、，同時(shí)監(jiān)控性能各項(xiàng)指標(biāo)，最后對測試結(jié)果進(jìn)行分析來確定系統(tǒng)的性能狀況。性能測試目標(biāo)性能測試目標(biāo)Performance Testingv獲取系統(tǒng)性能某些指標(biāo)數(shù)據(jù)v為了驗(yàn)證系統(tǒng)是否達(dá)到用戶提出的性能指標(biāo)v發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，優(yōu)化系統(tǒng)的性能壓力壓力/ /負(fù)載測試負(fù)載測試壓力測試壓力測試(Stress test)，也稱為強(qiáng)度測試、負(fù)載測試。壓力測試是模擬實(shí)際應(yīng)用的軟硬件環(huán)境及用戶使用過程的系統(tǒng)負(fù)荷，長時(shí)間或超大負(fù)荷地運(yùn)行測試軟件，來測試被測系統(tǒng)的性能、可靠性、穩(wěn)定性等。兩種負(fù)載類型兩種負(fù)載類型“FlatFlat”測試測試: : 對于一次給定的測試，應(yīng)該取響應(yīng)時(shí)間和吞吐量的平均值。精確地獲得這些值的

23、唯一方法是一次一次加載所有的用戶加載所有的用戶，然后在預(yù)定的時(shí)間段內(nèi)持續(xù)時(shí)間段內(nèi)持續(xù)運(yùn)行。虛擬用戶的數(shù)量虛擬用戶的數(shù)量兩種負(fù)載類型兩種負(fù)載類型 Ramp-upRamp-up測試測試: : 用戶是交錯(cuò)上升的（每幾秒增加一些新用戶）。ramp-up測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因?yàn)橛捎谟脩舻脑黾邮敲看我徊糠?，系統(tǒng)的負(fù)載在不斷地變化。其優(yōu)點(diǎn)是，可以看出隨著系統(tǒng)負(fù)載的改變，測量值是如何改變的據(jù)此選擇要運(yùn)行的flat測試的范圍。安全性測試安全性測試 p想方設(shè)法截取或破譯口令；p專門開發(fā)軟件來破壞系統(tǒng)的保護(hù)機(jī)制；p故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；p試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過被保護(hù)信息的價(jià)值，此時(shí)非法侵入者已無利可圖。軟件安全性測試就是檢驗(yàn)系統(tǒng)權(quán)限設(shè)置有效性、防范非法入侵的能力、數(shù)據(jù)備份和恢復(fù)能力等，設(shè)法找出上述各種安全性漏洞 功能性測試功能性測試 vs.安全性測試安全性測試p功能性測試：軟件做它應(yīng)該做的事，驗(yàn)證正確的輸出 不正確的輸出 /行為 / 缺陷(Bug)p安全性測試：軟件不做它不應(yīng)該做的事, 應(yīng)用輸入驗(yàn)證, 沒有不安全的事情發(fā)生在測試軟件系統(tǒng)中對危險(xiǎn)防止和危險(xiǎn)處理設(shè)施進(jìn)行的測試，以驗(yàn)證其是否有效 安全