軟件測試策略與過程

軟件測試策略與過程第1頁，共152頁，2023年，2月20日，星期日本章教學(xué)目標(biāo)理解軟件測試的復(fù)雜性理解軟件測試的方法與策略明確單元測試的主要任務(wù)和過程明確集成測試的方法和確認(rèn)測試的準(zhǔn)則明確系統(tǒng)測試的八個(gè)領(lǐng)域測試要點(diǎn)明確驗(yàn)收測試的主要內(nèi)容和相關(guān)配置第2頁，共152頁，2023年，2月20日，星期日概況定義：為了發(fā)現(xiàn)程序的錯(cuò)誤而執(zhí)行程序的過程軟件測試是SQA的重要手段，屬于軟件工程領(lǐng)域目前狀況軟件測試的實(shí)踐性大于理論性軟件測試?yán)碚擉w系尚不成熟軟件測試工具尚不成熟軟件測試效果對(duì)于個(gè)人的依賴性比較大第3頁，共152頁，2023年，2月20日，星期日目的為了尋找錯(cuò)誤，并盡可能地為修正錯(cuò)誤提供更多的信息為了證明軟件有錯(cuò)誤，而不證明軟件沒有錯(cuò)誤作用發(fā)現(xiàn)并管理缺陷度量質(zhì)量評(píng)價(jià)工作效率和效果預(yù)期項(xiàng)目風(fēng)險(xiǎn)第4頁，共152頁，2023年，2月20日，星期日衡量標(biāo)準(zhǔn)多能夠找到盡可能多的、以至于所有的BUG快能夠盡可能早地發(fā)現(xiàn)最嚴(yán)重的BUG好找到的BUG是關(guān)鍵的、用戶最關(guān)心的找到BUG后能夠重現(xiàn)找到的BUG，并為修正BUG提供盡可能多的信息省能夠用最少的時(shí)間、人力和資源發(fā)現(xiàn)BUG測試的過程和數(shù)據(jù)可以重用第5頁，共152頁，2023年，2月20日，星期日4.1軟件測試的復(fù)雜性分析

1、無法對(duì)程序進(jìn)行完全測試（1）測試所需要的輸入量太大（2）測試的輸出結(jié)果太多（3）軟件實(shí)現(xiàn)的途徑太多（4）軟件規(guī)格說明沒有一個(gè)客觀標(biāo)準(zhǔn)

2、測試無法顯示潛在的軟件缺陷和故障

——通過軟件測試只能報(bào)告軟件已被發(fā)現(xiàn)的缺陷和故障，無法報(bào)告隱藏的軟件故障。

3、存在的故障現(xiàn)象與發(fā)現(xiàn)的故障數(shù)量成正比

——結(jié)論：應(yīng)當(dāng)對(duì)故障集中的程序段進(jìn)行重點(diǎn)測試第6頁，共152頁，2023年，2月20日，星期日軟件測試的復(fù)雜性分析（續(xù)）

4、不能修復(fù)所有的軟件故障

——原因：沒有足夠的時(shí)間進(jìn)行修復(fù)；修復(fù)的風(fēng)險(xiǎn)較大；不值得修復(fù)；可不算做故障的一些缺陷；“殺蟲劑現(xiàn)象”。

——結(jié)論：關(guān)鍵是要進(jìn)行正確的判斷、合理的取舍，根據(jù)風(fēng)險(xiǎn)分析決定哪些故障必須修復(fù)，哪些故障可以不修復(fù)。

5、軟件測試的代價(jià)

——工作原則：就是如何將無邊無際的可能性減小到一個(gè)可以控制的范圍，以及如何針對(duì)軟件風(fēng)險(xiǎn)做出恰當(dāng)選擇，去粗存精，找到最佳的測試量，使得測試工作量不多也不少，既能達(dá)到測試的目的，又能較為經(jīng)濟(jì)。第7頁，共152頁，2023年，2月20日，星期日軟件測試的復(fù)雜性分析（續(xù)）軟件缺陷故障數(shù)量測試工作量測試中測試后測試費(fèi)用遺漏缺陷數(shù)目優(yōu)化測試量圖2-1測試工作量和軟件缺陷數(shù)量之間的關(guān)系第8頁，共152頁，2023年，2月20日，星期日4.2軟件測試方法與策略4.2.1靜態(tài)測試與動(dòng)態(tài)測試4.2.2黑盒測試與白盒測試4.2.3軟件測試過程第9頁，共152頁，2023年，2月20日，星期日軟件測試策略什么是軟件測試策略？

——是為軟件工程過程定義的一個(gè)軟件測試的模板，也就是把特定的測試用例方法放置進(jìn)去的一系列步驟。軟件測試策略包含的特征：（1）測試從模塊層開始，然后擴(kuò)大延伸到整個(gè)基于計(jì)算機(jī)的系統(tǒng)集合中。（2）不同的測試技術(shù)適用于不同的時(shí)間點(diǎn)。（3）測試是由軟件的開發(fā)人員和（對(duì)于大型系統(tǒng)而言）獨(dú)立的測試組來管理的。（4）測試和調(diào)試是不同的活動(dòng)，但是調(diào)試必須能夠適應(yīng)任何的測試策略。第10頁，共152頁，2023年，2月20日，星期日軟件測試充分性準(zhǔn)則對(duì)任何軟件都存在有限的充分測試集合。如果一個(gè)軟件系統(tǒng)在一個(gè)測試數(shù)據(jù)集合上的測試是充分的，那么再多測試一些數(shù)據(jù)也應(yīng)該是充分的。這一特性稱為單調(diào)性。即使對(duì)軟件所有成分都進(jìn)行了充分的測試，也并不表明整個(gè)軟件的測試已經(jīng)充分了。這一特性稱為非復(fù)合性。即使對(duì)軟件系統(tǒng)整體的測試是充分的，也并不意味軟件系統(tǒng)中各個(gè)成分都已經(jīng)充分地得到了測試。這個(gè)特性稱為非分解性。軟件測試的充分性應(yīng)該與軟件的需求和軟件的實(shí)現(xiàn)都相關(guān)。軟件越復(fù)雜，需要的測試數(shù)據(jù)就越多。這一特性稱為復(fù)雜性。測試得越多，進(jìn)一步測試所能得到的充分性增長就越少。這一特性稱為回報(bào)遞減率。第11頁，共152頁，2023年，2月20日，星期日測試技術(shù)不實(shí)際運(yùn)行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯(cuò)誤并評(píng)估代碼質(zhì)量的軟件測試技術(shù)。也稱為靜態(tài)分析技術(shù)。實(shí)際運(yùn)行程序，并通過觀察程序運(yùn)行的實(shí)際結(jié)果來發(fā)現(xiàn)錯(cuò)誤的軟件測試技術(shù)。在不知道程序內(nèi)部結(jié)構(gòu)，只知道程序規(guī)格的情況下采用的測試技術(shù)或策略。在知道程序內(nèi)部結(jié)構(gòu)的情況下采用的測試技術(shù)或策略。開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。針對(duì)要求的程序功能，按照規(guī)范的流程進(jìn)行的測試。針對(duì)要求的程序功能以外的其他要求，包括性能、安全、配置、負(fù)載等指標(biāo)，按照規(guī)范的流程進(jìn)行的測試。針對(duì)要求的程序功能、性能、安全、配置、負(fù)載等指標(biāo)，基于破壞目的、按照經(jīng)驗(yàn)進(jìn)行的隨機(jī)測試。程序修改或者版本更新以后，為了確保以前正確的功能和其他指標(biāo)仍舊正確，而重新進(jìn)行的測試。在測試過程中，選擇足夠的測試用例，使得每一個(gè)可執(zhí)行語句至少被執(zhí)行一次。在測試過程中，選擇足夠的測試用例，使得程序中的每一個(gè)分支判斷的每一種可能結(jié)果都至少被執(zhí)行一次。在測試過程中，選擇足夠的測試用例，使得程序中的每一條可能執(zhí)行的路徑都至少執(zhí)行一次。第12頁，共152頁，2023年，2月20日，星期日測試過程規(guī)格定義設(shè)計(jì)編碼系統(tǒng)測試集成測試單元測試用戶需求驗(yàn)收測試回歸測試配置管理缺陷跟蹤第13頁，共152頁，2023年，2月20日，星期日4.2.1靜態(tài)測試與動(dòng)態(tài)測試1、靜態(tài)測試靜態(tài)測試不實(shí)際運(yùn)行軟件，主要是對(duì)軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評(píng)估。靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，也可以借助軟件工具自動(dòng)進(jìn)行。靜態(tài)測試方法也可利用計(jì)算機(jī)作為對(duì)被測程序進(jìn)行特性分析的工具，但與人工測試方式有著根本區(qū)別。另一方面，因它并不真正運(yùn)行被測程序，只進(jìn)行特性分析，這又與動(dòng)態(tài)方法不同。所以，靜態(tài)方法常常稱為“分析”，靜態(tài)測試是對(duì)被測程序進(jìn)行特性分析方法的總稱。第14頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）

