軟件測試工程師培訓(xùn)---測試技術(shù)基礎(chǔ)課件

1、軟件測試工程師培訓(xùn)測試技術(shù)基礎(chǔ)培訓(xùn)內(nèi)容 第一章測試技術(shù)的發(fā)展歷程 第二章測試基本概念 第三章基本測試技術(shù) 第四章測試中的若干問題第一章測試技術(shù)的發(fā)展歷程60年代（軟件工程建立前），為表明程序正確而進(jìn)行測試。1972年，Bill Hetzel在North Carolina大學(xué)舉行第一次以軟件測試為主題的正式會議。1979年，Glenford MyersThe Art of Software Testing提出測試的目的是證偽。第一章測試技術(shù)的發(fā)展歷程1981年，Bill Hetzel開設(shè)“Structured Software Testing”公共課1988年David Gelperin & B

2、ill Hetzel 在“Communications of the ACM”發(fā)表“The Growth of Software Testing”。70年代后期至80年代中期的QA部門。第一章測試技術(shù)的發(fā)展歷程1996年提出的測試能力成熟度TCMM（Testing Capability Maturity Model）、測試支持度TSM（Testability Support Model）、測試成熟度TMM（Testing Maturity Model）。第二章測試基本概念2.1 軟件測試的定義2.2 軟件開發(fā)與軟件測試2.3 廣義的軟件測試2.4 測試方法2.5 測試策略2.6 驗(yàn)收測試2.7

3、 第三方測試2.1 軟件測試的定義軟件生存周期：需求定義和需求分析、軟件設(shè)計、程序編碼、軟件測試、運(yùn)行維護(hù)。2.1 軟件測試的定義軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。測試：為了發(fā)現(xiàn)軟件中的錯誤而運(yùn)行軟件的過程。2.1 軟件測試的定義軟件生存期的各個階段都可能產(chǎn)生錯誤。而軟件需求分析、設(shè)計和實(shí)現(xiàn)階段是軟件的主要錯誤來源。軟件測試在軟件生存期中，跨越兩個階段：一個是編碼與單元測試階段，另一個是綜合測試階段，即測試階段。2.1 軟件測試的定義軟件測試的對象軟件測試不等于程序測試。需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細(xì)設(shè)計規(guī)格說明、源程序

4、都是軟件測試的對象。軟件測試貫串于軟件定義和開發(fā)的整個期間。2.1 軟件測試的定義軟件測試的分類 按測試用例設(shè)計方法：白盒測試黑盒測試。 按測試策略和過程：單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試。2.1 軟件測試的定義軟件測試的目的 測試的目的是尋找錯誤，并且是盡最大可能找出最多的錯誤。 觀點(diǎn)1：好的測試方案是極可能發(fā)現(xiàn)迄今為止尚 未發(fā)現(xiàn)的錯誤的測試方案。 觀點(diǎn)2：成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn) 的錯誤的測試。 測試無法說明錯誤不存在，只能說明軟件錯誤已出現(xiàn)。2.1 軟件測試的定義2.1 軟件測試的定義軟件測試的原則 盡早地和不斷地進(jìn)行軟件測試 避免測試自己的程序 執(zhí)行測試計劃，排除隨意性

5、 增量測試，由小到大 周密的測試用例（輸入條件（合理、不合理）、預(yù)期輸出結(jié)果） 回歸測試 出錯統(tǒng)計和分析2.2 軟件開發(fā)與軟件測試軟件開發(fā)過程各環(huán)節(jié)的關(guān)系2.2 軟件開發(fā)與軟件測試測試的活動應(yīng)該與軟件開發(fā)同步進(jìn)行。 測試的執(zhí)行是在軟件已編制完成后進(jìn)行。及早發(fā)現(xiàn)軟件的缺陷可以降低軟件開發(fā)的成本。2.2 軟件開發(fā)與軟件測試V模型2.2 軟件開發(fā)與軟件測試V模型V模型：需求、功能、設(shè)計和編碼的開發(fā)活 動隨時間而進(jìn)行，而相應(yīng)的測試活動（即針對需求、功能、設(shè)計和編碼的測試）開展的次序正好相反。成功應(yīng)用軟件開發(fā)V模型的關(guān)鍵因素是設(shè)計 測試案例的時機(jī)。2.2 軟件開發(fā)與軟件測試V模型V模型的問題： 誤解：“

6、測試是開發(fā)之后的一個階段”、“測試的對象就是程序本身”。 實(shí)際應(yīng)用中容易導(dǎo)致需求階段的錯誤一直到最后驗(yàn)收階段才被發(fā)現(xiàn)。2.2 軟件開發(fā)與軟件測試W模型2.2 軟件開發(fā)與軟件測試W模型W模型： 測試伴隨整個開發(fā)周期。 測試的對象不僅僅是程序，還包括需求和設(shè)計。W模型應(yīng)用： 相應(yīng)開發(fā)活動完成，即可執(zhí)行測試（例如：需求分析完成，即可對需求進(jìn)行測試）。2.2 軟件開發(fā)與軟件測試W模型W模型未解決V模型中的部分問題： 需求、設(shè)計、編碼串行進(jìn)行，無法并行工作。 未將測試流程的完整性表示出來。2.2 軟件開發(fā)與軟件測試H模型測試流程： 測試準(zhǔn)備活動：測試計劃、測試設(shè)計、測試開發(fā)。 測試執(zhí)行活動：測試運(yùn)行、測

