Test en boîte noire (2)

peut fournir des statistiques intéressantes sur l’espérance de vie d’un système, au fur et à mesure que le nombre d’utilisateurs et le volume d’activité augmentent. Le test de charge consiste souvent à tester l’application en heure de pointe pour déterminer le maximum que l’on peut demander au système sans qu’il s’effondre.

Test de contrainte
Le test de contrainte consiste à tester l’application jusqu’au point de rupture. Beaucoup confondent le test de charge et le test de contrainte. Mais ils ont tort. L’objectif d’augmenter la charge du système jusqu’au point de rupture vise à tester une exigence qualitative : comment récupérer une fois que le système surchargé s’est effondré.

Test d’utilisabilité
Un système bien conçu offre aux utilisateurs une interface intuitive. En effet, une interface facile d’emploi joue un grand rôle dans le test d’acceptabilité des utilisateurs. Si nous faisons le nécessaire pour définir la spécification des exigences système (SRS, System Requirements Specification) et pour travailler avec les utilisateurs participant aux examens, et si nous respectons les standards courants et acceptés, nous devrions avoir – en théorie tout au moins – un niveau raisonnable d’acceptation pendant le test. Malheureusement, il est fréquent que ce qui se présente bien sur le papier ne fonctionne pas forcément bien dans la pratique.

Rien ne vaut de mettre le logiciel à l’épreuve dans un « environnement réel » simulé. Par exemple, nous pourrions constater que l’utilisation des touches de fonction programme est incohérente d’un programme à un autre dans une application sur écran vert, ou qu’une application de type navigateur est déroutante ou particulièrement lourde. Ou peut-être que l’exigence utilisateur demande d’afficher certaines informations, mais que le développeur a changé le dialogue de telle sorte que le groupage logique de l’information est divisé entre plusieurs écrans. Ce genre de problème n’apparaît pas bien souvent parce qu’on utilise de petits extraits de données. C’est pourquoi, dans la mesure du possible, il faut conduire le test système sur une base de données de taille production.

Test de sécurité
Cette forme de test s’est imposée au cours des dernières années face aux applications de type Web liées à l’utilisation d’informations personnelles comme des cartes de crédit. Pour des applications sur écran vert, l’exigence de sécurité peut être très simple : le créateur d’une demande d’achat a besoin d’une deuxième approbation si le montant de l’achat dépasse 1 000 $. Veillez donc à recueillir des exigences couvrant toute la gamme de sécurité.