軟件測試實(shí)用教程-方法與實(shí)踐（第2版）課件 第7-9章 單元測試、集成測試、系統(tǒng)測試

第7章單元測試高等學(xué)校計算機(jī)類系列教材軟件測試實(shí)用教程——方法與實(shí)踐01概述概述具體來說，建議的單元選取原則如下：(1)對于C語言這類面向過程的開發(fā)語言來說，單元常指一個函數(shù)或子過程。在特殊情況下，若有幾個函數(shù)之間具有強(qiáng)耦合性，導(dǎo)致函數(shù)關(guān)系非常密切，則應(yīng)將這幾個函數(shù)共同作為一個單元來測試。(2)對于C、Java或C#這類面向?qū)ο蟮拈_發(fā)語言來說，單元一般指一個類。然而，某些基礎(chǔ)類可能非常龐大，涉及大量屬性和方法，甚至需要幾個開發(fā)人員來編碼完成，若將該類作為一個單元來測試并不合適，此時的測試將上升到集成測試的層面，并分為類內(nèi)測試和類間測試。(3)圖形化軟件中，單元常指一個窗口或一個菜單。單元測試(UnitTesting)是指對軟件中的最小可測試單元或基本組成單元進(jìn)行檢查和驗(yàn)證。那么，如何定義這個最小可測試單元呢?一般地，一個單元應(yīng)具有明確的功能定義、性能定義，以及連接其他部分的接口定義等，且應(yīng)可以清晰地與其他單元區(qū)分開來。從某種意義上而言，單元的概念已經(jīng)擴(kuò)展為組件(Component)。02單元測試的內(nèi)容靜態(tài)檢查靜態(tài)檢查主要是通過走查、審查等會議方式，依據(jù)模塊的詳細(xì)設(shè)計，將代碼與缺陷檢查表進(jìn)行對照，查看代碼是否符合標(biāo)準(zhǔn)和規(guī)范。典型的靜態(tài)檢查主要是對模塊局部數(shù)據(jù)結(jié)構(gòu)的測試。局部數(shù)據(jù)結(jié)構(gòu)是最常見的缺陷來源，檢查局部數(shù)據(jù)結(jié)構(gòu)可以保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在代碼執(zhí)行過程中是完整和正確的。檢查局部數(shù)據(jù)結(jié)構(gòu)應(yīng)考慮如下方面：(1)是否存在不正確、不一致的數(shù)據(jù)類型說明；(2)是否存在未初始化或未賦值的變量；(3)是否存在變量初始化或默認(rèn)值錯誤；(4)是否存在變量名拼寫或書寫錯誤；(5)是否存在不一致的數(shù)據(jù)類型；(6)是否出現(xiàn)上溢、下溢或地址異常。動態(tài)測試完成靜態(tài)測試之后還需運(yùn)行程序，完成動態(tài)測試，主要包括對模塊接口、模塊邊界條件、模塊獨(dú)立路徑和錯誤處理進(jìn)行測試。(1)模塊接口測試首先應(yīng)考慮數(shù)據(jù)能正確地輸入和輸出，這是單元測試的基礎(chǔ)，具體內(nèi)容大致包括：①輸入的實(shí)參與形參在個數(shù)、屬性、量綱和順序上是否匹配；②被測模塊調(diào)用其他模塊時，傳遞的實(shí)參在個數(shù)、屬性、量綱和順序上與被調(diào)用模塊的形參是否匹配：③是否存在與當(dāng)前入口點(diǎn)無關(guān)的參數(shù)引用；④是否修改了只做輸入用的只讀形參；⑤全局變量在各模塊中的定義是否一致；⑥是否將某些約束條件作為形參來傳遞。動態(tài)測試(2)模塊邊界條件測試邊界條件可參考黑盒測試中的邊界值測試方法，即在被測模塊的輸入域或輸出域中尋找可能的邊界點(diǎn)，在邊界點(diǎn)附近抽取測試數(shù)據(jù)，根據(jù)單缺陷假設(shè)設(shè)計測試用例并展開測試。(3)模塊中所有獨(dú)立的執(zhí)行路徑測試應(yīng)對模塊中每條獨(dú)立執(zhí)行路徑進(jìn)行測試，便于發(fā)現(xiàn)如下錯誤情況(具體方法見第5章):①是否正確理解了操作符的優(yōu)先次序；②是否存在被零除的風(fēng)險；③是否不滿足運(yùn)算精度要求；④變量初值是否正確；⑤是否存在錯誤的邏輯運(yùn)算符或優(yōu)先次序；⑥關(guān)系表達(dá)式中是否存在錯誤的變量和比較符；⑦是否存在不可能的循環(huán)終止條件，導(dǎo)致死循環(huán)；⑧是否存在迭代發(fā)散，導(dǎo)致不能退出；⑨是否錯誤修改了循環(huán)變量，導(dǎo)致循環(huán)次數(shù)多一次或少一次。動態(tài)測試(4)模塊的所有錯誤處理路徑測試函數(shù)應(yīng)具備良好的容錯性，應(yīng)考慮的內(nèi)容主要包括：①輸出的錯誤提示是否難以理解；②錯誤提示是否信息不足，導(dǎo)致無法定位發(fā)現(xiàn)的缺陷；③顯示的錯誤是否與實(shí)際遇到的缺陷不符合；④是否存在不當(dāng)?shù)漠惓Ｌ幚?；⑤是否存在無法按預(yù)先自定義的出錯處理方式來處理的情況。03驅(qū)動和樁模塊的設(shè)計1.驅(qū)動模塊和樁模塊的概念驅(qū)動模塊(Driver)是模擬被測單元的上級模塊，用于接收測試數(shù)據(jù)、啟動被測模塊和輸出結(jié)果。樁模塊(Stub)是模擬被測單元所調(diào)用的模塊。有時，需要使用子模塊的接口，才能做少量數(shù)據(jù)操作，并驗(yàn)證和打印入口處的信息，然后返回。驅(qū)動模塊和樁模塊的定義樁模塊不包含原模塊的所有細(xì)節(jié)。由驅(qū)動模塊和樁模塊搭建的某個被測單元的單元測試環(huán)境如圖7.1所示。圖中的測試用例是概念意義上的測試用例，它可以文檔形式提供數(shù)據(jù)，也可以數(shù)據(jù)庫或其他形式的數(shù)據(jù)源提供數(shù)據(jù)，主要作用在于向驅(qū)動模塊提供輸入值和預(yù)期輸出，驅(qū)動模塊接收輸入值傳遞給被測單元，并調(diào)用被測單元，將得到的實(shí)際輸出與從測試用例獲取的預(yù)期輸出進(jìn)行比較，并根據(jù)指定精度判斷測試結(jié)果為通過或失敗。驅(qū)動模塊和樁模塊的定義當(dāng)被測單元需調(diào)用多個模塊才能完成本模塊的功能時，需對每個未經(jīng)單元測試的被調(diào)用模塊開發(fā)樁模塊(對應(yīng)圖中樁模塊1～n)，而那些已經(jīng)過單元測試或不需要進(jìn)行單元測試的模塊則不需要開發(fā)樁模塊，直接用實(shí)際的模塊即可(對應(yīng)圖中實(shí)際模塊1～m)。編寫和執(zhí)行單元測試時，需在被測單元代碼中將開發(fā)完成的樁模塊替代原始實(shí)際模塊。圖中的驅(qū)動模塊在此更多地等同于測試驅(qū)動程序，即用于調(diào)用被測單元和檢驗(yàn)測試結(jié)果的程序，本書所提到的驅(qū)動模塊均指測試驅(qū)動程序，不再單獨(dú)說明。2.驅(qū)動模塊和樁模塊的適用條件驅(qū)動模塊和樁模塊是為了對單元進(jìn)行測試而引入的額外代碼，當(dāng)存在驅(qū)動模塊和樁模塊時，原始被測單元的代碼也需要進(jìn)行修改，以在單元測試中調(diào)用樁模塊。驅(qū)動模塊和樁模塊的定義因此，不需要也不應(yīng)該將這些代碼與最終要交付給用戶的產(chǎn)品代碼混在一起，而且在保證測試質(zhì)量的前提下，應(yīng)盡量避免開發(fā)驅(qū)動模塊和樁模塊，以降低額外的測試工作量。當(dāng)被測單元所調(diào)用的某個模塊較簡單時，如代碼段很短，代碼結(jié)構(gòu)簡單，無復(fù)雜的循環(huán)和邏輯判斷，不涉及復(fù)雜的動態(tài)內(nèi)存分配和釋放，無大量非結(jié)構(gòu)化設(shè)計等，則不需要專門設(shè)計樁模塊，可以直接與被測單元放在一起執(zhí)行測試。然而，當(dāng)被測單元較為復(fù)雜時，需要利用驅(qū)動模塊和樁模塊構(gòu)建測試環(huán)境，運(yùn)行程序。驅(qū)動模塊和樁模塊的設(shè)計1.設(shè)計原則驅(qū)動模塊和樁模塊的一般設(shè)計原則如下：(1)應(yīng)考慮到測試結(jié)論的有效性決定于單元測試環(huán)境下模擬目標(biāo)環(huán)境(程序)執(zhí)行的精確度，即設(shè)計驅(qū)動模塊和樁模塊時應(yīng)能考慮到測試用例執(zhí)行所應(yīng)滿足的所有環(huán)境因素(前置條件、后置條件等);(2)應(yīng)充分考慮到測試過程的迭代性，使驅(qū)動模塊和樁模塊在回歸測試中盡量能不經(jīng)修改直接使用，提高重用性，進(jìn)而提高回歸測試效率。這些原則具體體現(xiàn)在如下方面：(1)盡量結(jié)合已有的測試用例來設(shè)計測試數(shù)據(jù)，使樁模塊在最重要的功能和數(shù)據(jù)上實(shí)現(xiàn)對原始模塊的正確模擬；(2)盡量使用已有測試用例的測試數(shù)據(jù)來驅(qū)動被測單元，降低設(shè)計和編寫驅(qū)動模塊的工作量；(3)將測試數(shù)據(jù)和測試腳本分離，使測試代碼與測試數(shù)據(jù)無關(guān)，提高重用性和靈活性。驅(qū)動模塊和樁模塊的設(shè)計2.驅(qū)動模塊的功能要求驅(qū)動模塊需完成的功能如下：(1)利用已有的測試用例，接收測試的輸入數(shù)據(jù)。實(shí)現(xiàn)方式是通過外部調(diào)用的方式從數(shù)據(jù)文件或外部數(shù)據(jù)源中依次讀入數(shù)據(jù)(包括測試用例的輸入和對應(yīng)的預(yù)期輸出)。(2)將測試數(shù)據(jù)傳遞給被測單元，從而啟動被測單元。實(shí)現(xiàn)方式是調(diào)用被測單元，同時利用參數(shù)傳遞將輸入數(shù)據(jù)傳給被測單元。(3)打印和輸出測試用例的相關(guān)結(jié)果，判斷測試是通過還是失敗。即利用結(jié)果的比較加以判斷，在允許的誤差條件下，一致的結(jié)果表明測試通過，否則視為測試失敗。執(zhí)行結(jié)果可以直接輸出到屏幕，也可以保存到指定的外部文件中。(4)通過測試日志文件記錄測試過程，便于后續(xù)數(shù)據(jù)保存和分析。日志文件中應(yīng)能區(qū)分被測對象、測試用例的基本信息、測試執(zhí)行結(jié)果是否通過、失敗用例的具體錯誤信息、測試用例通過率等內(nèi)容。驅(qū)動模塊和樁模塊的設(shè)計3.樁模塊的功能要求樁模塊需完成的功能如下：(1)在特定條件下完成原單元的基本功能。即針對特定的輸入可以輸出正確的結(jié)果。注意：這里所謂的完成功能其實(shí)并非真正在模塊內(nèi)部去執(zhí)行某些復(fù)雜的邏輯判斷或計算過程，而是簡單地批量“打印”而已，只針對測試用例的一組輸入直接返回預(yù)期輸出。(2)能夠被正確調(diào)用。即符合正確的輸入條件，在個數(shù)、參數(shù)類型、參數(shù)順序等方面與被模擬單元完全一致。(3)有返回值。若有返回值，則應(yīng)針對特定輸入返回與被模擬單元完全一致的結(jié)果。(4)不包含原單元的所有細(xì)節(jié)。原單元的輸入情況可能是無限多的，所謂模擬意味著僅挑選其中典型的輸入(如邊界)，給出已知的輸出結(jié)果。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計1.問題描述及代碼說明賬單優(yōu)惠計算問題主要是根據(jù)賬單的消費(fèi)數(shù)額大小，給予不同程度的折扣優(yōu)惠，具體折扣優(yōu)惠規(guī)則為：(1)當(dāng)賬單上一次性消費(fèi)數(shù)額為負(fù)數(shù)或零時，返回負(fù)數(shù)表示消費(fèi)數(shù)額無效；(2)當(dāng)賬單上一次性消費(fèi)數(shù)額在800元到1800元之間時(不含800元，但包含1800元)，為9折；(3)當(dāng)賬單上一次性消費(fèi)數(shù)額在1800元到4800元之間時(含4800元)，為8折；(4)當(dāng)賬單上一次性消費(fèi)數(shù)額在4800元以上時(不含4800元)，一律為7折；(5)當(dāng)賬單上的消費(fèi)數(shù)額無效時，程序應(yīng)提示消費(fèi)數(shù)額無效。受篇幅限制，根據(jù)上述問題描述編寫的程序代碼附在本書教學(xué)資源包內(nèi)。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計2.程序編譯執(zhí)行首先對該段程序進(jìn)行編譯，由于沒有語法錯誤，因此編譯通過。接著運(yùn)行程序，隨便輸入幾個數(shù)值，如-300、600、1000、5000等，觀察程序執(zhí)行結(jié)果，查看結(jié)果是否符合預(yù)期。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計3.測試用例設(shè)計首先從黑盒的角度設(shè)計測試用例，不妨采用等價類測試和邊界值測試方法，得到的測試用例如表7.1所示。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計其次，選擇路徑覆蓋指標(biāo)來評價所設(shè)計的測試用例。圖7.2給出了函數(shù)FuncRevenueAccount()的程序圖。圖中顯示，程序環(huán)復(fù)雜度為6，對應(yīng)6條路徑，但因子路徑8→10→12和8→10→11永遠(yuǎn)不可能執(zhí)行到，實(shí)際只有4條可執(zhí)行路徑，測試用例RA-UT-001到RA-UT-004可以實(shí)現(xiàn)對這4條路徑的覆蓋：Path1:1，2，4，5，12，13(對應(yīng)測試用例RA-UT-001)Path2:1，2，4，6，7，12，13(對應(yīng)測試用例RA-UT-002)Path3:1，2，4，6，8，9，12，13(對應(yīng)測試用例RA-UT-003)Path4:1，2，4，6，8，10，11(對應(yīng)測試用例RA-UT-004)捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計4.測試驅(qū)動開發(fā)本例中，測試驅(qū)動程序應(yīng)具體實(shí)現(xiàn)的功能如下：(1)設(shè)置統(tǒng)計和記錄程序執(zhí)行結(jié)果所需的局部變量。(2)打開存儲測試用例相關(guān)信息的數(shù)據(jù)文件。(3)讀入一批測試用例，對于每個測試用例：①讀入基本信息并顯示出來，包括測試用例的ID、輸入數(shù)據(jù)、預(yù)期輸出；②利用測試用例來驅(qū)動(調(diào)用)被測函數(shù)；③顯示測試用例的實(shí)際輸出，經(jīng)與預(yù)期輸出比較后，判斷該用例是否通過，并顯示比較結(jié)果，同時將執(zhí)行結(jié)果輸出到結(jié)果記錄的日志文件。(4)統(tǒng)計這批測試用例的執(zhí)行情況，如執(zhí)行率、通過率、失敗率等。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計在主函數(shù)中調(diào)用該測試驅(qū)動程序即可執(zhí)行測試。本例中采用記事本來記錄測試用例的基本信息，數(shù)據(jù)文件TCDatal.cxt中每行數(shù)據(jù)依次對應(yīng)：測試用例ID、測試用例的輸入值、測試用例的預(yù)期輸出值，具體內(nèi)容如圖7.3所示。5.測試執(zhí)行測試用例執(zhí)行之后的結(jié)果存儲在測試日志文件中，不妨仍用記事本存儲。對于本例，日志文件FuncRevenueAccountTestResult.txt的內(nèi)容如圖7.4所示。捉蟲實(shí)踐1:賬單計算問題的驅(qū)動設(shè)計6.測試分析在本次單元測試實(shí)踐中實(shí)際是存在問題的，體現(xiàn)在如下方面。(1)虛假的安全感。測試用例16的正確執(zhí)行路徑是沿著Path5執(zhí)行，并返回-1.0，而實(shí)際因代碼存在缺陷，導(dǎo)致不可能執(zhí)行到語句10，而是沿著路徑Path1執(zhí)行，結(jié)果正好也是返回-1.0。表面上看起來，用例16的實(shí)際輸出與預(yù)期輸出相同，判定為用例通過，事實(shí)上只是巧合而已。這也從另一方面說明僅進(jìn)行黑盒測試是不夠的，還應(yīng)針對源代碼本身展開白盒測試。(2)靜態(tài)測試先行。在對代碼執(zhí)行測試之前，應(yīng)優(yōu)先進(jìn)行靜態(tài)檢查，這樣應(yīng)該可以檢查出語句2的缺陷，這比通過動態(tài)測試發(fā)現(xiàn)缺陷要更加直接和快速。(3)測試用例評審。在設(shè)計測試用例后，應(yīng)對其進(jìn)行評審，判斷是否有漏洞、冗余，是否能體現(xiàn)其有效性，這樣才能有效避免虛假的測試用例通過率。(4)測試日志文件盡量簡潔。本例中的測試日志文件過于詳細(xì)，冗長的信息容易導(dǎo)致忽略掉那些失敗的測試用例。04測試需求分析測試需求概述關(guān)于測試需求，很多人都在提這個概念，但它似乎不是一個規(guī)范的概念，因?yàn)樵诠俜綑?quán)威機(jī)構(gòu)找不到關(guān)于測試需求的明確規(guī)定，因此，目前關(guān)于測試需求的定義和理解尚未達(dá)成共識。最典型的幾種認(rèn)識如下：(1)Jackei認(rèn)為，測試需求就是測試范圍，其表現(xiàn)形式并不限于表格或文本，關(guān)鍵遵循一個基本原則：每個測試需求僅包含一項(xiàng)測試內(nèi)容，且應(yīng)采用容易理解的自然語言來描述。(2)BrianMarick認(rèn)為，測試需求就是指明測試什么的規(guī)格說明，它描述了測試系統(tǒng)的行為、特性或?qū)傩?，是在測試過程中對測試的約束。(3)SAPABAPer認(rèn)為，測試需求就是測試設(shè)計，目的是細(xì)化測試計劃中描述的測試方法，確定要包含的特性和測試，確定完成測試所需的測試用例和測試規(guī)程，最后給出測試失敗和通過的標(biāo)準(zhǔn)。(4)也有人認(rèn)為，測試需求是根據(jù)程序文件和質(zhì)量目標(biāo)對軟件測試活動所提的要求，即對測試所做的一定程度的限定，使測試成本和質(zhì)量在一定程度上達(dá)成妥協(xié)。測試需求的定義軟件開發(fā)過程中，有多種類型的需求，其中：(1)用戶需求用于描述用戶使用產(chǎn)品必須要完成的任務(wù)，是軟件開發(fā)活動中最基本的需求。(2)系統(tǒng)需求用于描述軟件設(shè)計和編程人員必須完成的任務(wù)，系統(tǒng)分析員通過分析用戶需求，才能將用戶需求轉(zhuǎn)變成開發(fā)設(shè)計人員看得懂的系統(tǒng)需求。(3)測試需求用于描述軟件測試人員必須完成的任務(wù)，測試工程師通過分析系統(tǒng)需求，產(chǎn)生測試需求，作為測試活動的指導(dǎo)。因此，可將測試需求看做系統(tǒng)需求與測試用例之間的橋梁，即先從系統(tǒng)需求中提取測試需求，然后針對測試需求進(jìn)行逐步細(xì)化，并設(shè)計測試用例。測試需求的屬性測試需求的屬性包括：(1)ID。用于唯一標(biāo)識一個測試需求，可采用形如“REQ-A系統(tǒng)-B模塊-001”的編碼方式。(2)所屬功能模塊名。用于說明該測試需求所對應(yīng)的功能模塊或子系統(tǒng)的名稱。(3)評審狀態(tài)。用于測試需求的跟蹤，一般包含創(chuàng)建、變更、評審三種狀態(tài)。(4)重要性。用于度量測試需求的重要程度，可根據(jù)該測試需求所對應(yīng)的業(yè)務(wù)需求的重要性進(jìn)行度量，重要性的設(shè)定是一種客觀評價，一般包含如下4種級別：①核心：針對必不可少的業(yè)務(wù)需求及核心業(yè)務(wù)流程，該級別的測試需求在產(chǎn)品發(fā)布前必須測試通過，否則用戶將不會簽字驗(yàn)收通過；②重要：針對關(guān)鍵功能需求和重要的非功能需求及業(yè)務(wù)流程，該級別的測試需求在產(chǎn)品發(fā)布前也必須測試通過，否則將影響客戶滿意度；③一般：針對滿足特定用戶或業(yè)務(wù)需求的功能，該級別的測試需求不會對客戶滿意度造成太大的影響，是否通過測試不會影響到產(chǎn)品的發(fā)布；④可選：指一般測試需求，受資源、時間約束無法按期驗(yàn)證的測試需求。測試需求的屬性(5)穩(wěn)定性。用于表明該測試需求在測試實(shí)施過程中可能發(fā)生變更的概率，對測試需求穩(wěn)定性影響最大的因素一般是業(yè)務(wù)需求的變化，通常包含高、中、低三種級別。(6)工作量。用于表明后續(xù)測試實(shí)施過程中，為完全覆蓋該測試需求而需要的工作量，主要與該測試需求對應(yīng)的業(yè)務(wù)需求復(fù)雜程度及業(yè)務(wù)流程繁簡程度相關(guān)，一般采用百分制。(7)優(yōu)先級。用于表明該測試需求實(shí)施的優(yōu)先次序，需結(jié)合“重要性”、“穩(wěn)定性”和“工作量”3個屬性來設(shè)定，優(yōu)先級的設(shè)定是一種主觀評價，一般包含高、中、低3種級別。(8)需求版本。用于記錄該測試需求對應(yīng)的測試版本號。(9)功能點(diǎn)描述。用于描述該測試需求對應(yīng)的業(yè)務(wù)功能，一個測試需求僅對應(yīng)一個功能點(diǎn)。(10)業(yè)務(wù)規(guī)則描述。用于描述與該測試需求相對應(yīng)業(yè)務(wù)功能的邏輯約束，可采用R1～R9進(jìn)行編號。業(yè)務(wù)規(guī)則可從需求描述中的備注或例外情況來獲取。(11)創(chuàng)建人。用于記錄該測試需求的創(chuàng)建人。(12)創(chuàng)建日期。用于記錄該測試需求的創(chuàng)建日期。測試需求的分析測試需求的分析過程是用戶需求→系統(tǒng)需求→測試需求的過程，說明如下。(1)用戶定義業(yè)務(wù)需求用戶提出的用戶需求是較為籠統(tǒng)的。例如，UR1能上網(wǎng)繳電話費(fèi)。(2)系統(tǒng)分析師提取系統(tǒng)需求系統(tǒng)分析師通過分析用戶需求，將其轉(zhuǎn)換為便于開發(fā)人員理解的系統(tǒng)需求，是在技術(shù)層面上對用戶需求的分析，將用戶需求分解成若干功能點(diǎn)，所有功能點(diǎn)應(yīng)100%覆蓋用戶需求。(3)測試人員提取測試需求測試分析師應(yīng)對照系統(tǒng)需求，分析測試需求，所有測試需求應(yīng)100%覆蓋系統(tǒng)需求。(4)測試工程師設(shè)計測試用例根據(jù)測試需求，測試工程師應(yīng)將其細(xì)化為具體的測試用例。所有測試用例應(yīng)100%覆蓋測試需求。應(yīng)注意的問題測試需求的提取從業(yè)務(wù)需求中分解得到，從整個項(xiàng)目目標(biāo)開始，逐步從每個業(yè)務(wù)需求中對應(yīng)抽取一條或多條測試需求，對每個測試需求再進(jìn)行細(xì)化，得到一個有關(guān)測試需求的樹形結(jié)構(gòu)。提取測試需求時，最應(yīng)注意的是隱式需求，包括如下方面的內(nèi)容。(1)用戶隱式的需求(2)計算機(jī)領(lǐng)域的規(guī)范或習(xí)慣(3)用戶認(rèn)為開發(fā)方應(yīng)該理解的需求認(rèn)識的誤區(qū)測試需求與可測試性需求是兩個完全不同的概念。測試需求可以理解為針對要實(shí)現(xiàn)的功能或性能，從測試的角度來看，需要測試的特性，其關(guān)鍵點(diǎn)在于它是一種測試分析活動的產(chǎn)物。測試需求面向功能點(diǎn)，針對每個功能點(diǎn)，都需要提取其測試需求，進(jìn)而設(shè)計測試用例。可測試性需求是指需求分析時應(yīng)注意需求的可測試性要求，其關(guān)鍵點(diǎn)在于它是需求分析活動的產(chǎn)物。例如，軟件模塊的調(diào)試與測試的可測試性需求關(guān)鍵在于設(shè)置測試控制序列、狀態(tài)觀測點(diǎn)和輸入輸出機(jī)制的需求，主要考慮的內(nèi)容有：(1)方便控制軟件模塊的調(diào)試與測試，即軟件模塊調(diào)試測試控制點(diǎn)的選擇和測試序列導(dǎo)入機(jī)制的設(shè)計；(2)方便觀察軟件模塊的調(diào)試與測試，即軟件模塊調(diào)試測試觀察點(diǎn)的選擇和輸出機(jī)制設(shè)計；(3)軟件產(chǎn)品特性的可測試性需求，即方便測試產(chǎn)品的具體特性；(4)軟件公共可測試性需求，如操作系統(tǒng)中的內(nèi)存管理；(5)軟件內(nèi)建測試能力可測試性需求，如跟蹤機(jī)制、記錄機(jī)制、測試接口需求等。捉蟲實(shí)踐2:轄區(qū)移交問題的測試需求分析選取某系統(tǒng)中的一個子功能模塊，來看看其測試需求是怎樣的。1.功能需求描述轄區(qū)移交是某系統(tǒng)前臺功能中設(shè)備管理模塊的一個子模塊，有關(guān)該模塊的需求說明如表7.2所示。捉蟲實(shí)踐2:轄區(qū)移交問題的測試需求分析2.測試需求分析對應(yīng)上述功能需求，得到測試項(xiàng)為：修改轄區(qū)所屬二級單位，將轄區(qū)移交給其他二級單位負(fù)責(zé)，編號DM1.13，由此得到測試需求如表7.3所示。捉蟲實(shí)踐2:轄區(qū)移交問題的測試需求分析3.測試用例設(shè)計以測試需求DM1.13.1為例，設(shè)計的部分測試用例見表7.4。捉蟲實(shí)踐2:轄區(qū)移交問題的測試需求分析4.測試分析

