漏洞是与软件相关的问题。如果网站或应用程序上的某些功能未按预期工作，这个“错误”就是一个漏洞。在这里，我们区分以下漏洞类型：
功能性漏洞
功能性漏洞与软件功能有关，例如按钮不提交表单，搜索不响应用户输入，应用程序崩溃等。每当执行操作时，网站/应用程序未按预期响应时，可能存在功能性问题。
如何确定应用程序行为是否是功能性漏洞：
尝试弄清楚某个功能是否是特定方式设计的，或者实际上是否出现了问题。将其与其他功能单独测试并结合起来，以发现潜在差异。
考虑客户可能的意图，并考虑产品可能只是按照其实施方式工作。
找到证据表明某些内容不按预期工作，并支持您的主张。
示例：网店功能与您了解的其他网店不同。这并不意味着功能出现问题。客户可以按照他们的方式实施产品。
示例：如果您声称某个表单字段未经验证，并且这是一个漏洞，请确保存在该字段预期应验证的任何迹象。您可以通过显示在某些情况下验证该字段但在其他情况下不验证来提供这些证据。如果您没有提供任何证据，那就是未经证实的主张。
当视觉或内容问题妨碍功能时，它就变成了功能性问题，因此应报告为功能性漏洞。
如果某个功能在不同情况下一直以相同方式工作且没有明显问题，那可能是有意设计的（不是漏洞）。
严重性评估
功能性漏洞的适当严重性级别取决于多个因素：问题对功能的影响，问题的程度，是否存在解决方法或是否是阻碍性问题，是否存在潜在和显著的销售损失，以及是否可以将此漏洞与其他同等严重性的漏洞进行比较。因此，在test IO，我们区分三个功能性漏洞的严重性级别：
低：
对产品使用的影响较小。
产品显示意外行为，但一般使用不受影响。
受影响的用户、产品或项目较少。
某个功能/功能坏了或不可用，但容易找到解决方法。
高：
对产品使用的影响严重，但主要功能完好。
受影响的用户、产品或项目众多。
非常重要的功能坏了或不可用，没有解决方法。
重要功能坏了或不可用，但有解决方法（因此不是阻碍性问题）。
关键：
漏洞阻止了应用程序/网站的核心功能。
阻止用户继续主要流程，例如结账。
漏洞可能导致客户潜在且显著的销售损失。
我们已准备了基于常见评估的严重性级别的案例清单：带我去漏洞评估表！请仔细查看此列表，并定期检查以获取未来更新。
内容漏洞
内容漏洞涉及到网站或应用程序的实际内容：文本、标签、图片、视频、图标、链接、数据等。因此，典型的内容漏洞包括：
破损链接或图片（404）（除非位于导航菜单、标题、页脚或面包屑导航中，这些属于低功能性漏洞）
通用的缺陷重定向
丢失的文本，例如空工具提示中的文本
丢失的内容，例如空内容区域
丢失的内容，例如5个图标中有1个没有工具提示
丢失的翻译，例如某个英文网站上的某些按钮具有法语标签
一些产品在搜索结果中丢失，但搜索功能本身正常
丢失的数据
请注意，拼写错误不被视为内容漏洞，不能作为内容漏洞提交。
视觉漏洞
视觉漏洞涉及到网站或应用程序的图形用户界面，例如：
布局框架问题，如文本/元素不对齐
响应式设计问题，例如在一个移动设备上显示一个元素，但在另一个设备上不显示
文本/元素无意重叠
文本/元素被截断
将内容或视觉漏洞升级为功能性漏洞
一旦内容或视觉漏洞妨碍了功能，即使实际上功能本身并没有出现问题，也应将其报告为功能性漏洞。内容漏洞应报告为功能性漏洞的重要情况是当它出现在产品的功能组件中时，即导航菜单、标题、页脚或面包屑导航中的链接问题。这些问题通常是低功能性
重复性问题
将内容或视觉缺陷升级为功能性缺陷
一旦内容或视觉缺陷妨碍了功能，即使实际上功能本身并没有问题，也应将其报告为功能性缺陷。
一个内容缺陷应该报告为功能性缺陷的一个重要情况是当它出现在产品的功能性组件中，即导航菜单、页眉、页脚或面包屑导航中的链接问题。这些问题通常属于低功能性缺陷。
重复性问题
当内容或视觉问题重复出现时，只需提交一次报告，即使每次出现都有不同的URL、链接、图片等。这也适用于出现在同一页或不同页的情况。这个单一的缺陷报告应明确说明其他URL、链接、图片等也受到了影响。
不应该为问题的每次出现提交单独的缺陷报告，否则将被拒绝。例如，以下内容问题只需提交一个报告：某些网店多个商品详细页面上的某些产品图片破损，多个商品详细页面上的某些PDF手册下载链接导致404错误，某些商品描述与网店其余部分使用不同的语言，某些工具提示不包含任何信息，属于同一组的某些链接是破损的等等。
以下视觉问题只需提交一次：某些文本或图像大于它们的框，多个输入字段不足以容纳它们的默认文本，多个悬浮提示无意重叠其他元素等。
有关每种缺陷类型的更详细信息以及它们在test IO平台上的文档，请访问以下文章：