Test fonctionnel |
C’est
le test du type boîte noire canalisé sur la
vérification des requêtes de l’application
; ce type de test doit être exécuté
par les testeurs, fait qui n’exclut pas que les programmeurs
testent le code développé par eux (règle
qui s’applique dans tout stade du test) |
Méthode boîte noire
|
les essais tournent
autour du fonctionnement externe du système : les
détails d'implémentation des composants ne
sont pas connus (ou sciemment ignorés), et seul le
comportement extérieur est testé |
Méthode boîte blanche |
les détails d'implémentation
des composants sont ici tous connus, et le test teste spécifiquement
ces implémentations. |
Test fonctionnel
|
Test
unitaire |
Dans le premier stage
des tests, les fonctions ou les modules de code sont testés,
habituellement par les programmeurs, car ces tests supposent
une connaissance approfondie du design interne et du code
de l’application.. Pas toujours facile à exécuter,
sinon l’application n’a une architecture bien
structurée. Ce type de test peut nécessiter
le développement des drivers ou des programmes additionnels.
|
Test
d’intégration |
Ce type de test teste des
parties de l’application et l'intégration a
pour but de valider le fait que toutes les parties développées
indépendamment fonctionnent bien ensemble. Les parties
peuvent être modules de code, applications individuelles,
applications du type client ou serveur d’un réseau
etc. Le test d’intégration est notamment relevant
sur les systèmes client / serveur et sur les systèmes
distribués. |
Test système
|
On teste ici par la
méthode boîte noire la fiabilité et
la performance de l'ensemble du système, tant au
niveau fonctionnel que structurel, plutôt que de ses
composants. On teste aussi la sécurité, les
sorties, l'utilisation des ressources et les performances. |
Test
de recette |
Ce test doit confirmer que l'application
réponde d'une manière attendue aux requêtes
qui lui sont envoyées. Ce test permet d'adapter l'application
aux attentes des futurs clients. |
Test d’utilisabilité
|
Ce test doit valider si l’application
est facile à utiliser. Clairement ce test est subjectif
et il va dépendre des utilisateurs finals ou clients
visés. Les interviews, les enregistrements vidéo
des interrogations des clients ou d’autres techniques
peuvent être utilisées. Les programmeurs et les
testeurs ne sont pas indiqués pour ce teste. |
Test d’installation/
désintallation |
Tester le processus d’installation
/ désinstallation intégralement, partiellement
ou progressivement. |
Test bout à
bout |
Similaire au test système qui implique
le teste de l’entière application dans l’environnement
qui imite la situation réelle d’utilisation de
l’application dans l’interaction avec une base
de donnée, en utilisant un réseau de communication
ou en interaction avec d’autres components hardware,
application ou systèmes s’il est le cas. |
Sanity testing ou
smoke testing |
typically an initial testing effort to determine
if a new software version is performing well enough to accept
it for a major testing effort. For example, if the new software
is crashing systems every 5 minutes, bogging down systems
to a crawl, or corrupting databases, the software may not
be in a 'sane' enough condition to warrant further testing
in its current state |
Test
de régression |
Re - tester après avoir fixé
les bogues ou les modifications du logiciel ou de l’environnement.
Déterminer la nécessité de re - tester
peut être difficile, notamment si on est proche de la
fin du cycle de développement. Les outils de test automatisé
peuvent être extrêmement utiles pour ce type de
test. |
Test de compatibilité |
Tester la manière dont un logiciel
fonctionne dans une configuration spécifique du système,
sous un système d’exploitation spécifique,
dans un environnement de réseau particulier etc.
|
Test non fonctionnel |
Test
de performance |
Terme utilisé alternativement pour
les tests de volume et tests de charge. Dans le cas idéal
le test de performance (et d’autre types de tests) sont
prévus dans la documentation où sont spécifiés
les requêtes. |
Test de volume
|
Terme utilisé alternativement pour
les tests de charge et tests de performance. Terme utilisé
aussi pour décrire des testes similaires aux tests
fonctionnels à la différence que ces tests sont
roulés en appliquant des charges anormales ou par la
répétition exagérée de certaines
actions, demandes complexes à la base de donnée
etc |
Test de charge |
Tester une application sous de grandes charges,
comme par exemple tester un site web sous une série
de charges pour déterminer jusqu’à quel
point la réponse du système n’est plus
prompte ou craque. |
Test de récupération |
Tester comment un système récupère
les données après le craquement, erreurs du
système ou après d’autres catastrophes.
|
Test de craquement |
Utilisé alternativement avec test
de récupération |
Test de sécurité
|
Tester la manière dont le système
protège contre les accès interne ou externes
pas autorisés, endommagement par mauvaises intentions
etc ; peut nécessiter techniques de test sophistiquées. |
Autres méthodes
de test |
Tests d’exploration |
Utilisé souvent pour faire de tests
créatifs, informels qui ne portent pas sur un plan
ou cas de test formels et les testeurs apprennent l’application
en la testant. |
Tests ad- hoc |
Similaire aux tests d’exploration mais
qui supposent une connaissance du logiciel avant de commencer
à tester |
Tests contextuels |
Ce type de test est peut être exécuté
après une bonne connaissance de l’environnement,
culture et utilisation prévue pour le logiciel développée.
Par exemple on va avoir une
approche complètement différente pour un équipement
médical que pour un simple jeu de PC. |
Tests comparatifs |
Comparer les points faibles et points forts
des différentes applications pour en relever la compétitivité
des produits. |
Tests alpha |
Tester une application lorsque le développement
est presque fini et des changements mineurs peuvent être
faits à la suite de ce type de test. Couramment faits
par utilisateurs finals ou par d’autres que les testeurs
ou développeurs |
Tests beta |
Tester lorsque le développement et
les tests sont an principal terminés et on doit trouver
les bogues et problèmes finals avant de lancer la version
finale. Couramment faits par utilisateurs finals ou par d’autres
que les testeurs ou développeurs. |
Tests de mutation |
Une méthode pour déterminer
si un série de données à tester ou cas
de test sont utiles en introduisant délibérément
des nombreuses modifications de code (bogues) et puis re-tester
en utilisant les séries de données ou cas de
test pour voir si les « bogues » sont détectés.
Cette méthode implique de grandes ressources en matière
d’ordinateurs. |