J'ai toujours travaillé seul et ma méthode de test est généralement la compilation très souvent et en veillant à ce que les changements que j'ai réalisés fonctionnent bien et les réparer s'ils ne le font pas. Cependant, je commence à sentir que cela ne suffit pas et je suis curieux des types de tests standard.
Quelqu'un peut-il me parler des tests de base, un exemple simple de chacun, et pourquoi il est utilisé / ce qu'il teste?
merci.
4 Réponses :
Différentes personnes ont des idées légèrement différentes sur ce qui constitue quel type de test, mais voici quelques idées de ce que je pense à penser à chaque terme signifie. Notez que cela est fortement biaisé vers le codage côté serveur, car c'est ce que j'ai tendance à faire :)
test unitaire
Un test de l'unité doit uniquement tester une unité logique de code - typiquement une classe pour l'ensemble du boîtier de test et un petit nombre de méthodes dans chaque test. Les tests unitaires sont (idéalement) petits et bon marché. Les interactions avec des dépendances sont généralement isolées avec un double test tel qu'un simulacre, un faux ou un talon.
Test d'intégration
Un test d'intégration teste comment différents composants fonctionnent ensemble. Les services externes (ceux qui ne font pas partie de la portée du projet) peuvent toujours être trompés pour donner plus de contrôle, mais tous les composants du projet lui-même devraient être la chose réelle. Un test d'intégration peut tester tout le système ou un sous-ensemble.
test système
Un test système est comme un test d'intégration mais avec des services externes réels également. Si cela est automatisé, le système est généralement configuré dans un état connu, puis le client de test fonctionne indépendamment, en faisant des demandes (ou autre) comme un vrai client et d'observer les effets. Les services externes peuvent être de la production, ou celles installées dans un environnement de test.
test de sondage
Ceci est comme un test système, mais en utilisant les services de production pour tout. Celles-ci courent périodiquement pour garder une trace de la santé de votre système.
test d'acceptation
Ceci est probablement le terme le moins bien défini - au moins dans mon esprit; Cela peut varier de manière significative. Il sera typiquement de niveau assez élevé, comme un test système ou un test d'intégration. Les tests d'acceptation peuvent être spécifiés par une entité externe (une spécification standard ou un client).
Les tests peuvent également être des tests «Black Box», qui ne touchent jamais uniquement l'API public ou des tests «Box blanc» qui profitent de nouvelles connaissances supplémentaires pour faciliter les tests. Par exemple, dans un test de boîte blanche, vous savez peut-être qu'une méthode interne particulière est utilisée par toutes les méthodes d'API publique, mais est plus facile à tester. Vous pouvez tester beaucoup de cas d'angle en appelant directement cette méthode, puis effectuez moins de tests avec l'API publique. Bien sûr, si vous êtes concevoir l'API publique, vous devez probablement le concevoir pour pouvoir être facilement testable pour commencer - mais cela ne marche pas toujours de cette façon. Souvent, il est agréable de pouvoir tester un petit aspect isolément du reste de la classe.
D'autre part, le test de la boîte noire est généralement moins fragile que le test de la boîte blanche: par définition, si vous ne testez que ce que l'API garantit dans ses contrats, la mise en œuvre peut alors changer autant qu'il souhaite sans les tests. en changeant. Les tests de boîte blanche, d'autre part, sont sensibles aux modifications de mise en œuvre: si la méthode interne change subtilement - ou gagne un paramètre supplémentaire, par exemple, vous devez modifier les tests pour refléter cela.
Tout se résume pour équilibrer, à la fin - plus le niveau du test, plus il est probable que ce soit une boîte noire. Les tests unitaires, d'autre part, peuvent bien comprendre un élément de tests de boîte blanche ... au moins dans mon expérience. Il y a beaucoup de personnes qui refuseraient d'utiliser des tests de boîte blanche du tout, seulement jamais tester l'API publique. Cela se sent plus dogmatique que pragmatique pour moi, mais je peux aussi voir les avantages aussi.
Maintenant, comme pour où vous devriez aller prochain - le test unitaire est probablement la meilleure chose à faire. Vous pouvez choisir d'écrire les tests avant d'avoir conçu votre classe (développement axé sur les tests) ou à peu près au même moment, voire des mois, voire des mois (pas idéaux, mais il y a beaucoup de code qui n'a pas de test mais devrait) . Vous constaterez que certains de votre code sont plus prépénables à tester que d'autres ... Les deux concepts cruciaux qui rendent les tests réalisables (IMO) sont injection de dépendance (codage à interfaces et fournir des dépendances à votre classe plutôt que de les laisser instancier ces dépendances elles-mêmes) et test double (par exemple, des cadres moqueurs qui vous permettent de tester l'interaction ou de fausses implémentations qui font tout un moyen simple en mémoire). < / p>
+1 pour l'injection de dépendance et les tests doubles (pour la bonne TDD).
Qu'en est-il de ces tests "Boîte à blanc" et "Black-Box", j'entends?
Je suggérerais de lire au moins un livre à ce sujet, car le domaine est assez vaste et les livres ont tendance à synthétiser de meilleurs concepts. Par exemple. Une très bonne base pourrait être: Test de test logiciel sur l'ensemble du logiciel. Cycle de vie de développement (2007)
Je pense qu'un tel livre pourrait expliquer mieux tout que certains exemples de contexte que nous pourrions poster ici.
Salut ... Je voudrais ajouter à quelle réponse de Jon Skeet Sir .. Basé sur des tests de boîte blanche (ou des tests structurels) et des tests de boîte noire (ou des tests fonctionnels), les autres techniques de test sous chaque catégorie respective:
Test de stress
Ceci est utilisé pour tester des volumes en vrac de données sur le système. Plus que ce qu'un système prend normalement. Si un système peut supporter ces volumes, il peut sûrement bien prendre des valeurs normales.
Peut-être que vous pouvez prendre des conditions de dépassement du système comme essayer de retirer plus que la disponibilité de votre solde bancaire ne devrait pas fonctionner et retirer jusqu'à un seuil maximum devrait fonctionner.
Ceci peut être principalement utilisé, nous ne savons pas que les volumes jusqu'à votre système peuvent gérer.
test d'exécution
Fait pour vérifier à quel point un système est compétent.
Pour calculer le délai d'exécution des transactions.
test de récupération
Pour voir si un système peut récupérer au formulaire d'origine après une défaillance.
Un par exemple très courant. Dans la vie quotidienne, la restauration du système est présente dans Windows OS ..
Ils ont des points de restauration utilisés pour la récupération comme on le ferait bien.
Lorsqu'un utilisateur ressent une application essentielle à celui-ci à ce moment-là a cessé de fonctionner et devrait continuer à fonctionner, pour lequel il effectue une récupération.
D'autres types de tests que vous pouvez trouver utiliser comprennent: -
Test d'opérations
Test de conformité
test de sécurité
Test des exigences
Test de régression
Test de manipulation des erreurs
Test de support manuel
test intersystem
test de contrôle
test parallèle
Il y a un très bon livre intitulé "Méthodes efficaces pour les tests de logiciels" de William Perry of Qualy Assurance Institute (Qai) que je suggérerais, c'est un must à lire si vous souhaitez aller en profondeur W.R.T. Test de logiciel.
Plus sur les types de test mentionnés ci-dessus serait sûrement disponible dans ce livre.
Il existe également deux autres catégories de tests très larges, à savoir
test manuel : Ceci est fait pour les interfaces utilisateur.
test automatisé : test qui implique essentiellement des tests de boîte blanche ou des tests effectués
Grâce à des outils de test de logiciel tels que CHARGE Runner, QTP, etc.
Enfin je voudrais mentionner un type particulier de test appelé
Essais exhaustif
Vous essayez ici de tester toutes les conditions possibles, d'où le nom. C'est comme on noterait quasiment infaisable car le nombre de conditions de test pourrait être infini.
Tout d'abord, il y a divers tests que l'on peut effectuer. La question est de savoir comment l'organise-t-on. Le test est un processus vaste et de profusion.
commencer à tester avec 1. Tests de type. Une fois passé, allez-y avec des tests de fonctionnalité. C'est la colonne vertébrale des tests. Si la fonctionnalité fonctionne bien, 80% des tests sont rentables.
2.NOW Allez avec des tests d'interface utilisateur. Comme l'interface utilisateur temporelle est quelque chose qui attire le client plus que la fonctionnalité. C'est le look et sentez qu'un client devient plus attiré.
3.Now son temps d'examiner les bugs cosmétiques. Généralement, ces bugs sont ignorés à cause de la contrainte de temps. Mais ceux-ci jouent un rôle majeur en fonction de la page qui se trouve. Une erreur d'orthographe tourne pour être majeure lorsqu'elle est trouvée sur l'écran Splash ou votre page d'atterrissage ou le nom de l'application lui-même. Par conséquent, ceux-ci ne peuvent pas être négligés aussi.
4. Conduisez des tests de compatibilité. E, e Test sur diverses versions de navigateurs et de navigateurs. Peut être des appareils et des systèmes d'exploitation pour des applications réactives.
Tests heureux :)