2016-09-27 46 views

回答

1

是的。測試只能證明您所測試的沒有缺陷。動態測試不能涵蓋所有依賴性環境中的所有可能的輸入和輸出。

首先是簡單地不測試有問題的代碼。這可以通過檢查您的測試的coverage進行驗證。即使你達到100%的覆蓋率,仍然可能存在缺陷。

接下來是不檢查所有可能的輸入類型和範圍。例如,如果您有掃描字符串中某個單詞的功能,則需要檢查...

  • 字符串的開始處的單詞。
  • 字符串末尾的單詞。
  • 單詞在字符串中間。
  • 一個沒有單詞的字符串。
  • 空字符串。

這些被稱爲boundary conditions,包括喜歡的東西:

  • 負數
  • 空字符串
  • 非常大的值
  • 小數
  • 個Unicode的
  • 空文件
  • 非常大的文件

如果有問題的代碼在全局變量保持狀態,也許在一個對象,也許,你要測試的狀態不會被破壞或干擾隨後的運行。

如果您正在進行並行處理,您必須測試由於嘗試同時執行同一事件而導致的死鎖或損壞的任何數量的可能性。例如,兩個進程試圖寫入同一個文件。或者兩個進程都在等待同一資源的鎖定。他們只鎖定他們需要的東西嗎?他們儘快放棄鎖定嗎?

一旦你測試了代碼應該工作的所有方式,你必須測試它可能發生故障的所有方式,它是否以異常(而不是垃圾)方式優雅地失敗,錯誤是否使它損壞狀態等等。它如何處理資源故障,如未能連接到數據庫?這對於處理數據庫和文件非常重要,以確保失敗不會讓事情發生部分改變。

例如,如果你從一個賬戶轉移資金到另一個你可能會這樣寫:

my $from_balance = get_balance($from); 
my $to_balance = get_balance($to); 

set_balance($from, $from_balance - $amount); 
set_balance($to, $to_balance + $amount); 

會發生什麼,如果第一set_balance後的程序崩潰?如果另一個流程更改爲get_balanceset_balance之間的平衡,會發生什麼情況?必須考慮並測試這些併發問題。

代碼可以運行在不同的環境中。不同的操作系統。不同的編譯器。不同的依賴關係。不同的數據庫所有的版本都不一樣。所有這些都必須經過測試。

該測試可能只是錯誤的。在測試中可能是一個錯誤。在規範中可能是一個錯誤。通常,用不同的方式測試相同的代碼以避免這個問題。

該測試可以是正確的,規範可以是正確的,但功能是錯誤的。這可能是一個糟糕的設計。這可能是一個壞主意。你可以說這不是一個「bug」,但如果用戶不喜歡它,它需要被修復。

如果你的測試使用了大量的嘲諷,你的嘲笑可能不會反映被嘲弄的東西實際上是如何表現的。

依此類推。

對於所有這些缺陷,動態測試仍然是測試超過幾十行代碼的最佳選擇。