系統(tǒng)分析課件第八講

系統(tǒng)分析課件第八講第1頁，共165頁，2023年，2月20日，星期六本章重點程序設(shè)計系統(tǒng)測試系統(tǒng)調(diào)試系統(tǒng)安裝系統(tǒng)維護第2頁，共165頁，2023年，2月20日，星期六8.1概述8.1.1主要任務(wù)根據(jù)系統(tǒng)設(shè)計所提供的控制結(jié)構(gòu)圖、數(shù)據(jù)庫設(shè)計、系統(tǒng)配置方案及詳細設(shè)計資料，編制和調(diào)試程序、調(diào)試系統(tǒng)、進行系統(tǒng)切換等工作，將技術(shù)設(shè)計轉(zhuǎn)化為物理實際系統(tǒng)。其主要任務(wù)是:1)系統(tǒng)實施準備2)系統(tǒng)平臺的硬、軟件安裝與調(diào)試3)程序的編制與調(diào)試4)信息系統(tǒng)調(diào)試(軟、硬件結(jié)合)5)原始數(shù)據(jù)的建立6）組織系統(tǒng)測試7)系統(tǒng)轉(zhuǎn)換8)試運行、驗收與維護9）項目管理與實施進度控制第3頁，共165頁，2023年，2月20日，星期六系統(tǒng)實施的內(nèi)容與步驟系統(tǒng)實現(xiàn)準備項目管理與實施進度控制實施隊伍的組織軟、硬件和配套設(shè)施的準備信息流程、業(yè)務(wù)規(guī)程的組織與修訂實現(xiàn)方法、工具和數(shù)據(jù)的準備人員培訓(xùn)與宣傳教育培訓(xùn)程序編制數(shù)據(jù)采集系統(tǒng)測試及調(diào)試系統(tǒng)試運行系統(tǒng)轉(zhuǎn)換與驗收系統(tǒng)運行維護第4頁，共165頁，2023年，2月20日，星期六8.1.2系統(tǒng)實施階段的輸出文檔程序文檔程序設(shè)計報告源程序清單程序調(diào)試報告系統(tǒng)實施報告實施計劃設(shè)備采購及安裝驗收報告業(yè)務(wù)規(guī)程及有關(guān)制度系統(tǒng)調(diào)試及試運行報告系統(tǒng)轉(zhuǎn)換及驗收報告系統(tǒng)的操作使用手冊第5頁，共165頁，2023年，2月20日，星期六8.2程序模塊的設(shè)計程序設(shè)計的基本任務(wù)根據(jù)系統(tǒng)設(shè)計說明書中關(guān)于模塊的詳細描述和處理過程的描述，選擇合適的計算機語言來編制程序的工作。第6頁，共165頁，2023年，2月20日，星期六正確性：語法正確、邏輯正確、需求正確可維護性：可靠性：可理解性：效率：指計算機資源（如時間和空間）能否被有效地使用。對程序的基本要求：第7頁，共165頁，2023年，2月20日，星期六（1）結(jié)構(gòu)化程序設(shè)計方法三種基本結(jié)構(gòu)順序選擇循環(huán)模塊化自頂向下，逐步求精程序設(shè)計方法第8頁，共165頁，2023年，2月20日，星期六（2）面向?qū)ο蟪绦蛟O(shè)計方法封裝繼承多態(tài)程序設(shè)計方法第9頁，共165頁，2023年，2月20日，星期六程序設(shè)計風格程序?qū)嶋H上也是一種供人閱讀的文章，有一個文章的風格問題。應(yīng)該使程序具有良好的風格。源程序文檔化數(shù)據(jù)說明語句結(jié)構(gòu)輸入／輸出方法第10頁，共165頁，2023年，2月20日，星期六1.源程序文檔化符號名的命名程序的注釋視覺組織空格、空行和移行第11頁，共165頁，2023年，2月20日，星期六2.數(shù)據(jù)說明為了使程序中數(shù)據(jù)說明更易于理解和維護，必須注意以下幾點。

數(shù)據(jù)說明的次序應(yīng)當規(guī)范化說明語句中變量安排有序化使用注釋說明復(fù)雜數(shù)據(jù)結(jié)構(gòu)第12頁，共165頁，2023年，2月20日，星期六3.語句結(jié)構(gòu)語句構(gòu)造力求簡單，直接，不能為了片面追求效率而使語句復(fù)雜化。在一行內(nèi)只寫一條語句程序編寫首先應(yīng)當考慮清晰性程序要能直截了當?shù)卣f明程序員的用意除非對效率有特殊要求,程序編寫要做到清晰第一，效率第二。首先要保證程序正確,然后才要求提高速避免使用臨時變量而使可讀性下降。第13頁，共165頁，2023年，2月20日，星期六程序設(shè)計語言程序編碼階段的任務(wù)是將軟件的詳細設(shè)計轉(zhuǎn)換成用程序設(shè)計語言實現(xiàn)的程序代碼，即把用PDL偽碼寫成的程序，翻譯成計算機能接受的諸如FORTRAN、C、匯編之類程序設(shè)計語言的程序。因此，程序設(shè)計語言的性能和設(shè)計風格對于程序設(shè)計的效能和質(zhì)量有著直接的關(guān)系。第14頁，共165頁，2023年，2月20日，星期六1.程序設(shè)計語言的基本成分數(shù)據(jù)部分：程序中能構(gòu)造的數(shù)據(jù)類型，用以描述程序中使用的各種類型的數(shù)據(jù)，如變量、數(shù)組、指針、文件等。運算部分：程序中允許執(zhí)行的運算，用以描述程序中所需執(zhí)行的運算?？刂撇糠郑撼绦蛑性试S使用的控制結(jié)構(gòu)，用它們構(gòu)造程序的控制邏輯。傳輸部分：程序中用以傳輸數(shù)據(jù)的方式，如輸入/輸出語句。第15頁，共165頁，2023年，2月20日，星期六2.程序設(shè)計語言的層次從三個層次討論程序設(shè)計語言：語法

用來表示構(gòu)成語言的各個記號間的組合規(guī)則。如C語言中for語句的構(gòu)成規(guī)則為

