> Tech > Le test d’applications : un art méconnu

Le test d’applications : un art méconnu

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Colin Armitage
Les tests systématiques devraient être placés en haute priorité dans votre service informatique. Combien de temps votre département informatique passe-t-il à  corriger des erreurs et à  effectuer des modifications que vous auriez dû réaliser avant de déployer une application ? Si votre réponse est "beaucoup", alors vous devriez vous appesantir à  nouveau sur un aspect souvent négligé du développement d'applications : les tests.L'année dernière, à  l'occasion du lancement du produit TestBench400, mis sur le marché par mon entreprise, nous avons eu l'occasion de discuter des techniques de test applicatifs en environnement AS/400, avec plusieurs entreprises informatiques basées en Amérique du Nord et en Europe.

Cette expérience nous a permis d'acquérir une perspicacité unique dans les approches de tests en vigueur et dans la manière dont les techniciens professionnels perçoivent généralement l'équilibre indispensable coût/bénéfice quand il s'agit de tests.
La première chose dont nous nous sommes aperçus est le sérieux problème d'image dont souffre l'art de tester les logiciels.

En effet, ce domaine est largement perçu comme étant plus qu'obscur. Aussi, personne ne souhaite s'y investir. De plus, ceux qui acceptent de le faire, voudraient en finir le plus tôt possible. Considérez les scénarii de tests suivants :

La première chose dont nous nous sommes aperçus est le sérieux problème d'image dont souffre l'art de tester les logicielsTests unitaires.

Si vous travaillez sur un site où les développeurs ne sont pas responsables de leurs propres tests unitaires, alors félicitations. Le reste du monde doit avoir perdu la tête.

Après tout, pourquoi se donner tant de peine à  demander aux développeurs d'assurer le bon fonctionnent de leurs propres programmes ? D'une manière générale, les développeurs adorent développer mais ils ont horreur de tester. Seuls de rares et précieux développeurs essaient véritablement de tester les failles potentielles de leurs propre code de manière imaginative. Il ne faut que deux développeurs pour mettre en place une politique de vérification croisée.

En revanche, si on ne peut pas se le permettre, il faut se résigner à  accepter les tests unitaires réalisés par le programmeur ayant conçu le code tels qu'ils sont, c'est-à -dire, incertains.

Cependant, ces tests peuvent avoir un intérêt si vous fournissez des fiches de test prédéfinies et qui attesteront de l'adhésion à  des standards de conception (par exemple pour la présentation de rapports, les couleurs et la disposition des écrans), et de la fiabilité de tous les embranchements à  travers le programme.

Tests des systèmes.


Les tests des systèmes sont souvent réalisés par les membres seniors d'une équipe. Responsables de la livraison de systèmes dans leur ensemble, ces derniers sont généralement motivés pour réaliser les tests nécessaires.

Cependant, il y a deux obstacles majeurs à  la réalisation des tests de systèmes. En effet, les responsables informatiques planifient souvent les tests comme étant la dernière activité importante à  réaliser dans un cycle de développement. D'autre part, ces tests sont généralement programmés alors qu'une date de mise en production du logiciel a déjà  été fixée.

Aussi, lorsque les autres tâches du cycle de développement prennent du retard, le temps disponible pour effectuer les tests s'en trouvent réduits d'autant. Voilà  comment finalement on ne teste que ce que l'on peut, au lieu tester tout ce dont on a besoin.

Par ailleurs, la mauvaise qualité des tests unitaires oblige souvent les testeurs à  reprendre plusieurs fois une même série de tests des systèmes. Après le troisième ou quatrième cycle de tests, même le testeur le plus consciencieux ne testera plus que les corrections. C'est précisément à  ces moments là  que les bogues en profitent pour passer à  travers les mailles du filet.

Tests d'acceptation.

Dans certaines entreprises, les tests

Le test d’applications : un art méconnu

1. Définir les objectifs
des tests.
Définissez l’étendue des tests requis, les méthodes utilisées
pour effectuer les tests, le personnel impliqué et les conditions dans lesquelles
vous seriez prêt à  accepter le système.

