Meilleure façon de tester des cas simples dans les jeux

Lors de la conception et du test d'un nouveau jeu, la plupart du temps, les gens qui essaient la fonctionnalité s'habituent aux choses et n'essayent plus les "moyens stupides". Donc, si le développement casse quelque chose, cela peut être une fonctionnalité que seul un nouvel utilisateur prendrait la peine d'essayer. Quelles sont les meilleures façons de s'assurer que votre jeu a ses "cas stupides" testés quand il est finalement sorti, ou après une mise à jour majeure? Méthodologie, assistance logicielle, peut-être même des sites où les gens joueront pour vous, et ceteras.

Je dirais que certaines choses sont importantes:

Encourager les tests unitaires du programmeur

Cela garantira que certains bogues stupides, s'il y a un test unitaire pour eux, ne se reproduiront pas, car le test unitaire échouera s'ils le font. Cela nécessite un changement de méthodologie de programmation, mais à mon avis, cela en vaut la peine.

Automatisez tous les tests que vous pouvez

Au-delà des tests unitaires, créez un ensemble de tests de fonction et d'acceptation automatisés qui sont exécutés sur chaque build pour vous assurer que certaines builds sont bonnes. Si vous avez des contrôles scriptables et que votre jeu est généralement cohérent, vous pouvez tester de nombreux bugs automatiquement.

Créer un plan de test à plusieurs niveaux

Assurez-vous que vos testeurs ont un plan de test qui teste les bogues les plus importants. Cela devrait être à plusieurs niveaux:

• Test de fumée: teste que le jeu ne plante pas dans les cas les plus courants.
• Test régulier: teste des cas plus rares.
• Test de trempage: exécutez aussi profondément que possible, régressant autant de bugs courants que possible. Testez également que le jeu peut rester en place pendant de très longues périodes (jours) sans se bloquer.

Créez ce plan de test et suivez-le sur chaque build.

Une sorte d'approche de couverture de code pour les cas de test peut être effectuée à l'aide de simples indicateurs qui sont déclenchés une fois que le bloc de code a été exécuté dans le jeu. L'affichage des indicateurs qui ont été déclenchés et non déclenchés à l'écran peut permettre aux testeurs de savoir quels cas ont été couverts et lesquels ne l'ont pas été.

Aussi simple soit-il, il est toujours efficace tant que les drapeaux ont des noms significatifs afin que les testeurs puissent comprendre ce qui est censé être fait.

Cette technique est attribuée à Matthew Jack qui l'a implémentée dans Crysis.

Plusieurs bonnes réponses ici sur le plan de la programmation. J'en ajouterai un plus orienté design.

Demandez à vos concepteurs de systèmes d'écrire des plans de test de cas de pointe pour les testeurs

S'ils savent ce qu'ils font, la personne derrière la conception d'un système ou le script d'une séquence dans le jeu est très susceptible de connaître les cas limites de ce système et où il pourrait tomber en panne. Ils devraient également avoir une idée de l'endroit où le système interagit avec les autres. Leur faire rédiger un plan de test ou discuter avec les testeurs des situations susceptibles de mal tourner peut faire gagner du temps à tout le monde.

Vous devriez enquêter sur les tests de singe. Il peut attraper de nombreux bugs de ce type:

https://secure.wikimedia.org/wikipedia/en/wiki/Monkey_test

Vous devez également organiser des tests d'expérience utilisateur avec des "testeurs Kleenex", des testeurs qui voient votre jeu pour la première fois et que vous ne réutiliserez plus jamais. C'est un peu cher et compliqué à organiser, mais ça vaut bien l'effort. Si vous le faites, filmez chaque test avec 3 caméras: une sur l'écran, une sur les commandes et une sur le visage du testeur afin de détecter la frustration.

Grande question, chaque réponse dans ce fil est une excellente réponse. Une chose à ajouter:

D'après mon expérience (30 ans de développement de logiciels): les applications et les jeux sont plus fiables si au moins un membre du groupe de test est un testeur de gorilles qualifié , maîtrisant les tests ad hoc, abusant des applications et utilisant délibérément des jeux de la mauvaise façon pour trouver bogues du type décrit par l'affiche originale. Les testeurs de gorilles ont une compétence rare - lorsque vous en trouvez une bonne, gardez-les dans votre équipe.

Pour un exemple de test efficace des gorilles, voir: www.youtube.com/watch?v=8C-e96m4730;)

Pour résumer les réponses dans ce fil: les stratégies de qualité logicielle efficaces sont multiples , combinant plusieurs approches pour atteindre un haut niveau de confiance dans la qualité fonctionnelle et la fiabilité de votre jeu.

Un truc intéressant dont j'ai entendu parler par un ami pour tester les graphiques; au cours d'une bonne exécution connue d'un niveau record de statistiques de performances du GPU à intervalles réguliers (polys à l'écran par exemple). Vous pouvez ensuite rejouer cette route et si les nombres changent en dehors d'une tolérance donnée, cela peut signifier que quelque chose ne s'affiche plus correctement.

Une chose simple et simple qui aide beaucoup, en particulier avec les tests de stress et les tests de réseau. Permettez à votre IA de jouer contre d'autres IA. Si vous pouvez laisser votre jeu seul jouer lui-même, ou un petit groupe d'IA sur un réseau pendant un week-end, vous pouvez en apprendre beaucoup.

Bien sûr, enregistrez tout.