軟件測試合理策略與流程

軟件測試合理策略與流程軟件測試過程：針對每個單元的測試，

以確保每個模塊能正常工作為目標。大量采用白盒測試。集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在于檢驗與軟件設計相關的程序結構問題。多采用黑盒測試。系統(tǒng)測試：檢驗所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段。檢驗軟件產(chǎn)品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作。采用黑盒測試。驗收（用戶）測試：檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用，同時軟件開發(fā)人員也應有一定程度的參與。采用黑盒測試。軟件測試合理策略與流程例子#include<stdio.h>voidiszero(intm){if(m!=0)printf(“%d”,m);elseprintf(“%d”,1);}voidmain(void){inta[5];inti=0;printf(“pleaseinput5datas\n”);for(i=0;i<5;i++){scanf(“%d”,&a[i]);iszero(a[i]);}程序功能：若輸入的數(shù)組元素不等于0，則輸出元素值；若輸入的數(shù)組元素值為0，則輸出1。軟件測試合理策略與流程Main函數(shù)Iszero函數(shù)

分別進行單元測試Main函數(shù)Iszero函數(shù)進行集成測試然后，加上使用環(huán)境和用戶，進行系統(tǒng)測試及驗收測試軟件測試合理策略與流程一個實用軟件測試過程一種簡單實用的軟件測試過程模型POCERM。測試過程中必需的基本測試活動及其產(chǎn)生的結果：寫軟件測試計劃(Plans)寫測試設計(編制測試大綱(Outlines),設計測試用例(testCasegeneration)）測試執(zhí)行(Execution)生成軟件測試報告(softwaretestingReports)軟件問題報告SPR(SoftwareProblemReport)測試結果報告(testresultReports)軟件測試合理策略與流程2.3單元測試軟件測試合理策略與流程什么是單元測試(unittesting)？指對軟件中的最小可測試單元進行檢查和驗證。單元，一般應根據(jù)實際情況判定其具體含義，如，C中，單元指1個函數(shù)，java中，單元指1個類，圖形化軟件中也可以是1個窗口、1個菜單等，單元就是認為規(guī)定的最小被測試的模塊。軟件測試合理策略與流程單元測試過程單元測試計劃單元測試設計單元測試執(zhí)行測試的記錄測試總結分析完畢缺陷跟蹤軟件測試合理策略與流程單元測試過程計劃階段,依據(jù)是需求規(guī)格說明和詳細設計說明書,主要內(nèi)容是測試范圍、測試時間進度、資源分配表、單元測試策略和方法。例如,是否需要靜態(tài)測試、

測試工具、

單元測試代碼開發(fā)(驅動(Driver)和樁(Stub)模塊)等。設計階段,依據(jù)是單元測試計劃和詳細設計,生成單元測試用例,主要內(nèi)容是設計測試用例,編寫DriverandStub.執(zhí)行階段,依據(jù)是單元測試用例、需求說明、詳細說明,執(zhí)行測試用例,生成缺陷報告。評估階段，依據(jù)是單元測試用例、缺陷報告等。寫單元測試報告。軟件測試合理策略與流程單元測試策略分離式單元測試,將所有單元分離開，獨立地測試每個單元，測試時單元間互相不調(diào)用。分層式單元測試

由不調(diào)用其他單元的最底層單元開始，按自底向上順序完成每一層的單元的測試，在測試上一層單元時，可以調(diào)用已經(jīng)通過測試的下層單元。

或：由不被其他單元調(diào)用的最頂層單元開始，按自頂向下的順序完成每一層單元的測試。軟件測試合理策略與流程2.3.1單元測試的主要任務單元測試針對每個程序的模塊，主要測試5個方面的問題：——模塊接口、局部數(shù)據(jù)結構、邊界條件、獨立的路徑和錯誤處理。模塊模塊接口局部數(shù)據(jù)結構路徑測試出錯處理邊界條件軟件測試合理策略與流程單元測試的主要任務（續(xù)）模塊接口P47檢查進出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進行。模塊接口測試至少需要如下的測試項目：調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配,類型兼容的問題；文件使用是否正確，文件屬性是否正確,文件打開語句是否正確;全局變量的定義在各模塊中是否一致。軟件測試合理策略與流程單元測試的主要任務（續(xù)）局部數(shù)據(jù)結構

P47目的：為了保證模塊內(nèi)部的數(shù)據(jù)在程序執(zhí)行過程中完整、正確，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關系不發(fā)生錯誤。對于局部數(shù)據(jù)結構，應該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：（1）不正確的或不相容的類型說明。（2）變量無初值（2）錯誤的初始化或默認值。（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。（4）溢出,下溢、上溢或者地址錯誤。軟件測試合理策略與流程單元測試的主要任務（續(xù)）路徑測試

P48在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產(chǎn)生的錯誤。常見的錯誤有：誤解的或不正確的算術優(yōu)先級；混合類型的運算；變量初值錯誤；精度不夠精確；表達式符號錯。針對判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯誤：不同數(shù)據(jù)類型的比較；不正確的邏輯操作或優(yōu)先級；應當相等的地方由于精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當遇到分支循環(huán)時不能退出；不適當?shù)匦薷难h(huán)變量。軟件測試合理策略與流程單元測試的主要任務（續(xù)）邊界條件單元測試的最后一步，必須采用邊界值分析方法來設計測試用例，認真仔細地測試為限制數(shù)據(jù)處理而設置的邊界處，看模塊是否能夠正常工作。一些可能與邊界有關的數(shù)據(jù)類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測試中，應設計測試用例檢查以下情況：（1）在n次循環(huán)的第0次、1次、n次是否有錯誤。（2）運算或判斷中取最大值、最小值時是否有錯誤。（3）數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯誤。軟件測試合理策略與流程單元測試的主要任務（續(xù)）出錯處理好的設計應該能預見各種出錯條件,并預設各種出錯處理設施,出錯處理設施也需要測試。檢驗程序中的出錯處理可能面對的情況有：（1）對運行發(fā)生的錯誤描述難以理解。（2）所報告的錯誤與實際遇到的錯誤不一致。（3）出錯后，在錯誤處理之前就引起系統(tǒng)的干預。（4）異常處理不當。（5）提供的錯誤信息不足，以至于無法找到錯誤的原因。軟件測試合理策略與流程何時進行單元測試？通常在編碼完成后進行，在前期應準備，如寫單元測試計劃,編測試用例、單元測試代碼等。一般由白盒測試工程師、開發(fā)人員完成。單元測試的依據(jù)：源程序(包括代碼和注釋)，項目的《詳細設計》文檔。如何進行單元測試？一般先靜態(tài)地檢查代碼是否符合規(guī)范，然后動態(tài)地運行代碼并檢查運行結果。主要用白盒測試。軟件測試合理策略與流程單元測試的一般步驟：編譯運行程序，進行語法正確性驗證靜態(tài)測試，檢查代碼是否符合規(guī)范，參看“編碼規(guī)范”動態(tài)測試，深入檢查代碼的正確性、容錯性和邊界值等。需要提前設計一些測試步驟、測試用例。如何進行單元測試？軟件測試合理策略與流程案例單元測試例子#include<stdio.h>voidiszero(intm){if(m!=0)printf(“%d”,m);elseprintf(“%d”,1);}voidmain(void){inta[5];inti=0;printf(“pleaseinput5datas\n”);for(i=0;i<5;i++){scanf(“%d”,&a[i]);iszero(a[i]);}程序功能：若輸入的數(shù)組元素不等于0，則輸出元素值；若輸入的數(shù)組元素值為0，則輸出1。軟件測試合理策略與流程編譯運行該程序，無語法錯誤，編譯通過靜態(tài)測試，參照c語言編碼規(guī)范，檢查程序中是否存在不符合規(guī)范的地方，發(fā)現(xiàn)沒有注釋動態(tài)測試運行時,輸入數(shù)據(jù)包括合法數(shù)據(jù),非法數(shù)據(jù),邊界值.運行：合法數(shù)據(jù),輸入12340，輸出為12341，符合預期結果注意：邊界值問題，如輸入1234567；數(shù)組的邊界值等；非法數(shù)據(jù)的輸入，如輸入abcde，則結果出現(xiàn)某些數(shù)，因為scanf()的`錯誤判斷能力不強造成的。軟件測試合理策略與流程單元測試代碼是單元測試中的輔助測試模塊：（1）驅動模塊(Driver)指模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收測試數(shù)據(jù)，將相關數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并輸出結果。（2）樁模塊(Stub)指模擬被測模塊所調(diào)用的模塊。

