CTS optimisé par les développeurs

Cette page présente les consignes d'utilisation de CTS-D (Developer-Powered CTS).

Couverture des tests

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 OBLIGATOIRES incluses dans le document de définition de compatibilité (CDD) Android pour un certain niveau d'API

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

Étant donné que toutes les API et les exigences du CDD sont associées à un niveau d'API spécifique, tous les tests CTS (CTS, CTS-D et CTS Verifier) sont associés au même niveau d'API que leurs API ou exigences associées. Si une API spécifique est abandonnée ou modifiée, son test correspondant doit être abandonné 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 passe 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 certaine condition/configuration/configuration matérielle, cette configuration doit être clairement définie dans le message de validation. Pour obtenir des exemples d'instructions de configuration, consultez Configurer CTS.
  • Le test ne doit pas durer plus de six heures à la fois. Si le test doit s'exécuter 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 permettant de 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, aucun service de premier plan ni aucun service en arrière-plan n'est en cours d'exécution, à l'exception du CTS.
  • L'écran est éteint pendant l'exécution de CTS.
  • L'appareil n'est PAS isLowRamDevice.
  • Les restrictions de l'économiseur de batterie / des applications n'ont pas été modifiées par rapport à l'état "prêt à l'emploi".

Éligibilité aux tests

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 du champ d'application de notre couverture de test sera rejeté.

Processus d'envoi CTS

  1. Rédiger 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 de l'exigence du cahier des charges associé. L'équipe Android examine la proposition.
  2. Développer un test CTS:une fois qu'une proposition est approuvée, son auteur crée un test CTS sur AOSP dans la branche principale (AOSP/main). L'équipe Android examine le code.
  3. Test de publication:envoyez votre CL sur AOSP/main, puis sélectionnez-la dans la dernière branche androidx-tests-dev. Le test est désormais disponible publiquement.

Consignes de rédaction de test CTS-D

  • Suivez le guide de style du code Java.
  • Suivez toutes les étapes décrites dans la section 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.
  • Traitez les errorprone avertissements et suggestions dans build_error.log.
  • Redéfinissez 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 possible, 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 de test Google avec lequel vous travaillez:
    • # Bug component: xxx
    • LDAP du propriétaire de test Google
  • Dans AndroidTest.xml, spécifiez les paramètres suivants. Reportez-vous aux fichiers d'exemple (1, 2) :
    • Instant_app ou not_instant_app
    • secondary_user ou not_secondary_user
    • all_foldable_states ou no_foldable_states
  • Pour spécifier la version minimale de SDK correcte, consultez la documentation <uses-sdk>.
  • Lorsque vous envoyez 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 scénario de test spécifique, utilisez run cts --include-filter "test_module_name test_name".

Pour en savoir plus sur l'exécution de la version complète de CTS, consultez Exécuter des tests CTS.

Acceptation et publication

Une fois une demande de test envoyée, une équipe interne l'examinera pour s'assurer qu'elle teste une exigence de CDD ou un comportement d'API documenté. Si l'équipe détermine que le test vérifie une exigence ou un comportement valide, elle transmettra ce cas de test à un ingénieur Google pour examen approfondi. L'ingénieur Google vous contactera pour vous indiquer comment améliorer le test avant qu'il ne puisse être accepté dans CTS.

Pour en savoir plus sur le calendrier de publication du CTS, consultez la section Calendrier de publication et informations sur la branche.