我正在为我的应用程序的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（你的图书馆可能不会让你）。
你可以做的一件事是检查你所做的所有库调用的文档，找出哪些条件下引发的异常，并故意尝试找到引发这些异常的输入，然后确保你已经有测试验证这些异常是否被处理，或者在库代码的情况下被记录。
代码覆盖工具和代码突变还可以帮助您找出了以前没有被覆盖的情况。