Test logiciel

E n s e ig n a n t - ch e rc heur

y . b o u k o u c h i @ u i z . a c . m a

L E S F O N D A M E N T A U X D U

TEST LOGICIEL

Version 1.1 (Décembre 2017)

Plan

Introduction

Processus de test

Types de test

Activité tests

Jeu de tests

Principes de test

Outils de test

2

Prof. Youness BOUKOUCHI - ENSA d'Agadir

Introduction

3Prof. Youness BOUKOUCHI - ENSA d'Agadir

Introduction

L’erreur est humaine, presque tous les programmes contiennent des erreurs

Les erreurs sont difficiles à identifier:

Grande complexité des logiciels

Invisibilité du système développé

Pas de principe de continuité

L’activité de test est essentielle au développement de logiciels de qualité

lorsque les tests sont correctement réalisés et utilisés, ils permettent de découvrir des erreurs.

les tests mettent en avant des défaillances du logiciel, c’est-à-dire des fonctionnements anormaux aux vues de ses spécifications.

4

Définitions

Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus IEEE (Standard Glossary of Software Engineering Terminology)

Le test est une technique de contrôle consistant à s'assurer, au moyen de son exécution, que le comportement d'un programme est conforme à des données préétablies. AFCIQ : Association Française pour le Contrôle Industriel et la Qualité

Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts G. Myers (The Art of Software testing)

5

Erreur: commise par un développeur(Erreur de programmation ou Erreur de logique)

Défaut: état interne invalide d’un logiciel après l’activation d’une erreur

Défaillance ou anomalie: manifestation externe d’une faute, le comportement observé est différent du comportement attendu ou spécifié

La chaîne de l’erreur6

1. Erreur – mauvaise configuration des rails

2. Défaut – le chauffeur du train constate le problème et signale une alarme

3. Défaillance – les passagers du train n’arrivent pas à leur destination (ou pire, sont blessés ou sont morts!)

La chaîne de l’erreur8

Tester vs Déboguer

Tester et déboguer, ce n’est pas la même activité et les responsables sont différents:

Les testeurs testent

Les développeurs déboguent (Déboguer est une activité de développement permettant d’analyser, trouver et supprimer les causes de la défaillances)

9


Processus de test


Processus de test

un module n'est pas un programme isolé.

Il sera souvent nécessaire de mettre en place (simuler) un environnement pour tester unitairement un composant.

Ceci représente une charge supplémentaire de développement, qui doit être planifiée, car l'environnement mis en place pour chacun des composants à tester unitairement ne fait pas partie de la livraison.

11


Processus de test

Pilote

Module à tester

SoucheSouche Souche

Données de test Résultats

InterfaceOracle

12


Processus de test

Le rôle du pilote est de : Lire les données de test

Les passer au module à tester

On compare le résultat obtenu à la prédiction de l’ Oracle (verdict)

Les souches simuleront la logique de comportement. En général elles se contenteront de retourner une valeur fixe conforme aux paramètres passés.

Le rôle de l’oracle est de présenter les résultats attendus de l’exécution (verdict)

13

Processus de test

Spécification: trier un tableau par ordre croissant sans doublon

Choisir un scénario à exécuter (cas de test) S1: Un tableau est vide

S2: Un tableau contient des doublons

S3: Un tableau ne contient pas de doublons

Estimer le résultat attendu (oracle) O1: le résultat est un tableau vide

O2: le résultat est un tableau trié par ordre croissant sans doublon

O3: le résultat est un tableau trié par ordre croissant sans doublon

14


Processus de test

Interface : int[] mon_tri(int[] vec)

Etape 1 : On choisit un cas test (CT) à exécuter (un tableau non vide de N entiers sans doublons)

Etape 2 : On concrétise le cas test en lui fournissant des donnéesde test (DT): Le tableau [1,0,12,4,43,5,21]

Etape 3 : On indique le résultat que l’on attend pour ce CT (prédiction de l’Oracle): [1,0,12,4,43,5,21] [0,1,4,5,12,21,43]

Etape 4 : On exécute le pilote (script de test testant le CT sur les DT)

Etape 5 : On compare le résultat obtenu à la prédiction de l’Oracle (verdict)

Etape 6 : On rapporte le résultat du test : succès / échec

15


Cas de test: trier un tableau de 7 entiers

Processus de test

Pilote(Script de test)

Trier_tableau

DT:[1,0,12,4,43,5,21] Résultats

int[] mon_tri(int[] vec)

Oracle[0,1,4,5,12,21,43]verdictverdict

