- Interview ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre nov\u00e1\u010dikov<\/a><\/li>
- Ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre pokro\u010dil\u00fdch<\/a><\/li><\/ul><\/div>\n
- \n
- <\/li>\n<\/ul>\n\n
Questions d’entretien sur les tests manuels pour les nouveaux arrivants<\/h2>\n\n
Question no. 1. Qu’entendez-vous par tests de logiciels ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de logiciel est le processus d’\u00e9valuation d’un syst\u00e8me pour v\u00e9rifier s’il r\u00e9pond aux exigences de l’entreprise. Il mesure la qualit\u00e9 globale du syst\u00e8me en termes d’attributs tels que l’exactitude, l’exhaustivit\u00e9, la facilit\u00e9 d’utilisation, la performance, etc. Fondamentalement, il est utilis\u00e9 pour garantir la qualit\u00e9 du logiciel pour les parties prenantes de l’application.<\/p>\n\n
Question no. 2. Pourquoi les tests sont-ils n\u00e9cessaires ?<\/strong>
- \n
- Les tests donnent aux parties prenantes l’assurance que le produit fonctionne comme pr\u00e9vu.<\/li>\n\n\n\n
- Les bogues \u00e9vitables qui sont divulgu\u00e9s \u00e0 l’utilisateur final\/client sans avoir \u00e9t\u00e9 test\u00e9s correctement donnent une mauvaise r\u00e9putation \u00e0 l’entreprise de d\u00e9veloppement.<\/li>\n\n\n\n
- Les bogues d\u00e9couverts plus t\u00f4t dans le cycle de d\u00e9veloppement durable permettent de r\u00e9duire les co\u00fbts et l’utilisation des ressources pour la r\u00e9paration.<\/li>\n\n\n\n
- Permet de gagner du temps en d\u00e9tectant les probl\u00e8mes plus t\u00f4t dans le processus de d\u00e9veloppement.<\/li>\n\n\n\n
- L’\u00e9quipe de test ajoute une autre dimension au d\u00e9veloppement de logiciels en apportant une perspective diff\u00e9rente sur le processus de d\u00e9veloppement du produit.<\/li>\n<\/ul>\n\n
Question 3. Quand devons-nous cesser de tester le logiciel ?<\/strong>
- \n
- Apr\u00e8s l’ex\u00e9cution des cas de test – la phase de test peut \u00eatre arr\u00eat\u00e9e lorsqu’un cycle complet de cas de test avec un pourcentage de r\u00e9ussite convenu a \u00e9t\u00e9 ex\u00e9cut\u00e9 apr\u00e8s la derni\u00e8re correction d’erreur connue.<\/li>\n\n\n\n
- Une fois les d\u00e9lais de test respect\u00e9s – Les tests peuvent s’arr\u00eater une fois les d\u00e9lais respect\u00e9s, lorsqu’il ne reste plus de probl\u00e8mes hautement prioritaires dans le syst\u00e8me.<\/li>\n\n\n\n
- Bas\u00e9 sur le temps moyen entre deux d\u00e9faillances (MTBF) – Le MTBF est l’intervalle de temps entre deux d\u00e9faillances. En fonction des d\u00e9cisions des parties prenantes, si le MTBF est relativement \u00e9lev\u00e9, la phase d’essai peut \u00eatre interrompue.<\/li>\n\n\n\n
- Sur la base de la valeur de la couverture du code – La phase de test peut \u00eatre arr\u00eat\u00e9e lorsque la couverture du code automatis\u00e9e atteint un certain seuil avec un pourcentage suffisant de r\u00e9ussite et sans erreur critique.<\/li>\n<\/ul>\n\n
Question no. 4. Qu’est-ce que l’assurance qualit\u00e9 et quelles sont les diff\u00e9rentes activit\u00e9s impliqu\u00e9es dans l’assurance qualit\u00e9 ?<\/strong><\/p>\n\n
R : L’assurance qualit\u00e9 est une approche qui permet de v\u00e9rifier que le processus de d\u00e9veloppement du produit est correct et conforme \u00e0 toutes les normes. Elle est consid\u00e9r\u00e9e comme une mesure pr\u00e9ventive. Il identifie les failles dans le processus de d\u00e9veloppement du logiciel. Comprend des activit\u00e9s telles que l’examen des documents, l’examen des cas de test, les visites, l’inspection, etc.<\/p>\n\n
Question no. 5. Qu’est-ce que le contr\u00f4le de la qualit\u00e9 et quels sont les diff\u00e9rents types de tests impliqu\u00e9s dans le contr\u00f4le de la qualit\u00e9 ?<\/strong><\/p>\n\n
R : Le contr\u00f4le de la qualit\u00e9 est une approche ax\u00e9e sur le produit qui permet de v\u00e9rifier si la solution d\u00e9velopp\u00e9e r\u00e9pond \u00e0 toutes les exigences sp\u00e9cifi\u00e9es. Elle est consid\u00e9r\u00e9e comme une mesure corrective parce qu’elle teste le produit cr\u00e9\u00e9 afin de trouver des erreurs. Il comprend diff\u00e9rents types de tests tels que les tests fonctionnels, les tests de performance, les tests de convivialit\u00e9, etc.<\/p>\n\n
Question no. 6. Quelle est la diff\u00e9rence entre la v\u00e9rification et la validation ?<\/strong>
1.<\/span><\/td> La v\u00e9rification est le processus d’\u00e9valuation de divers artefacts ainsi que du processus de d\u00e9veloppement de logiciels. Elle est effectu\u00e9e pour s’assurer que le produit en cours de d\u00e9veloppement est conforme aux normes.<\/td> La validation est le processus qui consiste \u00e0 v\u00e9rifier qu’un produit logiciel d\u00e9velopp\u00e9 est conforme aux exigences professionnelles sp\u00e9cifi\u00e9es.<\/td><\/tr> 2.<\/span><\/td> Il s’agit d’un processus statique d’analyse des documents, et non du produit final.<\/td> Il s’agit de tester de mani\u00e8re dynamique un produit logiciel en l’ex\u00e9cutant.<\/td><\/tr> 3.<\/span><\/td> La v\u00e9rification est une approche ax\u00e9e sur le processus.<\/td> La validation est une approche ax\u00e9e sur le produit.<\/td><\/tr> 4.<\/span><\/td> Il r\u00e9pond \u00e0 la question : \u00ab\u00a0Sommes-nous en train de construire le bon produit ?\u00a0\u00bb.<\/td> Il r\u00e9pond \u00e0 la question : \u00ab\u00a0Construisons-nous le bon produit ?\u00a0\u00bb<\/td><\/tr> 5.<\/span><\/td> Les erreurs d\u00e9tect\u00e9es pendant la validation n\u00e9cessitent moins de co\u00fbts\/ressources pour \u00eatre corrig\u00e9es que les erreurs d\u00e9tect\u00e9es pendant la phase de validation.<\/td> Les erreurs d\u00e9tect\u00e9es lors de la validation n\u00e9cessitent davantage de co\u00fbts\/ressources. Un d\u00e9faut d\u00e9couvert plus tard a un co\u00fbt de r\u00e9paration plus \u00e9lev\u00e9.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Question no. 7. Qu’est-ce que le SDLC (Software Development Life Cycle) ?<\/strong>
Question 8. Expliquez le cycle de vie des tests de logiciels (STLC).<\/strong>
- \n
- Analyse et validation des exigences – Au cours de cette phase, les documents relatifs aux exigences sont analys\u00e9s et valid\u00e9s, et la port\u00e9e des tests est d\u00e9finie.<\/li>\n\n\n\n
- Planification des tests – Cette phase d\u00e9finit la strat\u00e9gie du plan de test, l’estimation de l’effort de test ainsi que la strat\u00e9gie d’automatisation et la s\u00e9lection des outils.<\/li>\n\n\n\n
- Conception et analyse des tests – Ici, les cas de test sont con\u00e7us, les donn\u00e9es de test sont pr\u00e9par\u00e9es et les scripts d’automatisation sont mis en \u0153uvre.<\/li>\n\n\n\n
- Mise en place d’un environnement de test – Un environnement de test est pr\u00e9par\u00e9 pour simuler avec pr\u00e9cision l’environnement r\u00e9el.<\/li>\n\n\n\n
- Ex\u00e9cution des tests – Les cas de test sont pr\u00e9par\u00e9s, les bogues sont signal\u00e9s et test\u00e9s \u00e0 nouveau une fois qu’ils ont \u00e9t\u00e9 r\u00e9solus.<\/li>\n\n\n\n
- Cl\u00f4ture des tests et rapports – Un rapport de cl\u00f4ture des tests sera pr\u00e9par\u00e9 pour r\u00e9sumer les r\u00e9sultats finaux des tests, les conclusions et les mesures des tests.<\/li>\n<\/ul>\n\n
Question no. 9. Quels sont les diff\u00e9rents types de tests ?<\/strong>
- \n
- Tests fonctionnels – Les tests fonctionnels consistent \u00e0 v\u00e9rifier les sp\u00e9cifications fonctionnelles du syst\u00e8me.<\/li>\n\n\n\n
- Tests non fonctionnels – Les tests non fonctionnels sont un type de test qui consiste \u00e0 tester les exigences non fonctionnelles d’un syst\u00e8me, telles que les performances, l’\u00e9volutivit\u00e9, la s\u00e9curit\u00e9, la r\u00e9silience, la portabilit\u00e9, etc.<\/li>\n<\/ul>\n\n
Selon la mani\u00e8re dont les tests sont effectu\u00e9s, ils peuvent \u00eatre class\u00e9s dans l’une ou l’autre des cat\u00e9gories suivantes :<\/p>\n\n
- \n
- Tests bo\u00eete noire – dans les tests bo\u00eete noire, le testeur n’a pas besoin de conna\u00eetre l’architecture interne ou la mise en \u0153uvre du syst\u00e8me. Le testeur communique avec le syst\u00e8me par l’interm\u00e9diaire d’une interface, fournit des donn\u00e9es d’entr\u00e9e et v\u00e9rifie les donn\u00e9es de sortie re\u00e7ues.<\/li>\n\n\n\n
- Tests bo\u00eete blanche – Dans les tests bo\u00eete blanche, le testeur analyse l’architecture interne du syst\u00e8me ainsi que la qualit\u00e9 du code source sur la base de divers param\u00e8tres tels que l’optimisation du code, la couverture du code, la r\u00e9utilisabilit\u00e9, etc.<\/li>\n\n\n\n
- Tests en bo\u00eete grise – Dans les tests en bo\u00eete grise, le testeur a un acc\u00e8s partiel \u00e0 l’architecture interne du syst\u00e8me, par exemple le testeur peut avoir acc\u00e8s aux documents de conception ou \u00e0 la structure de la base de donn\u00e9es. Ces informations aident le testeur \u00e0 mieux tester l’application.<\/li>\n<\/ul>\n\n
Question no. 10. Qu’est-ce qu’un test manuel ?<\/strong>
Question.11. Qu’est-ce qu’un test automatis\u00e9 ?<\/strong>
Question no. 12. Quels sont les avantages des tests automatis\u00e9s ?<\/strong>
- \n
- L’automatisation des tests est rapide et permet de gagner beaucoup de temps.<\/li>\n\n\n\n
- Des scripts de test soigneusement r\u00e9dig\u00e9s \u00e9liminent la possibilit\u00e9 d’une erreur humaine pendant les tests.<\/li>\n\n\n\n
- L’ex\u00e9cution des tests peut \u00eatre programm\u00e9e pour une ex\u00e9cution nocturne \u00e0 l’aide d’outils CI tels que Jenkins, qui peuvent \u00e9galement \u00eatre configur\u00e9s pour fournir les r\u00e9sultats des tests aux parties prenantes concern\u00e9es sur une base quotidienne.<\/li>\n\n\n\n
- Les tests automatis\u00e9s sont tr\u00e8s gourmands en ressources. Apr\u00e8s l’automatisation des tests, l’ex\u00e9cution des tests n’exige pratiquement plus de temps de la part de l’assurance qualit\u00e9.<\/li>\n<\/ul>\n\n
Question no. 13. Quels sont les inconv\u00e9nients des tests automatis\u00e9s ?<\/strong>
- \n
- Elle n\u00e9cessite des experts en tests automatis\u00e9s comp\u00e9tents qui \u00e9crivent des scripts de test.<\/li>\n\n\n\n
- Un effort suppl\u00e9mentaire est n\u00e9cessaire pour r\u00e9diger les scripts.<\/li>\n\n\n\n
- Les scripts d’automatisation sont limit\u00e9s \u00e0 la validation des tests cod\u00e9s. Ce test peut passer \u00e0 c\u00f4t\u00e9 d’une erreur tr\u00e8s perceptible et facilement identifiable par un humain (AQ manuelle).<\/li>\n\n\n\n
- M\u00eame une modification mineure de l’application n\u00e9cessite des mises \u00e0 jour et une maintenance des scripts.<\/li>\n<\/ul>\n\n
Question no. 14. Qu’est-ce qu’un test de performance ?<\/strong>
\n![\"Tests](\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/06\/perfomance-testing-1024x1008.webp\")
Tests de performance<\/figcaption><\/figure>\n<\/div>\n Question no. 15. Qu’est-ce qu’un environnement de test ?<\/strong>
Question 16. Qu’est-ce qu’un plan de test ?<\/strong>
Question no. 17. Qu’est-ce qu’un sc\u00e9nario de test ?<\/strong>
Question no. 18. Qu’est-ce qu’un sc\u00e9nario de test ?<\/strong>
Question no. 19. Quelles sont les caract\u00e9ristiques d’un sc\u00e9nario de test ?<\/strong>
- \n
- TestCaseId – Identifiant unique du cas de test.<\/li>\n\n\n\n
- R\u00e9sum\u00e9 du test – R\u00e9sum\u00e9 sans ambigu\u00eft\u00e9 du cas de test.<\/li>\n\n\n\n
- Description – Description d\u00e9taill\u00e9e du cas de test.<\/li>\n\n\n\n
- Pr\u00e9alable ou condition pr\u00e9alable – Ensemble de conditions pr\u00e9alables qui doivent \u00eatre remplies avant que les \u00e9tapes du test puissent \u00eatre ex\u00e9cut\u00e9es.<\/li>\n\n\n\n
- \u00c9tapes du test – \u00c9tapes d\u00e9taill\u00e9es de l’ex\u00e9cution d’un cas de test.<\/li>\n\n\n\n
- R\u00e9sultat attendu – R\u00e9sultat attendu pour la r\u00e9ussite du test.<\/li>\n\n\n\n
- R\u00e9sultat r\u00e9el – Le r\u00e9sultat r\u00e9el apr\u00e8s l’ex\u00e9cution des \u00e9tapes du test.<\/li>\n\n\n\n
- R\u00e9sultat du test – Statut de r\u00e9ussite ou d’\u00e9chec du test.<\/li>\n\n\n\n
- Statut d’automatisation – Identifiant d’automatisation, indiquant si l’application est automatis\u00e9e ou non.<\/li>\n\n\n\n
- Date – La date \u00e0 laquelle le test a \u00e9t\u00e9 effectu\u00e9.<\/li>\n\n\n\n
- Ex\u00e9cut\u00e9 par (Ex\u00e9cut\u00e9 par – Nom de la personne qui ex\u00e9cute le cas de test).<\/li>\n<\/ul>\n\n
Question no. 20. Qu’est-ce qu’une donn\u00e9e d’essai ?<\/strong>
Question no. 21. Qu’est-ce qu’un script de test ?<\/strong>
Question no. 22. Qu’est-ce qu’une erreur de test de logiciel ?<\/strong>
Question no. 23. Qu’est-ce qu’un \u00ab\u00a0bug\u00a0\u00bb ?<\/strong>
Question no. 24. Qu’est-ce qu’un \u00ab\u00a0d\u00e9faut\u00a0\u00bb ?<\/strong>
Question no. 25. Quelles sont les caract\u00e9ristiques du signalement des d\u00e9fauts ?<\/strong>
- \n
- DefectId – Identifiant unique du d\u00e9faut.<\/li>\n\n\n\n
- R\u00e9sum\u00e9 du d\u00e9faut – un r\u00e9sum\u00e9 d’une ligne du d\u00e9faut, plut\u00f4t que le nom du d\u00e9faut.<\/li>\n\n\n\n
- Description du d\u00e9faut – description d\u00e9taill\u00e9e du d\u00e9faut.<\/li>\n\n\n\n
- Marche \u00e0 suivre pour reproduire l’erreur – marche \u00e0 suivre pour reproduire l’erreur.<\/li>\n\n\n\n
- R\u00e9sultat attendu – le comportement attendu dont l’application s’\u00e9carte en raison d’une erreur.<\/li>\n\n\n\n
- R\u00e9sultat r\u00e9el – l’\u00e9tat actuel de l’application li\u00e9e \u00e0 l’erreur.<\/li>\n\n\n\n
- Gravit\u00e9 de l’erreur – En fonction de la criticit\u00e9 de l’erreur, ce champ peut \u00eatre d\u00e9fini comme mineur, moyen, majeur ou bloquant.<\/li>\n\n\n\n
- Priorit\u00e9 – En fonction de l’urgence de l’erreur, ce champ peut \u00eatre d\u00e9fini sur une \u00e9chelle allant de P0 \u00e0 P3.<\/li>\n<\/ul>\n\n
Question no. 26. Quels sont les outils permettant de g\u00e9rer les bogues ou les d\u00e9fauts ?<\/strong>
Question no. 27. Qu’est-ce que la densit\u00e9 de d\u00e9fauts ?<\/strong>
Question no. 28. Qu’est-ce que la priorit\u00e9 aux d\u00e9fauts ?<\/strong>
Question no. 29. Qu’est-ce que la gravit\u00e9 des d\u00e9fauts ?<\/strong>
Question no. 30. Donnez un exemple de d\u00e9fauts de faible priorit\u00e9 – faible gravit\u00e9, de faible priorit\u00e9 – forte gravit\u00e9, de forte priorit\u00e9 – faible gravit\u00e9 et de forte priorit\u00e9 – forte gravit\u00e9.<\/strong>
- \n
- Faible priorit\u00e9 – faible gravit\u00e9 : une faute d’orthographe sur une page que les utilisateurs ne consultent pas fr\u00e9quemment.<\/li>\n\n\n\n
- Faible priorit\u00e9 – Gravit\u00e9 \u00e9lev\u00e9e : applications en cas d’accident dans certains cas tr\u00e8s marginaux.<\/li>\n\n\n\n
- Priorit\u00e9 \u00e9lev\u00e9e – Gravit\u00e9 faible : un l\u00e9ger changement de couleur du logo ou une faute d’orthographe dans le nom de l’entreprise.<\/li>\n\n\n\n
- Priorit\u00e9 \u00e9lev\u00e9e – Gravit\u00e9 \u00e9lev\u00e9e : probl\u00e8me avec la fonction de connexion.<\/li>\n<\/ul>\n\n
Question 31. Qu’est-ce qu’un \u00ab\u00a0bloqueur\u00a0\u00bb ?<\/strong>
Question no. 32. Qu’est-ce qu’un bogue critique ?<\/strong>
Question no. 33. Expliquez le cycle de vie d’un insecte ou les diff\u00e9rents \u00e9tats d’un insecte.<\/strong><\/p>\n\n
R\u00e9ponse : Dans le cadre du d\u00e9veloppement d’un logiciel, un bogue passe par les phases suivantes<\/p>\n\n
- \n
- Nouveau – l’erreur ou le d\u00e9faut est dans l’\u00e9tat Nouveau lorsqu’il est d\u00e9tect\u00e9.<\/li>\n\n\n\n
- Assign\u00e9 – Le nouveau bogue d\u00e9tect\u00e9 est dans l’\u00e9tat Assign\u00e9 apr\u00e8s avoir \u00e9t\u00e9 assign\u00e9 au d\u00e9veloppeur appropri\u00e9.<\/li>\n\n\n\n
- Ouvert – Lorsque le d\u00e9veloppeur travaille sur un bogue, celui-ci est dans l’\u00e9tat ouvert.<\/li>\n\n\n\n
- Rejet\u00e9\/pas un bogue – Un bogue se trouve dans l’\u00e9tat Rejet\u00e9 si le d\u00e9veloppeur juge que le bogue n’est pas authentique.<\/li>\n<\/ul>\n\n
- \n
- Diff\u00e9r\u00e9 – Un bogue diff\u00e9r\u00e9 est un bogue dont la correction est report\u00e9e \u00e0 une certaine p\u00e9riode de temps (pour les versions futures) en fonction de l’urgence et de la criticit\u00e9 du bogue.<\/li>\n\n\n\n
- Corrig\u00e9 – Lorsque le d\u00e9veloppeur a r\u00e9solu le bogue, celui-ci est marqu\u00e9 comme corrig\u00e9.<\/li>\n\n\n\n
- Test\u00e9(Test) – Lorsqu’un bogue est corrig\u00e9, il est assign\u00e9 \u00e0 un testeur et est marqu\u00e9 comme test\u00e9 pendant cette p\u00e9riode.<\/li>\n\n\n\n
- R\u00e9ouverture – Si le testeur n’est pas satisfait de la r\u00e9solution du probl\u00e8me, le d\u00e9faut passe \u00e0 l’\u00e9tat R\u00e9ouvert.<\/li>\n\n\n\n
- V\u00e9rifi\u00e9 – Apr\u00e8s la phase de test, si le testeur estime que le bogue est r\u00e9solu, il est marqu\u00e9 comme v\u00e9rifi\u00e9.<\/li>\n\n\n\n
- Ferm\u00e9 – Apr\u00e8s v\u00e9rification de l’erreur, celle-ci passe \u00e0 l’\u00e9tat Ferm\u00e9.<\/li>\n<\/ul>\n\n
Question no. 34. Quelles sont les diff\u00e9rentes techniques de conception des tests ?<\/strong><\/p>\n\n
R\u00e9ponse : Les techniques de conception des tests sont diverses normes de conception des tests qui permettent d’obtenir des cas de test syst\u00e9matiques et g\u00e9n\u00e9ralement accept\u00e9s. Les diff\u00e9rentes techniques de conception de tests peuvent \u00eatre divis\u00e9es en techniques de conception de tests statiques et en techniques de conception de tests dynamiques.<\/p>\n\n
1. Techniques de conception de tests statiques – techniques de conception de tests qui impliquent des tests sans ex\u00e9cution du code. Les diff\u00e9rentes techniques de conception de tests statiques peuvent \u00eatre divis\u00e9es en deux parties : les techniques manuelles et les techniques utilisant des outils.<\/p>\n\n
- \n
- Techniques manuelles de conception de tests statiques<\/li>\n\n\n\n
- Cheminement<\/li>\n\n\n\n
- Examens informels<\/li>\n\n\n\n
- Examens techniques<\/li>\n\n\n\n
- Contr\u00f4le d’audit<\/li>\n\n\n\n
- Revue de direction (revue technique)<\/li>\n<\/ul>\n\n
2. Techniques de conception de tests statiques \u00e0 l’aide d’outils<\/p>\n\n
- \n
- L’analyse statique du code – consiste \u00e0 analyser les diff\u00e9rents chemins et flux de l’application ainsi que les diff\u00e9rents \u00e9tats des donn\u00e9es de test.<\/li>\n\n\n\n
- Conformit\u00e9 avec les normes de programmation – La conformit\u00e9 du code avec les diff\u00e9rentes normes de programmation est \u00e9valu\u00e9e.<\/li>\n\n\n\n
- Analyse des m\u00e9triques du code – Un outil utilis\u00e9 pour l’analyse statique est n\u00e9cessaire pour \u00e9valuer diverses m\u00e9triques telles que les lignes de code, la complexit\u00e9, la couverture du code, etc.<\/li>\n<\/ul>\n\n
3. Techniques de conception de tests dynamiques – Les techniques de conception de tests dynamiques consistent \u00e0 tester le syst\u00e8me en cours d’ex\u00e9cution.<\/p>\n\n
- \n
- Techniques de conception de tests bas\u00e9s sur les sp\u00e9cifications – Les techniques de conception de tests bas\u00e9s sur les sp\u00e9cifications sont \u00e9galement appel\u00e9es tests bo\u00eete noire. Ces techniques consistent \u00e0 tester la sp\u00e9cification du syst\u00e8me test\u00e9 sans conna\u00eetre son architecture interne.<\/li>\n\n\n\n
- Techniques de conception de tests bas\u00e9s sur la structure – \u00e9galement appel\u00e9es tests bo\u00eete blanche. Dans ces techniques, la connaissance du code ou de l’architecture interne du syst\u00e8me est n\u00e9cessaire pour effectuer les tests.<\/li>\n\n\n\n
- Bas\u00e9es sur l’exp\u00e9rience – Les techniques bas\u00e9es sur l’exp\u00e9rience reposent sur l’exp\u00e9rience ou l’intuition du testeur. Les deux formes les plus courantes de tests bas\u00e9s sur l’exp\u00e9rience sont les tests adhoc et les tests exploratoires.<\/li>\n<\/ul>\n\n
Question no. 35. Qu’est-ce que le test statique ?<\/strong><\/p>\n\n
R : Les tests statiques sont un type de test permettant d’examiner les produits de travail ou la documentation cr\u00e9\u00e9s tout au long d’un projet. Permet d’examiner les sp\u00e9cifications, les exigences commerciales, la documentation, les processus et les exigences fonctionnelles au cours de la phase de test initiale.<\/p>\n\n
Ainsi, les testeurs impliqu\u00e9s peuvent comprendre les exigences de mani\u00e8re plus d\u00e9taill\u00e9e avant d’entamer le cycle de vie des tests, qui a pour but de contribuer \u00e0 la livraison d’un produit de qualit\u00e9.<\/p>\n\n
Question no. 36. Qu’est-ce que l’essai dynamique ?<\/strong><\/p>\n\n
R\u00e9ponse : Le type de test effectu\u00e9 en ex\u00e9cutant l’application test\u00e9e, soit manuellement, soit par automatisation, est appel\u00e9 test dynamique.<\/p>\n\n
Question no. 37. Expliquez les diff\u00e9rents types de techniques de conception de tests bas\u00e9s sur les sp\u00e9cifications.<\/strong><\/p>\n\n
R\u00e9ponse : Les techniques de conception de tests bas\u00e9es sur les sp\u00e9cifications sont \u00e9galement appel\u00e9es tests en bo\u00eete noire. Il s’agit de tester la sp\u00e9cification du syst\u00e8me test\u00e9 sans conna\u00eetre son architecture interne. Les diff\u00e9rents types de tests bas\u00e9s sur les sp\u00e9cifications ou les techniques de test de la bo\u00eete noire sont les suivants :<\/p>\n\n
- \n
- Partitionnement par \u00e9quivalence – regroupement des donn\u00e9es de test en groupes logiques ou en classes d’\u00e9quivalence, en partant du principe que toutes les donn\u00e9es appartenant \u00e0 ces classes auront le m\u00eame effet sur l’application.<\/li>\n\n\n\n
- Analyse des valeurs limites – test utilisant les valeurs limites des classes d’\u00e9quivalence comme donn\u00e9es d’entr\u00e9e du test.<\/li>\n\n\n\n
- Tableaux de d\u00e9cision – tests effectu\u00e9s \u00e0 l’aide de tableaux de d\u00e9cision montrant le comportement de l’application en fonction de diff\u00e9rentes combinaisons de valeurs d’entr\u00e9e.<\/li>\n\n\n\n
- Graphique cause-effet – Test utilisant une repr\u00e9sentation graphique du r\u00e9sultat et de tous les facteurs qui l’influencent.<\/li>\n\n\n\n
- Test de transition d’\u00e9tat – Test bas\u00e9 sur le mod\u00e8le de la machine \u00e0 \u00e9tats.<\/li>\n\n\n\n
- Test des cas d’utilisation – Test effectu\u00e9 \u00e0 l’aide de cas d’utilisation.<\/li>\n<\/ul>\n\n
Question no. 38. Expliquez le partitionnement des classes d’\u00e9quivalence.<\/strong><\/p>\n\n
R : La distribution des classes d’\u00e9quivalence est une technique de test en bo\u00eete noire bas\u00e9e sur la sp\u00e9cification. Lors de la r\u00e9partition des classes d’\u00e9quivalence, l’ensemble des donn\u00e9es d’entr\u00e9e d\u00e9finissant les diff\u00e9rentes conditions d’essai doit \u00eatre divis\u00e9 en groupes logiquement similaires, de sorte que l’utilisation d’une seule donn\u00e9e d’essai d’un groupe d’essai puisse \u00eatre consid\u00e9r\u00e9e comme similaire \u00e0 l’utilisation de toutes les autres donn\u00e9es de ce groupe.<\/p>\n\n
Par exemple, pour tester un programme Square (un programme qui produit le carr\u00e9 d’un nombre), il peut y avoir des classes d’\u00e9quivalence – l’ensemble des nombres n\u00e9gatifs, des entiers, des d\u00e9cimales, l’ensemble des grands nombres, etc.<\/p>\n\n
Question no. 39. Qu’est-ce que l’analyse de la valeur limite ?<\/strong><\/p>\n\n
R\u00e9ponse : L’analyse des valeurs limites est une technique de test de logiciel pour la conception de cas de test qui prend les valeurs limites des distributions de classes d’\u00e9quivalence comme entr\u00e9e pour les cas de test, par exemple. si les donn\u00e9es d’essai se situent dans l’intervalle 0-100, l’analyse de seuil inclura les donn\u00e9es d’essai – 0,1, 99, 100.<\/p>\n\n
Question 40. Qu’est-ce qu’un test de table de d\u00e9cision ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test par table de d\u00e9cision est un type de technique de conception de test bas\u00e9e sur les sp\u00e9cifications ou une technique de test bo\u00eete noire dans laquelle les tests sont effectu\u00e9s \u00e0 l’aide de tables de d\u00e9cision d\u00e9crivant le comportement d’une application en fonction de diverses combinaisons de valeurs d’entr\u00e9e.<\/p>\n\n
Les tables de d\u00e9cision sont particuli\u00e8rement utiles pour concevoir des cas de test pour des sc\u00e9narios commerciaux complexes impliquant la validation d’applications avec de multiples combinaisons d’entr\u00e9es.<\/p>\n\n
Question 41. Qu’est-ce qu’un graphique de cause \u00e0 effet ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test par graphe de cause et d’effet est une technique de conception de tests en bo\u00eete noire dans laquelle une repr\u00e9sentation graphique de l’entr\u00e9e est utilis\u00e9e pour concevoir les tests, c’est-\u00e0-dire j. les causes et les r\u00e9sultats, c’est-\u00e0-dire j. de cons\u00e9quence. Cette technique utilise diff\u00e9rentes notations repr\u00e9sentant AND, OR, NOT, etc. entre les conditions d’entr\u00e9e et la sortie.<\/p>\n\n
Question no. 42. Qu’est-ce que le test de transition d’\u00e9tat ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de transition d’\u00e9tat est une technique de conception de tests en bo\u00eete noire bas\u00e9e sur un mod\u00e8le de machine \u00e0 \u00e9tats. Le test des transitions entre les \u00e9tats repose sur le concept selon lequel un syst\u00e8me peut \u00eatre d\u00e9fini comme un ensemble d’\u00e9tats multiples, et la transition d’un \u00e9tat \u00e0 un autre se produit \u00e0 la suite d’un \u00e9v\u00e9nement.<\/p>\n\n
Question no. 43. Qu’est-ce que le test des cas d’utilisation ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test des cas d’utilisation est une approche de test en bo\u00eete noire dans laquelle les tests sont effectu\u00e9s \u00e0 l’aide de cas d’utilisation. Le sc\u00e9nario du cas d’utilisation est consid\u00e9r\u00e9 comme une interaction entre l’application et les acteurs (utilisateurs). Ces cas d’utilisation servent \u00e0 illustrer les exigences et peuvent donc \u00e9galement servir de base aux tests d’acceptation.<\/p>\n\n
Question no. 44. Qu’est-ce que la couverture des tests ?<\/strong><\/p>\n\n
R\u00e9ponse : Il s’agit d’une m\u00e9trique qui mesure la quantit\u00e9 de tests effectu\u00e9s sur le logiciel lors de l’ex\u00e9cution des cas de test. La couverture des tests d’un logiciel peut \u00eatre calcul\u00e9e comme un pourcentage du nombre de domaines de test ou d’\u00e9l\u00e9ments de couverture couverts par rapport au nombre total de domaines de test.<\/p>\n\n
Plus la couverture des tests est \u00e9lev\u00e9e, plus le nombre de parties du logiciel couvertes par des cas de test est important et plus les tests sont efficaces.<\/p>\n\n
Question no. 45. Qu’est-ce qu’un test bas\u00e9 sur la structure ?<\/strong><\/p>\n\n
R\u00e9ponse : Les techniques de conception de tests bas\u00e9es sur la structure sont \u00e9galement appel\u00e9es tests bo\u00eete blanche. Dans ces techniques, la connaissance du code ou de l’architecture interne du syst\u00e8me est n\u00e9cessaire pour effectuer les tests. Les diff\u00e9rents types de tests bas\u00e9s sur la structure ou les techniques de tests en bo\u00eete blanche sont les suivants :<\/p>\n\n
- \n
- Test de d\u00e9claration – technique de test en bo\u00eete blanche dans laquelle les scripts de test sont con\u00e7us pour ex\u00e9cuter des commandes dans le code de l’application. Sa couverture est mesur\u00e9e par le nombre de lignes de code ou d’instructions ex\u00e9cut\u00e9es par les scripts de test.<\/li>\n\n\n\n
- Test de d\u00e9cision\/test de branche – technique de test dans laquelle les scripts de test sont con\u00e7us pour ex\u00e9cuter diff\u00e9rentes branches de d\u00e9cision (par exemple, conditions if-else) dans une application. Sa couverture est mesur\u00e9e en pourcentage de points de d\u00e9cision par rapport au nombre total de points de d\u00e9cision dans l’application.<\/li>\n\n\n\n
- Test des conditions – Le test des conditions est une approche qui consiste \u00e0 tester une application avec des r\u00e9sultats vrais et faux pour chaque condition. Par cons\u00e9quent, pour n conditions, nous aurons 2n scripts de test.<\/li>\n\n\n\n
- Tests de conditions multiples – Dans les tests de conditions multiples, diff\u00e9rentes combinaisons de r\u00e9sultats de conditions sont test\u00e9es au moins une fois. Par cons\u00e9quent, pour une couverture de 100 %, nous aurons 2^n scripts de test. C’est tr\u00e8s \u00e9puisant et il est tr\u00e8s difficile d’obtenir une couverture \u00e0 100 %.<\/li>\n\n\n\n
- Essai de d\u00e9termination des conditions – Il s’agit d’une mani\u00e8re optimis\u00e9e de tester plusieurs conditions, en \u00e9cartant les combinaisons qui n’ont pas d’incidence sur les r\u00e9sultats.<\/li>\n\n\n\n
- Test de cheminement – Test de cheminements ind\u00e9pendants dans le syst\u00e8me (les cheminements sont des instructions ex\u00e9cutables entre les points d’entr\u00e9e et de sortie).<\/li>\n<\/ul>\n\n
Question no. 46. Qu’est-ce que la couverture du code ?<\/strong><\/p>\n\n
R : La couverture du code est une mesure de la quantit\u00e9 de code couverte par les scripts de test. Il donne une id\u00e9e de la partie de l’application couverte par les tests.<\/p>\n\n
Question 47. Qu’est-ce qu’un test de d\u00e9claration et une couverture de d\u00e9claration dans le cadre d’un test en bo\u00eete blanche ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de d\u00e9claration est une approche de test en bo\u00eete blanche dans laquelle les scripts de test sont con\u00e7us pour ex\u00e9cuter des d\u00e9clarations de code.<\/p>\n\n
La couverture des instructions est une mesure du pourcentage d’instructions de code ex\u00e9cut\u00e9es par les scripts de test par rapport au nombre total d’instructions de code dans l’application. La couverture des commandes est la mesure la moins appr\u00e9ci\u00e9e pour v\u00e9rifier la couverture des tests.<\/p>\n\n
Question no. 48. Qu’est-ce qu’un test de d\u00e9cision ou un test de branche ?<\/strong><\/p>\n\n
R : Le test de d\u00e9cision ou test de branche est une approche de test bo\u00eete blanche dans laquelle la couverture du test est mesur\u00e9e par le pourcentage de points de d\u00e9cision (par exemple, les conditions if-else) ex\u00e9cut\u00e9s sur le nombre total de points de d\u00e9cision dans l’application.<\/p>\n\n
Question 49. Quels sont les diff\u00e9rents niveaux de test ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests peuvent \u00eatre effectu\u00e9s \u00e0 diff\u00e9rents niveaux du processus de d\u00e9veloppement. La r\u00e9alisation d’activit\u00e9s de test \u00e0 plusieurs niveaux permet d’identifier les d\u00e9fauts \u00e0 un stade pr\u00e9coce. Les diff\u00e9rents niveaux de test sont les suivants<\/p>\n\n
1. Tests unitaires<\/p>\n\n
2. les tests d’int\u00e9gration<\/p>\n\n
3. Test du syst\u00e8me<\/p>\n\n
4. Tests d’acceptation<\/p>\n\n
Question no. 50. Qu’est-ce que les tests unitaires ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests unitaires constituent le premier niveau de test et impliquent de tester des modules individuels du logiciel. Elle est g\u00e9n\u00e9ralement r\u00e9alis\u00e9e par des d\u00e9veloppeurs.<\/p>\n\n
Question no. 51. Qu’est-ce qu’un test d’int\u00e9gration ?<\/strong><\/p>\n\n
R : Les tests d’int\u00e9gration sont effectu\u00e9s apr\u00e8s les tests unitaires. Dans les tests d’int\u00e9gration, nous testons un groupe de modules apparent\u00e9s. Il vise \u00e0 d\u00e9tecter les probl\u00e8mes d’interconnexion entre les modules.<\/p>\n\n
Question no. 52. Quels sont les diff\u00e9rents types de tests d’int\u00e9gration ?<\/strong><\/p>\n\n
R : Les diff\u00e9rents types de tests d’int\u00e9gration sont les suivants<\/p>\n\n
1) Tests d’int\u00e9gration \u00ab\u00a0big bang\u00a0\u00bb – Dans les tests d’int\u00e9gration \u00ab\u00a0big bang\u00a0\u00bb, les tests commencent apr\u00e8s l’int\u00e9gration de tous les modules.<\/p>\n\n
2) Tests d’int\u00e9gration descendante – Dans l’int\u00e9gration descendante, les tests\/int\u00e9grations commencent \u00e0 partir des modules de niveau sup\u00e9rieur vers les modules de niveau inf\u00e9rieur.<\/p>\n\n
3) Tests d’int\u00e9gration ascendante – Dans l’int\u00e9gration ascendante, les tests partent des modules de niveau inf\u00e9rieur pour aller vers les modules de niveau sup\u00e9rieur dans la hi\u00e9rarchie.<\/p>\n\n
4. Tests d’int\u00e9gration hybrides – Les tests d’int\u00e9gration hybrides sont une combinaison de tests d’int\u00e9gration descendants et ascendants. Dans cette approche, l’int\u00e9gration commence \u00e0 partir de la couche interm\u00e9diaire et les tests sont effectu\u00e9s dans les deux sens<\/p>\n\n
Question no. 53. Qu’est-ce qu’un talon ?<\/strong><\/p>\n\n
R : Dans le cas des tests d’int\u00e9gration descendante, il arrive souvent que les modules de niveau inf\u00e9rieur n’\u00e9voluent pas lorsque les tests\/int\u00e9grations avec les modules de niveau sup\u00e9rieur sont lanc\u00e9s. Dans ce cas, des modules fictifs sont utilis\u00e9s pour simuler le fonctionnement des modules en fournissant une sortie fixe ou attendue sur la base des valeurs d’entr\u00e9e.<\/p>\n\n
Question 54. Qu’est-ce qu’un conducteur ?<\/strong><\/p>\n\n
R : Dans le cas des tests d’int\u00e9gration ascendants, les pilotes sont utilis\u00e9s pour simuler le fonctionnement des modules de niveau sup\u00e9rieur afin de tester les modules connexes situ\u00e9s plus bas dans la hi\u00e9rarchie.<\/p>\n\n
Question 55. Qu’est-ce qu’un test de syst\u00e8me ?<\/strong><\/p>\n\n
R : Le test de syst\u00e8me est un niveau de test qui teste le logiciel dans son ensemble. Lors du test du syst\u00e8me, on v\u00e9rifie que l’application est conforme aux exigences de l’entreprise.<\/p>\n\n
Question no. 56. Qu’est-ce qu’un test d’acceptation ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests d’acceptation sont des tests effectu\u00e9s par un utilisateur final ou un client potentiel pour v\u00e9rifier que le logiciel r\u00e9pond aux exigences de l’entreprise et qu’il peut \u00eatre accept\u00e9.<\/p>\n\n
Question no. 57. Qu’est-ce que le test UAT ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test UAT est la derni\u00e8re phase du cycle de test. Son objectif principal est de v\u00e9rifier que le logiciel fonctionne conform\u00e9ment aux exigences de l’entreprise. Elle permet \u00e9galement de s’assurer que l’application est conviviale et qu’elle peut g\u00e9rer au mieux des sc\u00e9narios complexes avant de mettre le produit \u00e0 la disposition des utilisateurs r\u00e9els.<\/p>\n\n
Question no. 58. Qu’est-ce qu’un test de bout en bout ?<\/strong><\/p>\n\n
R : Les tests de bout en bout sont un type de test dans lequel l’application enti\u00e8re est test\u00e9e pour v\u00e9rifier que chaque fonctionnalit\u00e9 du logiciel fonctionne comme pr\u00e9vu et qu’il n’y a pas de lacunes. Veille \u00e0 ce que l’application soit conviviale et r\u00e9ponde aux besoins de l’entreprise.<\/p>\n\n
Question no. 59. Qu’est-ce qu’un test alpha ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests alpha sont un type de tests d’acceptation r\u00e9alis\u00e9s par des testeurs ou des employ\u00e9s internes de l’organisation sur le lieu de travail du d\u00e9veloppeur.<\/p>\n\n
Question 60. Qu’est-ce qu’un test b\u00eata ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test b\u00eata est un test effectu\u00e9 par les utilisateurs finaux sur leur lieu de travail. Il permet aux utilisateurs de fournir des informations directes sur le logiciel \u00e0 la soci\u00e9t\u00e9 de d\u00e9veloppement.<\/p>\n\n
Question no. 61. Qu’est-ce qu’un test adhoc ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests adhoc sont des tests non structur\u00e9s effectu\u00e9s sans documentation formelle ni planification ad\u00e9quate.<\/p>\n\n
Question n\u00b0 62. Qu’est-ce que le test du singe ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de singe est un type de test qui est effectu\u00e9 de mani\u00e8re al\u00e9atoire sans aucun cas de test pr\u00e9d\u00e9fini ou entr\u00e9e de test.<\/p>\n\n
Question no. 63. Quelle est la diff\u00e9rence entre les tests monkey et les tests adhoc ?<\/strong><\/p>\n\n
R : Dans le cas des tests adhoc, bien qu’il n’y ait pas de cas de test pr\u00e9d\u00e9finis ou document\u00e9s, les testeurs ont toujours une vue d’ensemble de l’application. Alors que dans le cas des tests de singe, les testeurs ne comprennent pas l’application.<\/p>\n\n
Question no. 64. Qu’est-ce qu’un test exploratoire ?<\/strong><\/p>\n\n
R : Les tests exploratoires sont un type de test dans lequel de nouveaux cas de test sont ajout\u00e9s et mis \u00e0 jour au fur et \u00e0 mesure de l’exploration du syst\u00e8me ou de l’ex\u00e9cution des cas de test. Contrairement aux tests sc\u00e9naris\u00e9s, dans les tests exploratoires, la conception et l’ex\u00e9cution des tests se d\u00e9roulent en parall\u00e8le.<\/p>\n\n
Question no. 65. Qu’est-ce qu’un test de charge ?<\/strong><\/p>\n\n
R : Le test de charge est un type de test de performance qui vise \u00e0 d\u00e9terminer la performance d’une application sous une charge attendue. Lors des tests de charge, nous \u00e9valuons le temps de r\u00e9ponse, le d\u00e9bit, le taux d’erreur, etc. les param\u00e8tres d’application.<\/p>\n\n
Question no. 66. Qu’est-ce que la simulation de crise ?<\/strong><\/p>\n\n
R : Le test de stress est un type de test de performance dans lequel le comportement d’une application est contr\u00f4l\u00e9 sous une charge plus \u00e9lev\u00e9e que pr\u00e9vu. Des tests de stress sont effectu\u00e9s pour d\u00e9tecter les fuites de m\u00e9moire et la robustesse de l’application.<\/p>\n\n
Question no. 67. Qu’est-ce qu’un test de volume ?<\/strong><\/p>\n\n
R : Le test de volume est un type de test de performance qui \u00e9value la performance d’une application avec une grande quantit\u00e9 de donn\u00e9es. Il v\u00e9rifie l’\u00e9volutivit\u00e9 de l’application et permet d’identifier les goulets d’\u00e9tranglement dans le cas de gros volumes de donn\u00e9es.<\/p>\n\n
Question no. 68. Qu’est-ce qu’un test d’endurance ou un test d’impr\u00e9gnation ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test d’endurance est un type de test de performance qui vise \u00e0 trouver des probl\u00e8mes tels que des fuites de m\u00e9moire lorsqu’une application est soumise \u00e0 des tests de stress sur une longue p\u00e9riode de temps.<\/p>\n\n
Question no. 69. Qu’est-ce que le test des pics ?<\/strong><\/p>\n\n
R : Le test de pic est un type de test de performance qui mesure la performance d’une application lorsque le nombre d’utilisateurs actifs augmente soudainement au cours d’un test de stress.<\/p>\n\n
Question no. 70. Qu’est-ce qu’un test d’interface utilisateur ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de l’interface utilisateur est un type de test qui vise \u00e0 trouver les bogues de l’interface graphique dans une application et \u00e0 v\u00e9rifier si l’interface graphique est conforme aux sp\u00e9cifications.<\/p>\n\n
Question no. 71. Qu’est-ce qu’un test d’utilisabilit\u00e9 ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test d’utilisabilit\u00e9 est un type de test qui vise \u00e0 d\u00e9terminer la facilit\u00e9 d’utilisation d’une application. Son objectif est de d\u00e9tecter les bogues d’utilisation dans l’application.<\/p>\n\n
Question no. 72. Qu’est-ce qu’un test d’accessibilit\u00e9 ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test d’accessibilit\u00e9 est un type de test con\u00e7u pour d\u00e9terminer la facilit\u00e9 d’utilisation ou le fonctionnement d’une application sp\u00e9cifiquement pour les personnes handicap\u00e9es.<\/p>\n\n
Question 73. Qu’est-ce qu’un test de compatibilit\u00e9 ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de compatibilit\u00e9 est la v\u00e9rification d’un logiciel pour d\u00e9terminer sa compatibilit\u00e9 avec un environnement particulier – syst\u00e8me d’exploitation, plate-forme ou mat\u00e9riel.<\/p>\n\n
Question no. 74. Qu’est-ce qu’un test de configuration ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de configuration est un type de test utilis\u00e9 pour \u00e9valuer les exigences de configuration du logiciel ainsi que l’effet de la modification de la configuration requise.<\/p>\n\n
Question n\u00b0 75. Qu’est-ce qu’un test de localisation ?<\/strong><\/p>\n\n
R : Les tests de localisation sont un type de test dans lequel nous \u00e9valuons l’adaptation d’une application (une version localis\u00e9e de l’application) dans une culture, un lieu ou un pays particulier.<\/p>\n\n
Question no. 76. Qu’est-ce que le test de la mondialisation ?<\/strong><\/p>\n\n
R : Les tests de globalisation sont un type de test qui \u00e9value la performance d’une application dans le monde entier, dans des cultures, des langues, des lieux et des pays diff\u00e9rents.<\/p>\n\n
Question no. 77. Qu’est-ce qu’un test n\u00e9gatif ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test n\u00e9gatif est un type de test qui \u00e9value la r\u00e9sistance d’une application (sortie gracieuse ou signalement d’erreurs) lorsqu’elle est soumise \u00e0 des donn\u00e9es d’entr\u00e9e ou de test non valides.<\/p>\n\n
Question no. 78. Qu’est-ce qu’un test de s\u00e9curit\u00e9 ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de s\u00e9curit\u00e9 est un type de test qui vise \u00e0 \u00e9valuer l’int\u00e9grit\u00e9, l’authentification, l’autorisation, la disponibilit\u00e9, la confidentialit\u00e9 et la non-r\u00e9pudiation de l’application test\u00e9e.<\/p>\n\n
Question no. 79. Qu’est-ce qu’un test de p\u00e9n\u00e9tration ?<\/strong><\/p>\n\n
R : Le test de p\u00e9n\u00e9tration est un type de test de s\u00e9curit\u00e9 dans lequel une application est \u00e9valu\u00e9e (exploit\u00e9e en toute s\u00e9curit\u00e9) pour diff\u00e9rents types de vuln\u00e9rabilit\u00e9s qui pourraient \u00eatre exploit\u00e9es par n’importe quel pirate informatique.<\/p>\n\n
Question no. 80. Qu’est-ce qu’un test de robustesse ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de robustesse est un type de test effectu\u00e9 pour d\u00e9terminer la robustesse d’une application, c’est-\u00e0-dire j. la capacit\u00e9 du syst\u00e8me \u00e0 se comporter avec parcimonie en cas d’\u00e9tapes d’essai et d’entr\u00e9es d’essai d\u00e9fectueuses.<\/p>\n\n
Question no. 81. Qu’est-ce que les tests de simultan\u00e9it\u00e9 ?<\/strong><\/p>\n\n
R\u00e9ponse : Les tests de simultan\u00e9it\u00e9 sont des tests multi-utilisateurs dans lesquels une application est \u00e9valu\u00e9e en analysant le comportement de l’application lorsque les utilisateurs acc\u00e8dent \u00e0 la m\u00eame fonction de mani\u00e8re simultan\u00e9e.<\/p>\n\n
Question no. 82. Qu’est-ce qu’un test backend ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test du backend est un type de test qui consiste \u00e0 tester le backend du syst\u00e8me, c’est-\u00e0-dire les bases de donn\u00e9es et les API de l’application.<\/p>\n\n
Question no. 83. Qu’est-ce que le test A\/B ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test A\/B est un type de test dans lequel les utilisateurs finaux sont expos\u00e9s \u00e0 deux variantes d’un produit logiciel et, sur la base d’une analyse du comportement de l’utilisateur sur chaque variante, la meilleure variante est s\u00e9lectionn\u00e9e et utilis\u00e9e.<\/p>\n\n
Question no. 84. Qu’est-ce que l’analyse de risque ?<\/strong><\/p>\n\n
R\u00e9ponse : L’analyse de risque est l’analyse d’un risque identifi\u00e9 et l’attribution d’un niveau de risque appropri\u00e9 \u00e0 un d\u00e9faut en fonction de son impact sur l’application.<\/p>\n\n
Question no. 85. Quelle est la diff\u00e9rence entre les tests de r\u00e9gression et les nouveaux tests ?<\/strong><\/p>\n\n
R : Les tests de r\u00e9gression consistent \u00e0 tester une application pour v\u00e9rifier qu’une nouvelle modification du code n’affecte pas d’autres parties de l’application. Lors du retest, nous v\u00e9rifions si le probl\u00e8me corrig\u00e9 est r\u00e9solu ou non.<\/p>\n\n
Question no. 86. Quelle est la diff\u00e9rence entre les tests bo\u00eete noire et bo\u00eete blanche ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test bo\u00eete noire est un type de test dans lequel l’architecture interne du code n’est pas requise pour le test. Il est g\u00e9n\u00e9ralement utilis\u00e9 pour les tests de syst\u00e8me et les tests d’acceptation.<\/p>\n\n
Alors que les tests en bo\u00eete blanche n\u00e9cessitent une connaissance de la conception interne et de la mise en \u0153uvre de l’application test\u00e9e. Il est g\u00e9n\u00e9ralement utilis\u00e9 pour les tests unitaires et les tests d’int\u00e9gration.<\/p>\n\n
Question no. 87. Quelle est la diff\u00e9rence entre les tests de fum\u00e9e et les tests d’int\u00e9grit\u00e9 ?<\/strong><\/p>\n\n
R : La diff\u00e9rence entre les tests de fum\u00e9e et les tests d’int\u00e9grit\u00e9 est la suivante.<\/p>\n\n
- \n
- Le Smoke testing est un type de test dans lequel toutes les fonctions principales d’une application sont test\u00e9es avant que des tests exhaustifs ne soient effectu\u00e9s. Les tests d’\u00e9quilibre sont un sous-ensemble des tests de r\u00e9gression, qui sont effectu\u00e9s lorsqu’une correction mineure est apport\u00e9e \u00e0 l’application dans une nouvelle version.<\/li>\n\n\n\n
- Les tests de fum\u00e9e sont g\u00e9n\u00e9ralement document\u00e9s ou automatis\u00e9s. Les tests d’int\u00e9grit\u00e9 ne sont g\u00e9n\u00e9ralement pas document\u00e9s ou sc\u00e9naris\u00e9s.<\/li>\n<\/ul>\n\n
Question no. 88. Quelle est la diff\u00e9rence entre Release et Build ?<\/strong><\/p>\n\n
R\u00e9ponse : Un build est un fichier ex\u00e9cutable fourni par les d\u00e9veloppeurs \u00e0 l’\u00e9quipe de test pour tester l’application. Elle passe par plusieurs it\u00e9rations de corrections et de tests jusqu’\u00e0 ce que l’application fonctionne comme pr\u00e9vu. Lorsque l’application est stable et pr\u00eate pour les utilisateurs finaux, elle est mise sur le march\u00e9.<\/p>\n\n
Alors que la version est un logiciel installable fourni aux utilisateurs finaux apr\u00e8s avoir \u00e9t\u00e9 certifi\u00e9 par l’\u00e9quipe de test. Lorsqu’un logiciel est mis \u00e0 la disposition d’un client, il est accompagn\u00e9 de notes de mise \u00e0 jour qui indiquent le nombre de bogues encore en suspens, les histoires d’utilisateurs couvertes, les demandes de changement et la version de la mise \u00e0 jour.<\/p>\n\n
Questions d’entretien sur les tests manuels avanc\u00e9s<\/strong><\/h2>\n\n
Questions non. 89. Quelle est la diff\u00e9rence entre la fuite de bogues et la publication de bogues ?<\/strong><\/p>\n\n
R\u00e9ponse Une fuite de bogues se produit lorsqu’un logiciel test\u00e9 est mis sur le march\u00e9 et que l’utilisateur final y trouve des bogues. Il s’agit notamment des bogues n\u00e9glig\u00e9s par l’\u00e9quipe de test au cours de la phase de test.<\/p>\n\n
En revanche, on parle de version de bogue lorsqu’une version particuli\u00e8re d’un logiciel est mise sur le march\u00e9 avec quelques bogues connus qui seront corrig\u00e9s dans les versions ult\u00e9rieures. Ces types de probl\u00e8mes sont peu prioritaires et sont mentionn\u00e9s dans les notes de mise \u00e0 jour lorsqu’ils sont communiqu\u00e9s aux utilisateurs finaux.<\/p>\n\n
Question no. 90. Qu’entendez-vous par \u00ab\u00a0triage des d\u00e9fauts\u00a0\u00bb ?<\/strong><\/p>\n\n
R : Le triage des d\u00e9fauts est un processus qui permet de classer les d\u00e9fauts par ordre de priorit\u00e9 en fonction de divers facteurs tels que la gravit\u00e9, le risque, le temps n\u00e9cessaire pour corriger le d\u00e9faut, etc. Diverses parties prenantes participent \u00e0 cette r\u00e9union : \u00e9quipe de d\u00e9veloppement, \u00e9quipe de test, chef de projet, conseiller juridique, etc. et d\u00e9cider de la priorit\u00e9 \u00e0 accorder \u00e0 la correction des bogues.<\/p>\n\n
Question no. 91. Qu’est-ce qu’un test de harnais ? Pourquoi avons-nous besoin d’un test d’attelage ?<\/strong><\/p>\n\n
R\u00e9ponse : Un harnais de test est un ensemble de scripts et de donn\u00e9es de test qui est g\u00e9n\u00e9ralement associ\u00e9 aux tests unitaires et d’int\u00e9gration. Inclut les stubs et les pilotes n\u00e9cessaires pour tester les modules logiciels et les composants int\u00e9gr\u00e9s.<\/p>\n\n
Question no. 92. Qu’est-ce que le test en bin\u00f4me ?<\/strong><\/p>\n\n
R\u00e9ponse : Tous les tests par paires sont un type de test dans lequel l’application est test\u00e9e avec toutes les combinaisons possibles de valeurs de param\u00e8tres d’entr\u00e9e.<\/p>\n\n
Question no. 93. Qu’est-ce que le test de basculement ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de basculement est un type de test utilis\u00e9 pour v\u00e9rifier la capacit\u00e9 d’une application \u00e0 allouer des ressources multiples (plusieurs serveurs) en cas de d\u00e9faillance et \u00e0 transf\u00e9rer une partie du traitement vers un syst\u00e8me de secours.<\/p>\n\n
Question no. 94. Qu’est-ce que le fuzz testing ?<\/strong><\/p>\n\n
R : Le test Fuzz est un type de test dans lequel une grande quantit\u00e9 de donn\u00e9es al\u00e9atoires est fournie en entr\u00e9e \u00e0 une application afin de trouver des failles de s\u00e9curit\u00e9 et d’autres probl\u00e8mes dans l’application.<\/p>\n\n
Question no. 95. Qu’est-ce qu’un essai pilote ?<\/strong><\/p>\n\n
R : Le test pilote est un essai men\u00e9 avec un nombre limit\u00e9 d’utilisateurs qui \u00e9valuent le syst\u00e8me et fournissent un retour d’information avant le d\u00e9ploiement complet.<\/p>\n\n
Question no. 96. Qu’est-ce que le test \u00ab\u00a0dev-box\u00a0\u00bb ?<\/strong><\/p>\n\n
R : Dans le cadre des tests en bo\u00eete de d\u00e9veloppement, le testeur effectue des tests sur le syst\u00e8me du d\u00e9veloppeur afin de v\u00e9rifier que les principales caract\u00e9ristiques de l’application sont stables et pr\u00eates \u00e0 \u00eatre test\u00e9es.<\/p>\n\n
Question no. 97. Qu’est-ce qu’un test de mutation ?<\/strong><\/p>\n\n
R\u00e9ponse : Le test de mutation est un type de test en bo\u00eete blanche dans lequel le code source d’une application est modifi\u00e9 pour provoquer certaines erreurs dans son fonctionnement. Des scripts de test sont ensuite ex\u00e9cut\u00e9s pour v\u00e9rifier leur exactitude en contr\u00f4lant les erreurs caus\u00e9es par le code mut\u00e9.<\/p>\n\n
Question no. 98. Qu’est-ce qu’une matrice de tra\u00e7abilit\u00e9 des exigences (MTE) ?<\/strong><\/p>\n\n
R : Dans les tests de logiciels, une matrice de tra\u00e7abilit\u00e9 des exigences est un tableau qui relie les exigences de haut niveau aux exigences d\u00e9taill\u00e9es, aux plans de test ou aux cas de test. Le RTM permet d’assurer une couverture de 100 % des tests.<\/p>\n\n
Question no. 99. Qu’est-ce que la complexit\u00e9 cyclomatique ?<\/strong><\/p>\n\n
R : La complexit\u00e9 cyclomatique est une mesure du nombre de chemins ind\u00e9pendants dans une application ou un programme. Cette mesure donne une indication de la quantit\u00e9 d’efforts n\u00e9cessaires pour tester une fonctionnalit\u00e9 compl\u00e8te. Il peut \u00eatre d\u00e9fini par l’expression –<\/p>\n\n
- Ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre pokro\u010dil\u00fdch<\/a><\/li><\/ul><\/div>\n