for(表達式1；表達式2；表達式3）語句程序中出現(xiàn)的for語句必須符合上述構(gòu)成規(guī)則。語法不涉及這些記號的含義，也不涉及使用者。第16頁，共165頁，2023年，2月20日，星期六語義

用來表示按照各種表示方法所表示的各個記號的特定含義。但它不涉及使用者。如在for語句中，表達式1設(shè)置循環(huán)初值，表達式2控制循環(huán)結(jié)束，表達式3增減循環(huán)變量。語句是循環(huán)體。for

語義為：計算表達式1；計算表達式2；若結(jié)果為0，循環(huán)結(jié)束，否則繼續(xù)第步；執(zhí)行循環(huán)體；計算表達式3；轉(zhuǎn)向第步。第17頁，共165頁，2023年，2月20日，星期六語用

表示構(gòu)成語言的各個記號和使用者之間的關(guān)系。例如，在某種程序設(shè)計語言中是否允許遞歸。若允許遞歸，遞歸層數(shù)的上界是多少，這些都是語用方面的問題。第18頁，共165頁，2023年，2月20日，星期六3.廣泛使用的程序設(shè)計語言比較：1)匯編語言：面向機器，涉及計算機的結(jié)構(gòu)，特別適用于一些實時的過程控制程序，能夠設(shè)計出執(zhí)行效率最優(yōu)的程序代碼。2)Fortran：是一個編譯性語言，產(chǎn)生目標代碼，運行速度快，支持局部變量的概念，因而能夠?qū)崿F(xiàn)信息隱蔽的原則，進行模塊設(shè)計，主要用于科學計算領(lǐng)域。3)COBOL語言：面向商業(yè)應(yīng)用的語言，能夠定義和處理復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，具有較強的文件存取能力和報表處理能力。一定程序的支持模塊化設(shè)計。第19頁，共165頁，2023年，2月20日，星期六4)C語言：具有低級語言的一些特點：訪問寄存器進行位操作等，又具有高級語言的全部優(yōu)點：支持變量局部化，定義和操作復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，能夠進行模塊化程序設(shè)計，可用于實時程序設(shè)計，系統(tǒng)軟件設(shè)計和工具軟件設(shè)計。5)Ada語言：具有C語言的主要優(yōu)點外，還具備支持抽象數(shù)據(jù)類型的概念，即具有面向?qū)ο蟪绦蛟O(shè)計的一些特征，是軍隊的標準語言。第20頁，共165頁，2023年，2月20日，星期六6)4GL面向應(yīng)用面向應(yīng)用開發(fā)人員非過程化語言一體化語言高效率語言開放式語言第21頁，共165頁，2023年，2月20日，星期六4.程序設(shè)計語言的選擇項目的應(yīng)用領(lǐng)域用戶的要求可以使用的編譯程序或開發(fā)環(huán)境程序員的經(jīng)驗知識軟件可移植性要求第22頁，共165頁，2023年，2月20日，星期六8.3軟件測試軟件測試的目的和原則測試方法與測試用例設(shè)計軟件測試的策略軟件測試的種類程序的靜態(tài)測試第23頁，共165頁，2023年，2月20日，星期六

軟件產(chǎn)品最大的成本是檢測軟件錯誤、修正軟件錯誤的成本。在整個軟件開發(fā)中，測試工作量一般占30%～40%，甚至≥50%。在人命關(guān)天的軟件(如飛機控制、核反應(yīng)堆等）測試所花費的時間往往是其它軟件工程活動時間之和的三到五倍例:Exchange2000和Windows2000項目組人員構(gòu)成項目組角色Exchange2000Windows2000項目經(jīng)理約25人約250人開發(fā)人員約140人約1700人測試人員約350人約3200人測試/開發(fā)人員比例2.5:11.9:1第24頁，共165頁，2023年，2月20日，星期六軟件測試背景軟件是人編的—所以不完美實例:1994-1995,迪斯尼的獅子王系統(tǒng)不支持問題Intel的pentium處理器1994年浮點除法缺陷2000年8月28日，1.13MHZ處理器一個可能導(dǎo)致運行程序被掛起的執(zhí)行指令問題1999年12月3日,美國航天局火星極地登陸飛船失蹤1991年愛國者導(dǎo)彈防御系統(tǒng)系統(tǒng)時鐘錯誤積累造成跟蹤系統(tǒng)失去精確度千年蟲,世界各地解決2000年錯誤超過數(shù)億美元第25頁，共165頁，2023年，2月20日，星期六軟件測試的問題:誰執(zhí)行測試？開發(fā)者？單獨的測試人員？兩方面人員？測試什么？每個部分都測試？測試軟件中高風險部分？什么時候測試？怎樣測試？測試應(yīng)進行到什么程度？

第26頁，共165頁，2023年，2月20日，星期六8.3.1軟件測試的目的和原則

1、描述軟件失敗的術(shù)語軟件錯誤軟件缺陷軟件故障軟件失效第27頁，共165頁，2023年，2月20日，星期六2.軟件測試的目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求。第28頁，共165頁，2023年，2月20日，星期六Myers軟件測試目的Myers在其名著“TheArtofSoftwareTest”中強調(diào)：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。第29頁，共165頁，2023年，2月20日，星期六換言之，測試的目的是想以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試，我們就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤。第30頁，共165頁，2023年，2月20日，星期六“測試的目的是說明程序正確地執(zhí)行它應(yīng)有的功能”

這種說法正確嗎？例：程序Triangle，輸入三個整數(shù)，表示一個三角形的三個邊長，該程序產(chǎn)生一個結(jié)果，指出該三角形是等邊三角形、等腰三角形還是不等邊三角形。

為說明其能正確執(zhí)行它的功能，可使用“測試用例”：

(3,4,5)(5,5,6)(6,6,6)程序都能給出正確結(jié)果，是否就可認為程序是正確的？第31頁，共165頁，2023年，2月20日，星期六3.軟件測試的原則應(yīng)當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。測試用例應(yīng)由測試輸入數(shù)據(jù)和對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。程序員應(yīng)避免檢查自己的程序。在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件。所有的測試都應(yīng)當追溯到用戶要求，導(dǎo)致程序不能滿足用戶要求的錯誤是嚴重錯誤。第32頁，共165頁，2023年，2月20日，星期六充分注意測試中的群集現(xiàn)象。經(jīng)驗表明，測試發(fā)現(xiàn)錯誤的80%很可能出自20%的模塊，換句話說，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。嚴格執(zhí)行測試計劃，排除測試的隨意性。應(yīng)當對每一個測試結(jié)果做全面檢查。妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。第33頁，共165頁，2023年，2月20日，星期六4.軟件測試的對象軟件測試并不等于程序測試。軟件測試應(yīng)貫穿于軟件定義與開發(fā)的整個期間。需求分析、概要設(shè)計、詳細設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細設(shè)計規(guī)格說明以及源程序，都應(yīng)成為軟件測試的對象。測試的兩個方面：缺陷測試V&V（驗證和確認）第34頁，共165頁，2023年，2月20日，星期六驗證(Verification)，檢查軟件生存期各個階段過程活動的結(jié)果是否滿足規(guī)格說明的描述，證實各階段和階段之間的邏輯協(xié)調(diào)性、完備性和正確性。確認(Validation)，是比驗證更廣泛的過程活動。目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性，即是否滿足用戶的要求。Boehm給出兩者的區(qū)分：驗證：我們是否在正確地建造一個產(chǎn)品確認：我們是否在建成一個正確的產(chǎn)品第35頁，共165頁，2023年，2月20日，星期六

靜態(tài)和動態(tài)的V&V需求規(guī)約概要設(shè)計形式規(guī)約詳細設(shè)計程序原型靜態(tài)驗證動態(tài)確認第36頁，共165頁，2023年，2月20日，星期六5.測試信息流可靠性分析測試軟件配置測試配置測試工具結(jié)果分析測試結(jié)果預(yù)期結(jié)果出錯率數(shù)據(jù)預(yù)測的可靠性錯誤調(diào)試修改后的軟件第37頁，共165頁，2023年，2月20日，星期六軟件配置：軟件需求規(guī)格說明、軟件設(shè)計規(guī)格說明、源代碼等；測試配置：測試計劃、測試用例、測試程序等；測試工具：測試數(shù)據(jù)自動生成程序、靜態(tài)分析程序、動態(tài)分析程序、測試結(jié)果分析程序、以及驅(qū)動測試的測試數(shù)據(jù)庫等等。測試結(jié)果分析：比較實測結(jié)果與預(yù)期結(jié)果，評價錯誤是否發(fā)生。第38頁，共165頁，2023年，2月20日，星期六排錯(調(diào)試)：對已經(jīng)發(fā)現(xiàn)的錯誤進行錯誤定位和確定出錯性質(zhì)，并改正這些錯誤，同時修改相關(guān)的文檔。修正后的文檔再測試：直到通過測試為止。通過收集和分析測試結(jié)果數(shù)據(jù)，對軟件建立可靠性模型利用可靠性分析，評價軟件質(zhì)量。如果測試發(fā)現(xiàn)不了錯誤，可以肯定，測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。第39頁，共165頁，2023年，2月20日，星期六6.測試模型軟件開發(fā)過程是一個自頂向下，逐步細化的過程軟件計劃階段定義軟件范圍（作用域）軟件需求分析階段建立軟件信息域、功能和性能需求、約束等軟件設(shè)計階段建立軟件體系結(jié)構(gòu)、用戶接口、數(shù)據(jù)結(jié)構(gòu)和細部設(shè)計程序編碼階段把設(shè)計用某種程序設(shè)計語言轉(zhuǎn)換成程序代碼第40頁，共165頁，2023年，2月20日，星期六可行性研究需求分析概要設(shè)計詳細設(shè)計編碼與調(diào)試單元測試組裝測試確認測試運行

詳細設(shè)計說明書概要設(shè)計說明書需求規(guī)格說明書可行性報告·項目實施計劃測試過程是依相反順序安排的自底向上，逐步集成的過程。第41頁，共165頁，2023年，2月20日，星期六軟件生存期各階段間需保持的正確性用戶要求用戶:我要什么?運行結(jié)果計算機:程序運行得到的結(jié)果源程序程序員:我要讓計算機什么做?設(shè)計說明書設(shè)計員:我要讓軟件做什么?需求說明書分析員:我可以提供什么?12345理解正確性表達正確性理解正確性設(shè)計正確性表達正確性理解正確性編碼正確性運行正確性輸入正確性相符嗎?ABCDABCBCCB？第42頁，共165頁，2023年，2月20日，星期六7.軟件測試流程測試流程：制定測試計劃設(shè)計測試實施測試執(zhí)行測試評估測試回歸測試第43頁，共165頁，2023年，2月20日，星期六7.軟件測試流程3)實施測試 準備測試環(huán)境 獲得測試數(shù)據(jù) 測試腳本概要4)執(zhí)行測試：執(zhí)行測試用例并記錄測試結(jié)果5)評估測試 覆蓋評測：測試的完全程度 質(zhì)量評測：測試過程中已發(fā)現(xiàn)的缺陷的評估。