代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計(jì)的一致性，代碼對(duì)標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面。代碼檢查的具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等。代碼檢查的優(yōu)點(diǎn)：在實(shí)際使用中，代碼檢查比動(dòng)態(tài)測試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%～70%的邏輯設(shè)計(jì)和編碼缺陷；代碼檢查看到的是問題本身而非征兆。代碼檢查的缺點(diǎn)：非常耗費(fèi)時(shí)間，而且代碼檢查需要知識(shí)和經(jīng)驗(yàn)的積累。第15頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）

靜態(tài)結(jié)構(gòu)分析靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)。例如函數(shù)調(diào)用關(guān)系圖、函數(shù)內(nèi)部控制流圖。其中：

——函數(shù)調(diào)用關(guān)系圖以直觀的圖形方式描述一個(gè)應(yīng)用程序中各個(gè)函數(shù)的調(diào)用和被調(diào)用關(guān)系；

——控制流圖顯示一個(gè)函數(shù)的邏輯結(jié)構(gòu)，由許多節(jié)點(diǎn)組成，一個(gè)節(jié)點(diǎn)代表一條語句或數(shù)條語句，連接結(jié)點(diǎn)的叫邊，邊表示節(jié)點(diǎn)間的控制流向。第16頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）

代碼質(zhì)量度量軟件質(zhì)量包括六個(gè)方面：功能性、可靠性、易用性、效率、可維護(hù)性和可移植性。軟件的質(zhì)量是軟件屬性的各種標(biāo)準(zhǔn)度量的組合。針對(duì)軟件的可維護(hù)性，目前業(yè)界主要存在三種度量參數(shù)：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。其中Line復(fù)雜度以代碼的行數(shù)作為計(jì)算的基準(zhǔn)。Halstead以程序中使用到的運(yùn)算符與運(yùn)算元數(shù)量作為計(jì)數(shù)目標(biāo)（直接測量指標(biāo)），然后可以據(jù)以計(jì)算出程序容量、工作量等。McCabe復(fù)雜度一般稱為圈復(fù)雜度，它將軟件的流程圖轉(zhuǎn)化為有向圖，然后以圖論來衡量軟件的質(zhì)量。第17頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）靜態(tài)測試階段的任務(wù)：（1）檢查算法的邏輯正確性。（2）檢查模塊接口的正確性。（3）檢查輸入?yún)?shù)是否有合法性檢查。（4）檢查調(diào)用其他模塊的接口是否正確。（5）檢查是否設(shè)置了適當(dāng)?shù)某鲥e(cuò)處理。（6）檢查表達(dá)式、語句是否正確，是否含有二義性。（7）檢查常量或全局變量使用是否正確。（8）檢查標(biāo)識(shí)符的使用是否規(guī)范、一致。（9）檢查程序風(fēng)格的一致性、規(guī)范性。（10）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。第18頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）靜態(tài)測試可以完成以下工作：（1）發(fā)現(xiàn)下列程序的錯(cuò)誤：錯(cuò)用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當(dāng)?shù)难h(huán)嵌套或分支嵌套、死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標(biāo)號(hào)或代碼。（2）找出以下問題的根源：從未使用過的變量；不會(huì)執(zhí)行到的代碼、從未使用過的標(biāo)號(hào)；潛在的死循環(huán)。（3）提供程序缺陷的間接信息：所用變量和常量的交叉應(yīng)用表；是否違背編碼規(guī)則；標(biāo)識(shí)符的使用方法和過程的調(diào)用層次。（4）為進(jìn)一步查找做好準(zhǔn)備。（5）選擇測試用例。（6）進(jìn)行符號(hào)測試。第19頁，共152頁，2023年，2月20日，星期日靜態(tài)測試與動(dòng)態(tài)測試（續(xù)）2、動(dòng)態(tài)測試動(dòng)態(tài)方法的主要特征是：

——計(jì)算機(jī)必須真正運(yùn)行被測試的程序，通過輸入測試用例，對(duì)其運(yùn)行情況即輸入與輸出的對(duì)應(yīng)關(guān)系進(jìn)行分析，以達(dá)到檢測的目的。動(dòng)態(tài)測試包括：（1）功能確認(rèn)與接口測試（2）覆蓋率分析（3）性能分析（4）內(nèi)存分析第20頁，共152頁，2023年，2月20日，星期日4.2.2黑盒測試和白盒測試若測試規(guī)劃是基于產(chǎn)品的功能，目的是檢查程序各個(gè)功能是否能夠?qū)崿F(xiàn)，并檢查其中的功能錯(cuò)誤，則這種測試方法稱為黑盒測試(Black-boxTesting)方法。

——黑盒測試又稱為功能測試、數(shù)據(jù)驅(qū)動(dòng)測試和基于規(guī)格說明的測試。它是一種從用戶觀點(diǎn)出發(fā)的測試，一般被用來確認(rèn)軟件功能的正確性和可操作性。若測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)進(jìn)行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個(gè)部分功能是否得到充分使用，則這種測試方法稱為白盒測試(White-boxTesting)方法。

——白盒測試又稱為結(jié)構(gòu)測試、邏輯驅(qū)動(dòng)測試或基于程序的測試，一般用來分析程序的內(nèi)部結(jié)構(gòu)。

第21頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）白盒測試黑盒測試兩種測試方法從完全不同的角度出發(fā)，反映了測試思路的兩方面情況，適用于不同的測試階段。第22頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）1、黑盒測試黑盒測試的基本觀點(diǎn)是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程，被測程序被認(rèn)為是一個(gè)打不開的黑盒子，黑盒中的內(nèi)容（實(shí)現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測試主要根據(jù)規(guī)格說明書設(shè)計(jì)測試用例，并不涉及程序內(nèi)部構(gòu)造和內(nèi)部特性，只依靠被測程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計(jì)測試用例。黑盒測試的特點(diǎn)：（1）黑盒測試與軟件的具體實(shí)現(xiàn)過程無關(guān)，在軟件實(shí)現(xiàn)的過程發(fā)生變化時(shí)，測試用例仍然可以使用。（2）黑盒測試用例的設(shè)計(jì)可以和軟件實(shí)現(xiàn)同時(shí)進(jìn)行，這樣能夠壓縮總的開發(fā)時(shí)間。第23頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）輸入輸出黑盒測試是在程序接口進(jìn)行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。也被稱為用戶測試。第24頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：是否有不正確或遺漏了的功能？在接口上，輸入能否正確地接受？能否輸出正確的結(jié)果？是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息訪問錯(cuò)誤？性能上是否能夠滿足要求？是否有初始化或終止性錯(cuò)誤？黑盒測試的難點(diǎn)：在哪個(gè)層次上進(jìn)行測試？黑盒測試的具體技術(shù)方法：邊界值分析法等價(jià)類劃分法因果圖法決策表法第25頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）2、白盒測試白盒測試將被測程序看作一個(gè)打開的盒子，測試者能夠看到被測源程序，可以分析被測程序的內(nèi)部結(jié)構(gòu)，此時(shí)測試的焦點(diǎn)集中在根據(jù)其內(nèi)部結(jié)構(gòu)設(shè)計(jì)測試用例。白盒測試要求是對(duì)某些程序的結(jié)構(gòu)特性做到一定程度的覆蓋，或者說這種測試是“基于覆蓋率的測試”。通常的程序結(jié)構(gòu)覆蓋有：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋路徑覆蓋第26頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）白盒測試需要完全了解程序結(jié)構(gòu)和處理過程，它按照程序內(nèi)部邏輯測試程序，檢驗(yàn)程序中每條通路是否按預(yù)定要求正確工作。也被稱為程序員測試。應(yīng)用程序第27頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）？

X=2

y=2x

Y=4

X=2Y=4未知等式與已知等式黑盒白盒3、黑盒測試法和白盒測試法的比較第28頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）黑盒測試：

——以用戶的觀點(diǎn)，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系，即根據(jù)程序外部特性進(jìn)行測試，而不考慮內(nèi)部結(jié)構(gòu)及工作情況。

——黑盒測試技術(shù)注重于軟件的信息域（范圍），通過劃分程序的輸入和輸出域來確定測試用例。

——若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤，則應(yīng)用黑盒測試方法是不能發(fā)現(xiàn)問題的。第29頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）白盒測試：

——只根據(jù)程序的內(nèi)部結(jié)構(gòu)進(jìn)行測試。

——測試用例的設(shè)計(jì)要保證測試時(shí)程序的所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。

——如果程序的結(jié)構(gòu)本身有問題，比如說程序邏輯有錯(cuò)誤或者有遺漏，那也是無法發(fā)現(xiàn)的。第30頁，共152頁，2023年，2月20日，星期日黑盒測試和白盒測試（續(xù)）項(xiàng)目黑盒測試法白盒測試法規(guī)劃方面功能的測試結(jié)構(gòu)的測試優(yōu)點(diǎn)方面能確保從用戶的角度出發(fā)進(jìn)行測試能對(duì)程序內(nèi)部的特定部位進(jìn)行覆蓋測試缺點(diǎn)方面無法測試程序內(nèi)部特定部位；當(dāng)規(guī)格說明有誤，則不能發(fā)現(xiàn)問題無法檢查程序的外部特性；無法對(duì)未實(shí)現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進(jìn)行測試應(yīng)用范圍邊界分析法等價(jià)類劃分法決策表測試語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，路徑覆蓋，循環(huán)覆蓋，模塊接口測試第31頁，共152頁，2023年，2月20日，星期日4.2.3軟件測試過程單元測試單元測試單元測試集成測試集成測試確認(rèn)測試系統(tǒng)測試*這三個(gè)測試可能交叉與前后互換被測模塊被測模塊被測模塊設(shè)計(jì)信息單元軟件需求其它元素用戶信息其它元素*…*驗(yàn)收測試*交付用戶…圖2-2軟件測試的過程流程第32頁，共152頁，2023年，2月20日，星期日軟件測試過程（續(xù)）單元測試：針對(duì)每個(gè)單元的測試，

