带有 JSON 负载的 REST 服务的测试场景答案

【问题标题】：Test scenarios for REST services with JSON payload带有 JSON 负载的 REST 服务的测试场景
【发布时间】：2018-06-07 20:53:29
【问题描述】：

我正在寻找测试 REST 服务的指南/最佳实践。例如，如果我在 REST 请求中有以下 JSON 负载：

{
    "maxActiveBadges": "1",
    "photoUrl": "https://someurl/?employeeId=12345",
    "employeeId": "12345"
}

我进行测试的方式显然是测试快乐路径场景的第一选择，以确保我得到 200 响应代码。然后我可以涵盖许多负面情况：

输入字段缺失、输入字段拼写错误、输入字段格式不正确（例如字符串而不是 int）、无效 json 和超过字段输入长度。

我的问题是阴性测试的范围应该有多大？我是否应该合理地假设服务将通过在响应正文中返回适当的错误状态代码和消息来优雅地处理任何输入？

第二个问题 - 是否存在服务不应该接受的某些字符，例如\?<> 出于安全原因？

【问题讨论】：

【解决方案1】：

我是否应该合理地假设服务将通过在响应正文中返回适当的错误状态代码和消息来优雅地处理任何输入？

这取决于您使用的框架以及他们在手册中编写的内容。它还取决于您是否正确设置并正确指定了所有验证规则

我的问题是阴性测试的范围应该有多大？

它应该像您和您的团队认为值得的那样广泛。测试的目的是让你睡得更好。如果微服务是一项免费服务，可以返回指定时区的时间，作为宠物项目来学习新技术——如果用户传递错误的数据和服务崩溃，可能什么都不会发生。如果那是一个飞行控制系统，我会测试传递错误的参数是否不会杀死数百人

所以，事实上，你和你的团队是唯一能回答这个问题的人

通常在真实系统上，您使用一个公开其余端点的框架。测试其中一个端点以检查所有格式错误的输入（错误的 json、错误的方法等）只是为了检查框架的验证是否正确连接，然后您测试每个单个端点以检查特定于该端点的验证。具有参数化测试和请求构建器通常允许添加诸如单行测试之类的测试

第二个问题 - 是否存在服务不应该接受的某些字符，例如\?出于安全原因？

取决于。你将如何使用这些数据？如果它是一个用户密码，你肯定应该接受它——它是一个有效的密码，对吧？但如果它是一个电话号码，你要显示为纯 html，那么你应该使用一些白名单

【讨论】：