| Romana | English | Francais | Deutsch |
Software Testing Romania
 


 

Méthodes de Test Logiciel

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.
 

 

 
   
   
Avantages de l'Outsourcing    
       
   
Test logiciel automatisé vs test manuels
   
Pourquoi Automatiser le Test Logiciel?