CTS optimisé par les développeurs

Cette page présente les consignes d'utilisation de la CTS fournie par les développeurs (CTS-D).

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

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

Étant donné que toutes les API et exigences de CDD sont liées à un niveau d'API spécifique, toutes les CTS (CTS, CTS-D et CTS Verifier) sont liés au même niveau d'API que ou les 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 testant cet appareil une fois prêt à l'emploi.
  • Les créateurs de tests doivent supprimer tous les facteurs possibles qui pourraient affecter leurs résultats.
  • Si un appareil nécessite un certain état/environnement/configuration du matériel, cette configuration doit être clairement défini dans le message de commit. Par exemple, des instructions de configuration, consultez la section Configurer CTS.
  • Le test ne doit pas durer plus de six heures à la fois. S'il doit s'exécuter pendant 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 une application restriction:

  • Le Wi-Fi est stable (pour un test qui repose sur le Wi-Fi).
  • L'appareil reste immobile pendant le test (ou non, en fonction du test).
  • L'appareil est débranché de toute source d'alimentation lorsque le niveau de la batterie est à X %.
  • Aucune application, aucun service de premier plan ni aucun service d'arrière-plan ne sont en cours d'exécution, sauf CTS.
  • L'écran est éteint lors de l'exécution de CTS.
  • L'appareil n'est PAS isLowRamDevice.
  • Les restrictions liées à l'économiseur de batterie et aux applications n'ont pas été modifiées depuis le "prêt à l'emploi".

Éligibilité aux tests

Nous acceptons les nouveaux tests qui appliquent un comportement qui n'est pas testé par la CTS existante. CTS Verifier, ou tests CTS-D. Tout test qui vérifie un comportement en dehors du champ d'application de notre couverture de test seront refusés.

Processus d'envoi CTS

  1. Rédiger une proposition de test:un développeur d'applications soumet une proposition de test en utilisant Outil de suivi des problèmes Google, en décrivant le problème identifié et en proposant un test à vérifier pour cela. La proposition doit inclure l'ID des exigences du CDD associé. L'équipe Android examine la proposition.
  2. Développer un test CTS:une fois la proposition approuvée, le demandeur crée un test CTS. Test sur AOSP sur 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 dernière branche androidx-tests-dev. Le test est désormais accessible au public.

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é: <ph type="x-smartling-placeholder">
      </ph>
    • 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 cts-developer.xml et cts-developer-exclude.xml plans de test.
  • Rapprochez-vous de votre contact technique Google pour déterminer si votre scénario de test peuvent être incluses dans un module CTS existant. Si ce n'est pas possible, ils vous aideront créer un module.
  • Pour chaque module de test créé, créez un fichier OWNERS dans le nouveau module de test .
    • Votre fichier OWNERS doit contenir les informations suivantes, obtenues auprès de le propriétaire de 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. Consultez Les exemples de fichiers (1, 2). Voici quelques exemples:
    • Instant_app ou not_instant_app
    • secondary_user ou not_secondary_user
    • all_foldable_states ou no_foldable_states
  • Pour spécifier le SDK minimal correct, reportez-vous au <uses-sdk> documentation.
  • Lorsque vous enregistrez de nouvelles méthodes, classes ou modules de test, ajoutez-les à CTS-D plan de test et les exclure du plan de test CTS principal de la même manière que pour de nouveaux tests.

Exécuter votre test CTS-D

Exécutez le plan de test CTS-D à partir de la ligne de commande. avec 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 autorisation

Une fois la demande de test envoyée, une équipe interne l'examine pour s'assurer il teste une exigence du CDD ou un comportement documenté de l'API. Si le test est à vérifier une exigence ou un comportement valide, l’équipe transmettra ce scénario de test à un ingénieur Google pour un examen plus approfondi. La console Google votre ingénieur vous contactera pour vous faire part de ses commentaires sur la façon dont le test peut être amélioré. avant de pouvoir l'accepter dans CTS.

Voir Calendrier des versions et informations sur les succursales pour en savoir plus sur le calendrier de publication de CTS.