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