第44頁，共165頁，2023年，2月20日，星期六8、測試的方法與技術(shù)軟件測試技術(shù)的發(fā)展20世紀60年代：主要以代碼調(diào)試為主；70年代：以演示軟件系統(tǒng)的正確性為主；80年代90年代中期：主要以檢查程序錯誤為主；90年代中期以后：開始更注重軟件質(zhì)量特性的整體評估目前軟件測試最主要的目標是評估軟件功能，但一般也要測試軟件的非功能屬性。

第45頁，共165頁，2023年，2月20日，星期六測試技術(shù)分類按功能分：白盒測試(Whitetest)黑盒測試(BlackTest)按測試時間來分：單元測試(UnitTest)集成測試(IntegrateTest)確認測試(ValidationTest)系統(tǒng)測試(SystemTest)

按運行狀態(tài)分：靜態(tài)測試(Static

Test)動態(tài)測試(DynamicTest)

按方向來分：正向測試逆向測試

第46頁，共165頁，2023年，2月20日，星期六8.3.2測試方法與測試用例設(shè)計黑盒測試等價類劃分邊界值分析錯誤推測法因果圖接口測試白盒測試邏輯覆蓋判定結(jié)構(gòu)分析循環(huán)結(jié)構(gòu)分析基本路徑覆蓋一、測試方法第47頁，共165頁，2023年，2月20日，星期六黑盒測試（Black-BoxTest）這種方法是把測試對象看做一個黑盒，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求和功能規(guī)格說明，檢查程序的功能是否符合它的功能說明。黑盒測試叫做功能測試或數(shù)據(jù)驅(qū)動測試。第48頁，共165頁，2023年，2月20日，星期六黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:是否有不正確或遺漏了的功能?在接口上，輸入能否正確地接受?能否輸出正確的結(jié)果?是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤?性能上是否能夠滿足要求?是否有初始化或終止性錯誤?

第49頁，共165頁，2023年，2月20日，星期六動態(tài)黑盒測試

—

閉著眼睛測試軟件軟件輸入不深入代碼細節(jié)的測試方法稱為動態(tài)黑盒測試。軟件測試員充當客戶來使用它。輸出第50頁，共165頁，2023年，2月20日，星期六白盒測試（White-BoxTest）此方法把測試對象看做一個玻璃盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。第51頁，共165頁，2023年，2月20日，星期六軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一次—路徑覆蓋測試；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次—邏輯覆蓋測試；在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體—控制流測試；測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性—數(shù)據(jù)流測試、領(lǐng)域測試等。第52頁，共165頁，2023年，2月20日，星期六動態(tài)白盒測試

—

帶上X光眼鏡測試軟件??????????????3581322.293419985680302829734315250*(1+0.015)*((1+0.015)^360-1)/0.015250*(1+0.015)*((1+0.015)^360-1)/0.015假如知道一個盒子包含一臺計算機,而另一個盒子是人用紙筆計算,就會選擇不同的測試用例第53頁，共165頁，2023年，2月20日，星期六循環(huán)20次第54頁，共165頁，2023年，2月20日，星期六黑盒測試與白盒測試比較黑盒測試是從用戶觀點，按規(guī)格說明書要求的輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系設(shè)計測試用例,是根據(jù)程序外部特征進行測試。

白盒測試是根據(jù)程序內(nèi)部邏輯結(jié)構(gòu)進行測試。CBADA-只能用黑盒測試發(fā)現(xiàn)的錯誤B-只能用白盒測試發(fā)現(xiàn)的錯誤C-兩種方法都能發(fā)現(xiàn)的錯誤D-兩種方法都不能發(fā)現(xiàn)的錯誤黑盒測試與白盒測試能發(fā)現(xiàn)的錯誤第55頁，共165頁，2023年，2月20日，星期六

黑盒測試與白盒測試優(yōu)缺點比較

黑盒測試

