Lors de la première ouverture de DevTest Workstation, le panneau Project (Projet) contient le projet nommé Examples (Exemples).
Ouvrez un des exemples de fichiers en double-cliquant sur celui-ci. L'éditeur approprié s'ouvre dans le panneau droit.
Les fichiers du projet actif sont disponibles dans le répertoire LISA_HOME\examples.
Fichier MAR de suite qui inclut la suite de tests AllTestsSuite, avec tous les fichiers .tst et les fichiers de données associés pour l'exécution de la suite. La suite inclut également le document de simulation 1User1Cycle0Think, le document d'audit DefaultAudit et le fichier de configuration project.config.
Fichier MAR de moniteur basé sur un test qui inclut le scénario de test creditCheckValidate et le document de simulation monitorRunBase.
Fichier MAR de service virtuel qui inclut le modèle de service virtuel DatabaseModel et l'image de service virtuel.
Fichier MAR de moniteur basé sur un test qui inclut le scénario de test webservices-xml-fail, le document de simulation Run1User1Cycle et le fichier project.config.
Fichier MAR de moniteur basé sur un test qui inclut le scénario de test async-consumer-jms, le document de simulation Run1User1Cycle et le fichier de configuration project.config.
Fichier MAR de moniteur basé sur un test qui inclut les éléments suivants :
Fichier MAR de moniteur basé sur un test qui inclut le scénario de test webservices-xml, le document de simulation Run1User1Cycle et le fichier de configuration project.config.
Fichier MAR de test qui inclut le scénario de test rawSoap, le document de simulation 1User0Think_RunContinuously et le fichier de configuration project.config.
Le fichier project.config contient des valeurs par défaut intelligentes pour la plupart des propriétés.
Data (Données)
Le répertoire Data (Données) contient des ensembles de données, des référentiels de clés et des fichiers WSDL requis pour l'exécution de certains exemples pour le serveur de démonstration.
Monitors (Moniteurs)
Scénario de test utilisé pour les démonstrations du moniteur de service de validation en continu. Un échec se produit de manière aléatoire pour un ID de contenu spécifique.
Document de simulation spécifiant un utilisateur, un cycle, un délai de réflexion de 100 %, CAI non activé et aucun temps maximum d'exécution
Document de simulation spécifiant un utilisateur, une exécution continue, un délai de réflexion de 136 %, CAI activé et un temps d'exécution maximum de 15 secondes
Document de simulation spécifiant un utilisateur, un cycle, un délai de réflexion de 100 %, CAI non activé et aucun temps maximum d'exécution L'enregistrement des mesures JMX et JBoss est sélectionné.
Exemple de fichier squelette contenant des paramètres de pilote Web Selenium que vous pouvez définir pour personnaliser des options de scénarios de test Selenium
Utilisé pour les démonstrations du moniteur de service de validation en continu. Un échec se produit de manière aléatoire pour un ID de contenu spécifique.
Ce test est utilisé dans l'installation du moniteur pour les démonstrations du service de validation en continu.
Setup (Configuration)
Le répertoire Setup (Configuration) situé sous le répertoire Examples (Exemples) contient des fichiers de commandes permettant de démarrer ou d'arrêter tous les composants DevTest et de charger les moniteurs du service de validation en continu.
Pour utiliser les scripts avec la liste de contrôle d'accès activée, ajoutez les options de nom d'utilisateur et de mot de passe aux commandes du gestionnaire de services dans le script. Le mot de passe n'est pas automatiquement chiffré ; veillez donc à protéger le fichier à l'aide de la méthode appropriée pour votre système d'exploitation.
Ce document de simulation exécute un utilisateur virtuel unique avec un délai de réflexion de zéro. Il exécute également le ou les tests en continu, ce qui ne signifie pas nécessairement "pour toujours".
Lorsqu'un test exécuté par ce document de simulation remplit toutes les conditions suivantes et ne dispose pas suffisamment de données, l'exécution se termine :
S'il y a plusieurs ensembles de données correspondant à ces conditions, le premier ensemble de données qui expire termine l'exécution. Pour consulter un exemple significatif, reportez-vous au scénario de test à plusieurs niveaux multi-tier-combo.tst.
Ce document de simulation exécute un test une fois avec un seul utilisateur et un pourcentage de délai de réflexion de 0 %.
Pour tester la prise en charge de l'usurpation d'adresse IP avec votre installation de DevTest, utilisez ce document de simulation. L'usurpation de l'adresse IP est activée dans ce document de simulation dans l'onglet IP Spoofing (Usurpation de l'adresse IP). Si vous exécutez le serveur d'exemples, une page Web de test d'usurpation d'adresse IP est disponible à l'adresse suivante : http://localhost:8080/ip-spoof-test.
Ce document de simulation exécute un test avec trois utilisateurs, de manière continue, avec un temps maximum d'exécution de 440 secondes et un délai de réflexion de 100 %. Il sélectionne les quatre cases à cocher correspondant aux paramètres de générateur de rapports et spécifie également toutes les mesures JMX JBoss à collecter.
Ce document de simulation exécute un test une fois avec un seul utilisateur et un pourcentage de délai de réflexion de 100 %.
Ce document de simulation exécute un test une fois avec un seul utilisateur, un pourcentage de délai de réflexion de 100 % et CAI activé.
Ce document de simulation exécute un test une fois avec un seul utilisateur et un pourcentage de délai de réflexion de 100 %. Il sélectionne également les quatre cases à cocher dans le générateur de rapports par défaut, de sorte que d'autres informations s'affichent dans la page d'exécution du modèle Web.
Subprocesses
Ce scénario de test à étape unique est marqué comme sous-processus et peut être appelé à partir d'une étape Execute Sub Process (Exécuter un sous-processus).
La suite AllTestsSuite exécute tous les tests du répertoire Tests de DevTest, à l'aide du document de simulation 1user1cycle et du document d'audit par défaut AuditDocs\DefaultAudit.aud. Elle enregistre uniquement les demandes et les réponses pour les mesures de rapport et renvoie les mesures par défaut. Son mode d'exécution est Serial (En série).
La suite AllTestsSuite exécute tous les tests du répertoire Tests de DevTest, à l'aide du document de simulation 1user1cycle0think et du document d'audit par défaut AuditDocs\DefaultAudit.aud. Elle enregistre uniquement les demandes et les réponses pour les mesures de rapport et renvoie les mesures par défaut. Son mode d'exécution est Parallel (Parallèle).
Test JMS simple qui ajoute un utilisateur avec un compte à LISA Bank. Les modèles attendus dans les réponses sont utilisés dans des assertions à partir des deux étapes.
Il s'agit d'un exemple de file d'attente de consommateur asynchrone dans laquelle le scénario de test accepte des messages en continu à partir d'une rubrique ou d'une file d'attente de réponses. La file d'attente met également les messages à la disposition du scénario de test dans l'ordre d'arrivée des messages.
La première étape crée la file d'attente (interne au test).
La deuxième étape envoie trois messages à une file d'attente JMS sur le serveur de démonstration. La file d'attente asynchrone reçoit les messages.
La troisième étape valide la réception des trois messages dans la file d'attente asynchrone.
Test EJB exclusif de la fonctionnalité LISA Bank. En général, vous testez les applications en enregistrant un navigateur Web ou une autre interface utilisateur. Ces tests sont des tests d'intégration de bout en bout. Ils ne sont pas les plus accessibles et requièrent l'implication de rédacteurs techniques supplémentaires, même si vous ne devez toutefois écrire encore aucun code.
Ces tests sont utiles à l'équipe de développement, car ils permettent de constamment tester et valider le code sans recourir à une interface utilisateur, qui peut ne pas exister ou être modifiée continuellement, si bien que les tests ne peuvent pas suivre.
Ce modèle teste consciencieusement les services Web de LISA Bank. Il est presque identique au test ejb3EJB en termes de fonctionnalité et d'utilité. Pour plus d'informations, reportez-vous à la documentation de ce scénario de test.
Cet exemple de scénario de test illustre la prise en charge de l'usurpation d'adresse IP dans DevTest.
Ce test demande l'URL http://localhost:8080/ip-spoof-test à l'aide d'une étape REST, une page Web qui contient l'adresse IP du client demandeur. Le test envoie alors une demande SOAP à l'URL suivante, qui identifie un service Web contenant une opération qui renvoie l'adresse IP du client demandeur :
http://localhost:8080/itko-examples/ip-spoof-test/webservice
Le scénario de test exécute les deux demandes dans une boucle dix fois. Vous pouvez simuler ce test avec le document de simulation de test d'usurpation de l'adresse IP ip-spoofing.stg. La configuration d'interface réseau correcte vous permet de consulter les différentes adresses IP utilisées par les utilisateurs virtuels lorsqu'ils effectuent des demandes HTTP et SOAP.
Ce scénario de test est un exemple JMS simple indiquant la procédure d'envoi de messages de texte ou XML, et d'objets au format Java natif.
Ce scénario de test récupère les informations de diagnostic de l'ordinateur exécutant DevTest. Les résultats peuvent permettre au support technique de résoudre les problèmes de configuration.
Ce modèle de test utilise un fichier CSV de valeurs séparées par des virgules comme ensemble de données pour tester une application Web. L'application Web de démonstration fournie avec DevTest permet d'ajouter des utilisateurs à la base de données et de les supprimer.
Cet exemple indique la procédure à suivre pour mettre en échec un test en recherchant les messages ERROR ou WARNING dans un fichier journal.
L'exemple utilise un ensemble de données pour fournir deux nombres à diviser à l'exemple de bean AntiPattern. A la moitié de l'ensemble de données environ, l'opérande 0 est défini. Cet opérande entraîne une exception de division par zéro sur le serveur. Le bean AntiPattern enregistre l'exception dans le journal et renvoie la valeur -1 comme résultat.
Cet exemple est un anti-modèle commun : des erreurs internes se produisent, mais les intervenants extérieurs ignorent que le résultat est incorrect. Le résultat paraît plausible, mais il est erroné. Le résultat attendu est la propagation en retour de l'exception par le composant EJB vers l'appelant.
Ce scénario de test échoue avec CAI, car l'agent enregistre le fait qu'une exception a été renvoyée, ce qui permet à DevTest de déterminer qu'une erreur s'est produite.
Une alternative à l'utilisation de CAI consiste à configurer une assertion globale pour surveiller le fichier journal du serveur. Définissez les éléments compris dans une expression régulière. Dans le cas présent, il s'agit simplement de l'erreur de test ERROR. Vous pouvez choisir le niveau de complexité des expressions régulières qui vous convient le mieux.
En général, vous définissez l'assertion de sorte à mettre le test en échec immédiatement. Dans ce cas, passez à l'étape Error detected in log (Erreur détectée dans le fichier journal) et terminez le test normalement.
DevTest attend que les applications en cours de test qui journalisent des erreurs ou des avertissements ne soient jamais transmises. Pensez à utiliser un compagnon équivalent dans vos scénarios de test par défaut.
Ce test est un exemple de test négatif. Un échec des étapes du test doit se produire, c'est-à-dire, les données de service fournies doivent entraîner une erreur.
Le test comprend le compagnon NegativeTestingCompanion, qui met le test en échec si une étape réussit.
Dans ce scénario, vous tentez de créer des utilisateurs dans le serveur de démonstration qui existent déjà. Les données sont récupérées à partir de la base de données, grâce à l'ensemble de données de nom d'utilisateur qui interroge la table directement. Si une étape réussit, le test complet échoue.
La seule étape qui réussit est l'étape de "réussite silencieuse". Cette étape vous permet de marquer les étapes dont vous attendez la transmission dans ce type de scénario comme Quiet (silencieuses) dans l'éditeur, de sorte qu'elles ne soient pas traitées par le NegativeTestingCompanion (Compagnon de test négatif).
Ce test appelle un sous-processus permettant d'insérer un nom d'utilisateur unique dans la table USERS du serveur de démonstration.
L'ensemble de données est intéressant, car il compte sur une feuille de données pour extraire des valeurs à partir d'un générateur de code unique. La même opération peut être effectuée à l'aide d'un générateur de code unique comprenant un ensemble de données de compteur. Cet exemple illustre l'influence que peut exercer un ensemble de données sur un autre.
Les ensembles de données sont évalués dans l'ordre dans lequel ils sont spécifiés. A chaque exécution de l'étape, une nouvelle valeur est affectée à la propriété UniqueUser. La feuille de données mentionne {{UniqueUser}} quatre fois. Cinq valeurs uniques sont donc obtenues.
Si l'une des étapes échoue, le test échoue immédiatement.
Comparez ce test au test similaire main_all_should_fail, dans lequel un échec de chaque étape est attendu et qui est mis en échec si une étape est réussie. Ce processus utilise la méthode du test négatif.
Le test multi-tier-combo (à plusieurs niveaux) utilise différents terminaux de service pour valider l'exemple LisaBank. Testez des transactions SOAP, EJB, JMS, Selenium et Web et validez-les de différentes manières, notamment par validation directe de la base de données du serveur de démonstration. Ce test requiert le navigateur Firefox pour l'exécution des étapes Selenium.
Le test à plusieurs niveaux utilise différents terminaux de service pour valider l'exemple LISA Bank. Le scénario de test teste les transactions Web, SOAP, EJB et JMS, puis les valide de plusieurs façons, y compris via la validation directe de la base de données du serveur de démonstration.
Le test indique également la procédure de création d'objets SOAP complexes à partir de feuilles de calcul. La feuille de calcul multi-tier-users.xls du dossier Data (Données) du projet sauvegarde l'ensemble de données de l'utilisateur lors de la première étape.
Si vous exécutez ce test dans la fenêtre Interactive Test Run (Exécuter un test interactif), un utilisateur unique est créé à partir de la première ligne de la feuille de calcul, puis le test se termine.
Si vous simulez le test avec l'exemple de document de simulation 1User0Think_RunContinuously, il redémarrera jusqu'à atteindre la fin de l'ensemble de données. Ce processus est la méthode préférée pour une itération répétée sur un grand ensemble de données. Une boucle pourrait également être utilisée dans le scénario de test, mais elle ne fournirait pas autant de flexibilité.
Si vous permettez au document de simulation qui contrôle l'ensemble de données de terminer le test, vous pouvez diffuser le test auprès de plusieurs utilisateurs virtuels. Vous pouvez également contrôler le rythme du test à l'aide de délais de réflexion et d'autres paramètres.
Seuls les ensembles de données globaux définis lors de la première étape du test affectent le comportement de fin du test en continu du document de simulation. Si l'ensemble de données est local ou déclaré à un autre emplacement dans le test, l'exécution continue implique une exécution permanente réelle.
Le test multi-tier-combo-se (à plusieurs niveaux) utilise différents terminaux de service pour valider l'exemple LISA Bank. Testez des transactions SOAP, EJB, JMS et Web et validez-les de différentes manières, notamment par validation directe de la base de données du serveur de démonstration.
Le test indique également la procédure de création d'objets SOAP complexes à partir de feuilles de calcul. L'ensemble de données de l'utilisateur de la première étape est confirmé par la feuille de calcul multi-tier-users.xls du dossier Data (Données) du projet.
Si vous exécutez ce test dans la fenêtre Interactive Test Run (Exécution d'un test interactif), un utilisateur unique est créé à partir de la première ligne de la feuille de calcul, puis le test se termine.
Si vous simulez le test avec l'exemple de document de simulation 1User0Think_RunContinuously, il redémarrera jusqu'à atteindre la fin de l'ensemble de données. Ce processus est la méthode recommandée pour une itération répétée sur un ensemble de données volumineux. Vous pouvez introduire une boucle dans le scénario de test, mais cette méthode est loin d'être flexible.
Si vous laissez le document de simulation contrôler l'ensemble de données à la fin du test, vous pourrez répartir le test parmi plusieurs utilisateurs virtuels, ou contrôler le rythme du test à l'aide de délais de réflexion.
Notez que le comportement impliquant la fin de l'exécution continue du test du document de simulation est uniquement affecté par des ensembles de données globaux définis dans la première étape du test. Si l'ensemble de données est local ou déclaré à un autre emplacement dans le test, l'exécution continue implique une exécution permanente réelle.
L'étape rawSoap est un scénario de test en une étape unique présentant une demande SOAP brute simple dans l'étape listUsers.
Le test rest-example présente la procédure d'exécution des services RESTful. Le serveur de démonstration contient un exemple de JAX-RS. Chaque étape du test indique la procédure à suivre pour interagir avec ce service via XML et JSON.
Génération de scripts
CA Application Test peut utiliser des moteurs de génération de scripts JSR-223, ce qui vous permet d'utiliser de nombreux moteurs de génération de scripts dans des étapes de script, des assertions, des gestionnaires de protocole de données, des scripts de correspondance et pratiquement à tout emplacement à l'aide de la syntaxe {{=%language%}}.
Permet de tester la capacité de VSEasy à créer un service JMS à partir de paires demande-réponse.
Ce test est un exemple simple de validation de service. Le test appelle un service Web et un service EJB, puis examine la base de données sous-jacente à l'aide de SQL pour valider le fonctionnement approprié des services.
Ce test est un test Web simple généré à l'aide de l'enregistreur Web. Il contient certaines assertions de base comme l'assertion assert nonempty response (assertion d'une réponse non vide), qui est automatiquement générée. Le test contient également des assertions assert title (assertion de titre) créées lors de l'analyse des réponses HTML pour la balise <title>. Ces assertions permettent de vérifier que la page enregistrée est identique à celle utilisée lors de la réutilisation du test.
Ce scénario de test permet d'ajouter, de récupérer et de supprimer un utilisateur de services Web EJB3. Le test utilise un générateur de code unique pour créer un nombre comprenant un préfixe qui est une valeur {{user}} provenant du fichier de configuration. Le mot de passe est codé de manière irréversible dans le fichier de configuration.
Ce scénario de test teste la capacité d'envoi et de réception de BLOB de données intégrés codés en base64 et de pièces jointes XOP/MTOM. Les filtres et les assertions dans les étapes vérifient que les demandes et les réponses soient correctes.
Le scénario de test ws_security indique la procédure à suivre pour utiliser des messages SOAP signés et chiffrés. Les deux premières étapes réussissent et les deux dernières échouent. Les appels sont les mêmes, mais le service Web n'accepte pas les messages non chiffrés ou non signés.
Ce modèle de test indique la procédure à suivre pour utiliser des messages SOAP signés et chiffrés. Les deux premières étapes doivent se terminer correctement et les deux dernières doivent échouer. Les appels sont identiques, mais le service Web n'accepte pas les messages non chiffrés ou signés.
Ce plan de test requiert la prise en charge par votre environnement Java du niveau de chiffrement illimité. Si l'une des deux premières étapes échoue, il est probable que vos fichiers JAR de JCE doivent être mis à jour pour activer le niveau de chiffrement illimité. Vous pouvez télécharger les fichiers JAR de JCE à partir du site suivant : www.oracle.com. Recherchez les mots clés JCE unlimited strength (Niveau illimité JCE) et sélectionnez la bibliothèque de JCE correspondant à votre version Java, par exemple JCE 7 pour la version Java 7. Une fois les fichiers JAR de JCE installés, vous devez redémarrer les services DevTest.
Dans le document d'audit, deux occurrences Step Error (Erreur d'étape) sont attendues. Procédez à l'audit des deux erreurs d'étape, car les deux dernières étapes doivent déclencher des erreurs. De cette manière, le document d'audit peut également procéder à l'audit du nombre d'occurrences reçues pour un événement. Si vous ajoutez une troisième entrée Step Error (Erreur d'étape) au document d'audit, l'auditeur de ce test échouera, car deux événements d'erreur d'étape seulement sont déclenchés.
Echecs de tests
Ce scénario de test permet d'ajouter, de récupérer et de supprimer un utilisateur de services Web EJB3. Le test utilise un générateur de code unique pour créer un nombre comprenant un préfixe qui est une valeur {{user}} provenant du fichier de configuration. Le mot de passe est codé de manière irréversible dans le fichier de configuration.
VServices
Images
DatabaseModel.vsi
kioskV4ServiceImage.vsi
kioskV6.vsi
si-kioskV5-dynamic.vsi
si-kioskV5.vsi
WebServicesModel.vsm
|
Copyright © 2014 CA Technologies.
Tous droits réservés.
|
|