本教程解释了什么是测试场景，以及测试场景的重要性、实施、例子和模板：
任何可以测试的软件功能/特性都可以说是一个测试场景。 在编写任何测试方案时都要考虑最终用户的观点。
本教程将帮助你回答以下问题：为什么需要测试方案，何时编写测试方案，以及如何编写测试方案。
什么是测试场景？
考虑一个假想的情况： 有一个巨大的海洋。 你必须穿越海洋，从一个海滨到另一个海滨。 比如说、 从印度孟买海滨到斯里兰卡的科伦坡海滨。
你可以选择的旅行方式有：
(i) 航空公司： 乘飞机前往科伦坡
(ii) 水路：最好是乘船前往科伦坡
(iii) 铁路：乘坐火车前往斯里兰卡
现在是测试场景： 从孟买海滨到科伦坡海滨的旅行，是一种有待考验的功能。
测试场景包括：
- 乘飞机旅行、
- 乘坐水路旅行或
- 乘坐铁路旅行。
这些测试场景将有测试案例。
可以为上述测试场景编写的测试用例包括：
测试场景： 乘飞机旅行
测试用例可以包括如下情景：
- 飞行是按预定时间进行的。
- 航班不按预定时间飞行。
- 随后出现了紧急状况（大雨和风暴）。
以同样的方式，可以为其他剩余的场景编写一套单独的测试案例。
现在我们来谈谈技术测试方案。
任何可以测试的东西都是一个测试场景。 因此，我们可以说，任何被测试的软件功能都可以分为多个较小的功能，可以被称为 "测试场景"。
在向客户交付任何产品之前，需要对产品的质量进行鉴定和评估。 测试场景有助于评估软件应用程序的功能质量是否符合其业务要求。
测试员方案是一个过程，测试员从最终用户的角度测试软件应用程序。 在生产环境中实施之前，对软件应用程序的性能和质量进行全面评估。
测试方案的重要性
- 一个测试场景可以有多个 "测试用例"，它可以被理解为一个大的全景图，测试用例是完成全景图的重要的小部分。
- 它是一个单行声明，测试用例包括分步描述，以完成测试方案声明的目的。
- 例子：
测试场景： 为所使用的出租车服务付款。
这将有多个测试案例，如下所述：
(i) 使用的支付方式：PayPal、Paytm、信用卡/借记卡。
(二) 已完成的付款是成功的。
(三) 已完成的付款不成功。
(四) 付款过程在这中间中止了。
(v) 无法进入支付方式。
(六) 这中间的应用就中断了。
- 因此，测试场景有助于根据现实世界的情况来评估软件应用。
- 测试方案确定后，有助于将测试范围分化。
- 这种分叉被称为优先排序，有助于确定软件应用的重要功能。
- 对功能的优先测试，在很大程度上有助于软件应用的成功实施。
- 随着测试方案的优先化，最重要的功能可以很容易地被识别并优先测试。 这确保了大多数关键功能都能正常工作，与之相关的缺陷也被适当地捕捉和纠正。
- 测试场景决定了软件的业务流程流程，因此可以对应用程序进行端到端的测试。
测试方案和测试案例的区别
| 测试场景 | 测试案例 |
|---|---|
| 测试场景是一个概念。 | 测试用例是验证该概念的解决方案。 |
| 测试场景是一个高层次的功能。 | 测试用例是测试高水平功能的详细程序。 |
| 测试场景来自于需求/用户故事。 | 测试用例是由测试场景衍生出来的。 |
| 测试场景是 "要测试什么功能 | 测试用例是 "如何测试功能"。 |
| 测试场景有多个测试用例。 | 测试用例可能或不可能与多个测试情景相关联。 |
| 单一的测试场景是永远无法重复的。 | 一个测试案例可以在不同的场景中多次使用。 |
| 要求提供简要文件。 | 需要详细的文件。 |
| 为了最终确定测试方案，需要召开头脑风暴会议。 | 需要具备软件应用的详细技术知识 |
| 由于不需要细微的细节，所以节省了时间。 | 消耗时间，因为每一个微小的细节都需要照顾到。 |
| 由于所需的资源较少，维护成本很低。 | 维护成本很高，因为所需资源很高 |
为什么测试场景是必不可少的？
测试场景来自于需求或用户故事。
- 以出租车预订的测试场景为例。
- 场景可以是出租车预订选项、支付方式、GPS跟踪、路线图显示正确与否、出租车和司机的详细信息显示正确与否等，所有这些都列在测试场景模板中。
- 现在假设测试场景是检查位置服务是否打开，如果没有打开，显示 "打开位置服务 "的信息。 这个场景被遗漏了，没有列在测试场景模板中。
- 定位服务 "场景引起了与之相关的其他测试场景。
这些可以是：
- 定位服务呈灰色。
- 定位服务打开了，但没有互联网。
- 限制就地服务。
- 显示了错误的位置。
- 缺少一个场景 可能意味着错过了许多其他 关键场景或测试案例 这可以有一个很大的 负面影响 这导致了严重的资源损失（最后期限）。
- 测试场景在很大程度上有助于 避免详尽的测试 它确保所有关键和预期的业务流得到测试，这进一步帮助了应用程序的端到端测试。
- 这些都是节省时间的方法。 而且，不需要按照测试案例进行更详细的描述。 只需指定一个单行的描述，就可以测试什么。
- 测试方案是在下列情况下编写的 脑力激荡会议 因此，遗漏任何情况（关键或次要的）的可能性是最小的。 这样做是考虑到技术问题和软件应用的商业流程。
- 此外，测试方案可以由业务分析员客户或对被测应用有明确了解的双方来批准。
因此，测试方案是SDLC中不可缺少的一部分。
测试方案的实施
让我们看看测试方案的实现或如何编写测试方案：
- 形成了Epics/业务需求。
- 史诗的例子 ：创建一个Gmail帐户。Epic可以是一个应用程序的主要功能或业务要求。
- 史诗被划分为更小的用户故事，跨越冲刺阶段。
- 用户故事来自于Epics，这些用户故事必须有基线，并得到利益相关者的批准。
- 测试场景来自于用户故事或BRS（业务需求文件），SRS（系统需求规范文件），或FRS（功能需求文件），这些都是最终确定和基准化的。
- 测试人员编写测试方案。
- 这些测试方案由团队领导、业务分析师或项目经理批准，具体取决于组织。
- 每个测试场景必须与至少一个用户故事相联系。
- 必须确定积极的和消极的测试方案。
- 用户故事包括 验收标准如 :
- 验收标准是对客户需求的条件或意向状态的列表。 在编写验收标准时，要考虑客户的期望和误解。
- 这些对于一个用户故事来说是唯一的，每个用户故事必须至少有一个验收标准，应该是独立的可测试的。
- 验收标准有助于确定哪些功能在项目的范围内，哪些在项目的范围外。 这些标准应该包括功能性和非功能性的功能。
- 业务分析员编写验收标准，产品负责人批准。
- 或者在某些情况下，产品所有者可以自己编写标准。
- 测试方案可以从验收标准中获得。
测试场景示例
#1）Kindle应用程序的测试场景
Kindle是一款使电子阅读器能够在网上搜索电子书、下载和购买电子书的应用程序。 亚马逊Kindle为电子书阅读器提供了手握书本阅读的真实体验。 甚至翻页也在该应用程序中得到了很好的模拟。
现在，让我们记下测试方案。 ( 请注意： 下面列出了有限的场景，以获得编写测试场景的总体思路。 可以有多个测试用例，由它衍生出来）。
| 测试场景 # | 测试场景 |
|---|---|
| 1 | 验证Kindle应用程序是否正常启动。 |
| 2 | 在应用程序启动后，验证屏幕分辨率是否根据不同的设备进行调整。 |
| 3 | 验证显示的文本是否可读。 |
| 4 | 验证放大和缩小选项是否有效。 |
| 5 | 确认在Kindle应用程序中导入的兼容文件是可读的。 |
| 6 | 核实Kindle应用程序的存储容量。 |
| 7 | 验证下载功能是否正常工作。 |
| 8 | 验证翻页模拟是否正常工作 |
| 9 | 验证电子书格式与Kindle应用程序的兼容性。 |
| 10 | 验证Kindle应用程序所支持的字体。 |
| 11 | 核实Kindle应用所使用的电池寿命。 |
| 12 | 根据网络连接情况（Wi-Fi、3G或4G）验证Kindle的性能。 |
多个测试用例可以从上述的每个测试场景中衍生出来。
#2）谷歌文件的验收标准
Google docs "是一个基于网络的应用程序，用于创建、编辑和分享word文档、电子表格、幻灯片和表格。 所有文件都可以使用具有互联网连接的网络浏览器在线访问。
创建的文件可以以网页或打印文件的形式共享。 用户可以对谁可以查看和编辑文件设置限制。 一份文件可以由来自不同地理位置的不同人员协作共享和处理。
下面提到了有限的测试场景，供大家了解。 谷歌文档的深入测试方案可以完全是一个单独的话题。
| 验收标准 # | 验收标准 |
|---|---|
| 1 | Word、表单或表格可以成功打开，没有错误。 |
| 2 | 文件、工作表和幻灯片都有模板。 |
| 3 | 现有的模板可供用户使用。 |
| 4 | 使用的模板是可编辑的（例如：字体、字体大小、添加文本、删除文本、插入幻灯片）。 |
| 5 | 如果互联网连接暂时不可用，文件可以存储在本地，并在有互联网连接的情况下上传。 |
| 6 | 多个用户所做的修改不会被重复写入。 |
| 7 | 多个用户可以在单个文件上工作。 |
| 8 | 如果在上传文件时失去互联网连接，已完成的工作将被储存。 |
| 9 | 共享限制被正确应用。 |
| 10 | 查看限制的用户不能对文件进行任何编辑。 |
| 11 | 文件可以在互联网上公布，供公众查阅。 |
| 12 | 对文件所做的修改会被保存，并带有时间戳和作者的详细资料。 |
在这种情况下，通常只有验收标准被设定并被利益相关者批准，团队成员在这些验收标准上工作。 对于庞大的应用程序来说，编写测试用例或者说测试方案可能是一项详尽的任务。
这些验收标准在迭代过程的规划中起着重要作用，绝对不能忽视。 事先定义这些标准，可以避免在冲刺或发布结束时出现意外或冲击。
鉴于 一个先决条件。
当 来做一个动作。
那么 结果是预期的。
Given、When和Then的格式对指定接受标准很有帮助。
测试方案模板的例子
| 使用故事ID # | 测试方案ID # | 版本 # | 测试场景 | # 测试案例的数量 | 重要性 |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | 验证Kindle应用程序是否正常启动。 | 4 | 高 |
| USID12.1 | TSID12.1.2 | Kin12.4 | 核实Kindle应用程序的存储容量。 | 3 | 中型 |
总结
在任何软件测试中，对生命周期的理解和奠定测试场景是一个非常重要的因素。 通过为测试场景打下良好的基础，可以提高软件的质量。 通常，测试用例和测试场景的使用可能会被替换。
然而，经验法则是，测试场景用于编写多个测试用例，或者我们可以说测试用例来自于测试场景。 定义明确的测试场景确保了良好的软件质量。