白盒測試優(yōu)點缺點性質(zhì)①適用于各階段測試②從產(chǎn)品功能角度測試③容易入手生成測試數(shù)據(jù)①可構(gòu)成測試數(shù)據(jù)使特定程序部分得到測試②有一定的充分性度量手段③可或較多工具支持①某些代碼得不到測試②如果規(guī)格說明有誤，則無法發(fā)現(xiàn)③不易進行充分性測試①不易生成測試數(shù)據(jù)(通常)②無法對未實現(xiàn)規(guī)格說明的部分進行測試③工作量大，通常只用于單元測試，有應(yīng)用局限是一種確認技術(shù)，回答“我們在構(gòu)造一個正確的系統(tǒng)嗎？”是一種驗證技術(shù)，回答“我們在正確地構(gòu)造一個系統(tǒng)嗎？”第56頁，共165頁，2023年，2月20日，星期六二、白盒測試用例設(shè)計邏輯覆蓋判定結(jié)構(gòu)分析循環(huán)結(jié)構(gòu)分析基本路徑測試第57頁，共165頁，2023年，2月20日，星期六1、邏輯覆蓋語句覆蓋判定覆蓋條件覆蓋判定－條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù)。它屬白盒測試。第58頁，共165頁，2023年，2月20日，星期六(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFabdce第59頁，共165頁，2023年，2月20日，星期六

覆蓋標準：使得程序中每個語句至少都能被執(zhí)行一次。選擇用例：[(2,0,4),(2,0,3)]用例格式，由輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩部分組成：[輸入(A,B,X)，輸出(A,B,X)]1）語句覆蓋a

A>1ANDB=0X:=X/A

A=2ORX>1X:=X+1bcdeYNYNX:=X/AX:=X+1第60頁，共165頁，2023年，2月20日，星期六覆蓋標準使得程序中每個判定至少為TRUE或FALSE各一次。覆蓋情況：共有兩個判定，應(yīng)執(zhí)行路徑：ace∧abd 或：acd∧abe選擇用例，⑴⑵兩組用例中任選擇其一⑴[(2,0,4),(2,0,3)]ace[(1,1,1),(1,1,1)]abd⑵[(2,1,1),(2,1,2)]abe[(3,0,3),(3,1,1)]acd

A>1ANDB=0X:=X/A

A=2ORX>1X:=X+1abcdeYNYN2）判定覆蓋注：符號∧表示“AND”運算，符號∨表示“OR”運算。第61頁，共165頁，2023年，2月20日，星期六覆蓋標準：使得判定中的每個條件獲得各種可能的結(jié)果。應(yīng)滿足以下覆蓋情況：判定一:A>1,A≤1,B=0,B≠0判定二:A=2,A≠2,X>1,X≤1選擇用例：[(2,0,4),(2,0,3)][(1,1,1),(1,1,1)]注意:[(1,0,3),(1,0,4)][(2,1,1),(2,1,2)]滿足條件覆蓋，但不滿足判斷覆蓋。3）條件覆蓋

A>1ANDB=0X:=X/A

A=2ORX>1X:=X+1abcdeYNYN判定一判定二第62頁，共165頁，2023年，2月20日，星期六覆蓋標準： 同時滿足判定覆蓋和條件覆蓋。即使得程序中每個判定至少為TRUE或FALSE各一次，同時使得判定中的每個條件獲得各種可能的結(jié)果。應(yīng)滿足以下覆蓋情況：條件:A>1,A≤1,B=0,B≠0 A=2,A≠2,X>1,X≤1應(yīng)執(zhí)行路徑ace∧abd 或acd∧abe選擇用例：[(2,0,4),(2,0,3)]（ace)[(1,1,1),(1,1,1)](abd)4）判定/條件覆蓋

A>1ANDB=0X:=X/A

A=2ORX>1X:=X+1abcdeYNYN第63頁，共165頁，2023年，2月20日，星期六覆蓋標準：使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。滿足以下覆蓋情況：①A>1,B=0②A≤1,

B≠0③A>1,B≠0④A≤1,B=0⑤A=2,X>1

⑥A=2,X≤1

⑦A≠2,X>1

⑧A≠2,X≤1選擇用例：[(2,0,4),(2,0,3)]覆蓋情況①⑤[(2,1,1),(2,1,2)]覆蓋情況③

⑥[(1,0,3),(1,0,4)]覆蓋情況④

⑦[(1,1,1),(1,1,1)]覆蓋情況②

⑧5）條件組合覆蓋}判定一}判定二A>1X:=X/A

A=2X:=X+1abcdeB=0

X>1YNYNYNYN第64頁，共165頁，2023年，2月20日，星期六6）路徑測試測試用例

通過路徑【(2,0,4),(2,0,3)】ace(L1)

【(1,1,1),(1,1,1)】abd

(L2)

【(1,1,2),(1,1,3)】abe

(L3)

【(3,0,3),(3,0,1)】acd

(L4)覆蓋標準：設(shè)計足夠的測試用例，覆蓋程序中所有可能的路徑。

A>1ANDB=0X:=X/A

A=2ORX>1X:=X+1abcdeYNYN第65頁，共165頁，2023年，2月20日，星期六二、黑盒測試技術(shù)等價劃分測試：邊界值分析：基于圖的測試：比較測試：正交數(shù)組測試：主要介紹基于對象關(guān)系的測試序列，用以發(fā)現(xiàn)錯誤利用冗余系統(tǒng)，對不同版本的測試比較對輸入域采用正交數(shù)組測試，用比窮舉輸入域少得多的案例測試第66頁，共165頁，2023年，2月20日，星期六1.等價類劃分測試等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設(shè)計測試用例。等價類劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)代表性的數(shù)據(jù)做為測試用例。使用這一方法設(shè)計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。第67頁，共165頁，2023年，2月20日，星期六第一步：劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其他值的測試。 等價類的劃分有兩種不同的情況：

①有效等價類：是對于程序規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。

②無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。第68頁，共165頁，2023年，2月20日，星期六劃分等價類的原則：如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。如，在程序規(guī)格說明中對輸入條件有一句話：

“……項數(shù)可以從1到999……”

則有效等價類是“1≤項數(shù)≤999”

兩個無效等價類是“項數(shù)＜1”或“項數(shù)＞999”。第69頁，共165頁，2023年，2月20日，星期六在數(shù)軸上表示成:如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如，在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構(gòu)成有效等價類，而不在此集合內(nèi)（不以字母打頭）的歸于無效等價類。無效等價類有效等價類無效等價類1999第70頁，共165頁，2023年，2月20日，星期六如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應(yīng)的處理。第71頁，共165頁，2023年，2月20日，星期六

因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。

