在本文中，您将学习如何根据我们的规则和标准正确记录错误。为了理解一个错误，客户需要有足够信息且高质量的文档支持。本文的每个部分都会提供更详细的规则说明，但以下是我们错误报告要求的快速总结：
功能性错误报告：如果您报告的是功能性错误，必须在填写错误报告的其余内容之前选择一个可用的严重程度（Severity）。
标题（Title）：标题必须回答“发生了什么”、“错误发生在哪里”和“何时触发”的问题，反映真实问题，避免描述未发生的情况（重点描述实际发生的内容）。
URL：必须填写从浏览器复制的触发错误页面的链接。
重现步骤（Steps to Reproduce）：
第一步必须包含着陆页的 URL 或应用名称。
其他步骤应描述您为触发该问题所采取的操作，最后一步应为触发问题的最后操作（而不是“观察”）。
实际结果（Actual Result）：用一句或多句说明最后一步操作后发生的情况。如果前面的操作结果对于理解错误必不可少，也可以一并说明。实际结果不能与标题相同。
预期结果（Expected Result）：应说明在执行最后一步操作后应该发生的情况。不能只是实际结果的小改动，因为两个字段是用于不同目的的。
附件（Attachment）：如果报告需要附件，必须附上至少一个附件。
测试环境（Used Environment）和浏览器：必须根据您接受测试周期时被邀请使用的设备选择正确的测试环境和浏览器（如果适用）。
报告流程小技巧：
在填写错误报告表单时，第一步应选择正确的功能模块（Feature）。如果在下拉列表中找不到合适的功能模块，请返回测试概览页面，逐一阅读所有功能模块描述并标记为已读。之后返回错误报告表单，所有功能模块将会出现在下拉列表中。
错误报告表单
选择功能模块（Feature）后，整个错误报告表单将会显示给您。例如，功能性错误的表单如下所示：
您应根据我们的质量标准，在错误报告表单的每个字段中填写正确且具体的信息。有关每个字段及其要求的详细信息，请见下文。
严重性
仅适用于功能性缺陷，您将看到一个额外的字段称为严重性：低、高和/或关键。严重性指示您的报告的紧急程度，取决于多个因素。有关不同严重性级别的详细信息，请访问以下文章：功能性错误。
对于其他类型的缺陷，不会显示严重性字段。
标题
错误报告标题应总结问题，让阅读者仅通过标题就能对错误有一个总体了解，而无需阅读整个报告。标题应精确且简洁，同时包含以下信息：错误是什么？发生在何处？何时触发？因此，在撰写错误报告标题时，请始终记住：什么？哪里？什么时候？
在撰写标题时，应描述实际发生的情况，而不是没有发生的情况。标题中绝不能仅说明“某功能无法使用”，否则阅读者无法理解实际发生了什么。
标题必须反映真实问题。如果错误只在特定条件下出现，这些条件必须包含在标题中。例如，如果你在表明自己是青少年时无法预订票务，这就是重要信息，必须写入标题。
为了写出描述性标题，可以站在从未使用过该网站或应用的人角度思考——他们无法想象你所在的页面、页面的样子以及你进行了哪些操作。以他们的视角阅读你的标题，判断是否能够理解错误。如果无法清楚了解错误，请调整标题并重复该过程。
示例错误报告标题
错误示例：购物车页面显示错误
正确示例：从购物车页面点击“结账”按钮会跳转到“错误 500”页面
错误示例：用户无法将商品加入购物车
正确示例：在“蝙蝠侠 T 恤”页面，用户尝试将商品加入购物车时会收到“意外错误”提示
URL
访问出现错误的页面，并将浏览器地址栏中的 URL 复制粘贴到错误报告表单的 URL 字段中。
URL 必须是有效的链接。
复现步骤
错误必须是可重现的，并且需要提供详细的逐步操作指南来说明如何重现该错误。每一步都应描述一个独立的操作。
请注意，您无需手动为每个步骤编号，因为我们的系统会自动完成编号。
第一步必须包含指示，说明如果您在测试网站，应访问客户在“访问（Access）”部分提供的登陆页面 URL；如果您在测试移动应用，应打开该应用并注明其名称。后续步骤应描述从初始步骤到错误发生时的操作——您按了哪些按钮、点击了哪些链接、输入了哪些内容。最后一步必须描述触发错误的操作。请注意，“观察”并不是用户执行的操作。
您的步骤应尽可能通用。仅当错误发生在特定条件下（例如，只在特定的产品概览页、特定筛选条件或特定输入下出现）时，才在步骤中说明该条件。例如，如果问题在任何产品上都会发生，则步骤中无需描述您访问的具体产品概览页或添加到购物车的具体产品。这有助于读者快速理解错误的核心，而不会被无关细节分散注意力。
最后，请确保您的步骤包含最少量的操作。阅读每一步后，再现错误的人应能够在网站或应用上顺利完成操作，而不需要重复查看同一步骤以记住要做什么。
示例复现步骤
在右上角的搜索栏中输入任何搜索查询（例如“旧金山”）
单击“立即搜索”按钮
滚动并单击“按价格排序”
选择“按价格从高到低排序”选项
不好的示例复现步骤
观察
搜索 > 排序 > 从高到低
观察
上述示例有什么问题：第一步必须包含指示，即访问登陆页的URL，而不仅仅是URL本身。第三步不够详细，包含了太多操作。第二步和第四步是多余的，不必要的，不有助于理解缺陷。
实际结果
“实际结果”（Actual Result）是错误报告中最重要的字段之一，因为这里需要说明问题的具体表现，以及理解错误所需的所有细节。
在描述实际结果时，应尽可能详细地说明在按照您提供的逐步操作后实际发生了什么。尽量精确，不要过于笼统。例如，不要只说“在应用排序方法 X 后，产品顺序大体未变”，而是要具体说明哪些产品没有按正确顺序排列。
在此字段中，您可以添加与错误相关的任何信息，例如具体示例、额外条件、例外情况，或者其他重要操作的结果（如有必要）。唯一需要注意的是，要将信息结构化，以便读者能够理解您的思路和分析过程。
重要说明：“实际结果”（Actual Result）和“预期结果”（Expected Result）绝不能只是简单的相反描述。
“预期结果”描述的是在执行最后一步操作后应该发生的情况，而“实际结果”描述的是实际发生的情况，两者可能存在显著差异，因此必须分别准确描述。
同样，“实际结果”（Actual Result）绝不能与报告标题相同。标题只是对问题的概述，而实际结果应对问题进行详细描述，包括更多细节，例如场景信息、示例，以及在执行复现步骤时获得的结果。
示例 “实际结果”
错误示例：点击“结账（Checkout）”按钮后，购物车页面显示错误。
正确示例：用户尝试进入结账页面时，页面显示 “Error 500 - Internal Server Error - Sorry, something went wrong”。
错误示例：用户无法将商品添加到购物车，页面显示错误。
正确示例：在商品详情页（PDP）右上角显示 “Unexpected Error” 错误信息，商品未被添加到购物车。
预期结果
描述在执行您最后一步操作后，您预期会发生的情况。细节仍然是关键。请思考如果没有遇到该错误，正常情况下应该会发生什么——也就是说，一切都正常工作时的结果。
请注意，预期结果（Expected Result） 不能 只是对“实际结果（Actual Result）”稍作修改或加上否定词。它是一个独立的字段，用于说明在完成最后一步复现操作后，本应发生的所有正确行为和结果。
示例预期结果
错误示例：用户可以继续结账
正确示例：用户应被正确重定向到结账页面，在该页面他应能够添加运输和支付信息并完成下单。
错误示例：产品应添加到购物车
正确示例：产品“Batman T-Shirt”应成功添加到购物车。用户不应遇到“Error 505”等错误，并且应能够顺利结账购物车中的任何商品。
附件
了解您的缺陷所需的附件类型以及适用的规则，请访问以下文章：缺陷报告附件要求。
使用环境（Used Environment）
了解你在发现错误时使用的设备对我们和客户都很重要。
测试网站时：点击你使用的设备旁的浏览器图标。
测试移动应用时：选择你用于测试且已安装应用的设备。
你只能使用本节中列出的设备进行测试。此外，在提交错误报告时，你应仅选择一个设备或浏览器，并只上传与该设备/浏览器相关的附件。如果你能够在其他设备或浏览器上重现该错误，请在 实际结果（Actual Result） 中说明。
选择错误发生的正确环境是 必填操作。提交报告时，请确保选择了正确的环境。如果不小心选择了错误的环境，可以在提交后修改。在团队负责人（Team Leader）审核错误报告前，你可以通过更改环境选择来进行修正。如果错误报告中包含错误环境，TL 在审核时将会拒绝该报告。
如果你想使用未在个人资料可用设备列表中的设备进行测试，请通过 支持聊天（Support Chat） 向我们发送请求。只要该设备对客户相关，我们会将其添加到你的可用设备列表中。
注意：如果你从测试员个人资料中的设备列表中移除了原本被邀请使用的设备，你将无法再在该测试中提交报告。此时错误报告表单的 使用环境（Environment） 部分将为空，且表单无法提交。
一旦在接受测试邀请后删除了设备，该操作 无法撤销！
改进你的报告
提交报告后，你仍然可以编辑除了已选择的 错误类型（Bug Type） 之外的所有字段。你必须始终提交 完整且可供审核的错误报告，仅在出现小的拼写错误或想重新措辞以提高报告质量时使用 编辑（Edit） 功能。
请记住，不允许使用占位符（placeholders），因此 不要提交不完整的报告 然后再打算之后编辑。
如果您的错误只在特定输入下发生，请使用真实用户会使用的术语，避免在创建错误报告或附件时输入随机关键词。不良示例：在客户界面创建账户时使用用户名 “asdsdfkg_lajsdh”，这会让您的报告显得不专业。
如果您误提交了错误报告，可以删除它，但 前提是该报告尚未被团队负责人（Team Leader）审核。