7、試評估。2.2 軟件開發(fā)與軟件測試H模型H模型： 測試不僅僅是測試執(zhí)行，還包括其他活動。 測試是一個獨(dú)立流程，貫穿產(chǎn)品整個周期，于其他流程并發(fā)進(jìn)行。 測試要盡早準(zhǔn)備，盡早執(zhí)行。2.2 軟件開發(fā)與軟件測試H模型應(yīng)用H模型的意義： 測試準(zhǔn)備和測試執(zhí)行分離，有利于資源調(diào)配。降低成本，提高效率。 充分體現(xiàn)測試過程（不是技術(shù)）的復(fù)雜性。 有組織、結(jié)構(gòu)化的獨(dú)立流程，有助于跟蹤測試投入的流向。2.2 軟件開發(fā)與軟件測試軟件測試與開發(fā)的并行性需求分析需求評審概要設(shè)計詳細(xì)設(shè)計概要設(shè)計評審單元測試編碼設(shè)計走查編碼走查各子模塊有效性測試集成測試測試計劃測試過程測試評審* 項目階段任務(wù)的里程碑*2.2 軟件開發(fā)與軟件

8、測試開發(fā)各階段的測試工作項目規(guī)劃階段： 確定專人負(fù)責(zé)測試階段監(jiān)控。需求分析階段： 制定測試需求分析、確認(rèn)/系統(tǒng)測試計劃，經(jīng)評審后成為配置管理項。 測試所需要的資源、配置、每階段評判通過標(biāo)志進(jìn)行規(guī)約。2.2 軟件開發(fā)與軟件測試開發(fā)各階段的測試工作詳細(xì)設(shè)計和概要設(shè)計階段： 確保集成測試計劃和單元測試計劃完成。 測試計劃完成后，對參考的設(shè)計文檔進(jìn)行修改。編碼階段： 編寫測試代碼。（測試人員、專人）測試階段： 測試人員執(zhí)行測試。 完成測試報告。2.2 軟件開發(fā)與軟件測試開發(fā)各階段的測試工作2.3 廣義的軟件測試廣義的軟件測試是由確認(rèn)、驗(yàn)證、測試3個方面組成。 確認(rèn)（validation）：評估將要開發(fā)

9、的軟件產(chǎn)品是否正確 無誤、可行和有價值的。確認(rèn)意味著確保一個待開發(fā)軟件是正確無誤的，是對軟件開發(fā)構(gòu)想的檢測。 驗(yàn)證（verification）：檢測軟件開發(fā)的每個階段、每個步驟的結(jié)果是否正確無誤，是否與軟件開發(fā)各階段的要求 或期望的結(jié)果相一致。驗(yàn)證意味著確保軟件會正確無誤地實(shí)現(xiàn)軟件的需求，開發(fā)過程是沿著正確的方向進(jìn)行的。 測試：與狹隘的測試概念統(tǒng)一。2.3 廣義的軟件測試確認(rèn)：目的是想證實(shí)在一個給定的外部環(huán)境中軟件的邏輯正確性。包括需求規(guī)格說明的確認(rèn)和程序的確認(rèn)。程序確認(rèn)包括靜態(tài)確認(rèn)與動態(tài)確認(rèn)。驗(yàn)證：試圖證明在軟件生存期各個階段，以及階段間的邏輯協(xié)調(diào)性、完備性和正確性。2.3 廣義的軟件測試確

10、認(rèn)：保證所生產(chǎn)的軟件可追溯到用戶需求的一系列活動。（生產(chǎn)的軟件是否正確）驗(yàn)證：保證軟件正確地實(shí)現(xiàn)了特定功能的一系列活動。（生產(chǎn)軟件的步驟是否正確）2.3 廣義的軟件測試確認(rèn)主要體現(xiàn)在計劃階段、需求分析階段，也會出現(xiàn)在測試階段；驗(yàn)證主要體現(xiàn)在設(shè)計階段、編碼階段；測試主要體現(xiàn)在編碼階段和測試階段。確認(rèn)、驗(yàn)證、測試是相輔相成的。確認(rèn)產(chǎn)生驗(yàn)證和測試的標(biāo)準(zhǔn)，驗(yàn)證和測試幫助完成確認(rèn)（特別在系統(tǒng)測試階段）。2.4 測試方法黑盒測試白盒測試兩種測試方法從不同的角度出發(fā)，反映了軟件的不同側(cè)面，也適用于不同的開發(fā)環(huán)境2.4 測試方法任何工程產(chǎn)品都可以使用以下的兩種方法進(jìn)行測試： 已知產(chǎn)品的功能設(shè)計規(guī)格，可以進(jìn)行測

11、試證明每個實(shí)現(xiàn)了的功能是否符合要求。（黑盒測試）。 已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格的要求，所有內(nèi)部成分是否已經(jīng)過檢查。（白盒測試）。2.4 測試方法黑盒測試黑盒測試法把程序看成一個黑盒子，完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序接口進(jìn)行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。黑盒測試又稱功能測試。2.4 測試方法黑盒測試2.4 測試方法黑盒測試典型黑盒測試方法 等價類劃分 因果圖 邊界值分析2.4 測試方法黑盒測試黑盒主要是為了發(fā)現(xiàn)以下幾類錯誤： 是否有不正確或遺漏了的功能？ 在接口上，輸入能否正確地接受？能否輸出正確的結(jié)果？