例如，Pascal語言規(guī)定“一個語句必須以分號‘;’結(jié)束”。這時可以確定一個有效等價類“以‘;’結(jié)束”，若干個無效等價類“以‘:’結(jié)束”、“以‘,’結(jié)束”、“以‘’結(jié)束”、“以LF結(jié)束”第72頁，共165頁，2023年，2月20日，星期六將程序的輸入按數(shù)據(jù)類劃分，根據(jù)數(shù)據(jù)類設(shè)計等價類的測試案例?輸入是指定范圍----定義一個等價的有效輸入范圍定義兩個等價的無效輸入范圍?輸入是特定值-----定義一個等價的有效輸入值定義兩個等價的無效輸入值 ?輸入是某集合的元素---定義一個等價的有效輸入元素定義一個等價的無效輸入元素?輸入是布爾值----定義一個等價的有效輸入布爾值定義一個等價的無效輸入布爾值總結(jié)：第73頁，共165頁，2023年，2月20日，星期六第二步：確立測試用例

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。輸入條件有效等價類無效等價類………………………………………………………………再從劃分出的等價類中按以下原則選擇測試用例：第74頁，共165頁，2023年，2月20日，星期六為每一個等價類規(guī)定一個唯一編號；設(shè)計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復(fù)這一步，直到所有的有效等價類都被覆蓋為止；設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復(fù)這一步，直到所有的無效等價類都被覆蓋為止。第75頁，共165頁，2023年，2月20日，星期六

用等價類劃分法設(shè)計測試用例的實例在某一PASCAL語言版本中規(guī)定：“標識符是由字母開頭，后跟字母或數(shù)字的任意組合構(gòu)成。有效字符數(shù)為8個，最大字符數(shù)為80個。”并且規(guī)定：“標識符必須先說明，再使用?！薄霸谕徽f明語句中，標識符至少必須有一個?！?/p>

第76頁，共165頁，2023年，2月20日，星期六用等價類劃分方法，建立輸入等價類表:輸入條件有效等價類無效等價類說明語句中標識符個數(shù)1個(1),多個(2)0個(3)標識符中字符數(shù)1~8個(4)0個(5),>8個(6),>80個(7)標識符組成字母(8),數(shù)字(9)非字母數(shù)字字符(10),保留字(11)標識符第一個字符字母(12)非字母(13)標識符使用先說明后使用(14)未說明就使用(15)第77頁，共165頁，2023年，2月20日，星期六下面選取了9個測試用例，它們覆蓋了所有的等價類。①VARx，T1234567：REAL；

BEGINx:=3.414；

T1234567:=2.732；

...…

(1),(2),(4),(8),(9),(12),(14)

②VAR：REAL；

(3)

③VARx，：REAL;

(5)

④VART12345678：REAL；

(6)第78頁，共165頁，2023年，2月20日，星期六⑤VART12345......：REAL；

(7)

多于80個字符⑥VART$：CHAR；

(10)⑦VARGOTO：INTEGER；

(11)⑧VAR2T：REAL；

(13)⑨VARPAR：REAL；

(15)

BEGIN......

PAP:=SIN(3.14*0.8)/6；第79頁，共165頁，2023年，2月20日，星期六例:某報表處理系統(tǒng)要求用戶輸入處理報表的日期，日期限制在2003年1月至2008年12月，即系統(tǒng)只能對該段期間內(nèi)的報表進行處理，如日期不在此范圍內(nèi)，則顯示輸入錯誤信息。系統(tǒng)日期規(guī)定由年、月的6位數(shù)字字符組成，前四位代表年，后兩位代表月。

如何用等價類劃分法設(shè)計測試用例,

來測試程序的日期檢查功能？第80頁，共165頁，2023年，2月20日，星期六第一步：等價類劃分輸入條件有效等價類無效等價類

報表日期的類型及長度6位數(shù)字字符(1)有非數(shù)字字符

(4)少于6個數(shù)字字符

(5)多于6個數(shù)字字符

(6)年份范圍在2003～2008之間

(2)小于2003

(7)大于2008

(8)月份范圍在1～12之間(3)“報表日期”輸入條件的等價類表小于1

(9)大于12

(10)第81頁，共165頁，2023年，2月20日，星期六第二步：為有效等價類設(shè)計測試用例

測試數(shù)據(jù)期望結(jié)果覆蓋范圍200306等價類(1)(2)(3)輸入有效對表中編號為1,2,3的3個有效等價類用一個測試用例覆蓋：第82頁，共165頁，2023年，2月20日，星期六第三步：為每一個無效等價類設(shè)計至少一個測試用例

測試數(shù)據(jù)期望結(jié)果覆蓋范圍003MAY等價類(4)輸入無效20035等價類(5)輸入無效2003005等價類(6)輸入無效200105等價類(7)輸入無效200905等價類(8)輸入無效200300等價類(9)輸入無效200313等價類(10)輸入無效不能出現(xiàn)相同的測試用例本例的10個等價類至少需要8個測試用例第83頁，共165頁，2023年，2月20日，星期六例:對招干考試系統(tǒng)“輸入學生成績”子模塊設(shè)計測試用例招干考試分三個專業(yè),準考證號第一位為專業(yè)代號,如:1-行政專業(yè),2-法律專業(yè),3-財經(jīng)專業(yè).

行政專業(yè)準考證號碼為:110001～111215法律專業(yè)準考證號碼為:210001～212006財經(jīng)專業(yè)準考證號碼為:310001～314015第84頁，共165頁，2023年，2月20日，星期六例:準考證號碼的等價類劃分有效等價類:

(1)110001～111215(2)210001～212006(3)310001～314015

無效等價類:

(4)-

～110000(5)111216～210000(6)212007～31000(7)314016～+第85頁，共165頁，2023年，2月20日，星期六2.邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。

第86頁，共165頁，2023年，2月20日，星期六如果在懸崖峭壁邊可以自信地安全行走，平地就不在話下。如果軟件在能力達到極限時能夠運行，那么在正常情況下就不會出什么問題。軟件邊界與懸崖很類似第87頁，共165頁，2023年，2月20日，星期六邊界值分析法與等價類劃分法區(qū)別(1)邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。(2)邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況被測試子域測試內(nèi)點測試外點第88頁，共165頁，2023年，2月20日，星期六

A、先劃分等價類，劃分等價類的方法與等價分類法基本相同，不同的是在劃分等價類時，不僅要考慮輸入條件，還要考慮輸出條件。

B、選擇測試用例，測試等價類邊界。往往對同一邊界需要選擇一個或者多個測試用例。邊值分析法分析步驟：第89頁，共165頁，2023年，2月20日，星期六按照輸入值范圍的邊界。例如：輸入值的范圍是-1.0至1.0，則可選擇用例–1.0、1.0、-1.001、1.001。按照輸入/輸出值個數(shù)的邊界。例如：輸入文件可有1-255個記錄，則設(shè)計用例：文件的記錄數(shù)為0個、1個、255個、256個。輸出值域的邊界。例如：檢索文獻摘要，最多4篇。設(shè)計用例：可檢索0篇、1篇、4篇，和5篇（錯誤）。輸入/輸出有序集（如順序文件、線性表）的邊界。應(yīng)選擇第一個元素和最后一個元素。邊值分析法邊界選擇原則：第90頁，共165頁，2023年，2月20日，星期六輸入條件報表日期的類型及長度1個數(shù)字字符5個數(shù)字字符7個數(shù)字字符有1個非數(shù)字字符全部是非數(shù)字字符6個數(shù)字字符顯示出錯顯示出錯顯示出錯顯示出錯顯示出錯輸入有效日期范圍月份范圍“報表日期”邊界值分析法測試用例測試用例說明測試數(shù)據(jù)期望結(jié)果選取理由52003520030052003.5MAY---200305月份為1月月份為12月月份<1月份>12200301200312200300200313200301200812200300200813輸入有效輸入有效顯示出錯顯示出錯輸入有效輸入有效顯示出錯顯示出錯在有效范圍邊界上選取數(shù)據(jù)僅有1個合法字符比有效長度少1比有效長度多1只有1個非法字符6個非法字符類型及長度均有效最小日期最大日期剛好小于最小日期剛好大于最大日期最小月份最大月份剛好小于最小月份剛好大于最大月份第91頁，共165頁，2023年，2月20日，星期六3.錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。第92頁，共165頁，2023年，2月20日，星期六

