Présentation de Camera ITS

La suite de tests d'images de l'appareil photo (ITS) est un framework permettant d'exécuter des tests sur les images produites par un appareil photo Android. L'objectif général de chaque test ITS est de configurer l'appareil photo d'une manière spécifique, de prendre une ou plusieurs photos et de les examiner pour voir si elles contiennent les données d'image attendues. Pour de nombreux tests, l'appareil photo doit être pointé vers un graphique cible spécifique ou être éclairé à une intensité spécifique.

ITS se trouve dans le testeur CTS Verifier sous cts/apps/CameraITS. Les appareils doivent réussir les tests ITS correspondant aux fonctionnalités compatibles annoncées par le framework de l'appareil photo pour les applications tierces en tant que sous-ensemble de CTS.

Configuration

Pour exécuter les tests ITS, les éléments suivants doivent être configurés :

  • Un appareil testé
  • Une machine hôte (par exemple, un ordinateur de bureau ou un ordinateur portable Linux)
  • Une scène photographiée par l'appareil photo

Configuration de l'appareil testé

Pour configurer un appareil testé, procédez comme suit :

  1. Connectez l'appareil testé à une machine hôte via USB.
  2. Configurez les options pour les développeurs sur l'appareil testé :
    • Activez Rester éveillé et Débogage USB.
    • Désactivez Mises à jour automatiques du système et Vérifier les applications via USB.
  3. Accordez à l'hôte l'autorisation d'accéder à l'appareil testé via ADB.

  4. Installez l'application CTS Verifier (CtsVerifier.apk) sur l'appareil. Pour en savoir plus, consultez Utiliser CTS Verifier.

    extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
cd android-cts-verifier
adb install -r -g CtsVerifier.apk

  5. Sur l'appareil testé, lancez l'application d'appareil photo par défaut et fermez toutes les fenêtres qui s'affichent au lancement pour éviter toute interférence pendant les tests.

Configuration de l'hôte

ITS nécessite que la machine hôte soit connectée à l'appareil testé via USB, qu'elle puisse utiliser ADB pour le contrôle et la communication de l'appareil, et que le logiciel requis soit installé.

Pour configurer votre machine hôte, assurez-vous que le logiciel suivant est installé.

Outils de plate-forme du SDK Android

Les outils de plate-forme du SDK Android doivent être installés et ADB doit se trouver dans le chemin exécutable du shell ou du terminal qui s'exécute sur la machine hôte. Pour la version publique des outils de plate-forme du SDK Android, consultez les notes de version des outils de plate-forme du SDK.

Python

Python doit être installé sur la machine hôte. Nous vous recommandons d'utiliser une distribution Python groupée pour assurer la compatibilité avec les versions compatibles. Pour savoir quelles versions de Python et de package installer pour une version spécifique, consultez les notes de version de Camera ITS pour la version correspondante.

Mobly

Pour Android 12 et versions ultérieures, installez le framework de test Mobly. Mobly vous permet de configurer un appareil testé et un graphique sur tablette dans la classe its_base_test. Pour installer le framework de test Mobly, exécutez la commande suivante :

pip install mobly

Configuration de l'environnement

Pour configurer l'environnement de test, exécutez la commande suivante :

cd CameraITS
source build/envsetup.sh

