白盒測試相關的一些知識

4 人贊了文章

　　在白盒測試中，可以使用各種測試方法進行測試。下面這篇文章，可能比較枯燥，如果不樂意讀，可以先收藏。如果在你的工作中真遇到白盒測試的話，可以回過頭再來看看，還是值得讀一讀。

　　一般來說，白盒測試時要考慮以下5個問題：

　　1)測試中盡量先用自動化工具來進行靜態結構分析。

　　2)測試中建議先從靜態測試開始，如：靜態結構分析、代碼走查和靜態質量度量，然後進行動態測試，如：覆蓋率測試。

　　3)將靜態分析的結果作為依據，再使用代碼檢查和動態測試的方式對靜態分析結果進行進一步確認，提高測試效率及準確性。

　　4)覆蓋率測試是白盒測試中的重要手段，在測試報告中可以作為量化指標的依據，對於軟體的重點模塊，應使用多種覆蓋率標準衡量代碼的覆蓋率。

　　5)在不同的測試階段，測試的側重點是不同的。

　　在單元測試階段：以程序語法檢查、程序邏輯檢查、代碼檢查、邏輯覆蓋為主。

　　在集成測試階段：需要增加靜態結構分析、靜態質量度量、以介面測試為主。

　　在系統測試階段：在真實系統工作環境下通過與系統的需求定義作比較，檢 驗完整的軟體配置項能否和系統正確連接，發現軟體與系統/子系統設計文檔和軟體開發合同規定不符合或與之矛盾的地方;驗證系統是否滿足了需求規格的定義， 找出與需求規格不相符或與之矛盾的地方，從而提出更加完善的方案，確保最終軟體系統滿足產品需求並且遵循系統設計的標準和規定。

　　驗收測試階段：按照需求開發，體驗該產品是否能夠滿足使用要求，有沒有達到原設計水平，完成的功能怎樣，是否符合用戶的需求，以達到預期目的為主。

　　1、代碼檢查

　　代碼檢查是靜態測試的主要方法，它**代碼走查、桌面檢查、流程圖審查等。下面通過如下幾點來介紹代碼檢查。

　　(1)概述

　　代碼檢查主要檢查代碼和流圖設計的一致性，代碼結構的合理性，代碼編寫的標準性、可讀性，代碼的邏輯表達的正確性等方面。它**變數檢查，命名和類型審查，程序邏輯審查，程序語法檢查和程序結構檢查等內容。

　　最常見的靜態測試是找出源代碼的語法錯誤，這類測試可由編譯器來完成。

　　(2)代碼檢查的目的

　　代碼檢查是為達到以下目的：

　　檢查程序是不是按照某種標準或規範編寫的。

　　發現程序缺陷。

　　發現程序產生的錯誤。

　　檢查代碼是不是流程圖要求的。

　　檢查有沒有遺漏的項目。

　　使代碼易於移植，因為代碼經常需要在不同的硬體中運行，或者使用不同的編譯器編譯。

　　使代碼易於閱讀、理解和維護。

　　(3)代碼檢查需要的文檔

　　在進行代碼檢查前應準備好需求文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準、代碼缺陷檢查表和流程圖等。

　　2、代碼檢查的方式

　　代碼檢查的方式有3種，下面分別介紹。

　　1)桌面檢查

　　桌面檢查是程序員對源程序代碼進行分析、檢驗，並補充相關的文檔，發現程序中的錯誤的過程。

　　由於程序員熟悉自己的程序，可以由程序員自己檢查，這樣可以節省很多時間，但要注意避免自己的主觀判斷。

　　2)走查

　　走查是程序員和測試員組成的審查小組通過邏輯運行程序，發現問題。小組成員要提前閱讀設計規格書、程序文本等相關文檔，利用測試用例，使程序邏輯運行。

　　走查可分為以下兩個步驟：

　　① 小組負責人把材料發給每個組員，然後由小組成員提出發現的問題。

　　② 通過記錄，小組成員對程序邏輯及功能提出自己的疑問，開會探討發現的問題和解決方法。

　　3)代碼審查

　　代碼審查是程序員和測試員組成的審查小組通過閱讀、討論、分析技術對程序進行靜態分析的過程。

　　代碼審查可分為以下兩個步驟：

　　① 小組負責人把程序文本、規範、相關要求、流程圖及設計說明書發給每個成員。

　　② 每個成員將所發材料作為審查依據，但是由程序員講解程序的結構、邏輯和源程序。在此過程中，小組成員可以提出自己的疑問;程序員在講解自己的程序時，也能發現自己原來沒有注意到的問題。

　　為了提高效率，小組在審查會議前，可以準備一份常見錯誤清單，提供給參加成員對照檢查。

　　在實際應用中，代碼檢查能快速找到20%~30%的編碼缺陷和邏輯設計缺陷，代碼檢查看到的是問題本身而非問題的徵兆。代碼走查是要消耗時間的，而且需要知識和經驗的積累。

　　3、代碼檢查項目

