static testing dynamic testing difference between these two important testing techniques
Le test est Verification ET VALIDATION . Nous savons tous qu'il faut 2 V pour terminer les tests.
Dans l'article d'aujourd'hui, nous allons faire la lumière sur Test statique . Il est également appelé vérification. Nous apprendrons tout à ce sujet et y porterons un accent particulier car Test dynamique reçoit souvent une attention maximale et a d'innombrables articles détaillant.
Cependant, aucune discussion sur les tests statiques ne serait complète sans une explication de ce que signifie son équivalent, le test dynamique. Le test dynamique est la validation, l'autre «V».
Le test dynamique est lorsque vous travaillez avec le système réel (pas un artefact ou un modèle qui représente le système), fournissant une entrée, recevant une sortie et comparant la sortie au comportement attendu. C'est un travail pratique avec le système dans le but de trouver des erreurs.
Au cours de ce processus, nous comprendrons en quoi les deux idées fausses suivantes sur les tests ne sont pas vraies:
- Le test est une activité qui vient à la fin
- Il est effectué uniquement par des testeurs et les autres n'ont rien à faire
Commençons par une référence rapide à la modèle v :
- Sur le côté gauche du modèle V, nous avons des activités qui ne sont pas réalisées par l'équipe d'assurance qualité.
- Sur le du côté de la main droite , nous en avons certains qui sont pris en charge par l'équipe de développement, certains par les testeurs et certains par les utilisateurs.
Commençons avec - Rassemblement des exigences . Il est effectué par l'analyste métier et d'autres responsables de niveau supérieur - le document de sortie pour cette phase est le document d'exigence métier, BRD.
La prochaine étape est la Conception du système . La conception du système est une phase où les exigences métier sont traduites en exigences fonctionnelles, dans le FRD (document des exigences fonctionnelles).
Lorsque la traduction est en cours, l'équipe de développement (qui est l'acteur principal de cette étape) va parcourir le document BRD étape par étape, page par page et ligne par ligne. Même si l'objectif principal est de consommer les exigences de l'entreprise pour des raisons de traduction, le document BRD est révisé à son tour.
Un exemple: Disons que c'est la BRD pour un site bancaire qui est grand sur la sécurité. Il y a une section dans la BRD qui parle des règles de mot de passe pour les différents utilisateurs créant un compte sur le site de banque en ligne. L'une des règles est: Un utilisateur ne peut pas utiliser un mot de passe qu'il utilise pour d'autres comptes.
Ce n'est pas faisable. Parce qu'un site peut simplement suggérer comment l'utilisateur doit définir les informations de connexion, mais il n'y a aucun moyen, cette restriction peut être imposée. Donc, cette exigence n'est pas réalisable - en d'autres termes, elle ne peut pas être accomplie par le logiciel.
VPN gratuit netflix Japon
Considérons maintenant les points suivants sur la base de cet exemple:
- Comment est-il déterminé que cette exigence n'est pas constructible et ne peut donc pas être testée (en d'autres termes, non réalisable)? Avons-nous le site de la banque, puis définissons-nous l'identifiant et le mot de passe - puis réalisons-nous que ce n'est pas possible? Non, nous nous basons simplement sur notre examen de la BRD et, bien sûr, sur le bon sens des affaires.
- Testons-nous cette exigence? Bien sûr, mais purement basé sur le sens théorique et conceptuel, mais pas sur l'AUT réel (Application under Test).
- Quelle est la forme physique de ce test? -Une lecture simple ou une revue formelle de la BRD ou une analyse de faisabilité encore plus formelle des besoins métiers.
Revenons à nos idées fausses:
- Qui effectue cet examen de la BRD? - Principalement l'équipe de développement et les autres équipes techniques qui sont responsables de la création du produit. Pas des testeurs.
- Cet examen est-il en cours à la fin de la création du produit? Non, au tout début du développement du projet. Par conséquent, pas seulement la fin.
Techniques de test statique:
Pour résumer, les tests statiques sont la partie vérification des tests logiciels qui suivent les méthodes suivantes:
- Revues de documents
- Procédures pas à pas
- Inspection
- Analyse de faisabilité ou toute autre forme d'analyse pour déterminer si le logiciel est ce qu'il devrait être ou non
- Revue de code
Pour citer le CSTE CBOK, 'La vérification répond à la question' Avons-nous construit le bon système? ' tandis que les validations abordent: 'Avons-nous bien construit le système?'
Voici toutes les activités de test statiques qui se produisent sur le côté gauche du modèle en V.
| Stade SDLC | Production | Vérifie | Acteurs |
|---|---|---|---|
| Collecte des besoins commerciaux | BRD (document sur les exigences commerciales) | Document sur la portée (le cas échéant) | |
| Conception des exigences du système | FRD (document d'exigence fonctionnelle) | Examine / vérifie la BRD | Dev, équipes techniques |
| Conception des exigences techniques | TDD (Document de conception technique) | Examine / vérifie le FRD | Dev, équipes techniques |
| Conception (code) | Code | Examine / vérifie le TDD. Examen du code par l'équipe de développement pour vérifier l'exhaustivité, le format, etc. | Dev, équipes techniques |
Noter: Ces informations peuvent être extrapolées pour les projets suivant toutes les méthodologies de développement car les étapes vont être plus ou moins similaires.
Sur le côté droit du modèle en V se trouve la validation.
Techniques de test dynamiques:
- Test unitaire
- Test d'intégration
- Test du système
Les phases Unité, intégration, système et UAT consistent à créer des tests à effectuer sur l'AUT au cours des différentes étapes de son développement. Même si les tests visent à valider différents types d'exigences, ce sont tous des tests identiques.
Ainsi, toute forme de test où nous avons un test qui doit être exécuté sur un AUT et sa sortie est nécessaire pour déterminer le résultat du test (réussi ou non) - c'est la validation.
Maintenant, serait-il correct de généraliser que du côté droit (RHS) du modèle en V, il n'y a aucune vérification? La réponse est non.
Tous les tests créés à chaque étape du RHS sont revus plusieurs fois lors de l'étape de création / finalisation des tests. Le processus détaillé d'examen de la documentation de test est à https://www.softwaretestinghelp.com/test-documentation-reviews/
Sur le RHS:
- Les tests et le code sont revus lors des étapes de test unitaires / d'intégration par les développeurs.
- Les tests système font l'objet d'un examen par les pairs au cours de leur documentation et, une fois terminés, sont soumis à un examen par l'équipe de développement et l'analyste commercial.
- Les tests UAT font l'objet d'un examen par l'équipe QA ainsi que par les utilisateurs avant le début de l'UAT.
Conclusion
En conclusion, les tests statiques sont une technique de test importante qui prend la forme d'une revue des exigences métier, d'une revue des exigences fonctionnelles, de revues de conception, de procédures pas à pas de code et de revue de la documentation de test. Il s'agit d'une activité continue et non effectuée uniquement par des testeurs.
Validation, la partie des tests dynamiques est plus pratique et se produit sur le produit lui-même et non sur un artefact ou une représentation du produit. Un processus très formel d'identification de cas de test / condition, de considérations de couverture, d'exécution et de rapport de défauts marquent tous les méthodes de test dynamiques.
À propos de l'auteur: Cet article est écrit par Swati S., membre de l'équipe STH.
Veuillez partager vos commentaires, questions et expériences sur le sujet des tests statiques et dynamiques.
lecture recommandée
- Différence entre les tests de bureau, client-serveur et Web
- Techniques d'estimation agile: une vraie estimation dans un projet agile
- Test de la boîte noire: un didacticiel approfondi avec des exemples et des techniques
- Qu'est-ce que les tests de conformité (tests de conformité)?
- Quelle est la différence entre les tests SIT et UAT?
- Test alpha et test bêta (un guide complet)
- Différences clés entre les tests de boîte noire et les tests de boîte blanche
- Les différences entre les tests unitaires, les tests d'intégration et les tests fonctionnels