系統(tǒng)實現(xiàn)與維護

系統(tǒng)實現(xiàn)與維護2023/3/13第7章系統(tǒng)實現(xiàn)與維護2緒言系統(tǒng)設計完成后進入系統(tǒng)實施階段。系統(tǒng)實施就是將系統(tǒng)分析和設計的結(jié)果轉(zhuǎn)換為能夠在計算機上實際運行的系統(tǒng)的過程，屬于系統(tǒng)開發(fā)周期的后期階段。本章的主要內(nèi)容有：系統(tǒng)實施的任務、特點和方法；程序設計的原則、標準和方法；軟件開發(fā)工具；系統(tǒng)測試的原則、內(nèi)容和方法；系統(tǒng)轉(zhuǎn)換的主要方式和工作等。2023/3/13第7章系統(tǒng)實現(xiàn)與維護37.1系統(tǒng)實施的任務系統(tǒng)實施的任務就是以系統(tǒng)設計方案為依據(jù)，按照系統(tǒng)實施方案進行具體的實現(xiàn)，最終組建一個能夠?qū)嶋H運行的系統(tǒng)交付用戶使用。實現(xiàn)階段的任務和工作內(nèi)容包括以下4個方面：硬件準備；軟件準備人員培訓；數(shù)據(jù)準備。2023/3/13第7章系統(tǒng)實現(xiàn)與維護47.1系統(tǒng)實施的任務系統(tǒng)實施的特點系統(tǒng)實施是管理信息系統(tǒng)開發(fā)工作的后期階段，是一項涉及各級管理人員、系統(tǒng)開發(fā)技術(shù)人員、系統(tǒng)測試人員、系統(tǒng)操作和維護人員的組織協(xié)調(diào)，以及系統(tǒng)應用場地、設備和資金的調(diào)配管理，持續(xù)時間長且十分復雜的系統(tǒng)工程。工作量大，投入的人力、物力多，組織管理工作繁重是其主要特點。2023/3/13第7章系統(tǒng)實現(xiàn)與維護57.2程序設計語言分類按應用特點分類面向機器語言（機器語言和匯編語言）高級語言基礎語言（BASIC、Fortran）現(xiàn)代語言（Pascal、C、C++）專用語言（Lisp、Prolog）按語言內(nèi)在特點分類系統(tǒng)實現(xiàn)語言靜態(tài)高級語言塊結(jié)構(gòu)高級語言動態(tài)高級語言2023/3/13第7章系統(tǒng)實現(xiàn)與維護67.3程序設計語言的選擇

