容易被遗忘的测试用例

网络服务器启动了吗？应用程序服务器启动了吗？数据库上线了吗？测试数据是否预先加载到数据库中？每当我们准备开始测试应用程序时，一切都应该已经准备妥当。

 然而，当测试开始后，我们可能会漏掉一些测试用例，只有在发布期间对生产环境进行健全性测试时才会意识到这一点。在今天的文章中，我们将讨论开发团队经常忽视的一些常见领域：

• 数据库/内存数据库

• 访问令牌

• API 请求

• 其他杂项区域（即无连接）

话不多说，让我们看一下上面提到的每个领域的几个测试用例！

注意：本文中提到的内容均来自我们自己的经验，并不是全部用例。

数据库/内存数据库

测试案例 1：凭据无效

通常为每个应用程序完成一次数据库设置，其中将为不同的环境设置不同的凭据。设置完成后，凭据只会在 x 天后更改。当凭证发生更改时，团队可能会忘记在系统内手动更新（取决于数据库的设置方式），因为已经有一段时间了。因此，检查一下总是好的。此外，如果应用程序正在发布其第一个版本，则可能会从非生产环境复制凭据。因此，验证生产环境的凭据设置是否正确非常重要。

测试用例 2：未设置表

表的创建是手动或通过脚本完成的，有时可能会发生一些错误团队会漏掉。尽管这种情况很少见，但我们不想假设它总是成功且没有错误。

测试用例3：表中没有可用记录

这是一个被高度忽视的领域，因为每个人都认为数据肯定会在发布之前正确地预加载到数据库表中。由于这种假设，开发团队往往不进行检查/测试。此外，测试数据大多数时候都是预先加载到数据库中的，所以数据库中没有记录的可能性很小。

测试用例 4：过时的架构

架构可能会在测试期间更新，但有时可能会忘记部署到生产环境，特别是如果发布频率很短（例如每个发布 2-3 周）；每个版本中的架构并不总是发生变化。如果错误处理不当，应用程序可能会崩溃，从而给用户使用应用程序带来不便。

访问令牌

测试用例 5：访问令牌无效

必须在访问任何经过身份验证的 API 之前生成访问令牌。一旦能够访问 API，常常会对测试应用程序的功能过于兴奋，并且可能会错过对无效访问令牌场景的测试。应用程序中不允许注销或并发登录而撤销的令牌也属于无效访问令牌的情况。

测试用例 6：过期的访问令牌

访问令牌确实有过期时间，实际上有两种过期类型：由于闲置而过期和超过令牌生命周期而过期。如果笔记本电脑短暂闲置，你可能已经了解了当访问令牌的有效期很短时应用程序如何处理这种情况。

API请求

测试用例7：失败期间的常见响应代码

我们如此专注于功能测试（其中 API 请求将始终返回成功代码 200），以至于可能忘记测试 API 请求的其他常见响应代码，例如：

• 错误请求 (400)：无效请求

• 未经授权（401）：身份验证失败

• Forbidden (403)：身份验证成功但无权访问所请求的资源

• 未找到（404）：请求的资源不存在

• 内部服务器错误 (500)：服务器出现意外错误

• 服务不可用（503）：服务器尚未准备好处理任何请求

• 网关超时（504）：没有收到及时响应来完成请求

当测试上述测试用例时，需要确保应用程序有一个自定义页面来处理所有不同类型的错误。StackTrace 应始终对用户隐藏，以获得更好的用户体验。

其他

测试用例 8：服务中断

当数据库、后端服务器或其他下游服务宕机时，会给团队带来不便。因此，应该检查以确保所有连接始终处于正常状态。查看应用程序的架构图，看看是否有其他外部组件与应用程序交互。模拟内部/外部组件发生故障，以查看应用程序是否能够很好地处理它并在组件再次启动时正常恢复。

在进行此类测试用例的测试时，需要安排一个停电期来通知团队，以便团队了解测试环境的稳定性。如果无法进行中断期测试，还可以尝试其他环境（开发、UAT、登台、RC 等）或启动一个限时环境并在测试完成后将其拆除。

如果需要本文中上述测试用例的清单，可以参考下方列表~