succès / échec

16

Processus de test

public class Calculator {

public int add(int x, int y)

{ return x + y; }

public int multi(int x, int y)

{return x*y;}

}

import static org.junit.Assert.*;

import org.junit.Test;

import ma.ensa.metier.Calculator;

public class CalculatorTest {

@Test

public void addTest() // tester l’addition

{ int a = 15; int b = 18; // données de test

Calculator calc = new Calculator();

int c = calc.add(a,b);

// 33 résultat attendu (Oracle) et c résultat actuel

assertEquals(33, c); // rapport de test

}

@Test

public void multiTest() // tester l’addition

{ int a = 5; int b = 5; // données de test

Calculator calc = new Calculator();

int c = calc.multi(a,b);

assertEquals(25, c);

}}

17


Types & Classes de test


CLASSIFICATION DES TESTS

Il existe différentes façons de classifier les tests.

Il est possible de les regrouper selon leur mode d’exécution,

leurs modalités,

leurs méthodes,

leurs niveaux,

leurs caractéristiques.

19



LE MODE D’EXECUTION Le test Manuel

Les tests sont exécutés par le testeur. Il saisie les données en entrée, vérifie les traitements et compare les résultats obtenus avec ceux attendus. Ces tests sont fastidieux et offrent une plus grande possibilité d’erreurs humaines. Ces tests sont très vite ingérables dans le cas d’applications de grandes tailles.

Le test Automatique L’automatisation des tests est « l’utilisation de logiciels pour exécuter

ou supporter des activités de tests, par exemple ; gestion des tests, conception des tests, exécution des tests ou vérification des résultats.». (JUnit par exemple dans le monde Java).

20



LES MODALITES DE TEST Statiques : Les tests sont réalisés «par l'humain» (testeur), sans

machine, par lecture du code dans le but de trouver des erreurs.Il peut s’agir : de l’inspection ou d’une revue de code; d’un travail de collaboration lors d’une réunion (le programmeur, le

concepteur, un programmeur expérimenté, un testeur expérimenté, un modérateur…)

Dynamiques : On exécute le système de manière à tester l’ensemble des caractéristiques. Chaque résultat est comparé aux résultats attendus.

21



LES METHODES DE TEST Structurels (Boîte blanche) : Les tests structurels reposent sur des

analyses du code source. Il est possible d’analyser la structure du programme.

Fonctionnels (Boîte noire) : Les tests fonctionnels reposent sur une spécification du programme. Le code source du programme n’est pas utilisé. Les tests fonctionnels permettent d’écrire les tests bien avant le «codage ». Il est parfois utile de combiner ces deux méthodes.

22


Tests unitairesTests unitaires Tests d’intégration

Tests d’intégration

Tests du système et de fonctionnement

Tests du système et de fonctionnement

Tests d’acceptation


Tests de régressionTests de

régression Béta-TestsBéta-Tests

LES NIVEAUX DE TEST

23


Tests unitaires

Les tests unitaires sont des tests en boîte blanche

Les tests unitaires sont composé d’un ensemble de classes appelées « classes de test »

Ces classes valident que des portions de code répondent à un certain besoin

Les tests unitaires sont importants car ils permettent de détecter le maximum de défaillance avant les tests en boîte noire et qu’ils peuvent s’exécuter d’une manière automatique

24


Tests unitaires

Les tests unitaires ont deux objectifs : « couverture de code » et « couverture de données »

La couverture du code stipule de tester chaque ligne de code écrite (appel de fonction, boucles, décisions, décisions multiples,…)

La couverture des données oriente les tests vers les données (données valides, données invalides, peu de données, trop de données,…etc)

25


Tests d’intégration

Exécuté en boîte noire ou boîte blanche

Les tests d’intégration vérifient que les composants s’intègrent bien avec d’autres composants ou systèmes

Les tests d’intégration vérifient aussi que le produit est compatible avec l’environnement logiciel et matériel du client

26


Tests fonctionnels

S’exécute en boîte noire

Vérifie que le produit assure les fonctionnalités spécifiées dans les spécifications fonctionnelles

27



S’exécute en boîte noire

Les tests d’acceptation sont des tests formalisés par le client, ils sont exigés par le client pour qu’il accepte le produit

28


Tests système

S’exécute en boîte noire, s’oriente vers les spécifications non fonctionnelles

Composé de plusieurs tests :

Tests de stress : tester le produit au-delà des attentes non fonctionnelles du client. Parexemple, un système de sauvegarde qui doit tout sauvegarder deux fois par jour, letester en mode trois fois par jour.