12、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？ 性能上是否能夠滿足要求？ 是否有初始化或終止性錯誤？2.4 測試方法黑盒測試輸入輸出黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試，也可被成為用戶測試，主要應(yīng)用于快速應(yīng)用開發(fā)（RAD）環(huán)境2.4 測試方法白盒測試白盒測試的前提是可以把程序看成裝在一個透明的白盒子里，也就是完全了解程序結(jié)構(gòu)盒處理過程，這種方法按照程序內(nèi)部邏輯測試程序，檢驗(yàn)程序中每條通路是否按預(yù)定要求正確工作。白盒測試又稱結(jié)構(gòu)測試。2.4 測試方法白盒測試2.4 測試方法白盒測試典型白盒測試方法 靜態(tài)分析(靜態(tài)測試) 動態(tài)測試2.4 測試方法靜態(tài)測試靜態(tài)測試是指不利用

13、計算機(jī)運(yùn)行被測程序，而是通過其他手段達(dá)到檢測的目的。包括需求評審、設(shè)計評審、人工走查、代碼審查等。靜態(tài)測試并不等同于人工測試，它也可以利用計算機(jī)作為對被測程序進(jìn)行特性分析的工具，而只是不真正運(yùn)行被測程序。靜態(tài)方法也常常被稱為“分析”，靜態(tài)測試是對被測程序進(jìn)行特性分析的方法的總稱。2.4 測試方法代碼審查(Code Inspections)代碼審查會的過程如下：（1）會前準(zhǔn)備：如組織者在會議開始之前把這個程序清單和設(shè)計規(guī)范分發(fā)給小組的其他成員，以便在會議之前熟悉這些材料。（2）會議期間： a. 請程序員逐句地講述程序的邏輯結(jié)構(gòu)。 b. 根據(jù)常見程序錯誤檢驗(yàn)單分析程序。（3）會后檢查：把已查出錯誤

14、清單交程序員，并對修改結(jié)果進(jìn)行跟蹤。代碼審查關(guān)注下列類型問題：（1）數(shù)據(jù)引用錯誤（2）數(shù)據(jù)說明（3）計算（4）比較（5）控制流（6）接口（7）輸入/輸出（8）其它檢查2.4 測試方法人工走查(Walkthroughs)人工走查與代碼審查一樣，首先通過資料，研究程序。但不同的是：在人工走查會上是通過測試數(shù)據(jù)與人工運(yùn)行程序來達(dá)到測試目的。 對照實(shí)驗(yàn)發(fā)現(xiàn)，人工走查和審查會平均能查出被測程序38%的錯誤。據(jù)資料，IBM代碼審查會的查錯效率高達(dá)80%。2.4 測試方法靜態(tài)測試階段的任務(wù)：（1）檢查算法的邏輯正確性。（2）檢查模塊接口的正確性。（3）檢查輸入?yún)?shù)是否有合法性檢查。（4）檢查調(diào)用其他模塊的接

15、口是否正確。（5）檢查是否設(shè)置了適當(dāng)?shù)某鲥e處理。（6）檢查表達(dá)式、語句是否正確，是否含有二義性。（7）檢查常量或全局變量使用是否正確。（8）檢查標(biāo)識符的使用是否規(guī)范、一致。（9）檢查程序風(fēng)格的一致性、規(guī)范性。（10）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。2.4 測試方法靜態(tài)測試可以完成以下工作：（1）發(fā)現(xiàn)下列程序的錯誤：錯用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當(dāng)?shù)难h(huán)嵌套或分支嵌套、死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標(biāo)號或代碼。（2）找出以下問題的根源：從未使用過的變量；不會執(zhí)行到的代碼、從未使用過的標(biāo)號；潛

16、在的死循環(huán)。（3）提供程序缺陷的間接信息：所用變量和常量的交叉應(yīng)用表；是否違背編碼規(guī)則；標(biāo)識符的使用方法和過程的調(diào)用層次。（4）為進(jìn)一步查找做好準(zhǔn)備。（5）選擇測試用例。（6）進(jìn)行符號測試。2.4 測試方法2、動態(tài)測試動態(tài)方法的主要特征是計算機(jī)必須真正運(yùn)行被測試的程序，通過輸入測試用例對其運(yùn)行情況（即輸入與輸出的對應(yīng)關(guān)系）進(jìn)行分析，達(dá)到檢測的目的。動態(tài)測試包括：單元測試、集成測試、系統(tǒng)測試、用戶的驗(yàn)收測試和回歸測試。2.4 測試方法使用靜態(tài)和動態(tài)測試進(jìn)行結(jié)構(gòu)和功能測試：測試階段執(zhí)行人靜態(tài)校驗(yàn)動態(tài)校驗(yàn)可行性評審開發(fā)人員，用戶需求評審開發(fā)人員，用戶設(shè)計評審開發(fā)人員單元測試開發(fā)人員集成測試開發(fā)人員，

17、測試人員系統(tǒng)測試開發(fā)人員在測試人員的協(xié)助下完成驗(yàn)收測試用戶2.4 測試方法白盒測試使用白盒測試方法，主要想對程序模塊進(jìn)行如下的檢查： 對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一 次。 對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測試一次。 在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體。 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等。2.4 測試方法白盒測試白盒測試又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試，也可成為程序員測試，主要應(yīng)用于結(jié)構(gòu)化開發(fā)環(huán)境應(yīng)用程序2.4 測試方法黑盒測試法和白盒測試法的比較黑盒測試是以用戶的觀點(diǎn)，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系，也就是根據(jù)程序外部特性進(jìn)行的測試。若外部特性本身存在問