錯誤推測法是一種簡單易行的黑盒法，但由于該方法有較大的隨意性，主要依賴于測試者的經(jīng)驗，因此通常作為一種輔助的黑盒測試方法。例1對一個排序的程序，可能出錯的情況有：

1、輸入表為空的情況。

2、輸入表中只有一個一行。

3、輸入表中所有的行都具有相同的值。

4、輸入表已經(jīng)排好序。錯誤推測法第93頁，共165頁，2023年，2月20日，星期六4、使用各種測試方法的綜合策略在任何情況下都必須使用邊界值分析法。用這種方法設(shè)計出測試用例發(fā)現(xiàn)程序錯誤的能力最強。必要時用等價類劃分法補充一些測試用例。用錯誤推測法再追加一些測試用例。對照程序邏輯，檢查已有測試用例的邏輯覆蓋程度。如果未達到要求的覆蓋標準，應(yīng)再補充足夠的測試用例。如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。第94頁，共165頁，2023年，2月20日，星期六8.3.3軟件測試的策略測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試。開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。集成測試把已測試過的模塊組裝起來，主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。第95頁，共165頁，2023年，2月20日，星期六被測模塊單元測試集成測試被測模塊單元測試被測模塊單元測試確認測試系統(tǒng)測試系統(tǒng)其他元素軟件需求設(shè)計信息已集成的軟件已確認的軟件可交付的軟件已經(jīng)過測試的模塊第96頁，共165頁，2023年，2月20日，星期六確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其他系統(tǒng)成份組合在一起進行測試。第97頁，共165頁，2023年，2月20日，星期六一.單元測試(UnitTesting)單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。第98頁，共165頁，2023年，2月20日，星期六1)單元測試的內(nèi)容在單元測試時，測試者需要依據(jù)詳細設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。

第99頁，共165頁，2023年，2月20日，星期六模塊出錯處理獨立路徑模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件第100頁，共165頁，2023年，2月20日，星期六2)單元測試的步驟模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其他模塊。

驅(qū)動模塊(driver)

樁模塊(stub)──存根模塊第101頁，共165頁，2023年，2月20日，星期六被測模塊驅(qū)動模塊樁模塊樁模塊樁模塊測試用例測試用例第102頁，共165頁，2023年，2月20日，星期六如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。第103頁，共165頁，2023年，2月20日，星期六二.集成測試（IntegratedTesting）集成測試(即組裝測試、聯(lián)合測試）通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是：在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失；一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；全局數(shù)據(jù)結(jié)構(gòu)是否有問題；第104頁，共165頁，2023年，2月20日，星期六

各個子功能組合起來，能否達到預(yù)期要求的父功能；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。在單元測試的同時可進行集成測試,發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題，最終構(gòu)成要求的軟件系統(tǒng)。子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。第105頁，共165頁，2023年，2月20日，星期六

通常，把模塊組裝成為系統(tǒng)的方式有兩種:

一次性集成方式增量式集成方式1)一次性集成方式(bigbang)它是一種非增量式集成方式。也叫做整體拼裝。使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊集成在一起進行測試，最終得到要求的軟件系統(tǒng)。第106頁，共165頁，2023年，2月20日，星期六ACDBEFd1Bs1d2Ds2d3Cd4Ed5FAs4s5s3ACDBEF原來結(jié)構(gòu)分模塊測試一次性集成第107頁，共165頁，2023年，2月20日，星期六2)增量式集成方式這種集成方式又稱漸增式組裝。首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)在組裝的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題通過增量逐步加入，組裝成為要求的軟件系統(tǒng)。

第108頁，共165頁，2023年，2月20日，星期六(1)自頂向下的增量方式這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。自頂向下的增量方式在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向集成的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。第109頁，共165頁，2023年，2月20日，星期六As2s3s1As2s3Bs4ACs3Bs4ACDBs4s5ACDBEs5ACDBEF第110頁，共165頁，2023年，2月20日，星期六(2)自底向上的增量方式這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。

第111頁，共165頁，2023年，2月20日，星期六自頂向下增量的方式和自底向上增量的方式各有優(yōu)缺點。一般來講，一種方式的優(yōu)點是另一種方式的缺點。d4BEd2DFd1Ed2Cd3FACDBEF第112頁，共165頁，2023年，2月20日，星期六(3)混合增量式測試衍變的自頂向下的增量測試首先對輸入／輸出模塊和引入新算法模塊進行測試;再自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng);然后由主模塊開始自頂向下進行增量測試。第113頁，共165頁，2023年，2月20日，星期六自底向上自頂向下的增量測試首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行集成和測試;然后對含寫操作的子系統(tǒng)做自頂向下的集成與測試?；貧w測試這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;然后將這一部分視為子系統(tǒng)，再自底向上測試。第114頁，共165頁，2023年，2月20日，星期六關(guān)鍵模塊問題在集成測試時，應(yīng)當確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。關(guān)鍵模塊的特征：滿足某些軟件需求；在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；較復(fù)雜、較易發(fā)生錯誤；有明確定義的性能要求。第115頁，共165頁，2023年，2月20日，星期六三.確認測試（ValidationTesting）確認測試又稱有效性測試。任務(wù)是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎(chǔ)。第116頁，共165頁，2023年，2月20日，星期六選擇測試人員構(gòu)造測試用例實際運行測試軟件計劃用戶文檔開發(fā)文檔源程序文本支持環(huán)境軟件配置審查有效性測試管理機構(gòu)裁決軟件配置測試報告專家鑒定會交付用戶運行維護第117頁，共165頁，2023年，2月20日，星期六1)進行有效性測試（黑盒測試）有效性測試是在模擬的環(huán)境(可能就是開發(fā)的環(huán)境)下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。通過實施預(yù)定的測試計劃和測試步驟，確定軟件的特性是否與需求相符；所有的文檔都是正確且便于使用；第118頁，共165頁，2023年，2月20日，星期六同時，對其他軟件需求，例如可移植性、兼容性、出錯自動恢復(fù)、可維護性等，也都要進行測試在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：

測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。

