CTS optimisé par les développeurs

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

Couverture des tests

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, par exemple) 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, expliquez pourquoi 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 s'appuie 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 le niveau de batterie est de 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 des CTS.
  • L'appareil n'est PAS isLowRamDevice.
  • L'économiseur de batterie et les restrictions d'applications n'ont pas été modifiés par rapport à l'état d'usine.

Éligibilité aux tests

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 est refusé.

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 dernière branche de version d'Android (android17-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ù dois-je proposer des modifications à AOSP ?.

Consignes de rédaction des tests CTS-D

  • Suivez le guide de style du code Java.
  • Suivez toutes les étapes décrites dans Développement du 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, ils vous aident à 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 propriétaire du test 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 approprié, 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 libération

Une fois la demande de test envoyée, une équipe interne l'examine pour s'assurer qu'elle teste une exigence CDD ou un comportement d'API documenté. Si le test est censé vérifier une exigence ou un comportement valides, l'équipe transmet ce cas de test à un ingénieur Google pour qu'il l'examine plus en détail. L'ingénieur Google vous contacte pour vous faire part de ses commentaires sur la façon dont le test peut être amélioré avant d'ê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.