Cette commande vérifie l'installation de Python, configure la variable d'environnement PYTHONPATH et exécute des tests unitaires sur les modules utils/*.py. Si aucune erreur n'est affichée dans le terminal, l'environnement est prêt à exécuter les tests ITS.

Configuration de la scène

Pour configurer les scènes, nous vous recommandons d'utiliser la configuration Camera ITS-in-a-box pour faciliter l'automatisation, la fiabilité et l'efficacité des tests. Les bancs d'essai ITS-in-a-box sont compatibles avec toutes les exigences d'éclairage, de centrage et de changement de graphique pour ITS. De plus, ITS-in-a-box est requis pour les tests d'extensions de l'appareil photo.

Pour les tests manuels, assurez-vous des points suivants :

  • L'appareil testé est sur un trépied.
  • L'appareil testé est pointé vers la scène appropriée pour chaque test. Le script du test ITS fournit des invites pour modifier la configuration de la scène avant de commencer les tests dans une nouvelle scène.
  • L'appareil testé est connecté à la machine hôte via USB.
  • L'appareil testé ne bouge pas pendant l'exécution du test.
  • La scène est éclairée par une source de lumière stable et non fluctuante. (N'utilisez pas de lumière fluorescente, car cela introduit un scintillement.)

Le script de test ITS affiche une invite demandant à l'utilisateur de modifier la configuration de la scène avant de commencer les tests dans une nouvelle scène.

L'orientation du téléphone doit être définie de sorte que l'appareil photo prenne des images sans rotation. Le moyen le plus simple de vérifier cela consiste à utiliser les scènes de visage dans la scène 2. Sur la plupart des téléphones, l'orientation est en mode paysage, le téléphone étant tourné dans le sens inverse des aiguilles d'une montre pour la caméra arrière et dans le sens des aiguilles d'une montre pour la caméra avant.

Fichiers de configuration

À l'aide du framework Mobly, vous devez créer un fichier de configuration config.yml pour définir le banc d'essai Mobly. Vous trouverez ci-dessous des exemples pour différents cas d'utilisation.

Fichier config.yml des scènes basées sur une tablette

Voici un exemple de fichier config.yml pour les scènes basées sur une tablette. Pour les tests basés sur une tablette, le mot clé TABLET doit figurer dans le nom du banc d'essai. Lors de l'initialisation, le testeur Mobly initialise les paramètres du fichier et les transmet aux tests individuels.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # "True" or "False"; quotes needed
      lighting_cntl: <controller-type>  # "arduino" or "None"; quotes needed
      lighting_ch: <controller-channel>
      camera: 0
      foldable_device: "False". # set "True" if testing foldable
      scene: <scene-name>  # if <scene-name> runs all scenes

Pour appeler le banc d'essai, exécutez tools/run_all_tests.py. Si aucune valeur de ligne de commande ne spécifie d'appareils photo ou de scènes, le test est exécuté avec les valeurs du fichier config.yml. S'il existe des valeurs de ligne de commande pour les appareils photo ou les scènes, elles remplacent les valeurs de la section TestParams du fichier config.yml. Exemple :

python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=0 scenes=scene_tele
python tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele

Paramètre chart_scaling

Dans Android 17 et versions ultérieures, le paramètre chart_scaling est inclus dans config.yml pour TEST_BED_TABLET_SCENES. Ce paramètre résout les problèmes de mise à l'échelle des graphiques pour les appareils photo télé avec un champ de vision plus large, empêchant le recadrage de la scène et garantissant une mise au point correcte de l'appareil pendant les tests.

Les valeurs compatibles pour chart_scaling sont 1, 0.33, 0.5 ou 0.67, avec None comme valeur par défaut. Cette approche permet aux appareils d'utiliser un facteur de mise à l'échelle optimal adapté à leurs exigences spécifiques, tout en maintenant des tests fonctionnels sur tous les appareils.

Si chart_scaling est défini sur None, les tests déterminent automatiquement le facteur de mise à l'échelle à l'aide de chart_scaling_logic. Sinon, la valeur spécifiée dans config.yml est utilisée, ou une erreur est signalée si la mise à l'échelle n'est pas disponible.

Voici un exemple de config.yml avec le paramètre chart_scaling.

TestBeds:
  -   Name: TEST_BED_TABLET_SCENES  # Need 'tablet' in name for tablet scenes
    # Use TEST_BED_MANUAL for manual testing and remove below lines:
    #     - serial <tablet_id>
    #       label: tablet
    # Test configuration for scenes[0:4, 6]
    Controllers:
        AndroidDevice:
          -   serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
          -   serial: <tablet-id>  # quotes needed if serial id entirely numeric
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"  # quotes needed
      lighting_cntl: <controller-type>  # can be arduino or "None"
      lighting_ch: <controller-channel>
      camera: <camera-id>
      scene: <scene-name>  # if <scene-name> runs all scenes
      foldable_device: "False"  # "True" if testing foldable device
      chart_scaling: "None"  # use the values available for scene to be tested
      resultstore_upload: "False"  # "True" if results should be uploaded to ResultStore

Des ajustements côté test sont nécessaires pour activer les fonctionnalités de mise à l'échelle des graphiques ITS de l'appareil photo. Si un test que vous utilisez n'est pas compatible, signalez un bug.

Voici un exemple de modification côté test avec le paramètre chart_scaling.

# load chart for scene
      its_session_utils.load_scene(
          cam, props, self.scene, self.tablet, self.chart_distance,
          chart_scaling=self.chart_scaling)

Fichier config.yml de la scène sensor_fusion

Voici un exemple de fichier config_yml pour les tests sensor_fusion. Pour les tests sensor_fusion, le mot clé SENSOR_FUSION doit figurer dans le nom du banc d'essai. Android 13 et versions ultérieures ne sont compatibles qu'avec le contrôleur Arduino pour la fusion de capteurs en raison des tests de prévisualisation et de stabilisation vidéo. Android 12 est compatible avec les contrôleurs Arduino et Canakit.

Testbeds
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino
      rotator_ch: 1
      camera: 0

Pour exécuter les tests sensor_fusion avec le boîtier de fusion de capteurs, exécutez la commande suivante :

python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

Fichier config.yml de plusieurs bancs d'essai

Voici un exemple de fichier config.yml avec plusieurs bancs d'essai, un banc d'essai pour tablette et un banc d'essai sensor_fusion. Le banc d'essai approprié est déterminé par les scènes testées.

Testbeds
  - Name: TEST_BED_TABLET_SCENES
    # Test configuration for scenes[0:4, 6, _change]
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut
          - serial: 5B16001229
            label: tablet

    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      chart_loc_arg: ""
      camera: 0
      scene: <scene-name>           # if <scene-name> runs all scenes

  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion/test_sensor_fusion.py
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: arduino         # cntl can be arduino or canakit
      rotator_ch: 1
      camera: 0

Fichier config.yml des tests manuels

Voici un exemple de fichier config.yml pour les tests manuels. Android 14 et versions ultérieures sont compatibles avec les tests manuels pour tous les tests, à l'exception des scene_extensions tests. Pour les tests manuels, le mot clé MANUAL doit figurer dans le nom du banc d'essai. De plus, la section AndroidDevice ne peut pas inclure de section de numéro de série ou de libellé pour une tablette.

TestBeds:
  - Name: TEST_BED_MANUAL
    Controllers:
        AndroidDevice:
          - serial: 8A9X0NS5Z
            label: dut

    TestParams:
      debug_mode: "False"
      camera: 0
      scene: 1

Fichier config.yml des tests de banc d'essai Gen2

Voici un exemple de fichier config.yml d'un banc d'essai TEST_BED_GEN2. Ce banc d'essai est utilisé pour les tests scene_ip, qui utilisent un banc d'essai Gen2](/docs/compatibility/cts/camera-its-box-gen2). L'exemple suivant montre les paramètres du banc d'essai lorsque le banc d'essai Gen2 est disponible et les scene_ip tests ne sont pas ignorés.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: gen2_rotator   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: 0
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: gen2_lights  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: 1
      scene: scene_ip

L'exemple suivant montre les paramètres du banc d'essai lorsque le banc d'essai Gen2 n'est pas disponible et que les tests scene_ip sont ignorés.

Testbeds
  - Name: TEST_BED_GEN2
    # Test configuration for scene_ip/test_default_jca_ip.py
    Controllers:
        AndroidDevice:
          - serial: <device-id>  # quotes needed if serial id entirely numeric
            label: dut
    TestParams:
      debug_mode: "False"  # quotes are needed here
      chart_distance: 30
      rotator_cntl: "None"   # gen2 rig specific. "None" if gen2 rig not available
      rotator_ch: <controller-channel>
      camera: <camera-id>
      foldable_device: "False"  # "True" if testing foldable device
      tablet_device: "False"  # "True" if testing tablet device
      lighting_cntl: "None"  # gen2 rig specific. "None" if gen2 rig not available
      lighting_ch: <controller-channel>
      scene: scene_ip

Pour exécuter le test scene_ip, utilisez l'une des commandes suivantes :

python tests/scene_ip/test_default_jca_ip.py -c config.yml
python tools/run_all_tests.py camera=<camera-id> scenes=scene_ip

Exécuter les tests ITS

Cette section explique comment exécuter les tests ITS.

Appeler des tests

Une fois l'appareil, la machine hôte (y compris l'environnement) et la scène physique configurés, exécutez les tests ITS à l'aide de la procédure suivante.

  1. Ouvrez l'application CTS Verifier. Dans le menu des tests, sélectionnez Camera ITS Test (Test ITS de l'appareil photo). Pour Android 17 et versions ultérieures, les tests sensor_fusion et feature_combination se trouvent dans une activité supplémentaire nommée Camera ITS Sensor Fusion Rig Test (Test de banc d'essai de fusion de capteurs ITS de l'appareil photo).

  2. À partir de la machine hôte, exécutez les tests ITS à partir du répertoire CameraITS/. Par exemple, pour un appareil équipé de caméras avant et arrière, exécutez la commande suivante :

    python tools/run_all_tests.py

    Le script itère sur les appareils photo et les scènes de test en fonction du fichier config.yml. Pour les configurations de débogage, nous vous recommandons d'exécuter l'une des scènes scene2 avec un seul test pour un délai d'exécution plus rapide.

    Pour les tests manuels, avant de commencer à exécuter l'ensemble des tests ITS sur chaque scène, le script prend une photo de la scène actuelle, l'enregistre au format JPEG, affiche le chemin d'accès au JPEG dans la console et demande à l'utilisateur de confirmer si l'image est correcte. Ce flux de capture et de confirmation se répète jusqu'à ce que l'utilisateur confirme que l'image est correcte. Voici les messages de ce flux.

    Preparing to run ITS on camera 0
Start running ITS on camera:  0
Press Enter after placing camera 0 to frame the test scene:
scene1_1
The scene setup should be: A grey card covering at least the   middle 30% of the scene
Running vendor 3A on device
Capture an image to check the test scene
Capturing 1 frame with 1 format [yuv]
Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg
Is the image okay for ITS scene1_1? (Y/N)

    Chaque exécution du script affiche un journal indiquant PASS, FAIL, FAIL* ou SKIP pour chaque test ITS. FAIL* indique que le test a échoué, mais comme il n'est pas encore obligatoire, il sera signalé comme PASS à CtsVerifier. SKIP indique que le test a réussi, car l'appareil n'a pas annoncé la fonctionnalité sous-jacente testée. Par exemple, si un appareil n'annonce pas via les interfaces de l'appareil photo qu'il est compatible avec le format DNG, les tests liés à la capture de fichiers DNG sont ignorés et comptabilisés comme PASS.

  3. Pour confirmer que les tests ont satisfait aux exigences, appuyez sur le bouton de coche verte. L'entrée Camera ITS Test (Test ITS de l'appareil photo) dans le menu des tests CTS Verifier devient alors verte et indique que le téléphone a réussi le test ITS de l'appareil photo.

Tests parallèles sur l'appareil testé

Les appareils équipés d'Android 14 ou version ultérieure sont compatibles avec les tests parallèles sur l'appareil testé. Cela vous permet de tester les appareils testés en parallèle avec plusieurs bancs d'essai pour accélérer les tests globaux. Par exemple, les tests parallèles vous permettent de tester l'appareil photo 0 dans un banc d'essai et l'appareil photo 1 dans un autre banc d'essai en même temps. Pour Android 17 et versions ultérieures, étant donné que les tests ITS de l'appareil photo sont divisés en deux activités, vous pouvez exécuter les tests sensor_fusion et feature_combination sur un appareil testé, et d'autres tests sur un autre appareil testé en parallèle. Tous les tests des sessions de test parallèles sont agrégés dans la session CTS Verifier sur l'appareil testé de référence. Vous devez exécuter des tests parallèles avec le contrôle d'éclairage Arduino, car le contrôle d'éclairage manuel n'est pas compatible avec les tests parallèles. Assurez-vous qu'un canal différent sur le même contrôleur Arduino contrôle l'éclairage de chaque banc d'essai.

Voici un exemple de fichier config.yml qui définit trois bancs d'essai à exécuter en parallèle.

TestBeds:
  - Name: TEST_BED_TABLET_SCENES_INDEX_0
    Controllers:
        AndroidDevice:
          - serial: <device-id-0>
            label: dut
          - serial: <tablet-id-0>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-0>
      camera: 0
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  - Name: TEST_BED_TABLET_SCENES_INDEX_1
    Controllers:
        AndroidDevice:
          - serial: <device-id-1>
            label: dut
          - serial: <tablet-id-1>
            label: tablet
    TestParams:
      brightness: 192
      chart_distance: 22.0
      debug_mode: "False"
      lighting_cntl: "arduino"
      lighting_ch: <controller-channel-1>
      camera: 1
      scene: <scene-name>  # if <scene-name> left as-is runs all scenes
      foldable_device: "False"

  # TEST_BED_SENSOR_FUSION represents testbed index 2
  # Parallel sensor_fusion is currently unsupported due to Arduino requirements
  - Name: TEST_BED_SENSOR_FUSION
    # Test configuration for sensor_fusion
    Controllers:
        AndroidDevice:
          - serial: <device-id>
            label: dut
    TestParams:
      fps: 30
      img_size: 640,480
      test_length: 7
      debug_mode: "False"
      chart_distance: 25
      rotator_cntl: "arduino"
      rotator_ch: <controller-channel-2>
      camera: <camera-id>
      foldable_device: "False"
      tablet_device: "False"
      lighting_cntl: "None"
      lighting_ch: <controller-channel>
      scene: "sensor_fusion"

Pour exécuter les bancs d'essai en parallèle, utilisez la commande suivante :

for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; wait

Envoyer les résultats agrégés des tests

Dans Android 17 et versions ultérieures, vous pouvez envoyer les résultats agrégés des tests ITS de l'appareil photo pour approbation de la compilation. CTS Verifier vous permet de tester simultanément plusieurs scènes sur plusieurs appareils et d'agréger les résultats des tests de plusieurs rapports CTS Verifier (à partir de différentes exécutions de test ou appareils) dans un seul envoi unifié.

Procédure d'envoi

Pour envoyer les résultats agrégés de l'ITS de l'appareil photo pour approbation de la compilation, procédez comme suit :

  1. Préparer les appareils : rassemblez deux à trois appareils testés qui ont tous la même empreinte de compilation.
  2. Installer CTS Verifier : installez la dernière APK CTS Verifier, que vous pouvez obtenir à partir de l'explorateur de compilation fourni.

  3. Exécuter les tests en parallèle :

    1. Montez les appareils testés dans des bancs d'essai distincts.
    2. Exécutez simultanément différentes scènes ITS de l'appareil photo sur chaque appareil.
    3. Collecte des rapports : générez le rapport CTS Verifier après chaque exécution. Cela inclut les rapports dans lesquels des scènes ont échoué. Ne réexécutez que les scènes ayant échoué lors des exécutions suivantes.

  4. Envoyer les rapports : importez plusieurs rapports CTS Verifier collectés à partir de tous les appareils.

  5. Examiner les résultats : une fois les rapports importés, examinez les résultats agrégés :

    • La section Test Analysis (Analyse des tests) affiche la liste complète de toutes les scènes exécutées.

    • Les scènes non exécutées ou ayant échoué sont répertoriées dans la section Failed (Échec).

      result-aggregation-image-1

      Figure 1. Documentation des scènes qui n'ont pas été exécutées ou qui ont échoué.

    • Les scènes réussies sont répertoriées dans la section Aggregated Pass (Réussite agrégée).

      result-aggregation-image-2

      Figure 2. Scènes classées comme "Réussite agrégée"

État d'approbation de la compilation

L'approbation de la compilation est accordée une fois que toutes les scènes requises ont été exécutées avec succès dans les rapports agrégés.

Modèle de bruit DNG

Les appareils qui annoncent la possibilité de capturer des images RAW ou DNG doivent fournir un modèle de bruit dans les métadonnées du résultat de capture de chaque prise de vue RAW. Ce modèle de bruit doit être intégré au HAL de l'appareil photo pour chaque appareil photo (par exemple, les appareils photo avant et arrière) sur l'appareil qui revendique la compatibilité.

Implémentation du modèle de bruit

Pour implémenter un modèle de bruit, procédez comme suit pour générer un modèle de bruit et l'intégrer au HAL de l'appareil photo.

  1. Pour générer un modèle de bruit pour chaque appareil photo, exécutez le dng_noise_model.py script dans le tools répertoire. Cela génère un extrait de code C. Pour en savoir plus sur la configuration de l'appareil photo et de l'environnement de capture, consultez le document DngNoiseModel.pdf dans le répertoire tools.

  2. Pour implémenter le modèle de bruit pour l'appareil, coupez et collez l'extrait de code C dans le HAL de l'appareil photo.

Validation du modèle de bruit

Le test ITS automatisé tests/scene1_1/test_dng_noise_model.py valide le modèle de bruit en vérifiant que les valeurs de bruit pour l'exposition et le gain de la prise de vue fournies dans les données de l'appareil photo sont correctes.

Tests réussis de justesse (état du test PASS*)

Dans Android 17 et versions ultérieures, une réussite de justesse (PASS*) indique qu'un test a réussi, mais que ses métriques de performances sont très proches du seuil de réussite prédéfini. Bien que le test réponde techniquement aux critères de réussite, la proximité de la limite d'échec suggère qu'il est nécessaire de l'examiner de plus près.

Avantages de la réussite de justesse

L'état PASS* offre plusieurs avantages :

  • Système d'alerte précoce : identifie les tests sur le point d'échouer, ce qui permet aux équipes de résoudre les problèmes avant qu'ils n'entraînent des échecs complets.

  • Optimisation proactive : encourage les équipes à optimiser les tests et le code qui fonctionnent à l'extrémité inférieure de la plage acceptable, ce qui améliore la stabilité globale.

  • Amélioration de la qualité : permet de maintenir un niveau de qualité plus élevé en signalant les zones susceptibles de régresser à l'avenir avec des modifications mineures du code.

  • Réduction du temps de débogage : en détectant les tests PASS* de manière précoce, le temps et les efforts nécessaires pour déboguer les échecs complets à l'avenir peuvent être considérablement réduits.

Détails de PASS*

L'état PASS* inclut les éléments suivants :

  • Définition des seuils : des seuils de réussite de justesse spécifiques sont définis pour chaque test pertinent dans Camera ITS.

  • Détection automatisée : le système d'automatisation des tests détecte et classe les tests comme PASS* en fonction des seuils définis.

  • Mécanisme d'alerte : les équipes reçoivent des alertes automatisées pour tous les tests signalés comme PASS*, ce qui les invite à examiner le test spécifique et ses métriques.

  • Rapports : les états de réussite de justesse sont clairement indiqués dans les rapports de test et les tableaux de bord pour une meilleure visibilité en tant que PASS* dans le rapport ItsTestSummary, comme Fail* pour les tests not_yet_mandated. Le test conserve un état vert, car il continue de réussir dans les seuils établis, afin d'éviter toute confusion supplémentaire. L'état PASS* ne s'applique qu'à une classe de test, et non à l'ensemble de la scène. Par exemple, Scene_0 peut être considéré comme PASS même si test_jitter et test_metadata sont PASS*.

  • Surveillance : les données sur les performances sont collectées sur les tests qui réussissent de justesse sur un appareil. Cela permet de surveiller les futures améliorations de l'appareil photo apportées par les OEM si ces tests passent à l'état PASS.

Voici un exemple de résultats de test avec PASS* :

INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}

Nous encourageons les partenaires à :

  • surveiller les alertes PASS* ;
  • rechercher la cause des tests PASS* ;
  • optimiser de manière proactive les tests et le code identifiés comme PASS*.

L'état PASS* vise à améliorer la robustesse et la fiabilité des tests ITS de l'appareil photo, ce qui permet d'obtenir un produit stable et de haute qualité.