測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。第119頁，共165頁，2023年，2月20日，星期六2)軟件配置復(fù)查軟件配置復(fù)查的目的是保證軟件配置的所有成分都齊全；各方面的質(zhì)量都符合要求；具有維護階段所必需的細節(jié)；而且已經(jīng)編排好分類的目錄。應(yīng)當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。第120頁，共165頁，2023年，2月20日，星期六3)驗收測試（AcceptanceTesting）在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗收測試。驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。第121頁，共165頁，2023年，2月20日，星期六在測試過程中，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性、兼容性、可維護性、錯誤的恢復(fù)功能等進行確認。確認測試應(yīng)交付的文檔有：確認測試分析報告最終的用戶手冊和操作手冊項目開發(fā)總結(jié)報告

第122頁，共165頁，2023年，2月20日，星期六四.系統(tǒng)測試（SystemTesting）系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較,發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。第123頁，共165頁，2023年，2月20日，星期六α測試和β測試在軟件交付使用后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預(yù)測的。α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。α測試的目的是評價軟件產(chǎn)品的FURPS（即功能、可使用性、可靠性、性能和支持）。尤其注重產(chǎn)品的界面和特色。第124頁，共165頁，2023年，2月20日，星期六α測試可以從軟件產(chǎn)品編碼結(jié)束之時開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認測試過程中產(chǎn)品達到一定的穩(wěn)定和可靠程度之后再開始。β測試是由軟件的多個用戶在實際使用環(huán)境下進行的測試。這些用戶返回有關(guān)錯誤信息給開發(fā)者。測試時，開發(fā)者通常不在測試現(xiàn)場。因而，β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應(yīng)用。第125頁，共165頁，2023年，2月20日，星期六在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發(fā)者報告。

β測試主要衡量產(chǎn)品的FURPS。著重于產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。只有當α測試達到一定的可靠程度時，才能開始β測試。它處在整個測試的最后階段。同時，產(chǎn)品的所有手冊文本也應(yīng)該在此階段完全定稿。第126頁，共165頁，2023年，2月20日，星期六8.3.4調(diào)試（Debug）軟件調(diào)試是在進行了成功的測試之后才開始的工作。它與軟件測試不同，調(diào)試的任務(wù)是進一步診斷和改正程序中潛在的錯誤。調(diào)試活動由兩部分組成：確定程序中可疑錯誤的確切性質(zhì)和位置。對程序(設(shè)計,編碼)進行修改，排除這個錯誤。調(diào)試工作是一個具有很強技巧性的工作。第127頁，共165頁，2023年，2月20日，星期六軟件運行失效或出現(xiàn)問題，往往只是潛在錯誤的外部表現(xiàn)，而外部表現(xiàn)與內(nèi)在原因之間常常沒有明顯的聯(lián)系。如果要找出真正的原因，排除潛在的錯誤，不是一件易事?？梢哉f，調(diào)試是通過現(xiàn)象，找出原因的一個思維分析的過程。第128頁，共165頁，2023年，2月20日，星期六1.

調(diào)試的步驟從錯誤的外部表現(xiàn)形式入手，確定程序中出錯位置；研究有關(guān)部分的程序，找出錯誤的內(nèi)在原因；修改設(shè)計和代碼，以排除這個錯誤；重復(fù)進行暴露了這個錯誤的原始測試或某些有關(guān)測試。

第129頁，共165頁，2023年，2月20日，星期六從技術(shù)角度來看，查找錯誤的難度在于：現(xiàn)象與原因所處的位置可能相距甚遠。當其他錯誤得到糾正時,這一錯誤所表現(xiàn)出的現(xiàn)象可能會暫時消失，但并未實際排除?，F(xiàn)象實際上是由一些非錯誤原因(例如，舍入不精確)引起的?，F(xiàn)象可能是由于一些不容易發(fā)現(xiàn)的人為錯誤引起的。錯誤是由于時序問題引起的，與處理過程無關(guān)。第130頁，共165頁，2023年，2月20日，星期六現(xiàn)象是由于難于精確再現(xiàn)的輸入狀態(tài)（例如，實時應(yīng)用中輸入順序不確定）引起?，F(xiàn)象可能是周期出現(xiàn)的。在軟、硬件結(jié)合的嵌入式系統(tǒng)中常常遇到。第131頁，共165頁，2023年，2月20日，星期六8.5.1幾個名稱項目與產(chǎn)品轉(zhuǎn)換與發(fā)布客戶化與初始化8.5系統(tǒng)轉(zhuǎn)換第132頁，共165頁，2023年，2月20日，星期六8.5.2轉(zhuǎn)換方式1.直接轉(zhuǎn)換2.并行轉(zhuǎn)換3.分段轉(zhuǎn)換老系統(tǒng)新系統(tǒng)并行運行時間時間老系統(tǒng)新系統(tǒng)轉(zhuǎn)換點時間老系統(tǒng)新系統(tǒng)轉(zhuǎn)換過渡時間時間第133頁，共165頁，2023年，2月20日，星期六8.5.3系統(tǒng)轉(zhuǎn)換注意的問題新系統(tǒng)的投入運行運行需要大量的基礎(chǔ)數(shù)據(jù)，這些數(shù)據(jù)的整理與錄入工作量大，應(yīng)及時準備。系統(tǒng)轉(zhuǎn)換不僅是機器的轉(zhuǎn)換、程序的轉(zhuǎn)換，更重要的是人們工作方式的轉(zhuǎn)換，要提前做好人員的培訓(xùn)。系統(tǒng)運行時會出現(xiàn)一些局部性的問題，這是正常的現(xiàn)象，應(yīng)做好記錄并及時解決。第134頁，共165頁，2023年，2月20日，星期六8.6系統(tǒng)維護系統(tǒng)維護是指系統(tǒng)交付使用以后，為了改正錯誤或滿足新的需求而修改系統(tǒng)的過程。5.6.1系統(tǒng)維護的目的對系統(tǒng)進行維護的目的是為了糾正系統(tǒng)開發(fā)過程未發(fā)現(xiàn)的錯誤，增強、改進和完善系統(tǒng)的功能和性能，以適應(yīng)系統(tǒng)的發(fā)展，延長系統(tǒng)的壽命。第135頁，共165頁，2023年，2月20日，星期六遺留系統(tǒng)危機百分比20世紀70年代早期20世紀80年代早期20世紀80年代晚期20世紀90年代早期專用于系統(tǒng)演化的系統(tǒng)成本成本第136頁，共165頁，2023年，2月20日，星期六遺留系統(tǒng)更換遺留系統(tǒng)是有風險的業(yè)務(wù)策略，因為：遺留系統(tǒng)幾乎沒有完整的描述業(yè)務(wù)過程與遺留系統(tǒng)的操作方式緊密相關(guān)重要的業(yè)務(wù)規(guī)則隱藏在系統(tǒng)內(nèi)部開發(fā)新系統(tǒng)有風險繼續(xù)使用遺留系統(tǒng)，進行變更費用更高，因為：系統(tǒng)是由不同團隊實現(xiàn)的，程序設(shè)計風格不一致系統(tǒng)使用過時的語言編寫系統(tǒng)文檔不充分、過時經(jīng)多年維護，系統(tǒng)結(jié)構(gòu)已破壞系統(tǒng)進行過優(yōu)化，不可讀系統(tǒng)數(shù)據(jù)過時、不完整第137頁，共165頁，2023年，2月20日，星期六演化遺留系統(tǒng)信息系統(tǒng)生命周期時間功能業(yè)務(wù)需求構(gòu)建系統(tǒng)維護現(xiàn)代化改造第二個維護期第二個系統(tǒng)的維護系統(tǒng)替換系統(tǒng)1系統(tǒng)2第138頁，共165頁，2023年，2月20日，星期六8.6.2系統(tǒng)維護的類型完善性維護（PerfectiveMaintenance）糾錯性維護（CorrectiveMaintenance）適應(yīng)性維護（AdaptiveMaintenance）預(yù)防性維護（PreventiveMaintenance）一、按照不同的維護目的，維護工作可分成4類。第139頁，共165頁，2023年，2月20日，星期六序號維護的種類維護的內(nèi)容1糾錯性維護產(chǎn)品或項目中存在缺陷或錯誤，在測試和驗收時未發(fā)現(xiàn)，到了使用過程中逐漸暴露出來，需要改正2適應(yīng)性維護這類維護是為了產(chǎn)品或項目適應(yīng)變化了的硬件、系統(tǒng)軟件的運行環(huán)境，如系統(tǒng)升級3完善性維護這類維護是為了給軟件系統(tǒng)增加一些新的功能，使產(chǎn)品或項目的功能更加完善與合理，又不致于對系統(tǒng)進行傷筋動骨的改造，這類維護占維護活動的大多數(shù)情況4預(yù)防性維護這類維護是為了提高產(chǎn)品或項目的可靠性和可維性，有利于系統(tǒng)的進一步改造或升級換代第140頁，共165頁，2023年，2月20日，星期六維護在系統(tǒng)生

