回答
是的。測試只能證明您所測試的沒有缺陷。動態測試不能涵蓋所有依賴性環境中的所有可能的輸入和輸出。
首先是簡單地不測試有問題的代碼。這可以通過檢查您的測試的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_balance
和set_balance
之間的平衡,會發生什麼情況?必須考慮並測試這些併發問題。
代碼可以運行在不同的環境中。不同的操作系統。不同的編譯器。不同的依賴關係。不同的數據庫所有的版本都不一樣。所有這些都必須經過測試。
該測試可能只是錯誤的。在測試中可能是一個錯誤。在規範中可能是一個錯誤。通常,用不同的方式測試相同的代碼以避免這個問題。
該測試可以是正確的,規範可以是正確的,但功能是錯誤的。這可能是一個糟糕的設計。這可能是一個壞主意。你可以說這不是一個「bug」,但如果用戶不喜歡它,它需要被修復。
如果你的測試使用了大量的嘲諷,你的嘲笑可能不會反映被嘲弄的東西實際上是如何表現的。
依此類推。
對於所有這些缺陷,動態測試仍然是測試超過幾十行代碼的最佳選擇。
- 1. TestNG故障不是故障
- 2. iRuntimeExceptions被認爲是故障或故障?
- 3. 什麼是故障 - 段故障,即...?
- 4. 故障動態表
- 5. ,檢測故障
- 6. C++程序故障?
- 7. 方法是故障
- 8. 什麼是故障? :(
- 9. JUnit測試類故障
- 10. Jboss故障轉移測試
- 11. 單元測試WCF故障
- 12. 故障可以用Python
- 13. Jquery&Joomla無故障故障
- 14. 故障排除_mkdir故障
- 15. WCF故障 - 哪種故障?
- 16. JavaScript故障排除故障
- 17. Win32Shutdown通用故障
- 18. 故障使用單元測試
- 19. 如何跳過surefire測試但運行故障安全測試?
- 20. iOS應用程序故障
- 21. 動畫故障
- 22. 動畫故障
- 23. 通過sed管道故障
- 24. 可可教程故障
- 25. 線程故障
- 26. 動態隨機數故障
- 27. 故障而試圖通過PECL
- 28. 檢測Ckeditor故障
- 29. 試圖動態asp:FileUpload,刷新故障
- 30. 故障快速和故障安全異常處理原則是否不兼容?
呃......呃?我不知道你在問什麼,我相當肯定其他人可能會遇到同樣的問題。你認爲你可以澄清一點嗎? :) –
我相信這是經典的「我怎麼知道我的軟件是否是無bug的」問題。 – Schwern