El software de trading automatizado de criptomonedas debería especificarse mediante comportamientos observables. Un requisito como ejecutar eficientemente parece útil, pero no indica a quien revisa qué debe hacer el programa cuando caduca una cotización, los fondos ya están reservados o desaparece la respuesta a un envío. Un requisito verificable nombra la entrada, la transición permitida y las pruebas que establecen el resultado.
Esta guía desarrolla una prueba de aceptación de automatización que tiene en cuenta los costes utilizando una cuenta al contado ficticia. Las cifras son inventadas para que la contabilidad sea reproducible. No representan una tabla de comisiones actual ni una rentabilidad esperada. El objetivo es determinar si el software cumple sus reglas declaradas y conserva el estado de la cuenta. Superar esa prueba establece el comportamiento operativo, no que la estrategia de trading sea rentable.
Los requisitos del software de trading automatizado de criptomonedas comienzan con invariantes
Una invariante es una condición que debería seguir cumpliéndose durante los eventos ordinarios y los fallos. Un ejemplo útil es que el efectivo total comprometido no debe superar los recursos autorizados disponibles. Otro es que una misma intención persistente no debe crear una orden adicional simplemente porque un evento se entregue dos veces. Estas afirmaciones son más sólidas que una colección de capturas del recorrido sin incidencias porque se aplican durante todo el flujo de trabajo.
Redacta las invariantes en un lenguaje que pueda inspeccionar quien revisa. El sistema debe identificar la cuenta antes de reservar capital. Un resultado desconocido de una orden debe mantener su reserva. Una configuración nueva no debe reescribir la justificación asociada a una intención anterior. Cada afirmación debería identificar qué pruebas demostrarían un incumplimiento. Si ninguna observación posible pudiera refutar un requisito, probablemente sea demasiado vago para la aceptación.
La guía anterior del ciclo de trading automatizado separa configuración, observación y actividad de la cuenta. Utiliza esas etapas al asignar requisitos. Un componente de estrategia puede proponer una acción, pero un componente independiente de riesgo decide si la acción encaja en los límites de la cuenta. Separar esas responsabilidades facilita explicar por qué una observación aparentemente atractiva no condujo a una ejecución.
Define con precisión la cuenta ficticia
Supón que una cuenta hipotética comienza con 2,000 unidades de la divisa de cotización y ninguna posición en el activo seleccionado. De ese saldo, 200 unidades están reservadas como colchón operativo y 300 ya están comprometidas con otra intención activa. Por tanto, la nueva decisión comienza con 1,500 unidades de capacidad conforme a la política indicada. Estas categorías deberían seguir siendo distinguibles en cada pantalla y exportación.
La estrategia nueva propone comprar como máximo 80 unidades del activo a un precio límite de 10 unidades de cotización cada una. Para este ejercicio, supone una comisión de trading de una décima de un punto porcentual cobrada en el activo de cotización y un gasto de ejecución de 2 unidades modelado por separado. La nueva reserva máxima es 800 más 0.80 más 2, es decir, 802.80 unidades de cotización. Los costes reales de la plataforma deben comprobarse por separado.
Registra el conjunto de datos de prueba como una entrada inmutable. Incluye el identificador de la cuenta, la identidad del activo, la identidad del activo de cotización, los saldos iniciales, los compromisos existentes y los supuestos sobre comisiones. Una captura del resultado final no basta para reproducir la prueba. Quien la revise después necesita saber qué recursos estaban disponibles antes de la nueva decisión y qué costes estaban incluidos en el presupuesto de autorización.
Especifica qué puede proponer la señal
La señal debería producir una propuesta que contenga un motivo, la marca temporal de las pruebas y la exposición solicitada. No debería crear un saldo, alterar los permisos de la cuenta ni dar por hecho que una orden se ha ejecutado. En el caso ficticio, la señal propone la compra de 80 unidades porque se cumple una condición de observación declarada previamente. El ejercicio de aceptación no necesita afirmar que esa condición tenga valor predictivo.
Una propuesta debería identificar la versión de las pruebas utilizada para calcularla. Si se revisa la observación subyacente, conserva la propuesta original y crea una evaluación nueva en lugar de sustituir silenciosamente el historial. Esto importa al revisar por qué actuó el sistema. Una decisión no puede evaluarse de manera justa frente a información que solo estuvo disponible después de autorizarla.
La guía de automatización de criptomonedas explica cómo dividir un objetivo amplio de automatización en responsabilidades acotadas. Aplica aquí esa división: la señal propone, la capa de riesgo comprueba, la capa de reservas compromete capacidad y la capa de ejecución intenta la acción permitida. Los nombres pueden variar entre implementaciones, pero las responsabilidades deberían seguir siendo visibles en el registro de aceptación.
La autorización debe incluir el presupuesto completo
La comprobación de riesgo compara la reserva máxima de 802.80 unidades con las 1,500 unidades de capacidad disponible. Conforme a la política ficticia, la propuesta encaja y deja 697.20 unidades disponibles para otra actividad nueva. Una prueba debería verificar ambas cifras. Comprobar únicamente que el valor nominal solicitado de 800 es inferior al saldo total pasaría por alto las comisiones, el colchón operativo y el compromiso anterior.
Define si la provisión para comisiones es un límite estricto o una estimación. Si la ejecución real pudiera superar el presupuesto autorizado, el software necesita otra restricción aplicable o una regla de rechazo. Llamar estimado a un coste no concede autoridad ilimitada. El registro de aceptación debería explicar qué ocurre si la cotización final o el gasto de transacción supera el supuesto utilizado durante la autorización.
Prueba también un valor en el límite. Aumenta el importe propuesto hasta que la reserva supere la capacidad por una cantidad pequeña. El resultado esperado es un rechazo documentado o una propuesta nueva que la política permita explícitamente. Redimensionar silenciosamente no es aceptable de manera automática porque cambia la decisión original. Si se admite redimensionar, sus reglas y el importe resultante deberían formar parte del requisito declarado.
El software de trading automatizado de criptomonedas necesita identidades persistentes
Asigna a la decisión un identificador de intención antes del envío. El identificador debería conectar la observación original, la autorización de la cuenta, la reserva de capital y los intentos de ejecución resultantes. Puede aparecer un identificador separado de orden o transacción después de que la solicitud llegue al sistema de ejecución. Conserva ambos para que la aplicación pueda distinguir su propia decisión persistente de una representación externa de esa decisión.
Entrega dos veces el mismo evento de entrada durante la prueba. La segunda entrega debería encontrar la intención existente, no reservar otras 802.80 unidades. Esta es una condición de aceptación importante porque muchos sistemas de datos pueden volver a entregar eventos tras reconectarse. Un transporte duplicado no equivale a una segunda oportunidad económica, y la cuenta no debería deducir una autorización nueva únicamente de una entrega repetida.
La guía anterior de coordinación de varias carteras resulta útil cuando intervienen varios procesos de trabajo de cuentas. El ámbito de una identidad de intención debe definirse con suficiente cuidado para evitar confusiones entre cuentas y, a la vez, impedir el trabajo duplicado dentro de la cuenta prevista. Una etiqueta globalmente única ayuda, pero el requisito real es una titularidad y una interpretación coherentes durante todo el flujo de trabajo.
Modela una ejecución parcial sin perder el remanente
Ahora supón que la orden hipotética ejecuta 50 unidades a 9.90. El coste nominal es 495. Con la tasa de comisión supuesta, la comisión de la ejecución es 0.495. Si se incurre en el gasto de ejecución de 2 unidades para este intento, la parte completada ha consumido 497.495 unidades de cotización. La cuenta ha adquirido 50 unidades, no las 80 solicitadas originalmente.
Las 30 unidades restantes siguen asociadas a la orden activa. Su valor nominal máximo es 300 al precio límite y la comisión máxima supuesta es 0.30. Mantén una reserva de 300.30 unidades para ese remanente conforme al modelo de costes de este ejercicio. La diferencia entre la reserva original y los costes completados más la reserva restante es de 5.005 unidades, lo que refleja la mejora del precio de ejecución y la menor comisión sobre la cantidad ejecutada.
La prueba debería verificar explícitamente la política de liberación. Algunos sistemas mantienen toda la reserva original hasta la finalización para simplificar. Otros liberan de forma incremental el exceso de capacidad confirmado. Cualquiera de los enfoques necesita una especificación clara. El requisito esencial es que el sistema nunca libere dinero que siga siendo necesario para un remanente activo o sin resolver y nunca trate una cantidad sin ejecutar como un activo en propiedad.
La cancelación es una solicitud con su propio resultado
Después de la ejecución parcial, la estrategia solicita cancelar las 30 unidades restantes. Esa solicitud no demuestra al instante que la orden haya desaparecido. El sistema de ejecución puede confirmar la recepción antes de comunicar un estado final, y podría producirse otra ejecución durante ese intervalo. El escenario de aceptación debería incluir esta posibilidad en lugar de suponer que la cancelación es un borrado síncrono.
Para el conjunto básico de datos de prueba, estipula que se confirma la cancelación sin ninguna ejecución adicional. Entonces puede liberarse la reserva de 300.30 unidades del remanente. La cuenta conserva las 50 unidades adquiridas y el coste completado de 497.495 unidades. El compromiso independiente de 300 unidades y el colchón operativo de 200 unidades permanecen sin cambios. Un remanente cancelado no revierte la compra anterior ni los gastos en los que se haya incurrido.
Añade una segunda variante en la que se ejecuten cinco unidades más antes de completarse la cancelación. El sistema debe incorporar esas unidades y sus costes reales antes de determinar el importe final liberado. El resultado esperado debería calcularse a partir de las nuevas pruebas de ejecución, no del momento en que el operador hizo clic en cancelar. Esta variante comprueba si la implementación sigue los eventos económicos en lugar de las intenciones expresadas en la interfaz.
Recomienda y gana USDC
Recomienda y gana USDCNuestro programa de afiliados paga en tiempo real.
Pon a prueba un resultado de envío desconocido
Un escenario de recuperación de trading automatizado debería interrumpir la comunicación inmediatamente después del envío. El entorno de pruebas registra que la solicitud puede haber llegado al sistema de ejecución, mientras que la aplicación no recibe ninguna respuesta definitiva. El estado requerido es sin resolver, conservando la reserva. No debería crearse una orden económica nueva simplemente porque la llamada original devolviera un error o agotara el tiempo de espera.
La recuperación busca el resultado existente utilizando las referencias persistentes que admita la integración. Puede inspeccionar el historial de la cuenta, las órdenes abiertas o el estado de la transacción. La especificación debería describir qué pruebas bastan para clasificar el intento como aceptado, rechazado, completado o todavía desconocido. También debería describir cómo se eleva la incertidumbre para su atención cuando las fuentes disponibles discrepan o siguen incompletas.
La guía de bots de arbitraje cripto muestra por qué un envío sin resolver resulta especialmente relevante cuando puede haberse ejecutado otra pata de la operación. El mismo principio se aplica a este ejemplo de una sola orden. Un tiempo de espera agotado cambia lo que sabe la aplicación. No cambia necesariamente lo que ha hecho la cuenta externa, de modo que la prueba de aceptación debe mantener separados esos dos hechos.
Mide los costes sin convertir una estimación en un hecho
Después de la conciliación, sustituye los costes de ejecución estimados por los importes observados, conservando la estimación original para compararla. Esto permite a quien revisa ver si el modelo presupuestario era conservador, preciso o incompleto. Un único campo sobrescrito al pasar de estimación a valor real destruye esas pruebas y dificulta mejorar los supuestos futuros sobre costes.
En el caso ficticio de ejecución parcial, el coste total observado es de 497.495 unidades conforme a los supuestos indicados. Dividirlo entre 50 da 9.9499 unidades de cotización por unidad del activo adquirido cuando se asigna el gasto fijo a esa compra. El precio medio de negociación sigue siendo 9.90. Ambas cifras pueden resultar útiles, pero deberían tener etiquetas diferentes porque una incluye costes y la otra no.
La guía de software de arbitraje cripto explora por qué esta distinción importa cuando un diferencial aparente es pequeño. Para la aceptación, el comportamiento importante es una contabilidad reproducible. El software no debería alternar entre medidas brutas y medidas que incluyen costes según cuál parezca mejor. Una definición estable permite comparar los resultados económicos esperados con el registro real de la cuenta.
Prueba las pruebas obsoletas y los cambios de configuración
Crea un conjunto de datos de prueba en el que la observación caduque entre la propuesta y la autorización. El comportamiento esperado debería ser una nueva comprobación, un rechazo u otra transición permitida explícitamente. La aplicación no debería interpretar la existencia de una señal que fue válida en su momento como autoridad permanente. El límite de antigüedad de las pruebas debe pertenecer a la regla de decisión y aparecer en el registro de rechazo.
Después cambia la configuración de la estrategia mientras haya una intención pendiente. La intención existente debería seguir asociada a la versión que la autorizó, salvo que un proceso de modificación documentado la cambie. Una configuración nueva puede regir decisiones futuras sin reescribir el pasado. Esto resulta especialmente importante cuando alguien intenta reproducir después por qué el sistema comprometió un importe concreto.
Una prueba útil distingue entre almacenar y activar una configuración. Guardar un límite revisado no significa necesariamente que todos los componentes en funcionamiento lo hayan adoptado. El software debería mostrar la versión activa y el punto en el que el cambio entra en vigor. De lo contrario, un operador puede creer que una restricción está vigente mientras un proceso de trabajo sigue utilizando un conjunto de permisos anterior.
Incluye casos negativos que enseñen algo
Las pruebas negativas deberían abordar modos de fallo significativos. Una identidad de activo no admitida, un recurso de transacciones agotado, una instantánea obsoleta de la cuenta y un presupuesto con compromisos excesivos ponen a prueba límites distintos. Una gran colección de entradas inválidas casi idénticas puede generar un recuento de pruebas impresionante sin mejorar la confianza en el comportamiento económico del sistema.
Para cada caso negativo, especifica qué debe permanecer sin cambios. Una propuesta rechazada no debería adquirir un identificador de orden activa, consumir una asignación de trading ni aparecer como una operación completada. Aun así, puede crear un registro de auditoría y un coste operativo, según dónde se produzca el rechazo. La distinción debería ser explícita para que la prueba no confunda la conservación de pruebas con una actividad no autorizada en la cuenta.
La tabla anterior de evaluación de pruebas para software de trading ofrece una estructura útil de evaluación. Aplícala al comportamiento demostrado en lugar de a la cobertura declarada. Una prueba fallida es información valiosa cuando identifica un requisito que puede aclararse o un defecto de implementación que puede corregirse antes de un uso más amplio.
Reproduce el resultado a partir del diario
Al final de la sesión de aceptación, exporta el diario y reconstruye la cuenta sin depender de la aplicación en vivo. Quien revisa debería identificar el saldo inicial de 2,000 unidades, las reservas separadas, las 50 unidades adquiridas, el coste completado y el remanente liberado. Cada conclusión debería apuntar a un evento registrado o a un supuesto declarado.
Esta reconstrucción comprueba algo más que la contabilidad. Revela si el software conserva la cronología y si las etiquetas de los eventos significan lo que afirman. Un evento de envío no debería contarse como una ejecución. Una solicitud de cancelación no debería contarse como una cancelación confirmada. Una actualización de valoración no debería cambiar el número de unidades del activo en propiedad. El diario debería mantener estas distinciones incluso después de que la interfaz las simplifique.
Quien revisa también debería poder identificar lagunas. Si un gasto de ejecución no está disponible, la exportación debería indicar que la contabilidad de costes está incompleta en lugar de insertar cero. La ausencia de un dato es un estado diferente de un cero medido. Conservar esa distinción permite al propietario de la cuenta evaluar los límites prácticos del resultado sin inventar precisión.
Registra la aceptación sin afirmar el éxito de la estrategia
Un informe de aceptación debería nombrar el conjunto de requisitos, los conjuntos de datos de prueba, la versión del software y los resultados observados. Debería identificar las limitaciones restantes y las condiciones en las que habría que repetir la prueba de un resultado. Un cambio en la semántica de las órdenes, los permisos de la cuenta o el tratamiento de costes puede invalidar un resultado de aceptación anterior aunque los ajustes visibles de la estrategia sigan siendo los mismos.
Superar estos escenarios establece que el sistema se comporta de manera coherente con su flujo de trabajo especificado. No establece que la señal prediga precios futuros ni que la asignación seleccionada sea adecuada para una persona concreta. Esas son cuestiones separadas de investigación y decisión. Mantenerlas separadas evita que una demostración técnicamente satisfactoria se convierta en una afirmación económica sin fundamento.
El entregable práctico es un paquete pequeño y repetible de pruebas: requisitos, entradas ficticias, transiciones esperadas, registros observados y cálculos conciliados. Con ese paquete, otra persona puede entender qué se pidió al software y por qué el resultado cuenta como aprobado o fallido. Es una base más sólida para la automatización que la confianza construida a partir de una demostración sin interrupciones.
Conserva la diferencia entre el reloj de prueba y el reloj del mercado
Un conjunto de datos reproducible debería controlar explícitamente el tiempo. La prueba necesita saber cuándo se produjo una observación, cuándo estuvo disponible para la aplicación y cuándo se evaluó la acción propuesta. Pueden ser tres momentos distintos. Si una reproducción utiliza un valor histórico corregido antes de que llegara originalmente esa corrección, puede hacer que la decisión parezca mejor informada de lo que podría haber estado cualquier operador real.
Utiliza la misma distinción al simular interrupciones. Adelanta el reloj de prueba reteniendo una actualización de la cuenta y después verifica que la política de estado obsoleto se active en el límite previsto. Reanuda la fuente con eventos retrasados y comprueba si la aplicación conserva sus horas originales de evento. Este ejercicio puede descubrir un sistema que etiqueta como reciente una observación antigua simplemente porque se recibió después de la reconexión.
Por último, conserva el orden de los eventos que comparten una marca temporal mostrada. Los segundos redondeados pueden ocultar la secuencia entre una ejecución, una solicitud de cancelación y una actualización del saldo. Una referencia persistente de secuencia o un registro temporal más preciso ayuda a reproducir el resultado. La aceptación debería establecer en qué pruebas de orden se apoya la implementación y cómo se comporta cuando esas pruebas están incompletas.