Tests de performance : évaluation par rapport à des exigences de performancesdonnées. Par exemple, un moteur de recherche doit renvoyer des résultats en moinsde 30 millisecondes.

Tests d’utilisabilité : vérifier les exigences d’apprentissage demandées à un utilisateurnormal pour pouvoir utiliser le produit

etc.

29


Tests de régression

Les tests de régression sont un sous-ensemble des tests originaux

Les tests de régression vérifient qu’une modification n’a pas eu d’effets de bord sur le produit

Les tests de régression sont utiles parce que la réexécution de tous les tests est très coûteuse

Test de non-régression : vérifier que la correction des erreurs n'a pas affecté les parties déjà développées et testées. Cela consiste à jouer et exécuter des nouveaux tests.

30


Béta-Tests

Quand un produit est quasiment terminé, il est distribué gratuitement à certains de ses utilisateurs

Ces utilisateurs sont appelés testeurs béta

Ces utilisateurs vont utiliser le produit et reporter tout éventuel disfonctionnement de celui-ci

31


Positionnement des types de tests32


Activité tests


L’ACTIVITÉ TEST

L’activité tests est un projet à part entière. C’est la raison pour laquelle nous retrouvons l’ensemble des caractéristiques d’un projet : Planification et contrôle (planification, estimation des charges, définition des

métriques, définition des environnements matériels et logiciels, définition de la campagne, du plan et des livrables)

Analyse et conception (organisation du référentiel, identification des conditions de tests, traçabilité, cas de tests, données de tests, procédures de tests, scénarios)

Implémentation, suivi, exécution et reporting

Gestion des configurations, Evaluation des risques et Gestion des incidents

Bilan projet et Clôture (recette ou arrêt des tests) et Amélioration des processus

36


LES ACTIVISTES LIÉES AUX TESTS37

1. Planifier les tests : c’est-à-dire prévoir où et en quelle quantité porter les efforts en personne et en temps ; il s’agit également de prévoir et de réserver l’utilisation de plates-formes de tests et les outils nécessaires ;

2. Spécifier les tests : c’est-à-dire préciser ce que l’on attend des tests en termes de détection d’erreurs (fonctionnel ou non fonctionnel par exemple), les techniques et les outils à utiliser ou à ne pas utiliser, les parties du logiciel sur lesquelles porteront les tests ;

3. Concevoir les tests : c’est-à-dire définir les scénarios de tests, appelés aussi cas de test, permettant de mettre en évidence des défauts recherchés par les tests, en fonction de leurs spécifications ; il s’agit aussi de préciser les environnements d’exécution de ces tests ;

4. Établir les conditions de tests : c’est-à-dire prévoir pour chaque scénario de tests les jeux de valeurs à fournir au logiciel pour réaliser ce scénario ;


LES ACTIVISTES LIÉES AUX TESTS38

5. Définir les conditions d’arrêt d’une campagne de tests : c’est-à-dire définir, en relation avec la phase de planification, ce qui permettra de décider l’arrêt ou la poursuite des tests ;

6. Contrôler les résultats : c’est-à-dire comparer les données fournies par l’exécution des tests par rapport aux données attendues ou constatées lors de phases précédentes de tests ;

7. Tracer les tests vis-à-vis des exigences grâce à une matrice de traçabilité : c’est-à-dire analyser en quoi les tests fournissent une exhaustivité de la recherche d’erreurs dans les attendus du logiciel. Cette matrice permet de vérifier qu’à toute exigence correspond au moins un scénario de test (mesure de la complétude des tests) et, à l’opposé, elle permet également de vérifier qu’un scénario de test sert à valiser au moins une exigence (mesure de l’efficacité des tests).


LA STRATEGIE DE TESTS

Une technique de tests adaptée et puissante restera sans effet si elle ne fait pas partie d’une stratégie de tests.

La stratégie de tests vise à rendre l’effort de test efficace en :

Maximisant les chances de détecter les erreurs.

Tentant de trouver le plus d’erreurs possibles, le plus rapidement possible.

Facilitant le diagnostique.

la stratégie de tests tient compte :

Des méthodes de spécification, de conception …

Du langage de programmation et du type d’application (temps réel, base de données…)

Des ressources humaines, les délais et budget

De la criticité du logiciel et du coût de développement

…

39


Plan Qualité Projet (PQP)

L’ensemble de la stratégie de tests est détaillé dans le Plan Qualité Projet (PQP).