驅動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。

軟件測試合理策略與流程單元測試的測試環(huán)境測試用例被測模塊驅動模塊測試結果樁模塊1樁模塊2樁模塊3樁模塊n樁模塊…驅動模塊和樁模塊軟件測試合理策略與流程#include<stdio.h>voidmain(void){inta=1,b=2,c;c=fun1(a,b);}intfun1(intx,inty){returnx+y;}main函數(shù)fun1函數(shù)軟件測試合理策略與流程#include<stdio.h>voidmain(void){inta=1,b=2,c;c=fun1(a,b);}intfun1(intx,inty){returnx+y;}假設main()和fun1()分別由兩個程序員開發(fā)且進度不同，進行測試時：若沒有main()函數(shù)，如何測試fun1()？

若沒有fun1()函數(shù)，如何測試main()？

軟件測試合理策略與流程#include<stdio.h>//驅動模塊voidmain(void){inta=1,b=2,c;c=fun1(a,2*b);}intfun1(intx,inty){returnx+y;}假設main()和fun1()分別由兩個程序員開發(fā)且進度不同，進行測試時：若沒有main()函數(shù)，如何測試fun1()？構建一個驅動模塊(main()函數(shù)的驅動模塊)，里面至少能夠調(diào)用fun1()并輸出調(diào)用結果。如何測試fun1模塊?軟件測試合理策略與流程#include<stdio.h>voidmain(void){inta=1,b=2,c;c=fun1(a,b);}//樁模塊intfun1(intx,inty)

