动机

Test IO 代表着对测试员成长的支持。为确保你的测试生涯步入上升轨迹，我们决定与你分享我们的测试员在测试生涯初期常犯的最常见错误。即使经验丰富的测试员有时也会犯错，他们也会从中学到经验。

当你进行测试时，有时会很诱人尝试一切，甚至一些正常用户永远不会尝试的不寻常的步骤。当这种冲动发生时，在提交漏洞报告之前，请停下来。思考一下你的步骤是否符合正常用户行为，或者你发现的漏洞是否会对我们的客户有趣。请始终思考你的漏洞是否会影响正常用户的流程。

让我们看看一些我们为你收集的最常见错误示例。

测试使用无法访问的电子邮件订阅

通常我们的测试员希望证明电子邮件订阅或注册流程接受无效电子邮件。检查服务器是否接受无效电子邮件是完全可以的，也是对我们的客户非常有用的操作，但在进行此类操作之前，请确保你理解无效电子邮件与不存在电子邮件之间的区别。有人可能会说它是一回事，但实际上并不是。请阅读这篇文章以了解无效电子邮件是什么。

另一方面，不存在的电子邮件代表的是由你（或其他人）未创建的电子邮件，因此在系统中不存在。尝试验证不存在的电子邮件将极有可能不会引起服务器的任何反应，因为它将被认为是有效的，只要它遵循电子邮件结构模式。这种行为是可预期的，不被视为漏洞。

解决方案：

如果你使用商业电子邮件进行测试，必须使用现有的收件箱。这样，我们就不会向 Gmail、Outlook 或任何其他电子邮件提供商发送无效请求。
如果你想测试验证，你必须使用 qa.team 的电子邮件。由于所有有效的 qa.team 用户名都存在，测试员永远不会向不可接受的收件箱发送请求，因此他们只测试验证本身。
对于分级环境，应始终使用 qa.team 邮件进行常规注册（除非客户另有说明）。
对于无效电子邮件验证，使用文章中分享的示例或创建遵循相同路径的自己的组合。

报告与浏览器验证相关的漏洞

浏览器验证代表了浏览器基于输入元素内的属性进行的 HTML 输入验证。

以下是电子邮件输入的 HTML 5 浏览器验证的示例：

<input type="email" id="email" pattern=".+@test\.io" size="30" required>

如果你看到类似的东西，这意味着浏览器已实施验证，而验证不是由 JavaScript 完成的。

浏览器验证的一个常见示例是在表单字段中输入拼写错误的单词时显示红色波浪线。

报告此类漏洞不在 Test IO 执行的测试周期的范围内，此类漏洞将被拒绝。

解决方案：

当你想知道客户为特定环境（网站）实施了哪种输入验证时，请右键单击页面，然后单击“查看页面源代码”。如果你注意到 <input type="email"...> 代码，这意味着电子邮件字段由浏览器验证，你不应该在测试中报告此漏洞。

在测试指南中要求启用代理时没有启用代理

有时我们的测试员没有仔细阅读测试指南，这导致他们的漏洞被拒绝，甚至在最糟糕的情况下，可能会受到合规性团队的警告。最常见的错误之一是，当测试员要求使用代理时，测试员没有使用代理。我们进行了一些调查，以下是测试员遇到问题的原因：

在重复的测试中，测试员只阅读一次测试指南，当同一客户的同一产品的下一个测试出现时，测试员认为测试策略应该是相同的，阅读指南将浪费他们宝贵的时间。这就是他们犯错误的地方。测试的标题相同并不意味着访问测试环境的路径相同。

许多时候，我们的客户希望将测试员引发的流量与真实用户的流量分开。在这种情况下，我们使用代理。另一种情况是获得访问封锁给除持有适当通行证的人的分级环境：启用代理。如果测试员忘记启用代理，分级环境将显示 403 或 1020 错误。报告此类漏洞将触发因未遵循测试指南而被拒绝。

解决方案：

当你接受需要使用代理访问测试环境的测试周期时，你必须精确遵循测试指南，否则你找到的漏洞将不被认为是合法的。

将内容和视觉漏洞升级为功能漏洞，以使其符合测试范围

有时我们的测试员没有任何意图，就将所有内容和视觉漏洞升级为功能漏洞，因为他们没有经验来确定哪些漏洞应该升级为功能漏洞。结果，他们被拒绝。很多时候，这些拒绝是因为超出范围的原因，这意味着测试员的质量和排名会受到很大的影响。

解决方案：

专注于学习内容、视觉和功能漏洞之间的区别。要了解，如果内容和视觉漏洞不会影响产品的功能性或存在直观的解决方案，那么你就不应该提交功能漏洞。

在接受 Beta 测试周期之前，未更新设备操作系统

这种做法不仅被我们的新手测试员证实，而且也被经验丰富的测试员证实。通常情况下，这并不是有意的。我们的测试员每周参加许多测试，有时会忘记注册测试 Beta 操作系统版本。

解决方案：

犯错误是人之常情，但请确保始终阅读测试指南，因为它包含了关于所请求的设备和 Beta 操作系统的重要信息。
在需要 Beta 操作系统的情况下，你不应该使用官方版本来测试产品，而应该使用 Beta 版本。

在漏洞报告中选择错误的设备

有时，测试员希望在最快的时间内报告漏洞。当他们这样做时，有时会出错选择错误的设备。如果他们在团队领导检查他们的漏洞报告之前没有切换到正确的环境，好的漏洞可能会被拒绝。

解决方案:

在你点击"提交漏洞"之前，请确保你选择了正确的漏洞细节，如漏洞类型、严重性、设备和浏览器。如果你不小心选择了错误的设备或浏览器，只要没有其他人正确报告，你可以更正它，而且必须在团队领导检查你的漏洞报告之前更正。

在测试周期聊天中发送消息通知 TL 你已经按照漏洞报告中的 TL 请求进行了更改

在测试的早期阶段，我们的测试员收到多个信息请求，以改进他们的漏洞报告。在那段时间，测试员可能会感到不耐烦，想知道提交的结果如何。这是测试员大多数情况下陷入的陷阱，他们经常在漏洞报告中发送多个评论，甚至在测试周期聊天中发送消息，通知 TL 他们已经进行了更改。听起来很熟悉，对吧？我们都经历过这个，从错误中学到了经验。但我们希望你比那更聪明，向我们学习。

解决方案：

当你回答信息请求并提供 TL 请求的所有必要信息时，请克制自己，不要在漏洞报告中发送多个评论和在测试周期聊天中发送消息。TLs 将收到已完成的信息请求的通知，无需紧张或焦虑。所有的漏洞都会按时审核，因为我们的系统不允许关闭处于未审核状态的测试中的任何漏洞报告。

在录制漏洞时使用 Google 翻译翻译测试环境

现代技术的优势之一是你不需要掌握世界上所有语言才能测试外语环境中的产品。在测试期间使用第三方翻译工具，如 Google 翻译，是允许的，但请确保你发现的漏洞不是由于使用 Google 翻译引起的。有时，Google 翻译会破坏环境，导致测试员提交不存在的漏洞。在其他情况下，测试员提交的漏洞是存在的，但并不是由 Google 翻译引起的，但他们忘记在录制漏洞时关闭 Google 翻译。当发生这种情况时，漏洞将被 TL 拒绝，因为它不符合我们的标准。

解决方案：