Le plan qualité projet est très important. Il va notamment :

Définir l’organisation à mettre en place (équipe de tests).

Définir les responsabilités et relations entre les différents intervenants.

Définir les types et les objectifs de tests pour chacun des niveaux (tests unitaires, tests d’intégration, tests de validation).

Définir les outils qui seront utilisés.

Définir les moyens et les délais à investir dans l’activité de tests.

40


PLAN DE TESTS

Le plan de tests est un document obligatoiredéterminant le déroulement des tests durant le projet

C’est ainsi qu’il existe autant de plan de tests que de phases de qualification du produit.

De manière générale, les tests se déroulent du général au particulier (détail).

L’objectif de chaque plan de tests est de fournir un programme pour vérifier que le logiciel produit satisfait les spécifications et la conception du logiciel.

41


PLAN DE TESTS

Un plan de test doit :1. Définir les éléments à tester et l’ordre dans lequel ils doivent être testés

(planifier les tests).

2. Décrire l’environnement de tests.

3. Définir la façon dont les tests vont être menés (procédures) : processus exacts à mener, l’historisation, la traçabilité, le reporting, le suivi, le contrôle...

4. Décrire et constituer les fiches de tests (définir les actions à réaliser, les jeux de données à utiliser, les valeurs et les comportements attendus). L’ensemble des fiches de tests constitue le dossier de tests.

5. Fixer les critères d’arrêt des tests : selon la couverture définie, selon le nombre d’erreurs trouvés, selon le temps imparti… (Appliquer la stratégie de tests aux tests).

42


Le plan de tests

Le plan de tests détermine la priorisation des défaillances

La priorisation facilite la communication entre développeurs et testeurs ainsi que l’affectation et la planification des tâches

Par exemple, une priorisation de 1 à 6 est souvent adoptée:

Priorité Description

1 – Fatal Impossible de continuer les tests à cause de la sévérité des défaillances

2- Critique Les tests peuvent continuer mais l’application ne peut passer en mode production

3- Majeur L’application peut passer en mode production mais des exigences fonctionnelles importantes ne sont pas satisfaites

4- Medium L’application peut passer en mode production mais des exigences fonctionnelles sans très grand impact ne sont pas satisfaites

5- Mineur L’application peut passer en mode production, la défaillance doit être corrigée mais elle est sans impact sur les exigences métier

6- Cosmétique Défaillances mineures relatives à l’interface (couleurs, police, …) mais n’ayant pas une relation avec les exigences du client

43

RAPPORT DE TEST

Pour chaque phase de test l’équipe doit élaborer un rapport de tests.

Ce rapport est la synthèse des actions menées suivantes :

Exécution des fiches de tests (effectuer les actions décrites).

Analyser les résultats obtenus : comparer les résultats attendus avec les résultats obtenus. Les éléments de mesure sont très importants !

Emettre des fiches de non-conformité si nécessaire (ces fiches sont aussi appelées fiches d’anomalie, fiches de bug). Il s’agit de coupler intelligemment la gestion des tests et la gestion des corrections (incidents).

Consigner tous les résultats d’exécution de tests.

Rédiger des comptes rendus de tests. La somme de ces comptes rendus constituera le rapport de tests.

44


Jeu de test


Tests exhaustifs

Programme de 50-100 lignes 1boucles(1-20 itérations), 4

conditions imbriquées à l’intérieur de la boucle

1014 chemins d’exécution possibles

pour tester tous les chemins à raison d’un chemin par milliseconde! ~3174 ans

doif (…) then

if (…) thenif (…) thenelse …

else …if (…) thenelse …

elsewhile (i < 20)

46


Tests exhaustifs47

L’objet principal est d’analyser lecomportement d’un logiciel dans unenvironnement donné : ainsi, il ne serta priori à rien de tester le bonfonctionnement de la gestion dusystème de freinage d’une automobilepour une vitesse de 1000 km/h.


Tests exhaustifs

En général, tester un programme de façon exhaustive est impossible

Il faut choisir un sous-ensemble des tests qui maximise la probabilité de détecter les erreurs

Il est possible d’utiliser des tests aléatoires, mais leur efficacité est faible pour tester le comportement attendu.

Une meilleure approche: déterminer un ensemble de tests fonctionnels qui seront complémentés de tests structurels.

48


Approches des jeux de test

1- Approches de Test structurel:

couverture des instructions, des enchaînements

couverture des conditions

Couverture des conditions multiples

couverture des dépendances de données

49



