軟件測試與維護

軟件測試與維護第1頁，共58頁，2023年，2月20日，星期日軟件測試目標軟件測試的目標就是發(fā)現(xiàn)軟件中隱藏的錯誤。由于對軟件測試的目標存在一些錯誤認識和做法，G.Myers給出了關于軟件測試目標的一些規(guī)則說明：(1)測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；(2)一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；(3)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。組織專門的測試小組時，程序的編寫者不適合對自己編寫的程序進行確認測試（程序調(diào)試除外）。第2頁，共58頁，2023年，2月20日，星期日軟件測試是貫穿于軟件開發(fā)過程始終的一個活動，由測試計劃、單元測試、集成測試、系統(tǒng)測試、驗收測試組成。一、測試計劃：作為軟件項目計劃的子計劃，在項目啟動初期就開始進行規(guī)劃，在項目進行的各階段可以同步進行相應的測試計劃的編制。需求分析階段開始編制系統(tǒng)測試和驗收測試的計劃系統(tǒng)設計階段編制集成測試計劃編碼的同時編制單元測試計劃二、單元測試：依據(jù)詳細設計說明書，測試某個模塊是否滿足規(guī)定的功能，是整個軟件測試過程中最基本的活動。多采用白盒測試技術。軟件測試過程第3頁，共58頁，2023年，2月20日，星期日

單元測試的主要任務：模塊接口測試局部數(shù)據(jù)結構測試路徑測試錯誤處理測試邊界測試

單元測試方法：單元測試通常在編碼階段進行，使用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。輔助模塊主要有驅(qū)動模塊和樁模塊。（1）驅(qū)動模塊：相當于調(diào)用被測模塊的主程序。（2）樁模塊：用來代替被測模塊需要調(diào)用的子模塊。輸入的測試數(shù)據(jù)輸出的測試結果驅(qū)動模塊被測模塊樁模塊1樁模塊2樁模塊3第4頁，共58頁，2023年，2月20日，星期日

三、集成測試：在單元測試的基礎上，承擔對系統(tǒng)進行組裝與檢測的雙重任務，是軟件測試活動中最重要的部分。主要有非漸增組裝測試和漸增組裝測試兩種方法。具體測試任務連接各模塊時，穿越模塊接口的數(shù)據(jù)是否會丟失。一個模塊的功能是否對另一個模塊的功能產(chǎn)生不利影響。各子模塊組合起來，能否達到預期的協(xié)作功能。全局數(shù)據(jù)結構是否有問題。單個模塊的計算誤差積累起來，是否會放大進而達到不能接受的程度。第5頁，共58頁，2023年，2月20日，星期日非漸增組裝測試：先完成單元模塊的確認測試，然后將所有模塊按設計要求組合成系統(tǒng)，再進行測試。

測試過程中發(fā)現(xiàn)的問題斷定出錯的位置和出錯的原因。漸增組裝測試：把所有需要集成到系統(tǒng)中的模塊按照一定的次序，逐個集成到系統(tǒng)中去，并在進行模塊間協(xié)作性測試的同時對模塊的功能進行確認測試。漸增組裝測試的優(yōu)點：利用已測試過的模塊作為部分測試軟件，減少測試工作量。能夠較早發(fā)現(xiàn)模塊間的接口錯誤。發(fā)生的錯誤往往和最近加進來的模塊有關，便于錯誤診斷與定位。先加入系統(tǒng)的模塊不斷在新的條件下受到新的檢測，對程序的測試更徹底。第6頁，共58頁，2023年，2月20日，星期日漸增組裝測試的方法：自頂向下、自底向上。自頂向下漸增組裝測試：從主控模塊開始，沿著軟件的控制層次向下移動，從而逐個地把各個模塊集成到系統(tǒng)中來。在這種方法中不需要“驅(qū)動模塊”，需要“樁模塊”。自底向上漸增組裝測試：從軟件結構的最底層模塊開始組裝。在這種方法中不需要“樁模塊”，需要“驅(qū)動模塊”集成測試結束標準：成功執(zhí)行了測試計劃中規(guī)定的所有集成測試修正了所發(fā)現(xiàn)的錯誤，并成功地進行了再次測試。所有集成測試文檔齊全。測試結果通過了專門小組的評審。第7頁，共58頁，2023年，2月20日，星期日

