軟件工程：測試工具2課件

判斷結(jié)構(gòu)的CFG表達節(jié)點1代表了測試條件x<y，有不止一條出邊，稱為決策節(jié)點。節(jié)點4有不止一條入邊，稱為匯合節(jié)點。循環(huán)結(jié)構(gòu)的CFG表達注意，圖7‐2中的節(jié)點2就是增加的虛擬節(jié)點，不代表任何語句。（1）while循環(huán)的CFG表達循環(huán)結(jié)構(gòu)的CFG表達（2）do-while循環(huán)的CFG表達節(jié)點覆蓋即對于圖G中每個語法上可達的節(jié)點，測試用例所執(zhí)行的測試路徑的集合中至少存在一條測試路徑訪問該節(jié)點。語法上可達定義如下：如果存在從節(jié)點ni到節(jié)點n（或邊e）的一條路徑，則節(jié)點n（或邊e）是從節(jié)點ni在語法上可達的。顯然，節(jié)點覆蓋和語句覆蓋是等價的。邊覆蓋即對于圖G中每一個可到達的長度小于等于1的路徑，測試用例所執(zhí)行的測試路徑的集合中至少存在一條測試路徑游歷該路徑。顯然，邊覆蓋包含節(jié)點覆蓋，且邊覆蓋也可以實現(xiàn)分支覆蓋。路徑覆蓋路徑覆蓋測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑。

測試用例

通過路徑

覆蓋條件【(2,0,4),(2,0,3)】ace

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

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

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

基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內(nèi)，程序中的循環(huán)體最多只執(zhí)行一次。它是在程序控制流圖的基礎上，A.分析控制構(gòu)造的環(huán)路復雜性，B.導出基本可執(zhí)行路徑集合，C.設計測試用例的方法。設計出的測試用例要保證在測試中，程序的每一個可執(zhí)行語句至少要執(zhí)行一次，且每個條件在執(zhí)行時都將分別取真和假兩種值。

基本路徑測試2.確定線性獨立路徑的基本集合2.確定線性獨立路徑的基本集合從源節(jié)點（控制流圖的入口點）開始，一直走到匯節(jié)點（控制流圖的出口點）。該路徑作為基線路徑。接下來，重新回溯基線路徑，依次“翻轉(zhuǎn)”在判斷節(jié)點上原來選擇的路徑。即當遇到節(jié)點的出度大于等于2時，必須選擇不同的邊。重復以上過程，直到得到的路徑數(shù)目等于V(G)注意：如果存在循環(huán)，只能經(jīng)過一次，否則路徑存在冗余；第二，獨立路徑的基本集合可能不唯一，但集合中路徑的數(shù)目是唯一的。舉例

也叫功能測試或數(shù)據(jù)驅(qū)動測試，被測軟件看作一個不透明的黑盒子，在軟件接口處進行，完成功能的驗證。

黑盒測試完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性。

黑盒測試黑盒測試技術基于需求的測試黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:

是否有不正確或遺漏了的功能?

在接口上，輸入能否正確地接受?能否輸出正確的結(jié)果?

是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤?

性能上是否能夠滿足要求?

是否有初始化或終止性錯誤?

黑盒測試假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數(shù)，按黑盒方法進行窮舉測試：可能采用的測試數(shù)據(jù)組：232×232＝264

如果測試一組數(shù)據(jù)需要1毫秒，一年工作365×24小時，完成所有測試需5億年。用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。但這是不可能的。黑盒測試的局限性等價類劃分方法邊界值分析方法狀態(tài)測試方法黑盒測試方法等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設計測試用例。等價類劃分方法把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測試用例。使用這一方法設計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。等價類劃分方法等價類的劃分有兩種不同的情況：

①有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構(gòu)成的集合。 ②無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構(gòu)成的集合。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。1.劃分等價類劃分等價類等價類的原則

(1)如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。

劃分等價類的原則

例如，在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”。那么所有以字母打頭的構(gòu)成有效等價類，而不在此集合內(nèi)（不以字母打頭）的歸于無效等價類。

劃分等價類的原則劃分等價類等價類的原則

(2)如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。

劃分等價類的原則劃分等價類等價類的原則

(3)如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。劃分等價類等價類的原則