存期所占比例維護工作量70%開發(fā)工作量30%適應(yīng)性維護25%改正性維護20%完善性維護50%其他維護5%三類維護占總維護比例第141頁，共165頁，2023年，2月20日，星期六8.6.3系統(tǒng)的可維護性所謂系統(tǒng)的可維護性，就是維護人員理解、掌握和修改被維護軟件的難易程度。可維護性的系統(tǒng)，它應(yīng)具備下列四條性質(zhì)：

(1).可理解性。

(2).可測試性。

(3).可修改性。

(4).可移植性。第142頁，共165頁，2023年，2月20日，星期六系統(tǒng)的可維護性序號名稱可維護性內(nèi)容1可理解性軟件模塊化、結(jié)構(gòu)化，代碼風格化，文檔清晰化2可測試性文檔規(guī)范化，代碼注釋化，測試回歸化3可修改性模塊間低耦合，高內(nèi)聚，程序塊的單入口和單出口，數(shù)據(jù)局部化，公用模塊組件化4可移植性例如用ODBC、ADO來屏蔽對數(shù)據(jù)庫管理系統(tǒng)的依賴，用三層結(jié)構(gòu)來簡化對客戶瀏覽層的維護第143頁，共165頁，2023年，2月20日，星期六8.6.4維護的副作用(四個副作用)序號維護的方式副作用的表現(xiàn)1修改編碼使編碼更加混亂，程序結(jié)構(gòu)更不清晰，可讀性更差，而且有連鎖反映2修改數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu)是系統(tǒng)的骨架，修改數(shù)據(jù)結(jié)構(gòu)是對系統(tǒng)傷筋動骨的大手術(shù)，在數(shù)據(jù)冗余與數(shù)據(jù)不一致方面，可能顧此失彼3修改用戶數(shù)據(jù)需要與用戶協(xié)商，一旦有疏忽，可使系統(tǒng)發(fā)生意外4修改文檔對非結(jié)構(gòu)化維護不適應(yīng)，對結(jié)構(gòu)化維護要嚴防程序與文檔的不配匹第144頁，共165頁，2023年，2月20日，星期六維護的副作用

(1).很容易出現(xiàn)打補丁的現(xiàn)象；

(2).可能在維護中出現(xiàn)連鎖反映現(xiàn)象。為了減少維護的工作量，防止維護的副作用，人們在長期的實踐中積累了如下的經(jīng)驗：

(1).用CMMI體系來改善軟件企業(yè)的軟件過程管理；

(2).在開發(fā)和維護中，盡量使用CASE工具；

(3).維護完成后，一定要進行回歸測試。第145頁，共165頁，2023年，2月20日，星期六8.6.5維護中的典型問題(1)難以跟蹤軟件版本的進化過程,軟件的變化未在文檔中反映出來.(2)難以跟蹤軟件的創(chuàng)建過程.(3)難以讀懂他人程序.(4)無文檔或不全.(5)軟件人員流動性大.(6)設(shè)計時未考慮修改需要,修改困難.(7)維護工作無吸引力,缺乏成就感.第146頁，共165頁，2023年，2月20日，星期六8.7信息系統(tǒng)的監(jiān)理和評估8.7.1信息系統(tǒng)監(jiān)理1.信息系統(tǒng)監(jiān)理的含義信息系統(tǒng)監(jiān)理，是指具備相應(yīng)資質(zhì)的第三方，根據(jù)信息系統(tǒng)的開發(fā)規(guī)律以及國家法律法規(guī)、開發(fā)合同和監(jiān)理合同的要求，對信息系統(tǒng)開發(fā)過程中的行為、事件和文檔進行審查和監(jiān)督，為用戶方提供與項目有關(guān)的信息和信息處理能力的支持，以確保信息系統(tǒng)建設(shè)成功。工信部《信息系統(tǒng)工程監(jiān)理暫行規(guī)定》第147頁，共165頁，2023年，2月20日，星期六8.7信息系統(tǒng)的監(jiān)理和評估8.7.1信息系統(tǒng)監(jiān)理2.信息系統(tǒng)監(jiān)理的模式咨詢式里程碑式監(jiān)理全程式監(jiān)理第148頁，共165頁，2023年，2月20日，星期六8.7信息系統(tǒng)的監(jiān)理和評估8.7.1信息系統(tǒng)監(jiān)理3.信息系統(tǒng)監(jiān)理的內(nèi)容協(xié)助用戶組織信息系統(tǒng)建設(shè)的招標、評標協(xié)助用戶與中標單位簽訂合同監(jiān)督管理開發(fā)合同的履行根據(jù)監(jiān)理合同的要求，為用戶提供技術(shù)服務(wù)監(jiān)理合同終止后，向用戶提供監(jiān)理工作報告。第149頁，共165頁，2023年，2月20日，星期六8.7信息系統(tǒng)的監(jiān)理和評估8.7.1信息系統(tǒng)監(jiān)理4.信息系統(tǒng)監(jiān)理的程序和計劃組建監(jiān)理機構(gòu)編制監(jiān)理計劃實施監(jiān)理參與工程驗收并簽署監(jiān)理