18、題或規(guī)格說明書有誤，則應(yīng)用黑盒測試方法是不能發(fā)現(xiàn)問題的。白盒測試是根據(jù)程序的內(nèi)部結(jié)構(gòu)進(jìn)行測試。測試用例的設(shè)計要保證測試時程序的所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。如果程序的結(jié)構(gòu)本身有問題，比如說程序邏輯有錯誤或者有遺漏，那也是無法發(fā)現(xiàn)的。黑盒測試和白盒測試各有自己的優(yōu)缺點(diǎn)，可以構(gòu)成互補(bǔ)的關(guān)系。在規(guī)劃測試方案時，需要把黑盒測試與白盒測試結(jié)合起來。2.4 測試方法項目黑盒法白盒法規(guī)劃方面功能的測試結(jié)構(gòu)的測試優(yōu)點(diǎn)方面能確保從用戶的角度出發(fā)進(jìn)行測試能對程序內(nèi)部的特定部位進(jìn)行覆蓋測試缺點(diǎn)方面無法測試程序內(nèi)部特定部位；當(dāng)規(guī)格說明有誤，則不能發(fā)現(xiàn)問題 無法檢查程序的外部特性；無法對未實(shí)現(xiàn)規(guī)格說明

19、的程序內(nèi)部欠缺部分進(jìn)行測試應(yīng)用范圍邊界分析法等價類劃分法決策表測試語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，路徑覆蓋，循環(huán)覆蓋，模塊接口測試2.5 測試策略2.5 測試策略測試的數(shù)據(jù)流2.5 測試策略單元測試單元測試又稱為模塊測試，是針對程序模塊（軟件設(shè)計的最小單位）來進(jìn)行正確性檢驗(yàn)的測試工作。軟件單元測試的目的是檢測程序模塊對詳細(xì)設(shè)計說明書的符合程度；軟件單元測試依據(jù)是單元測試計劃。2.5 測試策略單元測試軟件單元測試由測試工程師編制測試用例進(jìn)行測試，及針對程序模塊進(jìn)行多次循環(huán)反復(fù)的單元測試，并將測試結(jié)果記錄在針對單元測試的軟件測試報告上。若程序模塊通過單元測試，則按配置管理規(guī)范所規(guī)定的

20、標(biāo)識方法進(jìn)行標(biāo)識。2.5 測試策略單元測試模塊接口測試局部數(shù)據(jù)結(jié)構(gòu)測試路徑測試錯誤處理測試邊界測試 2.5 測試策略單元測試的步驟通常單元測試是在編碼階段進(jìn)行的。在源程序代碼編制完成。經(jīng)過評審和驗(yàn)證，確認(rèn)沒有語法錯誤之后，就開始進(jìn)行單元測試的測試用例設(shè)計。 驅(qū)動模塊：相當(dāng)于所測模塊的主程序。 樁模塊：也叫做存根模塊。用以代替所測模塊調(diào)用的子模塊。2.5 測試策略單元測試的環(huán)境2.5 測試策略單元測試完成單元測試單元測試單元測試單元測試單元測試2.5 測試策略集成測試為什么要進(jìn)行集成測試？實(shí)踐表明，軟件的一些模塊能夠單獨(dú)地工作，但并不能保證組裝連接之后也肯定能正常工作。程序在某些局部反映不出來的

21、問題，在全局情況下有可能暴露出來，影響軟件功能的實(shí)現(xiàn)?？赡艿脑蛴幸韵聨追矫妫海?）模塊相互調(diào)用時引入了新的問題，例如數(shù)據(jù)可能沒有正確傳遞，一模塊對另一模塊產(chǎn)生了不利的影響等。（2）幾個子功能組合后不能實(shí)現(xiàn)預(yù)期的主功能。（3）單個模塊的誤差累計達(dá)到了不可接受的程度。（4）全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)問題。2.5 測試策略集成測試集成測試(Integrated Testing)階段是指每個模塊完成單元測試后，需要按照設(shè)計時確定的程序結(jié)構(gòu)圖，把它們連接起來進(jìn)行集成測試。集成測試也稱為綜合測試、組裝測試、聯(lián)合測試。集成測試的對象： 經(jīng)過單元測試的程序模塊間調(diào)用關(guān)系和接口數(shù)據(jù)。集成測試的目的：找出與軟件設(shè)計相關(guān)的

22、程序結(jié)構(gòu)，模塊調(diào)用關(guān)系，模塊間接口方面的問題。集成測試的測試依據(jù)：程序結(jié)構(gòu)設(shè)計文檔（包括概要設(shè)計說明書、詳細(xì)設(shè)計說明書等）。集成測試的基本方案：非增量式測試、增量式測試。2.5 測試策略集成中的組裝方法非增量式測試是采用一步到位的方法來構(gòu)造測試： 對所有模塊進(jìn)行個別的單元測試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個整體進(jìn)行測試。非增量式測試的缺點(diǎn)： 當(dāng)一次集成的模塊較多時，這種測試容易出現(xiàn)混亂，因?yàn)闇y試時可能發(fā)現(xiàn)了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。 2.5 測試策略集成中的組裝

23、方法 AS3S4S5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF（1）程序結(jié)構(gòu)圖（3）集成測試示意圖（2）單元測試示意圖2.5 測試策略集成中的組裝方法增量式測試的集成是逐步實(shí)現(xiàn)的：逐次將未曾集成測試的模塊和已集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實(shí)施次序，增量式集成測試又可以分為三種不同的方法：自頂向下增量式測試自底向上增量式測試混合增量式測試2.5 測試策略集成中的組裝方法自頂向下增量式測試這種集成方式是將模塊按系統(tǒng)的程序結(jié)構(gòu)自頂向下進(jìn)行集成，即模塊集成的順序是首

