Blog du testeur - Outil de test

Testlink 2 versions cette année

Dominique Mereaux — Sun, 30 Dec 2018 18:08:26 +0100

Cette année deux versions de testlink ont été déployées, supportant des versions plus récentes de php et mysql. L'interface est en cours de modernisation:

Sinon beaucoup de correction d'anomalies et la possibilité de se connecter à gitlab dans la partie connexion avec un gestionnaire d'anomalies. à suivre ...

Parametriser ses tests avec NUNIT

Dominique Mereaux — Tue, 06 May 2014 11:05:26 +0200

Pour rendre ses tests automatiques maintenables il est essentiel de limiter le code de test. La plupart des framework de test offre la possibilité d'utiliser le même code source pour des jeux d'essais différents.

Prenons un exemple: sur une page web je veux tester la présence d'une série de lien:

Avec NUNIT on peut simplement rejouer le même test pour les différents liens:

Le test est rejoué pour les deux liens:

Le code suivant est équivalent:

Encore plus fort, si j'ai plusieurs paramètres je peux les combiner en utilisant en autres une stratégie de type "pairwise". Pour celà j'utilise l'attribut Pairwise de test. Voici un exemple:

Pairwise: au lieu d'avoir toutes les combinaisons de paramètres par 3, on se contente des combinaisons par paire: toutes les combinaisons de valeurs pour 2 paramètres sont présentes.

Et voici les combinaisons proposées:

Plus d'infos sur NUNIT

Tester ses activités avec la classe: ActivityInstrumentationTestCase2

Dominique Mereaux — Fri, 14 Mar 2014 10:12:26 +0100

Cette classe permet de tester le cycle de vie d'une activité.
Elle hérite de la classe ActivityIntrumentationTestCase qui permet comme son nom l'indique d'instrumenter l'activité soit:

de contrôler le cycle de vie.
de simuler des intents.
de simuler des interaction utilisateur.

Rappel cycle de vie:

Dans un premier il faut démarrer l'activité. Cela est réalisé au moment su SetUp du test:

La fonction setActivityInitialTouchMode(false);permet de déactiver le mode tactile pour pouvoir utiliser l'envoi de caractères.
L'appel à mActivity = getActivity(); permet de démarrer l'activité. Tout est en place pour démarrer les tests.

Pour interagir avec l'interface de l'application il faut le faire dans le thread de l'application.

Une fois l'objet graphique initialisé, ici le spinner, il est possible de simuler les interactions avec des fonctions de type sendKeys. Et maintenant testons le cycle de vie:

Il faut récupérer l'objet instrumentation qui va nous permettre de tester le cycle de vie. Dans un premier temps on travaille sur l'activité, elle est ensuite mise en pause puis l'activité reçoit l'événement resume.
Le test va consister à vérifier que l'activité est dans l'état avant la mise en pause.

Plus d'information: ici

Utiliser lint pour une analyse statique de votre code Android

Dominique Mereaux — Thu, 13 Mar 2014 16:07:26 +0100

Lint est un outil d'analyse statique qui permet de détecter des anomalies avant même d'entamer les tests unitaires. Pour pas cher il vous permettra de détecter des bugs potentiels.

Si vous télécharger le bundle de développement android il se trouve sous le répertoire Tools du sdk.

Il se lance en ligne de commande:

Le résultat est affiché directement dans la console mais il est possible de générer un rapport en utilisant l'option:

./lint --html report.html /Users/dominiquemereaux/Android/SpinnerTest
Regardons de plus près ce rapport:

Il m'informe que je n'ai pas précisé le SDK min et max que mon application est sensée supporter.
Il me donne également des conseils pour corriger:

Les problèmes détectés sont classés dans les catégories suivantes:

correctness
security
performance
usability
accessibility
internationalization

Vous trouverez la liste des problèmes détectés à cette adresse:
lien

Testlink 1.9.6 avec Mantis

Dominique Mereaux — Fri, 10 May 2013 17:38:26 +0200

Avec cette nouvelle version de testlink il devient de plus en plus facile d'intégrer un gestionnaire d'anomalie.

Déjà sur la version précédente, plus besoin de configurer des fichiers. Tout se fait désormais avec une interface. Dans l'exemple qui suit j'ai utilisé l'interface SOAP.

Un certain nombre d'informations doivent être renseignées:

Des identifiants pour se connecter.
L'url d'accès à Mantis.
Le projet Mantis ainsi qu'une catégorie du projet.

Une fois configurée, il est possible de tester la connexion à la base:

En cliquant sur l'outil, la connexion est tentée, ici l'icone indique que le lien est mal configuré. Pour plus d'informations sur le problème, l'onglet event donne des logs et en particuliers les erreurs:

