【正文】 對高層結(jié)構(gòu)圖中的模塊進行逐層向下擴展 ?在同一張結(jié)構(gòu)圖中高層模塊調(diào)用下層模塊，存在調(diào)用和被調(diào)用關(guān)系 自頂向下的擴展原則在不同階段的用法和含義 ?先把程序高度概括 ?對下層模塊進行逐層向下擴展 ?對擴展出來的下層模塊，反復(fù)進行修改 ?層次模塊圖反映程序的功能以及在這個程序中各個模塊之間的關(guān)系 自頂向下的擴展原則在不同階段的用法和含義 自頂向下的模塊設(shè)計原則 ?先把程序高度概括 ， 看作是一個最簡單的控制結(jié)構(gòu) ，即 ?為了完成這個功能 ， 需要進一步分解成若干個較低一層的模塊 ， 每一個下層模塊都有一個名稱 ， 表達(dá)了一個較小的功能對擴展出來的每一個下層模塊 ?反復(fù)運用自頂向下程序設(shè)計中的第二條原則 ， 逐層擴展 ， 直到最低一層每一個模塊都非常簡單 、 功能很小 ， 能夠很容易地用程序語句實現(xiàn)為止 。 軟件測試的時間 （ 1）單元測試 軟件測試在軟件生命周期中橫跨兩個階段 ?單元測試和編碼屬于軟件生命的同一個階段，通常在寫出每個模塊之后，就對它做必要的測試 ?模塊的編寫者和測試者是同一個人 （ 2）綜合測試 ?綜合測試在程序全部完成之后進行 ?由專門的測試人員承擔(dān) 軟件測試原則 ?確定預(yù)期輸出（或結(jié)果）是測試情況必不可少的一部分 ?程序員應(yīng)避免測試自己的程序 ?程序設(shè)計機構(gòu)不應(yīng)該測試自己的程序 ?測試用例的設(shè)計和選擇、預(yù)期結(jié)果的定義要有利于錯誤的檢測 ?要嚴(yán)格執(zhí)行測試計劃、排除測試的隨意性 軟件測試原則 ?測試的目的 ?測試用例標(biāo)準(zhǔn)，工具 ?環(huán)境、機時 ?完成標(biāo)準(zhǔn)，進度，崗位責(zé)任 ?系統(tǒng)集成方式 ?跟蹤規(guī)程 ?排錯規(guī)程 ?回歸測試的規(guī)定等 ?要將軟件測試貫穿于軟件開發(fā)的整個過程，以便盡可能地發(fā)現(xiàn)錯誤，從而減少由于錯誤帶來的損失 ?軟件測試不僅要檢查程序是否做了應(yīng)該做的事情，還要檢查它是否做了不應(yīng)該做的事情 軟件測試原則 ?經(jīng)驗表明：程序中尚未發(fā)現(xiàn)的錯誤的數(shù)量與該程序段已發(fā)現(xiàn)的錯誤數(shù)量往往成正比 = 軟件測試原則 軟件錯誤 Neson將錯誤和缺陷概括為七個方面： 1. 編程時的語法錯誤 ? 保留字拼寫錯誤 ? 循環(huán)體不匹配 ? 參數(shù)與變元不匹配 ? 程序員發(fā)現(xiàn)在用某些解釋性程序設(shè)計語言（如VB， VFP等）編程時檢查這類錯誤容易而且及時 2. 程序員對語言結(jié)果誤解所造成的錯誤 ? 對循環(huán)體結(jié)構(gòu)的誤解 3. 算法或邏輯上的錯誤 4. 近似算法會使某些輸入變量得不到精確的甚至錯誤的結(jié)果 5. 由于錯誤的輸入導(dǎo)致程序的錯誤 軟件錯誤 6. 數(shù)據(jù)結(jié)構(gòu)說明不當(dāng)或?qū)崿F(xiàn)中的缺陷所造成的錯誤 過小的棧容量造成 ?棧操作的上溢 ?棧操作的下溢 軟件錯誤 7. 由于系統(tǒng) (或模塊 )說明書的缺陷所造成的錯誤 此類為最嚴(yán)重的錯誤 軟件錯誤 測試任務(wù) ?預(yù)防軟件發(fā)生錯誤 ?發(fā)現(xiàn)并改正程序錯誤 ?提供錯誤診斷信息 軟件測試的基本手段 人工測試 計算機測試 人工測試 人工測試可以由編寫者本人非正式地進行，也可以由審查小組正式地進行。如果第二列字符不是數(shù)字，則發(fā)出信息 X13 因 1第 1列字符是 A 2第 1列字符是 B 3第 2列字符是一個數(shù)字 果 70修改文件 71發(fā)出信息 X12 72發(fā)出信息 X13 實例分析 1 2 3 11 ∨ ∧ 71 70 72 ～ ～ 1 2 3 11 ∨ ∧ 71 70 72 ～ ～ E 實例分析 錯誤推錯法（猜錯） (error guessing) ?很大程度上依靠直覺和經(jīng)驗進行 ?列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況 ?選擇測試方案 靜態(tài)測試法 ?靜態(tài)測試法概述 ?靜態(tài)測試法種類 ?不涉及程序的實際執(zhí)行 ?以人工的，非形式化的方法對程序進行分析和測試 ?可檢出大約 30%~70%的邏輯設(shè)計錯誤 ?該方法的成本較低 靜態(tài)測試法 靜態(tài)測試法 人工測試 ?程序?qū)彶闀?代碼會審 ?桌前檢查（ Desk Checking)靜態(tài)檢查 ?軟件測試策略 ?人工運行 程序?qū)彶闀? ?由一組人員通過閱讀、討論和爭議，對程序進行靜態(tài)分析的過程 ?需要的材料： ☆ 待審程序文檔 ☆ 控制流程圖 ☆ 有關(guān)要求規(guī)范 程序?qū)彶闀ぷ鬟^程 ?會議前把要審查的程序清單和設(shè)計規(guī)范分發(fā)給小組的其他成員 ?請程序員講述程序的邏輯結(jié)構(gòu) ?根據(jù)常見程序錯誤檢驗單分析程序 錯誤檢驗單中的項目 ☆ 數(shù)據(jù)引用錯誤 ☆ 數(shù)據(jù)說明錯誤 ☆ 計算錯誤 ☆ 比較錯誤 ☆ 控制流程錯誤 ☆ 接口錯誤 ☆ 輸入 /輸出錯誤 ☆ 其他檢驗 桌前檢查 靜態(tài)檢查 ?由程序員反復(fù)閱讀編碼和流程圖，對照模塊功能說明、算法、語法規(guī)定檢查程序的語法錯誤和邏輯錯誤 ?可設(shè)計少量測試實例，由人工來模擬計算機單步執(zhí)行并觀察執(zhí)行過程的結(jié)果 軟件測試策略 ?用黑盒法設(shè)計基本的測試方案 ?用白盒法補充一些必要的測試方案 具體策略如下： ☆ 如果規(guī)范含有輸入條件的組合，便從因果圖開始 ☆ 在任何情況下都應(yīng)該使用邊界值分析的方法 ☆ 必要時用等價劃分法補充測試方案 ☆ 必要時再用錯誤推測法補充測試方案 ☆ 對照程序邏輯，檢查已經(jīng)設(shè)計出的測試方案 軟件測試策略 軟件測試步驟 ?單元測試（ Unit Testing) ?集成測試（ Integration Testing) ?功能測試（ Function Testing) ?系統(tǒng)測試（ System Testing) ?驗收測試（ Acceptance Testing) ?安裝測試（ Acceptance Testing) ?軟件測試框架 單元測試 模塊測試 (Module Testing) 測試單個程序模塊，確定模塊的邏輯功能是否正確 單元測試的目的： 對模塊的功能與定義模塊的性能規(guī)范或接口規(guī)范進行比較 單元測試的依據(jù) ? 模塊的規(guī)范 模塊說明書 ?模塊的源程序 詳細(xì)地說明了模塊的輸入、輸出參數(shù) 以及模塊的功能（模塊的外部屬性） 顯示了模塊內(nèi)部所使用的數(shù)據(jù)和 模塊的功能實現(xiàn)方式（模塊的內(nèi)部屬性） 單元測試 模塊測試 (Module Testing) ?單元測試數(shù)據(jù)的選擇 ?單元測試的原則 ?單元測試的內(nèi)容 ?單元測試情況的設(shè)計 單元測試的基本原則 （ 2）測試所有可能的執(zhí)行或邏輯路徑的組合 （ 1）至少一次測試所有的語句 （ 3）在索引或下標(biāo)的全域中測試所有的重復(fù) （ 4）測試每個模塊的所有入口和出口 單元的測試內(nèi)容 ?模塊的接口 ?數(shù)據(jù)結(jié)構(gòu) ?重要執(zhí)行通路 ?邊界條件 ?一個模塊向其子模塊傳遞和接收數(shù)據(jù)元素的個數(shù)不相等； ?傳遞的參數(shù)的屬性和變元的屬性不匹配； ?傳遞給內(nèi)部函數(shù)的變元數(shù)據(jù)類型和次序不匹配； ?只修改了做輸入用的變元； ?全程變量的定義和用法在各個模塊中定義不一致。 重要路徑 控制邏輯錯誤 ?沒有經(jīng)歷所有選擇結(jié)果的路徑； ?對所有選擇路徑的共同出口點的規(guī)定不正確； ?循環(huán)下標(biāo)不正確； ?初始化和步長不正確； ? 對循環(huán)出口的規(guī)定不正確。 ?設(shè)法證明未能滿足兼容性的目標(biāo)，以及不能實現(xiàn)兩系統(tǒng)間相互轉(zhuǎn)換 可靠性測試（ reliability testing) ?可靠目標(biāo)很難測試 ?可以考慮用一套數(shù)學(xué)模型來估計該目標(biāo)的有效性 恢復(fù)測試（ recovery testing) ?像操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和遠(yuǎn)程處理程序這類程序往往有系統(tǒng)恢復(fù)的目標(biāo)，說明在出現(xiàn)程序錯誤、硬件失效及數(shù)據(jù)錯誤之后，整個系統(tǒng)應(yīng)該怎樣恢復(fù) ?要證明恢復(fù)功能不正常工作