CTS optimisé par les développeurs

Cette page décrit les consignes d'utilisation de la suite CTS (Compatibility Test Suite) développée par les développeurs (CTS-D).

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 pour développeurs (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 non MUST, telles que STRONGLY RECOMMENDED, SHOULD et MAY, 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 de 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 le testant une seule fois.
  • Les créateurs de tests doivent supprimer tous les facteurs possibles qui pourraient affecter les résultats des tests.
  • Si un appareil nécessite une condition/un environnement/une configuration matérielle spécifique, cette configuration doit être clairement définie dans le message de commit. Pour obtenir des instructions de configuration, consultez la section Configurer CTS.
  • Le test ne doit pas durer plus de six heures à la fois. Si vous devez le laisser s'exécuter plus longtemps, 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 le niveau de batterie est de X %.
  • Aucune application, aucun service de premier plan ni aucun service en arrière-plan n'est en cours d'exécution, à l'exception de CTS.
  • L'écran est éteint lors de l'exécution de CTS.
  • L'appareil n'est PAS isLowRamDevice.
  • L'économiseur de batterie / les restrictions d'application n'ont pas été modifiés par rapport à l'état "prêt à l'emploi".

Éligibilité au test

Nous acceptons les nouveaux tests qui appliquent un comportement qui n'est pas testé par les tests CTS, CTS Verifier ou CTS-D existants. Tout test qui vérifie un comportement en dehors de la portée de notre couverture de test sera rejeté.

Processus d'envoi de CTS

  1. Rédigez une proposition de test : un développeur d'applications envoie une proposition de test à l'aide de Google Issue Tracker, décrivant le problème identifié et 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éveloppez 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 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 de tests CTS-D

  • Suivez le guide de style de 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érez 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.
  • Collaborez avec votre contact technique 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 nouveau répertoire du 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 exemples de fichiers (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 la suite CTS complète, consultez Exécuter des tests CTS.

Acceptation et publication

Une fois une 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 déterminé comme vérifiant une exigence ou un comportement valide, l'équipe transmet ce cas de test à un ingénieur Google pour 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 CTS.

Pour en savoir plus sur le calendrier de publication de CTS, consultez Calendrier de publication et informations sur les branches.