> For the complete documentation index, see [llms.txt](https://help.verkada.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.verkada.com/new-alarms/es/configuracion/alarm-sites/configure-partitions/walk-test-for-sensor-partitions.md).

# Prueba de recorrido para particiones de sensores

La prueba de recorrido permite a instaladores y clientes verificar que su sistema de alarma funciona correctamente sin activar alarmas reales.

Las pruebas de recorrido verifican que todos los sensores dentro de una partición funcionen correctamente. Por lo general, se usa:

* Después de la instalación del sistema para confirmar una configuración correcta.
* Para mantenimiento o cumplimiento de seguros.

{% hint style="danger" %}
Durante una prueba de recorrido, las particiones de sensores no activan alarmas, incluidas las configuradas como *Siempre armado.* Particiones de cámara **deben permanecer desarmadas**, y no son compatibles con las pruebas de recorrido.
{% endhint %}

***

## Realizar una prueba de recorrido

{% hint style="danger" %}
Necesita permisos de administrador del sitio para realizar una prueba de recorrido.
{% endhint %}

{% stepper %}
{% step %}
**En Verkada Command, vaya a Todos los productos > Alarmas.**
{% endstep %}

{% step %}
**Seleccione el sitio de alarma donde desea realizar la prueba.**
{% endstep %}

{% step %}
**A la izquierda, haga clic en Estado del sistema.**

a. En la parte superior derecha, seleccione **Pruebas de recorrido**. Desde aquí, puede ver o descargar informes de pruebas anteriores.\
b. En la parte superior derecha, haga clic en **Iniciar prueba**.
{% endstep %}

{% step %}
**Recorra el sitio y active todos los sensores, incluidas las puertas del controlador de acceso si están configuradas como disparadores de alarma.**

a. Cada sensor comienza en el **En espera de activación** estado. Una vez activado, su estado se actualiza en tiempo real.\
b. Cuando todos los sensores hayan sido activados, haga clic en **Finalizar prueba**.
{% endstep %}

{% step %}
**Para descargar los resultados, seleccione Generar informe para crear un resumen en PDF.**
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Las sesiones de prueba de recorrido finalizan automáticamente después de 4 horas, a menos que se detengan manualmente.
{% endhint %}

***

## Criterios de éxito para eventos de dispositivos

### Sensores con cable e inalámbricos

* Se registra un evento exitoso cuando se activa el sensor.
* Para los sensores inalámbricos, el sistema registra tanto la intensidad de la señal RSSI como el nivel de batería.
* Una batería baja o una señal débil no afectan el éxito si el sensor se activa correctamente.

### Puertas de control de acceso (AC)

Solo se cuenta como prueba exitosa el evento de puerta abierta, incluso si la puerta está configurada como puerta mantenida abierta o puerta forzada abierta.

### Criterios generales de éxito

* La prueba es exitosa cuando todos los dispositivos se activan al menos una vez.
* Cualquier advertencia, como batería baja o señal deficiente, se muestra pero no afecta el éxito general.

***

## Problemas del dispositivo

### Advertencias

* Cada sensor muestra su estado actual. Cuando una advertencia está activa, refleja el estado actual en vivo del sensor.
* Si la advertencia desaparece durante la prueba de recorrido, no aparecerá en el informe final.
* Si persiste hasta el final, se registra en el informe.

Esto permite a los usuarios abordar los problemas en tiempo real y evita que las advertencias temporales afecten el resultado final.

**Las advertencias pueden aparecer por:**

{% stepper %}
{% step %}
**Batería baja**
{% endstep %}

{% step %}
**RSSI deficiente**
{% endstep %}

{% step %}
**Dispositivo sin conexión**
{% endstep %}
{% endstepper %}

### Solución de problemas

Puede hacer clic en un dispositivo para abrir la página de detalles del dispositivo sin salir de la prueba de recorrido. Desde aquí puede:

* Diagnosticar problemas en vivo usando el contexto de la cámara, las tendencias de RSSI, el concentrador detectado durante el emparejamiento y el estado de la batería.
* Resolver problemas de inmediato ajustando la sensibilidad, volviendo a emparejar, silenciando sensores, añadiendo cámaras de contexto o habilitando la verificación por video.

### Anulación de estados de sensores

Si un sensor no funciona durante la prueba de recorrido, puede establecer manualmente su resultado directamente desde la página de prueba de recorrido:

* Seleccione **Dispositivo no funciona** para marcarlo para seguimiento posterior.
* Seleccione **Omitido / No probado** si el sensor no se probó.

  <div align="left" data-with-frame="true"><img src="https://3123261446-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNU1He6Uj2tgInV2VdCLQ%2Fuploads%2Fgit-blob-353f1730871ecc6dc67df6cc028191bc0553fa91%2F440a4e19d848ad79a60d6a3f5577e01e1a3ea31b.png?alt=media" alt=""></div>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.verkada.com/new-alarms/es/configuracion/alarm-sites/configure-partitions/walk-test-for-sensor-partitions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