以確保每個(gè)模塊能正常工作為目標(biāo)。集成測試：對(duì)已測試過的模塊進(jìn)行組裝，進(jìn)行集成測試。目的在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。確認(rèn)（有效性）測試：是檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段。系統(tǒng)測試：檢驗(yàn)軟件產(chǎn)品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作。驗(yàn)收（用戶）測試：檢驗(yàn)軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用，同時(shí)軟件開發(fā)人員也應(yīng)有一定程度的參與。第33頁，共152頁，2023年，2月20日，星期日測試過程單元測試：UnitTesting目標(biāo)：檢驗(yàn)程序最小單元有無錯(cuò)誤接口、數(shù)據(jù)結(jié)構(gòu)、邊界、覆蓋、邏輯檢驗(yàn)單元編碼與設(shè)計(jì)是否吻合時(shí)機(jī)：編碼完成后，首先要實(shí)施的測試方法：靜態(tài)測試白盒測試責(zé)任：開發(fā)工程師第34頁，共152頁，2023年，2月20日，星期日測試過程集成測試：IntegrationTesting目標(biāo)：檢驗(yàn)組成系統(tǒng)的模塊接口有無錯(cuò)誤代碼實(shí)現(xiàn)的系統(tǒng)設(shè)計(jì)與需求定義是否吻合時(shí)機(jī)：主要的單元測試完成后，經(jīng)常與單元測試同步進(jìn)行方法：黑盒測試責(zé)任：開發(fā)工程師測試工程師第35頁，共152頁，2023年，2月20日，星期日測試過程系統(tǒng)測試：SystemTesting目標(biāo)：檢驗(yàn)組成整個(gè)系統(tǒng)的代碼、以及系統(tǒng)的軟硬件配合有無錯(cuò)誤代碼實(shí)現(xiàn)的系統(tǒng)與用戶需求是否吻合檢驗(yàn)系統(tǒng)的文檔等是否完整、有效模擬驗(yàn)收測試的要求，檢查系統(tǒng)是否符合用戶的驗(yàn)收標(biāo)準(zhǔn)時(shí)機(jī)：多數(shù)集成測試完成后方法：黑盒測試責(zé)任：測試工程師第36頁，共152頁，2023年，2月20日，星期日測試過程系統(tǒng)測試：SystemTesting穩(wěn)定期測試目標(biāo)：度量是否可以結(jié)束測試時(shí)機(jī)：傳統(tǒng)的系統(tǒng)測試完成后方法：黑盒測試責(zé)任：測試工程師第37頁，共152頁，2023年，2月20日，星期日測試過程驗(yàn)收測試：AcceptanceTesting目標(biāo)：使客戶驗(yàn)收簽字系統(tǒng)是否符合事先約定的驗(yàn)收標(biāo)準(zhǔn)時(shí)機(jī)：系統(tǒng)測試完成后，在項(xiàng)目組看來開發(fā)和測試工作已經(jīng)全部完成，可以交付使用方法：黑盒測試責(zé)任：產(chǎn)品經(jīng)理或其他高級(jí)經(jīng)理開發(fā)工程師測試工程師用戶第38頁，共152頁，2023年，2月20日，星期日測試過程回歸測試：RegressionTesting目標(biāo)：驗(yàn)證程序修改或者版本更新以后，以前正確的功能和其他指標(biāo)仍舊正確。時(shí)機(jī)：每次錯(cuò)誤修改之后，或者版本更新之后方法：白盒測試/黑盒測試責(zé)任：開發(fā)工程師測試工程師第39頁，共152頁，2023年，2月20日，星期日測試過程缺陷跟蹤：DefectTracing目標(biāo)：確保所有發(fā)現(xiàn)的錯(cuò)誤被正確記錄、分發(fā)、評(píng)估、關(guān)閉、統(tǒng)計(jì)時(shí)機(jī)：從錯(cuò)誤發(fā)現(xiàn)開始到錯(cuò)誤關(guān)閉為止，每次錯(cuò)誤狀態(tài)修改之后方法：缺陷跟蹤系統(tǒng)責(zé)任：開發(fā)工程師、測試工程師、測試經(jīng)理、用戶第40頁，共152頁，2023年，2月20日，星期日一個(gè)實(shí)用軟件測試過程一種簡單實(shí)用的軟件測試過程模型POCERM。測試過程中必需的基本測試活動(dòng)及其產(chǎn)生的結(jié)果：擬定軟件測試計(jì)劃(Plans)編制軟件測試大綱(Outlines)設(shè)計(jì)和生成測試用例(testCasegeneration)實(shí)施測試(Execution)生成軟件測試報(bào)告(softwaretestingReports)軟件問題報(bào)告SPR(SoftwareProblemReport)測試結(jié)果報(bào)告(testresultReports)第41頁，共152頁，2023年，2月20日，星期日一個(gè)實(shí)用軟件測試過程（續(xù)）基本特性：（1）計(jì)劃性:任務(wù)人員設(shè)備時(shí)間相關(guān)...（2）平行性:開發(fā)編碼||測試再測試（3）完整性:計(jì)劃+大綱+用例+SPRs+...（4）重用性:測試再測試回歸測試升級(jí)多平臺(tái)…（5）可重復(fù)性:SPRs用例大綱再現(xiàn)Bugs（6）周期性:testcycles,regression,update（7）可管理性:wellstructuredandorganizedQEgroup+wellplannedandpreparedtask第42頁，共152頁，2023年，2月20日，星期日測試階段

測試過程的三個(gè)主要的測試活動(dòng)（計(jì)劃、準(zhǔn)備和實(shí)施）可被分成五個(gè)階段：Theplanningandcontrolphase－計(jì)劃和控制階段Thepreparationphase－準(zhǔn)備階段Thespecificationphase－規(guī)范階段Theexecutionphase－實(shí)施執(zhí)行階段Thecompletionphase－完成（收尾）階段第43頁，共152頁，2023年，2月20日，星期日測試的五個(gè)階段Plan&ControlCSEPP&CPreparationSpecificationExecutionCompletion第44頁，共152頁，2023年，2月20日，星期日計(jì)劃與控制階段它是整個(gè)測試過程中最重要的階段，為實(shí)現(xiàn)可管理且高質(zhì)量的測試過程提供基礎(chǔ)。本階段的主要工作內(nèi)容：（1）擬定測試計(jì)劃（2）論證那些使開發(fā)過程難于管理和控制的因素（3）明確軟件產(chǎn)品的最重要部分（風(fēng)險(xiǎn)評(píng)估）第45頁，共152頁，2023年，2月20日，星期日準(zhǔn)備階段開始本階段的前提條件：—完成測試計(jì)劃的擬定。—需求規(guī)格說明書（第一版）的確定。本階段的主要工作內(nèi)容：—對(duì)需求規(guī)格說明書的仔細(xì)研究?！獙⒁獪y試的產(chǎn)品分解成可獨(dú)立測試的單元?！獮槊總€(gè)測試單元確定采用的測試技術(shù)。—為測試的下一個(gè)階段及其活動(dòng)制定計(jì)劃。第46頁，共152頁，2023年，2月20日，星期日規(guī)范階段本階段的主要工作內(nèi)容：—編寫測試大綱/測試用例，測試腳本—搭建測試環(huán)境（測試數(shù)據(jù)庫，軟件環(huán)境，硬件環(huán)境）測試用例描述的內(nèi)容：—輸入—執(zhí)行過程—預(yù)期輸出第47頁，共152頁，2023年，2月20日，星期日實(shí)施執(zhí)行階段根據(jù)測試大綱/測試用例/測試腳本進(jìn)行測試（1）根據(jù)測試大綱/測試用例進(jìn)行測試，找出預(yù)期的測試結(jié)果和實(shí)際測試結(jié)果之間的差異（2）填寫軟件問題報(bào)告（3）確定造成這些差異的原因：產(chǎn)品有缺陷？規(guī)格說明書有缺陷？測試環(huán)境和測試下屬部件有缺陷？測試用例設(shè)計(jì)不合理？測試報(bào)告——與管理層進(jìn)行溝通的方式已測試部分占產(chǎn)品多大的百分比？還有什么工作要做？找到了多少個(gè)問題或不足？測試的發(fā)展趨勢如何？測試可以結(jié)束了嗎？第48頁，共152頁，2023年，2月20日，星期日完成階段本階段的主要工作內(nèi)容：

—選擇和保留測試大綱、測試用例、測試結(jié)果、測試工具。

