Contexte

Il s’agissait d’un projet de taille moyenne, essentiellement orienté « gestion de dossier », réalisé en Java J2EE.

Fonctionnellement, l’application ne présentait pas de difficulté particulière (si ce n’est le problème classique, dans le cadre de l’automatisation, des exports Excel ou des alertes par courriel). Elle s’interfaçait avec une autre application java qui était totalement disponible et maitrisée.

Le principal challenge résidait dans l’utilisation de smartGWT comme framework pour la couche de présentation.

Le plan de test est géré intégralement dans l’outil Testlink.

Environnement technique

Les postes de développement étaient relativement standards : Windows 7, eclipse, Oracle XE, java 1.6.

L’environnement d’intégration et l’environnement de test étaient hébergés sur des serveurs Ubuntu. Côté intégration, c’est l’outil Jenkins qui était chargé de lancer les tests sur différentes plateformes (Windows, Linux, Firefox, IE).

Bien qu’encore en béta au démarrage du projet, c’est la version 2.0 de Selenium qui a été utilisée.

Mise en place

La mise en place à demander des efforts particuliers sur deux points : smartGWT et Jenkins.

Pour Jenkins, la configuration des différents plugins, certains comportant quelques bugs, a pris plus de temps qu’on ne l’avait imaginé. C’est notamment la remonté du résultat des tests vers Testlink qui a posé problème (pour pouvoir conserver, à tout moment, une vue globale sur l’exécution de l’ensemble de la campagne de test, partie manuelle et partie automatique).

Côté smartGWT, les identifiants des composants graphiques sont générés dynamiquement, ce qui pose problème pour automatiser les tests. Des solutions de contournement sont donnés avec le framework smartGWT, mais dans la pratique, beaucoup de choses restaient difficiles, voir impossibles.

Résultats

Malgré les différents blocages rencontrés (outre les problèmes d’interfaçage avec des éléments hors web), nous avons réussi à automatiser environ 65% des tests.

Les tests, essentiellement développés sous eclipse (sans passer systématiquement par Selenium IDE), sont relativement simples à faire évoluer, même si certaines fonctions de Selenium ont du être surchargées pour supporter smartGWT.

Le développement des tests automatiques a également eu un impact sur le développement de l’application elle même : certaines règles de codage ont été mises en place pour faciliter l’automatisation des tests.

The post Selenium et SmartGWT first appeared on Progideo.

Contexte

Dans le cadre d’un projet important (> 3000 JH) développé en ASP.Net et interfacé avec l’outil de recherche Autonomy, l’objectif était d’automatiser les tests de non régression.

L’application comportait de nombreux écrans très spécifiques et des composants graphiques très riches (pour la plupart issus des bibliothèques de l’éditeur Telerik, tout comme Test Studio).

L’application devait également manipuler de nombreux fichiers externes, essentiellement des fichiers PDF, des fichiers Word et des fichiers Excel. Elle reposait également sur un ensemble de bases de données partagées avec des applications déjà existantes, auxquels nous n’avions pas accès pour des raisons de confidentialité.

Environnement technique

Il s’agit donc d’un environnement essentiellement Microsoft, avec des postes développeur sous Windows 7, Visual Studio 2010, SQL server 2008.

Les serveurs de test et les serveurs d’intégration étaient virtualisés, composés de plusieurs serveurs pour l’applicatif, la base de données et le moteur de recherche Autonomy. Ces serveurs simulaient également l’environnement du client avec un AD dédié.

Les tests étaient exécutés sur Internet Explorer 7.0.

L’intégration continue était gérée par CruiseControl.NET.

Mise en place

La mise en place des outils n’a pas posé de problème particulier, tout étant géré depuis Visual Studio.

L’outil Test Studio était encore jeune, mais le support de Telerik nous a permis de résoudre ou contourner rapidement les problèmes rencontrés.

Il a surtout fallut trouver des solutions pour gérer les nombreuses interfaces techniques.

Résultats

L’automatisation a été rendu particulièrement difficile du fait du grand nombre d’interfaces avec des bases de données (pas toujours directement disponibles) ou des fichiers externes. Il a fallut mettre en place des « bouchons » ou trouver des astuces pour valider le bon fonctionnement du système.

La couverture des tests est donc satisfaisante sur la partie interface utilisateur, mais incomplète sur certains processus qui ne sont pas directement accessibles à l’utilisateur.

L’exécution d’un test de non régression laisse donc encore une part importante à l’intervention humaine, mais il s’agit essentiellement de vérifier certains résultats (dans des fichiers ou des courriels).

The post Test Studio et ASP.Net first appeared on Progideo.

Contexte

Il s’agissait de développer des tests fonctionnels automatiques pour une application web développée grâce au framework PHP Yii.

L’application est composée, pour l’essentiel, d’écrans de type « CRUD », c’est à dire permettant la création, la modification et la visualisation de données.

Les tests sont développés en même temps que le code, chaque livraison d’un module ou d’un écran étant accompagné d’un jeu de tests fonctionnels, destinés surtout à valider les règles de gestion associées à la création ou la modification des données.

Les tests servent donc à valider les développements de manière unitaire, mais sont également utilisés comme tests de non régression.

Environnement technique

Le poste de développement type fonctionne avec l’OS Ubuntu, l’IDE Netbeans et l’outil de modélisation MySQL Workbench.

Le serveur d’intégration est un serveur Ubuntu virtualisé, faisant office de serveur SVN et serveur d’intégration continue grâce à PHPUnderControl (migré ensuite sous Jenkins).

Pour l’exécution des tests fonctionnels, des machines virtuelles dédiées ont été installées, avec différents OS (Ubuntu, Windows XP, Windows 7) et différents navigateurs (IE6, IE8, Firefox, Safari, Chrome, Opera).

On utilise la version 1.0 de Selenium.

Mise en place

Le framework Yii intègre nativement la possibilité de créer des tests fonctionnels avec Selenium.

La mise en place de l’automatisation des tests est donc relativement simple et standardisée.

D’autre part, l’application est très uniforme et il a donc été facile de factoriser les procédures de test pour accélérer la rédaction des tests et faciliter leur maintenabilité.

Toutefois, il a fallu surmonter quelques difficultés techniques, surtout pour la mise en place du serveur d’intégration continue et l’utilisation de PHPUnit pour lancer les tests fonctionnels.

Résultats

En phase de maintenance, les tests fonctionnels sont exécutés à chaque modification du code.

Les régressions sont détectés immédiatement, et la mise à jour des tests fonctionnels se révèle, dans le contexte de ce projet, très peu coûteuse (que ce soit pour une correction ou une évolution).

Le risque lié à la maintenance est donc extrêmement réduit. Quelque soit l’impact de la modification, quelque soit la personne qui la réalise, les tests fonctionnels automatisés sont la garantie que la qualité de l’application est maintenue.

Il faut par contre s’assurer que les tests sont bien maintenus, comme le code. Si le test des évolutions n’est pas automatisé, ou si les tests qui échouent sont simplement supprimés, le système peut rapidement perdre de son efficacité et le coût de la maintenance augmenter brutalement.

The post Selenium et Yii first appeared on Progideo.