(4)如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。劃分等價類等價類的原則

(5)如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。劃分等價類的原則例如，Pascal語言規(guī)定“一個語句必須以分號‘;’結(jié)束”。這時，可以確定一個有效等價類“以‘;’結(jié)束”，若干個無效等價類“以‘:’結(jié)束”、“以‘,’結(jié)束”、“以‘’結(jié)束”、“以LF結(jié)束”等。2.確立測試用例

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。2.確立測試用例再從劃分出的等價類中按以下原則選擇測試用例：

(1)為每一個等價類規(guī)定一個唯一編號；

(2)設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

(3)設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。2.確立測試用例用等價類劃分法設計測試用例的實例舉例：計算兩個1-100之間的整數(shù)的和。1.劃分等價類用等價類劃分法設計測試用例的實例舉例：計算兩個1-100之間的整數(shù)的和。2.設計測試用例用例編號所屬等價類加數(shù)1加數(shù)2和UC012(有效等價類)25631UC021(無效等價類)0-1提示請輸入1-100間整數(shù)UC033(無效等價類)110101UC044(無效等價類)1.23.2UC055(無效等價類)ABUC066(無效等價類)@#UC077(無效等價類)空格空格UC088(無效等價類)…………………………

另一個用等價類劃分法設計測試用例的實例

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

用等價類劃分的方法，建立輸入等價類表:下面選取了9個測試用例，它們覆蓋了所有的等價類。

①VAR

x，T1234567：REAL；

BEGIN

x:=3.414；

T1234567:=2.732；

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

②VAR

：REAL；

(3)

③VAR

x，：REAL;(5)

④VART12345678：REAL；

(6)⑤VART12345......：REAL；

(7)

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

(10)⑦VARGOTO：INTEGER；

(11)⑧VAR2T：REAL；

(13)⑨VARPAR：REAL；

(15)

BEGIN......

PAP:=SIN(3.14*0.8)/6；

邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

邊界值分析方法比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。我們應注意到這三個數(shù)值應當滿足

A＞0、B＞0、C＞0、

A＋B＞C、A＋C＞B、B＋C＞A，才能構(gòu)成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構(gòu)成三角形。問題恰出現(xiàn)在容易被疏忽的邊界附近。舉例這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值做為測試數(shù)據(jù)。

邊界值分析方法狀試態(tài)測由于在黑盒測試階段，程序內(nèi)部的邏輯結(jié)構(gòu)是無從得知的，因此只能通過對狀態(tài)的測試間接地加以驗證。軟件狀態(tài)（softwarestate）是指軟件當前所處的條件或者模式。通常，訪問所有的狀態(tài)是可以實現(xiàn)的，但除了極少數(shù)簡單程序外，不可能以走完所有分支的方式來達到每種狀態(tài)，即必須選擇重要的內(nèi)容進行測試。建立狀態(tài)轉(zhuǎn)換圖標識出軟件可能進入的每一種獨立狀態(tài)。找出從一種狀態(tài)轉(zhuǎn)入另一種狀態(tài)所需的輸入和條件。找出進入或退出某種狀態(tài)時的設置條件及輸出結(jié)果。根據(jù)狀態(tài)轉(zhuǎn)換圖設計測試用例每種狀態(tài)至少訪問一次測試看起來是最常見和最普遍的狀態(tài)轉(zhuǎn)換測試狀態(tài)之間最不常用的分支測試所有錯誤狀態(tài)及其返回值測試狀態(tài)的隨機轉(zhuǎn)換靜態(tài)分析方法不實際運行程序，通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質(zhì)量的軟件測試技術。作用通過對代碼標準及質(zhì)量的監(jiān)控提高代碼可靠性盡可能早地通過對源代碼的檢查發(fā)現(xiàn)缺陷組織代碼審核定位易產(chǎn)生錯誤的模塊非常有效的質(zhì)量保證手段越來越多地被采用通用評審過程

