软件测试中的测试场景是什么（示例）
托马斯·汉密尔顿
⚡ 智能摘要
软件测试中的测试场景 它定义了所有可验证的功能，以确保全面覆盖应用程序在真实环境下的行为。它强调端到端验证、以用户为中心的测试设计，以及 trac能够与要求保持一致，以确保业务关键流程的验证。
什么是测试场景？
A 测试场景 是对待测功能的高级描述。它代表了一种可能的用户交互或系统行为，有时也称为测试条件。作为测试人员，您应该设身处地地站在最终用户的角度思考，找出被测应用程序 (AUT) 的实际应用场景和用例。
测试场景可以根据以下方面进行分类： 申请的哪个方面 他们的目的是进行验证。了解这些类型可以确保全面覆盖所有功能和用户交互。
测试场景类型
- 功能场景： 这些测试用于验证特定功能或模块（例如登录、注册或结账）是否符合要求。它们侧重于“应该做什么”这一方面。
- 非功能性场景： 这些评估的是系统的性能，而不是系统的功能——涵盖性能、可扩展性、可用性和可靠性。
- 安全场景： 这些指标评估应用程序保护用户数据和防止未经授权的访问或漏洞的能力。
- 用户界面（UI）场景： 这些措施确保视觉布局、导航和交互元素在不同的设备和屏幕尺寸上都能直观地运行。
- 端到端场景： 这些模拟真实世界的工作流程，验证多个模块能否无缝协作——例如，在电子商务应用程序中进行搜索、添加到购物车和完成付款。
场景测试和测试场景是一样的吗？
测试场景定义了要测试的内容， 场景测试 是一种复杂、端到端或 实际用户故事 通常情况下，测试会使用多种测试用例，而不是仅仅依赖于详尽的测试用例列表。其目的是在特定的、实际的工作流程下评估系统的性能。
让我们借助下面的视频来研究一下这个问题——
为什么要创建测试场景？
创建测试场景的原因如下：
- 创建测试场景有助于确保在测试过程中涵盖主要用例。
- 测试场景可由业务分析师、开发人员和客户等利益相关者审核和批准，以确保被测应用程序 (AUT) 得到全面测试。这可以确保软件在最常见的用例中都能正常运行。
- 它们可以作为快速确定测试工作量的工具，并据此为客户制定方案或组织人员。
- 它们有助于确定最重要的端到端交易或软件应用程序的实际用途。
- 为了研究程序的端到端功能，测试场景至关重要。
👉 免费注册实时软件测试项目
什么情况下不应该创建测试场景？
以下情况可能无法创建测试场景
- 当应用程序复杂或不稳定，或者项目时间太短而无法编写结构化文档时，应避免创建测试场景。
- 遵循敏捷方法论（如 Scrum、看板）的项目可能不会创建测试场景。
- 测试场景可能并非为新的错误修复而新创建，或者 迭代测试 如果它们已经在之前的测试周期中记录下来。在这种情况下，测试场景必须在之前的测试周期中已有详尽的文档记录。对于维护项目而言，这一点尤为重要。
如何编写测试场景
作为测试人员，您可以按照以下五个步骤创建测试场景 -
- 第四步阅读被测系统 (SUT) 的需求文档，例如业务需求规格说明书 (BRS)、软件需求规格说明书 (SRS) 和功能需求规格说明书 (FRS)。您还可以参考待测应用程序的用例、书籍、手册等。
- 第四步针对每一项需求，找出用户可能采取的操作和目标。确定需求的具体技术细节。查明系统可能被滥用的场景，并以黑客的思维方式评估用户。
- 第三步： 在阅读需求文档并进行尽职调查分析后，列出不同的测试场景，以验证软件的每个功能。
- 第三步： 列出所有可能的测试场景后， 可追溯性矩阵 创建的目的是验证每个需求都有相应的测试场景
- 第三步： 所创建的场景将由您的主管进行审查。 Later，它们也会受到项目中其他利益相关者的审查。
人工智能如何帮助实现测试场景自动化？
人工智能正在变革测试场景自动化，使其比传统脚本编写更智能、更快速、更具适应性。人工智能驱动的工具无需为每个测试手动编写脚本，即可根据用户故事、需求甚至历史数据自动生成测试场景。利用机器学习的平台会分析以往测试失败的模式，以预测高风险区域，并帮助……ping 测试人员专注于真正重要的事情。
人工智能驱动的自动化框架可以自我修复脚本——当用户界面发生变化时自动更新定位器，从而大幅减少维护时间。它们还可以与……集成 CI/CD 流水线， 确保持续测试和实时反馈。
例如，人工智能引擎可以模拟电子商务网站上的数千个用户路径，检测流程中的断点，甚至可以建议优化的测试覆盖范围。
创建测试场景的技巧
- 根据项目方法论，每个测试场景都应该与至少一个需求或用户故事相关联。
- 在创建可同时验证多个需求的测试场景之前，请确保您有一个可单独检查该需求的测试场景。
- 避免创建跨越多个需求的过于复杂的测试场景。
- 测试场景数量可能很多，全部运行成本很高。根据客户优先级，仅运行选定的测试场景。
给学生的提示： 测试场景描述要测试的内容；测试用例描述如何测试它。
示例 1：电子商务应用程序的测试场景
对于电子商务应用程序，一些测试场景如下
测试场景1： 检查登录功能
为了帮助您理解测试场景和 测试用例，此测试场景的具体测试用例将是
- 输入有效的电子邮件 ID 和密码时检查系统行为。
- 输入无效的电子邮件 ID 和有效的密码时检查系统行为。
- 输入有效的电子邮件 ID 和无效的密码时检查系统行为。
- 检查输入无效电子邮件 ID 和无效密码时的系统行为。
- 检查当电子邮件 ID 和密码留空并输入登录信息时的系统行为。
- 检查“忘记密码”是否按预期工作
- 检查输入有效/无效的电话号码和密码时的系统行为。
- 检查选中“保留我的签名”时的系统行为
显然，测试用例更加具体。
测试场景2： 检查搜索功能
测试场景3： 检查产品 Descript离子页
测试场景4： 检查付款功能
测试场景5： 查看订单历史记录
除了这 5 种情况之外，以下是所有其他情况的列表
- 检查回访客户的主页行为
- 检查类别/产品页面
- 查看客户服务/联系页面
- 查看每日特惠页面
示例 2：银行网站的测试场景
测试场景 1：检查登录和身份验证功能
测试场景 2：可以进行支票汇款
测试场景 3：可以查看支票账户报表
测试场景 4：可以创建支票定期存款/定期存款
等等…
测试场景模板
测试场景中常见的挑战和错误
创建有效的测试场景听起来很简单，但实际上往往会遇到很多陷阱。以下是测试人员面临的一些常见挑战和错误：
- 要求不明确： 模糊不清或不断变化的需求会导致方案不完整或不相关。
- 交叠ping 场景： 冗余的测试场景会浪费时间，并造成测试执行中的混乱。
- 忽略极端情况： 只关注常见路径会忽略关键缺陷。
- 优先级排序不当： 对所有场景一视同仁会延误高影响力功能的测试。
- 过度细节： 过于复杂的场景会使维护变得困难，并降低灵活性。
- 缺乏 Trac能力： 需求与场景之间缺乏联系会导致覆盖范围不足。
- 忽视自动化准备： 编写不适合自动化的场景会限制可扩展性。