四、確認測試確認測試又叫有效性測試或驗收測試。任務是按照軟件需求規(guī)格說明書的要求，驗證軟件的功能、性能以及其它特性等是否與用戶的要求保持一致，并得到用戶確認。確認測試工作流程組織測試小組設計測試用例實施測試測試計劃需求文檔設計文檔源程序清單支持環(huán)境有效性測試軟件配置審查管理機構裁決專家鑒定測試報告軟件配置交付用戶第8頁，共58頁，2023年，2月20日，星期日1、有效性測試：用黑盒測試法確定軟件是否滿足需求規(guī)格說明書的要求。2、軟件配置復查：保證軟件配置的所有成分齊全，并已編排好分類的目錄。3、Alpha測試：在開發(fā)環(huán)境下由用戶進行測試，并作出全面的評價，開發(fā)者在場。4、Beta測試：由用戶在軟件實際使用環(huán)境下進行測試，開發(fā)者不在場。5、測試結果確認，交付相應文檔。第9頁，共58頁，2023年，2月20日，星期日

五、測試方法軟件測試最基本的方法是黑盒測試法和白盒測試法。

1、黑盒測試法：是基于程序外部功能規(guī)格而進行的測試，又叫功能測試法。將待測試的模塊當作一個黑盒子，只對模塊接口處的輸入輸出數(shù)據(jù)進行測試。黑盒測試一般以程序模塊為單位進行，適合于對程序模塊的確認測試，系統(tǒng)集成測試和用戶驗收測試。

黑盒子程序模塊測試輸入數(shù)據(jù)測試輸出數(shù)據(jù)第10頁，共58頁，2023年，2月20日，星期日2、白盒測試法：是基于程序的內(nèi)部結構與處理過程而進行的測試，又叫結構測試。白盒測試的內(nèi)容是程序的內(nèi)部算法細節(jié)。3、測試中的信息流：ABCDEYN待測程序模塊測試評價排錯錯誤軟件配置測試配置測試工具實際結果預測結果修正后的軟件可靠性預測錯誤率可靠性分析第11頁，共58頁，2023年，2月20日，星期日軟件測試用例設計

一、白盒測試用例設計白盒測試用例設計主要采用的是邏輯覆蓋，以程序內(nèi)部邏輯結構為依據(jù)的用例設計方法。包括語句覆蓋、判斷覆蓋、條件覆蓋、判斷－條件覆蓋、條件組合覆蓋、路徑覆蓋等。開始結束a>0ANDb=0a=2ORx>1輸出：a,b,xx=x/ax=x+1FFTT1246735被測模塊程序流程圖第12頁，共58頁，2023年，2月20日，星期日1、語句覆蓋：被測程序中每個語句至少執(zhí)行一次。測試用例：a=2,b=0,x=4執(zhí)行路徑：1-2-3-4-5-6-72、判定覆蓋：不僅被測程序中每個語句至少執(zhí)行一次，而且每個判定的每種可能的結果至少執(zhí)行一次。測試用例：a=3,b=0,x=4執(zhí)行路徑：1-2-3-4-5-6-7判斷式：T，F(xiàn)a=2,b=1,x=1執(zhí)行路徑：1-2-4-6-7判斷式：F，T開始結束a>0ANDb=0a=2ORx>1輸出：a,b,xx=x/ax=x+1FFTT1246735被測模塊程序流程圖第13頁，共58頁，2023年，2月20日，星期日3、條件覆蓋：不僅被測程序中每個語句至少執(zhí)行一次，而且判定表達式中的每個條件都取到各種可能的結果。用例：a=2,b=0,x=4執(zhí)行路徑：1-2-3-4-5-6-7條件式：T，T，T，Ta=1,b=1,x=1執(zhí)行路徑：1-2-4-5-6-7條件式：F，F(xiàn)，F(xiàn)，F(xiàn)開始結束a>0ANDb=0a=2ORx>1輸出：a,b,xx=x/ax=x+1FFTT1246735被測模塊程序流程圖第14頁，共58頁，2023年，2月20日，星期日

二、黑盒測試用例設計

1、等價類劃分：把所有可能的輸入數(shù)據(jù)劃分出若干個等價類，每個等價類中的一個典型值在測試過程中與該等價類中所有的其它值的作用相同。如輸入百分制的成績，輸出等級制成績。錄入數(shù)據(jù)>100測試結果：無效成績錄入數(shù)據(jù)<0測試結果：無效成績0=<錄入數(shù)據(jù)<60測試結果：不及格60=<錄入數(shù)據(jù)<70測試結果：及格70=<錄入數(shù)據(jù)<80測試結果：中80=<錄入數(shù)據(jù)<90測試結果：良90=<錄入數(shù)據(jù)<＝100測試結果：優(yōu)測試用例：102，－10，30，65，74，86，93第15頁，共58頁，2023年，2月20日，星期日

