靜態白箱測試 (Static White Box Testing)

一、介紹
靜態白箱測試是在「不執行軟體」的條件下,對文件或是程式碼進行檢查或是審核,從而找出軟體有問題的過程。
不僅可以用在程式碼開發階段,甚至可以提早在設計階段針對項目文件做檢查。
檢查的目的不僅是要找出軟體的問題,還有一些可能有漏測的項目。

執行靜態白箱測試的人員們主要精力放在發現錯誤上,而不是在修正錯誤上。過程中會有專人記錄所有錯誤,會議結束之後, RD 會得到一份已發現錯誤的清單,根據這份清單來修正錯誤。

常見的靜態白箱測試

  • 桌面檢查 (desk checking)

首先先使用拼寫檢查器、語法檢查器..等任何可以幫助程式碼或文件進行字面檢查的任何工具。在這些工具裡檢測出來的問題都應該由作者自己來做修改。當修改的工作完成時,則使用之前所使用的工具再次檢查。

  • 程式碼走查 (code walkthrough)

程式碼走查的討論過程沒有程式碼審查那麼正式,通常由一組 3~5 位開發人員或是測試人員所組成的,包含編寫程式的那個人。
在走查的過程中,開發人員有機會向別人講述他的程式碼,也有助於開發人員再次地想過一遍,也可以透過讓其他人員看過,增加程式碼可讀性。

  • 程式碼審查 (code inspection)

代碼審查是一種正式的評審活動,應包含業務邏輯的審查、算法的效率、程式碼的風格、程式設計規則。按照定義好的程序審查,讓程式碼的質量更完美。

二、優缺點
優點:

    • 可以在開發過程早期發現 bug,精確定位出 bug 在 code 哪裡,使修復的時間和費用大幅度降低。
    • 可以得知軟體如何運作、存在哪些弱點和危險
    • 找出黑盒測試難以發現的問題。
    • 讓測試人員在執行黑盒測試時有白箱測試的思想,提供更多思考的方向。
    • 可學習團隊 programming/ coding style。
    • 了解演算法及 programming technique 等方面的訊息,了解有哪些 programming technique 的弱點和風險。

缺點:

  • 花費時間多
  • 程式碼走查與審查通常可以有效查找出 30%~70% 的邏輯設計和編碼錯誤,但無法有效地查找出高層次的設計錯誤,例如軟件需求分析階段的錯誤。

雖然靜態白箱測試主要討論的都是針對「程式碼」的部分,但事實上,靜態白箱測試不只能用在程式碼開發階段,也可以在開發的更早階段來設計或應用類似的方法,或是針對文件進行靜態白箱測試,像是針對需求或是設計文件進行審查。
所以「靜態白箱測試」 應該不是只限定於「程式碼」,而是一種方法,就看在不同階段要怎麼應用。

大抵而言,靜態白箱測試的除錯成本相對低很多,可在開發初期就掃出錯誤、精確定位 Bug,但入門門檻略高,需要多人一同執行,且擁有豐富經驗、相關知識背景及邏輯思考能力,成效才會高。

參考文章:
1. 關於靜態白盒測試檢驗代碼的一些問題
2. 靜態白盒測試
3. 靜態白盒測試
4. 代碼走查 (code walkthrough)
5. 桌面檢查 (desk checking)

廣告

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s