在此页面上：了解如何在发布之前验证您的历程，方法是：使用模拟用户或使用测试用户档案的模拟模式及早发现错误。
不确定测试模式是否适合您？ 比较所有三个验证选项。
构建历程后，您可以在发布之前对其进行测试。 Adobe Journey Optimizer提供“测试模式”，以便在测试配置文件在历程中移动时查看测试配置文件，并在激活之前检测潜在错误。 通过运行快速测试，您可以检查历程是否正确运行，以便您能够放心地发布它们。
只有测试轮廓才能进入处于测试模式的历程。 您可以创建新的测试用户档案，也可以将现有用户档案转换为测试用户档案。 在本节中了解有关测试配置文件的更多信息。
历程优化器提供了两种方法来测试和验证您的历程：
-
模拟：将历程设置为模拟，并使用模拟用户（您在Adobe Experience Platform中创建或生成的临时配置文件，但不预先创建配置文件）。
-
测试模式：在Adobe Experience Platform中显式标记为测试配置文件的持久性配置文件。 它们可以在多个测试会话中重复使用。 建议使用此方法来测试一致且预定义的配置文件数据。 了解如何创建测试用户档案。
重要说明 important_notes
在历程中运行测试之前，请查看这些注释。
一般限制
- 仅测试配置文件 — 只有在Real-time Customer Profile Service中标记为“测试配置文件”的个人才能进入测试模式的历程。 了解如何创建测试用户档案。
- 命名空间要求 — 测试模式仅适用于使用命名空间的草稿历程。 测试模式需要检查进入历程的人员是否为测试用户档案，因此必须能够访问Adobe Experience Platform。
- 配置文件限制 — 在单个测试会话期间，最多可以有100个测试配置文件进入历程。
- 事件触发 — 只能从接口触发事件。 无法使用API从外部系统触发事件。
- 自定义上传受众 -历程测试模式不支持自定义上传受众属性扩充。
测试期间和测试后的行为
- 禁用测试模式 — 禁用测试模式时，将删除历程中当前或之前输入的所有配置文件，并清除报告。
- 重新激活的灵活性 — 您可以根据需要多次启用和禁用测试模式。
- 自动停用 — 在测试模式下保持非活动状态超过一周 的历程 会自动退出测试模式并返回草稿状态。 无历程内容丢失；仅测试模式会话结束。
- 编辑和发布 — 当测试模式处于活动状态时，您无法修改历程。 但是，您可以直接发布历程，之前无需停用测试模式。
- 消息投放 — 在测试模式下，使用与生产相同的投放管道将消息发送到测试用户档案的实际收件箱。 这与历程练习不同，后者模拟旅程执行，而不传递消息或触发真正的渠道操作。 这两种方法都不会复制实时发送的每个方面；请使用暂存环境进行完整的端到端验证。
执行
- 拆分行为 — 当历程达到拆分时，在测试模式下将始终选择顶部分支。 这不会反映在实时执行期间统计上选择的路径。 如果您希望测试其他路径，请重新排序分支。
- 事件计时 — 如果历程包含多个事件，则按顺序触发每个事件。 太早（第一个等待节点完成之前）或太晚（在配置的超时之后）发送事件将放弃该事件。 然后，该配置文件将发送到超时路径。 通过在定义的窗口中发送有效负载，始终确认对事件有效负载字段的任何引用保持有效。
- 活动日期窗口 — 确保历程配置的开始和结束日期/时间窗口包括启动测试模式时的当前时间。 否则，触发的测试事件将随日志消息
DISPATCHER DISCARD #16 — unqualified on journey version enablements一起被静默放弃。 要在测试期间解决此问题，请暂时将历程开始日期设置为当前时间之前的时间，然后在发布之前恢复该日期。 在此页面🔗上了解有关此问题疑难解答的更多信息。 - 反应事件 — 对于具有超时的反应事件，最小和默认等待时间为40秒。
- 测试数据集 — 在测试模式下触发的事件存储在专用数据集中，标记如下：
JOtestmode - <schema of your event> - 共享基础架构 — 测试模式在与生产相同的基础架构上运行。 在高流量期间，您可能会注意到电子邮件发送或事件处理出现延迟。 在这种情况下，请检查平台流量仪表板或在非高峰时间重试测试。
激活测试模式
当您想要使用已在Adobe Experience Platform中创建的预先存在的测试配置文件测试您的历程时，请使用 测试模式 方法。
-
要激活测试模式，请单击 模拟 按钮，然后选择测试模式。
历程界面中的
-
如果历程至少有一个 等待 活动，请设置 等待时间 参数以定义每个等待活动和事件超时在测试模式下的停留时间。 等待和事件超时的默认时间为10秒。 这将确保您快速获得测试结果。
note NOTE 当在历程中使用具有超时的反应事件时，等待时间的默认值和最小值为40秒。 请参阅此小节。 -
使用 触发事件 按钮配置事件并将其发送到历程。
-
配置所需的不同字段。 在 配置文件标识符 字段中，输入用于标识测试配置文件的字段的值。 例如，它可以是电子邮件地址。 确保发送与测试用户档案相关的事件。 请参阅此小节。
-
收到事件后，单击 显示日志 按钮查看测试结果并进行验证。 请参阅此小节。
-
如果有任何错误，请取消激活测试模式，修改历程并再次进行测试。 完成测试后，即可发布旅程。 请参阅此页。
工作示例：验证简单历程 test-walkthrough
以下示例逐步演示了测试历程，该历程以单一事件开始，发送电子邮件，等待10分钟，然后发送推送通知。
验证端到端历程：
-
单击右上角的 测试模式 激活测试模式。 画布切换到测试模式，并出现 触发事件 按钮。
-
将 等待时间 设置为10秒，以便在测试期间快速完成等待节点。
-
单击触发事件，选择您的事件，然后输入测试配置文件标识符（例如，在Adobe Experience Platform中标记为测试配置文件的配置文件的电子邮件地址）。
-
单击发送。 可视流量会显示在画布上，并在用户档案执行每个步骤时变为绿色。
-
单击 显示日志 并在JSON输出中确认以下内容：
currentstep与您期望的配置文件所在的活动匹配。- 当配置文件处于等待节点时，
phase显示running，当配置文件到达结尾时，显示finished。 - 不存在
actionExecutionErrors条目。
-
10秒后，刷新日志。 配置文件应已超过等待节点并触发推送操作。
-
当所有步骤显示
finished且未记录任何错误时，停用测试模式并发布历程。
- 您输入的配置文件标识符在Adobe Experience Platform中被标记为测试配置文件。
- 历程的配置开始和结束日期包括当前时间。 在此窗口之外触发的事件将被静默丢弃。 了解详情。
测试模式疑难解答 troubleshoot-test-mode
在打开支持票证之前，使用此表可以自行诊断常见测试模式故障。
@{<EventName>.identityMap.entry('<NamespaceName>').first().id}。 <NamespaceName>必须与事件架构完全匹配（区分大小写）。 请参阅先决条件。DISPATCHER DISCARD #16 — unqualified on journey version enablements触发您的事件 firing_events
使用 触发事件 按钮配置将促使人员进入历程的事件。
先决条件 trigger-events-prerequisites
作为先决条件，您必须知道哪些配置文件在Adobe Experience Platform中被标记为测试配置文件。 事实上，测试模式仅在历程中允许这些用户档案。
事件必须包含ID。 预期ID取决于事件配置。 例如，它可以是ECID或电子邮件地址。 需要将此键的值添加到 配置文件标识符 字段中。
配置文件标识符值必须与事件架构中存储的标识完全匹配。 用于引用事件有效负载中的标识的格式为：
@{<EventName>.identityMap.entry('<NamespaceName>').first().id}
将<NamespaceName>替换为事件架构中定义的完全相同的命名空间（例如，Email或Phone）。 命名空间不匹配会导致静默式下降：事件被接受并返回成功响应，但配置文件从未进入历程，并且UI中未显示任何错误。 如果触发事件后配置文件未出现在测试日志中，请验证 配置文件标识符 中的命名空间是否与事件架构命名空间完全匹配。
如果您的历程无法启用测试模式并出现错误ERR_MODEL_RULES_16，请确保使用的事件在使用渠道操作时包含标识命名空间。
身份命名空间用于唯一标识测试配置文件。 例如，如果电子邮件用于识别测试用户档案，则应选择身份命名空间Email。 如果唯一标识符是电话号码，则应选择身份命名空间电话。
-
在测试模式下触发事件时，会生成一个实际事件，这意味着该事件还会点击侦听此事件的其他历程。
-
请确保在测试模式下每个事件均按正确顺序在配置的等待窗口内触发。 例如，如果等待60秒，则必须仅在该60秒等待过后、超时限制过期之前触发第二个事件。
事件配置 trigger-events-configuration
如果您的历程包含多个事件，请使用下拉列表选择一个事件。 然后，对于每个事件，配置传递的字段和事件发送的执行。 界面可帮助您在事件有效载荷中传递正确的信息并确保信息类型正确无误。 测试模式会保存测试会话中使用的最后一个参数以供将来使用。
利用接口，可传递简单的事件参数。 如果要在事件中传递集合或其他高级对象，则可以选择 代码视图 以查看有效负载的整个代码并对其进行修改。 例如，您可以复制并粘贴技术用户准备的事件信息。
用于高级配置的
技术用户还可以使用此界面来撰写事件负载和触发事件，而无需使用第三方工具。
单击 发送 按钮时，测试开始。 个人在历程中的进度由视觉流表示。 当个人在历程中移动时，路径将逐渐变为绿色。 如果发生错误，则会在相应的步骤上显示警告符号。 您可以将光标放在错误上以显示有关错误的更多信息，并访问完整的详细信息（如果可用）。
当您在事件配置屏幕中选择不同的测试用户档案并再次运行测试时，可视流将被清除并显示新用户的路径。
在测试中打开历程时，显示的路径对应于上次执行的测试。
基于规则的历程的测试模式 test-rule-based
测试模式也可用于使用基于规则的事件的历程。 有关基于规则的事件的详细信息，请参阅此页面。
触发事件时，事件配置屏幕允许您定义要在测试中传递的事件参数。 您可以单击右上角的工具提示图标来查看事件ID条件。 作为规则评估一部分的每个字段旁边还提供了工具提示。
业务事件的测试模式 test-business
使用商业事件时，请使用测试模式在历程中触发单个测试配置文件入口，模拟该事件并传递正确的配置文件ID。 您必须传递事件参数和将进入测试历程的测试用户档案的标识符。 在测试模式下，对于基于业务事件的历程，没有“代码视图”模式可用。
请注意，首次触发业务事件时，不能在同一测试会话中更改业务事件定义。 您只能让同一个人或不同人通过相同或其他标识符进入历程。 如果要更改业务事件参数，则必须停止并重新启动测试模式。
查看日志 viewing_logs
使用 显示日志 按钮可以查看测试结果。 此页面以JSON格式显示历程的当前信息。 使用按钮可复制整个节点。 您需要手动刷新页面以更新历程的测试结果。
将显示历程中当前存在的个人（技术上称为实例）的数量。 将显示每个人的以下信息：
- Id：历程中个人的内部ID。 这可用于调试目的。
- currentstep：个人在历程中的步骤。 我们建议向您的活动添加标签以更轻松地对其进行识别。
- currentstep >阶段：个人历程的状态（正在运行、已完成、出错或超时）。 有关详细信息，请参阅下文。
- currentstep > extraInfo：错误的描述和其他上下文信息。
- currentstep > fetchErrors：有关在此步骤中发生的数据错误的获取信息。
- externalKeys：事件中定义的键公式的值。
- 扩充数据：如果历程使用数据源，则历程已检索的数据。
- transitionHistory：个人执行的步骤列表。 对于事件，将显示有效负载。
- actionExecutionErrors ：有关所发生错误的信息。
以下是个人旅程的不同状态：
- 正在运行：个人当前正在历程中。
- 已完成：个人已到达历程的结尾。
- 错误：个人在历程中因错误而停止。
- 超时：个人在历程中停止，因为步骤耗时过长。
当使用测试模式触发事件时，将自动使用源名称生成数据集。
测试模式会自动创建体验事件并将其发送给Adobe Experience Platform。 此体验事件的源名称是“Journey Orchestration测试事件”。
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains how to use Test mode in Adobe Journey Optimizer to validate a journey with persistent test profiles before publishing, including activating test mode, triggering events, reading logs, and handling business and rule-based events.
Intents:
- Activate Test mode on a draft journey to validate it with pre-existing AEP test profiles
- Configure and trigger events for test profiles using the Trigger an event interface
- Override Wait activity durations in test mode to accelerate journey progression
- Read and interpret the Show log JSON output to verify profile progression and identify errors
- Test rule-based journeys and business event journeys in test mode
- Understand the limitations and behavioral differences of Test mode compared to Simulation
Glossary:
- Test mode: A journey validation state that allows persistent AEP test profiles to traverse a draft journey before it is published (product-specific)
- Test profiles: Profiles explicitly flagged as test profiles in the Adobe Experience Platform Real-time Customer Profile Service; the only profile type permitted to enter a journey in test mode (product-specific)
- Visual flow: The canvas representation that turns green to show the path a test profile has followed through the journey
- Show log: A test mode feature that displays journey execution state in JSON format for each test profile instance (product-specific)
- Journey Orchestration Test Events: The source name under which test mode experience events are stored in Adobe Experience Platform
Guardrails:
- Only profiles flagged as test profiles in AEP can enter a journey in test mode
- Test mode requires the journey to use a namespace to verify test profile identity
- Maximum 100 test profiles per single test session
- Events can only be triggered from the test mode UI; external API triggering is not supported
- Custom upload audience attribute enrichment is not supported in test mode
- Events triggered in Test mode generate real experience events that can also trigger other journeys listening to the same event
- In Test mode, Wait activities and most event timeouts default to 10 seconds; Reaction event timeouts default to a minimum of 40 seconds
- Automatic deactivation — Journeys that remain inactive in test mode for over a week automatically exit test mode and return to Draft status. No journey content is lost; only the test mode session ends.
- Journey edits are blocked while test mode is active, but direct publishing is allowed
- At a split, the top branch is always selected; reorder branches to test different paths
- Reaction event timeout minimum and default wait time is 40 seconds
- Events sent outside the journey’s configured start/end date window are silently discarded
- Disabling test mode removes all profiles from the journey and clears reporting
Terminology:
- Canonical name: Test mode — Acronym: none — variants: test mode, journey test mode
- Canonical name: Test profiles — Acronym: none — variants: test users (Simulation UI label only)
- Synonyms: “Show log” = test results log; “visual flow” = canvas path visualization
- Do not confuse: “Test mode” ≠ “Simulation” — Test mode uses persistent AEP test profiles; Simulation uses temporary simulated users generated on the fly
FAQ:
- Q: Who can enter a journey in test mode? — Only profiles explicitly flagged as test profiles in the Adobe Experience Platform Real-time Customer Profile Service.
- Q: How many test profiles can run in a single test session? — A maximum of 100 test profiles per test session.
- Q: What happens when I disable test mode? — All profiles currently in or previously entered in the journey are removed and reporting is cleared.
- Q: Can I edit a journey while test mode is active? — No. The journey cannot be modified while test mode is active, but you can publish it directly without deactivating test mode first.
- Q: Why are my test events being silently discarded? — Events triggered outside the journey’s configured active date/time window are silently discarded. Verify the journey start and end dates include the current time.
- Q: What does the phase field in the test log indicate? — It shows the profile’s current status: running (active in journey), finished (reached end), error (stopped due to error), or timed out (stopped due to timeout).