2、邊界類分析：在邊界處設計專門的測試用例，用于驗證程序運行在邊界時是否發(fā)生錯誤。如根據(jù)上例可設計測試用例為：－1，0，59，60，69，70，79，80，89，90，100，1013、錯誤推測：測試人員憑借測試經(jīng)驗和直覺，例舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況來選擇測試用例。

第16頁，共58頁，2023年，2月20日，星期日面向?qū)ο鬁y試

1、面向?qū)ο髥卧獪y試此時的“單元”不再是程序模塊的概念，而是以類為單位，把操作作為類的一部分進行測試

2、面向?qū)ο蠹蓽y試（1）基于線程的測試：把響應系統(tǒng)的一個事件所需要的一組類集成為一個線程，分別集成并測試每個線程，同時進行回歸測試。（2）基于使用的測試：先測試獨立類，再按層次測試依賴類，直到構造出整個系統(tǒng)。

3、面向?qū)ο蟠_認測試測試的主要內(nèi)容是用戶可見的動作和用戶可識別的輸出，不需考慮類的構造及類之間的聯(lián)系。第17頁，共58頁，2023年，2月20日，星期日軟件調(diào)試

軟件調(diào)試也叫排錯，涉及兩個步驟：

1、診斷：確定錯誤的位置和性質(zhì)。

2、排錯：修改程序，改正錯誤。

一、調(diào)試方法

1、輸出存儲器內(nèi)容。

2、在程序中插入輸入輸出語句。

3、使用自動調(diào)試工具。

二、調(diào)試策略

1、試探法：猜測故障可能的大致位置進行試探，以獲得程序錯誤的準確定位。

2、回溯法：確定最先發(fā)現(xiàn)錯誤的位置，沿程序控制流程往回追蹤源程序代碼，找出程序錯誤的準確位置。

3、對分查找法：與二分查找排序算法一致。

4、歸納法：以程序的錯誤征兆為線索，分析這些線索之間的關系，找出故障。

5、演繹法：先列出所有可能成立的原因或假設，逐個排除。第18頁，共58頁，2023年，2月20日，星期日自動測試工具

常見的自動測試工具：

1、測試數(shù)據(jù)生成程序

2、動態(tài)分析程序

3、靜態(tài)分析程序

4、模塊測試程序

5、集成環(huán)境測試第19頁，共58頁，2023年，2月20日，星期日軟件可靠性評估

一、可靠性概念

1、軟件可靠性：在給定的時間間隔內(nèi)，程序按照規(guī)格說明書成功運行的概率。

2、軟件可用性：在給定的時間點，程序按照規(guī)格說明書成功運行的概率。一般使用穩(wěn)態(tài)可用性對系統(tǒng)進行評估：

Ass=MTTF/(MTTF+MTTR)MTTF為系統(tǒng)平均無故障時間，MTTR為系統(tǒng)平均維修時間。估算系統(tǒng)平均無故障時間及系統(tǒng)故障總數(shù)略。第20頁，共58頁，2023年，2月20日，星期日軟件維護軟件維護的概念軟件可維護性軟件維護的實施對老化系統(tǒng)的維護逆向工程與再工程軟件配置管理第21頁，共58頁，2023年，2月20日，星期日軟件維護的概念軟件維護的定義影響維護工作量的因素結構化維護與非結構化維護維護成本第22頁，共58頁，2023年，2月20日，星期日軟件維護的定義在軟件運行／維護階段對軟件產(chǎn)品進行的修改就是所謂的維護。維護的類型有三種：改正性維護適應性維護完善性維護第23頁，共58頁，2023年，2月20日，星期日改正性維護在軟件交付使用后，因開發(fā)時測試的不徹底、不完全，必然會有部分隱藏的錯誤遺留到運行階段。這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程就叫做改正性維護。第24頁，共58頁，2023年，2月20日，星期日適應性維護在使用過程中，外部環(huán)境（新的硬、軟件配置）

數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)）可能發(fā)生變化。為使軟件適應這種變化，而去修改軟件的過程就叫做適應性維護。

