Systèmes de négociation
Convertissez les conditions d’entrée, de sortie, de dimensionnement, de synchronisation et d’arrêt définies par le client en scénarios que les équipes peuvent vérifier ensemble.
Comment le flux de travail s’articule
Une stratégie peut sembler claire à son auteur tout en laissant place à plusieurs interprétations valides pour l’équipe technique. Un tableau de tests rend ces écarts visibles avant la mise en œuvre. Il ne cherche pas à déterminer si la stratégie sera rentable; il confirme le comportement attendu des règles pour des données précises.
Commencez par une décision unique définie par le client, par exemple si une demande d'entrée est admissible. Énumérez l'instrument, l'horodatage, la session de marché, les valeurs des indicateurs, la position actuelle, les commandes en attente, les limites configurées et la fraîcheur des entrées. Ne combinez pas l'entrée, le calibrage et la sortie dans une seule rangée si elles peuvent être examinées séparément.
Enregistrer la source et la précision de chaque entrée. Une valeur calculée à partir d'une barre fermée peut produire une décision différente du même indicateur mis à jour pendant une barre active.
Inclure des valeurs juste au-dessous, égales et juste au-dessus de chaque seuil. Ajouter des limites de session, des valeurs de position zéro ou maximum, des données inexistantes, des entrées manquantes et un ordre ouvert existant. Ces lignes forcent la spécification à indiquer des comparaisons inclusives et la préséance entre les règles.
Un test de règle peut s'attendre à ce que le logiciel crée une demande de commande autorisée. Il ne devrait pas s'attendre à ce que le courtier se remplisse à un prix donné ou que le commerce fasse de l'argent. L'acceptation de l'exécution utilise des réponses simulées de courtiers pour vérifier les paramètres soumis, les transitions d'état et le traitement des erreurs.
Donnez une version des règles et des exemples. Lorsqu'un seuil, une hypothèse de calendrier ou une règle de priorité change, mettre à jour les lignes touchées et conserver l'historique approuvé. Les tests automatisés peuvent ensuite encoder les mêmes exemples alors que la table reste lisible pour les non-développeurs.
Prendre une règle définie par le client qui permet une entrée seulement pendant une session spécifiée lorsque deux conditions numériques sont vraies et aucune position n'est ouverte. Geler l'horodatage, le fuseau horaire, les entrées de l'indicateur, l'état de position actuel, l'instrument autorisé et la version de configuration. Le résultat attendu devrait indiquer les critères d'éligibilité ou de non-éligibilité et indiquer la règle qui l'a décidée.
Utilisez les lignes pour régler la priorité de la règle ainsi que les comparaisons individuelles. Décider si les données non valides ou invalidées sont vérifiées avant le moment de la session, si un garde-position a priorité sur les conditions numériques, et quelle raison apparaît lorsque plusieurs règles échouent. La preuve attendue devrait rendre cette commande visible dans le dossier de décision.
| Scénario | Séance | État | Fonction | Décision concernant les logiciels attendus |
|---|---|---|---|---|
| Sous-seuil | Ouvrir | Valeur inférieure à la limite configurée | Aucune | Non éligible: seuil |
| Au seuil | Ouvrir | Valeur égale frontière | Aucune | Utiliser la règle d'inclusion documentée |
| La position existe | Ouvrir | Toutes les règles numériques passent | Ouvrir | Non admissible: garde de poste |
| Tente d'entrée | Ouvrir | La dernière mise à jour dépasse la limite de fraîcheur | Aucune | Évaluation et alerte de rejet |
| Stratégie handicapée | Ouvrir | Toutes les entrées valables | Aucune | Aucune demande d'exécution |
Un tableau des règles prouve comment la décision stratégique doit se comporter pour les intrants connus. Elle ne prouve pas qu'un courtier acceptera une commande, que les données du marché arriveront à temps ou qu'un résultat financier se produira. Conservez l'admissibilité, commandez la construction, la soumission du courtier, puis indiquez les étapes d'essai distinctes avec leurs propres preuves.
Au cours de l'examen de l'acceptation, comparez la version approuvée du tableau avec la configuration et les preuves de décision produites par le logiciel. Si un résultat diffère, conservez l'exemple original et enregistrez si la règle, la configuration ou l'implémentation doit changer. Cela préserve un lien critique entre le comportement convenu et la libération testée.
Repère visuel
Séparer les couches empêche une décision stratégique d'être confondue avec un résultat d'exécution ou une revendication de performance.
Éligibilité
Les intrants congelés satisfont-ils aux règles établies par le client?
Construction des commandes
Le côté, le type, la quantité, le prix et les identifiants sont-ils valides?
Réponse du site
Le courtier a-t-il accepté, rejeté ou laissé le résultat incertain?
Cycle de vie
Quel état plus tard ouvert, partiel, rempli, annulé ou réconcilié est survenu?
Questions pratiques
Ils peuvent fournir des exemples d'entrée, mais le comportement logiciel attendu devrait être séparé du profit. Les résultats historiques n'établissent pas de performance future ni ne prouvent toutes les limites des règles.
Le client ou le propriétaire autorisé de la stratégie définit et approuve l'intention de la stratégie. L'ingénierie peut identifier l'ambiguïté et mettre en œuvre les règles approuvées, mais elle ne devrait pas inventer de décisions commerciales.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster applique des règles de négociation définies par le client avec un comportement testable, des connexions de courtiers, des contrôles et un déploiement privé.