—提交最終報(bào)告。收尾工作的意義和重要性：

—產(chǎn)品如果升級(jí)或功能變更，或維護(hù)，只要對(duì)保留下來的相關(guān)測試數(shù)據(jù)只要作相應(yīng)調(diào)整，就能夠進(jìn)行新的測試。第49頁，共152頁，2023年，2月20日，星期日4.3單元測試4.3.1單元測試的主要任務(wù)4.3.2單元測試技術(shù)4.3.3單元測試流程4.3.4單元測試的執(zhí)行過程4.3.3單元測試文檔第50頁，共152頁，2023年，2月20日，星期日單元測試概況定義：檢驗(yàn)程序最小單位有無錯(cuò)誤。一般在編碼之后，由開發(fā)人員完成。單元：軟件開發(fā)中的最小的獨(dú)立部分C語言中的單元：函數(shù)或者是子過程C++語言中的單元：類目前狀況：實(shí)施效果非常好，但是實(shí)施阻力比較大(主要是人員和管理因素)，一般只在關(guān)鍵的程序單元中實(shí)施有比較系統(tǒng)的理論和方法，但也依賴于系統(tǒng)的特殊性和開發(fā)人員的經(jīng)驗(yàn)有大量的輔助工具，開發(fā)人員也經(jīng)常自己開發(fā)測試代碼和測試工具主要使用白盒測試和靜態(tài)分析，也使用黑盒測試第51頁，共152頁，2023年，2月20日，星期日單元測試目標(biāo)1、檢查代碼實(shí)現(xiàn)是否符合設(shè)計(jì)不能檢查設(shè)計(jì)是否正確2、盡早發(fā)現(xiàn)錯(cuò)誤Microsoftapplications10-20defects/KLOCduringunittesting0.5defects/KLOCafterrelease性價(jià)比最好第52頁，共152頁，2023年，2月20日，星期日4.3.1單元測試的主要任務(wù)單元測試針對(duì)每個(gè)程序的模塊，主要測試5個(gè)方面的問題：