理想標準應該有理想的模塊化機制，以及可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，以使程序容易測試和維護，同時減少軟件生存周期的總成本。應有良好的獨立編譯機制，以降低軟件開發(fā)和維護的成本。應該使編譯程序能夠盡可能多地發(fā)現(xiàn)程序中的錯誤，以便于調(diào)試和提高軟件的可靠性。2023/3/13第7章系統(tǒng)實現(xiàn)與維護77.3程序設計語言的選擇實踐標準語言自身的功能系統(tǒng)用戶的要求編碼和維護成本軟件的兼容性可以使用的軟件工具軟件的可移植性開發(fā)系統(tǒng)的規(guī)模程序設計人員的水平2023/3/13第7章系統(tǒng)實現(xiàn)與維護87.4程序設計風格編碼階段的任務是把詳細設計階段中用偽代碼寫成的程序轉(zhuǎn)換成用程序設計語言實現(xiàn)的程序。程序設計語言的特性和程序設計風格會深刻地影響軟件的質(zhì)量和可維護性。為保證編碼的質(zhì)量，程序員必須深刻理解、熟練掌握并正確地運用程序設計語言的特性。此外，還要求源程序具有良好的結(jié)構(gòu)性和良好的程序設計風格。2023/3/13第7章系統(tǒng)實現(xiàn)與維護97.4程序設計風格好程序的代碼邏輯簡明清晰、易讀易懂：程序的內(nèi)部文檔；數(shù)據(jù)說明；語句構(gòu)造；輸入／輸出方法；2023/3/13第7章系統(tǒng)實現(xiàn)與維護107.4程序設計風格程序的內(nèi)部文檔標識符的命名：標識符即符號名，包括模塊名、變量名、常量名、標號名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。這些名字應能反映它所代表的實際東西，應有一定實際意義。名字不是越長越好，應當選擇精煉的意義明確的名字。必要時可使用縮寫名字，但這時要注意縮寫規(guī)則要一致，并且要給每一個名字加注釋。在一個程序中，一個變量只應用于一種用途。2023/3/13第7章系統(tǒng)實現(xiàn)與維護117.4程序設計風格程序的內(nèi)部文檔C#、Java等語言編碼命名規(guī)范對字段、變量、類、方法和屬性等指定了統(tǒng)一的命名形式：類名、方法名和屬性名均使用Pascal命名法，即所有單詞連寫，每個單詞的第一個字母大寫，其它字母小寫。例如：GetData、HelloWorld等。變量名、對象名以及方法的參數(shù)名均使用Camel命名法，即所有單詞連寫，第一個單詞全部小寫，其它每個單詞的第一個字母大寫。例如：userName、userAge等等。2023/3/13第7章系統(tǒng)實現(xiàn)與維護127.4程序設計風格這里需要強調(diào)一點，對于一名合格的程序員來說，不論是練習還是實際開發(fā)，一定不要養(yǎng)成隨意命名的壞習慣。良好的命名習慣會給項目開發(fā)帶來很多益處。2023/3/13第7章系統(tǒng)實現(xiàn)與維護137.4程序設計風格程序的內(nèi)部文檔程序的注釋：夾在程序中的注釋是程序員與日后的程序讀者之間通信的重要手段。注釋決不是可有可無的。一些正規(guī)的程序文本中，注釋行的數(shù)量占到整個源程序的1／3到1／2，甚至更多。注釋分為序言性注釋和功能性注釋。2023/3/13第7章系統(tǒng)實現(xiàn)與維護147.4程序設計風格序言性注釋：通常置于每個程序模塊的開頭部分，它應當給出程序的整體說明，對于理解程序本身具有引導作用。有些軟件開發(fā)部門對序言性注釋做了明確而嚴格的規(guī)定，要求程序編制者逐項列出。2023/3/13第7章系統(tǒng)實現(xiàn)與維護157.4程序設計風格序言性注釋有關項目包括：程序標題；有關本模塊功能和目的的說明；主要算法；接口說明：包括調(diào)用形式，參數(shù)描述，子程序清單；有關數(shù)據(jù)描述：重要的變量及其用途，約束或限制條件，以及其它有關信息；模塊位置：在哪一個源文件中，或隸屬于哪一個軟件包；開發(fā)簡歷：模塊設計者，復審者，復審日期，修改日期及有關說明等。2023/3/13第7章系統(tǒng)實現(xiàn)與維護167.4程序設計風格功能性注釋：功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執(zhí)行了下面的語句而會怎么樣。而不要解釋下面怎么做。2023/3/13第7章系統(tǒng)實現(xiàn)與維護177.4程序設計風格程序的內(nèi)部文檔：視覺組織空格、空行和縮進。恰當?shù)乩每崭?，可以突出運算的優(yōu)先性。自然的程序段之間可用空行隔開。縮進也叫做向右縮格或移行。它是指程序中的各行不必都在左端對齊，都從第一格起排列。這樣做使程序完全分不清層次關系。對于選擇語句和循環(huán)語句，把其中的程序段語句向右做階梯式移行。使程序的邏輯結(jié)構(gòu)更加清晰。2023/3/13第7章系統(tǒng)實現(xiàn)與維護187.4程序設計風格數(shù)據(jù)說明在設計階段已經(jīng)確定了數(shù)據(jù)結(jié)構(gòu)的組織及其復雜性。在編寫程序時，則需要注意數(shù)據(jù)說明的風格。為了使程序中數(shù)據(jù)說明更易于理解和維護，必須注意以下幾點：數(shù)據(jù)說明的次序應當規(guī)范化；說明語句中變量安排有序化；使用注釋說明復雜數(shù)據(jù)結(jié)構(gòu)。2023/3/13第7章系統(tǒng)實現(xiàn)與維護197.4程序設計風格數(shù)據(jù)說明的次序應當規(guī)范化：數(shù)據(jù)說明次序規(guī)范化，使數(shù)據(jù)屬性容易查找，也有利于測試，排錯和維護。原則上，數(shù)據(jù)說明的次序與語法無關，其次序是任意的。但出于閱讀、理解和維護的需要，最好使其規(guī)范化，使說明的先后次序固定。例如，在類型說明中可按如下順序排列：①整型量說明②實型量說明③字符量說明④邏輯量說明2023/3/13第7章系統(tǒng)實現(xiàn)與維護207.4程序設計風格說明語句中變量安排有序化當多個變量名在一個說明語句中說明時，應當對這些變量按字母的順序排列。例如：把integersize,length,width,cost,price寫成integercost,length,price,size,width2023/3/13第7章系統(tǒng)實現(xiàn)與維護217.4程序設計風格使用注釋說明復雜數(shù)據(jù)結(jié)構(gòu)如果設計了一個復雜的數(shù)據(jù)結(jié)構(gòu)，應當使用注釋來說明在程序?qū)崿F(xiàn)時這個數(shù)據(jù)結(jié)構(gòu)的特點。2023/3/13第7章系統(tǒng)實現(xiàn)與維護227.4程序設計風格語句構(gòu)造在設計階段確定了軟件的邏輯流結(jié)構(gòu)，但構(gòu)造單個語句則是編碼階段的任務。語句構(gòu)造力求簡單、直接，不能為了片面追求效率而使語句復雜化。在一行內(nèi)只寫一條語句。避免采用過于復雜的條件測試。盡量減少“非”條件的測試。避免大量使用循環(huán)嵌套和條件嵌套。利用括號使邏輯表達式或算術(shù)表達式的運算次序清晰直觀。除非對效率有特殊的要求，程序編寫要做到清晰第一，效率第二。2023/3/13第7章系統(tǒng)實現(xiàn)與維護237.4程序設計風格語句構(gòu)造比較下面兩段代碼，哪一段更好？A[I]=A[I]＋A[T];A[T]=A[I]－A[T];A[I]=A[I]－A[T];WORK=A[T];A[T]=A[I];A[I]=WORK;2023/3/13第7章系統(tǒng)實現(xiàn)與維護247.4程序設計風格語句構(gòu)造程序要能直截了當?shù)卣f明程序員的用意。比較下面兩段代碼，哪一段更好？for(i=1;i<=n;i++)for(j=1;j<=n;j++)