Exemple : PGCD de 2 nombres Précondition: p et q entiers naturels positifs

-Tester tous les nœuds (les instructions):(E, B1, P1 , P2, B2, P1 , B4, S)(E, B1, P1 , P2, B3, P1 , B4, S)

-Tester tous les branches(les décisions):(E, B1, P1 , P2, B2, P1 , B4, S)(E, B1, P1 , P2, B3, P1 , B4, S)

-Tester 1-chemin élémentaire:(E, B1, P1 , B4, S)

-Tester deux chemins élémentaires:(E, B1, P1 , P2, B2, P1 , P2, B2, P1 , B4, S)(E, B1, P1 , P2, B2, P1 , P2, B3, P1 , B4, S)(E, B1, P1 , P2, B3, P1 , P2, B2, P1 , B4, S)(E, B1, P1 , P2, B3, P1 , P2, B3, P1 , B4, S)

etc.

50


Approches de Test fonctionnel:

couverture de scénarios d’utilisation

couverture des partitions des domaines d’entrée

couverture des cas limites

51


Exemples de Couverture des partitions des domaines d’entrée

les entrées est partitionnée en deux groupes :

Classes d’équivalence valides

Classes d’équivalence invalides

Plage de valeurs (ex:1..100)

Classes d’équivalence valides: 1..100

Classes d’équivalence invalides:<1, >100

Nombre de valeurs (ex:3 ou 4 arguments spécifiés)

Classes d’équivalence valides : {3,4} arguments spécifiés

Classes d’équivalence invalides: <3 arguments, >4 arguments spécifiés

Approches du jeu de test52


Approches du jeu de test

Exemples de Couverture des cas limites

En pratique, il est souvent bénéfique de tester les conditions de marge

Plage de valeurs : Écrire un test valide pour la valeur de début et celle de fin, et des tests invalides pour les conditions juste en dehors de la plage valide

ex: [-1..1]: tester -1, 1, -1.001, 1.001

Nombre de valeurs: Écrire un test pour le nombre minimum, le nombre maximum, un de moins que le nombre minimum et un de plus que la nombremaximum

ex:1..255 enregistrements: tester pour 0, 1, 255, 256

53



Soit la spécification suivante :

Un programme prend en entrée trois entiers. Ces trois entiers sont interprétés comme représentant les longueurs des cotés d’un triangle. Le programme rend un résultat précisant si il s’agit d’un triangle scalène, isocèle ou équilatéral.

Produire une suite de cas de tests pour ce programme

54



14 cas de test –GJ Myers –«The Art of Software Testing»- 19791. Cas scalène valide (1,2,3 et 2,5,10 ne sont pas valides)

2. Cas équilatéral valide

3. Cas isocèle valide (2,2,4 n’est pas valide)

4. Cas isocèle valide avec les trois permutations (e.g. 3,3,4; 3,4,3; 4,3,3)

5. Cas avec une valeur à 0

6. Cas avec une valeur négative

7. Cas ou la somme de deux entrées est égale à la troisième entrée

8. cas pour le test 7 avec les trois permutations

9. Cas ou la somme de deux entrées est inférieur à la troisième entrée

10. 3 cas pour le test 9 avec les trois permutations

11. Cas avec les trois entrées à 0

12. Cas avec une entrée non entière

13. Cas avec un nombre erroné de valeur (e.g. 2 entrées, ou 4)

14. Pour chaque cas de test, avez-vous défini le résultat attendu ?

55



Chacun de ces 14 tests correspond à un défaut constaté dans des implantations de cet exemple triangle

La moyenne des résultats obtenus par un ensemble de développeurs expérimentés est de 7.8 sur 14.

La conception de tests est une activité complexe, a fortiori sur de grandes applications

56


Les 7 Principes de test


Les 7 principes généraux des tests

Un nombre de principes de test ont été suggérés au cours des 40 dernières années et offrent des indications communes à tous les tests.

58



Principe 1 – Les tests montrent la présence de défautsLes tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas une preuve d’exactitude.

Principe 2 – Les tests exhaustifs sont impossiblesTout tester (toutes les combinaisons d’entrées et de préconditions) n’est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l’analyse des risques et des priorités pour focaliser les efforts de tests.

Principe 3 – Tester tôtPour trouver des défauts tôt, les activités de tests devraient commencer aussi tôt que possible dans le cycle de développement du logiciel ou du système, et devraient être focalisées vers des objectifs définis.

59