24、先集成主控模塊（主程序），然后沿控制層次向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成：首先集成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。 廣度優(yōu)先方式的集成：首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集中起來，直到最底層。2.5 測試策略集成中的組裝方法自頂向下增量式測試的步驟：（1）以主控模塊為所測模塊兼驅(qū)動模塊，所有直屬于主控模塊的下屬模塊全部用樁模塊代替。（2）采用深度優(yōu)先或廣度優(yōu)先的策略，用實(shí)際模塊替換相應(yīng)樁模塊，再用樁模塊代替實(shí)際模塊的直接下屬模塊，與已測試的模塊或子系統(tǒng)集成為新的子系統(tǒng)。

25、下層的樁模塊一次一次地被替換為真正的模塊。（3）進(jìn)行回歸測試（即重新執(zhí)行以前做過的全部測試或部分測試），排除集成過程中引起錯誤的可能。（4）判斷是否所有的模塊都已集成到系統(tǒng)中，是則結(jié)束測試，否則轉(zhuǎn)到（2）去執(zhí)行。2.5 測試策略集成中的組裝方法 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)先方式2.5 測試策略集成中的組裝方法 A B C S3 E A B C D E F A S1 S2 S3 A B S2 S3 E（1）（2）（3）深度優(yōu)先方式（4）2.5 測試策略集成中的組裝方法自底向上增量式測試這種集成方式是將模

26、塊按系統(tǒng)的程序結(jié)構(gòu)自底向上進(jìn)行集成，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是自底向上進(jìn)行集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。2.5 測試策略集成中的組裝方法自底向上增量式測試的步驟：（1）由驅(qū)動模塊控制最底層模塊的并行測試。（2）用實(shí)際模塊代替驅(qū)動模塊，與它已測試的直屬子模塊集成為子系統(tǒng)。（3）為子系統(tǒng)配備驅(qū)動模塊，進(jìn)行新的測試。（4）判斷是否已集成到達(dá)主控模塊，是則結(jié)束測試，否則執(zhí)行（2）。2.5 測試策略集成中的組裝方法 A B C D E F

27、d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F2.5 測試策略集成中的組裝方法混合增殖式測試：對軟件中、上層使用自頂向下，對軟件的中下層采用自底向上。集成步驟： 首先對輸入輸出模塊和引入新算法模塊進(jìn)行測試； 再自底向上組裝成為功能相當(dāng)完整且相對獨(dú)立的子系統(tǒng)； 然后由主模塊開始自頂向下進(jìn)行增殖測試。2.5 測試策略集成測試的組織和實(shí)施集成測試是一種正規(guī)測試過程，必須精心計劃,并與單元測試的完成時間協(xié)調(diào)起來。在制定測試計劃時，應(yīng)考慮如下因素： 是采用何種系統(tǒng)組裝方法來進(jìn)行組裝測試。 組裝測試過程中連接各個模塊的順序。 模塊代碼編制和測試進(jìn)度是否與組裝測試的順序一致。 測試

28、過程中是否需要專門的硬件設(shè)備。2.5 測試策略集成測試完成的標(biāo)志成功地執(zhí)行了測試計劃中規(guī)定的所有組裝測試。修正了所發(fā)現(xiàn)的錯誤。測試結(jié)果通過了專門小組的評審。2.5 測試策略集成測試完成單元測試單元測試單元測試單元測試單元測試組合測試2.5 測試策略集成測試完成的標(biāo)志組合測試組合測試組合測試組合測試集成測試2.5 測試策略確認(rèn)測試確認(rèn)測試又稱有效性測試。任務(wù)是驗(yàn)證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明中已經(jīng)明確規(guī)定。2.5 測試策略確認(rèn)測試的步驟2.5 測試策略確認(rèn)測試中的有效性測試有效性測試是在模擬的環(huán)境（可能就是開發(fā)的環(huán)境）下，運(yùn)用黑盒測試的

29、方法，驗(yàn)證所測軟件是否滿足需求規(guī)格說明書列的需求。在全部軟件測試的測試用例運(yùn)行完后，所有的測試結(jié)果可以分為兩類： 測試結(jié)果與預(yù)期的結(jié)果相符。 測試結(jié)果與預(yù)期的結(jié)果不符。2.5 測試策略確認(rèn)測試中的軟件配置復(fù)查軟件配置復(fù)查的目的是保證軟件配置的所有成分都齊全。各方面的質(zhì)量都符合要求。具有維護(hù)階段所必需的細(xì)節(jié)。而且已經(jīng)編排好分類的目錄。2.5 測試策略系統(tǒng)測試系統(tǒng)測試是將通過確認(rèn)測試的軟件，作為整個基于計算機(jī)系統(tǒng)的一個元素，與計算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起測試。在實(shí)際運(yùn)行（使用）環(huán)境下，對計算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。系統(tǒng)測試的目的在于通過與系統(tǒng)的需

30、求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。2.5 測試策略系統(tǒng)測試由于軟件只是計算機(jī)系統(tǒng)中的一個組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運(yùn)行。因此，軟件在投入運(yùn)行以前需要完成系統(tǒng)測試，以保證各組成部分不僅能單獨(dú)的得到檢驗(yàn)，而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。系統(tǒng)測試實(shí)際上是針對系統(tǒng)中各個組成部分進(jìn)行的綜合性檢驗(yàn)。盡管每一個檢驗(yàn)有特定的目標(biāo)，然而所有的檢測工作都要驗(yàn)證系統(tǒng)中每個部分均已得到正確的集成，并能完成指定的功能。嚴(yán)格的說，系統(tǒng)測試超出了軟件工程范圍。通常這項工作并不由系統(tǒng)開發(fā)人員或系統(tǒng)開發(fā)組織來承擔(dān)，而是由軟件用