V[i][j]=(i

／j)*(j／i)；for(i=1;i<=n;i++)for(j=1;j<=n;j++)if(i==j)V[i][j]=1;elseV[i][j]=0;

2023/3/13第7章系統(tǒng)實現(xiàn)與維護257.4程序設計風格語句構(gòu)造首先要保證程序正確,然后才要求提高速度。反過來說，在使程序高速運行時，首先要保證它是正確的。讓編譯程序做簡單的優(yōu)化。盡可能使用庫函數(shù)。避免使用臨時變量而使可讀性下降。避免不必要的轉(zhuǎn)移。同時如果能保持程序可讀性，則不必用GOTO語句。盡量只采用三種基本的控制結(jié)構(gòu)來編寫程序。避免使用空的ELSE語句和IF…

…THEN語句。這種結(jié)構(gòu)容易使讀者產(chǎn)生誤解?！叭绻也皇蔷幋a的人，那么能看懂它嗎？”2023/3/13第7章系統(tǒng)實現(xiàn)與維護267.4程序設計風格輸入與輸出關于輸入和輸出有下列的啟發(fā)規(guī)則：對所有的輸入數(shù)據(jù)都要進行檢驗，識別錯誤的輸入，以保證每個數(shù)據(jù)的有效性；檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態(tài)信息；使得輸入的步驟和操作盡可能簡單，并保持簡單的輸入格式；輸入數(shù)據(jù)時，應允許使用自由格式輸入；應允許缺省值；輸入一批數(shù)據(jù)時，最好使用輸入結(jié)束標志，而不要由用戶指定輸入數(shù)據(jù)數(shù)目；2023/3/13第7章系統(tǒng)實現(xiàn)與維護277.4程序設計風格輸入與輸出關于輸入和輸出有下列的啟發(fā)規(guī)則：在交互式輸入時，要在屏幕上使用提示符明確提示交互輸入的請求，指明可使用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結(jié)束時，也要在屏幕上給出狀態(tài)信息；當程序設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句要求的一致性；給所有的輸出加注解，并設計輸出報表格式。輸入／輸出風格還受到許多其它因素的影響。如輸入／輸出設備（例如終端的類型，圖形設備，數(shù)字化轉(zhuǎn)換設備等）、用戶的熟練程度以及通信環(huán)境等。2023/3/13第7章系統(tǒng)實現(xiàn)與維護287.4程序設計風格程序效率的準則效率是一個性能要求，目標值應當在需求分析階段給出，軟件效率應以需求為準。好的軟件設計可以提高效率。程序的效率與程序的簡單性相關。2023/3/13第7章系統(tǒng)實現(xiàn)與維護297.4程序設計風格算法對效率的影響盡可能簡化相關的表達式；仔細檢查算法中的嵌套循環(huán)，將某些語句移到循環(huán)外；盡量避免使用多維數(shù)組；盡量避免使用指針和復雜的表達式；采用“快速”的算術(shù)運算；不要混淆數(shù)據(jù)結(jié)構(gòu)，避免類型混雜；盡量采用整數(shù)算術(shù)表達式和布爾表達式；選用高效算法；2023/3/13第7章系統(tǒng)實現(xiàn)與維護307.5系統(tǒng)測試基礎軟件測試目的：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。2023/3/13第7章系統(tǒng)實現(xiàn)與維護317.5系統(tǒng)測試基礎軟件測試的準則：所有測試都應該能追溯到用戶需求。應該遠在測試開始之前就制定出測試計劃。把Pareto原理應用到軟件測試中。Pareto原理說明，測試發(fā)現(xiàn)的錯誤中的80％很可能是由程序中20％的模塊造成的。應該從“小規(guī)?！睖y試開始，并逐步進行“

