如何定义核心场景用例？

​首先我们解决两个问题：

1. 1.什么是场景测试？

2. 2.什么是核心场景？

1、什么是场景测试？

🎯 1.1：什么是场景

事件触发时的情景形成了场景。场景必不可少的几个要素：环境、人、时间、行为。简而言之：xx人在xx时间xx环境下进行了xx行为。划分场景的意义在于：我们想通过场景知道“人”“行为”的目的是什么。

🎯 1.2：什么是测试场景

测试场景是指模拟真实环境下的一系列测试活动，以观察系统在这种环境下的表现。注意：模拟真实环境。我们所有测试行为都应该是有意义的，而不应该是想当然的。

1.【从需求的角度来说，测试场景通常是可以从需求描述中获得到的】

用户故事（user story）在软件开发过程中被作为描述需求的一种表达形式，并着重描述角色（谁要用这个功能）、功能（需要完成什么样子的功能）和价值（为什么需要这个功能，这个功能带来什么样的价值）。简单理解，即：xx人想用xx功能实现xx价值。

以目前我们特性模板为例（如下图所示），其实是涵盖了用户故事想要表述的几个元素。所以，如果产品同学认真写的话，我们是能够获取到我们要的信息的。

值得注意的是：从需求描述获取测试场景，可以预见的是，我们会强依赖产品的需求拆分粒度、需求描述清晰度。所以，因为需求拆分粒度不同，我们的测试场景也会有大小（不要恐惧，这是正常的。没有谁规定一定要是一个大的场景，难道小舞台就不能表演了吗？）再者，如果只是一句话需求怎么办（这是大部分情况）？还能怎么办？多交流呗。

2.【从测试分层的角度来说，测试场景通常是由小到大、由简到复的】

测试分层的定义和意义毋庸赘述。在不同层级测试，我们应该有不同粒度的测试场景。比如：单元测试，我们测试场景大多着眼于单功能交付；集成测试，则关注于模块交互；验收测试，则强调系统功能的完善。

可以试想一个汽车生产商，生产汽车的过程。是不是先零部件（轮胎、方向盘）生成，然后再是局部功能组合调式（引擎、仪表盘），最后才是整车交付？大致如此道理。

3.【从交付的角度来说，对内交付和对外交付的测试场景不同】

对内交付（可以是团队内、项目内），关注的更多是单功能和交互功能场景测试；对外交付（项目外），更关注的是系统场景测试。

所以，又回到了“你的用户是谁”的话题，仔细思考？

2、什么是核心场景测试？

了解了什么是场景和测试场景，现在我们来定义什么是核心测试场景。

定义核心测试测试场景是确保软件系统的关键功能得到充分测试的关键步骤。这些场景通常涉及到系统的核心功能、最重要的用户操作流程以及最关键的使用情景。

请注意：“核心”、“重要”、“关键”。

以下是定义核心测试场景的一些步骤：

1.【识别关键功能】

确定系统中的关键功能，这些功能对于系统的整体运作和用户体验至关重要。这可能涉及到核心业务逻辑、主要用户流程和最常用的功能。

2.【确定用户故事】

将关键功能转化为用户故事或使用情景。每个用户故事描述一个用户的目标、操作和预期结果。这有助于将功能放置在真实使用环境中，以便更好地理解其重要性。

3.【优先级排序】

对识别的关键功能和用户故事进行优先级排序。确定哪些功能是绝对必须测试的，以确保系统的核心方面能够正常工作。

有了以上几点，我们可以定义测试场景。然后，根据优先级，为每个关键功能或用户故事定义一个或多个测试场景。每个场景描述用户如何与系统交互，以及系统应该如何响应。

3、实际上如何操作？

建议1.【核心测试场景一定是覆盖关键功能的场景】

这点不用多说，意义很明显。

建议2.【核心测试场景最好是能覆盖功能更多的场景】

这样的话，场景测试可以覆盖的功能点更多。

建议3.【核心测试场景一定是用户关注的场景】

举个例子来说，思考一下，我们常做的单功能测试、单接口测试，用户关注不？

建议4.【实在不能确定，那就启动评审吧（三个臭皮匠敌过一个诸葛亮）】

列出测试场景，然后优先级排序，筛选出高优先级场景作为核心测试场景。可以使用如下表格列举、筛选。

4、总 结

了解了什么是场景和测试场景，现在我们来定义什么是核心测试场景。

本文是目的在于启发大家对“核心场景用例”的理解，帮助大家在测试工作中更好地区分和提取核心用例。希望对阅读的你有所帮助~

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：【文末小卡片领取】

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！