可用性测试，因为虽然 QA 可能会在此过程中提供帮助，但实际的测试参与者可能不是 QA 人员。

对最简单的功能进行基本的探索性测试。

历史使用示例倾向于将人们推向“总是坏的”或“总是有效的”的方向。最糟糕的事情是也不检查，看看他们现在是否有效。

我认为这个问题非常广泛，取决于您正在测试哪种应用程序/软件。但是，如果您正在测试一个 gui 应用程序，您可能会忘记的一件常见事情是可用性和那些烦人的语法/拼写错误。但这又取决于您要测试的内容以及您愿意走多远。

负面测试虽然不会被遗忘，但在时间紧迫时会被遗忘。例如，假设消息响应具有一组有限的有效数值（1、2、3、4）。如果发送的响应超出了该数字范围（6、10、0、-1）怎么办？如果发回的数据类型不匹配（1.5、0.2、“蓝色”、BLOB）怎么办？如果返回的响应为空或 null 怎么办？尤其是在使用对普通用户开放的应用程序（就像许多 Web 应用程序一样）时，最终用户培训的问题总是缺失，因此最终用户可能会输入意外的值。

很多时候，我从开发人员那里得到的响应是“没有用户会这样做”，只是在发布该功能后，用户会精确地执行该操作，并导致应用程序出现重大问题。