Compute Nest:Tester un service

Les fournisseurs de services peuvent tester un service manuellement ou via des tests automatisés. Choisissez la méthode la plus adaptée à votre service.

• Test manuel : utilisez le lien de déploiement d'instance de service pour déployer une instance dans votre propre compte, en vous plaçant du point de vue d'un utilisateur.

• Test automatisé : créez des cas de test pour différents modèles et exécutez des tâches de test afin de vérifier l'exactitude des modèles. Les cas de test sont hérités par les versions ultérieures du service, ce qui permet d'effectuer des tests de régression au fil des itérations. Les tests automatisés se déclenchent automatiquement lors de la soumission du service pour examen.

Test manuel

Utilisez le lien de déploiement d'instance de service pour créer une instance dans votre compte et vérifier le processus de déploiement.

1. Connectez-vous à la console Compute Nest.

2. Recherchez le service enregistré. Cliquez sur le nom du service pour ouvrir la page de détails du service.

3. Cliquez sur l'onglet Service Test, puis cliquez sur le lien de test pour ouvrir la page de création d'instance de service.

   Sur la page de création d'instance de service, vérifiez l'interface utilisateur (UI).

4. Une fois le test terminé, le message Test successful s'affiche dans l'onglet Service Test. Cela confirme que l'instance de service a bien été créée et que le service est disponible.

Test automatisé

Créez un cas de test pour personnaliser les paramètres du modèle de service. Ce cas de test est lié au processus d'examen du service et s'exécute automatiquement lorsque vous soumettez le service pour examen. Tous les cas de test sont hérités par les versions ultérieures du service, permettant ainsi d'effectuer des tests de régression lors de la mise à niveau ou de la mise à jour du service.

Configuration des cas de test

Un cas de test est défini dans un fichier YAML. L'exemple suivant illustre la configuration d'un cas de test pour un service consul.

---
parameters:
  SystemDiskSize: 100
  PayType: "PostPaid"
  DataDiskSize: 40
  InstanceType: "$[iact3-auto]"
  AllocatePublicIp: "true"
  DataDiskCategory: "cloud_efficiency"
  InstancePassword: "$[iact3-auto]"
  SystemDiskCategory: "cloud_essd"

Vous pouvez également cliquer sur Import Default Configurations dans la boîte de dialogue Add Test Case pour importer la configuration de cas de test par défaut du service. Cette configuration par défaut utilise les paramètres définis dans le modèle de service.

Paramètres

Le tableau suivant décrit les champs d'une configuration de cas de test.

Créer une tâche de test

Pour exécuter un test, sélectionnez un modèle et un cas de test dans votre compte Compute Nest.

1. Dans la section Test Tasks, cliquez sur Create Task. Dans la boîte de dialogue qui s'affiche, configurez les informations de la tâche.

   1. Définissez un nom pour la tâche de test.

   2. Sélectionnez un modèle de service et un cas de test.

      Si vous disposez de plusieurs modèles, vous pouvez ajouter un cas de test pour chacun d'eux.

   3. Sélectionnez la région dans laquelle vous souhaitez exécuter la tâche.

      En l'absence de sélection, une région est choisie aléatoirement parmi les régions de déploiement configurées pour le service.

2. Cliquez sur Create Now.

   Après la création de la tâche, suivez sa progression dans la liste des tâches. La tâche apparaît dans la liste Test Tasks. Cette liste contient des informations telles que Task Name, Region, Test Case et Execution Status. Le statut d'exécution initial est Running.

3. Consultez le rapport.

   Une fois la tâche terminée, le rapport d'exécution affiche la configuration de test ainsi que les informations relatives au cas de test.

   1. Cliquez sur l'icône située à côté du nom de la tâche de test, puis cliquez sur Details.

   2. Dans la boîte de dialogue Test Report, examinez la configuration de test, la région et la pile de la tâche. Cette boîte de dialogue comporte deux sections : la section Test Configuration affiche les paramètres YAML du modèle, tels que SystemDiskSize, PayType, DataDiskSize, InstanceType, AllocatePublicIp, DataDiskCategory, InstancePassword et SystemDiskCategory. La section Test Case présente sous forme de tableau le nom du test, la région, la pile, le résultat et le journal de test. Cliquez sur le lien View pour consulter les détails du journal de test correspondant.

