CTS optimisé par les développeurs

Cette page décrit les consignes d'utilisation pour CTS-D (CTS optimisé par les développeurs).

Couverture de test

Comme CTS et CTS Verifier, CTS-D ne peut appliquer que les éléments suivants :

  • Toutes les API publiques décrites dans le SDK Developer (developer.android.com) pour un certain niveau d'API.
  • Toutes les exigences MUST incluses dans le document de définition de compatibilité (CDD) Android pour un certain niveau d'API.

Les exigences autres que MUST (STRONGLY RECOMMENDED, SHOULD, MAY, etc.) sont facultatives et ne peuvent pas être testées à l'aide de CTS.

Étant donné que toutes les API et toutes les exigences du CDD sont liées à un niveau d'API spécifique, tous les tests CTS (CTS, CTS-D et CTS Verifier) sont liés au même niveau d'API que leurs API ou exigences associées. Si une API spécifique est obsolète ou modifiée, le test correspondant doit être obsolète ou mis à jour.

Règles de création des tests CTS

  • Un test doit produire le même résultat objectif de manière cohérente.
  • Un test doit déterminer si un appareil réussit ou échoue en testant cet appareil une seule fois dès sa sortie de l'emballage.
  • Les créateurs de tests doivent éliminer tous les facteurs susceptibles d'affecter les résultats des tests.
  • Si un appareil nécessite une configuration, un environnement ou une condition matérielle spécifique, cette configuration doit être clairement définie dans le message de commit. Pour obtenir des instructions de configuration, consultez Configurer CTS.
  • Le test ne doit pas durer plus de six heures à la fois. Si vous avez besoin de plus de temps, veuillez inclure la raison dans votre proposition de test afin que nous puissions l'examiner.

Voici un exemple d'ensemble de conditions de test pour tester une restriction d'application :

  • Le Wi-Fi est stable (pour un test qui repose sur le Wi-Fi).
  • L'appareil reste immobile pendant le test (ou non, selon le test).
  • L'appareil est débranché de toute source d'alimentation et la batterie est chargée à X %.
  • Aucune application, ni aucun service de premier plan ou d'arrière-plan n'est en cours d'exécution, à l'exception du CTS.
  • L'écran est éteint pendant l'exécution du CTS.
  • L'appareil n'est PAS isLowRamDevice.
  • L'économiseur de batterie et les restrictions d'application n'ont pas été modifiés par rapport à l'état "prêt à l'emploi".

Tester l'éligibilité

Nous acceptons les nouveaux tests qui appliquent un comportement non testé par les tests CTS, CTS Verifier ou CTS-D existants. Tout test qui vérifie un comportement en dehors du champ d'application de notre couverture de test sera rejeté.

Processus d'envoi des CTS

  1. Rédiger une proposition de test : un développeur d'applications envoie une proposition de test à l'aide de Google Issue Tracker, en décrivant le problème identifié et en proposant un test pour le vérifier. La proposition doit inclure l'ID d'exigence CDD associé. L'équipe Android examine la proposition.
  2. Développer un test CTS : une fois la proposition approuvée, son auteur crée un test CTS sur AOSP dans la branche de la dernière version d'Android (android16-release). L'équipe Android examine le code et, s'il est accepté, sélectionne la modification et la fusionne dans la branche de développement interne. Pour en savoir plus, consultez Où puis-je proposer des modifications à AOSP ?.

Consignes pour la rédaction des tests CTS-D

  • Suivez le guide de style du code Java.
  • Suivez toutes les étapes décrites dans Développement CTS.
  • Ajoutez vos tests au plan de test approprié :
    • Utilisez include-filters pour ajouter vos nouveaux tests au plan de test CTS-D : platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Utilisez exclude-filters pour exclure vos nouveaux tests du plan de test CTS principal : platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Gère tous les avertissements et suggestions errorprone dans build_error.log.
  • Rebasez vos modifications sur head. Cela inclut les plans de test cts-developer.xml et cts-developer-exclude.xml.
  • Contactez votre ingénieur Google pour déterminer si votre cas de test peut être inclus dans un module CTS existant. Si ce n'est pas le cas, il vous aidera à créer un module.
  • Pour chaque nouveau module de test créé, créez un fichier OWNERS dans le répertoire du nouveau module de test.
    • Votre fichier OWNERS doit contenir les informations suivantes, obtenues auprès du responsable des tests Google avec lequel vous travaillez :
    • # Bug component: xxx
    • LDAP du propriétaire du test Google
  • Dans AndroidTest.xml, spécifiez les paramètres suivants. Pour obtenir des exemples, consultez les fichiers exemples (1, 2) :
    • Instant_app ou not_instant_app
    • secondary_user ou not_secondary_user
    • all_foldable_states ou no_foldable_states
  • Pour spécifier le minSDK correct, consultez la documentation <uses-sdk>.
  • Lorsque vous enregistrez de nouvelles méthodes, classes ou modules de test, ajoutez-les au plan de test CTS-D et excluez-les du plan de test CTS principal de la même manière que pour les nouveaux tests.

Exécuter votre test CTS-D

Exécutez le plan de test CTS-D à partir de la ligne de commande à l'aide de run cts --plan cts-developer.

Pour exécuter un cas de test spécifique, utilisez run cts --include-filter "test_module_name test_name".

Pour savoir comment exécuter l'intégralité du CTS, consultez Exécuter des tests CTS.

Acceptation et décharge

Une fois une demande de test envoyée, une équipe interne l'examinera pour s'assurer qu'elle teste une exigence CDD ou un comportement d'API documenté. Si le test est considéré comme vérifiant une exigence ou un comportement valides, l'équipe transmettra ce cas de test à un ingénieur Google pour un examen plus approfondi. L'ingénieur Google vous contactera pour vous faire part de ses commentaires sur la façon d'améliorer le test avant qu'il puisse être accepté dans le CTS.

Pour en savoir plus sur le calendrier des versions du CTS, consultez Calendrier des versions et informations sur les branches.