Tests de développement
Comment tester le géorepérage et les fonctions iPhone basées sur la localisation
Planifiez des tests de géorepérage iOS reproductibles pour l’entrée, la sortie, les autorisations, le comportement en arrière-plan et les redémarrages, avec la simulation Xcode et une validation sur appareil physique.
Un test fiable de géorepérage iPhone définit la coordonnée centrale, le rayon, les conditions d’entrée et de sortie, l’état de l’app et l’autorisation de localisation avant l’exécution. Utilisez des localisations fixes Xcode ou des itinéraires GPX pour des tests de développement reproductibles, puis validez les autorisations, la livraison en arrière-plan, les redémarrages et le comportement réel sur un iPhone physique.
Tester un geofence iPhone ne consiste pas seulement à déplacer un marqueur de carte vers une autre ville. Un test complet vérifie l’entrée, le séjour, la sortie, l’exécution en arrière-plan, les changements d’autorisation et le comportement après un redémarrage de l’appareil. Définissez ces conditions comme des cas de test reproductibles avant de choisir la simulation Xcode ou une méthode sur appareil physique.
Qu’est-ce qu’un geofence ?
Un geofence est une condition géographique autour d’une coordonnée. Apple décrit la surveillance de conditions, aussi appelée géorepérage, comme un moyen pour une app de recevoir des événements lorsqu’un utilisateur entre dans une région géographique ou la quitte.
La documentation Apple sur la surveillance des conditions géographiques décrit une zone circulaire avec une coordonnée centrale et un rayon. Les conditions de surveillance sont des ressources système partagées, et une app ne peut pas en enregistrer un nombre illimité à la fois, donc la capacité et la priorisation appartiennent au plan de test.
Définir six paramètres avant de tester
Chaque cas de test doit enregistrer :
- la latitude et la longitude du centre ;
- le rayon du geofence ;
- si le point initial est à l’intérieur ou à l’extérieur ;
- l’entrée attendue, la sortie, ou les deux ;
- l’état de l’app : premier plan, arrière-plan, ou non en cours d’exécution ;
- l’autorisation de localisation et l’état de la Localisation précise.
Notez aussi le modèle d’iPhone, la build iOS, la build de l’app et l’heure du test. Un événement manqué ne peut pas être reproduit si ces entrées manquent.
Voie 1 : Construire des tests reproductibles avec Xcode
Pour une app que votre équipe développe, commencez par les outils de développement Apple. Le guide de simulation de localisation Xcode d’Apple explique comment un plan de test peut définir une localisation prédéterminée ou rejouer un trajet GPX avec une localisation, une élévation et une vitesse variables.
Préparez au moins trois jeux de données :
- un point de départ extérieur ;
- un point confirmé à l’intérieur de la zone ;
- un itinéraire GPX qui entre dans la zone puis en ressort.
Les tests automatisés doivent vérifier séparément l’entrée, la sortie, la suppression des doublons et le comportement en cas d’autorisation refusée. Un simulateur ne peut pas reproduire chaque fonction d’un appareil physique, donc la couverture simulateur doit être suivie d’une validation sur appareil réel.
Voie 2 : Valider sur un iPhone physique
Les tests sur appareil physique couvrent les demandes d’autorisation, la livraison en arrière-plan, l’environnement réseau réel, les ports de l’appareil et le trajet de localisation système. Apple explique que le Service de localisation peut combiner GPS, Bluetooth, points d’accès Wi‑Fi et antennes cellulaires plutôt que de dépendre d’un seul capteur.
Lorsqu’un test sur appareil réel a besoin de coordonnées répétées sur le même iPhone, un matériel externe de test de localisation peut être envisagé. HHJ Pro se connecte via Lightning ou USB-C et utilise son app compagnon pour sélectionner un point de test. Confirmez le modèle et l’état iOS avant de l’inclure dans un plan de test.
Le matériel externe ne couvre qu’une partie de l’environnement. La sortie réseau, la région du compte, l’autorisation de notification et les décisions côté serveur ont encore besoin de cas de test indépendants.
Une séquence complète de test de géorepérage
- Établir une référence : ouvrez la carte système à la localisation réelle et notez l’état des autorisations.
- Enregistrer la zone : créez une région de test avec un identifiant unique.
- Vérifier l’état initial : confirmez si l’app signale l’intérieur ou l’extérieur.
- Déclencher l’entrée : passez du point de test extérieur à un point intérieur et notez l’heure de l’événement.
- Déclencher la sortie : revenez à l’extérieur et confirmez qu’un seul événement de sortie est traité.
- Changer l’état de l’app : répétez au premier plan, en arrière-plan et à l’état non en cours d’exécution.
- Changer l’autorisation : testez Refusé, Lorsque l’app est active, Toujours et les réglages de Localisation précise selon le cas.
- Redémarrer l’appareil : vérifiez la récupération après que l’utilisateur a déverrouillé l’iPhone.
- Restaurer la référence : retirez les conditions de test et confirmez la localisation réelle dans la carte système.
Enregistrez les événements réels plutôt que de vous fier uniquement à une notification visible. Les horodatages, les identifiants de région, les journaux d’app et les journaux serveur facilitent le diagnostic des événements en double ou manquants.
Conditions limites à inclure
| Condition | Comportement attendu à vérifier |
|---|---|
| Zones petites ou adjacentes | Bruit de frontière, entrée en double et changements d’état rapides |
| Localisation précise désactivée | Gestion gracieuse d’une localisation approximative |
| Autorisation révoquée | Guidage clair et arrêt de la surveillance |
| Réseau indisponible | Séparation des événements locaux et de la synchronisation serveur |
| App en arrière-plan | Le comportement correspond à la conception du produit |
| Appareil redémarré | L’état de surveillance requis est recréé après le déverrouillage |
| iOS mis à jour | Les résultats de test précédents sont revalidés |
Un geofence n’est pas un interrupteur géométrique parfait. La précision de localisation et la planification système affectent le moment des événements, donc les exigences produit doivent prévoir une tolérance raisonnable plutôt que de traiter un événement retardé comme un échec permanent.
Erreurs courantes
Une alerte doit-elle apparaître dès qu’un point de carte traverse le cercle ?
Non. Les mises à jour de localisation, l’évaluation de région, la planification en arrière-plan et la logique de l’app peuvent tous affecter la livraison. Jugez le résultat avec des journaux et une fenêtre de temps explicite.
Un test au premier plan suffit-il ?
Non. Le géorepérage est souvent utilisé dans des flux en arrière-plan. L’autorisation, l’état en arrière-plan, la fermeture de l’app et le redémarrage de l’appareil nécessitent tous une couverture.
Changer la localisation système change-t-il aussi la région du compte ?
Non. La localisation de l’appareil, la sortie réseau, les données de compte et les règles serveur sont des signaux distincts et doivent être testés indépendamment.
HHJ Pro peut-il garantir que chaque app de géorepérage se déclenchera ?
Non. Il peut servir d’entrée de test de localisation sur un iPhone physique compatible, mais chaque app et chaque serveur contrôlent leur propre logique.
Quelle voie de test choisir ?
Utilisez d’abord Xcode et GPX pour une app que vous contrôlez et pour la régression automatisée. Ajoutez des tests sur appareil physique pour l’autorisation, l’arrière-plan et le comportement du trajet matériel. Si des points reproductibles sont nécessaires sur un iPhone physique compatible, consultez la page de compatibilité HHJ Pro et le guide de configuration.
Utilisez des comptes de test dédiés et des données de test non sensibles. N’appliquez pas un flux QA pour falsifier une présence, tromper un service ou contourner des contrôles de sécurité.