——模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨(dú)立的路徑和錯(cuò)誤處理。模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)路徑測試出錯(cuò)處理邊界條件第53頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)任務(wù)1、模塊接口測試檢查進(jìn)出模塊的數(shù)據(jù)是否正確Checklist：模塊的實(shí)際輸入與定義的輸入是否一致個(gè)數(shù)、類型、順序模塊中對(duì)于非內(nèi)部/局部變量是否合理使用使用其他模塊時(shí)，是否檢查可用性和處理結(jié)果使用外部資源時(shí)，是否檢查可用性并及時(shí)釋放資源內(nèi)存、文件、硬盤、端口等其他第54頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)任務(wù)2、模塊局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)能否保持完整性Checklist：變量從來沒有被使用可能別的地方使用了錯(cuò)誤的變量名變量沒有初始化錯(cuò)誤的類型轉(zhuǎn)換數(shù)組越界非法指針變量或函數(shù)名稱拼寫錯(cuò)誤使用了外部變量或函數(shù)其他第55頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)任務(wù)3、模塊邊界條件測試檢查臨界數(shù)據(jù)是否正確處理Checklist：普通合法數(shù)據(jù)是否正確處理普通非法數(shù)據(jù)是否正確處理邊界內(nèi)最接近邊界的(合法)數(shù)據(jù)是否正確處理邊界外最接近邊界的(非法)數(shù)據(jù)是否正確處理其他第56頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)任務(wù)4、模塊獨(dú)立執(zhí)行通路(路徑)測試檢查由于計(jì)算錯(cuò)誤、判定錯(cuò)誤、控制流錯(cuò)誤導(dǎo)致的程序錯(cuò)誤Checklist：死代碼錯(cuò)誤的計(jì)算優(yōu)先級(jí)精度錯(cuò)誤比較運(yùn)算錯(cuò)誤賦值錯(cuò)誤表達(dá)式的不正確符號(hào)>、>=；=、==、!=循環(huán)變量的使用錯(cuò)誤錯(cuò)誤賦值其他第57頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)任務(wù)5、模塊內(nèi)部錯(cuò)誤處理測試檢查內(nèi)部錯(cuò)誤處理設(shè)施是否有效Checklist：是否檢查錯(cuò)誤出現(xiàn)資源使用前后其他模塊使用前后出現(xiàn)錯(cuò)誤，是否進(jìn)行錯(cuò)誤處理拋出錯(cuò)誤通知用戶進(jìn)行記錄錯(cuò)誤處理是否有效在系統(tǒng)干預(yù)前處理報(bào)告和記錄的錯(cuò)誤真實(shí)詳細(xì)其他第58頁，共152頁，2023年，2月20日，星期日4.3.2單元測試技術(shù)靜態(tài)分析定義：不實(shí)際運(yùn)行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯(cuò)誤并評(píng)估代碼質(zhì)量的軟件測試技術(shù)。也稱為靜態(tài)測試技術(shù)。方法：走查：WalkThrough審查：Inspection評(píng)審：ReviewMichaelFaganIBM(1976)第59頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)靜態(tài)分析-走查定義：開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。經(jīng)驗(yàn)：限時(shí)避免跑題參加人員經(jīng)驗(yàn)豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項(xiàng)目組的新人由本模塊的開發(fā)者進(jìn)行講解、回答問題并記錄不要現(xiàn)場修改檢查要點(diǎn)邏輯錯(cuò)誤代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格第60頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)靜態(tài)分析-審查定義：開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。經(jīng)驗(yàn)：以會(huì)議的形式，制定會(huì)議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告參加人員經(jīng)驗(yàn)豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項(xiàng)目組的新人由另外一名開發(fā)者進(jìn)行講解、其他開發(fā)者主要按照Checklist進(jìn)行提問并填表、本模塊開發(fā)者回答問題并記錄不要現(xiàn)場修改檢查要點(diǎn)設(shè)計(jì)需求代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格第61頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)靜態(tài)分析-評(píng)審定義：開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。經(jīng)驗(yàn)：以會(huì)議的形式，制定會(huì)議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告。相關(guān)資料要在會(huì)議前下發(fā)并閱讀。參加人員經(jīng)驗(yàn)豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員測試組和相關(guān)人員由另外一名開發(fā)者進(jìn)行講解、其他開發(fā)者主要按照Checklist進(jìn)行提問并填表、本模塊開發(fā)者回答問題并記錄不要現(xiàn)場修改檢查要點(diǎn)設(shè)計(jì)需求代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格文檔的完整性和一致性第62頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)測試設(shè)計(jì)定義：依據(jù)模塊的內(nèi)部結(jié)構(gòu)，設(shè)計(jì)測試用例的過程。主要采用白盒測試技術(shù)，關(guān)注邏輯覆蓋原則：1、保證沒有死代碼保證一個(gè)模塊中的每個(gè)獨(dú)立路徑都可能被使用到2、保證對(duì)所有的邏輯值都測試true和false3、在上下邊界和合法的范圍內(nèi)運(yùn)行所有的循環(huán)4、確保內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性和完整性第63頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)測試設(shè)計(jì)邏輯覆蓋測試方法：1、語句覆蓋選擇足夠的測試用例，使得程序中每一條可執(zhí)行語句至少被執(zhí)行一次。2、判定覆蓋選擇足夠的測試用例，使得程序中每一個(gè)分支判斷的每一種可能結(jié)果(主要指switch-case情況)都至少被執(zhí)行一次。判定覆蓋也叫分支覆蓋。3、條件覆蓋選擇足夠的測試用例，使得程序中每一個(gè)分支判斷中的每一個(gè)條件的可能結(jié)果都至少被執(zhí)行一次。第64頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)測試設(shè)計(jì)邏輯覆蓋測試方法：4、判定/條件覆蓋選擇足夠的測試用例，使得同時(shí)滿足判定覆蓋和條件覆蓋。5、條件組合覆蓋選擇足夠的測試用例，使得程序中每一個(gè)分支判斷中的每一個(gè)條件的每一種可能組合結(jié)果都至少被執(zhí)行一次。6、路徑覆蓋選擇足夠的測試用例，使得程序中所有的可能路徑都至少被執(zhí)行一次。第65頁，共152頁，2023年，2月20日，星期日單元測試技術(shù)測試設(shè)計(jì)邏輯覆蓋測試方法：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋第66頁，共152頁，2023年，2月20日，星期日單元測試流程管理流程主要指動(dòng)態(tài)測試應(yīng)用流程測試計(jì)劃測試設(shè)計(jì)測試執(zhí)行測試記錄分析測試總結(jié)完畢缺陷跟蹤針對(duì)測試目標(biāo)，規(guī)定測試任務(wù)、資源分配、人員角色、進(jìn)度安排等。根據(jù)測試計(jì)劃，設(shè)計(jì)測試用例，包括：測試步驟、測試場景、測試代碼、測試數(shù)據(jù)(包括預(yù)期結(jié)果)。根據(jù)測試計(jì)劃，配置測試環(huán)境，并手動(dòng)或者自動(dòng)執(zhí)行測試設(shè)計(jì)。根據(jù)測試計(jì)劃，忠實(shí)地記錄測試執(zhí)行的過程和結(jié)果。分析測試記錄，如果發(fā)現(xiàn)與預(yù)期結(jié)果不同，確定并重現(xiàn)缺陷。檢查測試設(shè)計(jì)是否全部執(zhí)行完畢，缺陷是否全部關(guān)閉。記錄、分發(fā)、評(píng)估、關(guān)閉缺陷報(bào)告。分析測試過程和缺陷報(bào)告，評(píng)估測試質(zhì)量和測試效果，給出是否通過測試的建議。第67頁，共152頁，2023年，2月20日，星期日單元測試流程測試文檔主要指動(dòng)態(tài)測試應(yīng)用文檔測試計(jì)劃測試設(shè)計(jì)測試執(zhí)行測試記錄分析測試總結(jié)完畢缺陷跟蹤測試計(jì)劃文檔測試用例文檔測試記錄文檔缺陷跟蹤報(bào)告測試總結(jié)報(bào)告第68頁，共152頁，2023年，2月20日，星期日4.3.4單元測試的執(zhí)行過程何時(shí)進(jìn)行單元測試？單元測試常常是和代碼編寫工作同時(shí)進(jìn)行的，在完成了程序編寫、復(fù)查和語法正確性驗(yàn)證后，就應(yīng)進(jìn)行單元測試用例設(shè)計(jì)。在單元測試時(shí)，如果模塊不是獨(dú)立的程序，需要設(shè)置一些輔助測試模塊。輔助測試模塊有兩種：（1）驅(qū)動(dòng)模塊(Drive)用來模擬被測試模塊的上一級(jí)模塊，相當(dāng)于被測模塊的主程序。它接收數(shù)據(jù)，將相關(guān)數(shù)據(jù)傳送給被測模塊，啟動(dòng)被測模塊，并打印出相應(yīng)的結(jié)果。（2）樁模塊(Stub)用來模擬被測模塊工作過程中所調(diào)用的模塊。它們一般只進(jìn)行很少的數(shù)據(jù)處理。驅(qū)動(dòng)模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。第69頁，共152頁，2023年，2月20日，星期日單元測試的執(zhí)行過程（續(xù)）被測模塊、驅(qū)動(dòng)模塊和樁模塊共同構(gòu)成了一個(gè)如下圖所示的單元測試的測試環(huán)境：測試用例被測模塊驅(qū)動(dòng)模塊測試結(jié)果樁模塊1樁模塊2樁模塊3樁模塊n樁模塊…第70頁，共152頁，2023年，2月20日，星期日4.3.5單元測試文檔測試計(jì)劃編號(hào)如：ut-tp0016標(biāo)題如：文字排版功能.字間距.MarchCalculator版本號(hào)如：V1.0執(zhí)行狀態(tài)如：未執(zhí)行修改記錄如：2003年7月1日；某某編制/修改；原因測試目標(biāo)如：語句覆蓋測試人員如：某某1負(fù)責(zé)執(zhí)行測試用例xxx；某某2負(fù)責(zé)執(zhí)行測試用例xxx測試用例編號(hào)(多個(gè))如：ut-tc00021/ut-tc00031/ut-tc00035…被測試單元代碼位置如：$tag1/layout/marchCal.cpp第71頁，共152頁，2023年，2月20日，星期日單元測試文檔測試用例編號(hào)如：ut-tc00016標(biāo)題如：測試“文字排版功能.字間距.MarchCalculator”版本號(hào)如：V1.3執(zhí)行狀態(tài)如：已經(jīng)執(zhí)行修改記錄如：2003年7月2日；某某編制/修改；原因測試步驟如：配置運(yùn)行環(huán)境；輸入測試數(shù)據(jù)；執(zhí)行X功能/測試代碼；觀察/記錄XX測試場景如：在聯(lián)網(wǎng)的環(huán)境下測試代碼如：ut-tcc00021(位置)/ut-tcc00035(位置)…測試數(shù)據(jù)如：輸入數(shù)據(jù)(輸入文件、文字描述…)；預(yù)期結(jié)果(性能、圖片、文字描述…)第72頁，共152頁，2023年，2月20日，星期日單元測試文檔測試記錄編號(hào)如：ut-tr00016標(biāo)題如：記錄測試“文字排版功能.字間距.MarchCalculator”結(jié)果填寫記錄如：2003年7月2日；某某填寫；原因測試用例編號(hào)如：ut-tc0016輸出結(jié)果如：圖片、文字描述測試觀察符合/不符合期望結(jié)果第73頁，共152頁，2023年，2月20日，星期日單元測試文檔缺陷跟蹤報(bào)告編號(hào)如：ut-dt00016標(biāo)題如：文字排版功能.字間距.MarchCalculator計(jì)算錯(cuò)誤版本號(hào)如：V1.3執(zhí)行狀態(tài)如：空白/草稿/提交/審批/分發(fā)/正在修改/修改完畢/正在確認(rèn)/關(guān)閉…修改記錄如：2003年7月2日；某某編制/修改；原因測試環(huán)境和版本號(hào)碼、程序編寫人員錯(cuò)誤嚴(yán)重程度和優(yōu)先級(jí)別錯(cuò)誤詳細(xì)描述重現(xiàn)步驟和方式、對(duì)應(yīng)的測試記錄編碼附件建議修改方式修改內(nèi)容、結(jié)果及修改人員簽字/日期確認(rèn)內(nèi)容、結(jié)果及確認(rèn)人員簽字/日期第74頁，共152頁，2023年，2月20日，星期日單元測試文檔測試總結(jié)報(bào)告編號(hào)如：ut-tr00016標(biāo)題如：文字排版功能.字間距.MarchCalculator單元測試總結(jié)報(bào)告版本號(hào)如：V1.5執(zhí)行狀態(tài)如：已經(jīng)提交修改記錄如：2003年7月3日；某某編制/修改；原因測試計(jì)劃編號(hào)計(jì)劃執(zhí)行情況缺陷統(tǒng)計(jì)(缺陷總數(shù)/未解決數(shù)目)及為解決缺陷列表后續(xù)處理措施是否通過單元測試第75頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)（續(xù)）模塊接口這是對(duì)模塊接口進(jìn)行的測試，檢查進(jìn)出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進(jìn)行。模塊接口測試至少需要如下的測試項(xiàng)目：（1）調(diào)用所測模塊時(shí)的輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；（2）所測模塊調(diào)用子模塊時(shí)，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；（3）是否修改了只做輸入用的形式參數(shù)；（4）調(diào)用標(biāo)準(zhǔn)函數(shù)參數(shù)在個(gè)數(shù)、屬性、順序上是否正確；（5）全局變量的定義在各模塊中是否一致。第76頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)（續(xù)）局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯(cuò)誤。對(duì)于局部數(shù)據(jù)結(jié)構(gòu)，應(yīng)該在單元測試中注意發(fā)現(xiàn)以下幾類錯(cuò)誤：（1）不正確的或不一致的類型說明。（2）錯(cuò)誤的初始化或默認(rèn)值。（3）錯(cuò)誤的變量名，如拼寫錯(cuò)誤或書寫錯(cuò)誤。（4）下溢、上溢或者地址錯(cuò)誤。第77頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)（續(xù)）路徑測試在單元測試中，最主要的測試是針對(duì)路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計(jì)算錯(cuò)誤、不正確的判定或不正常的控制流而產(chǎn)生的錯(cuò)誤。常見的錯(cuò)誤有：誤解的或不正確的算術(shù)優(yōu)先級(jí)；混合模式的運(yùn)算；錯(cuò)誤的初始化；精確度不夠精確；表達(dá)式的不正確符號(hào)表示。針對(duì)判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯(cuò)誤：不同數(shù)據(jù)類型的比較；不正確的邏輯操作或優(yōu)先級(jí)；應(yīng)當(dāng)相等的地方由于精確度的錯(cuò)誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當(dāng)遇到分支循環(huán)時(shí)不能退出；不適當(dāng)?shù)匦薷难h(huán)變量。第78頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)（續(xù)）邊界條件邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設(shè)計(jì)測試用例，認(rèn)真仔細(xì)地測試為限制數(shù)據(jù)處理而設(shè)置的邊界處，看模塊是否能夠正常工作。一些可能與邊界有關(guān)的數(shù)據(jù)類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個(gè)、最后一個(gè)、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測試中，應(yīng)設(shè)計(jì)測試用例檢查以下情況：（1）在n次循環(huán)的第0次、1次、n次是否有錯(cuò)誤。（2）運(yùn)算或判斷中取最大值、最小值時(shí)是否有錯(cuò)誤。（3）數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯(cuò)誤。第79頁，共152頁，2023年，2月20日，星期日單元測試的主要任務(wù)（續(xù)）出錯(cuò)處理測試出錯(cuò)處理的重點(diǎn)是模塊在工作中發(fā)生了錯(cuò)誤，其中的出錯(cuò)處理設(shè)施是否有效。檢驗(yàn)程序中的出錯(cuò)處理可能面對(duì)的情況有：（1）對(duì)運(yùn)行發(fā)生的錯(cuò)誤描述難以理解。（2）所報(bào)告的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不一致。（3）出錯(cuò)后，在錯(cuò)誤處理之前就引起系統(tǒng)的干預(yù)。（4）例外條件的處理不正確。（5）提供的錯(cuò)誤信息不足，以至于無法找到錯(cuò)誤的原因。第80頁，共152頁，2023年，2月20日，星期日4.4集成測試4.4.1非增量式測試4.4.2增量式測試4.4.3不同集成測試方法的比較4.4.4回歸測試第81頁，共152頁，2023年，2月20日，星期日集成測試將經(jīng)過單元測試的模塊按設(shè)計(jì)要求連接起來，組成所規(guī)定的軟件系統(tǒng)的過程稱為“集成”。集成測試是組裝軟件的系統(tǒng)測試技術(shù)之一，按設(shè)計(jì)要求把通過單元測試的各個(gè)模塊組裝在一起之后，進(jìn)行集成測試的主要任務(wù)是要求軟件系統(tǒng)符合實(shí)際軟件結(jié)構(gòu)，發(fā)現(xiàn)與接口有關(guān)的各種錯(cuò)誤。集成測試的主要任務(wù)是解決以下5個(gè)方面的測試問題。第82頁，共152頁，2023年，2月20日，星期日集成測試