2. Prévoirdes scripts de tests. Prévoyez des ensembles de données
de test comprenant des combinaisons possibles de transactions de gestion. Cette
étape doit définir les résultats attendus et les conditions qui doivent être remplies
pour que le résultat d’un test soit jugé satisfaisant.

3. Récupérer les données des tests. Bien que l’on puisse copier
une base de données active dans sa totalité, il est plus facile de vérifier 100
enregistrements que 100000. De plus, il se peut que vous soyez limité par l’espace
disque. Si vous effectuez des tests en utilisant des échantillons, vous devez
extraire un sous-ensemble représentatif par rapport aux relations existantes.

.4. Affiner les données des tests. Manipulez votre base de données
de tests afin de produire des combinaisons de données qui sollicitent correctement
le système. Cela inclut la remise à  l’état initial des champs statut, l’extension
des champs dates et la protection de renseignements confidentiels.

5. Définir l’environnement de tests. L’environnement de tests des
AS/400 doit être configuré de manière homogène pour tous les cycles de tests.
Cela inclut la base de données de tests, les zones des données, les paramètres
des programmes et les listes de bibliothèques.

6. Créer des scripts interactifs. Définissez les embranchements à  suivre
à  travers le système de test pour vous assurer que ce dernier est testé exhaustivement.
(Ce secteur constituait la principale préoccupation de la première génération
d’outils de test).

7. Tester les programmes batch et interactifs. Après une préparation
minutieuse, les tests se posent comme une opération plus simple. Un plus grand
défi consiste à  définir le niveau de test requis suite à  un échec.

8. Vérifier les écrans. Une approche exhaustive doit vous permettre de
vous assurer que tous les écrans satisfont aux critères aussi bien de présentation
que de contenu.

9. Vérifier les rapports.Même avec des volumes de données
de test de taille limitée, les rapports peuvent générer plusieurs pages. Des outils
de comparaison peuvent s’avérer utiles, à  condition qu’ils soient capables d’exclure
les champs qui changent constamment (par exemple les champs date et heure) du
système, et ceux dont le contenu peut légitiment varier entre deux cycles de test.


10. Vérifier la base de données.
On ne peut pas compter sur les écrans
et les rapports pour refléter correctement le contenu d’une base de données. Vérifiez-le
directement en utilisant des requêtes SQL, ou des programmes qui testent la conception
du système.

11. Vérifier tous les paramètres.Le développement d’applications
sur AS/400 encourage l’utilisation de la programmation modulaire, qui renvoie
des données comme paramètres. Les tests unitaires exigent de vérifier individuellement
tous les modules avant de les lier au système.

12. Vérifier le journal du job.Même si vous réalisez un
test sans rencontrer d’échec et atteignez les résultats attendus, vos programmes
peuvent se heurter à  des problèmes qui ne sont pas répertoriés du fait des moniteurs
de messages ou du paramétrage du job.

13. Vérifier les performances.Vérifiez les performances à  la fois
batch et interactives. Une routine de fin de journée peut fonctionner co rrectement
avec un échantillon de test de 100 enregistrements, et prendre 25 heures avec
des volumes de données de production !

14. Effectuer des tests de contre-vérification.Comparez
les résultats des rapports à  ceux des cycles de tests antérieurs et à  vos attentes.

15. Préparer des rapports en prévision des audits.Les services
d’audit interne et externe montrent un intérêt grandissant pour les services informatiques.
Ils peuvent réclamer des preuves (sous la forme d’enregistrements de tests) indiquant
que vous avez testé un système avant sa mise en production.

16. Suivre l’état d’avancement du projet.Suivez à  la trace l’état
d’avancement du projet de test. Des rapports réguliers sur l’état d’avancement
vous aideront à  respecter les délais et à  identifier rapidement une source de
retard probable.CA

Téléchargez cette ressource

Checklist de protection contre les ransomwares

Checklist de protection contre les ransomwares

Comment évaluer votre niveau de protection contre les ransomwares à la périphérie du réseau, et améliorer vos défenses notamment pour la détection des ransomwares sur les terminaux, la configuration des appareils, les stratégies de sauvegarde, les opérations de délestage... Découvrez la check list complète des facteurs clés pour améliorer immédiatement la sécurité des terminaux.

Tech - Par iTPro.fr - Publié le 24 juin 2010