Une fois la correction effectuée le test de connexion donnera:

Voyons maintenant la partie déclaration d'anomalie. Pour cela nous avons besoin d'un test exécuté:

Deux possibilités:

Lier le test à une anomalie existante avec son Id.
Créer automatiquement une anomalie avec des informations de testlink.

Une fois l'anomalie créée le lien est en place au niveau de l'exécution du test et permet d'accéder à l'anomalie pour la modifier:

Coté Mantis on obtient:

Avec cette nouvelle version de testlink déclarer des anomalies devient un jeu d'enfant.

Faire le lien avec testlink et Mantis sur les versions 1.9.5

Dominique Mereaux — Sun, 21 Apr 2013 15:16:26 +0200

Dans les nouvelles versions de testlink, le lien avec Mantis est plus simple. Finis les modifications dans les fichiers de configuration sujettes à erreur! Une nouvelle interface est disponible.

1ère étape:

Sélectionner dans le menu "gestion de projet de test" la fonction "Issue Tracker Management".

2ème étape:

Vous pouvez créer autant de connexion à des gestionnaires d'anomalie de type différent.

3ème étape:

Un exemple de configuration (show configuration example) vous est proposé ici pour Mantis (db).

4ème étape:

Maintenant il faut modifier le paramétrage du projet pour faire le lien avec le gestionnaire d'anomalie comme sur la copie d'écran ci-dessous:

5ème étape:

Vous pouvez désormais au moment de l'exécution du test (résultat) accéder à une popup (icône système d'anomalies) dans laquelle vous renseignerez le numéro d'anomalie:

Le lien est fait. Vous pouvez à partir de testlink accéder à Mantis et à la description de l'anomalie.

Outil d'analyse statique: jlint

Dominique Mereaux — Sun, 14 Apr 2013 20:06:26 +0200

Jlint est un outil d'analyse statique basé en particulier sur le "dataflow analysis" qui permet de détecter des erreurs avant même d'avoir exécuter le code. Ce type d'outil permet d'améliorer à moindre coût la maturité et la maintenabilité du code.

Exemples d'erreur détectée

"return always true": effectivement la variable locale deltaV est initialisée à 0 au début et comparée à 0!

shadows component of class 'echec/PieceEchiquier': la variable locale a le même nom que l'un des éléments de la classe:

La page d’accueil de l'outil:

Jlint

Les sources sont téléchargés sous forme de zip. Un makefile permet de générer l'exécutable sous n'importe quelle plateforme.

Il contient un autre outil complémentaire détectant des erreurs de code telle que le signe '=' utilisé au lieu de "==". Dans ce cas il faudra utiliser l'option -java pour un programme java.

Dans le zip vous trouverez également un pdf décrivant les types d'erreurs détectées.

Pourquoi utiliser un outil d'analyse de code

Dominique Mereaux — Mon, 01 Apr 2013 10:38:26 +0200

Diminution des coûts :

L’utilisation des outils d’analyse de code permet de faire de la prévention, c’est à dire trouver des défauts avant d’exécuter le code lors de tests unitaires, intégration ou système.

Exemple:

Lancement de l’outil sur un code java :

Résultat de l’analyse :

Détail du défaut :

Le test est effectivement toujours à vrai. Manque-t-il un appel une méthode pour calculer deltaV? Cette condition est-elle finalement inutile ?

Détecter un défaut à ce niveau permet une correction immédiate et limite de fait les coûts de test :

Le volume d’anomalies impacte le nombre de phases de tests nécessaire à l’obtention d’un niveau de qualité, et donc le coût (et les délais).
Le nombre de phases minimum est de trois, mais peu être plus élevé si la volumétrie d'anomalie est importante.
On pourrait mesurer l'efficacité de ces outils en calculant le nombre de défauts détectés répartis par gravité.

Maintenabilité, maturité :

Autre exemple : utilisation d’un résultat boolean d’une méthode de façon « inversée »

Visualisation du code :

Recherche de l’utilisation de la méthode :

Effectivement la négation est utilisée :

L’outil d’analyse propose même une correction automatique :

Ici je peux remplacer estValide par estNonValide, l’outil fera automatiquement les corrections y compris dans la fonction appelante.

En simplifiant le code (suppression des négations) je rend le code plus maintenable est évite les erreurs de codage liées à l’utilisation des négations.

Par une lisibilité plus importante, le coût de la maintenance pourra être diminuée.
Remarque, en offrant ces fonctions de corrections automatiques, la production de code devient plus efficace.

Les exemples ont été réalisés avec Intelliji IDEA.