{return2*x+y;}假設main()和fun1()分別由兩個程序員開發(fā)且進度不同，進行測試時：若沒有fun1()函數(shù)，如何測試main()？構建一個樁模塊(fun1()的樁模塊)，至少能夠被main()調(diào)用并有一個返回值。如何測試main模塊?軟件測試合理策略與流程驅動模塊一般結構：IntDriverModule(){….調(diào)用被測試的模塊；處理運行結果；

….}

單元測試代碼應該與單元代碼保持一致，每當單元代碼發(fā)生變化，需確認單元測試代碼是否需要更新；單元測試代碼通常不完全等同于所模擬的真實模塊，一般只模擬一個或一些運行情況，返回一個執(zhí)行所需要的值。樁模塊一般結構：IntStubModule(.…){….Return返回值；

….}單元測試代碼的一般結構軟件測試合理策略與流程單元測試的技術指標正確地實現(xiàn)規(guī)定的功能錯誤處理正確邊界條件處理正確達到預定的代碼覆蓋率(語句覆蓋、判定覆蓋、條件組合覆蓋、路徑覆蓋等)軟件測試合理策略與流程什么是集成測試(integrationtesting)？單元測試的下一個階段，指將通過測試的單元模塊組裝成系統(tǒng)或子系統(tǒng)，再進行測試。集成測試的內(nèi)容：單元組裝后的功能正確性：是否實現(xiàn)預期功能單元之間的接口：調(diào)用關系、數(shù)據(jù)傳遞一個單元是否使其他單元出現(xiàn)問題？對全局數(shù)據(jù)結構、數(shù)據(jù)文件/數(shù)據(jù)庫的使用是否出現(xiàn)問題集成后的系統(tǒng)性能：集成后系統(tǒng)資源使用情況2.4集成測試軟件測試合理策略與流程集成測試過程集成測試計劃集成測試設計集成測試執(zhí)行測試的記錄測試總結分析完畢缺陷跟蹤

一些項目不一定要有一個單獨的集成測試計劃，可以在項目計劃中包含；一些項目不設置單獨的集成測試階段，而是和單元測試合并，如分層單元測試。軟件測試合理策略與流程什么時候進行集成測試？理論上是在單元測試之后進行，但效率低，實際幾乎可以同步進行。依據(jù)？單元測試的模塊以及《概要設計》文檔。由誰來進行集成測試?主要是開發(fā)人員或白盒測試工程師。軟件測試合理策略與流程集成測試的模式非增量式測試模式增量式測試模式軟件測試合理策略與流程2.4.1非增量式測試非增量式測試也稱為一次性集成，是采用一步到位的方法來構造測試：

——對所有模塊進行獨立的單元測試后，按照程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。

軟件測試合理策略與流程采用非增量式測試方法進行集成測試AS3S4S5d2Cd4Ed5Fd1Bs1d3s2DABCDEFABCDEF（1）程序結構圖（3）集成測試示意圖（2）各模塊的單元測試示意圖軟件測試合理策略與流程非增量式測試的缺點：需要所有單元就緒，而實際上集成測試可以和單元測試重疊并行，因此不利于開發(fā)進度；問題定位比較困難，集成后一旦出現(xiàn)問題，很難判定出錯的具體原因和位置。

適合于規(guī)模較小的應用，有利于并行開發(fā)。軟件測試合理策略與流程2.4.2增量式測試增量式測試的集成是逐步實現(xiàn)的：

逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊結合成程序包，再將這些模塊集成為較大系統(tǒng)。

按照不同的實施次序，增量式集成測試又可以分為：（1）自頂向下增量式測試（2）自底向上增量式測試（3）自頂向下與自底向上相結合（“三明治”）

軟件測試合理策略與流程自頂向下法(top-downintegration)自頂向下法：逐步集成和逐步測試是按照結構圖自上而下進行的，即首先集成主控模塊（主程序），然后依照控制層次結構向下進行集成,逐漸將各模塊集成。策略有兩種，深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）。深度優(yōu)先方式的集成：——首先集成在結構中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。

廣度優(yōu)先方式的集成：——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。軟件測試合理策略與流程自頂向下增量式測試（續(xù)）集成測試的整個過程由3個步驟完成：（1）主控模塊作為測試驅動器。（2）根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。（3）在每個模塊被集成前，都必須進行單元測試。重復第2步，直到整個系統(tǒng)被測試完成。

軟件測試合理策略與流程自頂向下增量式測試（續(xù)）ABCDEFAS1S2S3A