　　下面介紹代碼檢查項目。

　　1.目錄文件組織

　　目錄文件組織要遵循以下原則：

　　1)所有的文件名簡單明了，見名知意。

　　2)文件和模塊分組清晰。

　　3)每行代碼在80個字元以內。

　　4)每個文件只**一個完整模塊的代碼。

　　2.檢查函數

　　檢查函數要遵循以下原則：

　　1)函數頭清晰地描述了函數的功能。

　　2)函數的名字清晰地定義了它所要做的事情。

　　3)各個參數的定義和排序遵循特定的順序。

　　4)所有的參數都要是有用的。

　　5)函數參數介面關係清晰明了。

　　6)函數所使用的演算法要有說明。

　　3.數據類型及變數

　　數據類型及變數要遵循以下原則：

　　1)每個數據類型都有其解釋。

　　2)每個數據類型都有正確的取值。

　　3)數據結構盡量簡單，降低複雜性。

　　4)每一個變數的命名都明確地表示了其代表什麼。

　　5)所有的變數都?皇褂謾?

　　6)全部變數的描述要清晰。

　　4.檢查條件判斷語句

　　檢查條件判斷語句要遵循以下原則：

　　1)條件檢查和代碼在程序中清晰表露。

　　2)if/else的使用正確。

　　3)數字、字元和指針判斷明確。

　　4)最常見的情況優先判斷。

　　5.檢查循環體制

　　檢查循環體制要遵循以下原則：

　　1)任何循環不得為空。

　　2)循環體系清晰易懂。

　　3)當有明確的多次循環操作時使用for循環。

　　4)循環命名要有意義。

　　5)循環終止條件清晰。

　　6.檢查代碼注釋

　　檢查代碼注釋時要遵循以下原則：

　　1)有一個簡單的關於代碼結構的說明。

　　2)每個文件和模塊都要有相應的解釋。

　　3)源代碼能夠自我解釋，並且易懂。

　　4)每個代碼的解釋說明要明確地表達出代碼的意義。

　　5)所有注釋要具體、清晰。

　　6)所有無用的代碼及注釋要刪除。

　　7.桌面檢查

　　進行桌面檢查時要注意以下問題：

　　1)檢查代碼和設計的一致性。

　　2)代碼對標準的遵循、可讀性。

　　3)代碼邏輯表達的正確性。

　　4)代碼結構的合理性。

　　5)程序編寫與編寫標準的符合性。

　　6)程序中不安全、不明確和模糊的部分。

　　7)編程風格問題等。

　　8.其他檢查

　　其他檢查**如下內容：

　　1)軟體的擴展字元、編碼、兼容性、警告/提示信息。

　　2)檢查變數的交叉引用表：檢查未說明的變數和違反了類型規定的變數，以及變數的引用和使用情況。

　　3)檢查標號的交叉引用表：驗證所有標號的正確性。

　　4)檢查子程序、宏、函數：驗證每次調用與所調用位置是否正確，調用的子程序、宏、函數是否存在，參數是否一致。

　　5)等價性檢查：檢查全部等價變數的類型的一致性。

　　6)常量檢查：確認常量的取值和數制、數據類型。

　　7)標準檢查：檢查程序中是否有違反標準的問題。

　　8)風格檢查：檢查程序的設計風格。

　　9)比較控制流：比較設計控制流圖和實際程序生成的控制流圖的差異。

　　10)選擇、激活路徑：在設計控制流圖中選擇某條路徑，然後在實際的程序中激活這條路徑，如果不能激活，則程序可能有錯。

　　11)補充文檔：根據以上檢查項目，可以編製代碼規則、規範和檢查表等作為測試用例。

　　12)對照程序的規格說明，詳細閱讀源代碼，比較實際的代碼，從差異中發現程序的問題和錯誤。

　　13)檢查必須遵守規定代碼的語法格式和規則(如排版、注釋、標識符命名、可讀性、變數、函數、過程、可測性、程序效率、質量保證、代碼編輯、編譯、審查、代碼測試、維護、宏)等各方面的編碼要求。

　　在進行人工代碼檢查時，可以製作代碼走查缺陷表。在缺陷檢查表中，我們列出工作中遇到的典型錯誤，如下所示：

　　(1)格式部分

　　嵌套的IF是否正確地縮進。

　　注釋是否準確並有意義。

　　使用的符號是否有意義。

　　代碼基本上是否與開始時的模塊模式統一、一致。

　　是否遵循了**的編程標準。

　　(2)入口和出口的連接

　　初始入口和最終出口是否正確。

　　被傳送的參數值是否正確地設置了。

　　對關鍵的被調用的模塊的意外情況是否有所處理(如丟失、混亂)。

　　對另一個模塊的每一次調用時，全部所需的參數是否傳送給每一個被調用的模塊。

　　(3)存儲器問題

　　每一個域在第一次使用前是否正確地初始化。

　　規定的域是否正確。

　　每個域是否有正確的變數類型聲明。

