CTS propulsé par les développeurs

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

Couverture de test

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

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

Les exigences non OBLIGATOIRES, telles que FORTEMENT RECOMMANDÉ, DEVRAIT, PEUT, sont facultatives et ne peuvent pas être testées à l'aide de CTS.

Étant donné que toutes les exigences API et 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, son test correspondant doit être obsolète ou mis à jour.

Règles de création de tests CTS

  • Un test doit produire systématiquement le même résultat objectif.
  • Un test doit déterminer si un appareil réussit ou échoue en testant cet appareil une fois prêt à l'emploi.
  • Les créateurs de tests doivent supprimer tous les facteurs possibles susceptibles d’affecter les résultats des tests.
  • Si un périphérique nécessite une certaine condition matérielle/environnement/configuration, cette configuration doit être clairement définie dans le message de validation. Pour obtenir des exemples d'instructions de configuration, voir Configuration de CTS .
  • Le test ne doit pas durer plus de 6 heures à la fois. S'il doit durer plus longtemps, veuillez inclure le raisonnement 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 Wifi est stable (pour un test qui repose sur le Wifi).
  • L'appareil reste immobile pendant le test (ou non, selon le test).
  • L'appareil est débranché de toute source d'alimentation avec X pour cent du niveau de batterie.
  • Aucune application, service de premier plan ou service d'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 isLowRamDevice .
  • Les restrictions sur l'économiseur de batterie/l'application n'ont pas été modifiées par rapport à l'état « prêt à l'emploi ».

Éligibilité aux tests

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

Processus de soumission CTS

  1. Rédiger une proposition de test : un développeur d'application soumet une proposition de test à l'aide de Google Issue Tracker , décrivant le problème qui a été 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évelopper un test CTS : une fois qu'une proposition est approuvée, son émetteur crée un test CTS sur AOSP sur la branche principale (AOSP/main). L'équipe Android examine le code.
  3. Publier le test : soumettez votre CL sur AOSP/main , puis sélectionnez-le dans la dernière branche androidx-tests-dev . Le test est désormais accessible au public.

Directives de rédaction du test 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 principal CTS : 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 en head . Cela inclut les plans de test cts-developer.xml et cts-developer-exclude.xml .
  • Travaillez avec votre contact technique Google pour déterminer si votre scénario de test peut être inclus dans un module CTS existant. Si ce n’est pas le cas, ils vous aideront à créer un nouveau 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
    • Propriétaire du test Google LDAP
  • Dans AndroidTest.xml , spécifiez les paramètres suivants. Reportez-vous aux exemples de fichiers ( 1 , 2 ) pour obtenir des exemples :
    • 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, reportez-vous à la documentation <uses-sdk> .
  • Lors de l'intégration 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écutez votre test CTS-D

Exécutez le plan de test CTS-D à partir de la ligne de commande en utilisant run cts --plan cts-developer .

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

Pour plus d’informations sur l’exécution du CTS complet, consultez Exécuter les tests CTS .

Acceptation et libération

Une fois qu'une demande de test est soumise, une équipe interne l'examinera pour s'assurer qu'elle teste une exigence CDD ou un comportement d'API documenté. S'il est déterminé que le test vérifie une exigence ou un comportement valide, l'équipe transmettra ce scénario de test à un ingénieur Google pour un examen plus approfondi. L'ingénieur Google vous contactera pour vous expliquer comment le test peut être amélioré avant qu'il puisse être accepté dans CTS.

Voir Calendrier de publication et informations sur les succursales pour plus de détails sur le calendrier de publication de CTS.