Guide Unreal Automation Framework et tests fonctionnels

Réponse directe

Le guide Unreal Automation Framework and Functional Tests doit être considéré comme une décision de production maîtrisée sur ce qui relève des tests d’automatisation de type unitaires, des tests fonctionnels basés sur carte, ou des exécutions de bout en bout sur appareil. Définissez le propriétaire des tests d’automatisation de type unitaires, rendez les tests éditeur observables, testez les acteurs de test fonctionnels sous la version cible d’Unreal Engine et la plateforme cible, et conservez un résultat d’échec et de rollback. Ce guide couvre les tests d’automatisation de type unitaires, les tests éditeur, les acteurs de test fonctionnel, les commandes latentes, les filtres de test ; il ne prétend pas qu’une seule exécution éditeur prouve un résultat packagé, en réseau ou prêt pour la plateforme.

Établir le composant propriétaire et le chemin de preuve avant de modifier les détails d\u2019intégration. Cet article s\u2019adresse aux ingénieurs de build, aux équipes QA et aux leads techniques produisant des releases Unreal auditables. Il se concentre sur le contrat de production en marge de tests d\u2019automatisation de type unit-like, tests éditeuret test actors fonctionnels. Elle exclut délibérément les consignes d'environnement de livraison non publiques, les garanties du moteur non documentées, les détails d'implémentation privés d'un projet et les affirmations qui ne peuvent pas être reproduites à partir d'une révision nommée du projet.

Points clés

• Traiter les tests d\u2019automatisation de type unit-like comme un périmètre technique propriétaire, et non comme un simple paramètre isolé.
• Tester les tests d\u2019éditeur avec les conditions de moteur, de build, de contenu et de plateforme nommées qui comptent.
• S\u2019appuyer sur les acteurs de test fonctionnels pour rendre visibles la réussite, la dérive, l\u2019interruption et le chemin de réparation.
• Rouvrez le choix de production lorsqu'on construit uniquement des tests de cartes lents ou uniquement des tests de code isolés et que le comportement d'intégration reste non couvert.

Définissez la frontière du système avant l’implémentation

La première tâche consiste à séparer le comportement du moteur, la politique de la base de code et la preuve observable observée. La documentation officielle d'Epic Games décrit les concepts Unreal Engine documentés à l'extérieur et les chemins d'exécution pris en charge. Une base de code décide néanmoins du nommage, des responsabilités, de la durée de validité, des budgets de performance, de la couverture de test et des portes de release. Un résultat au niveau d'une station de travail ne prouve que les critères effectivement exercés. Garder ces couches séparées permet à l'article d'être cité sans transformer un exemple en promesse universelle.

For tests fonctionnels du unreal automation framework, la frontière de propriété commence avec les tests d'automatisation de type unitaire. Notez qui la crée, qui peut la modifier, quand elle devient valide et ce qui l'invalide. Puis mappez ensuite les tests éditeur à une demande concrète et les test actors fonctionnels à une réponse traçable. Si aucun propriétaire d'état ni résultat observable ne peut être nommé, la configuration in-project n'est pas préparée à l'échelle des cartes, des utilisateurs, des builds ou des familles d'appareils.

Liste de contrôle de la propriété

• Autorité des tests d'automatisation de type unitaire : enregistrez le module, l’objet propriétaire, l’actif propriétaire, la frontière de service ou le compte de plateforme ; clôturez le ticket avec un chemin source ou une configuration ainsi que des notes de durée de vie à l’exécution.
• Rédacteurs de tests éditeur : Enregistrer les valeurs entrantes, les signaux, les composants requis, l\u2019ordre des événements et le contrôle ; clore la vérification par un enregistrement d\u2019exécution, un journal de trace, une capture de débogueur ou une inspection directe déterministe.
• Preuve pour les acteurs de test fonctionnels : Enregistrer la valeur résultante attendue, la tolérance mesurée et l\u2019état non pris en charge ; clore la vérification avec une validation répétée, un problème et un chemin de réparation sur une seule base.
• Zone de travail externe : Enregistrer les révisions non prises en charge, les plugins, les appareils et les hypothèses de production ; clore le sujet avec une limitation explicite et un déclencheur de rollback.

Comment les tests fonctionnels Unreal Automation Framework fonctionnent dans un projet de production