31、戶或軟件開發(fā)機(jī)構(gòu)委托獨(dú)立測試機(jī)構(gòu)來完成。2.5 測試策略系統(tǒng)測試系統(tǒng)測試與單元測試、集成測試的區(qū)別：（1）測試方法不同：系統(tǒng)測試屬于黑盒測試，而單元測試大量采用白盒測試，集成測試則是結(jié)合使用白盒與黑盒測試方法。（2）考察范圍不同：單元測試主要測試模塊內(nèi)部的接口、數(shù)據(jù)結(jié)構(gòu)、邏輯、異常處理等對象。集成測試主要測試模塊之間的接口和異常。系統(tǒng)測試主要測試整個系統(tǒng)相對于用戶的需求。（3）評估基準(zhǔn)不同：系統(tǒng)測試的評估基準(zhǔn)是測試用例對需求規(guī)格的覆蓋率；而單元測試和集成測試的評估主要是代碼的覆蓋率。2.5 測試策略系統(tǒng)測試的15種測試類型功能（機(jī)能）測試：目標(biāo)中的功能是否真正實(shí)現(xiàn)了。批量測試：企圖證明程序不能

32、處理目標(biāo)中指出的大批數(shù)據(jù)。強(qiáng)度測試：讓程序在高負(fù)荷情況下運(yùn)行（微軟建議72小時）?？捎眯詼y試：界面友好、錯誤信息簡明易懂。安全性測試：設(shè)法破壞程序的保密檢查。2.5 測試策略系統(tǒng)測試的15種測試類型性能測試：在一定工作負(fù)荷和配置條件下，系統(tǒng)響應(yīng)時間及處理速度。存儲量測試：測試程序所占用的內(nèi)外存容量（靜/動態(tài)）。配置測試：至少每一類和最大最小的設(shè)備配置情況都要測試。兼容/移植測試：對現(xiàn)有程序進(jìn)行修改和補(bǔ)充后，要進(jìn)行此類測試?？砂惭b性測試：測試系統(tǒng)的安裝過程。2.5 測試策略系統(tǒng)測試的15種測試類型可靠性測試：如平均無故障時間（MTTF），需要模擬運(yùn)行環(huán)境?；謴?fù)測試：測試系統(tǒng)出錯后如何恢復(fù)正常工作

33、的?？删S護(hù)性測試：對維護(hù)過程和難易程度進(jìn)行測試。文檔測試：審查文檔的正確性，對文檔中的每個例子都要作為測試用例。工序測試：測試操作工序的次序正確性。2.5 測試策略系統(tǒng)測試完成系統(tǒng)聯(lián)調(diào)2.5 測試策略回歸測試系統(tǒng)維護(hù)二次開發(fā)項目更新單元測試集成測試確認(rèn)測試系統(tǒng)測試回歸測試2.5 測試策略測試和測試測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試,也可以是開發(fā)機(jī)構(gòu)內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測試。測試的目的是評價軟件產(chǎn)品的功能、可使用性、可靠性、性能和支持，尤其注重產(chǎn)品的界面和特色。測試可以從軟件產(chǎn)品編碼結(jié)束之時開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認(rèn)測試過程中產(chǎn)品達(dá)到一定的穩(wěn)定和可

34、靠程度之后再開始。2.5 測試策略測試和測試測試是由軟件的多個用戶在一個或多個用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。與測試不同的是，開發(fā)者通常不在測試現(xiàn)場。測試的目的是衡量軟件產(chǎn)品的功能、可使用性、可靠性、性能和支持，尤其注重產(chǎn)品的產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。只有當(dāng)測試達(dá)到一定的可靠程度時，才能開始測試。它處在整個測試的最后階段。同時，產(chǎn)品的所有手冊文本也應(yīng)該在此階段完全定稿2.5 測試策略測試與調(diào)試軟件調(diào)試和軟件測試是完全不同的含義。通常情況是在測試以后緊接著要進(jìn)行調(diào)試，實(shí)際上這兩項工作是交叉進(jìn)行的。測試是一種檢驗(yàn)，經(jīng)過測試后可能會發(fā)現(xiàn)一些錯誤的征兆，但常常不能直接從測試的

35、結(jié)果中找出錯誤的根源。這就需要充分利用測試結(jié)果和測試過程中提供的信息進(jìn)行全面地分析，找到錯誤的根源和出現(xiàn)錯誤的原因，修正這些已發(fā)現(xiàn)的錯誤就是調(diào)試。即：調(diào)試是在測試發(fā)現(xiàn)錯誤后消除錯誤的過程。 2.6 驗(yàn)收測試驗(yàn)收測試是檢驗(yàn)軟件產(chǎn)品質(zhì)量的最后一道工序。驗(yàn)收測試是以用戶為主的測試，同時軟件開發(fā)人員也有一定的參與。驗(yàn)收測試由用戶參加設(shè)計測試用例，使用用戶界面來輸入測試數(shù)據(jù)，并分析測試的輸出結(jié)果，一般使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測試。在驗(yàn)收測試過程中，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性、兼容性、可維護(hù)性等進(jìn)行確認(rèn)。2.6 驗(yàn)收測試范圍軟件驗(yàn)收測試應(yīng)完成的工作包括： 明確驗(yàn)收項目，給定驗(yàn)收測試通