4. Consultez les journaux.

   Les journaux fournissent des informations telles que les paramètres effectifs, les détails de la pile et les messages d'erreur. La boîte de dialogue des détails du journal affiche des champs comme Region, StackName, StackId, TestedResult et ResultReason. Par exemple, si le résultat du test est Failed, la raison peut être StackValidationFailed avec un message tel que Resources.Database.Condition: Unrecognized value 'Please fill in'. Cela indique une valeur de paramètre non valide. Les valeurs valides pour les types booléens incluent '0', '1', 'true', 'false', 'yes', 'no', 'on' et 'off'.

Erreurs courantes et solutions

Voici les erreurs fréquemment rencontrées lors des tests de service, accompagnées de leurs solutions.

• Message d'erreur : Dans le journal des erreurs, TestedResult indique Failed et ResultReason affiche IacerException, can not find any available value for ZoneId in {region}. Exemple : « IacerException, can not find any available value for ZoneId in cn-qingdao region in [] for default ».

  Solution : Aucune ressource correspondante n'est disponible dans la région actuelle. Spécifiez une autre région pour la tâche.

• Message d'erreur : « Resources.TiDBServerScalingGroupEnable.Properties: : Unknown Property DetachOptions request id: 51341F62-56DC-xxxx-xxxx-xxx »

  Solution : Un paramètre du modèle n'est pas valide. Modifiez le paramètre dans la configuration de test en vous basant sur le message du journal.

Pseudo-paramètres

La saisie manuelle des paramètres de test pour la validation fonctionnelle peut s'avérer fastidieuse. Utilisez le pseudo-paramètre $[iact3-auto] pour remplir automatiquement les valeurs des paramètres. Les pseudo-paramètres sont pris en charge dans les scénarios suivants :

• Le paramètre prend en charge une API permettant d'interroger ses contraintes. Lorsque vous appelez l'opération GetTemplateParameterConstraints pour ce paramètre, l'opération retourne une liste de AllowedValues.

• Le nom du paramètre possède une signification spécifique ou implique un type de ressource clair. Dans ce cas, le pseudo-paramètre obtient automatiquement une valeur appropriée.

  • Pour les paramètres tels que VpcId, VswitchId et SecurityGroupId, le pseudo-paramètre sélectionne automatiquement un ID d'instance correspondant dans la région actuelle.

  • Pour les paramètres tels que VpcName, Password et Uuid, le pseudo-paramètre génère aléatoirement un nom, un mot de passe ou une valeur UUID.

  • Le pseudo-paramètre prend en charge les noms correspondant aux expressions régulières suivantes :

    • Si un nom de paramètre correspond à l'expression régulière vpc(_|)id, il obtient automatiquement une valeur VpcId aléatoire dans la région actuelle.

    • Si un nom de paramètre correspond à v(_|)switch(_|)id, il obtient automatiquement une valeur VswitchId dans la région actuelle. Si le nom du paramètre contient également une valeur correspondant à zone(_|)id, l'ID d'un vSwitch dans la zone correspondante est recherché.

    • Si un nom de paramètre correspond à security(_|)group(_id|id), il obtient automatiquement les informations du groupe de sécurité.

    • Si un nom de paramètre correspond à l'expression régulière r'\w*name', une chaîne aléatoire commençant par iacer- est générée.

    • Si un nom de paramètre correspond à l'expression régulière r'\w*password', un mot de passe aléatoire contenant des lettres majuscules, des lettres minuscules, des chiffres et des caractères spéciaux est généré.

    • Si un nom de paramètre correspond à l'expression régulière r'\w*uuid', un UUID est généré automatiquement.