“大規(guī)?！睖y試。窮舉測試是不可能的。為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。2023/3/13第7章系統(tǒng)實現(xiàn)與維護327.5系統(tǒng)測試基礎軟件測試步驟：模塊測試（單元測試）：把每個模塊作為一個單獨的實體來測試，發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。子系統(tǒng)測試（集成測試）：把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試，著重測試模塊的接口。系統(tǒng)測試（集成測試）：把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。2023/3/13第7章系統(tǒng)實現(xiàn)與維護337.5系統(tǒng)測試基礎軟件測試步驟：驗收測試（確認測試）：把軟件系統(tǒng)作為單一的實體進行測試，是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)（系統(tǒng)將來要處理的信息）進行測試。目的是驗證系統(tǒng)確實能夠滿足用戶的需要。發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。平行運行：是同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結(jié)果。這樣做的具體目的有如下幾點：可以在準生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風險；用戶能有一段熟悉新系統(tǒng)的時間；可以驗證用戶指南和使用手冊之類的文檔；能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，可以用測試結(jié)果驗證性能指標。2023/3/13第7章系統(tǒng)實現(xiàn)與維護347.5系統(tǒng)測試基礎2023/3/13第7章系統(tǒng)實現(xiàn)與維護357.5系統(tǒng)測試基礎測試階段的信息流程：軟件配置：軟件需求規(guī)格說明、軟件設計規(guī)格說明、源代碼等；測試配置：測試計劃、測試方案、測試數(shù)據(jù)等；測試結(jié)果分析：比較實測結(jié)果與預期結(jié)果，評價錯誤是否發(fā)生。排錯(調(diào)試)：對已經(jīng)發(fā)現(xiàn)的錯誤進行錯誤定位和確定出錯性質(zhì)，并改正這些錯誤，同時修改相關的文檔。2023/3/13第7章系統(tǒng)實現(xiàn)與維護367.6單元測試測試重點：模塊接口。主要檢查下述幾個方面：參數(shù)的數(shù)目、次序、屬性或單位系統(tǒng)與變元是否一致；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。局部數(shù)據(jù)結(jié)構(gòu)：發(fā)現(xiàn)局部數(shù)據(jù)說明、初始化、默認值等方面的錯誤。重要的執(zhí)行通路：選擇最有代表性、最可能發(fā)現(xiàn)錯誤的執(zhí)行通路進行測試。2023/3/13第7章系統(tǒng)實現(xiàn)與維護377.6單元測試測試重點：出錯處理通路。當評價出錯處理通路時，應該著重測試下述一些可能發(fā)生的錯誤：對錯誤的描述是難以理解的；記下的錯誤與實際遇到的錯誤不同；在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)干預；對錯誤的處理不正確；描述錯誤的信息不足以幫助確定造成錯誤的位置。2023/3/13第7章系統(tǒng)實現(xiàn)與維護387.6單元測試測試重點：邊界條件。軟件常常在它的邊界上失效。使用剛好小于、剛好等于和剛好大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制量和數(shù)據(jù)值的測試方案，非?？赡馨l(fā)現(xiàn)軟件中的錯誤。2023/3/13第7章系統(tǒng)實現(xiàn)與維護397.6單元測試代碼檢測由審查小組對源程序正式進行人工測試。審查之前，小組成員應該先研究設計說明書，力求理解這個設計。審查會上傾聽程序編寫者的解釋，并力圖發(fā)現(xiàn)其中的錯誤。對照類似于上一小節(jié)中介紹的程序設計常見錯誤清單，分析審查這個程序。預排：由一個人扮演“測試者”，其他人扮演“計算機”。2023/3/13第7章系統(tǒng)實現(xiàn)與維護407.7集成測試測試重點：恢復測試：通過各種方式強制地讓系統(tǒng)發(fā)生故障并驗證其能適當恢復的一種測試。（初始化、重啟、平均恢復時間等等）安全測試：驗證建立在系統(tǒng)內(nèi)的保護機制是否能夠?qū)嶋H保護系統(tǒng)不受非法入侵。壓力測試：以一種要求反常數(shù)量、頻率和容量的方式執(zhí)行系統(tǒng)。性能測試：常與壓力測試一起進行，需要軟件和硬件配合。2023/3/13第7章系統(tǒng)實現(xiàn)與維護417.7集成測試代表工具：OTF：由MCGSoftware開發(fā)QADirector：由CompuwareCrop開發(fā)TestWorks：由SoftwareResearch開發(fā)，包含完整的、集成的成套測試工具，包括測試管理和測試報告。C++Test：是一個單元測試工具，用于C或C++代碼測試。CodeMedic、BugColllectorPro、GNATS2023/3/13第7章系統(tǒng)實現(xiàn)與維護427.7集成測試集成測試是測試和組裝軟件的系統(tǒng)化技術(shù)。由模塊組裝成程序時有兩類方法：非漸增式測試：先分別測試每個模塊，再一下子把所有模塊按設計要求放在一起結(jié)合成所要的程序。漸增式測試：把下一個要測試的模塊同已測試好的那些模塊結(jié)合起來進行測試，依次類推，每次增加一個模塊。這種方法實質(zhì)上同時完成單元測試和集成測試。2023/3/13第7章系統(tǒng)實現(xiàn)與維護437.7集成測試非漸增式測試方法漸增式測試方法需要分別測試每個模塊，編寫的測試軟件（驅(qū)動模塊和支持模塊）較多，工作量較大；可利用已測試過的模塊最后才把模塊相連在一起，接口錯誤發(fā)現(xiàn)得晚?？梢暂^早發(fā)現(xiàn)模塊之間的接口錯誤一次組合所有模塊，如果發(fā)現(xiàn)錯誤難以判斷定位。如果發(fā)生錯誤則通常和最新加進來的模塊有關；可以并行測試所有模塊，能充分利用人力，加快工程進度。占用機時多，測試每個新加入模塊時，已經(jīng)測試完的模塊也都要一起運行。但測試更徹底2023/3/13第7章系統(tǒng)實現(xiàn)與維護447.7集成測試四種集成策略：一次性集成自頂向下集成自底向上集成三明治集成2023/3/13第7章系統(tǒng)實現(xiàn)與維護457.8確認測試確認測試目標是驗證軟件的有效性。軟件有效性的簡單定義：如果軟件的功能和性能如同用戶所合理期待的那樣，軟件就是有效的。因此，需求階段產(chǎn)生的需求規(guī)格說明書或類似文檔是軟件有效性的標準，也是進行確認測試的基礎。確認測試以用戶為主來進行。2023/3/13第7章系統(tǒng)實現(xiàn)與維護467.8確認測試確認測試的范圍保證軟件能滿足所有功能要求。能達到每個性能要求。文檔資料是準確而完整的。應該保證軟件能滿足其他預定的要求（例如，安全性、可移植性、兼容性和可維護性等）。2023/3/13第7章系統(tǒng)實現(xiàn)與維護477.8確認測試軟件配置復查復查的目的是保證軟件配置的所有成分都齊全，質(zhì)量符合要求，文檔與程序完全一致，具有完成軟件維護所必須的細節(jié)，而且已經(jīng)編好目錄。在確認測試過程中應該嚴格遵循用戶手冊及其他操作程序的說明和要求，從而檢驗用戶使用手冊的完整性和正確性。2023/3/13第7章系統(tǒng)實現(xiàn)與維護487.8確認測試Alpha和Beta測試Alpha測試由用戶在開發(fā)者的場所進行，并且在開發(fā)者對用戶的“指導”下進行測試。開發(fā)者負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題。總之，Alpha測試是在受控的環(huán)境中進行的。Beta測試由軟件的最終用戶們在一個或多個客戶場所進行。與Alpha測試不同，開發(fā)者通常不在測試的現(xiàn)場，因此，Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。2023/3/13第7章系統(tǒng)實現(xiàn)與維護497.9測試技術(shù)白盒測試：把測試對象看做一個透明盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關信息，設計或選擇測試用例，對程序的所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。黑盒測試：把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數(shù)據(jù)驅(qū)動測試。2023/3/13第7章系統(tǒng)實現(xiàn)與維護507.9.1白盒測試技術(shù)軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一次；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體；測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等；“錯誤潛伏在角落里，聚集在邊界上”2023/3/13第7章系統(tǒng)實現(xiàn)與維護517.9.1白盒測試技術(shù)邏輯覆蓋：邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎的設計測試用例的技術(shù)。語句覆蓋；判定覆蓋；條件覆蓋；判定/條件覆蓋；條件組合覆蓋；點覆蓋；邊覆蓋；路徑覆蓋；2023/3/13第7章系統(tǒng)實現(xiàn)與維護527.9.1白盒測試技術(shù)語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執(zhí)行語句至少執(zhí)行一次。判斷覆蓋：判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判定的取真分支和取假分支至少經(jīng)歷一次。判定覆蓋又稱為分支覆蓋。條件覆蓋：條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判定中的每個條件的可能取值至少執(zhí)行一次。2023/3/13第7章系統(tǒng)實現(xiàn)與維護537.9.1白盒測試技術(shù)判定/條件覆蓋：選取足夠多的測試數(shù)據(jù)，使得判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結(jié)果。條件組合覆蓋：條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判定中條件的所有可能組合至少出現(xiàn)一次。滿足條件組合覆蓋標準的測試數(shù)據(jù)，也一定滿足判定覆蓋、條件覆蓋和判定／條件覆蓋標準。因此，條件組合覆蓋是前述幾種覆蓋標準中最強的。但是，滿足條件組合覆蓋標準的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。2023/3/13第7章系統(tǒng)實現(xiàn)與維護547.9.1白盒測試技術(shù)點覆蓋：要求選取足夠多的測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖的每個結(jié)點一次，由于流圖的每個結(jié)點與一條或多條語句相對應，顯然，點覆蓋標準和語句覆蓋標準是相同的。邊覆蓋：要求選取足夠多測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖中每條邊一次。通常邊覆蓋和判定覆蓋是一致的。路徑覆蓋：路徑覆蓋就是設計足夠的測試用例，程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。2023/3/13第7章系統(tǒng)實現(xiàn)與維護557.9.2黑盒測試技術(shù)黑盒測試力圖發(fā)現(xiàn)下述類型的錯誤：①功能不正確或遺漏了功能；②界面錯誤；③數(shù)據(jù)結(jié)構(gòu)錯誤或外部數(shù)據(jù)庫訪問錯誤；④性能錯誤；⑤初始化和終止錯誤。黑盒測試法與白盒測試法不能互相代替，兩者應互為補充。2023/3/13第7章系統(tǒng)實現(xiàn)與維護567.9.2黑盒測試技術(shù)黑盒測試的主要方法有：等價劃分；邊界值分析；錯誤推測；因果圖。2023/3/13第7章系統(tǒng)實現(xiàn)與維護577.9.2黑盒測試技術(shù)等價值劃分等價劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測試用例。等價類的劃分有兩種不同的情況：有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。2023/3/13第7章系統(tǒng)實現(xiàn)與維護587.9.2黑盒測試技術(shù)劃分等價類的原則：如果輸入條件規(guī)定了取值范圍或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。2023/3/13第7章系統(tǒng)實現(xiàn)與維護597.9.2黑盒測試技術(shù)劃分等價類的原則：如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。如果規(guī)定了輸入數(shù)據(jù)為整型，則可以劃分出正整數(shù)、零和負整數(shù)等3個有效類。如果程序的處理對象是表格，則應該使用空表，以及含一項或多項的表。2023/3/13第7章系統(tǒng)實現(xiàn)與維護607.9.2黑盒測試技術(shù)確定測試用例設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。2023/3/13第7章系統(tǒng)實現(xiàn)與維護617.9.2黑盒測試技術(shù)等價劃分實例：假設有一個把數(shù)字串轉(zhuǎn)變成整數(shù)的函數(shù)。被處理的數(shù)字串是右對齊的，也就是說，如果數(shù)字串比6個字符短，則在它的左邊補空格。如果數(shù)字串是負的，則負號和最高位數(shù)字緊相鄰(負號在最高位數(shù)字左邊一位)。且只能轉(zhuǎn)化-32768~32767之間的整數(shù)。2023/3/13第7章系統(tǒng)實現(xiàn)與維護627.9.2黑盒測試技術(shù)分析這個程序的規(guī)格說明，劃分出有效輸入的等價類有：l~6個數(shù)字字符組成的數(shù)字串(最高位數(shù)字不是零)；最高位數(shù)字是零的數(shù)字串；最高位數(shù)字左鄰是負號的數(shù)字串；2023/3/13第7章系統(tǒng)實現(xiàn)與維護637.9.2黑盒測試技術(shù)無效輸入的等價類有：空字符串(全是空格)；左部填充的字符既不是零也不是空格；最高位數(shù)字右面由數(shù)字和空格混合組成；最高位數(shù)字右面由數(shù)字和其他字符混合組成；負號與最高位數(shù)字之間有空格；2023/3/13第7章系統(tǒng)實現(xiàn)與維護647.9.2黑盒測試技術(shù)合法輸出的等價類有：在計算機能表示的最小負整數(shù)和零之間的負整數(shù)；零；在零和計算機能表示的最大正整數(shù)之間的正整數(shù)；非法輸出的等價類有：比計算機能表示的最小負整數(shù)還小的負整數(shù)；比計算機能表示的最大正整數(shù)還大的正整數(shù)。2023/3/13第7章系統(tǒng)實現(xiàn)與維護657.9.2黑盒測試技術(shù)根據(jù)上面劃分出的等價類，可以設計出下述測試方案：1～6個數(shù)字組成的數(shù)字串，輸出是合法的正整數(shù)。輸入：‘1’預期的輸出：1。最高位數(shù)字是零的數(shù)字串，輸出是合法的正整數(shù)。輸入：‘00000l’預期的輸出：12023/3/13第7章系統(tǒng)實現(xiàn)與維護667.9.2黑盒測試技術(shù)最高位是負號的數(shù)字串，輸出是合法的負整數(shù)。輸入：‘-1’預期的輸出：-1。全部是零，輸出也是零。輸入：‘000000’預期的輸出：預期的輸出：0太小的負整數(shù)。輸入：‘-67561’預期的輸出：“錯誤—