Choisir une tranche semblable à la production pour que les compromis coût, correction et séquence restent comparables. Commencer par les tests d\u2019automatisation de type unit-like comme source de vérité. Les zones techniques Unreal environnantes peuvent mettre en cache, répliquer, rendre, sérialiser ou transformer cette vérité, mais chaque passation doit préserver un contrat lisible. Quand le paquet de tests d\u2019éditeur franchit cette frontière, enregistrer la forme des données, l\u2019ordre, l\u2019autorité d\u2019écriture et la réponse d\u2019échec plutôt que de s\u2019appuyer sur une convention implicite de l\u2019éditeur.

La couche suivante est celle des acteurs de test fonctionnel. Rendez-la inspectable au moment où la décision d’ingénierie est prise, pas seulement après qu’un utilisateur remarque l’effet visible en production. Selon le sujet, une preuve adaptée peut être Unreal Insights, une catégorie de débogueur de gameplay, une capture réseau, un journal de diagnostic AutomationTool, un audit d’actifs, un manifeste généré, une capture de profiler, ou une petite carte de test prévisible. L’outil importe moins que la préservation de l’état et de la couche responsable derrière le résultat.

Enfin, reliez les commandes latentes à un budget d'acceptation. Une couche runtime peut être fonctionnellement correcte et échouer quand même car elle consomme trop de temps image, de mémoire, de bande passante, de temps de build, d'espace de package, d'attention opérateur ou de temps de récupération. Utilisez au moins un scénario ordinaire et un exemple de limite système qui ressemble à l'échelle de production. N'extrapolez pas à partir d'un titre modèle vide sans en mentionner la limitation.

Modèle opérationnel spécifique au sujet

Pour ce guide, commencez par identifier la révision source, les règles cibles, la commande d’automatisation et le propriétaire de l’artefact. Le premier point de contrôle est le test d’automatisation de type unitaire, tandis que les tests éditeur et les acteurs de test fonctionnel décrivent le transfert technique qui doit rester traçable. Ne laissez pas un objet d’exécution pratique, une prévisualisation éditeur uniquement ou une couche de présentation aval devenir une seconde vérité canonique accidentelle. Notez l’exigence de propriété à côté de la révision du projet afin que le comportement de démontage/redémarrage puisse être revu avec la configuration in-project.

L\u2019enregistrement diagnostic le plus utile ici est les journaux AutomationTool ou BuildGraph, les manifestes, les codes de sortie, les artefacts de test, les symboles et les checksums. Appliquer cette preuve observable aux acteurs de test fonctionnels avant d\u2019optimiser les commandes latentes. Un résultat correct doit nommer la condition d\u2019entrée, la transition observée, l\u2019artefact de sortie et l\u2019identité du build. Si une utilité ne peut pas montrer la couche responsable associée ou le calendrier, ajouter une instrumentation plus fine à la limite du système plutôt que d\u2019inférer la correction à partir de la sortie visuelle ou audible terminée.

Exercez la perte d'un worker, l'annulation de cuisson, l'absence de cache, la nouvelle tentative, le téléversement partiel, le crash et le rollback. Ces cas sont particulièrement importants car l'état d'échec définissant cette page consiste à ne construire que des tests de carte lents ou uniquement des tests de code isolés et à laisser le comportement d'intégration non couvert. Arrêtez-vous au premier état qui contredit le propriétaire d'état requis, enregistrez sa capture ou son journal d'exécution, et démontrez qu'une nouvelle tentative répétée ou une révision de repli supprime les ressources d'exécution périmées et le travail dupliqué. Développer le contenu ou la couverture matérielle d'exécution avant que ce chemin de réparation soit reproductible masque la limite contractuelle causale.

L\u2019acceptation de type production doit inclure les minutes de build et de cook, le taux de hits cache, la taille des artefacts, la durée des tests et la reproductibilité sur agent propre. Sélectionner uniquement les mesures spécifiques aux tests fonctionnels du Unreal Automation Framework, en préciser les unités de mesure et la fenêtre d\u2019échantillonnage, et conserver la tranche de données de production de manière durable. Le jugement de production reste de savoir quel comportement appartient aux tests de code rapides, aux tests fonctionnels basés sur map ou aux exécutions de bout en bout sur appareil. Il n\u2019est clos que lorsque le chemin choisi, l\u2019alternative rejetée, la limitation connue et la contrainte de réouverture font tous partie de la passation technique.

