測試分類及報告格式

1、測試的分類1測試用例設計方法1黑盒測試(Black-boxTestDesignTechnique)技術一:1黑盒測試(Black-boxTestDesignTechnique)技術二:3(參考技術一得到的測試用例設計流程)4白盒測試(White-boxTestDesignTechnique)技術一:5測試策略與過程6單元測試6集成測試7系統(tǒng)測試7驗收測試7基本要求和適用要求7測試基本方法7測試組織7選擇測試技術的相對依據(jù)7測試的分類測試用例設計方法黑盒測試(Black-boxTestDesignTechnique)技術一：(從黑盒測試的技術來分類)1等價類劃分(EquivalenceParti

2、tioning)：定義：分步驟的把無限的測試用例集減的很小，但過程同樣有效。目標：把可能的測試用例集縮減到可控制且仍然足以測試軟件的小范圍內分類：有效等價類、無效等價類特性：嚴格控制測試用例的增加，減少為達到“合理測試”的某些既定目標而必須設計的其他測試用例的數(shù)量它覆蓋了大部分其他可能的測試用例。(它會告訴我們，使用或不使用這個特定的輸入集合，哪些錯誤會被發(fā)現(xiàn)，哪些會被遺漏掉)等價類覆蓋率計算：等價類覆蓋率=(已覆蓋等價類數(shù)目/總等價類數(shù)目)*100%優(yōu)點：在有明確的條件和限制的情況下，利用等價類劃分技術可以幫助測試人員在有限的時間內選擇合適的測試數(shù)據(jù)和組合，以減少冗余的測試用例2. 邊界值分

3、析(BoundaryValueAnalysis)：定義：通過分析輸入或輸出的邊界值并取值進行測試用例設計的一種黑盒測試。包含：邊界條件、次邊界條件(有些邊界在軟件內部，最終用戶幾乎看不到，但是軟件測試員仍有必要進行檢查。這樣的邊界條件稱為次邊界條件sub-boundaryconditions或者內部邊界條件internalboundaryconditions）注意：緩沖區(qū)溢出（bufferoverrun）是由邊界條件卻引起的，它是造成軟件安全問題的頭號原因等價類劃分與邊界值分析的區(qū)別：與從等價類中挑選出任意一個元素作為代表不同，邊界值分析需要選擇一個或多個元素，以便等價類的每個邊界都經(jīng)過一次測

4、試。與僅僅關注輸入條件（輸入空間）不同，還需要考慮從結果空間（輸出等價類）設計測試用例邊界值覆蓋率計算：邊界值覆蓋率=（已覆蓋的邊界值數(shù)目/總的邊界值數(shù)目）*100%優(yōu)點：邊界值分析技術往往是等價類劃分技術的有效補充3決策表測試：定義：決策表或因果圖是通過分析說明，識別出系統(tǒng)可能的條件和行為，并最終設計測試用例的技術。決策表組成部分：條件樁（ConditionStub）:列出了測試對象的所有條件。一般情況下，列出的條件的次序不會影響測試對象的動作動作樁（ActionStub）:列出了測試對象的所有可能執(zhí)行的操作。一般情況下，這些執(zhí)行的操作沒有先后順序的約束。條件項（ConditionEntry

5、）組合：列出針對特定條件的取值的組合，即條件的真假值。每一列條件值得組合形成一個規(guī)則。動作項（ActionEntry）組合：列出在不同條件項的各種取值組合下（規(guī)則），測試對象應該執(zhí)行的組合。決策表或因果表的覆蓋率計算：決策表覆蓋率=（已覆蓋的規(guī)則書/總的規(guī)則數(shù)）*100%優(yōu)缺點：決策表技術將各種輸入條件的組合，以及它們的行為生成決策表，是一種系統(tǒng)化而且非常正式的方法，它可以覆蓋一些在其他測試設計技術中沒有包含的輸入組合。隨著被測對象條件數(shù)目的增加，得到的決策表和因果圖的規(guī)模會急劇變大，不僅失去可讀性，并且變得難以處理4. 狀態(tài)轉換測試：定義：指的是所設計的測試用例用來執(zhí)行有效和無效的狀態(tài)轉換的

6、一種黑盒測試技術。狀態(tài)轉換圖：通過描繪系統(tǒng)的“狀態(tài)”及引起系統(tǒng)“狀態(tài)轉換”的“事件”，來表示系統(tǒng)的行為。此外狀態(tài)轉換圖還指明了作為特定事件的結果，系統(tǒng)將做哪些“動作”（例如處理數(shù)據(jù)）。因此狀態(tài)轉換圖提供了行為建模機制。狀態(tài)轉換圖應該表示出的項目：軟件可能進入的每一種獨立狀態(tài)。從一種狀態(tài)轉入另一種狀態(tài)所需的輸入和條件。進入或者退出某周狀態(tài)時的設置條件及輸出結果。狀態(tài)轉換樹：由于狀態(tài)轉換圖中可能存在循環(huán)的回路，為了方便設計測試用例，需要將狀態(tài)轉換圖轉變?yōu)橹话囟ㄞD換順序的狀態(tài)轉換樹。優(yōu)點：狀態(tài)轉換測試技術適用于那些狀態(tài)起著重要作用，并且功能也會因為狀態(tài)不同而受到影響的測試對象。在面向對象的系統(tǒng)中