—無效輸入”太大的正整數(shù)。輸入：‘132767’預期的輸出：“錯誤—

—無效輸入”2023/3/13第7章系統(tǒng)實現(xiàn)與維護677.9.2黑盒測試技術(shù)空字符串。輸入：‘

’預期的輸出：“錯誤——

沒有數(shù)字”字符串左部字符既不是零也不是空格輸入：‘XXXXXl’預期的輸出：“錯誤——填充錯”最高位數(shù)字后面有空格。輸入：‘12’預期的輸出：“錯誤——

無效輸入”2023/3/13第7章系統(tǒng)實現(xiàn)與維護687.9.2黑盒測試技術(shù)最高位數(shù)字后面有其他字符。輸入：‘1XX2’預期的輸出：“錯誤——無效輸入”

負號和最高位數(shù)字之間有空格。輸入：‘

-12’預期的輸出：“錯誤——負號位置錯”2023/3/13第7章系統(tǒng)實現(xiàn)與維護697.9.2黑盒測試技術(shù)邊界值分析人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。2023/3/13第7章系統(tǒng)實現(xiàn)與維護707.9.2黑盒測試技術(shù)補充下述測試方案：使輸出剛好等于最小的負整數(shù)。輸入：‘

-32768’預期的輸出為：-32768使輸出剛好等于最大的正整數(shù)。輸入：‘32767’預期的輸出：32767原來用等價劃分法設計出來的測試方案5最好改為：使輸出剛剛小于最小的負整數(shù)。輸入：‘