①將各模塊連接起來，檢查模塊相互調(diào)用時(shí)，數(shù)據(jù)經(jīng)過接口是否丟失。②將各個(gè)子功能組合起來，檢查能否達(dá)到預(yù)期要求的各項(xiàng)功能。③一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響。④全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題，會(huì)不會(huì)被異常修改。⑤單個(gè)模塊的誤差積累起來，是否被放大，從而達(dá)到不可接受的程度。第83頁，共152頁，2023年，2月20日，星期日4.4.1非增量式測試非增量式測試是采用一步到位的方法來構(gòu)造測試：

——對(duì)所有模塊進(jìn)行個(gè)別的單元測試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個(gè)整體進(jìn)行測試。

實(shí)例采用非增量式測試方法進(jìn)行集成測試非增量式測試的缺點(diǎn)：

——當(dāng)一次集成的模塊較多時(shí)，非增量式測試容易出現(xiàn)混亂，因?yàn)闇y試時(shí)可能發(fā)現(xiàn)了許多故障，為每一個(gè)故障定位和糾正非常困難，并且在修正一個(gè)故障的同時(shí)，可能又引入了新的故障，新舊故障混雜，很難判定出錯(cuò)的具體原因和位置。第84頁，共152頁，2023年，2月20日，星期日非增量式測試（續(xù)）

AS3S4S5d2

Cd4

Ed5

Fd1

B

s1d3

s2

DABCDEFABCDEF（1）程序結(jié)構(gòu)圖（3）集成測試示意圖（2）單元測試示意圖第85頁，共152頁，2023年，2月20日，星期日4.4.2增量式測試增量式測試的集成是逐步實(shí)現(xiàn)的：

——逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實(shí)施次序，增量式集成測試又可以分為三種不同的方法：（1）自頂向下增量式測試（2）自底向上增量式測試（3）混合增量式測試第86頁，共152頁，2023年，2月20日，星期日自頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進(jìn)行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成：

——首先集成在結(jié)構(gòu)中的一個(gè)主控路徑下的所有模塊，主控路徑的選擇是任意的。

廣度優(yōu)先方式的集成：

——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。第87頁，共152頁，2023年，2月20日，星期日自頂向下增量式測試（續(xù)）集成測試的整個(gè)過程由3個(gè)步驟完成：（1）主控模塊作為測試驅(qū)動(dòng)器。（2）根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。（3）在每個(gè)模塊被集成時(shí)，都必須進(jìn)行單元測試。重復(fù)第2步，直到整個(gè)系統(tǒng)被測試完成。

實(shí)例按照廣度優(yōu)先方式進(jìn)行集成測試實(shí)例按照深度優(yōu)先方式進(jìn)行集成測試第88頁，共152頁，2023年，2月20日，星期日自頂向下增量式測試（續(xù)）

A

B

C

D

E

F

A

S1

S2

S3

A

B

C

D

S4

S5

A

B

C

D

E

F（1）（2）（3）廣度優(yōu)先方式第89頁，共152頁，2023年，2月20日，星期日自頂向下增量式測試（續(xù)）

A

B

C

D

E

F

A

S1

S2

S3

A

B

S2

S3

E

A

B

C

S3

E（1）（2）（3）深度優(yōu)先方式（4）第90頁，共152頁，2023年，2月20日，星期日自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進(jìn)行的，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是從最底層開始集成，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進(jìn)行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。實(shí)例采用自底向上增量式測試方法進(jìn)行集成測試第91頁，共152頁，2023年，2月20日，星期日自底向上增量式測試（續(xù)）

A

B

C

D

E

F

d2

Cd1

Ed3

Fd4

B

Ed5

F

D

A

B

C

D

E

F第92頁，共152頁，2023年，2月20日，星期日混合增量式測試混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結(jié)合起來進(jìn)行集成和測試。這樣可以兼具兩者的優(yōu)點(diǎn)，而摒棄其缺點(diǎn)。常見的兩種混合增量式測試方式：（1）衍變的自頂向下的增量式測試：基本思想是強(qiáng)化對(duì)輸入/輸出模塊和引入新算法模塊的測試，并自底向上集成為功能相對(duì)完整且相對(duì)獨(dú)立的子系統(tǒng)，然后由主模塊開始自頂向下進(jìn)行增量式測試。（2）自底向上-自頂向下的增量式測試：首先對(duì)含讀操作的子系統(tǒng)自底向上直至根節(jié)點(diǎn)模塊進(jìn)行集成和測試，然后對(duì)含寫操作的子系統(tǒng)做自頂向下的集成與測試。第93頁，共152頁，2023年，2月20日，星期日4.4.3不同集成測試方法的比較1、非增量式測試與增量式測試的比較非增量式測試的方法是先分散測試，然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯(cuò)誤，只會(huì)在最后的集成測試時(shí)一下子暴露出來。增量式測試是逐步集成和逐步測試的方法，把可能出現(xiàn)的差錯(cuò)分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測試中，得到了較多次的考驗(yàn)，因此，可能會(huì)取得較好的測試效果。

結(jié)論：增量式測試要比非增量式測試具有一定的優(yōu)越性。第94頁，共152頁，2023年，2月20日，星期日不同集成測試方法的比較（續(xù)）2、自頂向下與自底向上增量式測試的比較自頂向下增量式測試：

——主要優(yōu)點(diǎn)在于它可以自然的做到逐步求精，一開始就能讓測試者看到系統(tǒng)的框架。

——主要缺點(diǎn)是需要提供樁模塊，并且在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據(jù)有一定困難。自底向上增量式測試：

——優(yōu)點(diǎn)在于，由于驅(qū)動(dòng)模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構(gòu)成有向的非環(huán)狀圖，生成測試數(shù)據(jù)也無困難。

——主要缺點(diǎn)在于，直到最后一個(gè)模塊被加進(jìn)去之后才能看到整個(gè)程序（系統(tǒng)）的框架。第95頁，共152頁，2023年，2月20日，星期日4.4.4回歸測試什么是回歸測試？

——在集成測試策略的環(huán)境中，回歸測試是對(duì)某些已經(jīng)進(jìn)行過的測試的某些子集再重新進(jìn)行一遍，以保證上述改變不會(huì)傳播無法預(yù)料的副作用或引發(fā)新的問題。

——在更廣的環(huán)境里，回歸測試就是用來保證（由于測試或其他原因的）改動(dòng)不會(huì)帶來不可預(yù)料的行為或另外的錯(cuò)誤?；貧w測試可以通過重新執(zhí)行所有的測試用例的一個(gè)子集人工地進(jìn)行，也可以使用自動(dòng)化的捕獲回放工具來進(jìn)行?；貧w測試集包括三種不同類型的測試用例：（1）能夠測試軟件的所有功能的代表性測試用例（2）專門針對(duì)可能會(huì)被修改而影響軟件功能的附加測試（3）針對(duì)修改過的軟件成分的測試第96頁，共152頁，2023年，2月20日，星期日4.5確認(rèn)測試1、確認(rèn)測試的準(zhǔn)則確認(rèn)測試也稱為合格性測試，是檢驗(yàn)所開發(fā)的軟件是否能按用戶提出的要求進(jìn)行。軟件確認(rèn)要通過一系列證明軟件功能和要求一致的黑盒測試來完成。經(jīng)過確認(rèn)測試，應(yīng)該為已開發(fā)的軟件給出結(jié)論性評(píng)價(jià)：（1）經(jīng)過檢驗(yàn)的軟件的功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，則可被認(rèn)為是合格的軟件。（2）經(jīng)過檢驗(yàn)發(fā)現(xiàn)與需求說明書有相當(dāng)?shù)钠x，得到一個(gè)各項(xiàng)缺陷清單。第97頁，共152頁，2023年，2月20日，星期日確認(rèn)測試（續(xù)）2、配置審查的內(nèi)容確認(rèn)測試過程的重要環(huán)節(jié)就是配置審查工作。其目的在于確保已開發(fā)軟件的所有文件資料均已編寫齊全，并得到分類編目，足以支持運(yùn)行以后的軟件維護(hù)工作。配置審查的文件資料包括用戶所需的以下資料：（1）用戶手冊（2）操作手冊（3）設(shè)計(jì)資料