Cadre de prise de décision

La décision principale consiste à déterminer quel comportement appartient aux tests de code rapides, aux tests fonctionnels basés sur map ou aux exécutions de bout en bout sur appareil. Utiliser le tableau d\u2019évaluation ci-dessous pour maintenir le choix lié au membre de l\u2019équipe et aux résultats de production plutôt qu\u2019à la préférence de capacité.

Cas de décision

• Le modèle d’autorité et la durée de vie sont clairs : préservez l’architecture la plus petite qui expose clairement les tests d’automatisation de type unitaires. Exigez des artefacts d’initialisation, de mutation, de démontage et de redémarrage. Réévaluez lorsque qu’un autre propriétaire d’état commence à écrire le même état.
• Plusieurs diagnostics semblent résoudre le problème de production : comparez-les via une même procédure de tests éditeur mesurée avec le même matériel de projet, la même révision, la même famille d'appareils et le même test d'acceptation. Reconsidérez lorsqu'un choix d'implémentation dépend d'hypothèses cachées liées au projet ou à la famille d'appareils.
• Le chemin attendu fonctionne : introduire des situations inacceptables, d'interruption, de redémarrage et de montée en charge. Exiger un diagnostic d'échec ainsi qu'un chemin de retour propre. Reconsidérez lorsque la restauration nécessite une réparation manuelle ou laisse un état obsolète.
• Le support de la version du moteur ou de la cible runtime diffère : isoler le chemin non pris en charge derrière une limite de contrat explicite. Conserver la date de documentation, le résultat du build et le fallback. Réévaluer lorsque le fallback modifie un comportement d\u2019exécution visible par le joueur ou le coût.

Définir le propriétaire d\u2019état et le chemin d\u2019enregistrement diagnostique avant de modifier les détails de conception opérationnelle. Une bonne décision est réversible. Enregistrer la raison du choix actuel, la preuve utilisée et la condition qui l\u2019invalide. Cet enregistrement vaut plus qu\u2019une longue liste de capacités car il survit aux changements d\u2019effectifs et aux mises à jour moteur.

Flux de travail d’implémentation et de validation

1. Figer la base de référence. Geler le patch Unreal Engine, la révision du projet, les plugins, la plateforme cible, la configuration d'exécution du build et une tranche de contenu représentative. Écrivez le résultat attendu pour les tests d'automatisation de type unitaire avant de toucher à l'intégration.
2. Attribuer la responsabilité. Nommez l'état et la plage de cycle de vie responsables pour les tests éditeur. Enregistrez quel module de projet, instance d'objet, fournisseur, ressource détenue ou couche runtime peut le modifier et quelles couches observent ou présentent seulement.
3. Instrumenter l\u2019artefact de revue. Exposer les acteurs de test fonctionnels via un enregistrement d\u2019exécution, un log diagnostic, une catégorie de débogueur, un profileur, un manifeste ou une tâche d\u2019inspection directe prévisible adaptée à la zone technique. Éviter de s\u2019appuyer sur une dernière capture d\u2019écran comme seule preuve observable.
4. Interruption du test. Exécutez le chemin normal avec des déclencheurs fixes, puis réexécutez-le avec une entrée invalide, une interruption et un redémarrage ou une reconnexion. Conservez les mêmes critères d’acceptation à chaque exécution.
5. Observez l'échelle mesurée. Mesurez les commandes latentes sur du gameplay matériel et un matériel réel. Capturez les quantités, la fenêtre de temps, les situations de tranche capturée et l'identité de build afin qu'une comparaison ultérieure choisisse la même ligne de base.
6. Publier la passation. Conditionner le choix d\u2019ingénierie comme une passation : fichiers modifiés, prérequis, commande de reproduction, élément de revue prédit, limitation connue, autorité, et critère déclenchant une révision de fallback ou une nouvelle investigation.

Ce flux de production sépare intentionnellement la configuration, l'implémentation moteur, l'observation et l'acceptation. Si un test échoue, revenez à la frontière la plus tôt qui ne correspond plus au matériel de vérification. Ne modifiez pas plusieurs paramètres puis conservez uniquement la dernière capture vérifiée ; cela supprime la chaîne causale qu'un autre membre de l'équipe doit avoir.

Matrice de validation

