Tests unitaires - logiciels fondamentaux d'essai
Tests unitaires fondamentaux
Tests unitaires est un niveau de tests de logiciels où les unités individuelles / composants d'un logiciel sont testés. Le but est de vérifier que chaque unité du logiciel effectue comme prévu.
cadres de tests unitaires, les conducteurs, les talons et les objets fantaisie / faux sont utilisés pour aider à des tests unitaires.
Définition par ISTQB
- tests unitaires: Voir les tests de composants.
- les tests de composants: Les tests de composants logiciels individuels.
Tests unitaires est effectuée en utilisant la méthode d'essai White Box.
Quand est-il effectué?
Unité de test est le premier niveau de test et est effectué avant le test d'intégration.
- Les tests unitaires augmente la confiance en changement de code / maintien. Si de bons tests unitaires sont écrits et si elles sont exécutées chaque fois qu'un code est changé, nous serons en mesure de prendre rapidement des défauts introduits en raison du changement. En outre, si les codes sont déjà faits moins interdépendants pour faire des tests unitaires possibles, l'impact involontaire des changements à tout code est moins.
- Les codes sont plus réutilisables. Afin de rendre possible les tests unitaires, les codes doivent être modulaire. Cela signifie que les codes sont plus faciles à réutiliser.
- Le développement est plus rapide. Comment? Si vous ne disposez pas des tests unitaires en place, vous écrivez votre code et effectuer que « test de développeur » floue (Vous définissez des points d'arrêt, lancez l'interface graphique, fournissez quelques entrées qui nous l'espérons frapper votre code et espérons que vous êtes tous ensemble. ) Si vous avez des tests unitaires en place, vous écrivez le test, écrire le code et le test. des tests d'écriture prend du temps, mais le temps est compensé par le moins de temps qu'il faut pour exécuter les tests; Vous ne devez pas le feu l'interface graphique et de fournir toutes les entrées. Et, bien sûr, les tests unitaires sont plus fiables que des « tests de développement. Le développement est plus rapide à long terme aussi. Comment? L'effort nécessaire pour trouver et corriger les défauts constatés lors de tests unitaires est très inférieur par rapport à l'effort nécessaire pour corriger les défauts constatés lors des essais du système ou des tests d'acceptation.
- Le coût de la fixation d'un défaut détecté pendant le test unitaire est moindre par rapport à celle des défauts détectés à des niveaux plus élevés. Comparez le coût (le temps, l'effort, la destruction, l'humiliation) d'un défaut détecté lors des tests d'acceptation ou lorsque le logiciel est en direct.
- Le débogage est facile. Lorsqu'un test échoue, ne doivent être débogué les dernières modifications. Avec les tests à des niveaux plus élevés, les changements effectués au cours de la période de plusieurs jours / semaines / mois doivent être scannés.
- Les codes sont plus fiables. Pourquoi? Je pense qu'il n'y a pas besoin d'expliquer cela à une personne saine d'esprit.
- Trouver un outil / cadre pour votre langue.
- Ne pas créer des cas de test pour tout. Au lieu de cela, se concentrer sur les tests qui ont une incidence sur le comportement du système.
- Isoler l'environnement de développement de l'environnement de test.
- Utiliser les données de test qui est proche de celle de la production.
- Avant de fixer un défaut, écrire un test qui expose le défaut. Pourquoi? Tout d'abord, vous pourrez par la suite de prendre le défaut si vous ne fixez pas correctement. Deuxièmement, votre suite de test est maintenant plus complet. Troisièmement, vous serez très probablement trop paresseux pour écrire le test après avoir déjà fixé le défaut.
- Ecrire des cas de test qui sont indépendants les uns des autres. Par exemple, si une classe dépend d'une base de données, ne pas écrire un cas qui interagit avec la base de données pour tester la classe. Au lieu de cela, créer une interface abstraite autour de cette connexion de base de données et mettre en œuvre cette interface avec objet fantaisie.
- Visez à couvrir tous les chemins à travers l'unité. Portez une attention particulière aux conditions de boucle.
- Assurez-vous que vous utilisez un système de contrôle de version pour garder une trace de vos scripts de test.
- Outre les cas d'écriture pour vérifier le comportement, écrire des scénarios pour assurer une performance du code.
- Effectuer des tests unitaires en continu et fréquemment.
Disons que vous avez un programme comprenant deux unités et le test que vous effectuez est le test du système. [Vous sautez tests unitaires et d'intégration.] Au cours du test, vous trouvez un bug. Maintenant, comment allez-vous déterminer la cause du problème?
- Le bug en raison d'une erreur dans l'unité 1?
- Le bug en raison d'une erreur dans l'unité 2?
- Le bug en raison d'erreurs dans les deux unités?
- Le bug en raison d'une erreur dans l'interface entre les unités?
- Le bug en raison d'une erreur dans le cas de test ou un test?
Les tests unitaires est souvent négligée, mais il est, en fait, le niveau le plus important des tests.