Principe 4 – Regroupement des défautsL’effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. Un petit nombre de modules contiennent généralement la majorité des défauts détectés lors des tests pré-livraison, ou affichent le plus de défaillances en opération.

Principe 5 – Paradoxe du pesticideSi les mêmes tests sont répétés de nombreuses fois, il arrivera que le même ensemble de cas de tests ne trouvera plus de nouveaux défauts. Pour prévenir ce “paradoxe du pesticide”, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d’autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts.

60



Principe 6 – Les tests dépendent du contexteLes tests sont effectués différemment dans des contextes différents. Par exemple, les logiciels de sécurité critique seront testés différemment d’un site de commerce électronique.Principe 7 – L’illusion de l’absence d’erreursTrouver et corriger des défauts n’aide pas si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs.

61


Les outils de test


LES OUTILS DE TEST

Le premier groupe concerne les outils d’aide à la réalisation des tests.

Capture et réexécution des scripts réalisés via une IHM.

Sauvegarde des tests et des résultats associés.

Génération de scripts de tests en fonction des langages et des plateformes

Outils

Mercury WinRunner et Quicktest Pro de Mercury Quality Center

QARUN de MicroFocus

ABBOT (open source)

Rational robot de IBM

Irise studio de Irise

63


LES OUTILS DE TEST

Le second groupe concerne les outils de campagne de tests.

Les outils de gestion des plans et campagnes de test servent à définir, organiser et conduire les campagnes de tests. Ils doivent donc s'interfacer avec tous les outils qui interviennent dans les tests.

Les outils:

Testdirector de Mercury Quality Center

Salomé TMF (open source)

Test Manager de SoftEdition.Net

QaDirector de MicroFocus

64


LES OUTILS DE TEST

Le troisième groupe concerne les tests fonctionnels (boite noire).

Les tests concernent l'analyse des spécifications du logiciel, sans tenir compte du code source. Le périmètre des contrôles englobe les interfaces utilisateurs, les API, la gestion des bases de données, la sécurité et le réseau. Il vérifie la conformité du fonctionnement d’un système vis-à-vis des exigences de l’utilisateur (se réfère au cahier des charges).

Les outils LEIRIOS Test Generator de LEIROS

Conformiq Test Generator de Conformiq Software

Mercury Functional Testing et Mercury Service Test

Test Vector Generation de T-VEC

AutoTester ONE de AutoTester

QACenter Enterprise Edition de Compuware

Quality Forge de TestSmith

Selenium (open source)

Rational Robot d'IBM

iRise Application Simulator de iRise

Mercury Business Process Testing de Mercury Interactive

TestView, WebFT de Radview

Seapine SQA de Seapine

SilkTest de Segue

Visual WebTester de Softbees -

eValid de Software Research

65


LES OUTILS DE TEST

Le quatrième groupe concerne les tests structurels (boite blanche).

Ces outils permettent de valider ce que fait le logiciel testé. Ils sont donc complémentaires aux outils de tests fonctionnels qui vérifient, eux, ce que doit faire le logiciel. Ces pourquoi des éditeurs ont créé des suites comprenant ces deux types de tests.

Les outils:

C++TEST, .TEST, JTEST, SOATEST et INSURE++ de PARASOFT

RATIONAL TEST REALTIME de IBM

XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC

66


LES OUTILS DE TEST

Le cinquième groupe concerne la performance des logiciels développés, quelque soit l’environnement. Le test de montée en charge.

La simulation d'un environnement spécifique.

L’évolution agressive de l'accès aux ressources

Les outils: Wapt de Softlogica (test de charge)

LoadRunner de Mercury quality center – (test de stress et de charge)

Siege (open source) (test de charge)

jMeter (open source) du groupe apache (test de performance)

QaLoad de MicroFocus (test de charge)

Performance Center de EMBARCADERO (test de performance)

Web Performance Load Tester de WebPerformance, inc (test de charge)

67


Conclusion


Conclusion

Les applications sont de plus en plus complexes, les volumes de données sont de plus en plus grands...

les tests sont aujourd’hui au centre de tous les intérêts : de nombreux progiciels ont vu le jour pour tester, gérer les versions… Des sociétés ont investi dans la création d’un service interne, véritable structure de tests. Rien ne peut être mis en production sans être validé par ce service.

L’Internet mobile, nouveau mode d’information et nouveau challenge pour les entreprises, est un support graphique différent nécessitant une programmation adaptée et donc des tests complémentaires.

69


MERCI DE VOTRE ATTENTION


Test logiciel

Software

Transcript of Test logiciel