我正在为我的应用程序的 API 部分整理受 BDD 启发的单元测试。（是的，我知道，BDD 应该是关于域并与西装交谈，但我宁愿先在不太明显的东西上尝试 BDD）
普通用途。 开发人员使用具有普通参数值的 API 方法。
极端使用。开发人员使用异常大/小参数调用 API。例如， zip() 方法传递了一个 2 GB 的文件。
API 滥用。开发人员使用疯狂的参数调用 API——疯狂的程序员会将日期传递给整数参数，对吧？——参数被遗忘，等等。
恶意黑客攻击。开发人员并不关心 API 的用途，而是寻找执行任意代码的方法。测试将包括 JavaScript、SQL，只是为了看看我们是否可以让它们在任何地方执行。
还有其他我应该考虑的情况吗？
当然，总是有更多的场景需要考虑。坦率地说，有一个实际上无限的场景池。这是一个非常开放的问题。
对于恶意黑客攻击场景，你应该只关心明显的缓冲区溢出点，然后坚持测试确认的安全漏洞，以免意外重新打开它们。并且无论何时你确实得到了一个确认的漏洞，寻找代码中使用类似编程技术和模式的每个地方，并抢先测试/修复它们。然而，在很多情况下，模糊测试会给你带来更好的结果。自动化测试是处理安全问题的重要组成部分，但绝不应该是工具箱中的主要工具。
其他需要考虑的事情可能是特定于数据的。例如，在解析日期时，请务必处理 2/29/2009 或 9/31/2009 之类的内容。如果可以，请尝试处理 1/1/1900 和 12/31/2038（您的图书馆可能不允许您）。
您可以做的一件事是检查您正在进行的所有库调用的文档，找出在哪些条件下引发了哪些异常，并故意尝试查找将触发这些异常的输入，然后确保您有测试验证是否处理了这些异常，或者在库代码的情况下，记录了这些异常。
代码覆盖工具和代码变异还可以帮助您识别以前没有被覆盖的场景。