Gains :
- Capacité à produire des tests unitaires, d'intégration et d'interface utilisateur avec l'intelligence artificielle conformément à la pyramide des tests et couvrir les situations de limites et d'erreurs ainsi que les scénarios heureux
- Possibilité d'éliminer les tests vides/inutiles et la couverture gonflée en vérifiant que chaque test généré valide réellement un comportement
- S'assurer que le test détecte le bug et l'empêche de le corriger en indiquant à l'IA ce que le code doit faire
L'écriture de code représente la moitié du travail ; Prouver que le code fonctionne correctement est l’autre moitié. Les applications mobiles sont confrontées à des centaines d'appareils, de tailles d'écran, de versions de système d'exploitation et de comportements d'utilisateurs différents. Il est impossible de tester tout cela manuellement ; C'est pourquoi les tests automatisés (code de test de code – tests qui s'exécutent sans clic humain) constituent l'épine dorsale de la qualité mobile. L'IA est incroyablement efficace pour écrire des tests, car l'écriture de tests est exactement le type de travail de modèle qu'elle aime : valider un comportement spécifique pour des entrées spécifiques. Dans cette unité, nous apprendrons comment accélérer les tests unitaires, les tests d'interface et l'automatisation avec l'IA, tout en garantissant la qualité du test à travers l'œil humain.
Pyramide des tests : quoi tester et combien
Une stratégie de tests sains ressemble à une pyramide. La base comprend un grand nombre de tests unitaires (tests rapides qui testent une seule fonction ou classe de manière isolée) ; ils sont rapides et bon marché. Au milieu se trouvent moins de tests d'intégration (tester la manière dont plusieurs parties fonctionnent ensemble). En haut, il y a un minimum de tests d'interface utilisateur/de bout en bout (tests effectués en cliquant sur l'écran comme le fait l'utilisateur) ; ils sont réalistes mais lents et fragiles. L’IA est utile à chaque niveau, mais la plus grande valeur se trouve à la base : produire rapidement des tests unitaires de logique métier.
Type d'essai
Portée
vitesse
Efficacité de l'IA
tests unitaires
Fonction/classe unique
très vite
très élevé
intégration
intercalaire
moyen
haut
UI / de bout en bout
Flux sur tout l'écran
lent
Moyen (fragile)
Astuce : lorsque vous demandez à l'IA de "générer des tests pour cette fonction", demandez explicitement les cas extrêmes : entrée vide, valeur nulle, nombre négatif, valeur très grande, erreur réseau. L'IA produit facilement un chemin heureux ; Les vraies erreurs se cachent dans les frontières et ressortent si vous ne voulez pas qu'elles s'y trouvent.
Étapes d'écriture de tests avec l'IA
- Définir le comportement à tester. "Cette fonction devrait donner cette sortie à cette entrée."
- Précisez le cadre. JUnit + MockK sur Android, XCTest sur iOS, Espresso (Android) ou XCUITest (iOS) pour l'interface utilisateur.
- Demandez les états limites. Scénario heureux + erreur + points d'arrêt.
- Gérez les objets fictifs. Les dépendances externes telles que le réseau et la base de données sont émulées pour les tests (simulation – simulation contrôlée au lieu du service réel).
- Exécutez le test et vérifiez. Le test réussit-il, confirme-t-il quelque chose de vraiment significatif ?
La cinquième étape est cruciale. L’IA produit parfois des tests inutiles qui « réussissent toujours » ; par exemple, un test qui ne vérifie rien ou vérifie ses propres fausses données. Un test réussi et un test utile sont des choses différentes.
Attention : Ce n'est pas parce que l'IA peut produire que le test est correct. Parfois, l'IA accepte le comportement actuel (peut-être défectueux) du code comme « correct » et écrit des tests en conséquence. De tels tests corrigent le bug plutôt que de le détecter. Vous déterminez ce que le test attend ; Dites à l'IA ce qu'elle doit faire, pas ce que fait le code.
Mesure de couverture des tests et erreur
La couverture des tests (quel pourcentage de code est exécuté par les tests) est une mesure utile mais trompeuse. Une couverture de 90 % indique que 90 % du code a été exécuté ; mais il n'a pas été vérifié que ces lignes fonctionnent correctement. Un test qui exécute une ligne et ne vérifie pas le résultat gonfle la portée mais n'assure pas la sécurité. L’objectif n’est pas des chiffres élevés, mais une validation significative. Vous pouvez rapidement évoluer avec l’IA, mais assurez-vous que chaque test teste réellement un comportement.
trois mini-cases
Cas 1 — Situation frontalière détectée. L'IA a été sollicitée pour tester une fonction de transfert d'argent dans une application bancaire, et des scénarios spécifiques de « montant négatif » et « supérieur au solde » ont été ajoutés. Le test a révélé que le virement n’était pas bloqué avec un montant négatif ; cela constituerait une faille de sécurité majeure en production. Fermé en ajoutant un contrôle d'une ligne. Leçon : les tests aux limites sont les tests les plus précieux.
Cas 2 — Faux test. Une équipe a été soulagée d’augmenter la couverture à 85 % avec 40 tests unitaires produits par l’IA. Lors de l'inspection, il a été constaté que la plupart des tests ne vérifiaient aucune sortie, ils appelaient simplement la fonction et écrivaient assertTrue(true). La couverture était élevée mais la protection était nulle. Les tests ont été révisés et réécrits avec de vraies validations. Leçon : les chiffres de couverture peuvent mentir.
Cas 3 – Les tests de l’interface utilisateur sont accélérés. Une équipe de commerce électronique a écrit un script XCUITest du flux d'ajout au panier avec l'IA en 20 minutes ; Si c’était écrit à la main, cela prendrait une demi-journée. L'IA a deviné les identifiants des éléments d'écran ; L'équipe les a comparés avec le vrai code et les a corrigés. La vitesse de rédaction est réelle, mais la vérification des identifiants est un travail humain.
Invite faible/Invite forte
Invite faible : "Écrivez un test pour cette fonction."
Invite puissante : "Produisez des tests unitaires pour cette fonction Kotlin avec JUnit5 + MockK. Fonction : transfert d'argent (montant, source, cible). Comportements à tester (ce que le code doit faire) : - Le transfert valide doit réussir - Un montant négatif ou nul doit être rejeté - Un montant supérieur au solde doit être rejeté - Une erreur réseau doit lever une exception appropriée. Chaque test ne doit vérifier qu'une seule chose, leurs noms doivent être descriptifs, se moquer du service externe. N'écrivez pas une assertion vide. "
Modèles copiables
Modèle de test unitaire : "Générer des tests unitaires [JUnit/XCTest] pour cette fonction pour [langue]. Comportement attendu : [que faire]. Inclure : un scénario heureux, une entrée nulle, des points d'arrêt, un cas d'erreur. Laissez chaque test vérifier un comportement unique ; utiliser une assertion significative ; simuler. [code]"
Modèle de test d'interface utilisateur : "Écrivez un test d'interface utilisateur du flux suivant avec [Espresso/XCUITest] : [flux utilisateur étape par étape]. Sélectionnez les éléments d'écran avec l'identifiant d'accessibilité, utilisez l'identifiant au lieu du texte. Ajoutez une stratégie d'attente. Rappelez-moi de faire correspondre les identifiants des éléments au code réel. "
Modèle d'audit de test : "Examinez ces tests : 1) Vérifient-ils réellement une sortie/un comportement ou sont-ils nuls ? 2) Couvrent-ils des cas limites ? 3) Corrigent-ils le code ou s'attendent-ils à un comportement correct ? Signalez et renforcez les tests faibles. [tests]"
Modèle d'optimisation de couverture : "Identifiez les parties non testées de cette classe et suggérez des tests significatifs. Donnez la priorité aux chemins présentant un risque réel, pas seulement le nombre de couvertures. [code]"
Erreurs courantes
- Je teste juste le scénario heureux. Les erreurs sont stockées dans des états limites ; Demandez-les ouvertement.
- Accepter un test vide/inutile. Les tests de type assertTrue(true) gonflent la portée et n'offrent aucune protection.
- Demander à l'IA de vérifier ce que fait le code. Les tests doivent s'attendre à ce que le code doit faire ; sinon cela corrige le bug.
- Confondre le numéro de portée avec le but. Une couverture de 90 % ne signifie pas une précision de 90 %.
- Lien vers le texte dans les tests de l'interface utilisateur. Le test est interrompu lorsque le texte change ; Utilisez un identifiant stable (id).
- Configuration incorrecte des simulations. Le « test unitaire » qui appelle le service réel sera lent et fragile.
En résumé
Les tests sont l’épine dorsale de la qualité mobile, et l’IA est très efficace dans ce domaine, notamment dans les tests unitaires. Suivez la pyramide des tests : de nombreuses unités, une intégration moyenne, peu de tests d'interface utilisateur. Demandez explicitement à l'IA le scénario heureux ainsi que les cas limites et les chemins d'erreur. Assurez-vous que chaque test généré valide réellement un comportement ; Les tests vides et la couverture gonflée sont trompeurs. Plus important encore, dites à l'IA ce que le code doit faire, pas ce qu'il fait, afin que le test détecte le bogue et ne le corrige pas.
Tâche de candidature
Demandez des tests à l'IA à l'aide du « Modèle de test unitaire » pour une fonction de logique métier (par exemple, calcul de remise ou validation de formulaire) et spécifiez explicitement les cas limites (nul, négatif, trop grand). Exécutez les tests générés, puis faites auditer les mêmes tests avec le « Modèle d'audit de test ». Trouvez au moins un test faible, renforcez-le et testez si les tests détectent une erreur réelle de la fonction (en ajoutant un petit bug).
liste de contrôle
- [ ] J'ai sélectionné la couche appropriée pour la pyramide de test (unité prioritaire)
- [ ] Je voulais des cas limites et des erreurs en plus du scénario heureux
- [ ] J'ai vérifié que chaque test contient une assertion significative
- [ ] J'ai dit à l'IA ce que le code devait faire, pas ce qu'il faisait
- [ ] Je me suis concentré sur les chemins de risque réels, pas sur le nombre de couvertures
- [ ] J'ai utilisé un identifiant stable dans les tests d'interface utilisateur, je ne me suis pas lié au texte