测试场景 测试文档 测试用例 测试场景（Test Scenario） 测试场景是测试用例的详细文档，涵盖了线性语句中软件应用程序的端到端功能。班轮语句被视为一个场景。测试场景是可测试需求的高级分类。这些需求根据模块的功能进行分组，并从用例中获得。 在测试场景中，由于相关的测试用例很多，所以有一个详细的测试过程。在执行测试场景之前，测试人员必须考虑每个场景的测试用例。 在测试场景中，测试人员需要将自己置于用户的位置，因为他们在用户的角度下测试软件应用程序。场景准备是最关键的部分，需要向客户、利益相关者或开发人员寻求建议或帮助来准备场景。 笔记： 测试场景永远不能用于文本执行过程，因为它不包含导航步骤和输入。 这些是讨论使用应用程序的所有可能组合或多种方式或组合的高级文档，测试场景的主要目的是了解应用程序的整体流程。 如何编写测试场景 作为测试人员，请按照以下步骤创建测试场景- 阅读被测软件的BRS（业务需求规范）、SRS（系统需求规范）、FRS（功能需求规范）等需求文档。 确定每个要求的所有技术方面和目标。 找出用户操作软件的所有可能方式。 确定由于哪个系统可能被滥用而导致的所有可能场景，并检测可能成为黑客的用户。 在阅读需求文档并完成预定分析后，列出各种测试场景以验证软件的每个功能。 列出所有可能的测试场景后，创建一个可追溯性矩阵，以确定每个需求是否都有相应的测试场景。 项目主管审查所有场景。之后，项目的其他利益相关者会对它们进行评估。 测试场景特点 测试场景是指导测试人员进行测试序列的线性语句。 测试场景降低了产品的复杂性和重复性。 测试场景意味着详细讨论和思考测试，但将它们写在线性语句中。 它是一个操作线程。 当测试人员没有足够的时间编写测试用例，并且团队成员同意详细的线性场景时，测试场景变得更加重要。 测试场景是一种节省时间的活动。 由于测试场景的添加和修改简单且独立，因此易于维护。 笔记： 我们在编写测试场景时必须遵循一些规则： 始终列出用户最常用的功能和模块。 我们总是通过逐个模块选择模块来开始场景，以便遵循正确的顺序，并且我们不会错过任何模块级别。 通常，场景是模块级别的。 删除场景应该始终是最后的选择，否则我们将浪费大量时间再次创建数据。 它应该用简单的语言编写。 每个场景都应该写在一行或最多两行，而不是在段落中。 每个场景都应该包含 Dos 和检查。 测试场景示例 这里我们以Gmail 应用程序为例，针对最常用的不同模块（例如登录、撰写、收件箱和垃圾箱）编写测试场景 登录模块上的测试场景 输入有效的登录详细信息（用户名、密码），并检查主页是否显示。 输入无效的用户名和密码并检查主页。 将用户名和密码留空，并检查显示的错误消息。 输入有效的登录名，然后单击取消，并检查重置的字段。 输入无效登录，超过3次，并检查该帐户被阻止。 输入有效的登录名，并检查用户名是否显示在主屏幕上。 Compose 模块上的测试场景 检查所有用户是否可以在To、Cc 和 Bcc 中输入电子邮件 ID 。 检查整个用户是否可以在“收件人”、“抄送”和“密件抄送”中输入各种电子邮件 ID。 撰写邮件、发送邮件并检查确认消息。 撰写邮件，发送，并检查发件人的已发送项目和收件箱。 撰写邮件，发送邮件，并检查无效和有效的电子邮件 ID（有效格式），检查发件人收件箱中的邮件。 撰写主要，丢弃，然后检查确认消息和签入草稿。 撰写邮件点击另存为草稿并检查确认消息 撰写邮件点击关闭并检查确认保存为草稿。 收件箱模块上的测试场景 单击收件箱，并确认所有收到的邮件都显示并突出显示在收件箱中。 检查最近收到的邮件是否已正确显示到发件人电子邮件 ID。 选择邮件，回复转发发送；检查发件人的已发送项目和收件人的收件箱。 检查已下载或未下载的邮件附件。 下载前检查附件是否已正确扫描任何病毒。 选择邮件，回复并转发另存为草稿，并在草稿部分检查确认消息和检查。 检查所有标记为已读的电子邮件都没有突出显示。 检查抄送中的所有邮件收件人是否对所有用户可见。 检查密件抄送中的所有电子邮件收件人对用户不可见。 选择邮件，删除它，然后检查垃圾箱部分。 Trash 模块上的测试场景 打开垃圾箱，检查所有已删除的邮件。 从垃圾箱中恢复邮件；签入相应的模块。 从垃圾箱中选择邮件，将其删除，检查邮件将被永久删除。 测试文档 测试用例