7、，對象可以有不同的狀態(tài)，選擇針對對象進行操作的方法必須能根據(jù)不同的狀態(tài)做出相應的反應。狀態(tài)轉換測試技術對于面向對象的測試非常重要，因為它考慮到了面向對象的特征。5. 用例測試：定義：通過用例或業(yè)務場景設計測試用例的測試技術。黑盒測試（Black-boxTestDesignTechnique）技術二:（從黑盒測試的內容分類）軟件最簡單的分類：數(shù)據(jù)（范圍）和程序數(shù)據(jù)包括鍵盤輸入、鼠標單擊、磁盤文件、打印輸出等。軟件是指可執(zhí)行的流程、轉換、邏輯和運算。1. 數(shù)據(jù)測試：數(shù)據(jù)測試關鍵的原則：邊界條件次邊界條件空值無效數(shù)據(jù)2. 狀態(tài)測試有效狀態(tài)測試參考上述轉換測試。失效狀態(tài)測試包含以下三種測試條件：競爭條

8、件和時序錯亂:（牽扯硬件上運行的其他軟件共用同一種的資源時發(fā)生的特殊情況）重復測試：是不斷執(zhí)行同樣的操作。主要原因是檢查是否存在內存泄露（memoryleaks）。壓迫測試：使軟件在不夠理想的條件下運行-內存小、磁盤空間少、CPU速度慢、調制調解器速率低等。目的是觀察軟件對外部資源的要求和依賴的程度。重負測試：盡可能的提供條件任其發(fā)揮。讓軟件處理盡可能大的數(shù)據(jù)。目的是最大限度的發(fā)掘軟件的能力，讓其不堪重負。參考技術一得到的測試用例設計流程）通過分析決策表測試確認系統(tǒng)可能運行的行為和所需條件需要進行數(shù)據(jù)測試的系統(tǒng)行為（數(shù)據(jù)包括鍵盤輸入、鼠標單擊、磁盤文件、打印輸出等）需要進行狀態(tài)測試的系統(tǒng)行為（

9、指可執(zhí)行的流程、轉換、邏輯和運算）通過分析等價類劃分來確定等價值集合通過狀態(tài)轉換測試來確認系統(tǒng)在狀態(tài)轉換間所需要的行為和所需條件通過對等價值集合的分析獲得邊界值、次邊界值、空值、無效數(shù)據(jù)決策表到底是什么？我的理解是：例如一個注冊用戶的頁面，決策表測試就是測試用戶在這個頁面的所有可響應的操作所需要的條件和行為。白盒測試(White-boxTestDesignTechnique)技術一：靜態(tài)白盒測試定義靜態(tài)白盒測試是在不執(zhí)行軟件的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，也稱為結構化分析。靜態(tài)白盒測試的優(yōu)點：1. 盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以發(fā)現(xiàn)或隔離的軟

10、件2. 為黑盒測試員在接受軟件進行測試時設計和應用測試用例提供思路靜態(tài)白盒測試的過程與規(guī)范：正式審査(formalreview)就是進行靜態(tài)白盒測試的過程。它包含了四個基本要素：1. 確定問題：審查的目的是找出軟件的問題-不僅是出錯的項目，還包括遺漏項目。2. 遵守規(guī)則：審查要遵守一套固定的規(guī)則，規(guī)則可能設定要審查的代碼量，花費多少時間，哪些內容需要做評價。3. 準備：每一個參與者都為審查做準備，并盡自己的力量。4. 編寫報告：審查小組必須做出審查結果的書面報告總結，并使報告便于開發(fā)小組的成員使用。編碼標準和規(guī)范：有三個重要的原因要堅持標準或規(guī)范1. 可靠性：事實證明按照某種標準或規(guī)范編寫的代