第25頁，共58頁，2023年，2月20日，星期日完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動叫做完善性維護。第26頁，共58頁，2023年，2月20日，星期日實踐表明，在幾種維護活動中，完善性維護所占的比重最大。即大部分維護工作是改變和加強軟件，而不是糾錯。完善性維護不一定是救火式的緊急維修，而可以是有計劃、有預謀的一種再開發(fā)活動。事實證明，來自用戶要求擴充、加強軟件功能、性能的維護活動約占整個維護工作的50％。第27頁，共58頁，2023年，2月20日，星期日在整個軟件維護階段所花費的全部工作量中，完善性維護占了幾乎一半的工作量。軟件維護活動所花費的工作占整個生存期工作量的70%以上，這是由于在漫長的軟件運行過程中需要不斷對軟件進行修改，以改正新發(fā)現(xiàn)的錯誤、適應新的環(huán)境和用戶新的要求，這些修改需要花費很多精力和時間，而且有時會引入新的錯誤。第28頁，共58頁，2023年，2月20日，星期日影響維護工作量的因素在軟件的維護過程中，需要花費大量的工作量，從而直接影響了軟件維護的成本。應當考慮有哪些因素影響軟件維護的工作量，相應應該采取什么維護策略，才能有效地維護軟件并控制維護的成本。第29頁，共58頁，2023年，2月20日，星期日系統(tǒng)大小：系統(tǒng)越大，理解掌握起來越困難。系統(tǒng)越大，所執(zhí)行功能越復雜。因而需要更多的維護工作量。程序設計語言：使用強功能的程序設計語言可以控制程序的規(guī)模。語言的功能越強，生成程序的模塊化和結構化程度越高，所需的指令數(shù)就越少，程序的可讀性越好。

第30頁，共58頁，2023年，2月20日，星期日系統(tǒng)年齡：老系統(tǒng)隨著不斷的修改，結構越來越亂；維護人員經(jīng)常更換，程序又變得越來越難于理解。許多老系統(tǒng)在當初并未按照軟件工程的要求進行開發(fā)，因而沒有文檔，或文檔太少。在長期的維護過程中文檔在許多地方與程序?qū)崿F(xiàn)變得不一致，在維護時就會遇到很大困難。第31頁，共58頁，2023年，2月20日，星期日數(shù)據(jù)庫技術的應用：使用數(shù)據(jù)庫，可以簡單而有效地管理和存儲用戶程序中的數(shù)據(jù)，還可以減少生成用戶報表應用軟件的維護工作量。先進的軟件開發(fā)技術：在軟件開發(fā)時，若使用能使軟件結構比較穩(wěn)定的分析與設計技術，及程序設計技術，如面向?qū)ο蠹夹g、復用技術等，可減少大量的工作量。第32頁，共58頁，2023年，2月20日，星期日其它：應用的類型數(shù)學模型任務的難度開關與標記、IF嵌套深度、索引或下標數(shù)等 對維護工作量都有影響。許多軟件在開發(fā)時并未考慮將來的修改，為軟件的維護帶來許多問題。第33頁，共58頁，2023年，2月20日，星期日結構化維護與非結構化維護非結構化維護

非結構化維護往往與早期的軟件開發(fā)非工程化有關，是軟件開發(fā)過程中沒有按照軟件工程原則實施軟件開發(fā)留下的后遺癥。結構化維護結構化維護是一種依靠完整的軟件配置而進行的維護，其中的軟件配置包括源程序清單、維護計劃以及軟件工程過程各階段產(chǎn)生的文檔。第34頁，共58頁，2023年，2月20日，星期日維護成本有形的軟件維護成本是花費了多少錢，無形的維護成本有更大的影響。一些合理的修復或修改請求不能及時安排，使得客戶不滿意；變更的結果引入新的故障，使得軟件整體質(zhì)量下降；把軟件人員抽調(diào)到維護工作中，干擾了軟件開發(fā)工作。第35頁，共58頁，2023年，2月20日，星期日軟件維護的代價是降低了生產(chǎn)率，在做老程序的維護時非常明顯。例如，開發(fā)每一行源代碼耗資25美元，維護每一行源代碼需要耗資1000美元。維護工作量包括生產(chǎn)性活動（如分析和評價、設計修改和實現(xiàn)）和非生產(chǎn)性活動（如試圖理解代碼在做什么、試圖判明數(shù)據(jù)結構、接口特性、性能界限等）。第36頁，共58頁，2023年，2月20日，星期日維護工作量的模型M是維護中消耗的總工作量p是上面描述的生產(chǎn)性工作量K是一個經(jīng)驗常數(shù)c是因缺乏好的設計和文檔而導致復雜性的度量d是對軟件熟悉程度的度量。第37頁，共58頁，2023年，2月20日，星期日