從表7.4可以看出，測試需求均是圍繞功能需求，從功能執(zhí)行的前提條件、例外情況、備注等方面提取需要測試的內(nèi)容，但每個測試需求中只說明了測試對象在輸入方面應(yīng)滿足的約束關(guān)系，并未嚴(yán)格限定具體的取值。測試需求主要受到需求和設(shè)計變化的影響，如業(yè)務(wù)流程的變化、功能的增刪等，不會受到代碼修改的影響。而測試用例則對輸入的規(guī)定相對更加具體、詳細(xì)，當(dāng)代碼變化時(如函數(shù)接口)，底層測試用例將發(fā)生變化。從測試需求與測試用例的對應(yīng)關(guān)系來說，一般地，一個測試需求將對應(yīng)多個測試用例。測試需求在功能需求與測試用例之間起到連接作用，測試需求更像是測試設(shè)計，指出了測試用例設(shè)計的方向。且測試需求與代碼實(shí)現(xiàn)基本無關(guān)，更加有利于測試的復(fù)用和維護(hù)。05單元測試的過程測試過程概述單元測試的過程與第1章在軟件測試的定義中所討論的軟件測試的過程是一致的，可劃分為如下5個階段：①計劃階段：完成單元測試計劃，制訂單元測試策略；②設(shè)計階段：根據(jù)單元測試計劃，提取測試需求，完成測試設(shè)計；③實(shí)施階段：根據(jù)測試用例開發(fā)測試數(shù)據(jù)或測試腳本，并建立單元測試環(huán)境，準(zhǔn)備正式開始測試執(zhí)行；④執(zhí)行階段：以手動方式或利用測試腳本自動執(zhí)行單元測試用例，記錄測試結(jié)果；⑤評估階段：利用測試用例和缺陷計算相關(guān)指標(biāo)，評估階段性測試過程和結(jié)果，做出決策。測試過程概述以上階段可用一個過程模型來描述，見圖7.5。測試過程概述圖中表明，單元測試中有兩個關(guān)鍵時間點(diǎn)：測試就緒點(diǎn)和評估就緒點(diǎn)。(1)測試就緒點(diǎn)在該測試就緒點(diǎn)之前，是測試計劃、設(shè)計和實(shí)施階段，也是測試正式開始之前需做的工作。(2)評估就緒點(diǎn)一旦測試就緒，就可以正式開始測試執(zhí)行階段。在本階段，無論是手動執(zhí)行測試，還是以自動化方式執(zhí)行測試，都需要檢查每個測試用例的實(shí)際輸出結(jié)果與預(yù)期輸出結(jié)果之間的差異，在評估就緒點(diǎn)上經(jīng)過評估，得出結(jié)論。計劃階段1.測試計劃大綱測試計劃是測試人員與開發(fā)人員之間交流意圖的主要方式，最終目標(biāo)是交流(而非記錄)測試小組的意圖、期望和對測試任務(wù)的理解。IEEE829標(biāo)準(zhǔn)的測試計劃模板如圖7.6所示。當(dāng)然，不同公司和項(xiàng)目小組會根據(jù)自己的實(shí)際需要來制訂自己的測試計劃，只要能夠達(dá)到有效交流的目的即可，無須拘泥于一個唯一的格式。這里以EEE829標(biāo)準(zhǔn)測試計劃模板為例，具體說明測試計劃中各項(xiàng)內(nèi)容的具體含義。計劃階段2.測試計劃內(nèi)容(1)引言引言一般包含以下幾方面內(nèi)容：①目的。②背景。③范圍。④參考文檔。⑤常用術(shù)語。(2)測試范圍測試范圍包括測試項(xiàng)、要測試的特性和不測試的特性。①測試項(xiàng)。②要測試的特性。③不測試的特性。(3)測試方法即測試策略，它描述測試小組用于測試整體和各階段的方法。計劃階段(4)測試階段每個測試階段都應(yīng)有客觀定義的規(guī)則，而不能主觀地單純靠拍腦袋來決定某測試階段是否應(yīng)該開始，是否應(yīng)該結(jié)束。(5)測試交付品測試交付品是指測試階段結(jié)束時應(yīng)提交的文檔，一般包括測試計劃說明書、測試方案(或測試設(shè)計說明書)、測試用例說明書、缺陷報告、測試總結(jié)評估報告等。(6)測試任務(wù)測試任務(wù)主要指整個項(xiàng)目小組的相關(guān)任務(wù)和職責(zé)劃分，重要的是明確指出可能影響測試的任務(wù)和交付內(nèi)容，并確保一旦出了問題，可以迅速找到責(zé)任人來處理問題，并在出現(xiàn)糾紛時，能夠快速找到解決糾紛的仲裁人并提出仲裁方案。計劃階段(7)資源需求測試資源包括：①人力資源：測試所需的人員數(shù)目、各自的特長；②測試環(huán)境：測試所需的軟硬件環(huán)境、網(wǎng)絡(luò)環(huán)境，以及可能需要的測試工具(8)職責(zé)職責(zé)主要是指測試小組的任務(wù)劃分，即哪些人員負(fù)責(zé)哪些軟件部分的測試。(9)人員配置和培訓(xùn)需求關(guān)于人員培訓(xùn)需求部分的內(nèi)容，有觀點(diǎn)認(rèn)為，人員培訓(xùn)需求是一項(xiàng)長期的工作，應(yīng)由測試部門統(tǒng)一規(guī)劃，并非單個項(xiàng)目的需求，不必列在測試計劃中。計劃階段(10)進(jìn)度即甘特圖。明確指出哪些人在什么階段負(fù)責(zé)對軟件哪些部分的測試工作。由于測試任務(wù)往往依賴于前期其他交付內(nèi)容的完成，進(jìn)度表中應(yīng)注意采用相對日期來劃分階段，并給出一定寬松度，以應(yīng)對突發(fā)事件。(11)風(fēng)險和不測事件不考慮風(fēng)險就等于接受失敗。特別是好的開發(fā)過程應(yīng)對風(fēng)險管理實(shí)行全局管理方法。這里的風(fēng)險主要考慮與測試相關(guān)的人員和資源風(fēng)險，如人員的流失、資源的到位和使用風(fēng)險等。(12)批準(zhǔn)所有文檔均應(yīng)經(jīng)過評審、審批并通過后，才能進(jìn)入下一個測試階段。這也是責(zé)任劃分的一個有力措施。計劃階段3.注意事項(xiàng)撰寫測試計劃應(yīng)注意以下幾點(diǎn)：(1)測試計劃重在計劃，不在于文檔。再漂亮的計劃說明書，都是擺設(shè)，應(yīng)從項(xiàng)目實(shí)際情況出發(fā)，對測試工作切實(shí)起到指導(dǎo)作用，不能寫完計劃后就讓其束之高閣了。(2)測試計劃自身應(yīng)不斷精確和細(xì)化，逐步完善豐富。(3)測試計劃應(yīng)及時更新。隨著項(xiàng)目需求和設(shè)計的不斷變更，測試計劃應(yīng)及時跟蹤這些變化，做出相應(yīng)的調(diào)整，并對所有變更記錄在案。另外，軟件測試計劃是測試負(fù)責(zé)人管理和跟蹤的依據(jù)，同時起到指導(dǎo)測試組日常工作的作用。當(dāng)實(shí)際情況與計劃偏離到一定程度時，也應(yīng)立即修正測試計劃。(4)測試計劃不一定要很長，但要說明幾點(diǎn)問題，即測試對象、測試進(jìn)度里程碑、測試方法和工具、測試人員及測試文檔。(5)就測試的實(shí)施過程來講，軟件測試應(yīng)按照測試計劃制訂的內(nèi)容進(jìn)行。測試計劃是項(xiàng)目跟蹤的依據(jù)，通過與實(shí)際開發(fā)進(jìn)展情況做比較分析，項(xiàng)目經(jīng)理可以及時了解項(xiàng)目開發(fā)的狀態(tài)。測試組中的每個成員都應(yīng)準(zhǔn)確了解測試計劃的內(nèi)容，并對所分配的任務(wù)承諾簽字，確保測試計劃的貫徹執(zhí)行。設(shè)計階段單元測試計劃經(jīng)評審無誤后進(jìn)入設(shè)計階段。該階段的主要任務(wù)是進(jìn)行單元測試設(shè)計，提取測試需求，設(shè)計單元測試用例。該階段的主要依據(jù)是軟件詳細(xì)設(shè)計說明書和單元測試計劃說明書。單元測試設(shè)計說明書中應(yīng)指出被測單元的測試需求，并對應(yīng)不同的測試需求設(shè)計測試用例，確定具體的測試輸入和預(yù)期輸出。在該階段，若采用不同的單元測試策略，將產(chǎn)生數(shù)量不同的驅(qū)動模塊和樁模塊。該階段完成時，需提交單元測試設(shè)計說明書和單元測試用例說明書。同樣地，在開始后續(xù)階段之前，應(yīng)對設(shè)計實(shí)現(xiàn)階段提交的所有測試文檔(包括測試設(shè)計說明書、測試用例說明書等)進(jìn)行嚴(yán)格的評審。進(jìn)行單元測試設(shè)計時應(yīng)考慮項(xiàng)目進(jìn)度、測試粒度和測試密度。(1)項(xiàng)目進(jìn)度：項(xiàng)目進(jìn)度應(yīng)考慮適當(dāng)放寬，即將風(fēng)險因素加入進(jìn)來，不能將進(jìn)度卡得太緊，否則沒有一點(diǎn)冗余度，測試只能以降低質(zhì)量標(biāo)準(zhǔn)來換取按進(jìn)度的交付。設(shè)計階段(2)測試粒度：如何定義單元，對于傳統(tǒng)面向過程的軟件測試而言，即選擇多大的功能單元作為單元測試的基本單元，是函數(shù)級還是模塊級。粒度越細(xì)，發(fā)現(xiàn)缺陷的概率越大，但同時測試工作量越大。(3)測試密度：單元測試用例的語句覆蓋率，即每千行代碼中包含的測試用例數(shù)目。測試粒度越精細(xì)，測試密度越高，單元測試越接近完美。然而測試不追求完美，夠用即可，千萬不要為了測試而測試。單元測試用例太多，測試代碼編寫的工作量太大。因此，若采用函數(shù)級的單元測試粒度，可根據(jù)函數(shù)的復(fù)雜度進(jìn)行篩選，僅針對復(fù)雜度高的函數(shù)編寫單元測試；而設(shè)計測試用例時，至少以關(guān)鍵路徑測試覆蓋指標(biāo)作為測試密度的標(biāo)準(zhǔn)，確保被測對象經(jīng)單元測試之后，能夠找出最嚴(yán)重或風(fēng)險最高的缺陷。實(shí)施階段單元測試實(shí)施階段主要工作是對照測試用例，開發(fā)測試驅(qū)動模塊和樁模塊。該階段的主要依據(jù)是單元測試設(shè)計說明書，根據(jù)測試用例的輸入和預(yù)期輸出要求編寫驅(qū)動和樁模塊來驅(qū)動測試用例的執(zhí)行。該階段完成時需提交單元測試程序。因單元測試程序的本質(zhì)仍然是可執(zhí)行的代碼，因此，對這類程序也是需要進(jìn)行靜態(tài)檢查和編譯的，以確保測試程序的正確性。當(dāng)然，實(shí)現(xiàn)對代碼進(jìn)行測試的方式有很多，例如，在開發(fā)源代碼中直接加入斷點(diǎn)(和調(diào)試相似)?；蛘呖梢酝ㄟ^調(diào)用被測函數(shù)，輸入一些測試數(shù)據(jù)，觀察實(shí)際執(zhí)行情況與預(yù)期情況之間的差異?；蛘?，可以針對被測對象編寫專門的測試代碼，并專門對這些代碼進(jìn)行組織和管理，這當(dāng)然是推薦的方式，這樣測試程序可以重復(fù)執(zhí)行，將程序員從反復(fù)的調(diào)試中解放出來，且不必對開發(fā)代碼進(jìn)行任何有關(guān)測試的修改，從而提高回歸測試的效率。實(shí)施階段編寫單元測試代碼時，應(yīng)遵循以下的基本原則：(1)不要將測試用例的執(zhí)行結(jié)果打印輸出到屏幕若將所有測試用例的執(zhí)行結(jié)果輸出到屏幕，就需要測試人員一直守在屏幕旁邊，盯著屏幕核對每一個輸出結(jié)果與預(yù)期結(jié)果是否一致，這樣既容易疲勞又容易出錯。(2)將測試代碼與開發(fā)代碼分開應(yīng)將所有用于測試的程序文件放在特殊目錄下，該目錄不應(yīng)距離被測代碼太遠(yuǎn)，更不能混在一起，可選的方案是將被測程序代碼的副本與被測代碼放在一起，然而這樣的弊端是必須及時更新，確保每次測試的版本正確。實(shí)施階段(3)所有測試方法以test開頭，測試代碼分組放置所有測試方法都以test開頭，可以方便地了解該段測試代碼是針對哪些方法或函數(shù)展開的測試。(4)在一個單獨(dú)的測試中避免多重聲明一個測試方法往往是針對某個測試用例所寫的，而測試用例中可能包含多組輸入情況，針對預(yù)期輸出與實(shí)際輸出的比較，通常利用assert語句來實(shí)現(xiàn)。(5)測試正確的事情失敗測試并不代表該測試用例執(zhí)行后必須失敗。(6)測試非正常失敗可能是碰到了沖突的需求一般來說，測試非正常失敗可能是一個新的需求(一個改變的特性)與一個舊的可能已不再有效的需求發(fā)生了沖突。執(zhí)行階段測試代碼開發(fā)完成后進(jìn)行單元測試執(zhí)行階段。該階段的主要任務(wù)是執(zhí)行測試用例，判斷測試用例是否通過，記錄測試中發(fā)現(xiàn)的缺陷，生成和提交缺陷報告，并將報告及時反饋給開發(fā)小組，敦促缺陷得到盡早修復(fù)。該階段的主要依據(jù)是單元測試用例說明書、軟件需求規(guī)格說明書和軟件詳細(xì)設(shè)計說明書。評估階段測試執(zhí)行后，需要對測試的情況進(jìn)行評估和總結(jié)。主要任務(wù)包括對測試完備性和代碼覆蓋率等指標(biāo)進(jìn)行評估，從而判斷單元測試的質(zhì)量如何，是否可以退出單元測試進(jìn)入后續(xù)環(huán)節(jié)的集成測試階段。其主要依據(jù)是單元測試用例、缺陷跟蹤報告、缺陷檢查表等。對測試的評估可從兩方面進(jìn)行：(1)對測試用例執(zhí)行情況的評估利用測試用例的相關(guān)統(tǒng)計數(shù)字來對測試進(jìn)行評估，主要目的是評價測試的質(zhì)量，包括測試用例滿足語句覆蓋和判定覆蓋的情況怎樣，測試用例的執(zhí)行率和通過率怎樣，從中可以看出設(shè)計的測試用例是否存在漏洞，測試用例對源代碼和對需求的覆蓋程度如何。評估階段(2)對缺陷情況的評估利用缺陷相關(guān)統(tǒng)計數(shù)據(jù)來對測試進(jìn)行評估，主要目的是判斷被測系統(tǒng)的質(zhì)量，包括缺陷在不同子系統(tǒng)不同模塊中的分布情況、缺陷在不同測試階段的分布情況、缺陷的走勢(如累計打開缺陷數(shù)目、累計關(guān)閉缺陷數(shù)量、每輪測試的遺漏缺陷數(shù)目等)，從中可以看出被測系統(tǒng)的質(zhì)量如何，是否可以進(jìn)入下一個測試環(huán)節(jié)等。同時也可以看出，當(dāng)前階段的測試活動和開發(fā)活動是否存在嚴(yán)重的管理問題。單元測試的執(zhí)行和評估往往不是相互分離的，在單元測試執(zhí)行和評估階段完成時需提交單元測試總結(jié)報告。06日構(gòu)建日構(gòu)建的概念日構(gòu)建(DailyBuild)是自動、完整地構(gòu)建整個代碼庫的代碼，在構(gòu)建的同時完成單元測試執(zhí)行的軟件研發(fā)工作模式。所謂日構(gòu)建并非一定要每日構(gòu)建一次，實(shí)際上可以根據(jù)需要更加頻繁地構(gòu)建(如一天構(gòu)建幾次)，但統(tǒng)一稱為日構(gòu)建。日構(gòu)建的過程日構(gòu)建一般在晚上進(jìn)行，白天由程序員完成編碼后，提交給配置管理員，代碼入庫后啟動編譯和運(yùn)行工作，且構(gòu)建一般無須人工參與，而是由構(gòu)建腳本驅(qū)動整個目錄代碼文件的編譯和連接，形成可執(zhí)行的程序。具體的構(gòu)建過程是：(1)安裝在構(gòu)建服務(wù)器上的自動化構(gòu)建腳本從CVS(版本)服務(wù)器上下載導(dǎo)出完整的最新源代碼，并進(jìn)行編譯鏈接；(2)如果可以運(yùn)行并能執(zhí)行最基本的功能，構(gòu)建服務(wù)器就會將程序打包成安裝文件，并上傳到整個團(tuán)隊(duì)均可訪問的Web服務(wù)器上；(3)如果程序執(zhí)行遇到了問題，則會自動將錯誤日志以電子郵件形式通知整個團(tuán)隊(duì)，或?qū)?yīng)的提交人員；(4)同時，構(gòu)建腳本也會將當(dāng)前構(gòu)建過程和結(jié)果生成某種形式的報告(如HTML形式)，自動發(fā)布到內(nèi)部網(wǎng)站(即之前的Web服務(wù)器)。日構(gòu)建腳本的開發(fā)由于整個構(gòu)建過程均需由構(gòu)建腳本自動完成，因此，構(gòu)建人員必須編寫腳本來完成以上功能?？梢允褂萌魏我环N腳本語言或程序語言來實(shí)現(xiàn)，常用于編寫構(gòu)建腳本的語言包括TCL、Perl、Python等。在構(gòu)建腳本開發(fā)過程中，需注意建立版本服務(wù)器、配置好目錄結(jié)構(gòu)、做好版本管理規(guī)則設(shè)定、構(gòu)建規(guī)則設(shè)定、缺陷修復(fù)規(guī)則設(shè)置等工作。特別地，日構(gòu)建通常與冒煙測試(SmokeTesting，一種較為隨機(jī)的一般不用參照測試用例的測試類型)聯(lián)系在一起，如果希望日構(gòu)建時執(zhí)行冒煙測試，則需使用測試框架來調(diào)用被測單元模塊代碼，并在測試框架中編寫測試代碼，完成測試數(shù)據(jù)的加載和執(zhí)行，這會額外增加測試的難度和工作量。但是，將日構(gòu)建與冒煙測試結(jié)合起來，可對每日提交的產(chǎn)品代碼完成初步的質(zhì)量度量，一旦冒煙測試不能通過，通常不會啟動測試計劃，因?yàn)閷Α袄碑a(chǎn)品執(zhí)行測試是沒有意義的。日構(gòu)建的優(yōu)勢日構(gòu)建的優(yōu)勢在于：(1)進(jìn)度可見、可控通過日構(gòu)建可將開發(fā)進(jìn)度控制到1～2天的粒度，有利于了解進(jìn)度偏差，及時調(diào)整進(jìn)度。(2)適于多環(huán)境下的團(tuán)隊(duì)研發(fā)當(dāng)被開發(fā)的產(chǎn)品需要適應(yīng)多種語言、多操作系統(tǒng)且有多個版本同時研發(fā)時，通過日構(gòu)建可幫助開發(fā)人員將重點(diǎn)放在自己使用的環(huán)境下，而不需要在所有的環(huán)境中運(yùn)行自己的代碼。(3)便于盡早發(fā)現(xiàn)、修復(fù)和驗(yàn)證缺陷在日構(gòu)建過程中發(fā)現(xiàn)的缺陷將自動發(fā)送電子郵件到代碼的編寫者，便于程序員盡早對缺陷進(jìn)行確認(rèn)和處理。(4)增量測試通過每日構(gòu)建將大集成分解為小集成，不但易于進(jìn)行缺陷定位，而且充分體現(xiàn)了增量測試的思想。日構(gòu)建的不足日構(gòu)建的不足體現(xiàn)在如下方面：(1)給開發(fā)人員的壓力太大，開發(fā)環(huán)境較緊張，不利于開發(fā)人員創(chuàng)造性思維的發(fā)揮；(2)加重了開發(fā)經(jīng)理的工作負(fù)擔(dān)，要求其將功能細(xì)化到1～2天之內(nèi)，并有明確輸出的功能點(diǎn)；(3)開發(fā)小組需投入額外的精力來保證每日構(gòu)建的順暢；(4)需要額外的人手來負(fù)責(zé)冒煙測試，以及維護(hù)每日構(gòu)建的硬件環(huán)境。07回歸測試回歸測試的定義和目的回歸測試是貫穿在整個測試各個階段的一個測試活動，主要是對修改過的軟件重新進(jìn)行測試，以保證驗(yàn)證修改的正確性及其影響。軟件的修改可能是由于需求的變化導(dǎo)致加入新的功能模塊，也可能是為了修復(fù)缺陷而對代碼或界面進(jìn)行的改動，這種改動將導(dǎo)致如下問題：(1)新加入的功能模塊可能對原有的模塊產(chǎn)生影響，引入新的缺陷；(2)缺陷修復(fù)后僅在上報的條件下不再出現(xiàn)，而在其他條件下再次出現(xiàn)，原因是程序員通過編寫特殊代碼段來對缺陷的外在表現(xiàn)進(jìn)行修正，并未修復(fù)缺陷本身，造成修復(fù)失??；(3)缺陷修復(fù)后導(dǎo)致新的缺陷出現(xiàn)，原因是程序員盲目改動代碼，不做任何檢查，導(dǎo)致軟件未被修改的部分產(chǎn)生新的缺陷?；貧w測試的定義和目的統(tǒng)計數(shù)據(jù)表明，多達(dá)一半的缺陷修復(fù)在首次測試驗(yàn)證中是通不過的。因此，每當(dāng)軟件發(fā)生變化時，必須對現(xiàn)有功能進(jìn)行重新測試，目的主要在于：(1)確保缺陷真正得到了修復(fù)。為了杜絕程序員僅修復(fù)了缺陷報告中的癥狀，而并非真正修復(fù)根本缺陷，應(yīng)在程序的其他位置嘗試更多測試用例，充分進(jìn)行此類測試；(2)防止在缺陷修復(fù)或功能變化過程中造成對軟件原有正常部分代碼的損壞；(3)防止由于開發(fā)人員自身因素或其他因素導(dǎo)致的版本倒流現(xiàn)象(例如測試中發(fā)現(xiàn)曾經(jīng)改好的缺陷又出現(xiàn)了，可能就是個別文件版本錯誤導(dǎo)致);(4)防止由于其他因素造成的原正常功能的失效(例如因更換顯卡而造成界面顯示異常)?；貧w測試的策略從系統(tǒng)實(shí)現(xiàn)的角度來說，軟件的變化包括代碼的變化和用戶界面的變化(不考慮導(dǎo)致變化的原因，如需求和設(shè)計的變化)，回歸測試應(yīng)圍繞軟件的變化展開，其策略核心在于：關(guān)注功能、界面、代碼的變化，關(guān)注由此而導(dǎo)致的測試的變化。下面主要以代碼的變化來討論由此而導(dǎo)致的測試的變化。(1)關(guān)注代碼的變化所謂代碼的變化是指為了修復(fù)缺陷而改動的代碼段所在的模塊，以及與代碼修復(fù)相關(guān)的模塊。不妨設(shè)為了修復(fù)缺陷而改動的代碼段為模塊A(事實(shí)上可能不僅僅是一個模塊，還可能是多個模塊)，則與模塊A相關(guān)聯(lián)的模塊包括：①與模塊A具有調(diào)用關(guān)系的模塊，設(shè)模塊B調(diào)用模塊A，若A的輸入接口發(fā)生變化，B將無法按照原來的格式進(jìn)行參數(shù)傳遞，而若A的輸出接口變化了，B將無法按照原始格式進(jìn)行賦值或判斷；回歸測試的策略②受到模塊A的輸出結(jié)果影響的模塊，例如，模塊A輸出結(jié)果到xml文件，而模塊B從xml文件中讀取所需的數(shù)據(jù)，一旦模塊A的輸出格式發(fā)生變化，模塊B將無法按照原來的格式從xml文件中讀取數(shù)據(jù)，實(shí)際上xml文件也應(yīng)視為受到模塊A變化影響的對象；③受到模塊A的數(shù)據(jù)處理方式影響的模塊，例如，某些全局類型的變量可能在模塊A的數(shù)據(jù)處理過程中被賦值，則模塊A的變化將導(dǎo)致這些變量的賦值方式變化；④受到模塊A的結(jié)構(gòu)變化而被合并或新增的模塊，例如，當(dāng)發(fā)現(xiàn)模塊A結(jié)構(gòu)非常復(fù)雜時，可能將其改為函數(shù)調(diào)用的形式，則產(chǎn)生新增的模塊；⑤在面向?qū)ο蟪绦蛑?，還可能有類的設(shè)計變化而導(dǎo)致對應(yīng)的對象狀態(tài)的變化?；貧w測試的策略(2)關(guān)注測試的變化由軟件變化而導(dǎo)致的測試的變化主要體現(xiàn)在如下方面：①部分測試用例過時。由于需求、設(shè)計的變化，或代碼優(yōu)化的需要，導(dǎo)致部分函數(shù)被刪去或部分函數(shù)接口、數(shù)據(jù)格式、原有系統(tǒng)邊界等發(fā)生變化，則被刪去函數(shù)的測試用例將丟棄，針對變化的函數(shù)功能、變化的函數(shù)接口，以及針對系統(tǒng)邊界的那些測試用例等均不再有效，必須對應(yīng)修改，如果涉及自動化測試腳本，測試腳本需要修改，對應(yīng)的測試數(shù)據(jù)需要重新整理。②需新增部分測試用例。對于新增的功能、新增的模塊，以及新增模塊所引入的新接口、新增的對象狀態(tài)、新增狀態(tài)變遷觸發(fā)事件等，均需補(bǔ)充新的測試用例?；貧w測試的實(shí)施回歸測試的實(shí)施過程如下：①識別出被測系統(tǒng)中被修改的部分，包括需求、設(shè)計和代碼；②圍繞系統(tǒng)的變化，確定受到變化影響的功能、模塊和代碼；③針對新增的功能、模塊，補(bǔ)充測試用例；④針對不再使用的功能、模塊，丟棄過時的測試用例；⑤針對變化的功能、模塊，修改原有的測試用例，并注意進(jìn)行優(yōu)化，避免冗余；⑥針對更新的測試用例集合對新的軟件版本實(shí)施和執(zhí)行測試?；貧w測試的實(shí)施回歸測試的實(shí)施過程中應(yīng)注意以下幾點(diǎn)：(1)回歸測試并非隨時進(jìn)行，是有周期的，回歸測試針對兩個不同研發(fā)版本之間的改動，且應(yīng)以最低限度的回歸測試獲得最少數(shù)量的測試用例覆蓋。(2)以自動化方式執(zhí)行回歸測試。手動方式的回歸測試容易導(dǎo)致測試人員的厭煩情緒，且不利于快速完成回歸測試，因此，沒有自動化測試就沒有真正意義上的全回歸測試。(3)回歸測試中應(yīng)注意對測試用例進(jìn)行良好的組織和管理。各測試階段發(fā)生的修改一定要在本測試階段內(nèi)完成回歸，以免將缺陷遺留到下一測試階段?；貧w測試期間還應(yīng)對該軟件版本凍結(jié)，將回歸測試發(fā)現(xiàn)的問題集中修改，集中回歸。(4)注意區(qū)分回歸測試中的新、舊缺陷。08捉蟲實(shí)踐3:第二日問題的單元測試代碼說明第二日問題的集成版本共包含7個函數(shù)，其函數(shù)調(diào)用圖如圖7.7所示。詳細(xì)代碼見教學(xué)資源包。該版本至少包含一個明顯的缺陷，請自行思考。單元測試計劃根據(jù)IEEE829標(biāo)準(zhǔn)測試計劃模板，給出第二日問題的單元測試計劃如下。單元測試計劃1.引言1.1編寫目的本《單元測試計劃》文檔為第二日項(xiàng)目的單元測試活動提供測試范圍、測試方法、所需資源和測試進(jìn)度方面的指導(dǎo)本文檔的讀者主要是開發(fā)經(jīng)理和開發(fā)人員。1.2背景●項(xiàng)目名稱：第二項(xiàng)目●任務(wù)提出者：軟件測試課程組●開發(fā)者：軟件測試課程組●用戶：學(xué)生單元測試計劃1.3測試范圍本《單元測試計劃》文檔是整個軟件開發(fā)項(xiàng)目中的一部分，起始于軟件詳細(xì)設(shè)計階段，直至單元測試階段結(jié)束后終止。該計劃主要處理與第二日項(xiàng)目的單元測試有關(guān)的任務(wù)安排、資源需求、人力需求、風(fēng)險管理和進(jìn)度安排等內(nèi)容。1.4測試參考文檔制訂單元測試計劃所需使用的文檔如下。單元測試計劃2.測試項(xiàng)下表給出了所有的測試項(xiàng)目，即所有涉及的函數(shù)。單元測試計劃3.要測試的特性對于單元測試而言，要測試的特性就是選取要進(jìn)行單元測試的函數(shù)。根據(jù)被測函數(shù)的規(guī)模和復(fù)雜度來選擇被測對象，若被測函數(shù)的代碼行(非空非注釋行)大于20，或環(huán)復(fù)雜度大于3，則需進(jìn)行單元測試。按此原則選取需要測試的函數(shù)如下表所示。4.不測試的特性相對于要測試的特性，除了要測試的函數(shù)之外，其他函數(shù)因代碼行太少，且環(huán)復(fù)雜度低，均不需要進(jìn)行單元測試。注意：這些函數(shù)仍需要展開嚴(yán)格的代碼檢查，以確保不出現(xiàn)低級錯誤，并確保集成測試階段的接口正確。單元測試計劃5.測試方法采用獨(dú)立的單元測試策略，將每個函數(shù)看做一個單元展開測試，并根據(jù)需要設(shè)計相應(yīng)的驅(qū)動和樁來測試被測函數(shù)。本測試階段使用的測試方法包括：(1)保證測試到所有分支和可執(zhí)行語句，即滿足判定覆蓋；(2)使用等價類測試方法來設(shè)計測試用例；(3)使用邊界值測試方法來設(shè)計測試用例；(4)在VisualStudio2008平臺下撰寫測試腳本，并與驅(qū)動代碼、樁代碼共同構(gòu)成一個可執(zhí)行系統(tǒng)；(5)某函數(shù)的缺陷被修復(fù)后應(yīng)充分進(jìn)行回歸測試，回歸的范圍應(yīng)包含所有與該函數(shù)相關(guān)及該函數(shù)可能影響的所有單元測試用例。單元測試計劃6.測試項(xiàng)通過/失敗標(biāo)準(zhǔn)參照《軟件測試通過標(biāo)準(zhǔn)》制訂本項(xiàng)目的單元測試通過/失敗準(zhǔn)則。7.暫停/恢復(fù)標(biāo)準(zhǔn)參照《軟件測試通過標(biāo)準(zhǔn)》制訂本項(xiàng)目的單元測試暫停/恢復(fù)準(zhǔn)則。8.測試交付品單元測試的交付品包括：單元測試計劃9.測試任務(wù)測試任務(wù)見下表。單元測試計劃10.環(huán)境需求10.1硬件需求1臺目前標(biāo)準(zhǔn)的PC10.2軟件需求11.職責(zé)單元測試角色及相應(yīng)職責(zé)見下表(表中姓名和聯(lián)系方式略)。單元測試計劃12.人員配置和培訓(xùn)需求需要一名懂得在VisualStudio2008平臺下進(jìn)行C#開發(fā)的開發(fā)人員，且應(yīng)在詳細(xì)設(shè)計開始之后可全職地投入到單元測試項(xiàng)目組中。在詳細(xì)設(shè)計完成之前，需要完成項(xiàng)目需求、概要設(shè)計、詳細(xì)設(shè)計、單元測試技術(shù)和單元測試腳本技術(shù)方面的培訓(xùn)。這些培訓(xùn)大約需要花費(fèi)人均5人時的工作量。在編碼完成之前，應(yīng)完成缺陷跟蹤流的使用、測試日志表的使用，以及測試工具使用的培訓(xùn)。單元測試計劃13.進(jìn)度13.1進(jìn)度安排(時間)本《單元測試計劃》文檔為第二日項(xiàng)目的單元測試活動提供測試范圍、測試方法、所需進(jìn)度安排如下表所示(因第二日項(xiàng)目太小，嚴(yán)格來說，不能稱為一個項(xiàng)目，所以工作量幾乎無法給出，這里給出的工作量相比實(shí)際情況要大)。單元測試計劃13.2項(xiàng)目評審本單元測試計劃需要評審的工作產(chǎn)品、采用的評審方式和參加評審的人員如下表所示。其中，評審過程參見《軟件評審過程》。14.風(fēng)險和不測事件風(fēng)險參考下表。15.批準(zhǔn)計劃提交人簽字：xxx開發(fā)經(jīng)理簽字：xxx產(chǎn)品經(jīng)理簽字：xxx日期：xx×x-xx-xx日期：xx×x-xx-xx日期：xxxx-xx-xx單元測試設(shè)計針對第二日項(xiàng)目的單元測試設(shè)計如下。單元測試設(shè)計1.引言1.1編寫目的本《單元測試設(shè)計說明書》文檔為第二日項(xiàng)目的單元測試提供測試設(shè)計方法，內(nèi)容包括需要測試的函數(shù)、總體的測試設(shè)計方法，以及針對每個函數(shù)的測試策略。1.2測試范圍本《單元測試設(shè)計說明書》文檔是整個軟件開發(fā)項(xiàng)目中的一部分。該文檔主要用于提出測試需求和指導(dǎo)單元測試用例的設(shè)計。1.3測試參考文檔在單元測試計劃所需文檔基礎(chǔ)上，補(bǔ)充下表所示文檔。單元測試設(shè)計2.測試項(xiàng)被測的代碼版本為NextDateV1.0.1版。3.要測試的特性對于本單元測試，需要測試的函數(shù)如下表所示。單元測試計劃4.測試總體設(shè)計方法由于采用獨(dú)立的單元測試策略，需對每個被測函數(shù)撰寫驅(qū)動和樁代碼，為了便于管理，對每個被測函數(shù)建立工程，采用C#語言實(shí)現(xiàn)。5.測試設(shè)計說明5.1lastDayOfMonth測試設(shè)計說明5.1.1設(shè)計標(biāo)識符UTTD001(這里的001表示測試設(shè)計的第1個函數(shù))5.1.2被測特性(1)有效年份中每月有31天的情況；(2)有效年份中每月僅有30天的情況；(3)非閏年的2月情況；(4)閏年的2月情況；(5)有效年份和月份的邊界情況；(6)輸入?yún)?shù)不合法，提示錯誤(即年份或月份無效的情況，含邊界)。單元測試計劃5.1.3測試方法被測函數(shù)調(diào)用的isLeapYear函數(shù)邏輯簡單，且代碼很少，無須做樁函數(shù)。5.1.4測試項(xiàng)所有測試項(xiàng)如下表所示。5.1.5測試通過/失敗標(biāo)準(zhǔn)執(zhí)行所有測試用例，且優(yōu)先級為高或中的測試用例中，任何一個用例失敗，則測試失敗。單元測試計劃5.2ValidDate測試設(shè)計說明5.2.1設(shè)計標(biāo)識符UT_TD_0025.2.2被測特性(1)日期合法且該日期存在的性的情況。(2)年份不在有效的取值范圍內(nèi)；(3)月份不在有效的取值范圍內(nèi)；(4)日不在有效的取值范圍內(nèi)；(5)輸入的年份、月份和日有效，但該日期不存在的情況；(6)日期的邊界情況。5.2.3測試方法被測函數(shù)所調(diào)用的lastDayOfMonth函數(shù)較為復(fù)雜，因此需要對該函數(shù)進(jìn)行打樁。年份和月份的等價劃分同lastDayOfMonth。日應(yīng)劃分為3個等價類，D1={日|日∈[1，31]}，D2={日舊小于1}，D3={日日大于31}，并結(jié)合邊界點(diǎn)來設(shè)計測試用例。單元測試計劃5.2.4測試項(xiàng)所有測試項(xiàng)如下表所示。5.2.5測試通過/失敗標(biāo)準(zhǔn)執(zhí)行所有測試用例，且優(yōu)先級為高或中的測試用例中，任何一個用例失敗，則測試失敗。6.批準(zhǔn)測試設(shè)計提交人簽字：xxx開發(fā)經(jīng)理簽字：xx日期：xxxx-xx-xx日期：xxxx-xx-xx單元測試用例針對第二日項(xiàng)目的單元測試用例如下。單元測試用例1.引言1.1編寫目的本《單元測試用例說明書》文檔為第二日項(xiàng)目的單元測試提供測試用例，針對每個測試用例指出了該用例的標(biāo)識、輸入、預(yù)期輸出和必要的操作步驟。本文檔的讀者主要是開發(fā)經(jīng)理和開發(fā)人員。1.2測試范圍本《單元測試用例說明書》文檔是單元測試文檔中的一部分。該文檔主要用于說明所有的測試用例。單元測試用例1.3測試參考文檔在單元測試設(shè)計所需文檔基礎(chǔ)上，補(bǔ)充下表所示文檔。2.測試項(xiàng)被測的代碼版本為NextDateV1.0.1版。3.要測試的特性對于本單元測試，需要測試的函數(shù)如下表所示。單元測試用例4.測試用例說明4.1lastDayOfMonth測試用例說明lastDayOfMonth的測試用例說明如表4.1～表4.6所示。單元測試用例單元測試用例4.2ValidDate測試用例說明ValidDate的測試用例說明如表4.7～表4.14所示。單元測試用例單元測試用例單元測試用例5.批準(zhǔn)測試設(shè)計提交人簽字：XXX日期：XXX開發(fā)經(jīng)理簽字：XXX日期：XXXXXX單元測試腳本1.創(chuàng)建腳本工程的過程以ValidDate函數(shù)為例，創(chuàng)建腳本工程的過程如下。(1)在VisualStudio2008環(huán)境下新建項(xiàng)目，選擇語言類型為VisualC++，模板為Win32控制臺應(yīng)用程序，命名為UTTD002，如圖7.8所示。注意單擊“確定”按鈕后，在后續(xù)彈出的Win32應(yīng)用程序向?qū)υ捒蛑?，附加選項(xiàng)應(yīng)勾選“空項(xiàng)目”。(2)在新建工程中加入必要的文件，如圖7.9所示。單元測試腳本2.腳本的設(shè)計(1)公共信息頭文件CommonUse.h公共信息頭文件中主要放置對所有被測函數(shù)有用的信息，特別包括不需要打樁的函數(shù)的聲明，內(nèi)容如下。單元測試腳本(2)公共信息執(zhí)行文件CommonUse.cpp該文件中主要存放不需要打樁的函數(shù)源代碼，本例中即為isLeapYear的源代碼。(3)被測函數(shù)頭文件ValidDate.h該文件主要用于聲明被測函數(shù)、全局變量、測試用例函數(shù)和樁模塊，部分代碼如下：單元測試腳本(4)被測函數(shù)文件ValidDate.cpp該文件僅包含被測函數(shù)，詳細(xì)代碼不再給出。(5)測試用例文件ValidDateCase.cpp該文件是對被測函數(shù)所有測試用例的具體實(shí)現(xiàn)，每個用例對應(yīng)一個函數(shù)，函數(shù)名與該用例標(biāo)識符相同，函數(shù)返回值代表該用例是否通過。全局變量CASESUC用于記錄當(dāng)前用例的測試結(jié)果，STUBSUC用于記錄被測函數(shù)用到的樁是否執(zhí)行通過，CASEID用于記錄每個用例的標(biāo)識符，并在驅(qū)動模塊中用于測試結(jié)果的輸出。單元測試腳本(6)單元測試驅(qū)動文件ValidDateDriver.cpp該文件直接調(diào)用被測函數(shù)用到的所有測試用例函數(shù)，輸出和記錄測試結(jié)果。(7)單元測試樁文件ValidDateStub.cpp樁文件應(yīng)結(jié)合測試用例進(jìn)行設(shè)計，一般較為復(fù)雜。單元測試執(zhí)行運(yùn)行單元測試腳本后，對lastDayOfMonth的單元測試執(zhí)行結(jié)果如圖7.10所示。對ValidDate函數(shù)的測試結(jié)果是所有測試用例全部通過。單元測試評估總結(jié)(1)計劃進(jìn)度偏差：(實(shí)際進(jìn)度-計劃進(jìn)度)/計劃進(jìn)度；(2)測試密度：測試用例總數(shù)/代碼規(guī)模，一般代碼規(guī)模用KLOC表示，通常測試密度應(yīng)在20~25個/KLOC;(3)缺陷密度：打開的缺陷總數(shù)/代碼規(guī)模；(4)測試用例的質(zhì)量：打開的缺陷總數(shù)/測試用例總數(shù)。本例由于規(guī)模太小，難以評估，不再給出具體的評估總結(jié)數(shù)據(jù)。單元測試的評估總結(jié)主要是對單元測試活動的質(zhì)量進(jìn)行評價，包括測試用例的執(zhí)行情況、發(fā)現(xiàn)缺陷的情況、代碼覆蓋的情況等，目的在于決定是否可退出當(dāng)前測試階段。評價指標(biāo)一般包括：09捉蟲實(shí)踐4:第二日問題的單元測試改進(jìn)存在的不足上述單元測試的代碼存在以下問題：(1)測試代碼工作量太大。由于對每個測試用例均用一個單獨(dú)的函數(shù)來表示，導(dǎo)致測試用例文件(即*Case.cpp文件)非常龐大，且函數(shù)內(nèi)容相似，重復(fù)代碼非常多。同時，測試驅(qū)動代碼(即*Drivercpp文件)也異常龐大，充斥著大量重復(fù)代碼。這種處理方式無疑將大大增加測試代碼工作量，難以提高測試效率。(2)測試代碼靈活性差。由于將所有與測試用例相關(guān)的輸入數(shù)據(jù)全部直接寫入程序，導(dǎo)致輸入數(shù)據(jù)在多個文件中同時并存，如樁代碼(即*Stub.cpp文件)和測試用例文件中，不僅編寫代碼時容易出錯，且當(dāng)測試用例變化時，需要同時修改多個文件，使得測試代碼的維護(hù)非常困難。(3)測試結(jié)果難以保存。測試結(jié)果從控制臺輸出，未保存在指定文件中，無法方便地查看。改進(jìn)措施為了提高測試代碼的質(zhì)量，可行的改進(jìn)措施如下：(1)多個測試用例合并為一個通用的測試用例，通過循環(huán)執(zhí)行的方式，用相同的策略執(zhí)行不同的測試用例；(2)將測試用例的輸入和預(yù)期輸出數(shù)據(jù)與執(zhí)行文件完全分離，使用例變化與測試代碼無關(guān)；(3)將測試結(jié)果輸出到指定文件，便于測試結(jié)束后查看。改進(jìn)的單元測試腳本仍以VaidDate函數(shù)的單元測試為例，被測函數(shù)頭文件ValidDate.h中，所有形如boolUTTC002001001()的函數(shù)聲明全部刪去，代之以如下代碼：測試用例文件ValidDateCase.cpp中，所有形如boolUTTC002001001()的函數(shù)體全部刪去，代之以如下代碼：改進(jìn)的單元測試腳本測試驅(qū)動文件ValidDateDriver.cpp中，將測試結(jié)果保存在*Result.txt中，詳細(xì)代碼如下：更多討論獨(dú)立的單元測試策略主要從模塊(或函數(shù))的環(huán)復(fù)雜度和代碼行來評估是否需要進(jìn)行單元測試，而實(shí)際上很多函數(shù)是處于調(diào)用層次中的，還可從如下方面評估模塊的單元測試價值：(1)模塊自身復(fù)雜程度，模塊的環(huán)復(fù)雜度越大，結(jié)構(gòu)越復(fù)雜，越需要進(jìn)行單元測試；(2)模塊的調(diào)用層次，模塊在調(diào)用圖中所處層次越高，地位越重要，越需要盡早測試；(3)模塊間的關(guān)聯(lián)度，模塊被調(diào)用的次數(shù)越高，或被該模塊調(diào)用的模塊越多，該模塊與其他模塊的關(guān)聯(lián)度越高，越需要進(jìn)行更加嚴(yán)格的測試。更多討論根據(jù)以上原則，若暫不考慮模塊自身的復(fù)雜度，對于某個模塊node而言，若該模塊需調(diào)用n個子模塊node;(i=1，2，…，n)，則其測試價值可按如下方式進(jìn)行粗略計算：式中，L(node)表示模塊的總測試價值，表示與調(diào)用圖層次有關(guān)的測試價值，level表示模塊所處的調(diào)用圖層次，從葉子節(jié)點(diǎn)開始計算，直至根節(jié)點(diǎn)。一般地，level滿足下式：更多討論10本章小結(jié)本章小結(jié)單元測試通常由開發(fā)人員完成，看起來貌似增加了程序員的工作量，實(shí)際上將大大減少在代碼級別植入缺陷的概率，提高單元的質(zhì)量，從而大大縮短后續(xù)集成測試和系統(tǒng)測試的時間。完整的單元測試包括測試計劃、設(shè)計、實(shí)施、執(zhí)行和評估5個階段，其中，測試需求、日構(gòu)建、回歸測試是整個測試階段中的重要概念，在測試需求的基礎(chǔ)上設(shè)計測試用例將有利于提高測試的復(fù)用和全面性，日構(gòu)建能幫助程序員更好地控制進(jìn)度、盡快發(fā)現(xiàn)和修復(fù)缺陷，回歸測試的質(zhì)量則直接影響整個測試過程的效率。謝謝觀看第8章集成測試高等學(xué)校計算機(jī)類系列教材軟件測試實(shí)用教程——方法與實(shí)踐01概述集成測試的定義集成測試就是在單元測試的基礎(chǔ)上，將所有已通過單元測試的模塊按照概要設(shè)計的要求組裝為子系統(tǒng)或系統(tǒng)，并進(jìn)行測試的過程，目的是確保各單元模塊組合在一起后能夠按既定意圖協(xié)作運(yùn)行，并確保增量的行為正確。需要再次強(qiáng)調(diào)的是，不經(jīng)過單元測試的模塊是不應(yīng)進(jìn)行集成測試的，否則將對集成測試的效果和效率帶來巨大的不利影響。集成測試的內(nèi)容包括模塊之間的接口以及集成后的功能。它主要使用黑盒測試方法測試集成的功能，并對以前的集成進(jìn)行回歸測試。具體來說，集成測試的內(nèi)容包括以下方面：(1)將各個具有相互調(diào)用關(guān)系的模塊組裝起來時，檢查穿越模塊接口的數(shù)據(jù)是否會丟失；(2)判斷各子功能組合起來能否達(dá)到預(yù)期要求的各功能；(3)檢查一個模塊的功能是否會對其他模塊的功能產(chǎn)生不利影響；(4)檢查全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否正確，以及在完成模塊功能的過程中是否會被異常修改；(5)單個模塊的誤差累積起來，是否會放大到不可接受的程度。集成測試的內(nèi)容02集成測試的評價集成測試的評價集成測試可基于多種測試策略展開，可從如下4個方面對集成測試策略進(jìn)行評價：(1)測試用例的規(guī)模。測試用例數(shù)量越多，設(shè)計、執(zhí)行和分析這些測試用例所花費(fèi)的工作量越大，因此，測試用例的規(guī)模應(yīng)越小越好。(2)驅(qū)動模塊的設(shè)計。受到模塊調(diào)用關(guān)系的影響，參與某次集成測試的模塊可能被不包含在本次集成中的其他模塊所調(diào)用，為此需要設(shè)計驅(qū)動模塊，驅(qū)動模塊不含在產(chǎn)品代碼中，因此，驅(qū)動模塊的數(shù)量應(yīng)越少越好。(3)樁模塊的設(shè)計。類似地，參與某次集成測試的模塊可能調(diào)用其他不包含在本次集成中的模塊，為此需要設(shè)計樁模塊，樁模塊不應(yīng)提交給用戶，因此，樁模塊的數(shù)量應(yīng)越少越好。(4)缺陷的定位。集成測試的主要任務(wù)是檢查模塊間的接口，集成測試用例涉及的接口數(shù)量越少，越容易定位出錯的接口，因此，單個集成測試涉及接口數(shù)量(即模塊數(shù)量)越少越好。03單個集成測試用例的設(shè)計成對集成的基本思想是將每個集成測試用例限定在一對調(diào)用單元上，每個集成測試用例都是最小的集成單元，僅涉及一對調(diào)用的接口。這樣做最大的好處就是使得缺陷非常容易定位，一旦某個集成測試用例失敗，可以肯定地說，一定是該用例涉及的這一對模塊的接口有問題。成對集成捉蟲實(shí)踐1:第二日問題的成對集成1.成對集成的測試用例設(shè)計兩個典型的成對集成用例見圖8.1(即圖中虛線框住的灰色區(qū)域，后續(xù)同理，不再贅述)，函數(shù)名用縮寫表示。2.規(guī)模估算設(shè)某模塊調(diào)用圖中包含m個模塊，共有n條邊，因每條邊對應(yīng)一對調(diào)用接口，確定一個成對集成用例，因此，該調(diào)用圖的集成測試應(yīng)包含n個測試用例。本例中為8個集成測試用例。成對集成的測試用例規(guī)模與模塊的數(shù)量沒有直接關(guān)系。捉蟲實(shí)踐1:第二日問題的成對集成3.特點(diǎn)分析成對集成的最初目的是希望能避免開發(fā)樁和驅(qū)動模塊(有關(guān)樁和驅(qū)動模塊的概念參見單元測試相關(guān)內(nèi)容)，但事實(shí)并非如此。以GetDate(即GD)與ValidDate(即VD)之間的集成測試為例，GetDate被NextDate3(即ND3)調(diào)用，ValidDate又調(diào)用lastDayofMonth(即IDOM)，分別需為NextDate3和lastDayOfMonth開發(fā)驅(qū)動和樁模塊，即測試時，用stublastDayOfMonth(lastDayOfMonth的樁模塊)替換ValidDate函數(shù)中所有出現(xiàn)lastDayOfMonth的地方，并用driverNextDate3(NextDate3的驅(qū)動模塊)替換原始NextDate3函數(shù)，而GetDate函數(shù)代碼無須任何改動，正常調(diào)用ValidDate即可。鄰居集成鄰居集成的基本思想是將每個集成測試用例限定在某個節(jié)點(diǎn)的鄰居上，針對某個模塊的集成測試用例應(yīng)同時包含該模塊及其鄰居。所謂鄰居，是對應(yīng)某個模塊的一個特定鄰域模塊集合，它包括指定的某個模塊、所有直接調(diào)用該模塊的上層模塊以及所有被該模塊直接調(diào)用的下層模塊。鄰居的構(gòu)成有兩種方式：(1)處于中間層的模塊。每個處于調(diào)用圖中間層的模塊既有上層調(diào)用模塊，又有下層被調(diào)用模塊，自然形成一組鄰居，構(gòu)成一個集成測試用例。(2)根節(jié)點(diǎn)直接調(diào)用葉子節(jié)點(diǎn)。當(dāng)根節(jié)點(diǎn)模塊直接調(diào)用葉子節(jié)點(diǎn)模塊時，根模塊與所有被它直接調(diào)用的葉子模塊共同形成一組鄰居，構(gòu)成一個集成測試用例。捉蟲實(shí)踐2:第二日問題的鄰居集成1.鄰居集成的測試用例設(shè)計以第二日問題為例，兩個典型的鄰居集成用例見圖8.2。2.規(guī)模估算設(shè)某模塊調(diào)用圖中包含m個模塊，其中n個模塊是中間層的模塊，則當(dāng)存在根節(jié)點(diǎn)直接調(diào)用葉子模塊的情況時，該調(diào)用圖的鄰居集成測試應(yīng)包含n+1個測試用例，否則僅包含n個測試用例。本例中為5個集成測試用例。鄰居集成測試用例的規(guī)模與模塊數(shù)量也沒有直接關(guān)系。捉蟲實(shí)踐2:第二日問題的鄰居集成3.特點(diǎn)分析與成對集成相比，鄰居集成試圖通過擴(kuò)大單個測試用例的范圍來減少測試用例總數(shù)，導(dǎo)致的結(jié)果是致使缺陷定位變得困難。一旦某個測試用例失敗，需要在鄰居所形成的一組接口中判斷出錯接口。且某個模塊可能包含在多個集成測試用例中，該模塊的修改意味著所有包含該模塊的測試用例需要全部重測，如lastDayofMonth函數(shù)同時包含在ValidDate、IncrementDate和lastDayofMonth的3個集成測試用例中，如此將大大增加集成測試的工作量。鄰居集成仍需開發(fā)樁或驅(qū)動模塊。以NextDate3與PrintDate的集成測試為例，在NextDate3的代碼中需用3個樁函數(shù)stubGctDate、stubValidDate和stubIncremenfDate分別替換GetDate、ValidDate和IncrementDate函數(shù)。相比成對集成，鄰居集成的樁和驅(qū)動模塊開發(fā)工作量略低。對于本例，若采用獨(dú)立測試策略，樁模塊同成對集成，驅(qū)動模塊減少為2個，僅需為NextDate3和GetDate開發(fā)驅(qū)動?；讵?dú)立路徑的集成基于獨(dú)立路徑的集成基本思想是將函數(shù)調(diào)用圖看做程序的控制流圖或程序圖，每個從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的調(diào)用形成了路徑，每條獨(dú)立路徑即可構(gòu)成一個集成測試用例。捉蟲實(shí)踐3:第二日問題基于獨(dú)立路徑的集成1.基于獨(dú)立路徑集成的測試用例設(shè)計以第二日問題為例，兩個典型的獨(dú)立路徑集成用例如圖8.3所示，分別為NextDate3→GetDate→ValidDate→lastDayOfMonth→isLeapYear和NextDate3→ValidDate→lastDayOfMonth→isLeapYear。2.規(guī)模估算將模塊調(diào)用圖視做程序圖，設(shè)其環(huán)復(fù)雜度為V，理論上而言，基于獨(dú)立路徑的集成測試應(yīng)包含V個測試用例。顯然，模塊調(diào)用關(guān)系越復(fù)雜，基于路徑的集成測試用例的規(guī)模越大。本例中為4個集成測試用例。捉蟲實(shí)踐3:第二日問題基于獨(dú)立路徑的集成3.特點(diǎn)分析基于獨(dú)立路徑的集成其實(shí)質(zhì)是將單個測試用例的范圍從相鄰模塊向外擴(kuò)展，直至達(dá)到根和葉子節(jié)點(diǎn)，形成完整的調(diào)用過程，以進(jìn)一步降低測試用例數(shù)及樁和驅(qū)動的開發(fā)工作量。本例中，樁模塊減少為3個(無須為lastDayOfMonth開發(fā)樁)，且因每個測試都包含從根到葉子節(jié)點(diǎn)的完整的直接調(diào)用關(guān)系而完全避免了驅(qū)動模塊的開發(fā)。以上測試方法側(cè)重于單個集成測試用例的設(shè)計，其中成對集成是將每個測試用例的集成最小化，鄰居集成和基于獨(dú)立路徑的集成以鄰居的方式擴(kuò)大每個測試用例所包含的接口規(guī)模，達(dá)到局部范圍內(nèi)的集成最大化，不足在于增加了缺陷定位的難度。能否找到一種折中的方式來控制每個集成用例的接口規(guī)模，降低缺陷定位難度，并將測試用例總數(shù)控制在一定范圍內(nèi)呢?04集成測試遍歷順序的設(shè)計大爆炸集成1.基本思想大爆炸集成(BigBang)是將所有經(jīng)過單元測試的模塊一次性組裝到被測系統(tǒng)中進(jìn)行測試，完全不考慮模塊之間的依賴性和可能的風(fēng)險。2.捉蟲實(shí)踐4:第二日問題的大爆炸集成以第二日問題為例，大爆炸集成就是將所有7個模塊放在一起進(jìn)行測試，即僅需一個測試用例，達(dá)到用例規(guī)模的最小化。同時，由于該測試一次性包含了所有模塊，無須開發(fā)樁和驅(qū)動模塊。顯而易見的弊端是直接導(dǎo)致缺陷定位異常困難。一旦用例失敗，完全不知道是哪對模塊的調(diào)用接口出了問題。特別地，即使被測系統(tǒng)能夠一次性集成成功，也會有許多接口缺陷逃過測試而進(jìn)入系統(tǒng)測試，給系統(tǒng)測試帶來不良影響，大大增加系統(tǒng)測試的負(fù)擔(dān)。自頂向下的集成1.基本思想自頂向下的集成(TopDown)是從主控模塊(主程序，即根節(jié)點(diǎn))開始，按照系統(tǒng)程序結(jié)構(gòu)，沿著控制層次從上而下，逐漸將各模塊組裝起來。該集成測試方式下無須開發(fā)驅(qū)動模塊，但需對未經(jīng)集成測試的模塊開發(fā)樁模塊。集成中采用寬度優(yōu)先或深度優(yōu)先的策略向下推進(jìn)，步驟如下：(1)對根節(jié)點(diǎn)進(jìn)行集成測試，所有被根節(jié)點(diǎn)直接調(diào)用的模塊均用樁模塊來代替。(2)根據(jù)選擇的推進(jìn)策略(寬度優(yōu)先或深度優(yōu)先)，用實(shí)際模塊替換樁模塊(一般每次僅替換一個)，并用新的樁模塊代替新加入的模塊，與已測模塊或子系統(tǒng)構(gòu)成新的子系統(tǒng)，進(jìn)行測試。(3)回歸測試，全部或部分執(zhí)行以前做過的測試，以確保新加入的模塊未引入新的缺陷。(4)重復(fù)步驟(2)、(3)，直至所有模塊都已集成到系統(tǒng)中。自頂向下的集成2.捉蟲實(shí)踐5:第二日問題的自頂向下集成以第二日問題為例，按寬度優(yōu)先策略自頂向下進(jìn)行集成測試，其中PrintDate和isLeaYear太簡單，均無須開發(fā)樁。(1)若按每個節(jié)點(diǎn)的集成為對象，且對每個節(jié)點(diǎn)的一組集成不分次序，則從根節(jié)點(diǎn)NextDate3開始，其存在直接調(diào)用關(guān)系的接口有4個，對應(yīng)根節(jié)點(diǎn)的3個集成測試用例見圖8.4。自頂向下的集成接著測試GetDate對應(yīng)的接口，如圖8.5所示。測試ValidDate的接口，如圖8.6所示。最后測試ValidDate對應(yīng)的接口，只需將lastDayOfMonth與isLeapYear一并加入即可展開集成測試。自頂向下的集成(2)若按每層所涉及的接口為對象，不斷替換原始樁模塊以遍歷整個調(diào)用圖，則仍從根節(jié)點(diǎn)開始，集成測試的順序如圖8.7所示，圖中最終一次性加入lastDayOfMonth和isLeapYear函數(shù)。深度優(yōu)先策略與此類似，詳細(xì)內(nèi)容不再給出。自頂向下的集成3.規(guī)模估算自頂向下的集成中，每個被調(diào)用的模塊都需要開發(fā)樁模塊，設(shè)調(diào)用圖中有m個模塊，則理論上樁模塊的數(shù)量為m-1個。注意：樁模塊的開發(fā)工作量主要受測試用例數(shù)量的影響，當(dāng)測試用例較多時，樁模塊的工作量會變得很大。自頂向下的集成4.特點(diǎn)分析自頂向下的集成測試優(yōu)勢在于：(1)優(yōu)先從根節(jié)點(diǎn)開始測試，有助于早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)主要功能，給開發(fā)團(tuán)隊(duì)和用戶帶來成功的信心，也便于早期驗(yàn)證主要的控制和判斷，避免主控程序的缺陷，確保開發(fā)進(jìn)度；(2)單個測試用例包含多個模塊，可從整體上降低測試用例規(guī)模；(3)采用遞增方式展開測試，每個新的測試用例一般僅加入一個新的模塊，便于缺陷定位。自頂向下的集成測試不足在于：(1)樁模塊的開發(fā)和維護(hù)工作量較大；(2)難以早期發(fā)現(xiàn)底層模塊中復(fù)雜算法的缺陷，且隨著測試的進(jìn)行，系統(tǒng)越來越復(fù)雜，底層模塊的測試很難保證充分性；(3)不利于測試的并行，難以充分展開人力。自底向上的集成1.基本思想自底向上的集成(BottomUp)是從底層模塊(即葉子節(jié)點(diǎn))開始，按照調(diào)用圖的結(jié)構(gòu)，從下而上，逐層將各模塊組裝起來。該集成測試方式下無須開發(fā)樁模塊，但需對未經(jīng)集成測試的模塊開發(fā)驅(qū)動模塊。集成中采用寬度優(yōu)先或深度優(yōu)先的策略向上推進(jìn)，步驟如下：(1)對葉子節(jié)點(diǎn)進(jìn)行集成測試，所有直接調(diào)用葉子節(jié)點(diǎn)的模塊均用驅(qū)動模塊來代替；(2)用實(shí)際模塊替換驅(qū)動模塊(一般每次僅替換一個)，并用新的驅(qū)動模塊代替新加入的模塊，與下層所有已測的被調(diào)用模塊構(gòu)成新的子系統(tǒng)(子功能)，進(jìn)行測試；(3)回歸測試，即全部或部分執(zhí)行以前做過的測試，以確保新加入的模塊未引入新的缺陷；(4)重復(fù)步驟(2)、(3)，直至所有模塊都已集成到系統(tǒng)中。自底向上的集成2.捉蟲實(shí)踐6:第二日問題的自底向上集成以第二日問題為例，按寬度優(yōu)先策略自底向上進(jìn)行集成測試(見圖8.8)，圖中帶陰影的小圓圈表示上層調(diào)用模塊對應(yīng)的驅(qū)動，虛線框表示同一個調(diào)用模塊(如圖8.8(b)中的lastDayOfMonth)。自底向上的集成各步驟具體的測試用例如下：(1)步驟一：測試isLeapYear和PrintDate，構(gòu)成兩個集成測試用例；(2)步驟二：加入lastDayOfMonth，構(gòu)成兩個集成測試用例；(3)步驟三：加入ValidDate和IncrementDate，構(gòu)成三個集成測試用例；(4)步驟四：加入GetDate，構(gòu)成一個集成測試用例；(5)步驟五：將所有模塊加入構(gòu)成一個總體集成測試用例(圖示不再畫出)。實(shí)際上，若仍按寬度優(yōu)先的策略，但每次向上推進(jìn)時同時替換多個驅(qū)動模塊，則總集成測試用例數(shù)可適當(dāng)降低，但部分接口可能得不到充分的測試，讀者可嘗試自行設(shè)計對應(yīng)的測試用例。自底向上的集成3.規(guī)模估算自底向上的集成中，除了葉子節(jié)點(diǎn)不需要開發(fā)驅(qū)動模塊，每個處于上層調(diào)用位置的模塊都需要開發(fā)驅(qū)動模塊。設(shè)調(diào)用圖中有m個模塊，其中葉子模塊為n個，則理論上驅(qū)動模塊的數(shù)量為m-n個。值得注意的是：驅(qū)動模塊的數(shù)量相比自頂向下集成中樁模塊的數(shù)量要少很多，而且驅(qū)動模塊的開發(fā)難度較樁模塊的開發(fā)難度要小一些。自底向上的集成4.特點(diǎn)分析與