11、碼比不這樣做的代碼更加可靠和安全2. 可讀性/維護性：符合設備標準和規(guī)范的代碼易于閱讀、理解和維護3. 移植性：代碼經(jīng)常需要在不同的硬件中運行，或者使用不同的編譯器編譯。如果代碼符合設備標準，遷移到另一個平臺就會輕而易舉，甚至完全沒有障礙。通用代碼審査清單：數(shù)據(jù)引用錯誤：指使用未經(jīng)正確聲明和初始化的變量、常量、數(shù)組、字符串或記錄而導致的軟件缺陷。(引起緩沖區(qū)溢出的主要原因)數(shù)據(jù)聲明錯誤：數(shù)據(jù)聲明缺陷產(chǎn)生的原因是不正確的聲明或使用變量和常量。計算錯誤：計算或者運算錯誤實質上是糟糕的數(shù)學問題。計算無法得到預期結果。比較錯誤：小于、大于、等于、不等于、真、假。比較和判斷錯誤很可能是由于邊界條件問題。

12、控制流程錯誤：控制流程錯誤的原因是編程語音中循環(huán)等控制結構未按預期方式工作。它們通常由計算或者比較錯誤直接或間接造成。子程序參數(shù)錯誤：來源是軟件程序不正確的傳遞數(shù)據(jù)。輸入輸出錯誤：輸入輸出錯誤包括文件讀取、接受鍵盤或鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。其他檢查：動態(tài)白盒測試定義：動態(tài)白盒測試不僅僅是查看代碼的運行情況，還包括直接測試和控制軟件。動態(tài)白盒測試的4個主要部分：1. 直接測試底層函數(shù)、過程、子程序和庫。在MicrosoftWindows中這稱為應用程序編程接口(API)。2. 以完整程序的方式從頂層測試軟件，但是根據(jù)對軟件運行的了解調整測試用例。3. 從軟件獲得讀取變量和

13、狀態(tài)信息的訪問權，以確定測試與預期結果是否相符，同時，強制軟件以正常測試難以實現(xiàn)的方式運行。4. 估算執(zhí)行測試時“命中”的代碼量和具體代碼，然后調整測試，去掉多余的測試用例，補充遺漏的用例。注意：動態(tài)白盒測試和調試(debugging)不同。動態(tài)測試的目標是尋找軟件缺陷，調試的目標是修復缺陷?；液袦y試：測試策略與過程在底層進行的測試稱為單元測試(unittesting)或者模塊測試(moduletesting)。單元經(jīng)過測試，底層軟件缺陷被找出并修復之后，就集成在一起，對模塊的組合進行集成測試(integrationtesting)o這個不斷增加的測試過程繼續(xù)進行，加入越來越多的軟件片段，直至

14、整個產(chǎn)品-至少是產(chǎn)品的主要部分在稱為系統(tǒng)測試(systemtesting)的過程中一起測試遞增測試分為兩條途徑：1 自底而上(bottom-up)2 自頂而下(top-down)單元測試定義：針對單個軟件組件的測試稱為單元測試(組件測試)。目的：為了驗證軟件組件是否按照組件詳細說明的要求工作，發(fā)現(xiàn)需求和設計中存在的錯誤以及編碼過程中引入的錯誤。組件測試的任務：局部數(shù)據(jù)結構測試、組件邊界值測試、組件中獨立的執(zhí)行路徑測試，以及組件的錯誤處理測試等方面。組件測試：包括性能測試和特定的非功能測試。樁或驅動器：需要一些輔助的組件與被測組件一起形成一個可運行的系統(tǒng)，這些輔助的組件稱為樁、驅動器等。樁的定義：1.驅動器模塊：用于模擬被測組件的上級模塊，它生成測試數(shù)據(jù)，把相關數(shù)據(jù)傳送給被測組件，啟動被測組件獲得反饋信息并輸出相應的結果。2.樁模塊：用于模擬被測組件工作過程中所調用的模塊，它們一般只進行很少的數(shù)據(jù)處理，例如打印返回信息。組件測試目的：通過組件測試可以發(fā)現(xiàn)各種典型的軟件缺陷，例如計算錯誤、需求或功能遺漏或程序路徑選擇錯誤。組件測試需要考慮的測試內容：1.檢查組件接口參數(shù)，這就是測試的基礎。（只有在數(shù)據(jù)能正確流入、流出組件的前提下，其他測試才有意義）2.檢查局部數(shù)據(jù)結構，可以用來保證臨時存儲在組件內的數(shù)據(jù)在程序執(zhí)行過程中的完整性和正確性。（局部數(shù)據(jù)結構