——如：設(shè)計(jì)說明書、源程序以及測試資料（測試說明書、測試報(bào)告）等第98頁，共152頁，2023年，2月20日，星期日4.6系統(tǒng)測試為什么要進(jìn)行系統(tǒng)測試？

——由于軟件只是計(jì)算機(jī)系統(tǒng)中的一個(gè)組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運(yùn)行。因此，在投入運(yùn)行前要完成系統(tǒng)測試，以保證各組成部分不僅能單獨(dú)的得到檢驗(yàn)，而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。盡管每一個(gè)檢驗(yàn)有特定的目標(biāo)，然而所有的檢測工作都要驗(yàn)證系統(tǒng)中每個(gè)部分均已得到正確的集成，并能完成指定的功能。嚴(yán)格的說，系統(tǒng)測試超出了軟件工程范圍。通常這項(xiàng)工作并不由系統(tǒng)開發(fā)人員或系統(tǒng)開發(fā)組織來承擔(dān)，而是由軟件用戶或軟件開發(fā)機(jī)構(gòu)委托獨(dú)立測試機(jī)構(gòu)來完成。

第99頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試什么是系統(tǒng)測試為了發(fā)現(xiàn)缺陷并度量產(chǎn)品質(zhì)量，按照系統(tǒng)的功能和性能需求進(jìn)行的測試一般使用黑盒測試技術(shù)一般由獨(dú)立的測試人員完成對(duì)于模塊之間交互性比較強(qiáng)的軟件，還會(huì)有單獨(dú)的集成測試，用來發(fā)現(xiàn)模塊接口之間的錯(cuò)誤第100頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試客戶和用戶Customerv.s.User都是利益相關(guān)者，但是終極關(guān)注的是客戶客戶是衣食父母，不是上帝尊重客戶的需求與客戶溝通，讓他理解你的困難和方案，給他咨詢客戶是人，人就會(huì)犯錯(cuò)誤第101頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容1、功能測試目標(biāo)：對(duì)產(chǎn)品的功能進(jìn)行測試，檢驗(yàn)是否實(shí)現(xiàn)、是否正確實(shí)現(xiàn)方法：覆蓋產(chǎn)品的功能工具：回歸測試時(shí)候可以使用工具第102頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容2、性能測試目標(biāo)：對(duì)產(chǎn)品的性能進(jìn)行測試，檢驗(yàn)是否達(dá)標(biāo)、是否能夠保持方法：覆蓋系統(tǒng)的性能需求，一般和負(fù)載測試結(jié)合使用工具：在需要大訪問量時(shí)候尤其需要使用工具第103頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容3、負(fù)載測試目標(biāo)：在人為設(shè)置的高負(fù)載(大數(shù)據(jù)量、大訪問量)的情況下，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題方法：人為生成大數(shù)據(jù)量，并利用工具模擬頻繁并發(fā)訪問工具：一般需要使用工具第104頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容4、壓力測試目標(biāo)：在人為設(shè)置的系統(tǒng)資源緊缺情況下，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題方法：人為減少可用的系統(tǒng)資源，包括：內(nèi)存、硬盤、網(wǎng)絡(luò)、CPU占用、數(shù)據(jù)庫反應(yīng)時(shí)間…工具：一般需要使用工具第105頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容5、疲勞測試目標(biāo)：在一段時(shí)間內(nèi)(經(jīng)驗(yàn)上一般是連續(xù)72小時(shí))保持系統(tǒng)功能的頻繁使用，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題方法：人為設(shè)置不同功能的連續(xù)重復(fù)操作工具：一般需要使用工具第106頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容6、易用性測試目標(biāo)：檢查系統(tǒng)界面和功能是否容易學(xué)習(xí)、使用方式是否規(guī)范一致，是否會(huì)誤導(dǎo)用戶或者使用模糊的信息一般與功能測試結(jié)合使用方法：可以采用用戶操作、觀察(錄像)、反饋并評(píng)估的方式第107頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容7、安裝測試目標(biāo)：檢查系統(tǒng)安裝是否能夠安裝所有需要的文件/數(shù)據(jù)并進(jìn)行必要的系統(tǒng)設(shè)置；檢查系統(tǒng)安裝是否會(huì)破壞其他文件或配置；檢查系統(tǒng)安裝是否可以中止并恢復(fù)現(xiàn)場；檢查系統(tǒng)是否能夠正確卸載并恢復(fù)現(xiàn)場；檢查安裝和卸載過程的用戶提示和功能是否出現(xiàn)錯(cuò)誤有時(shí)候?qū)惭b測試作為功能測試的一部分第108頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容8、配置測試目標(biāo)：在不同的硬件配置下，在不同的操作系統(tǒng)和應(yīng)用軟件環(huán)境中，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題方法：一般需要建立測試實(shí)驗(yàn)室，IE4.0測試實(shí)驗(yàn)室建立花費(fèi)了$200萬第109頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容9、文檔測試目標(biāo)：檢查系統(tǒng)的文檔是否齊全，檢查是否有多余文檔或者死文檔，檢查文檔內(nèi)容是否正確/規(guī)范/一致，檢查CI是否正確…方法：一般由單獨(dú)的一組測試人員實(shí)施第110頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容10、安全測試(包括病毒、加密、權(quán)限)目標(biāo)檢查系統(tǒng)是否有病毒檢查系統(tǒng)是否正確加密檢查系統(tǒng)在非授權(quán)的內(nèi)部或外部用戶訪問或故意破壞時(shí)候是否出現(xiàn)錯(cuò)誤第111頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容11、恢復(fù)測試目標(biāo)：在人為使發(fā)生系統(tǒng)災(zāi)難(系統(tǒng)崩潰、硬件損壞、病毒入侵等)的情況下，檢查系統(tǒng)是否能夠恢復(fù)被破壞的環(huán)境和數(shù)據(jù)第112頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容12、回歸測試目標(biāo)：檢查系統(tǒng)變更之后是否引入新的錯(cuò)誤或者舊的錯(cuò)誤重新出現(xiàn)，尤其是在每次Biuld之后和穩(wěn)定期測試的時(shí)候工具：一般使用工具，一般依賴于測試用例庫和缺陷報(bào)告庫第113頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容13、健全測試目標(biāo)：檢查系統(tǒng)的功能和性能是否基本可以正常使用，來確定是否可以繼續(xù)進(jìn)行系統(tǒng)測試的其他內(nèi)容方法：正常安裝，并使用正常情況下的測試用例對(duì)主要功能進(jìn)行測試；同時(shí)檢查系統(tǒng)文檔是否齊全第114頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容14、交付測試目標(biāo)：關(guān)閉所有缺陷報(bào)告，確保系統(tǒng)達(dá)到預(yù)期的交付標(biāo)準(zhǔn)方法：一般需要結(jié)合回歸測試，并謹(jǐn)慎處理新出現(xiàn)的Bug交付測試也稱為穩(wěn)定期測試，有時(shí)候與系統(tǒng)測試獨(dú)立劃分第115頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容15、演練測試目標(biāo)：在交付給用戶之前，利用相似的用戶環(huán)境進(jìn)行測試?yán)纾簥W運(yùn)會(huì)MIS系統(tǒng)在2008年前用于其他比賽第116頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容16、背靠背測試目標(biāo)：設(shè)置一組以上的測試團(tuán)隊(duì)，在互相不進(jìn)行溝通的情況下獨(dú)立進(jìn)行相同的測試項(xiàng)目，用來評(píng)估測試團(tuán)隊(duì)的效果并發(fā)現(xiàn)更多的錯(cuò)誤開始用于測試外包，現(xiàn)在也用于內(nèi)部測試第117頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容17、度量測試目標(biāo)：在系統(tǒng)中人為地放入錯(cuò)誤(播種)，并根據(jù)被發(fā)現(xiàn)的比例來確定系統(tǒng)中遺留的錯(cuò)誤數(shù)量開始用于測試外包，現(xiàn)在也用于內(nèi)部測試第118頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容18、比較測試目標(biāo)：與競爭產(chǎn)品及本產(chǎn)品的舊版本測試同樣的內(nèi)容，來確定系統(tǒng)的優(yōu)勢和劣勢嚴(yán)格地說，比較測試屬于系統(tǒng)測評(píng)的內(nèi)容BenchMarking是一種特殊的比較測試第119頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的常見內(nèi)容實(shí)際上，以上18種測試內(nèi)容并不是都要進(jìn)行的，而是在制定測試策略和測試計(jì)劃的時(shí)候有不同的側(cè)重點(diǎn)，這與測試目標(biāo)、測試資源、軟件系統(tǒng)特點(diǎn)和業(yè)務(wù)環(huán)境有關(guān)。第120頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試員和用戶相似的地方都是使用軟件，一般不接觸軟件的代碼都是假設(shè)軟件應(yīng)該正確實(shí)現(xiàn)說明書的功能系統(tǒng)測試員和用戶不同的地方使用軟件的目的測試員是發(fā)現(xiàn)錯(cuò)誤，他的每一個(gè)操作都是為這個(gè)目的服務(wù)的用戶是獲得功能，他的每一個(gè)操作都是為這個(gè)目的服務(wù)的對(duì)待錯(cuò)誤測試員希望看到錯(cuò)誤，他的每一個(gè)操作都是為了使軟件出錯(cuò)用戶不希望看到錯(cuò)誤，他的每一個(gè)操作都會(huì)盡量避免使軟件出錯(cuò)第121頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試測試員的效率平均每個(gè)工作日發(fā)現(xiàn)3-5個(gè)Bug平均每修正3個(gè)Bug，會(huì)引進(jìn)1個(gè)新的Bug平均75%的Bug會(huì)在單元測試階段解決掉平均20%的Bug會(huì)在集成測試和系統(tǒng)測試階段解決掉平均5%的Bug會(huì)被交付給用戶普通大型民用軟件平均錯(cuò)誤率5個(gè)/10,000LOC電信/銀行/操作系統(tǒng)等軟件平均錯(cuò)誤率5個(gè)/100,000LOC第122頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試測試團(tuán)隊(duì)測試團(tuán)隊(duì)一般4-5人，否則應(yīng)該細(xì)分為測試組測試經(jīng)理/測試組長制定測試計(jì)劃和測試方案分配測試任務(wù)并檢查測試進(jìn)度代表測試團(tuán)隊(duì)與開發(fā)、產(chǎn)品、用戶溝通實(shí)際測試測試員設(shè)計(jì)測試用例執(zhí)行測試用例并填寫缺陷報(bào)告檢查缺陷處理結(jié)果第123頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試測試與開發(fā)的關(guān)系獨(dú)立MSF對(duì)立破與立統(tǒng)一在目標(biāo)上：ShippingonDate/Quality/Scope/Cost第124頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試測試與開發(fā)的比例與產(chǎn)品大小、復(fù)雜度、質(zhì)量要求相關(guān)目前國內(nèi)比例平均為1:62000年M$全球52000人，利潤$300億，10000開發(fā)人員，15000測試人員，測試費(fèi)用占研發(fā)費(fèi)用的60%Exchange2000程序經(jīng)理25人；開發(fā)人員140人；測試人員350人Windows2000：$50億程序經(jīng)理250人；開發(fā)人員1700人；測試人員3200人IE4.0開發(fā)時(shí)間6個(gè)月，測試時(shí)間8個(gè)月第125頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試的客觀要求系統(tǒng)測試需要以智力為核心、以系統(tǒng)為框架來實(shí)施智力：靈活性和技巧性系統(tǒng)：計(jì)劃性和流程性第126頁，共152頁，2023年，2月20日，星期日認(rèn)識(shí)系統(tǒng)測試系統(tǒng)測試中最關(guān)鍵的兩個(gè)要素測試設(shè)計(jì)測試設(shè)計(jì)的主要任務(wù)是設(shè)計(jì)測試用例測試用例庫是一種經(jīng)驗(yàn)的積累，是測試活動(dòng)最寶貴的財(cái)富測試用例的衡量標(biāo)準(zhǔn)：多、快、好、省軟件攻擊是在系統(tǒng)測試中常用的一種設(shè)計(jì)測試用例的思路測試流程系統(tǒng)測試的控制過程系統(tǒng)測試的度量過程第127頁，共152頁，2023年，2月20日，星期日恢復(fù)測試恢復(fù)測試是通過各種手段，強(qiáng)制性地使軟件出錯(cuò)，使其不能正常工作，進(jìn)而檢驗(yàn)系統(tǒng)的恢復(fù)能力?；謴?fù)測試包含的內(nèi)容：