　　(4)判斷及轉移

　　用於判斷的是否是正確的變數。

　　是否判斷了正確的條件。

　　每個轉移目標是否正確地並且至少執行了一次。

　　(5)性能

　　性能是否最佳。

　　(6)可維護性

　　清單格式是否適用於提高可讀性。

　　各個程序塊之間是否符合代碼的邏輯意義。

　　(7)邏輯

　　全部設計是否已經實現。

　　代碼所做的是否是設計規定的內容。

　　每一個循環是否執行了正確的次數。

　　(8)可靠性

　　對從外部介面採集的數據是否確認過。

　　(9)內存設計

　　數組或指針的下標是否越界。

　　是否修改了指向常量的指針的內容。

　　是否有效地處理了內存耗盡的問題。

　　是否出現了不規範指針(指針變數沒有被初始化、用free或者delete釋放了內存之後，忘記將指針設置為Null)。

　　是否忘記為數組和動態內存賦初值。

　　用malloc或者new申請內存之後，是否立即檢查指針值是否為Null。

　　(10)關於類的高級特性

　　是否違背了繼承和組合的規則。

　　4、靜態結構分析

　　靜態結構分析主要是以圖形的方式表現程序的內部結構，例如函數調用關係圖、函數內部控制流圖。

　　靜態結構分析是測試者通過使用測試工具分析程序源代碼的系統結構、數據 結構、數據介面、內部控制邏輯等內部結構，生成函數調用關係圖、模塊控制流圖、內部文件調用關係圖等各種圖形圖表，清晰地標識整個軟體的組成結構，便於理 解，通過分析這些圖表(**控制流分析、數據流分析、介面分析、表達式分析)，檢查軟體是否存在缺陷或錯誤。

　　通過應用程序各函數之間的調用關係展示了系統的結構，這可以通過列出所有函數，用連線表示調用關係和作用來實現。靜態結構主要分析以下內容：

　　1)檢查函數的調用關係是否正確。

　　2)是否存在孤立的函數沒有被調用。

　　3)明確函數被調用的頻繁度，對調用頻繁的函數可以重點檢查。

　　5、SQL語句測試

　　SQL語句測試分為語句檢查和類型轉移檢查，下面分別介紹。

　　1.語句檢查

　　語句檢查必須要檢查的十點內容如下：

　　1)每個資料庫對象都有擁有者。

　　2)Table: 是Database的基本單位，由行和列組成，用於存儲數據。

　　3)Data Type: 限制輸入到表中的數據類型。

　　4)Constraint: 有主鍵、外鍵、唯一鍵、預設和檢查5種。

　　5)Default: 自動插入常量值。

　　6)Rule: 限制表中列的取值範圍。

　　7)Trigger: 一種特殊類型的存儲過程，當有操作影響到它所保護的數據時，它會自動觸發執行。

　　8)Index: 提高查詢速度。

　　9)View: 查看一個或多個表的一種方式。

　　10)Stored Procedure: 一組預編譯的SQL語句，可以完成指定的操作。

　　2.類型轉換檢查

　　檢查SQL語句的類型轉換時，主要避免顯示或隱含的類型轉換。

　　6、代碼檢查的分析與評價

　　下面介紹代碼檢查的分析與評價主要要注意的問題。

　　1.功能

　　陳述經代碼檢查證實了的本軟體的功能。

　　2.缺陷和限制

　　陳述經代碼檢查測試證實的軟體缺陷和限制，說明每項缺陷和限制對軟體性能的影響，並說明全部測得的性能缺陷的累積影響。軟體的缺陷和限制如下：

　　1)數據引用錯誤：指未經正確聲明和初始化的變數、常量、數組、字元串或記錄而導致的軟體缺陷。

　　注意：數據引用錯誤是緩衝區溢出的主要原因，是一個造成許多軟體安全問題的缺陷。

　　2)數據聲明錯誤：其產生的原因是不正確地聲明或使用變數和常量。

　　3)計算錯誤。

　　4)比較錯誤：比較和判斷錯誤很可能是由於邊界條件問題而引起的，所以要特別注意這些地方。一般要檢查的運算符**：　<小於、>大於、=等於、 !=不等於、1真、0假。

　　5)控制流程錯誤：其產生的原因是編程語言中循環等控制結構未按預期方式工作，它們通常由計算或者比較錯誤直接或間接造成。

　　6)子程序參數錯誤：其產生的原因是軟體子程序不正確地傳遞數據。

　　7)輸入/輸出錯誤：**文件讀取、接受鍵盤或者滑鼠輸入以及向印表機或者屏幕等輸出設備寫入錯誤。

　　8)其他錯誤：**編碼錯誤以及警告/提示信息錯誤。

　　通過對代碼檢查結果的分析，需標明遺留缺陷、局限性和軟體的約束限制等，說明該代碼是否已達到預定的結果，判定代碼能否交付使用。審查小組必須做出審查結果的書面總結報告，並使報告便於開發小組的成員使用。