軟件可維護性

軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的難易程度?？删S護性、可使用性、可靠性是衡量軟件質(zhì)量的主要質(zhì)量特性，也是用戶十分關心的幾個方面。軟件的可維護性是軟件開發(fā)階段各個時期的關鍵目標。第38頁，共58頁，2023年，2月20日，星期日目前廣泛使用的是用如下的七個特性來衡量程序的可維護性。

可理解性：閱讀源程序和相關文檔的難易程度。可使用性：指對用戶而言，程序的方便、實用和易于使用的程度?？蓽y試性：診斷程序錯誤的難易程度可移植性：程序轉(zhuǎn)移到新的環(huán)境的可能性的大小?？尚薷男裕撼绦蛐薷牡碾y易程度。運行效率：執(zhí)行預定功能而不浪費機器資源的程度?？煽啃裕涸诮o定的時間段內(nèi)正確運行的概率。第39頁，共58頁，2023年，2月20日，星期日在各類維護中的側(cè)重點

第40頁，共58頁，2023年，2月20日，星期日軟件維護的實施為了有效地進行軟件維護，應事先就開始做組織工作。首先建立維護的機構申明提出維護申請報告的過程及評價的過程為每一個維護申請規(guī)定標準的處理步驟建立維護活動的登記制度以及規(guī)定評價和評審的標準。第41頁，共58頁，2023年，2月20日，星期日維護機構除了較大的軟件開發(fā)公司外，通常在軟件維護工作方面，并不保持一個正式的組織機構。雖然不要求建立一個正式的維護機構，但是在開發(fā)部門確立一個非正式的維護機構則是非常必要的。第42頁，共58頁，2023年，2月20日，星期日

軟件維護的機構第43頁，共58頁，2023年，2月20日，星期日軟件維護申請報告維護申請報告或稱軟件問題報告，由申請維護的用戶填寫。用戶必須完整地說明產(chǎn)生錯誤的情況，包括輸入數(shù)據(jù)、錯誤清單以及其它有關材料。如果申請的是適應性維護或完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。第44頁，共58頁，2023年，2月20日，星期日

維護申請報告將由維護管理員和系統(tǒng)監(jiān)督員來研究處理。他們應相應地做出軟件修改報告，指明：所需修改變動的性質(zhì)；申請修改的優(yōu)先級；為滿足某個維護申請報告，所需的工作量；預計修改后的狀況.

第45頁，共58頁，2023年，2月20日，星期日軟件維護工作流程第46頁，共58頁，2023年，2月20日，星期日維護檔案記錄程序名稱源程序語句條數(shù)機器代碼指令條數(shù)所用的程序設計語言程序安裝的日期程序安裝后的運行次數(shù)與程序安裝后運行次數(shù)有關的處理故障次數(shù)第47頁，共58頁，2023年，2月20日，星期日

程序改變的層次及名稱修改程序增加的源程序語句條數(shù)修改程序減少的源程序語句條數(shù)每次修改所付出的“人時”數(shù)修改程序的日期軟件維護人員的姓名維護申請報告的名稱、維護類型維護開始時間和維護結束時間、花費在維護上的累計“人時”數(shù)維護工作的凈收益等。第48頁，共58頁，2023年，2月20日，星期日維護評價評價維護活動比較困難，因為缺乏可靠的數(shù)據(jù)。如果維護的檔案記錄做得比較好，可以得出一些維護“性能”方面的度量值。每次程序運行時的平均出錯次數(shù)；花費在每類維護上的總“人時”數(shù)；第49頁，共58頁，2023年，2月20日，星期日每個程序、每種語言、每種維護類型的程序平均修改次數(shù)；因為維護，增加或刪除每個源程序語句所花費的平均“人時”數(shù)；用于每種語言的平均“人時”數(shù)；維護申請報告的平均處理時間；各類維護申請的百分比。據(jù)此可對開發(fā)技術、語言選擇、維護工作計劃、資源分配、以及其它許多方面做出判定。第50頁，共58頁，2023年，2月20日，星期日對老化系統(tǒng)的維護老化系統(tǒng)是指使用早期程序設計語言（FORTRAN,COBOL）開發(fā)的系統(tǒng)，結構差，文檔不完整，沒有保