📚 Formation

← QA Mobile : principes, métier et pratique

Explorer les logs cloud pour aider l'équipe

≈ 25 minutes · Jalon M4 · Prérequis : Automatiser les tests mobiles : Appium, Espresso, XCUITest

Le gain du jour : retrouver dans les logs cloud la trace exacte d’un bug que tu viens de reproduire, et joindre à ton rapport la preuve qui fait gagner une heure au développeur.

Un log cloud, c’est quoi ?

Un log est une ligne horodatée qu’un programme écrit pour dire ce qu’il fait : « requête reçue », « paiement refusé », « exception levée ». Ton app mobile parle à des serveurs (l’API, l’authentification, le paiement). Chacun de ces serveurs écrit ses logs. Dans le cloud, ces lignes ne restent pas sur une machine. Elles sont envoyées vers un service de logs centralisé où l’on peut les chercher toutes au même endroit.

Les plus courants : Google Cloud Logging (son écran de recherche s’appelle le Logs Explorer), AWS CloudWatch Logs, Azure Monitor, Datadog. Les noms changent, la démarche est la même. Les exemples de cette leçon utilisent le Logs Explorer de Google Cloud.

Trois sources de logs à ne pas confondre

Pourquoi un testeur QA s’en sert

Tu vois l’écran. Le développeur voit le code. Les logs cloud montrent ce qui s’est passé entre les deux. On construit le chemin en trois étapes.

D’abord, ton action sur l’app part vers le serveur :

 📱 App (toi, testeur)  ──── requête HTTP ────▶  ☁️ API

Ensuite, le serveur écrit ce qu’il a reçu et ce qu’il a répondu dans le service de logs :

 📱 App  ──── requête ────▶  ☁️ API
                               │
                               ▼  écrit
                        🗂 Service de logs
                    (timestamp, severity, message, requestId)

Enfin, toi tu vas lire ces logs et tu joins l’extrait au bug :

 📱 App  ──── requête ────▶  ☁️ API
   │                           │
   │ note l'heure +            ▼  écrit
   │ le compte de test   🗂 Service de logs
   │                           │
   └──────▶ 🔎 Logs Explorer ◀─┘
                 │
                 ▼
            🐞 Bug JIRA  + extrait de log + lien vers la requête

Concrètement, les logs te permettent de répondre à une question que le développeur va poser de toute façon : le problème vient-il de l’app ou du serveur ?

Ce que tu vois dans les logsCe que ça veut direÀ qui l’envoyer
Aucune requête à l’heure du testLa requête n’est jamais partie (ou pas vers ce serveur)Équipe mobile
Requête reçue, réponse 4xx (400, 401, 404, 422)Le serveur a refusé ce que l’app a envoyéSouvent mobile, à vérifier avec le back
Requête reçue, réponse 5xx (500, 502, 503)Le serveur a planté ou un service derrière luiÉquipe back-end
Réponse 200 mais une ligne ERROR juste aprèsErreur silencieuse : l’écran dit OK, le serveur nonÉquipe back-end, bug souvent sévère
Réponse 200 correcte, mais l’app affiche fauxLe serveur a bien répondu, l’app interprète malÉquipe mobile

L’anatomie d’une entrée de log

Dans le Logs Explorer, chaque ligne se déplie en un objet structuré. Les champs qui comptent pour toi :

{
  "timestamp": "2026-11-05T09:42:17.318Z",
  "severity": "ERROR",
  "resource": { "type": "cloud_run_revision", "labels": { "service_name": "api-panier" } },
  "httpRequest": { "requestMethod": "POST", "requestUrl": "/v1/panier/items", "status": 500 },
  "jsonPayload": {
    "message": "quantity must be >= 0",
    "userId": "qa-test-042",
    "appVersion": "3.2.1"
  },
  "trace": "projects/mon-projet/traces/4bf92f3577b34da6a3ce929d0e0e4736"
}

Chercher : du large au précis

Le Logs Explorer a deux réglages : une fenêtre de temps (en haut) et une requête dans le langage de requête de Cloud Logging. La bonne méthode est de partir large puis de resserrer.

1. Les erreurs autour de ton test. Règle la fenêtre sur 15 minutes autour de l’heure notée, puis :

severity>=ERROR

2. Seulement le service concerné.

resource.labels.service_name="api-panier"
severity>=WARNING

Deux lignes sur deux lignes séparées sont reliées par un AND implicite.

3. Seulement ton compte de test.

resource.labels.service_name="api-panier"
jsonPayload.userId="qa-test-042"

4. Un mot que tu as vu à l’écran, sans savoir dans quel champ il se trouve :

SEARCH("quantity")

SEARCH ignore la casse et cherche des mots entiers. Pour un bout de texte dans un champ précis, utilise une expression régulière avec =~ :

jsonPayload.message =~ "(?i)quantit"

5. Toute l’histoire d’une requête. Clique sur une ligne intéressante, copie sa valeur trace, puis :

trace="projects/mon-projet/traces/4bf92f3577b34da6a3ce929d0e0e4736"

Tu vois alors toutes les lignes de cette requête, dans l’ordre, dans tous les services qu’elle a traversés.

Astuces de terrain

Ce que le QA peut faire pour aider l’équipe

Au-delà de lire les logs, tu es bien placé pour les améliorer, parce que tu es souvent le premier à essayer de s’en servir sur un vrai problème.

Vérifie ta compréhension

Tu valides un paiement dans l'app. L'écran affiche « Paiement réussi ». Dans les logs, la requête a un statut 200, puis une ligne ERROR « échec d'envoi du reçu » apparaît avec le même trace. Que fais-tu ?

Tu as reproduit un bug à 10 h 42 heure de Paris (hiver, UTC+1). Quelle fenêtre de temps règles-tu dans le Logs Explorer si l'outil affiche l'UTC ?

À toi de jouer

  1. Demande un accès en lecture seule aux logs de l’environnement de test (sur Google Cloud : roles/logging.viewer).

  2. Reproduis un parcours avec ton compte de test, note l’heure, puis retrouve tes requêtes avec jsonPayload.userId=”…” (adapte le nom du champ à ton projet).

  3. Ouvre une ligne, copie son trace et affiche toute l’histoire de la requête.

  4. Ajoute une ligne « Logs (trace + lien) » à ton modèle de bug report.

🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.