——如果系統(tǒng)恢復(fù)是自動(dòng)的（由系統(tǒng)自身完成），則應(yīng)該檢驗(yàn)：重新初始化、檢驗(yàn)點(diǎn)設(shè)置機(jī)構(gòu)、數(shù)據(jù)恢復(fù)以及重新啟動(dòng)是否正確。

——如果這一恢復(fù)需要人為干預(yù)，則應(yīng)考慮平均修復(fù)時(shí)間是否在限定的、可以接受的范圍之內(nèi)。第128頁，共152頁，2023年，2月20日，星期日安全測試安全測試的目的在于驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)制能否在實(shí)際中保護(hù)系統(tǒng)且不受非法入侵，不受各種非法干擾。在安全測試中，測試者扮演著試圖攻擊系統(tǒng)的個(gè)人角色：

—嘗試去通過外部的手段來獲取系統(tǒng)的密碼

—使用可以瓦解任何防守的客戶軟件來攻擊系統(tǒng)

—把系統(tǒng)“癱瘓”，使得其他用戶無法訪問

—有目的地引發(fā)系統(tǒng)錯(cuò)誤，期望在恢復(fù)過程中侵入系統(tǒng)

—通過瀏覽非保密的數(shù)據(jù)，從中找到進(jìn)入系統(tǒng)的鑰匙系統(tǒng)的安全測試要設(shè)置一些測試用例試圖突破系統(tǒng)的安全保密措施，檢驗(yàn)系統(tǒng)是否有安全保密的漏洞。第129頁，共152頁，2023年，2月20日，星期日強(qiáng)度測試從本質(zhì)上來說，強(qiáng)度測試（也稱壓力測試-StreeTesting）的目的是要檢測非正常的情形，測試是想要破壞程序。強(qiáng)度測試需要在反常規(guī)數(shù)據(jù)量、頻率或資源的方式下運(yùn)行系統(tǒng)，以檢驗(yàn)系統(tǒng)能力的最高實(shí)際限度。舉例：

—如果正常的中斷頻率為每秒5次，強(qiáng)度測試設(shè)計(jì)為每秒50次中斷。

—把輸入數(shù)據(jù)的量提高一個(gè)數(shù)量級(jí)來測試輸入功能會(huì)如何響應(yīng)。

—若某系統(tǒng)正常運(yùn)行可支持200個(gè)終端并行工作，強(qiáng)度測試則檢驗(yàn)1000個(gè)終端并行工作的情況。

—運(yùn)行大量的消耗內(nèi)存或其他系統(tǒng)資源的測試實(shí)例。第130頁，共152頁，2023年，2月20日，星期日性能測試性能測試用來測試軟件在系統(tǒng)集成中的運(yùn)行性能，特別是針對(duì)實(shí)時(shí)系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測試可以在測試過程的任意階段進(jìn)行，但只有當(dāng)整個(gè)系統(tǒng)的所有成分都集成在一起后，才能檢查一個(gè)系統(tǒng)的真正性能。性能測試常常和強(qiáng)度（壓力）測試結(jié)合起來進(jìn)行，而且常常需要硬件和軟件測試設(shè)備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。第131頁，共152頁，2023年，2月20日，星期日正確性測試正確性測試檢查軟件的功能是否符合規(guī)格說明。正確性測試的方法：

——枚舉法，即構(gòu)造一些合理輸入，檢查是否得到期望的輸出。測試時(shí)應(yīng)盡量設(shè)法減少枚舉的次數(shù)，關(guān)鍵在于尋找等價(jià)區(qū)間，因?yàn)樵诘葍r(jià)區(qū)間中，只需用任意值測試一次即可。——邊界值測試，即采用定義域或者等價(jià)區(qū)間的邊界值進(jìn)行測試。因?yàn)槌绦蛟O(shè)計(jì)容易疏忽邊界情況，程序也容易在邊界值處出錯(cuò)。

第132頁，共152頁，2023年，2月20日，星期日可靠性測試可靠性測試是從驗(yàn)證的角度出發(fā)，檢驗(yàn)系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時(shí)給出當(dāng)前系統(tǒng)可能的可靠性增長情況。對(duì)可靠性性測試來說，最關(guān)鍵的測試數(shù)據(jù)包括失效間隔時(shí)間，失效修復(fù)時(shí)間，失效數(shù)量，失效級(jí)別等。根據(jù)獲得的測試數(shù)據(jù)，應(yīng)用可靠性模型，可以得到系統(tǒng)的失效率及可靠性增長趨勢?？煽啃灾笜?biāo)有時(shí)很難測試，通常采用平均無故障時(shí)間或系統(tǒng)投入運(yùn)行后出現(xiàn)的故障不能大于多少數(shù)量這些指標(biāo)來對(duì)可靠性進(jìn)行評(píng)估。第133頁，共152頁，2023年，2月20日，星期日兼容性測試軟件兼容性測試是檢測各軟件之間能否正確地交互和共享信息，其目標(biāo)是保證軟件按照用戶期望的方式進(jìn)行交互，使用其它軟件檢查軟件操作的過程。兼容性的測試通常需要解決以下問題：（1）新開發(fā)的軟件需要與哪種操作系統(tǒng)、Web瀏覽器和應(yīng)用軟件保持兼容，如果要測試的軟件是一個(gè)平臺(tái)，那么要求應(yīng)用程序能在其上運(yùn)行。（2）應(yīng)該遵守哪種定義軟件之間交互的標(biāo)準(zhǔn)或者規(guī)范。（3）軟件使用何種數(shù)據(jù)與其它平臺(tái)、與新的軟件進(jìn)行交互和共享信息。第134頁，共152頁，2023年，2月20日，星