我正在爲我的應用程序的API部分編寫BDD靈感單元測試。 （是的，我知道，BDD應該是域與談話的西裝，但我寧願嘗試BDD在不太顯眼的東西第一）針對泛型API的BDD方案的建議？
正常使用。開發人員使用帶有普通參數值的 API方法。
至尊使用。開發人員使用異常大/小的 參數調用API 。例如。 zip（）方法傳遞一個2 GB的文件。
API濫用。開發者調用API 瘋狂的參數 - 什麼瘋狂 程序員會在日期傳遞給 整數參數，正確的 - ？參數 遺忘等
惡意黑客。開發商 不關心什麼API旨在 做，而是正在尋找 的方式來執行任意代碼。 測試將包括JavaScript，SQL 只是爲了看看我們是否可以讓它們在任何地方執行到 。
我應該考慮其他場景嗎？
當然，總是有更多的場景需要考慮。坦率地說，有一個有效的無限情景池。這實在是一個非常開放的問題。
對於惡意黑客的場景，你真的應該只針對緩衝區溢出明顯的斑點麻煩，然後堅持測試確認的安全漏洞，讓你不小心重新打開。任何時候，如果您確實收到確認的漏洞，請追查代碼中使用類似編程技術和模式的每個地方，並搶先測試/修復這些漏洞。但是，在很多情況下，模糊會給你更好的結果。自動化測試是處理安全問題的重要部分，但它決不應該是工具箱中的主要工具。
其他需要考慮的東西很可能是具體的數據。例如，解析日期時，一定要處理像2009年2月29日或9/31/2009這樣的東西。如果可以的話，嘗試處理1/1/1900和12/31/2038（你的圖書館可能不會讓你）。
你可以做的一件事是檢查你所做的所有庫調用的文檔，找出哪些條件下引發的異常，並故意嘗試找到引發這些異常的輸入，然後確保你已經有測試驗證這些異常是否被處理，或者在庫代碼的情況下被記錄。
代碼覆蓋工具和代碼突變還可以幫助您找出了以前沒有被覆蓋的情況。