36、過的標(biāo)準(zhǔn)。 確定測試方法。 決定驗(yàn)收測試的組織機(jī)構(gòu)和可利用的資源。 選定測試結(jié)果分析方法。 制定驗(yàn)收測試計劃并進(jìn)行評審。 設(shè)計驗(yàn)收測試所用測試用例。 審查驗(yàn)收測試準(zhǔn)備工作。 執(zhí)行驗(yàn)收測試。 分析測試結(jié)果。 闡明驗(yàn)收測試結(jié)論，決定通過驗(yàn)收或是拒絕。2.6 驗(yàn)收測試計劃可能包括的檢驗(yàn)方面有以下一些： 功能測試（例如，完整的工資計算過程）。 逆向測試（例如，檢驗(yàn)不符合要求數(shù)據(jù)而引起出錯的恢復(fù)能力）。 特殊情況（例如，極限測試、不存在路徑的測試）。 文檔檢查。 強(qiáng)度測試（例如，大批數(shù)據(jù)或多用戶同時使用）。 恢復(fù)測試（例如，硬件故障或用戶不良數(shù)據(jù)引起的一些情況）。 可維護(hù)性評價。 用戶操作測試（如啟動、

37、退出系統(tǒng)）。 用戶友好性檢驗(yàn)。 安全測試。2.6 驗(yàn)收測試結(jié)果確認(rèn)測試的結(jié)果，確認(rèn)測試的結(jié)果有兩種情況： 功能和性能與用戶的要求一致，軟件可以接受。 功能和性能與用戶的要求的差距。2.7 第三方測試信息系統(tǒng)工程承建單位內(nèi)部進(jìn)行的自測被稱為第一方測試，業(yè)主單位對工程進(jìn)行的測試被稱為第二方測試。與此相對應(yīng)，由中立的第三方測試機(jī)構(gòu)對系統(tǒng)進(jìn)行的權(quán)威技術(shù)測試被稱為第三方測試。國內(nèi)的第三方測試工作始創(chuàng)于九十年初，經(jīng)過了近十年的孕育，以“千年蟲”問題的檢 驗(yàn)為契機(jī)，在二十世紀(jì)末開始快速發(fā)展。2.7 第三方測試必要性國外開發(fā)商質(zhì)量控制能力較強(qiáng)，但在比較專業(yè)的質(zhì)量認(rèn)證領(lǐng)域依然需要由第三方機(jī)構(gòu)來完成。國內(nèi)業(yè)主與開

38、發(fā)商在信息技術(shù)與業(yè)務(wù)技術(shù)上的信息不對稱性。國內(nèi)還沒有適應(yīng)國情的、系列化協(xié)調(diào)配套 的、工程化的信息系統(tǒng)生產(chǎn)過程管理、質(zhì)量 評測、控制技術(shù)的規(guī)范和法律規(guī)程指導(dǎo)。2.7 第三方測試特點(diǎn)第三方測試具有明顯的工程特性，主要包括需求分析審查、設(shè)計審查、功能測試、性能測試、安全性測試、可靠性測試、易用性測試、兼容性測試、可擴(kuò)充性測試、文檔測試等。2.7 第三方測試特點(diǎn)第三方測試以合同的形式制約了測試方，保證了測試工作在一開始就具有客觀性。第三方能夠從需求理解系統(tǒng)，從軟件工程角度把握系統(tǒng)，公平的評價系統(tǒng)中出現(xiàn)的問題。第三方機(jī)構(gòu)的權(quán)威性能夠更好的協(xié)調(diào)用戶與開發(fā)方之間的關(guān)系。2.7 第三方測試特點(diǎn)第三方測試不同于

39、開發(fā)方的自測試。 避免開發(fā)人員的定勢思維。 第三方測試的目的就是為盡量多地發(fā)現(xiàn)程序中的錯誤而運(yùn)行程序的過程，可以更多的發(fā)現(xiàn)問題。 隨著系統(tǒng)越做越大，開發(fā)方很難投入足夠的人力與物力進(jìn)行測試工作，同時也缺乏專業(yè)的測試工具及豐富的工具使用經(jīng)驗(yàn)。2.7 第三方測試特點(diǎn)第三方測試不同于用戶的自測試。 用戶熟悉業(yè)務(wù)但不熟悉計算機(jī)領(lǐng)域知識，很難對系統(tǒng)進(jìn)行深入分析。 用戶缺乏專用的測試工具。 第三方機(jī)構(gòu)既往測試經(jīng)驗(yàn)對測試的幫助。2.7 第三方測試對象應(yīng)用軟件的確認(rèn)測試、鑒定測試工程項目的系統(tǒng)測試、驗(yàn)收測試特殊項目/項目關(guān)鍵模塊的單元測試其他： 工程監(jiān)理 ISO9000認(rèn)證、CMM認(rèn)證2.7 第三方測試開展項目

40、組成立制定方案、規(guī)范、案例與計劃實(shí)施測試工作問題報告回歸測試測試總結(jié)、評估與測試報告第三章基本測試技術(shù)3.1 測試生命周期3.2 測試計劃3.3 測試設(shè)計3.4 測試開發(fā)3.5 測試執(zhí)行3.6 測試評估3.7 測試跟蹤3.1 測試生命周期測試計劃測試設(shè)計測試開發(fā)測試執(zhí)行測試評估3.2 測試計劃概述測試目的完成的標(biāo)準(zhǔn)時間安排明確的責(zé)任測試用例庫測試工具3.2 測試計劃概述所需機(jī)器時間軟/硬件配置系統(tǒng)組裝方式記錄手段回歸測試3.2 測試計劃具體內(nèi)容目的測試項（對象）測試類型測試范圍測試過程資源需求（硬件、軟件、人力）3.2 測試計劃具體內(nèi)容文檔的檢驗(yàn)進(jìn)度安排測試開始、結(jié)束準(zhǔn)則測試記錄回歸測試的方法