-32769’預期的輸出：“錯誤——無效輸入”2023/3/13第7章系統(tǒng)實現(xiàn)與維護717.9.2黑盒測試技術(shù)補充下述測試方案：原來的測試方案6最好改為：使輸出剛剛大于最大的正整數(shù)。輸入：‘

32768’預期的輸出：“錯誤——無效輸入”2023/3/13第7章系統(tǒng)實現(xiàn)與維護727.9.2黑盒測試技術(shù)錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。2023/3/13第7章系統(tǒng)實現(xiàn)與維護737.9.2黑盒測試技術(shù)Myers提出了使用各種測試方法的綜合策略:在任何情況下都必須使用邊界值分析方法。經(jīng)驗表明用這種方法設計出測試用例發(fā)現(xiàn)程序錯誤的能力最強。必要時用等價類劃分方法補充一些測試用例。用錯誤推測法再追加一些測試用例。對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。2023/3/13第7章系統(tǒng)實現(xiàn)與維護747.10軟件調(diào)試技術(shù)軟件調(diào)試是在進行了成功的測試之后才開始的工作。它與軟件測試不同，調(diào)試的任務是進一步診斷和改正程序中潛在的錯誤。2023/3/13第7章系統(tǒng)實現(xiàn)與維護757.10軟件調(diào)試技術(shù)從技術(shù)角度來看，查找錯誤的難度在于：現(xiàn)象與原因所處的位置可能相距甚遠。當其它錯誤得到糾正時，這一錯誤所表現(xiàn)出的現(xiàn)象可能會暫時消失，但并未實際排除?，F(xiàn)象實際上是由一些非錯誤原因(例如，舍入不精確)引起的?，F(xiàn)象可能是由于一些不容易發(fā)現(xiàn)的人為錯誤引起的。錯誤是由于時序問題引起的，與處理過程無關?，F(xiàn)象是由于難于精確再現(xiàn)的輸入狀態(tài)（例如，實時應用中輸入順序不確定）引起?，F(xiàn)象可能是周期出現(xiàn)的。在軟、硬件結(jié)合的嵌入式系統(tǒng)中常常遇到?，F(xiàn)象可能是由分布在許多任務中的原因引起的，這些任務運行在不同的處理機上。2023/3/13第7章系統(tǒng)實現(xiàn)與維護767.10軟件調(diào)試技術(shù)幾種主要的調(diào)試方法蠻干法：這種調(diào)試方法目前使用較多，效率較低。它不需要過多的思考，比較省腦筋。例如：通過內(nèi)存全部打印來調(diào)試；在程序特定部位設置打印語句；2023/3/13第7章系統(tǒng)實現(xiàn)與維護777.10軟件調(diào)試技術(shù)幾種主要的調(diào)試方法回溯法調(diào)試這是在小程序中常用的一種有效的調(diào)試方法。一旦發(fā)現(xiàn)了錯誤，人們先分析錯誤征兆，確定最先發(fā)現(xiàn)“癥狀”的位置。人工沿程序的控制流程，向回追蹤源程序代碼，直到找到錯誤根源或確定錯誤產(chǎn)生的范圍。2023/3/13第7章系統(tǒng)實現(xiàn)與維護787.10軟件調(diào)試技術(shù)原因排除法對分查找法如果已經(jīng)知道每個變量在程序內(nèi)若干個關鍵點的正確值，則可以用賦值語句或輸入語句在程序中點附近“注入”這些變量的正確值，然后運行程序并檢查所得到的輸出。如果輸出結(jié)果是正確的，則錯誤原因在程序的前半部分；反之，錯誤原因在程序的后半部分。對錯誤原因所在的那部分再重復使用這個方法，直到把出錯范圍縮小到容易診斷的程度為止。2023/3/13第7章系統(tǒng)實現(xiàn)與維護797.10軟件調(diào)試技術(shù)原因排除法歸納法是從個別現(xiàn)象推斷出一般性結(jié)論的思維方法。使用這種方法調(diào)試程序時，首先把和錯誤有關的數(shù)據(jù)組織起來進行分析，以便發(fā)現(xiàn)可能的錯誤原因。然后導出對錯誤原因的一個或多個假設，并利用已有的數(shù)據(jù)來證明或排除這些假設。當然，如果已有的數(shù)據(jù)尚不足以證明或排除這些假設，則需設計并執(zhí)行一些新的測試用例，以獲得更多的數(shù)據(jù)。2023/3/13第7章系統(tǒng)實現(xiàn)與維護807.10軟件調(diào)試技術(shù)原因排除法演繹法是一種從一般原理或前提出發(fā)，經(jīng)過排除和精化的過程來推導出結(jié)論的思考方法。演繹法排錯是測試人員首先根據(jù)已有的測試用例，設想及枚舉出所有可能出錯的原因做為假設；然后再用原始測試數(shù)據(jù)或新的測試，從中逐個排除不可能正確的假設；最后，再用測試數(shù)據(jù)驗證余下的假設確是出錯的原因。2023/3/13第7章系統(tǒng)實現(xiàn)與維護817.10軟件調(diào)試技術(shù)在動手改正錯誤之前，軟件工程師應該仔細考慮下述3個問題：是否同樣的錯誤也在程序其他地方存在?將要進行的修改可能會引入的“下一個錯誤”是什么?為防止今后出現(xiàn)類似的錯誤，應該做什么?2023/3/13第7章系統(tǒng)實現(xiàn)與維護827.11軟件維護軟件維護：就是在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。軟件維護的分類：改正性維護（Correctivemaintenance）適應性維護（Adaptivemaintenance）完善性維護（Perfectivemaintenance）預防性維護（Preventivemaintenance）2023/3/13第7章系統(tǒng)實現(xiàn)與維護837.11軟件維護2023/3/13第7章系統(tǒng)實現(xiàn)與維護847.11軟件維護結(jié)構(gòu)化維護與非結(jié)構(gòu)化維護差別巨大維護的代價高昂維護的問題很多2023/3/13第7章系統(tǒng)實現(xiàn)與維護857.11軟件維護結(jié)構(gòu)化維護：有完整的軟件配置，能夠提高維護的整體質(zhì)量。非結(jié)構(gòu)化維護：缺少相關文檔使得維護的代價巨大。2023/3/13第7章系統(tǒng)實現(xiàn)與維護867.11軟件維護有形的維護代價：費用。無形的維護代價有更大的影響：貽誤良機；一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結(jié)果引入新的故障，使得軟件整體質(zhì)量下降；把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。2023/3/13第7章系統(tǒng)實現(xiàn)與維護877.11軟件維護生產(chǎn)率大幅下降：維護工作量包括生產(chǎn)性活動（如分析和評價、設計修改和實現(xiàn)）和非生產(chǎn)性活動（如力圖理解代碼功能、解釋數(shù)據(jù)結(jié)構(gòu)、接口特性、性能限度等）2023/3/13第7章系統(tǒng)實現(xiàn)與維護887.11軟件維護維護工作量的模型：M是維護中消耗的總工作量