評審過程就是執(zhí)行靜態(tài)分析的過程。IEEEStandardforSoftwareReviewsandAudits定義了以下6個步驟：1、計劃2、概述3、準備4、評審會議5、返工6、跟蹤靜態(tài)分析的主要內(nèi)容檢查需求檢查設計檢查代碼其他10%軟件產(chǎn)品說明書（需求）56%編寫代碼7%設計27%軟件缺陷產(chǎn)生的原因分布檢查需求需求的標準完整性是否完整描述一個功能正確性是否正確反應客戶要求可行性必要性Goldplating?無二義性會引起歧義嗎可驗證性測試用例怎么寫？實施無關性需求規(guī)格說明的標準完整性是否包含所有需求FURPS一致性相互矛盾重復需求檢查練習例1產(chǎn)品必須在固定的時間間隔內(nèi)提供狀態(tài)信息，并且每次時間間隔不得小于60秒。完整嗎？清晰嗎？例2分析程序應該能生成HTML標記錯誤的報告，從而使HTML初學者可以用它來快速排錯。是否有歧義？可驗證嗎？例3如果可能的話，應當根據(jù)系統(tǒng)貨物編號列表，在線確認輸入的貨物編號?！叭绻赡艿脑挕笔鞘裁匆馑迹啃枨髾z查練習例4產(chǎn)品不應該提供將帶來災難性后果的查找和替換選擇。真正的需求是什么？例5系統(tǒng)對標準XYZ1.4.1的支持是可選的。有歧義嗎？例6當用戶選擇“緊湊內(nèi)存”選項時，程序通過Huffman解析矩陣方法將郵件列表數(shù)據(jù)壓縮到相應的大小。可測嗎？代碼無關嗎？規(guī)格說明用語清單絕對的肯定總是、每一種、所有、沒有、從不注意隱含的假設當然、因此、顯然、必然模棱兩可的詞某些、有時、常常、通常、經(jīng)常、太多、幾乎不可測的描述良好、迅速、廉價、高效、穩(wěn)定隱藏的需求已處理、已拒絕、已忽略、已消除缺少的分支如果…那么…（沒有“否則…”分支）檢查設計在編碼開始前進行檢查功能設計說明，消除歧義功能的用意、總體位置輸入、輸出可能的錯誤/例外接口定義交互細節(jié)實施建議檢查代碼通過檢查代碼發(fā)現(xiàn)模塊中的錯誤通過代碼檢查能夠發(fā)現(xiàn)大部分的錯誤靜態(tài)分析的類型同事審查走查審查同事審查同事審查是一種非正式的評審，但也應遵循上面介紹的評審流程。適用于初次審查，是要求最低的正式方法，也稱為伙伴審查。同事審查常常僅在編寫代碼或設計體系結(jié)構(gòu)的程序員，以及充當審查者的其他一兩個程序員和測試員之間進行。走查（Walkthrough）開發(fā)組內(nèi)部進行的采用講解、討論和模擬運行的方式查找錯誤的活動限時-避免跑題參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關的開發(fā)人員本項目組的新人由本模塊的開發(fā)者進行講解、回答問題并記錄不要現(xiàn)場修改檢查要點邏輯錯誤代碼標準/規(guī)范/風格審查（Inspection）開發(fā)組、測試組和相關人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進行。采用講解、提問并使用Checklist方式進行的查找錯誤的活動。以會議的形式，制定目標、流程、規(guī)則和結(jié)果報告。相關資料要在會議前下發(fā)并閱讀。參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關的開發(fā)人員測試組和相關人員審查（Inspection）由另外一名開發(fā)者進行講解、其他開發(fā)者主要按照Checklist進行提問并填表、本模塊開發(fā)者回答問題并記錄不要現(xiàn)場修改檢查要點設計需求代碼標準/規(guī)范/風格文檔的完整性和一致性通用代碼審查清單1、數(shù)據(jù)引用錯誤。2、數(shù)據(jù)聲明錯誤。3、計算錯誤。4、比較錯誤。5、控制流程錯誤。6、子程序參數(shù)錯誤。7、輸入/輸出錯誤。8、其他檢查。如：字符集、移植性、兼容性等。自動化工具基于編碼規(guī)則LogiscopeLDRANuMega的CodeReview基于質(zhì)量度量LogiscopeMcCabeLDRA如何使靜態(tài)分析更有效？必須引入“別人”的眼睛根據(jù)團隊及項目的實際情況，設計合理的實施辦法有準備地進行應該有包含所有關注要點的Checklist把握會