41、測試的評估缺陷跟蹤3.2 測試計劃測試需求業(yè)務(wù)功能 業(yè)務(wù)流程 數(shù)據(jù)庫事務(wù) 域值合法性用戶界面 對象狀態(tài) 窗口模式 菜單 標(biāo)準(zhǔn)尺寸的控件/文字3.2 測試計劃測試需求性能 在少于3秒的情況下增加一個新顧客帳戶強(qiáng)度 當(dāng)內(nèi)存很低的情況下運(yùn)行應(yīng)用程序 為設(shè)計規(guī)定是1,000,000 條記錄的系統(tǒng)增加1,000,001條記錄3.2 測試計劃測試需求配置 顯示驅(qū)動的兼容性 網(wǎng)絡(luò)連接安裝 新安裝（典型安裝、定制安裝） 升級安裝 網(wǎng)絡(luò)下載3.3 測試設(shè)計測試過程包括詳細(xì)的步驟以確定測試需求是否被滿足。組成： 測試的先決條件 輸入條件 被執(zhí)行的動作 期待的結(jié)果 證實(shí)期待結(jié)果的方法3.3 測試設(shè)計單元測試用例模塊

42、接口局部數(shù)據(jù)結(jié)構(gòu)獨(dú)立的路徑邊界條件出錯處理3.3 測試設(shè)計黑盒測試用例功能不對或遺漏界面錯誤數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤性能不滿足初始化和終止錯誤3.3 測試設(shè)計白盒測試用例保證一個模塊中的所有可執(zhí)行路徑至少被執(zhí)行一次 對所有邏輯值均需測試真和假在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性3.3 測試設(shè)計循環(huán)測試用例簡單循環(huán)嵌套循環(huán)串接循環(huán)非結(jié)構(gòu)循環(huán)3.3 測試設(shè)計GUI測試用例窗口下拉菜單與鼠標(biāo)數(shù)據(jù)項3.3 測試設(shè)計測試案例測試說明：3.3 測試設(shè)計測試案例測試案例： 3.3 測試設(shè)計測試案例測試案例：3.4 測試開發(fā)功能的自動化測試工具性能的自動化測試工具中的開發(fā)3.

43、5 測試執(zhí)行概述目標(biāo) 執(zhí)行測試 查看測試結(jié)果 研究并組織對測試結(jié)果進(jìn)行評估 記錄缺陷輸入 測試過程和測試用例輸出 測試日志 缺陷報告3.5 測試執(zhí)行記錄結(jié)果測試日志信息執(zhí)行測試過程評估意外的結(jié)果記錄缺陷3.5 測試執(zhí)行錯誤等級5級：災(zāi)難性的系統(tǒng)崩潰、數(shù)據(jù)被破壞4級：很嚴(yán)重的數(shù)據(jù)被破壞3級：嚴(yán)重的特性不能運(yùn)行，無法替代2級：中等的特性不能運(yùn)行，可替代1級：煩惱的提示不正確，報警不確切0級：輕微的表面化的錯誤，拼寫錯等3.5 測試執(zhí)行記錄格式3.5 測試執(zhí)行記錄格式3.5 測試執(zhí)行記錄格式3.6 測試評估概述目標(biāo) 提交測試過程的衡量標(biāo)準(zhǔn) 產(chǎn)生缺陷報告和測試覆蓋的總結(jié)報告輸入 測試日志 缺陷報告輸出

44、 測試覆蓋程度 缺陷分析報告3.6 測試評估測試覆蓋率基于覆蓋策略的系統(tǒng)測試 驗(yàn)證所有需求的完成情況 驗(yàn)證每行代碼的執(zhí)行情況基于測試需求的測試過程 覆蓋功能和設(shè)計的需求 驗(yàn)證一個測試需求對應(yīng)的測試過程3.6 測試評估缺陷分析軟件質(zhì)量 缺陷分析是提供驗(yàn)證軟件質(zhì)量的手段之一 測試需求的覆蓋程度決定了軟件測試的質(zhì)量如何實(shí)例報告 缺陷分配 缺陷趨向 缺陷狀態(tài) 遺留缺陷對軟件的影響3.6 測試評估性能評測主要的性能評測包括動態(tài)監(jiān)測：在測試執(zhí)行過程中，實(shí)時獲取并顯示正在執(zhí)行的各測試腳本的狀態(tài)。響應(yīng)時間吞吐量：測試對象針對特定主角或測試用例的響應(yīng)時間或吞吐量的評測。百分比報告：代表不同測試執(zhí)行情況的兩個（或多個）數(shù)據(jù)集之間的差異或趨勢。追蹤報告：包括主角（測試腳本）和測試對象之間的消息會話詳細(xì)信息。3.6 測試評估報告對上面所有的測試評估方法按規(guī)格整理成一個書面的測試評估報告，展現(xiàn)出軟件在各種評測手段下的質(zhì)量狀態(tài)。3.7 測試跟蹤記錄測試事件或用戶問題分析原因，定位錯誤進(jìn)行軟件修改修改結(jié)果的跟蹤第四章測試中的若干問題4.1 對測試的誤解4.2 測試