Segments de validation requis

• Baseline: choisir une révision connue et un jeu d\u2019actifs réaliste minimal. Capturer le composant propriétaire, la transition, la sortie et la latence. Valider quand l\u2019observation se répète sans tâches de main manuelle cachées ; sinon stocker la première trace causale et arrêter l\u2019extension de la frontière de travail.
• Demande inacceptable : choisir une entrée manquante, mal formée, non autorisée ou hors périmètre. Capturer explicitement le rejet indiqué et l\u2019état d\u2019autorité inchangé. Valider quand aucun crash, état obsolète ou succès silencieux n\u2019apparaît ; sinon améliorer la revue qualité au niveau de la responsabilité propriétaire.
• Interruption: exercer les cas de travel, annulation, déconnexion, démontage ou arrêt de build selon le besoin. Capturer le nettoyage des ressources et le chemin de réparation. Valider quand la zone technique retourne à un état connu sans réparation manuelle ; sinon introduire l\u2019annulation, le timeout ou une réversion transactionnelle.
• Scale: s’appuyer sur des acteurs, des actifs moteur, des utilisateurs, des frames, des tâches ou des appareils à l’échelle cible. Capturer la surcharge avec des unités rapportées et les critères d’échantillonnage de test. Valider quand la marge budgétaire convenue a de la réserve ; sinon réduire l’étendue d’implémentation ou modifier l’architecture avant la phase de polish.
• Upgrade: s'appuyer sur le correctif du moteur cible, l'ensemble de plugins du projet ou la chaîne d'outils de la plateforme cible. Comparez les artefacts d'avant et d'après. Validez lorsque l'effet visible et le budget cible restent dans les limites ; sinon restaurez la ligne de base précédente et documentez l'incompatibilité.

Pour les tests fonctionnels du Unreal Automation Framework, des indicateurs utiles peuvent inclure les millisecondes par image, les mégaoctets, les octets répliqués, les minutes de cook, la taille du package, le nombre d\u2019objets actifs runtime, les voix actives, les permutations de shaders, les cellules chargées ou les secondes de restauration. Utiliser uniquement les signaux exposés par la zone technique réelle. Si une valeur n\u2019a pas été quantifiée, la marquer comme unknown plutôt que de remplir la page avec une estimation.

Modes de défaillance et reprise

Dérive de propriété

La dérive de propriété d’état apparaît lorsque les tests d’automatisation de type unitaires peuvent être modifiés depuis plusieurs couches sans hiérarchie stable ni mise à jour atomique. Le signal d’alerte traçable peut sembler aléatoire, mais le manque d’implémentation en cause est généralement un acteur de référence non documenté ou une durée de vie non maîtrisée. Incluez un artefact de revue spécifique à la couche responsable, rejetez les écritures invalides, et réappliquez la même séquence après déplacement, rechargement, reconnexion ou teardown.

Dérive de version et de configuration

Les paramètres par défaut de l'éditeur, les plugins, les cibles de build, les fournisseurs de cibles d'exécution et les paramètres de workspace changent selon les versions du moteur et des machines. Enregistrez la révision nommée et la configuration du projet à côté de l'artefact de revue. Un exemple UE 5.8 fonctionnel ne doit pas être présenté comme preuve pour une branche de version plus ancienne ou un plugin de projet propre à un fournisseur, sauf si cette combinaison a réellement été testée.

Échelle masquée par un flux heureux

Les tests éditeur peuvent fonctionner avec un seul acteur, un seul actif moteur, un seul utilisateur ou un seul appareil cible, alors que la charge mesurée et l’ordre des événements échouent à l’échelle mesurée. Augmentez une dimension à la fois et enregistrez la première tolérance mesurée ou limite de correction du système. Conservez les données de test de production afin que le travail ultérieur mesure le même problème au lieu d’un benchmark réinventé.

Récupération qui dépend d’une réparation manuelle

Traitez l'annulation, les données d'exécution périmées, les callbacks tardifs et la révision de secours comme des exemples d'acceptation de première classe. Pour ce sujet, le risque caractéristique est de construire uniquement des tests de carte lents ou uniquement des tests de code isolés et de laisser le comportement d'intégration non couvert. Un repli sain restaure l'état officiel, libère les ressources, empêche les callbacks ou habilitations en double, et laisse suffisamment de preuves pour expliquer ce qui s'est passé. Si un mainteneur autorisé doit supprimer des données d'exécution générées ou redémarrer plusieurs instruments sans base de décision documentée, le flux de production n'est pas prêt pour la production.

