对于通用 API 的 BDD 场景有什么建议吗？
我正在为我的应用程序的 API 部分组合受 BDD 启发的单元测试。 （是的，我知道，BDD 应该是关于领域并与西装交谈的，但我宁愿先在不太明显的东西上尝试 BDD）
普通用途。 开发人员使用这 具有普通参数值的 API 方法。
极端使用。 开发者调用API 具有异常大/小的参数。 例如，向 zip() 方法传递一个 2 GB 的文件。
API 滥用。开发人员调用 带有疯狂参数的 API——太疯狂了 程序员会将日期传递给 整数参数，对吗？--参数是 忘记等。
恶意黑客攻击。 开发商 不关心 API 的用途，而是寻找执行任意代码的方法。 测试包括 JavaScript、SQL 只是为了看看我们能否让他们 在任何地方执行。
我还应该考虑其他场景吗？
I'm putting together BDD inspired unit tests for the API part of my application. (Yeah, I know, BDD is supposed to be about the domain and talking to the suits, but I'd rather try out BDD on something less visible first)
Ordinary use. The developer uses the
API methods with ordinary parameter values.Extreme use. The developer invokes the API
with unusually large/small parameters. E.g. the zip() method is passed a 2 GB file.API abuse. The developer invokes the
API with crazy parameters--what crazy
programmer would pass in a date to an
integer parameter, right?--parameters are
forgotten, etc.Malicious hacking. The developer
doesn't care what the API is intended to do, but instead is looking for ways to execute arbitrary code.
Tests would include JavaScript, SQL
just to see if we can get them to
execute anywhere.
Are there any other scenarios I should consider?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当然，总是有更多的场景需要考虑。 坦率地说，场景实际上是无限的。 这是一个极其开放性的问题。
关于恶意黑客攻击场景，您实际上应该只关注明显的缓冲区溢出点，然后坚持测试已确认的安全漏洞，这样您就不会意外地重新打开它们。 每当您确实发现漏洞时，请寻找代码中使用类似编程技术和模式的每个位置，并抢先测试/修复这些漏洞。 然而，在很多情况下，模糊测试会给你带来更好的结果。 自动化测试是处理安全问题的重要组成部分，但它绝不应该成为工具箱中的主要工具。
其他需要考虑的事情可能是特定于数据的。 例如，在解析日期时，请务必处理 2/29/2009 或 9/31/2009 等内容。 如果可以的话，尝试处理 1/1/1900 和 12/31/2038（您的图书馆可能不允许）。
您可以做的一件事是检查您正在进行的所有库调用的文档，找出在哪些条件下抛出什么异常，并故意尝试查找将触发这些异常的输入，然后确保您进行了测试验证这些异常是否已处理，或者在库代码的情况下是否已记录。
代码覆盖工具和代码突变还可以帮助您识别以前未覆盖的场景。
Sure, there's always more scenarios to consider. There's an effectively limitless pool of scenarios, frankly. It's an extremely open-ended question.
Regarding the malicious hacking scenarios, you should really only bother with obvious spots for buffer overflow and then stick to testing for confirmed security vulnerabilities, so that you don't accidentally reopen them. And anytime you do get a confirmed vulnerability, hunt down every place in the code that uses similar programming techniques and patterns, and preemptively test/fix those too. However, in a lot of cases, fuzzing will give you better results. Automated testing is an important part of dealing with security issues, but it should by no means be the primary tool in the toolbox.
Other things to consider are likely to be data specific. For example, when parsing dates, be sure to handle stuff like 2/29/2009 or 9/31/2009. If you can, try to handle 1/1/1900 and 12/31/2038 (your library may not let you).
One thing you can do is check the documentation for all the library calls you're making, figure out what exceptions are thrown under which conditions, and deliberately try to find inputs that will trigger those exceptions, and then make sure you've got tests that verify that those exceptions are either handled or, in the case of library code, documented.
Code coverage tools and code mutation can also help you to identify scenarios that weren't previously being covered.