TL;DR — Un breakpoint pausa tu macro en una línea antes de que se ejecute y te deja en break mode. Ahí puedes leer cada valor en vivo — pasa el ratón por una variable para ver un data tip, o pregunta a la Immediate Window — y luego recorrer el código línea a línea. F9 pone o quita un breakpoint, F5 ejecuta hasta él, F8 avanza a la línea siguiente, Shift+F8 salta por encima de un procedimiento llamado. Así es como encuentras en qué línea va mal, no solo qué valores hubo. Dos cosas que saber: los breakpoints no se guardan con el archivo, y una instrucción
Stopen el código que entregas congelará el Excel de un usuario.
Sub Investigate()
Dim total As Double, r As Long
For r = 2 To 100
total = total + Cells(r, 3).Value ' F9 aqui pone un breakpoint (punto rojo)
Next r ' F8 avanza; pasa el raton por 'total' para verlo crecer
Debug.Assert total > 0 ' rompe en el editor SOLO si esto es False
End Sub
Lo que aprenderás
- El modelo mental — un breakpoint congela el tiempo para que puedas recorrer el código
- Los tres observadores de poder creciente, y por qué este es el pesado
- Poner breakpoints con F9, y avanzar con F8 frente a Shift+F8
- Por qué los breakpoints desaparecen, y por qué
Stopnunca debe entregarse - Cómo
Debug.Assertte da un breakpoint que es seguro en producción - Cuándo recorrer paso a paso, y cuándo salpicar
Debug.Printen su lugar
El modelo mental: congela el tiempo, luego recorre el código
Un breakpoint detiene la ejecución en una línea elegida antes de que esa línea se ejecute, y te entrega la macro congelada en pleno vuelo. Cada variable conserva su valor en vivo, la pila de llamadas está intacta y Excel está pausado exactamente donde está tu lógica. Desde ahí avanzas paso a paso: F8 ejecuta la línea actual y se detiene en la siguiente, así que recorres el programa hacia delante a velocidad humana, viendo cada instrucción surtir efecto.
Esa es la diferencia que importa. Debug.Print te dice qué valores hubo tras
la ejecución; un breakpoint te deja encontrar en qué línea el comportamiento se aparta por primera vez de
lo que esperabas. Cuando los valores están mal pero no sabes dónde se torcieron, no necesitas más registro —
necesitas congelar la macro y verlo suceder.
Los tres observadores, de poder creciente
Un breakpoint es el peldaño más alto de una escalera. Cuando una macro se porta mal, cada herramienta responde una pregunta distinta, y esta es la que detiene el tiempo:
| Observador | La pregunta que responde | Su mentira característica |
|---|---|---|
Debug.Print |
¿Qué valores hubo mientras se ejecutaba? | Imprime en una ventana cerrada por defecto |
| Immediate Window | ¿Qué es verdad ahora mismo, en esta pausa? | Una consulta con ? en realidad ejecuta el código |
| Breakpoint + F8 | ¿En qué línea va mal? | Desaparecen cuando cierras el libro |
Debug.Print muestra el pasado; la Immediate Window interroga el presente;
un breakpoint crea el presente, congelando la macro para que puedas inspeccionar y avanzar. Es el más
potente de los tres y el más lento de usar — recorrer 10 000 iteraciones de bucle a mano no es idea de tarde
para nadie — así que echas mano de él justo cuando los observadores más baratos no pueden responder «¿en qué
línea?».
Poner breakpoints, y F8 frente a Shift+F8
Haz clic en el margen gris a la izquierda de una línea, o pon el cursor en la línea y pulsa F9 — un punto rojo la marca, y la siguiente ejecución se pausa ahí. Una vez pausado, cuatro teclas hacen el recorrido:
- F8 (Step Into) — ejecuta esta línea; si llama a un Sub o Function, entra en él y continúa línea a línea dentro.
- Shift+F8 (Step Over) — ejecuta por completo un procedimiento llamado y se detiene en la siguiente línea de aquí.
- Ctrl+Shift+F8 (Step Out) — termina el procedimiento actual y se detiene donde fue llamado.
- F5 (Run) — deja de avanzar paso a paso y ejecuta hasta el siguiente breakpoint o el final.
El mayor sumidero de tiempo es meterte con F8 directamente dentro de una rutina auxiliar de 500 líneas en la que ya confías — una rutina de formato, una llamada a una biblioteca — y recorrerla entera. Si no escribiste tú el fallo, sáltala por encima con Shift+F8. F8 es para el código que sospechas; Shift+F8 es para el que no.
Trampa 1: los breakpoints no se guardan — y Stop es la trampa que sí
Cierra el libro y todos los breakpoints desaparecen. Viven en la sesión del editor, no en el archivo, así que nunca viajan con tu macro ni se disparan para nadie más. Eso suele ser lo que quieres.
El arreglo tentador es la instrucción Stop — un breakpoint permanente escrito en el código:
Sub Risky()
Stop ' pausa aqui en CADA ejecucion - incluso en la maquina de un usuario
' ... tu trabajo real ...
End Sub
Stop es genuinamente útil mientras desarrollas porque sobrevive a un reinicio. Pero si llega a producción,
un usuario ejecuta la macro, choca con Stop, y Excel parece congelado en una pausa que no puede
entender ni quitar sin el editor de VBA. Trata Stop como un marcador de solo desarrollo que debes borrar
antes de entregar — nunca como manejo de errores, y nunca en código que sale de tu máquina.
Trampa 2: Debug.Assert es el breakpoint que se puede entregar sin peligro
Cuando quieres un breakpoint que comprueba una condición y es inofensivo en producción, usa
Debug.Assert:
Debug.Assert cnt = expected ' rompe en el editor si los recuentos no coinciden
Debug.Assert Not rng Is Nothing ' rompe si el rango no se pudo resolver
Debug.Assert condition rompe la ejecución solo cuando la condición es False, y solo dentro del
editor de VBA — en tiempo de ejecución, fuera del IDE, la línea se ignora por completo. Eso lo convierte en
la forma correcta de codificar un invariante que crees que siempre debería cumplirse («el recuento de
después es igual al de antes», «este objeto no es Nothing»): durante el desarrollo te detiene en el instante
en que la suposición se rompe, y en la copia de un usuario no cuesta nada y no congela a nadie. Es un
breakpoint condicional que se documenta a sí mismo.
Trampa 3: editar mientras está pausado tira tu estado a la basura
En break mode puedes editar código — y VBA a menudo reiniciará la ejecución para aplicar el cambio, borrando cada variable en vivo de vuelta a vacío y empezando de cero. Esta es la razón habitual de que alguien informe de que sus variables «desaparecieron» a mitad del recorrido: una pequeña edición reinició la macro en silencio. Si estás metido a fondo en una ejecución pausada, resiste la tentación de arreglar la errata que acabas de detectar hasta que hayas leído el estado por el que hiciste la pausa. Herramienta de poder relacionada: Set Next Statement (Ctrl+F9) te deja arrastrar la flecha amarilla para volver a ejecutar o saltar una línea — inestimable para reintentar un paso, pero sáltate una inicialización y el estado que luego inspeccionas es una mentira.
Breakpoint frente a Debug.Print
No son rivales; son fases distintas de la misma cacería:
| Breakpoint + F8 | Debug.Print |
|
|---|---|---|
| Responde | En qué línea va mal | Qué valores hubo |
| Bucles grandes | Doloroso — avanzas en cada pasada | Ideal — miles de líneas pasan de largo |
| Interactivo | Sí — inspecciona y cambia el estado en vivo | No — solo emite |
| Coste | Detiene la macro | Corre a toda velocidad |
Usa Debug.Print para acotar un bucle de 10 000 filas a la región donde los números se rompen; luego pon
un breakpoint ahí — o un Add Watch con una condición de ruptura que se
pausa solo cuando un valor se vuelve negativo por primera vez — para congelar en la única iteración que
importa en vez de recorrer todas con F8. El registro encuentra el vecindario; un breakpoint encuentra la
línea.
La opinión: la herramienta pesada, usada con criterio
Un breakpoint es el depurador más potente que te da VBA y el más lento de manejar, así que gástalo donde las
herramientas más baratas se agotan: cuando los valores están mal y de verdad no puedes decir qué instrucción
es la responsable. Para todo lo que sí puedes responder a partir de los valores — ¿es esta variable lo que
espero?, ¿corre este bucle el número correcto de veces? — una consulta con Debug.Print o con la
Immediate Window es más rápida y no detiene el mundo.
Dos disciplinas separan a quienes depuran rápido de quienes pelean con el editor. Nunca entregues un Stop;
codifica tus suposiciones siempre-verdaderas como Debug.Assert en su lugar, para que te guarden en el
desarrollo y desaparezcan en producción. Y nunca recorras con F8 código que no escribiste — sáltalo por
encima. El objetivo no es mirar cada línea; es llegar a la única línea que te miente.
Cuando todo el trabajo es encontrar la fila rota — descríbelo en su lugar
Recorrer paso a paso es soberbio para una única ejecución rota y miserable para «cuál de 8000 filas rompe el total». Para cuando has puesto un breakpoint, añadido un watch y avanzado hasta que un valor sale mal, has simulado a mano lo que una consulta responde en una sola pasada. ExcelMaster te deja enunciar la pregunta en español llano — «encuentra la primera fila donde el total acumulado deja de cuadrar con la columna E, y muéstrame las filas de alrededor» — y genera Python que lee la hoja, respalda tu archivo primero, comprueba cada fila y devuelve al culpable exacto. Usa un breakpoint para entender un fallo; describe la regla cuando el trabajo es encontrar qué caso falla.
Preguntas frecuentes
¿Cómo pongo un breakpoint en VBA?
Haz clic en el margen gris a la izquierda de una línea, o pon el cursor en la línea y pulsa F9. Un punto rojo marca la línea, y la próxima vez que la macro se ejecute se pausa justo antes de esa línea, dejándote en break mode. Pulsa F9 otra vez en la línea para quitar el breakpoint.
¿Por qué mis breakpoints no dejan de desaparecer?
Porque los breakpoints no se guardan con el libro — cerrar el archivo los borra todos. Si necesitas una
pausa que viva en el código, usa la instrucción Stop, pero quítala antes de compartir la macro, ya que un
Stop congelará Excel para cualquiera que lo ejecute.
¿Cuál es la diferencia entre F8 y Shift+F8?
F8 (Step Into) ejecuta una línea y entra en cualquier Sub o Function que llame, así que recorres también el código llamado. Shift+F8 (Step Over) ejecuta por completo un procedimiento llamado y se detiene en la línea siguiente del actual. Usa Step Over para rutinas auxiliares en las que ya confías.
¿Cómo veo el valor de una variable mientras una macro está pausada?
Pasa el puntero del ratón por encima del nombre de la variable para ver un data tip, teclea ? varName en
la Immediate Window, o añade la variable a la Watch Window. Esto solo
funciona mientras la macro está pausada en break mode, porque las variables locales solo existen durante la
ejecución.
¿Qué hace Debug.Assert en VBA?
Debug.Assert condition rompe la ejecución en el editor de VBA solo cuando la condición es False, y se
ignora por completo cuando el código corre fuera del editor. Es una forma segura de comprobar un invariante
durante el desarrollo — los recuentos coinciden, un objeto no es Nothing — sin dejar un Stop que podría
congelar el Excel de un usuario.
Probado en
Probado en: Excel 365 (Windows 11), VBA 7.1 — última verificación el 05/09/2026.
Guías relacionadas: VBA Debug.Print · VBA Immediate Window · VBA Error Handling · VBA On Error · VBA Bucle For