Version, plateforme et limites de preuve

Cette page applique la documentation de référence UE 5.8 actuelle comme point de référence daté. Epic Games peut modifier l\u2019état sensible aux versions, les valeurs par défaut, l\u2019emballage des plugins de projet, les API, la prise en charge de l\u2019environnement de livraison et les chemins d\u2019exécution recommandés. Vérifier le sélecteur de version du matériau de référence et les notes de version avant de recopier des paramètres dans une autre ligne de développement. Pour un travail ciblé par plateforme, les recommandations publiques Unreal ne remplacent pas les documents techniques confidentiels de plate-forme cible ni l\u2019accès à la certification.

L\u2019article fournit une méthode de contrôle qualité, et non une affirmation selon laquelle SEELE AI ou ce dépôt ont exécuté tous les scénarios natifs UE. Lorsque les sources de référence de premier parti et les éléments de vérification du projet diffèrent, enregistrer les deux et restreindre la conclusion au codebase testé. Ne pas masquer la différence en présentant une preuve d\u2019aperçu d\u2019éditeur, d\u2019exemple généré ou de prévisualisation prototype comme une observation de packaged-game.

Liste de vérification de transfert d’équipe

• Version précise d\u2019Unreal Engine, révision de projet, plugins, cible et configuration de build du projet.
• Propriétaire d\u2019état nommé pour les tests d\u2019automatisation de type unit-like et limite système avec tests d\u2019éditeur.
• Actions de reproduction pour les exemples normal, non pris en charge, interruption, voie de réparation et montée en charge.
• Journaux, traces, manifestes, captures d’écran ou captures de profiler avec identité de build et horodatages.
• Plafond de ressources de référence pour les test actors fonctionnels et les contraintes représentatives qui le justifient.
• Situations indisponibles, dépendances amont non publiques, limites de propriété de licence et inconnues connues.
• Restaurer la commande d'automatisation de chemin ou la baseline ainsi que le critère qui l'exige.

Un autre développeur doit pouvoir reproduire le résultat de ce transfert de revue sans chemins hôtes privés ni explication orale. S'il ne peut pas nommer le premier critère en échec, le lot d'enregistrement de diagnostic doit être amélioré même si la fonctionnalité de production semble fonctionner.

Frontière de transfert SEELE AI

SEELE AI peut aider un groupe de projet à comparer une direction de scène, une boucle d'interaction, un brief de contenu, une sensation de caméra ou un plan de test avant une production Unreal plus approfondie. Ce prototype amont peut clarifier le rendu joueur attendu et réduire l'ambiguïté dans l'arriéré de configuration in-project. Ce n'est pas une intégration native de plateforme ni une surface de vérification de moteur.

SEELE AI peut générer un jeu Unreal 5 natif, le prévisualiser dans le navigateur, l'optimiser et l'empaqueter, et fournir un jeu téléchargeable ou une construction empaquetée pour une publication externe ou des jeux Seele payants. Les ventes ne sont pas garanties.

Sources officielles et recommandations associées

Poursuivez via le guide [Unreal Engine Build, Test, and Shipping Guides](/resources/blogs/unreal-engine-build-test-shipping-guides-library) pour comparer ce choix à ses prérequis, ses chemins d’implémentation frères, ses dépendances de vérification et ses passages de relais de livraison. Le hub est l’index canonique de ce cluster thématique et relie chaque guide ciblé dans l’ordre du processus.

• Vue d\u2019ensemble du Gauntlet Automation Framework dans Unreal Engine | Documentation Unreal Engine 5.8 | Epic Developer Community — référence de première partie utilisée uniquement pour l’effet visible, la révision ou le chemin opérationnel qu’elle documente explicitement.
• Gauntlet Automation Framework dans Unreal Engine | Documentation Unreal Engine 5.8 | Epic Developer Community — référence de première partie utilisée uniquement pour le comportement, la branche de version ou le flux de production qu'elle documente explicitement.

Unreal Engine est une marque déposée d’Epic Games. SEELE AI est indépendant et cette page n’implique pas d’approbation, de partenariat ni d’intégration native vérifiée d’Epic Games.