INTRODUCTION AUX TESTS LOGICIELS

SOFTWARE:
Une application logicielle est un ensemble de programmes informatiques et de données minimales pour fonctionner.
un système est appelé Logiciel.

. Logiciel de comptabilité
Logiciel de messagerie

PROJET :

Si une application logicielle est conçue pour un client spécifique, alors on l'appelle PROJET.

PRODUCT:

Si une application logicielle est conçue pour plusieurs clients, elle est appelée un PRODUIT.

. Fenêtres.

ERREUR / ERREUR

Une action humaine incorrecte qui entraîne un dysfonctionnement est appelée une
ERREUR.

DEFECT / BUG / FAULT / INCIDENT

Tous sont un et le même qui réduit la qualité de l'application. En d'autres termes

Une déviation entre le comportement attendu et le comportement réel du système

identifié lors des tests est appelé un défaut ou un bogue.

ÉCHEC :
L'écart entre le comportement attendu et le comportement réel identifié par l'utilisateur final

en opération est appelé échec.

La présence d'erreurs entraîne des défauts et la présence de défauts entraîne l'échec du produit.

BRS - SPÉCIFICATIONS DES EXIGENCES D'AFFAIRES

SRS - SPÉCIFICATIONS DES EXIGENCES DU SYSTÈME

FRS - SPÉCIFICATIONS DES EXIGENCES FONCTIONNELLES

HLD - CONCEPTION DE HAUT NIVEAU

LLD - CONCEPTION DE NIVEAU INFÉRIEUR

DFD - DIAGRAMMES DE FLUX DE DONNÉES

WBT - TEST DE BOÎTE BLANCHE

BBT - TEST DE BOÎTE NOIRE

UAT - TEST DE VALIDATION D'UTILISATEUR

1
 SOFTWARE DEVELOPMENT LIFE CYCLE

Participants Étapes Responsibilites

Analyste d'affaires Exigences et Compréhension BRS SRS/FRS

PlanDeProjet
PM/PL & TM, TL Planification
PlanDeTest

Conception de haut niveau ArchitectureDeProjet

Analyste Système Conception
Conception de bas niveau D.F.D
E.R.D & Spécifications Techniques

Développeurs Codage Code Source UnitTestng

Boîte blanche
Test d'intégration
Testeurs Testng Testng
Application exécutable

System Testng
Test de boîte noire
Exécutif de production Livraison et Maintenance U.A.T

TESTS PRÉCOCES :

Effectuer des tests logiciels dès que possible dans le SDLC pour détecter les défauts à un stade précoce est appelé PRÉCOCE
TESTING.
DES TESTS PRÉMATURS SONT RECOMMANDÉS POUR RÉDUIRE LE COÛT DE CORRECTION DES DÉFAUTS

Exigence 1 Exigence 2 Exigence 3 Requirement 4

Correct Correct Correct incorrect C

Exigence Exigence Exigence Exigence

Conception selon Conception selon Erreurs C Conception selon

Exigence Exigence fabriqué en Exigence
design F
F
Développé comme Erreurs C Développé comme Développé comme
par Design fabriqué en F par design D par conception
Développement D
D
Correct Le produit a Le produit a Incorrect
Produit défauts de codage Défauts de conception Produit

2
 Signification de testng

---------------------------------------

Fournir un logiciel de qualité au client.

Les tests sont nécessaires pour vérifier que l'application satisfait aux exigences.

Le test est nécessaire pour construire un produit de qualité.

TestNG améliorera la qualité du logiciel.

Testng réduira également le coût de maintenance.

TestNG donnera confiance à l'entreprise de développement logiciel que le logiciel va

travailler de manière satisfaisante dans l'environnement du client.

Pour maintenir la fiabilité de votre produit.

Résister dans les affaires.

Pour satisfaire les exigences du client.

TESTING DE LOGICIEL

C'est un processus de vérification pour savoir si nous développons le bon produit ou non et aussi de validation.
le produit développé est-il correct ou non

TEST DE LOGICIEL = VÉRIFICATION + VALIDATION

VÉRIFICATION :

C'est un processus de vérification pour savoir si nous développons le bon produit ou non, cela s'appelle aussi TEST STATIC.

VALIDATION:

C'est un processus de validation pour savoir si le produit développé est correct ou non, on l'appelle aussi DYNAMIQUE.
TESTING.

3
 VERIFICATION v/s VALIDATION
Gauche DROIT

Exigences des clients Déployer

(Examiner les exigences)

Système de construction
System Requirements (Examiner SRS) (Système
Testng)

High Level Design Intégrer

Conception de bas niveau Construire des unités

Codage

LES TESTS SONT APPLICABLES À TOUS LES STADES DU DÉVELOPPEMENT LOGICIEL

Le côté GAUCHE est la ligne de base pour l'activité du côté DROIT, c'est-à-dire que les exigences des clients sont la ligne de base pour

les tests d'acceptation et les exigences système sont la base des tests système.
Chaque étape du développement de produit est suivie d'un test pour trouver les défauts le plus tôt possible.

4
 TECHNIQUES DE TEST DE LOGICIEL
. TEST STATIC

. TEST DE LA BOÎTE BLANCHE

. TEST DE BOÎTE NOIRE

. TEST DE BOÎTE GRIS (WBT+BBT) ou TEST DE BASE DE DONNÉES

NIVEAUX DE TEST DYNAMIQUE

Un test dynamique sera effectué à 4 niveaux.

. Testng de composant/unité/module

. Test d'intégration

. Testng du système

. Test d'acceptation

APPROCHES DE TEST
Une approche de test traditionnelle [APPROCHE POSITIVE]
Montrez que le système

. Fait ce qu'il devrait

. Ne fait pas ce qu'il devrait faire

Objectif – Montrer le travail

Succès - Système Fonctionne

FACILE À ÉCRIRE DES CAS DE TESTResults = DEFECTS leſt in

Une meilleure approche de test [APPROCHE NÉGATIVE]

Montrez que le système

. Est-ce que ce qu'il devrait ne pas

. Ne fait pas ce qu'il devrait

Objectif - Trouver une faute

Success - System Fail

DIFFICULT TO WRITE TEST CASES

Résultat : moins de défauts laissés dans
Remarque : La meilleure approche pour tester l'application est l'approche négative qui essaie toujours de prouver
l'application ne fonctionne pas, n'essayez pas de prouver que l'application fonctionne. Alors seulement nous pourrons en trouver plus.

les défauts de l'application. Plus nous trouvons de défauts, meilleure sera la qualité de l'application.

5
POURQUOI UNE APPLICATION LOGICIELLE AURA-T-ELLE DES DÉFAUTS

. ExigenceIncorrecte

. Mauvais Design

. Mauvais codage

. Logique commerciale complexe et technologie complexe

LES DÉFAUTS LES PLUS COURANTS SONT

. Fonctionnalité incorrecte

. Modifications de données incorrectes

. Mauvaise performance et sécurité

. Incompatibilité

. Mauvaise interface utilisateur

. Mauvaise utilisabilité

MODÈLES DE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

Il existe différentes approches de développement logiciel définies et conçues qui sont

utilisés/employés pendant le processus de développement de logiciels, ces approches sont également appelées
Modèles de processus de développement logiciel

MODÈLES DU CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

MODÈLE SÉQUENTIEL MODÈLE INCRÉMENTAL ou MODÈLE ITÉRATIF

MODÈLE EN CASCADE MODÈLE D'APPLICATION RAPIDE

MODÈLE V MODÈLE PROTOTYPE

MODÈLE EN SPIRALE

Un modèle de cycle de vie de développement logiciel démontrera quelles seront toutes les activités de développement.
réalisé pour la mise en œuvre de logiciels

MODÈLE SÉQUENTIEL :
Ces modèles conviennent le mieux aux petits projets où toutes les activités du SDLC seront réalisées.
un après l'autre pour le projet entier.

Le modèle en cascade et le modèle V sont les meilleurs exemples de MODÈLES SÉQUENCE.

6
 MODÈLE EN CASCADE
User Requirements

Exigences du système

Conception de haut niveau

Conception de bas niveau

Codage

Testng

Livraison

Dans le modèle en cascade, toutes les activités de mise en œuvre seront réalisées pour l'ensemble du projet après
un autre, ce modèle est le mieux adapté pour les petits projets où les exigences sont très claires
Comme la taille de l'application est petite et que les exigences sont très claires, la validation est
assez, les vérifications ne sont pas requises pour ce modèle de projet car le flux d'activité ressemble à de l'eau
L'automne, ce modèle est intitulé Modèle de cascade.

Modèle en V

Exigences de l'utilisateur (Vérifier) (UAT) Déployer

System Requirements (Vérifier) (Validation) Système de construction

Conception de haut niveau (Vérifier) Intégration (Validation)

Conception de bas niveau Construire des unités

(Vérifier) (Unittestng)

Codage (Vérifier)

Ce modèle est adapté pour des applications de petite taille où les exigences ne sont pas claires, car le
les exigences ne sont pas claires, les chances de faire des erreurs sont plus grandes lors de la mise en œuvre.
applicatonto reducethis atevery stage of implementng a so ſtwaretestng applied i.e. both
La vérification et la validation seront effectuées pour les projets en V Model.

7
 MODÈLES INCRÉMENTAUX OU ITÉRATIFS
Ces modèles sont les mieux adaptés pour de grands projets dans le modèle incrémental, un grand projet sera
divisé en modules, toutes les activités du SDLC seront réalisées module par module.
Le Modèle de Développement d'Applications Rapides, le Modèle Prototype, le Modèle Spirale sont les meilleurs exemples pour
Modèle incrémental.

MODÈLE DE DÉVELOPPEMENT D'APPLICATION RAPIDE

Dans le modèle RAD, un grand projet sera divisé en modules et chaque module sera considéré comme un
mini projet. Une équipe séparée sera programmée pour mettre en œuvre toutes les activités du SDLC pour ces modules
simultanément. Une fois tous les modules implémentés, ces modules seront combinés et livrés au
client

Le module RAD est un modèle si coûteux car il nécessite d'énormes ressources, il est donc recommandé.
lorsqu'il y a peu de temps pour développer un projet.

Projet

Module 1 Module 2 Module 3

Exigence Exigence Exigence

Planification Planification Planification

Conception Conception Conception

Codage Codage Programmation

MODÈLE
Testng PROTOTYPE Testng Testng

Ce modèle est recommandé lorsque la taille de l'application est grande et que les exigences commerciales du client
ne sont pas clairs. Comme les exigences ne sont pas claires, au lieu de construire l'application réelle, un
Une application fictive appelée prototype sera développée et démontrée au client pour obtenir le
retour précoce.

Une fois que le client a approuvé le prototype basé sur les exigences système du prototype approuvé.
sera préparé et vérifié. Toutes les activités du SDLC seront réalisées en fonction du SRS. Si des changements
sollicité par le client après la livraison du système, cela sera documenté comme une demande de changement
et ces changements seront intégrés dans le cahier des charges existant (SRS) basé sur
Les modifications apportées au SRS mettront à jour toutes les activités restantes du SDLC. Ces cycles seront
continué pour tous les modèles dans le projet.

8
 User Requirements Exigences de changement

Développer un prototype Préparez S.R.S

Vérifier Vérifiez

Conception

Codage

Testng

Delivery

MODÈLE EN SPIRALE
Ce modèle est le mieux adapté pour les projets de maintenance où il y a des changements fréquents.
exigences ou exigences dynamiques du client. Dans ce modèle, l'application sera
mis en œuvre exigence par exigence comme le flux des activités ressemble à un filet en spirale, cela s'appelle
modèle en spirale.

9
 TEST DE LOGICIEL

Test statique Testng dynamique

Avis
Unité Intégration Système U.A.T
Revue de gestion Testng Testng Testng
Revue Technique

Revue de code Test de boîte blanche Test de boîte noire

Revues formelles
Test Grey Box
Avis informels

Visites guidées

10
 TECHNIQUES DE TEST STATIQUE

TEST STATIC :
C'est un processus de vérification pour déterminer si nous développons le bon système ou non, ce test de statut sera
réalisé avec l'aide d'Avis et de Guides.

REVIEWS:
L'examen d'un travail lié à un projet ou d'un travail lié à un processus s'appelle une revue.
Par exemple : Examiner les exigences, Conception, Code, etc...

« LE TEST STATIC NE DÉROULE PAS LE CODE »

TYPE OF REVIEWS:

1) ManagementReview
2) Revue technique
3) Revue formelle
4) Informal Review

REVUE DE GESTION :
Cette révision sera effectuée par la direction de haut niveau ou la direction de niveau intermédiaire pour surveiller le projet

statut. Ces avis sont utiles pour la direction afin de prendre les mesures correctives nécessaires si
il y a des écarts.

SLIP AGE:

L'écart entre les efforts planifiés et les efforts réels s'appelle le GLISSEMENT.

Les réunions quotidiennes ou hebdomadaires de suivi de projet sont appelées revues de gestion.

REVUES TECHNIQUES :

Ces avis seront réalisés parmi les personnes techniques pour décider de la meilleure approche de
mise en œuvre, s'il y a des ambiguïtés lors de la mise en œuvre d'un travail technique.

REVUES FORMELLES :

Si un examen est effectué selon un plan préalable en suivant des procédures systématiques et appropriées
La documentation sur cette revue est appelée Revue Formelle

Modérateur/Inspection
Auteur Leader
Demande formelle
BA
Scribe/Enregistreur

Examinateurs / Inspecteurs

11
 AUTHOR:Writer of a Document

MODÉRATEUR/LEADER D'INSPECTION : Une personne principale qui dirige l'activité d'examen est appelée
modérateur.

EXAMEN/INSPECTEURS : Participants d'un processus d'examen

SCRIBE/ENREGISTREUR : Une personne impliquée dans l'enregistrement des défauts lors de la réunion de revue est
appelé scribe

PHASES DES REVUES FORMELLES

1) Planification
2) Réunion de lancement
3) Préparation
4) Réunion de révision
5) Re-travailler
6) Suivi
Les inspections et les audits sont des exemples de revues formelles.

INSPECTION :

Si un examen formel est effectué lors de l'exécution d'une tâche, cela s'appelle une INSPECTION.

AUDIT

Si un examen formel est réalisé après l'achèvement d'une tâche, on l'appelle AUDIT.

INFORMAL REVIEWS

Si un examen est effectué sans suivre aucune procédure et documentation, alors ces examens sont
appelées évaluations informelles

Les évaluations entre pairs et les revues de code sont les meilleurs exemples d'évaluations informelles.

ÉVALUATIONS PAR LES PAIRS

Les évaluations effectuées entre collègues sont appelées ÉVALUATIONS PAR PAIRS.

OBJECTIFS DES REVUES

Pour identifier les défauts dans les exigences

Pour trouver des défauts dans la conception

Pour identifier les écarts dans tout processus

12
 Fournir des suggestions précieuses pour améliorer le processus

VISITES GUIDÉES

Une présentation étape par étape menée par l'auteur ou par un expert du domaine sur un sujet.

Les KTS (Sessions de Transfert de Connaissances) sont le meilleur exemple de démonstrations.

13
 TEST DYNAMIQUE
TECHNIQUES DE TESTING EN BOÎTE BLANCHE :

TestNG a été effectué sur le code source par les développeurs pour assurer la couverture du code. C'est-à-dire que le code
fonctionne comme prévu ne sont pas appelés test de boîte blanche. Les tests unitaires et les tests d'intégration sont
appelé collectivement Test blanc. WBT est également appelé test de boîte en verre ou test de boîte claire ou
testngstructure.

BESOIN DE TESTING EN BOÎTE BLANCHE

Trouver des défauts est facile car le code est visible

Pour éliminer autant de défauts que possible, la correction des défauts identifiés dans BBT est
consommation de temps parce que l'analyse des causes profondes prend du temps.

Le test en boîte blanche est plus économique par rapport au test en boîte noire.

Pour garantir une couverture de code de 100%

TEST UNITAIRE

Un porton testable le plus petit dans le code source de l'application est appelé UnitTestng/Module
testng /ComponentTestng. Tels que Fonctions, Procédures, Méthodes, Objets, etc.

Dans le code source de l'application, des unités sont appelées, et des tests sont effectués sur cette unité pour vérifier si...

le code fonctionne comme prévu ou pas, est appelé test unitaire.

Code source Programme 1

Lire A
Programme Programme Lire B
1 2 Si A > B Alors
Fonction Fonction A est grand
1 2 sinon
Procédure Procédure Imprimer "A n'est pas grand"
1 2 Fin si

Test effectué sur le Programme 1 par le développeur pour vérifier que le code derrière le programme 1 fonctionne comme prévu.

les attentes ne sont pas appelées TEST DE UNITÉ.

TEST D'INTÉGRATION :
Une fois les tests unitaires terminés, les développeurs intégreront toutes les unités de code source et effectueront des vérifications.

interactions entre toutes ces unités, ce qui s'appelle l'intégration des tests. Basé sur la disponibilité de
le code source unites le test d'intégration sera réalisé selon 3 approches suivantes

14
 APPROCHE DU BIG BANG

APPROCHE DESCENDANTE

APPROCHE DE BAS EN HAUT

APPROCHE DU BIG BANG :

Cette approche est recommandée lorsque toutes les unités de code source sont disponibles et testées unitairement.
l'approche consiste à combiner toutes les unités de code source ensemble en un grand système puis à réaliser l'intégration entre
toutes ces unités seront validées, cela prend très peu de temps pour effectuer des tests d'intégration, mais si jamais
Les défauts rencontrés pour trouver la cause profonde du défaut deviendront une tâche difficile.

Unité- 1 Unité- 2 Unité - 3 Unité- 4

APPROCHE DE HAUT EN BAS

[Link]
Appeler le Sous 1
Appeler le sous 2

Sous 1 Sous 2
Appeler la fonction 1 Appeler la fonction 2
Appeler la procédure 1 Appeler la procédure 2

Fonction 1 Procédure 1 Fonction 2 Procédure 2

IncompleteCode Code Code Code

EMBOUT

[Link] et Sub1testé
Deuxième Sub1 et Procédure1 Testé
[Link] et Sous 2 Testé
NextSub2 et Fonction 2 Testé
NextSub2 et Procédure 2 Testés

Cette approche est recommandée s'il y a des programmes inachevés au niveau de base, dans ces derniers.
l'approche du test d'intégration sera effectuée de haut en bas, le programme incomplet à
le niveau du fond sera remplacé par des Stubs

15
 STUB : UN PROGRAMME SIMULÉ QUI REMPLACE UN PROGRAMME APPELÉ S'APPELLE
UN SQUELETTE.

APPROCHE PAR LE BAS

Conducteur
(Programme fictif)
[Link]
Incomplet
Code

Sous [Link] [Link]

Fonction 1 Procédure 1 Fonction 2 Procédure 2

Code Code Code Code

Cette approche est recommandée lorsqu'il y a des programmes incomplets au niveau supérieur.
L'approche des tests d'intégration sera effectuée de bas en haut. Le programme incomplet en haut sera
replaced with drivers.

UN PILOTE : UN PROGRAMME DE SIMULATION QUI REMPLACE UN PROGRAMME D'APPEL EST

APPELER UN CHAUFFEUR.

APPROCHE EN SANDWICH : Cette approche combine les approches descendante et ascendante.

intégration des tests. Dans ce module de niveau intermédiaire, des tests sont effectués en utilisant les pilotes et les stubs.

Principal

Conducteur

Sous
Module1
Bouchon

Sous Sous
Module2 Module3

CODE COVERAGE:

Le pourcentage de code testé lors de la WBT est appelé « Couverture de code ».

Exemple en 100 Lignes de Code (LOC) si 80 lignes de code sont testées, la couverture de code est de 80%.

16
 TECHNIQUES DE BOÎTE BLANCHE

Tester chaque ligne de code est impossible et cela demande beaucoup d'efforts pour éviter cela, tout en s'assurant en même temps.
100 % de couverture de code, les programmes appliqueront les techniques suivantes lors des tests en boîte blanche.

StatementCoverage

Couverture des conditions

Path or Branch Coverage

COUVERTURE DES DÉCLARATIONS :

La couverture des déclarations identifie quelles déclarations dans une méthode ou une classe ont été exécutées. C'est un
une métrique simple à calculer, et un certain nombre de produits open source existent qui mesurent ce niveau de
la couverture. Le pourcentage d'instructions analysées durant les tests White Box s'appelle Instruction
Couverture

Exemple Nombre de déclarations testées * 100

Lire (a) Total No of Statements

Lire(b)
Test Case Input Data Expected
Si a > b alors
1 7 7
b=a
**UN TEST À MINIMUM EST REQUIS POUR UNE COUVERTURE DE STATEMENT DE 100 %.

As all 5 Statements are covered bythistestcase we have 100% statementCoverage

Printb

17
COUVERTURE DES CONDITIONS : Le pourcentage de conditions testées lors des tests en boîte blanche est appelé
COUVERTURE DE CONDITION.

EXAMPLE:

Lire A Nombre de conditions testées * 100

Lisez B Nombre total de conditions

Dans cet exemple, il n'y a qu'une SEULE condition.

FAUX VRAI
disponible c'est-à-dire A>B, si cette condition est

testé, la couverture de condition est de 100%

réalisé.
Imprimer Imprimer

A n'est pas GRAND A est GRAND

Un cas de test suffit pour y parvenir
100 % de couverture des conditions pour ce qui précède
FIN
exemple.

COUVERTURE DES CHEMINS

Un chemin représente le flux d'exécution du début d'une méthode à sa sortie. Une méthode avec N
les décisions ont 2^N chemins possibles, et si la méthode contient une boucle, elle peut avoir une infinité
number of paths. Fortunately, you can use a metric called cyclomatc complexityto reducethe
nombre de chemins que vous devez tester. Le pourcentage de chemins exercés lors des tests en boîte blanche est
appelé Couverture de Chemin.

EXEMPLE 1
Nombre de chemins testés * 100
Lire A
Nombre total de chemins
Lire B
TestCase1 : 10, 5 Expected: A is Big.

FAUX VRAI Path Coverage = ½*100 = 50%

TestCase2 : 5, 10 Expected: A is notBig

Imprimer Imprimer Couverture de chemin = ½*100 = 50&
A n'est pas GRAND A est GRAND Minimum 2 cas de test requis pour 100%
couverture des chemins.
FIN
No of Statements = 7

No of Conditons = 1

Nombre de chemins = 2

18
 EXEMPLE 2

Lire A Cas de test minimum

Lire A
Si A>0 alors StatementCoverage = 1
OUI OUI Si A = 21 alors Branch Coverage = 3

Imprimez "Oui" InputExpected

Fin si TC 1 - 0 Erreur
IMPRIMER
NON NON
Fin Dans l'exemple ci-dessus, la couverture des chemins
si TC2 - 20 Erreur
assurer la couverture des déclarations tandis que
TC3 - 21ne garantira
la couverture de déclaration Clépas 100%
couverture de chemin
FIN

Une couverture de chemin à 100 % garantira automatiquement une couverture d'instructions à 100 %, mais ce n'est pas l'inverse.

Exemple :

Dans l'exemple ci-dessus, la couverture de chemin garantit la couverture des déclarations, tandis que la couverture des déclarations sera

ne garantissant pas une couverture de chemin à 100 %. Donc, la couverture de chemin est la meilleure technique pour assurer 100 % du code
couverture.

19
 TEST DE BOÎTE NOIRE OU TEST BASÉ SUR LA SPÉCIFICATION
Des tests réalisés sur l'application par des ingénieurs de test ou par des experts du domaine pour garantir les exigences.
la couverture c'est-à-dire que l'application développée selon les exigences du client n'est pas appelée noire
boxtestng. Il est également appelé testng basé sur les spécifications. testng système et testng d'acceptation utilisateur
appelés collectivement Tests en boîte noire.

Testng Système

Test fonctionnel Test non fonctionnel

+ve Testng Performance
-ve Testng Charger
Sécurité
Compatibilité
GUI (Interface utilisateur)
Utilisabilité

La validation des exigences fonctionnelles et non fonctionnelles du système s'appelle le test système.

LES TESTS SYSTÈME SONT GÉNÉRALEMENT CLASSÉS EN

Test fonctionnel du système

2) Test non fonctionnel du système

TEST DE SYSTÈME FONCTIONNEL

La validation des exigences fonctionnelles des affaires du système est appelée test fonctionnel du système.

TESTING SYSTÈME NON FONCTIONNEL

Validation des exigences non fonctionnelles telles que la performance, la charge, la sécurité, la compatibilité, l'utilisateur

L'interface, l'utilisabilité, etc. sont appelés tests système non fonctionnels.

APPROCHE DE TEST SYSTEME:

En tant que Testng système, cela doit être réalisé avec la perspective de l'utilisateur final, nous devons couvrir toutes les possibilités.

opérations effectuées par les utilisateurs finaux. Pour couvrir toutes les opérations possibles, nous devons effectuer les deux

Tests positifs et négatifs.

TEST POSITIF :

Un test a été effectué sur l'application avec une perspective positive pour vérifier ce que le système est censé faire.
do s'appelle le TEST POSITIF Entrer un nom d'utilisateur valide et un mot de passe valide puis cliquer sur soumettre
buton. To determine whatlogin supposeto do is called positvetestng.

20
 LOGIN Entrer un nom d'utilisateur valide et valide
mot de passe et cliquez sur le bouton soumettre. Pour
USERNAME déterminer ce que la connexion est censée faire
MOT DE PASSE appelé test positif.

SOUMETTRE

TEST DÉFAUT.

Des tests ont été effectués sur l'application avec une perception négative pour déterminer quels systèmes ne fonctionnent pas.
ce que l'on supposait faire s'appelle TEST DES CAS NÉGATIFS.

Saisie d'un nom d'utilisateur ou d'un mot de passe invalide

LOGIN
mot de passe cliquez sur le bouton soumettre pour
NOM D'UTILISATEUR X X déterminer ce que la connexion ne doit pas
MOT DE PASSE faire est appelé test négatif.
X X
SOUMETTRE

Saisir un nom d'utilisateur invalide ou un mot de passe invalide puis cliquer sur le bouton soumettre pour déterminer ce qui est incorrect.
ce qu'on est censé faire s'appelle le test de négativité.

L'objectif des tests de positivité est la conformité aux exigences, tandis que l'objectif de
le test négatif consiste à trouver des défauts.

CRITÈRES D'ADMISSION :

Un ensemble de préconditions pour commencer une activité s'appelle des Critères d'Entrée.

CRITÈRES D'ENTRÉE POUR LE TEST DE SYSTÈME

Toutes les exigences des clients doivent être examinées et approuvées.

100 % des tests unitaires et des tests d'intégration doivent être réussis.

Tous les cas de test préparés doivent être examinés et approuvés.

EXIT CRITERIA:

Un ensemble de postconditions pour arrêter une activité s'appelle CRITERES DE SORTIE.

QUAND ARRÊTER LES TESTS (OU) CRITÈRES DE SORTIE POUR LES TESTS SYSTÈME ?
Tous les cas de test devraient être exécutés avec succès et réussis

21
 1) Tous les défauts majeurs doivent être corrigés et clos.
2) Quand le temps est écoulé ou terminé.

TEST DE VALIDATION PAR L'UTILISATEUR :

C'est un processus de test effectué sur l'application pour déterminer si l'application est prête à être utilisée.
ou non. Les tests d'acceptation par les utilisateurs seront initiés après les tests du système. Les experts du domaine ou la fin
les utilisateurs sont les bonnes personnes pour réaliser le test d'acceptation utilisateur.

L'UAT peut être réalisé à 2 niveaux, à savoir

Test alpha
Bêta Test

TEST ALPHA :

C'est le premier niveau de tests d'acceptation réalisés dans les locaux de développement.
Dans ce type de test, les utilisateurs sont invités au centre de développement où ils utilisent le
L'application et les notes des développeurs enregistrent chaque saisie ou action effectuée par l'utilisateur. Tout
Un type de comportement anormal du système est noté et rectifié par les développeurs.

TEST BÊTA :

C'est le dernier niveau de test acceptable effectué sur le site du client.

Dans ce type de test, le logiciel est distribué en tant que version bêta aux utilisateurs et les utilisateurs testent le
application sur leurs sites. Au fur et à mesure que les utilisateurs explorent le logiciel, en cas d'exception/défaut, si cela se produit

cela est signalé aux développeurs.

22
 TECHNIQUES DE TEST INVISIBLE
TEST ENTIERS :

Si nous testons la fonctionnalité dans le système avec toutes les entrées valides possibles et les entrées invalides, alors cela s'appelle

TESTING EXHAUSTIF ou TESTING NON DÉTAILLÉ ou TESTING EN PROFONDEUR.

Les tests exhaustifs sont impossibles.

Étant donné que les tests exhaustifs sont impossibles à éviter en même temps, pour garantir 100 % des exigences.
couverture

Les techniques suivantes sont introduites dans les tests de boîte noire.

1) Classe d'équivalence / Partiton d'équivalence {CE/PE}

2) Analyse des valeurs frontières {BVA}
3) Table de Décision Testng {DTT}
4) Test de Transition d'État {STT}
5) Cas d'utilisation Testng

CLASSE D'ÉQUIVALENCE / PARTITION D'ÉQUIVALENCE {CE/PE}

Selon la classe d'équivalence / le modèle d'équivalence, en analysant d'abord les possibles valides et
entrée invalide puis divisez ces données en groupes. Lors de la création des groupes, assurez-vous que chaque entrée
les données qui appartiennent à un groupe produisent la même sortie.

Comme chaque entrée appartenant à un groupe produit la même sortie, chaque entrée prendra un temps égal.
montant de priorité pour les tests. Donc, nous n'avons pas besoin de tester avec chaque entrée, considérons une entrée de chacune.
classe de préférence valeur médiane pour le test.
Exemple
Préparez les données d'entrée en utilisant EC/EP

Application sous Testng technique pour vérifier ce qui précède

fonctionnalité c'est-à-dire le système
Entrez un caractère affichage d'un message approprié ou
pas. En fonction du type de
Soumettre
characters.

Message approprié

23
 VALIDE INVALIDE
Spécial Supérieur à 1
minuscules MAJUSCULE Numeric Personnages Nul Caractère
un Un 0 $ <BLANK> ab
b B 1 @ abc
c C 2 # abc123
d D 3 ^
e E 4 &
7 !
8 (
z Z 9 )

Exemple 2

Application sous Testng Sal Bet Salaire Salaire Non

>5K <50K <5000 >50K NULL Numérique
Salaire 5000 4999 50001 <BLANK> abc
VALIDE INVALIDE
Soumettre 4998 abc123
TestData
25000 -1
-2
Valide – 25000
-3
Invalide – 2000, 75000, 50000 Infini Infini

<BLANK>, abc123

Validation d'entrée :

Obligatoire
Exemple 3 : Dans
Numérique les logiciels bancaires, les frais de service pour la fonctionnalité de transfert de fonds sont indiqués ci-dessous
uniquement
préparez les données d'entrée pour vérifier si le système applique des frais de service appropriés ou non en fonction de
Minimum
amount 5000 et Maximum
transferred. 50000.1000 and amountabove 1lakh is not transferable
Amountbelow

Sno Amount Frais de service Données d'entrée valides

EC/EP - 5000, 25000, 65000
1 1000 à 10000 100
BVA – 1000/10000, 10001/50000,
2 10 001 à 50 000 200 50001/100000
Invalide - Données d'entrée
3 50 001 à 100 000 300
EC/EP – 500, 2Lks, <NULL>, abcd123
BVA – 999,100001

24
 VALIDE INVALIDE
Amt 1000- Amt 10001- Amt 50001 Amount < Amount > Non
NULL
10000 50000 -1 LK 1000 1LK Numérique
1000 10001 50001 999 100001 <BLANK Abcd
1001 10002 50002 998 100002 abc123

5000 25000 75000 0

-1

10000 50000 1 lakh Infini

ANALYSE DES VALEURS AUX LIMITES : Il a été observé que la plupart du temps, les programmeurs commettent
erreurs lors de la spécification des conditions aux limites telles que [ >, >=, <, <=] pour identifier ce type de défauts
L'analyse des valeurs limites est introduite dans le test en boîte noire.

Selon BVA, identifiez les partitions où il y a des plages, puis déterminez la limite extérieure et
limites intérieures (le cas échéant), considérer la valeur de la limite inférieure (VLI), valeur de la limite supérieure (VLS)
considérez chaque frontière intérieure comme des entrées valides et considérez 'LBV-1', 'UBV+1' pour la frontière extérieure comme invalides.

inputs

Les avantages évidents de l'analyse des valeurs limites sont l'amélioration de la robustesse du code et la préparation
système pour les pires scénarios. La robustesse est améliorée car les cas de test "propres" et "sales" sont
être utilisé intestng. Les cas "propres" représentent ceux dans la plage autorisée tandis que les cas "sales"
représenter ceux en dehors de la plage. De plus, les cas propres et sales aident à évaluer le système
capacité à gérer les pires conditions.

**EC/EP ET BVA ENSEMBLE GARANTISSENT UNE COUVERTURE DES EXIGENCES À 100%.

Avantages du test de boîte noire

Plus efficace sur des unités de code plus grandes que les tests de boîte en verre

Tester needs no knowledge of implementaton, including specific programming languages

Tester and programmer are independentof each other

Les tests sont effectués du point de vue de l'utilisateur.

Aidera à exposer toute ambiguïté ou incohérence dans les spécifications

Les cas de test peuvent être conçus dès que les spécifications sont complètes.

Inconvénients du test en boîte noire

Seul un petit nombre d'entrées possibles peut être effectivement testé, pour tester toutes les entrées possibles.
le flux prendrait presque une éternité
Sans des spécifications claires et concises, les cas de test sont difficiles à concevoir.

25
 Il peut y avoir une répétition inutile des tests si le testeur n'est pas informé des cas de test.
le programmeur a déjà essayé
Peut laisser de nombreux chemins de programme non testés

Ne peut pas être dirigé vers des segments spécifiques de code qui peuvent être très complexes (et
donc plus sujet à erreur)

La plupart des recherches liées aux tests ont été orientées vers les tests de boîte en verre.

TEST DE TABLE DE DÉCISION

Il est utile de dériver les cas de test pour valider la fonctionnalité, s'ils dépendent de plusieurs entrées.

For Ex: Entrée Condition 1 Condition 2 Conditon 3 Condition 4

User Name Vrai Vrai Faux Faux

Mot de passe Vrai Faux Vrai Faux

Attendu Boîte de réception

Erreur Erreur Erreur

Cas de test pour valider la connexion selon le tableau de décision TestNG

T/C No Cas de test Résultat attendu

1 Entrez un nom d'utilisateur et un mot de passe valides. Le système doit afficher la boîte de réception.
Cliquez sur Soumettre

2 Entrez un nom d'utilisateur valide et invalide. Le système doit afficher une erreur.
password, Click on Submit message

3 Saisissez un nom d'utilisateur invalide et valide Le système doit afficher une erreur
password, Click on Submitmessage

4 Entrez un nom d'utilisateur et un mot de passe invalides. Le système doit afficher une erreur.
Cliquez sur Soumettre le message

Le nombre de cas de test que nous pouvons préparer pour vérifier la fonctionnalité, s'il dépend de plusieurs entrées
est 2noù n est le nombre d'entrées. Chaque fois que chaque cas, nous n'avons pas besoin de couvrir tous les cas de test, nous pouvons
réduisez les cas de test en fonction du design du système.

TEST DE TRANSITION D'ÉTAT

Chaque application logicielle aura divers états (interfaces utilisateur). Les états de l'application vont
change un état à un autre état en fonction de l'opération que nous effectuons et en fonction de la date d'entrée
fournie. Pour vérifier tous les parcours possibles de l'application en cours d'essai, ce test de transition d'état est
utile.
Par exemple : Diagramme de transition d'état pour l'accès au compte client dans le logiciel de DAB.

26
 Non valide
Insérer Erreur
Carte
t Msg
Bloc
Carte
k
Valide

Carte

Demander 4 1er 2 nd 3ème

CODE PIN Essaye Essayer
Carte Essayer
Entrer
PIN

A/C

Accès

Fig : Diagramme de flux de données ATM

Préparer des cas de test pour vérifier la fonctionnalité d'accès au compte client

Cas de test 1 Inserta valid card and enter correctpin atfirst try

Cas de test 2 Inserta Valid Card enter incorrectpin atfirst try and correctpin @ 2ndessayer

TestCase 3 Inserta Valid Card enter incorrectpin atfirst try and correctpin @ 3rdessayer

Cas de test 4 Après 3rdla carte d'essai doit être bloquée

Cas de test 5 La carte valide doit être bloquée

Cas de test 6 Insertng card in invalid directon should show error message

TEST DE CAS D'UTILISATIONUn cas d'utilisation est une brève description des actions des acteurs et des réponses du système. Si vous
développez des cas de test pour vérifier si l'application est développée conformément aux cas d'utilisation ou non, alors c'est
appelé TEST DE CAS D'UTILISATION.

TEST DE BOÎTE GRISE

Le test est réalisé en combinant des composants à la fois structurels et non structurels pour valider un spécifiquement.
le scénario dans le système s'appelle Test de boîte grise.
Une combinaison de tests en boîte blanche et de tests en boîte noire est appelée test en boîte grise.

27
 ADMIN

MODULE
Login Pswd Role

U1 P1 Administrateur LOGIN
BANQUIER
U2 P2 Banquier USERNAME
MOT DE PASSE MODULE
U3 P3 Client
SOUMETTRE

CUSTOMER

MODULE

Dans l'exemple ci-dessus, pour vérifier si la connexion affiche le bon module au bon utilisateur ou non, nous
besoin d'interagir à la fois avec la base de données et l'application qui s'appelle grey boxtestng.
U10 P10 Administrateur
Note: Data Base Testng is a bestexample for grey boxtestng

TEST DE BASE DE DONNÉES validant diverses opérations effectuées dans le frontend au backend, validant
various operatons backend atfrontend validatng the Database design such as field datatype, filed
la taille, les contraintes et la validation des scripts SQL tels que les procédures stockées et les déclencheurs sont collectivement

appelé Data basetestng.

Le besoin de tests de base de données en général, un ingénieur de test confirmera la fonctionnalité en voyant le
messages appropriés générés par l'application. Par exemple :

BASEDEDONNÉES

EMP ID ENAME DESIGN SAL

ENREGISTREMENT DES EMP

EMP ID

ENAME

DÉSIGNATION

SALAIRE

SOUMETTRE

Employee Created Successfully

28
 Pour vérifier la fonctionnalité d'enregistrement d'EMP ci-dessus, un ingénieur de test saisira un empno valide.

nom, désignation, salaire et cliquez sur soumettre. Si l'application affichait un message EMP CRÉÉ
AVEC SUCCÈS, il suppose que cette fonctionnalité est justifiée dans le système, mais ici cette boîte de message est
une technique de programmation nota de confirmation de la base de données.
Donc, il n'est pas garanti que les données soient réellement stockées dans la base de données. Afin de confirmer cela

databasestestng est requis.

29
 CYCLE DE VIE DES ESSAIS LOGICIELS

Processus de cycle de vie des tests logiciels, modèles et terminologies

Gestionnaire de Projet/Test Stratégie de test

Planification des tests

Plan de Test

Étude BRS/SRS
Ingénieurs de test AnalyseDeTest
Préparation RCN

IngénieursDeTest Conception de test TestScenarios

TestCases/InputData

Métriques de traçabilité

Ingénieurs de test TestExecuton Exécuter les cas de test

Suivi des bogues et Rapport de bogues

Re-test

Test/ProjectManagers TestFermeture TestSummary Report

PLANIFICATION DES TESTS :

Une fois un projet programmé pour les tests, le Chef de projet ou le Responsable des tests définira la stratégie de test.
En se basant sur cette stratégie de test, un responsable de test prépare un document de plan de test.

POLITIQUE DE TEST :

C'est un document au niveau organisationnel qui explique comment les tests doivent être effectués.
organisation.

STRATÉGIE DE TEST :

C'est un niveau élevé de gestion planifié et approuvé pour tester une application, la stratégie de test sera
dérivé de la politique de test qui peut légèrement varier d'un projet à l'autre.

30
 TEST PLAN
C'est un plan détaillé de test d'une application qui explique la portée, l'approche, les ressources, les horaires, etc.
ce plan de test sera préparé par le responsable des tests en fonction de la stratégie de test

MODÈLE DE PLAN DE TEST

1.0 Objectifs
2.0 Portée
2.1 Dans le champ
2.1.1 Fonctionnalités à tester
2.1.2 Types de testng applicables
2.2 Hors champ
2.2.1 Fonctionnalités à ne pas tester
2.2.2 Types de testng n'est pas applicable
3.0 Approche
3.1 Approche d'analyse de tests
3.2 Approche de conception de test
3.3 Approche d'exécution des tests
3.4 DefectmanagementApproach
4.0 Ressources
4.1 Ressources matérielles
4.2 Ressources logicielles
4.3 Ressources humaines
5.0 Horaires
6,0 Entry criteria & Exitcriteria
6.1 Critères d'entrée
6.2 ExitCriteria
7.0 Livrables
7.1 Scénarios de test
7.2 TestCases
7,3 Métriques de traçabilité
7.4 Défauts

On l'appelle également matériel de test.

OBJECTIFS/DÉMARCHES D'UN PLAN DE TEST :

Un document de plan de test agit comme un document de lignes directrices, fonctionne comme une feuille de route pour tester un projet.

Le plan de test est utile pour déterminer ce qui suit

Portée de testng
Approche à suivre
Ressources
Horaires

31
 ANALYSE DE TEST
Inthis phasetestengineers will analyse varioustestrequirements i.e. BRS & SRSto determine what
pour être le meilleur et comprendre comment tester toutes les exigences. En analysant les exigences de test
s'il y a des questions, nous enregistrons nos questions dans un modèle de processus appelé exigence
note de clarification (RCN) Une fois que les exigences ont été étudiées, nous envoyons ce document à l'auteur ou
experts en la matière (SME) pour obtenir les éclaircissements.

MODÈLE DE SPÉCIFICATIONS DES EXIGENCES D'ENTREPRISE

1.0 Introduction
1.1 ClientIntroducton
1.2 ProjectIntroducton
2.0 Système Existant
3.0 Inconvénients du système existant
4.0 Système proposé
5.0 Architecture du système
6.0 Business Requirements

SRS: System Requirement Specifications

SRE : Spécifications des exigences fonctionnelles
FD : Document Fonctionnel
BRD : Document de exigences commerciales
BDD : Document de conception commerciale

Tous les documents mentionnés ci-dessus sont identiques, contenant des détails sur le système.
exigences

MODÈLE DE SPÉCIFICATIONS DES EXIGENCES SYSTÈME :

1.0 Aperçu
2.0 Prototype
3.0 Éléments de formulaire/Page

4,0 Validation de l'entreprise (ou) Validation d'entrée & États d'erreur

5.0 Diagramme de cas d'utilisation / DFD / Diagramme de flux de tâches

6.0 Cas d'utilisation

32
MODÈLE DE NOTE DE CLARIFICATION DES EXIGENCES

Note de clarification des exigences

Project Name:
Module Name:
Préparé par :
Prepared Date:
# Référence de spécification des exigences. Clarification Clarification Clarification Clarification
Requis sur Fournit Fournie
Fournie Par Date

33
 CONCEPTION DES TESTS

À ce stade, les testeurs prépareront des scénarios de test, des cas de test et des données de test, etc., en fonction des cas de test.

collecté auprès des membres de l'équipe, le responsable de test prépare la matrice de traçabilité.

SCÉNARIO DE TEST

CAS DE TEST

DONNÉES DE TEST (Si Nécessaire)

MATRICE DE TRAÇABILITÉ (Préparé par T.L)

SCÉNARIO DE TEST :

Un élément ou une fonctionnalité à tester dans l'application est appelé SCÉNARIO DE TEST.

MODÈLE DE SCÉNARIO DE TEST

Project Name
Références de document

Auteur Examined par

Date de création Reviewed Date
Scénario
Module Exigences Scénario de test
Identifiant

34
 CAS DE TEST
Un cas de test est un ensemble de préconditions, de scripts de test, de données d'entrée et de résultats attendus à valider.

fonctionnalité dans le système.

(Ou)
Un cas de test est une brève description de ce qui doit être testé et comment le tester

Types de cas de test

1)+ Ve cas de test : Si un cas de test est préparé pour vérifier ce que le système prend en charge alors i

s'appelle "+ Ve Cas de test "

Ex: Vérifiez la CONNEXION avec des entrées valides

2) – Ve cas de test : Si un cas de test est préparé pour vérifier ce que le système ne prend pas en charge.

alors il est appelé "- Ve cas de test"

Ex: vérifier la connexion avec des entrées non valides.

3) Cas de test de validation des affaires : Si un cas de test est préparé pour vérifier l'affaire
validation alors on l'appelle "cas de test B.V".

Modèle de cas de test

ID DU CAS DE TEST : <Nom-Projet>_<Nom-Module>_<Référence-Document>_<Scénario-Test>

35
 MATRICE DE TRAÇABILITÉ DES EXIGENCES (MTE)

TRACEABILITY:The ability of identfying a batch oftestcases (group oftestcases)that

appartient à une exigence appelée « Traçabilité »

Mapping betweentestcases & Requirementis called “TRACEABILITY MATRIX”

Avantages du RTM

1)À dedéterminez le % de couverture des tests

2) Pour identifier un bacas de test qui appartient à une exigence

3) Pour mettre en œuvre facilementdemande de changement.

36
 MODÈLE RTM

Matrice de traçabilité
Projet Chef de projet
Nom
Préparé Approuvé par
Par
Préparé Reviewed-On
Sur
Last Updated-On
Exigence
Traçabilité Id/ Test
Id Description Use Case Ref Scénarios Réf. du cas de test

37
 EXÉCUTION DU TEST
EXÉCUTION DES TESTS : Exécution d'un test formel ou de cas de test informels pour confirmer l'entreprise

Les exigences et l'identification des défauts s'appellent l'exécution des tests.

PROCESSUS DE PUBLICATION DE VERSION : Conformément à la date de publication de la version déjà planifiée, les développeurs publieront le

buildtotestngteam avec chaque version de build nous recevons 2 documents ils sont (SRN, DD)

Soſtware requirement Notes, Deployment Document

BUILD : Une application exécutable s'appelle Build

NOTES DE VERSION DU LOGICIEL (NRL) : Ce document fournit les informations suivantes

Informations sur le développement et l'équipe de test

Deploymentpath
problèmes connus (s'il y en a)
Scénarios de test de régression (le cas échéant)

DOCUMENT DE DÉPLOIEMENT : Ce document fournit l'ensemble des directives pour le déploiement

environnement d'application intestin

TYPES DE TESTS DANS LE TEST DE SYSTÈME FONCTIONNEL

Fumée/Santé/Acceptation de Build/Validation de Build/Préliminaire/Test Pilote C'est une sorte de test rapide

ou des tests rigoureux effectués sur la demande pour déterminer si la demande est éligible pour un majeur
testng ou pas
Par exemple, si le nouveau logiciel fait planter les systèmes toutes les 5 minutes, le logiciel peut ne pas
être dans un état 'sain' suffisant pour justifier des tests supplémentaires dans son état actuel

OBJECTIFS DES TESTS DE FUMÉE

L'objectif de smoketest est de déterminer si l'application est testable ou non, sans chercher à trouver
défauts, donc nous ne devrions pas signaler de défauts lors du test de validation, ce qui doit être testé dans le test de validation.
pour déterminer si cette application est stable ou non.
Vérifiez ce qui suit

Vérifiez si les fonctionnalités de base sont disponibles ou non.

Vérifiez si l'application est constamment opérationnelle ou non.
TEST FORMEL : Tester l'application en suivant toutes les procédures préalablement planifiées s'appelle FORMEL
TEST

PROCÉDURES EFFECTUÉES PENDANT LES TESTS FORMELS :

Assurez-vous que tous les cas de test sont examinés et approuvés

38
Arrangez tous les cas de test par ordre de priorité pour effectuer des TESTS BASÉS SUR LE RISQUE ou des TESTS BASÉS SUR LA PRIORITÉ

Exécutez toutes les étapes appartenant à un cas de test dans un ordre séquentiel, après avoir documenté les étapes.
comportement réel puis comparer le comportement attendu avec le comportement réel. Lorsque les deux sont
document apparié les résultats de l'étape passent. Si non apparié alors document comme échoué

Une fois que toutes les étapes appartenant à un cas de test sont exécutées, résumez ou agrégatez les résultats du cas de test. C'est-à-dire si

tous les étapes sont passées le testfinal, resultid réussi, si l'une des étapes échoue. Le résultat du cas de test est
échoué

si des défauts sont rencontrés, documentez-les dans un modèle de rapport de bogue ou dans un rapport de bogue.
outil et rapport identique au développeur

TESTING ADHOC OU TESTING INFORMEL : Si nous testons l'application sans suivre de plan préétabli
procédures c'est-à-dire comme vous le souhaitez, alors cela s'appelle TESTING AD HOC, en plus des tests formels ad hoc
TestNG est également recommandé pour trouver des défauts difficiles. Les tests ad hoc sont également recommandés lorsqu'il y a
pas de test de développement de cas.

RE-TESTING : Tester une fonctionnalité de manière répétée (encore et encore) s'appelle le retesting. Le retesting entre dans
les deux scénarios suivants testent la fonctionnalité avec plusieurs entrées pour confirmer la validation des affaires
testng functonality in modified buildto confirmthe bug fixes.

TEST DE RÉGRESSION : Réexécution ou nouvelle exécution de cas de test sélectionnés pour le dépendant
fonctionnalité sur l'identifiant de build modifié appelé TEST DE RÉGRESSION

OBJECTIFS : Les corrections de bogues ou les nouvelles fonctionnalités ajoutées ou les fonctionnalités existantes modifiées peuvent

introduire des effets secondaires pour déterminer que ce test de régression des effets secondaires est mené

TESTING DE LA FIN À LA FIN : C'est un type de test global effectué sur la version finale depuis une extrémité.
à une autre fin, construire la confiance c'est-à-dire savoir si l'application est prête à être publiée ou non.
Les tests de bout en bout seront réalisés par des experts du domaine qui ont une connaissance complète de
projet

TESTING EXPLORATOIRE : explorer l'application, ajouter ou modifier les cas de test existants pour
betertestng est appelé Exploratory Testng.

ERREUR DE DEVINER : Avec la connaissance préalable et l'expérience d'un testeur. Deviner l'erreur dans
Certaines zones critiques sont appelées ERREUR DE DEVINETTE.

TEST DE MUTATION : C'est un processus d'injection délibérée des défauts pour confirmer si les testeurs
tester correctement l'application ou non.

MONKEY TESTING/ ZIG ZAG TESTING RATTLE TESTINGT:Testng a applicaton in a uneven way or in
Une méthode en zigzag pour trouver des défauts s'appelle TEST DE SINGE.

39
 TYPES DE TESTS DANS UN SYSTÈME NON FONCTIONNEL

TEST DE L’INTERFACE UTILISATEUR / TEST DE L’INTERFACE GRAPHIQUE : Validation que les interfaces utilisateur sont
profession conçue ou non est appelée TEST DE L'INTERFACE UTILISATEUR.

LISTE DE VÉRIFICATION POUR LES TESTS D'INTERFACE UTILISATEUR

Vérifiez si les éléments de base sont disponibles ou non (référez-vous au prototype ou aux éléments de la page)
section dans SRS
Vérifiez l'orthographe des objets
Vérifiez les alignements des objets
Vérifiez la cohérence de la couleur de fond, de la couleur de premier plan, du type de police, de la taille de police, etc.

Vérifiez si les champs obligatoires sont surlignés ou non.

TEST DE FACILITÉ D'UTILISATION : Vérification de la convivialité des applications, c'est-à-dire la facilité avec laquelle l'utilisateur final peut les utiliser.

la capacité de comprendre et d'utiliser le système ou d'opérer le système s'appelle TEST DE L'USABILITÉ

TEST DE SÉCURITÉ : Valider si toutes les conditions de sécurité sont correctement intégrées dans l'application ou non.
s'appelle sécurité.
Listes de contrôle :

Vérifier l'autorisation :
TEST DE L'AUTORISATION : Valider si le système a des dispositions définissant
utilisateurs, définir les privilèges et changer les privilèges ou non.

Vérifier l'authentification

TEST DE VALIDATION D'AUTHENTIFICATION : Valider si le système est capable de reconnaître le

les utilisateurs enregistrés et fournir les bonnes informations au bon utilisateur ou non est appelé
Test d'authentification.

Vérifiez si des informations critiques telles que le mot de passe, le numéro de carte de crédit, etc. sont obtenues.
chiffré ou non
Vérifiez l'accès directURL
Vérifiez l'expiration de la session
Vérifiez la navigation du navigateur en arrière et les navigations en avant après la session expirée.

TEST DE PERFORMANCE : Analyse des diverses caractéristiques d'efficacité d'une application logicielle telle que
as response tme,through put, load, stress,transacton per minute,transacton mix, resource
la consommation, les hits par seconde sont appelés Test de Performance.

TEST DE COMPATIBILITÉ : Validation de la compatibilité de l'application avec divers matériels et

environnements logiciels (compatibilité du système d'exploitation, compatibilité du navigateur)

TEST DE RÉCUPÉRATION : Vérification si le système dispose d'une option de sauvegarde et de restauration.

ou pas et aussi comment le système gère-t-il des situations imprévisibles telles que les pannes de courant &
crashes de système, etc.
TEST DE MONTAGE ou TEST DE DOCUMENTATION ou TEST DE DÉPLOIEMENT : Validation fait
l'application installable avec succès ou non selon les directives fournies dans le document d'installation
appelé Testng d'installation.

40
TEST DE DÉSINSTALLATION : Vérification si nous sommes en mesure de désinstaller le produit avec succès.
système de notifications appelé Testng d'installation UN.

TEST DE GLOBALISATION : Validation de l'application qui a une disposition pour changer

(langue, monnaie, format de date et d'heure, etc. s'il est conçu pour des utilisateurs du monde entier.)

TEST DE LOCALISATION : Validation de la langue par défaut, de la devise, du format de date / heure, etc., lorsqu'un
Une application conçue pour une localité particulière d'utilisateurs s'appelle TEST DE LOCALISATION

41
 CYCLE DE VIE D'UN BUG / DÉFAUT

CYCLE DE VIE DES DÉFAUTS ou CYCLE DE VIE DES BUGS

Nouveau
Tester

Info pas Publier Déjà

Invalide Valide
Clair
Mettez Signalé
Rejeté Ouvrir Attendez Différé Dupliquer

Résolu

Construction Modifiée

Rouvrir Si DéfaillanceRéparée Fermé

REPRODUISIBLE (O/N) : Si un défaut se produit chaque fois, on parle de défaut reproductible, si un

défauts Reproductibles énumérez les étapes pour reproduire le défaut qui aide le développeur à analyser
le défaut rapidement. Si un défaut n'est pas reproductible ou si nous ne sommes pas en mesure de décrire clairement le défaut
capture l'écran, photo du défaut et envoyer au développeur.

42
Type – I Type –II Type – III Severity Descripton

S0 Mortel Très élevé Toutes les erreurs d'exécution, défauts bloquants

S1 Majeur Haut Non-conformité aux exigences

S2 Mineur Moyen Les exigences sont justifiées, il y a pourtant une légère déviation.

S3 Bas Faible Interface utilisateur / Utilisabilité

GRAVITÉ DU DÉFAUT : La gravité du défaut ou l'impact du défaut dans le système est appelée
DefectSeverity.
Différentes gravités de défauts

** Le testeur est la bonne personne pour spécifier la gravité des défauts

PRIORITÉ DES DÉFAUTS : L'ordre dans lequel le défaut doit être corrigé est appelé Priorité des Défaillances.
Le développeur est la bonne personne pour spécifier la priorité.

Org 1 P0 P1 P2 P3

Org2 Très élevé Élevé Moyen Bas

En général, la gravité des défauts et les priorités sont proportionnelles l'une à l'autre. Mais dans certains scénarios, cela
les sévérités et les priorités peuvent changer.

Un défaut de haute gravité et de faible priorité

Un problème sérieux appartient au module de version future
Un défaut qui a une faible gravité et une haute priorité, logo incorrect, titre, etc.

DÉFAUT RÉTENTISSEUR : Un défaut qui ne nous permettra pas de poursuivre les tests.
DEFECT AGE: The tme interval between date of defectand date of closure or how long a bug is

43
existe dans le cycle de vie du développement.

44
TEST MANAGEMENT:

Planification des tests

RequirementManagement
Gestion de configuration
Gestion du contrôle des changements
Contrôle de Version
Gestion des versions de construction

DefectManagement
Gestion des risques

PLANIFICATION DES TESTS : Un responsable des tests est chargé de planifier les activités de test logiciel pour un bon déroulement.

exécution d'un projet ; généralement, la section du plan de test contiendra les éléments suivants

Portée de testng
Approche à mettre en œuvre
Ressources
Horaires, etc.
GESTION DES EXIGENCES : Tous les besoins commerciaux des clients doivent être documentés.
Les exigences commerciales doivent avoir un numéro d'identification unique grâce auquel nous
devrait dans une position de tracer les exigences de couverture à tout moment. Pour y parvenir sur une base quotidienne
les documents de traçabilité des exigences doivent être mis à jour

GESTION DE CONFIGURATION : cela inclut

GESTION DES DÉFAUTS : Afin de suivre l'état du défaut et également de générer divers MIS
Les rapports liés aux défauts, une procédure adéquate d'enregistrement des défauts doit être définie, c'est mieux.
pratique de la définition de tous les défauts dans une base de données centralisée

GESTION DES RISQUES : lors de l'exécution d'un projet, il existe une chance de divers risques possibles qui peuvent
cela entraîne un glissement de la livraison pour éviter cela, une gestion des risques appropriée doit être effectuée.
Risque : un problème possible qui peut avoir un impact négatif sur un travail est appelé un risque.

45
GESTION DE LA CONFIGURATION LOGICIELLE

COMMON REPOSITORY: A centralised computer system where you define and manage all project
des ressources telles que les spécifications des exigences, les spécifications de conception, le code, les cas de test, le rapport de défaut, etc. s'appellent un

dépôt commun.

Enregistrement et gestion de toutes les ressources du projet dans un système centralisé et gestion de la version
basé sur les changements apportés à ces ressources collectivement appelées gestion de configuration.

AVANTAGES DE LA GESTION DE CONFIGURATION

Partager les ressources entre l'équipe

Pour surveiller l'état du projet, à tout moment.
Pour maintenir un contrôle de version approprié
Un dépôt commun agit comme un système de sauvegarde pour les fichiers sources.

OUTILS DE GESTION DE CONFIGURATION FAMILIERS

VSS - Visual Source Safe (Microsoft)

CVS - Système de gestion de versions concurrentes (open source)

46
 MANUALTESTING FAQ’s

Qu'est-ce que la traçabilité bidirectionnelle ?

La traçabilité bidirectionnelle doit être mise en œuvre à la fois dans le sens direct et inversé (c'est-à-dire, de
exigences des produits finis et des produits finis aux exigences).
Lorsque les exigences sont bien gérées, la traçabilité peut être établie depuis la source.
exigence à ses exigences de niveau inférieur et des exigences de niveau inférieur retour à
leur source. Une telle traçabilité bidirectionnelle aide à déterminer que toutes les exigences de source
ont été complètement traités et que toutes les exigences de niveau inférieur peuvent être tracées à un
source valide.

Qu'est-ce qu'un stub ? Expliquez du point de vue de TestNG ?

Un stub est un programme ou un composant fictif, le code n'est pas prêt pour les tests, il est utilisé pour
testng...cela signifie que, dans un projet, s'il y a 4 modules et que le dernier est en cours et qu'il n'y a pas de
Ensuite, nous utiliserons un programme fictif pour compléter ce quatrième module et nous allons l'exécuter.
les 4 modules entiers aussi. Le programme fictif est également connu sous le nom de stub.

For Web Applicatons what type of tests are you going to do?

Les applications basées sur le Web présentent de nouveaux défis, ces défis comprennent :
- Cycles de sortie courts;
Technologie en constante évolution;
- Nombre d'utilisateurs potentiellement énorme lors du lancement initial du site web ;
Incapacité à contrôler l'environnement d'exécution de l'utilisateur ;
Disponibilité du site Web 24 heures sur 24.

La qualité d'un site web doit être évidente dès le départ. Toute difficulté, que ce soit dans la réponse
le temps, la précision des informations ou la facilité d'utilisation - poussera l'utilisateur à cliquer sur un concurrent
site. De tels problèmes entraînent une perte d'utilisateurs, une perte de ventes et une mauvaise image de l'entreprise.

Pour surmonter ces types de problèmes, utilisez les techniques suivantes :

Test de fonctionnalité
Les tests de fonctionnalité impliquent de s'assurer que les fonctionnalités qui affectent le plus les interactions des utilisateurs.
travailler correctement. Cela inclut :
· formulaires

recherches
fenêtres contextuelles
chariots de courses
paiements en ligne

2. Test de convivialité
de nombreux utilisateurs ont une faible tolérance pour tout ce qui est difficile à utiliser ou qui ne fonctionne pas.

47
La première impression de l'utilisateur sur le site est importante, et de nombreux sites Web sont devenus encombrés.
avec un nombre croissant de fonctionnalités. Pour les sites web à usage général, les utilisateurs frustrés peuvent facilement
cliquez sur le site d'un concurrent.

Le test d'utilisabilité implique les étapes principales suivantes

· identifier le but du site web;
Identifier les utilisateurs indentés;
· définir des tests et réaliser les tests d'utilisabilité
analyser les informations acquises

3. Test de navigation
Good Navigaton is an essental partof a website, especiallythosethatare complex and
Fournir beaucoup d'informations. Évaluer la navigation est une partie importante de l'évaluation de l'utilisabilité.

4. Formulaires Testng
Les sites Web qui utilisent des formulaires ont besoin de tests pour s'assurer que chaque champ fonctionne correctement et que le
les formulaires affichent toutes les données comme prévu par le designer.

5. Test de contenu de page

Chaque page web doit être testée pour le contenu correct du point de vue de l'utilisateur.
contenu du point de vue de l'utilisateur. Ces tests se classent en deux catégories : s'assurer que chacun
les fonctions de composant correctement et en veillant à ce que le contenu de chacune soit correct.

6. Tests de configuration et de compatibilité

Un défi clé pour les applications Web est de s'assurer que l'utilisateur voit une page Web comme le
designer intended. The user can selectdifferentbrowser soſtware and browser optons, use
des logiciels de réseau différents et des services en ligne, et exécutez d'autres applications simultanées. Nous
exécutez l'application sous chaque combinaison de navigateur/plateforme pour garantir les sites web
travailler correctement dans divers environnements.

7. Test de Fiabilité et de Disponibilité

Une exigence clé pour un site web est qu'il soit disponible chaque fois que l'utilisateur en fait la demande, après 24-
heures par jour, tous les jours. Le nombre d'utilisateurs accédant au site Web simultanément peut également
affecter la disponibilité du site.

8. Test de performance
Test de Performance, qui évalue la performance du système sous une utilisation normale et intensive,
est crucial pour le succès de toute application web. Un système qui met trop de temps à répondre peut
frustrer l'utilisateur qui peut ensuite rapidement se déplacer vers un site concurrent. Donnez assez de temps,
chaque demande de page sera finalement livrée. Les tests de performance visent à garantir que
le serveur du site web répond aux requêtes des navigateurs dans des paramètres définis.

9. Charger testng
Le but de Loadtesting est de modéliser des expériences du monde réel, généralement en générant beaucoup
utilisateurs simultanés accédant au site Web. Nous utilisons des outils automatisés pour augmenter la capacité
pour effectuer un test de charge valide, car il simule des milliers d'utilisateurs en envoyant
demandes simultanées à l'application ou au serveur.

48
10. Test de résistance
Le test de stress consiste à soumettre le système à des charges variées et maximales pour évaluer
la performance résultante. Nous utilisons des outils de test automatisés pour simuler des charges sur le site web et
exécutez les tests en continu pendant plusieurs heures ou jours.

11. Test de Sécurité

La sécurité est une préoccupation principale lors de la communication et de la conduite des affaires - surtout
transactions sensibles et critiques pour les affaires - sur Internet. L'utilisateur veut une assurance
que les informations personnelles et financières sont sécurisées. Trouver les vulnérabilités dans une application
il est important qu'un utilisateur non autorisé puisse accéder au système.

Define Brain Stromming and Cause Effect Graphing?

BS :
Une technique d'apprentissage impliquant des discussions de groupe ouvertes visant à élargir le champ de
idées disponibles
OU
Une réunion pour générer des idées créatives. Chez PEPSI Advertising, quotidiennement, hebdomadairement et bimensuellement.

Des sessions de brainstorming sont organisées par divers groupes de travail au sein de l'entreprise. Nos réunions mensuelles I-
La réunion de brainstorming de puissance est attendue par tout le personnel de l'agence.
OU
Le brainstorming est un processus très structuré pour aider à générer des idées. Il est basé sur le
le principe selon lequel vous ne pouvez pas générer et évaluer des idées en même temps. Pour utiliser
brainstorming, vous devez d'abord obtenir l'accord du groupe pour essayer le brainstorming pour un fixe
intervalle (par exemple, six minutes).

CEG :
Atestngtechniquethataids in selectng, in a systematc way, a high-yield setoftestcases
cela relie logiquement les causes aux effets pour produire des cas de test. Il a un effet secondaire bénéfique dans
soulignant l'incomplétude et les ambiguïtés dans les spécifications.

Quelle est la longueur maximale du cas de test que nous pouvons écrire ?

Nous ne pouvons pas dire exactement la longueur du cas de test, cela dépend de la fonctionnalité.

Le mot de passe a 6 caractères alphanumériques, alors quelle est la saisie possible

conditions ?

Les conditions d'entrée possibles incluent également des caractères spéciaux :

1) Mot de passe d'entrée = 6abcde (c'est-à-dire un nombre d'abord)
2) Mot de passe d'entrée = abcde8 (c'est-à-dire caractère d'abord)
3) Mot de passe de saisie = 123456 (tous les chiffres)
4) Saisissez le mot de passe comme = abcdef (tous les caractères)
5) Mot de passe inférieur à 6 chiffres
6) Mot de passe supérieur à 6 chiffres
7) Saisir le mot de passe sous forme de caractères spéciaux

49
8) Entrez le mot de passe en MAJUSCULES c'est-à-dire en lettres majuscules
9) Mot de passe d'entrée incluant un espace
10) (ESPACE) suivi d'alphabets/nombre/alphanumérique/

Qu'est-ce que le test d'internationalisation ?

L'internationalisation des logiciels est le processus de développement de produits logiciels indépendamment de

normes culturelles, langue ou autres attributs spécifiques d'un marché

Si je donne quelques milliers de tests à exécuter en 2 jours, que fais-tu ?

Si possible, nous allons automatiser ou sinon, exécuter uniquement les cas de test qui sont obligatoires.

Que signifie le test en boîte noire au niveau unitaire, d'intégration et système ?

Tests pour chaque exigence logicielle utilisant le partitionnement en classes d'équivalence, la valeur limite
Testng, et plus de cas de test pour les exigences logicielles du système en utilisant la matrice de traçabilité,
Tests interfonctionnels, tableaux de décision et plus de cas de test pour l'intégration du système pour
configurations, opérations manuelles, etc

Qu'est-ce que TestNG agile ?

Agiletestng est utilisé chaque fois que les exigences du client changent dynamiquement.

Si nous n'avons pas de SRS, de BRS mais que nous avons des cas de test, exécutez-vous les cas de test à l'aveugle ou faites-vous...

vous suivez un autre processus.

Le cas de test contiendra des étapes détaillées de ce que l'application est censée faire.
1) Fonctionnalité de l'application.
2) De plus, vous pouvez vous référer au Backend, qui signifie examiner la base de données. Pour en savoir plus.
connaissance de l'application.

Qu'est-ce que le cycle de vie d'un bogue ?

Nouveau : quand le testeur signale un défaut

Ouvert : lorsque le développeur accepte qu'il s'agit d'un bogue ou si le développeur rejette le défaut, alors
le statut est devenu "Rejeté"
Corrigé : lorsque le développeur effectue des modifications dans le code pour rectifier le bug...
Fermé/Rouvert : quand le testeur le teste à nouveau. Si le résultat attendu apparaît, il est transformé en
Fermé et si le problème persiste, c'est 'Rouvrir'.

50
W Qu'est-ce que le statut différé dans le cycle de vie des défauts ?

Le statut différé signifie que le développeur a accepté le bus, mais qu'il est prévu de le rectifier dans le
nextbuild

Test de validation ? Utilisez-vous un outil d'automatisation pour le test de validation ?

Tester l'application pour vérifier si elle fonctionne correctement dans ses fonctionnalités de base.
l'équipe de test peut procéder avec l'application. Peut certainement l'utiliser.

Vérification et validation ?

La vérification est statique. Aucun code n'est exécuté. Parlez de l'analyse des exigences, etc.
La validation est dynamique. Le code est exécuté avec des scénarios présentant des cas de test.

Lorsqu'un bug est trouvé, quelle est la première action ?

Outil de suivi des bugs Reportitin.

Qu'est-ce qu'un plan de test et expliquez son contenu ?

Testplan is a documentwhich containsthe scope fortestngthe applicaton and what to be

testé, quand être testé et qui tester.

Advantages of automaton over manual testng?

Gain de temps, ressources et argent

Que signifie les notes de version ?

C'est un document publié avec le produit qui explique le produit. Il également

contient des informations sur les bugs qui sont en statut différé.

W Quel est l'environnement TestNG dans votre entreprise, c'est-à-dire comment le processus TestNG commence-t-il?

Le processus de test se déroule comme suit :

Unité d'assurance qualité
Responsable assurance qualité
Testlead
Ingénieur de test

51
Give an example of high priority and low severity, low priority and high severity?

Severity level:

Le degré d'impact que le problème ou l'enjeu a sur le projet. La sévérité 1 signifie généralement que le
niveau le plus élevé nécessitant une attention immédiate. La gravité 5 représente généralement une documentation.
défaut d'impact minimal.

La gravité est des niveaux :

Critique : le logiciel ne fonctionnera pas

Élevé : erreurs fatales inattendues (inclut les pannes et la corruption des données)

Moyen : une fonctionnalité ne fonctionne pas correctement

Faible : un problème cosmétique

Niveaux de gravité

1. Un bug provoque un plantage du système ou une perte de données.

2. Un bogue cause des problèmes de fonctionnalité majeurs ou d'autres problèmes graves ; le produit plante dans des circonstances obscures

cas.
3. Un bogue cause de légers problèmes de fonctionnalité, peut affecter la " finition et l'ajustement".

4. Bugs contenant des fautes de frappe, un langage peu clair ou des messages d'erreur dans des champs à faible visibilité.

Severity levels

Élevé : Un problème majeur où une grande partie de la fonctionnalité ou un composant système majeur
est complètement cassé. Il n'y a aucune solution de contournement et testng ne peut pas continuer.
Moyen : Un problème majeur où une grande partie de la fonctionnalité ou d'un système majeur
le composant ne fonctionne pas correctement. Il existe cependant une solution de contournement, et testng
peut continuer.

Faible : Un petit problème qui impose une certaine perte de fonctionnalité, mais pour lequel il y a un
solution de contournement acceptable et facilement reproductible. Testng peut continuer sans
interruption.

52
Sévérité et Priorité

La priorité est relative : la priorité peut changer au fil du temps. Peut-être qu'un bogue initialement jugé P1
devient classé comme P2 ou même P3 à mesure que le calendrier se rapproche de la sortie et que le test
l'équipe trouve encore plus d'erreurs odieuses. La priorité est une évaluation subjective de l'importance.
Le problème est, compte tenu des autres tâches dans la file d'attente et du calendrier actuel. C'est relatif. C'est fini.
Et c'est une décision commerciale.

La gravité est un absolu : c'est une évaluation de l'impact du bogue sans tenir compte des autres.
travailler dans la file d'attente ou l'emploi du temps actuel. La seule raison pour laquelle la gravité devrait changer est si nous

have new informatonthatcauses usto re-evaluate our assessment. If itwas a high severity
problème lorsque je l'ai saisi, c'est toujours un problème de haute gravité lorsqu'il est reporté à la prochaine version.
La gravité n'a pas changé simplement parce que nous manquons de temps. La priorité a changé.

Les niveaux de gravité peuvent être définis comme suit :

S1 - Urgent/Blocage. Comme un plantage du système ou un message d'erreur forçant à fermer la fenêtre.

Capacité du testeur à faire fonctionner le système soit totalement (Système hors service), soit presque totalement,
affecté. Un domaine majeur du système des utilisateurs est affecté par l'incident et il est significatif de
processus commerciaux.

S2 - Medium/Workaround. Existlike when a problem is required inthe specs but tester can
continue avec testng. L'incident affecte une zone de fonctionnalité mais il existe une solution de contournement qui
n'influe pas sur le processus commercial. C'est un problème qui :
a) Affecte un aspect de fonctionnalité plus isolé.
b) Se produit uniquement à certaines conditions aux limites.
c) A une solution de contournement (où "ne le fais pas" pourrait être une réponse acceptable pour l'utilisateur).
d) Se produit uniquement chez un ou deux clients. ou est intermittent

S3 - Faible. Ceci concerne les problèmes mineurs, tels que les défaillances à des conditions limites extrêmes qui
sont peu susceptibles de se produire en utilisation normale, ou des erreurs mineures dans

Mise en page/formatage. Les problèmes n'impactent pas l'utilisation du produit de manière substantielle.
sont des incidents qui sont cosmétiques par nature et ont un impact nul ou très faible sur les processus métier.

Qu'est-ce qu'un cas d'utilisation ?

Un flux simple entre l'utilisateur final et le système. Il contient des préconditions, des postconditions.
Conditions, flux normaux et exceptions. Cela est fait par le Responsable d'équipe / Responsable de test / Testeur.

Différence entre STLC et SDLC ?

STLC est le cycle de vie des tests logiciels, il commence par

53
 Préparation de la stratégie de test.
Préparation du plan de test.

Création de l'environnement de test.

Rédaction des cas de test.

Création de scripts de test.

Exécution des scripts de test.

Analyser les résultats et signaler les bogues.

Effectuer des tests de régression.

Testexitng.

Le SDLC est le cycle de vie du développement logiciel ou système, les phases sont...

Initiation de projet.
Collecte des exigences et documentation.

Conception.

Codage et tests unitaires.

Test d'intégration.

Systemtestng.

Installation et test d'acceptation. « Support ou maintenance. »

Comment répartissez-vous le projet entre les membres de l'équipe ?

Cela peut dépendre des cas suivants ----

1) Nombre de modules
2) Nombre de membres de l'équipe
3) Complexité du projet
4) Durée du projet
L'expérience des membres de l'équipe etc......

Qu'est-ce que la collecte de données de test ?

Les données de test sont la collection de données d'entrée prises pour tester l'application. Différents types et
La taille des données d'entrée sera prise pour tester les applications. Parfois dans des applications critiques
la collection des données de test sera également fournie par le client.

Qu'est-ce que le serveur de test ?

L'endroit où les développeurs placent leurs modules de développement, auxquels on accède par
testeurs pour tester la fonctionnalité

54
 Quelles sont les exigences non fonctionnelles ?

Les exigences non fonctionnelles d'un produit logiciel sont : fiabilité, utilisabilité, efficacité,
délai de livraison, environnement de développement logiciel, exigences de sécurité, normes à respecter
suivi etc.

Quelles sont les différences entre ces trois mots : Erreur, Défaut et Bug ?

Erreur : L'écart par rapport à la logique, à la syntaxe ou aux normes/éthiques requises est appelé erreur.

Il existe trois types d'erreurs. Ce sont :

Erreur de syntaxe (Ceci est dû à une déviation de la syntaxe de la langue qui est supposée)
suivre).
Erreur logique (C'est dû à une déviation de la logique du programme ce qui est supposé)
suivre
Erreur d'exécution (Cela se produit généralement lorsque vous exécutez le même programme, que
tme you getit.)
Défaut : Lorsqu'une erreur est trouvée par l'ingénieur de test (département testng), alors on l'appelle
défaut

Erreur : si le défaut est accepté par le développeur, alors il se transforme en bug, qui doit être corrigé par
le développeur ou reporter à la prochaine version.

Pourquoi effectuons-nous des tests de stress, des tests de résolution et des tests multi-navigateurs ?

Test de Stress : - Nous devons vérifier la performance de l'application.

Def: Testng conductedto evaluate a system or componentator beyondthe limits of its
exigences spécifiées
Resoluton Testng: - Sometmes developer created only for 1024 resoluton,the same page
affiché une barre de défilement horizontale en résolution 800 x 600. Personne n'aime la barre horizontale.
un défilement apparaît à l'écran. C'est la raison de tester le test de résolution.

Testng multi-navigateur : - Ce testng est parfois appelé testng de compatibilité. Quand nous
développez les pages compatibles IE, la même page ne fonctionne pas dans Firefox ou Netscape
correctement, parce que
la plupart des scripts ne prennent pas en charge deux autres que IE. Donc, nous devons tester la compatibilité croisée
navigateur Testng

Il y a deux sabliers, l'un complet en 7 minutes et l'autre en

Nous avons 9 minutes à calculer avec les minuteurs et sonner la cloche après l'achèvement de 11-
minutes !s'il vous plaît donnez-moi la solution.

1. Démarrez les deux horloges

2. Lorsque l'horloge de 7 minutes se termine, tournez-la pour qu'elle redémarre.

55
3. Quand l'horloge de 9 minutes finit, démarrez les horloges de 7 minutes (il ne reste que 2 minutes).
4. Lorsque l'horloge de 7 minutes se termine, 11 minutes sont complètes.

Quels sont les critères minimums pour la boîte blanche ?

Nous devrions connaître la logique, le code et la structure du programme ou de la fonction. Interne

connaissance de l'application comment le système fonctionne quelle est la logique derrière cela et la structure
comment cela devrait réagir à une action particulière

Quelles sont les critiques techniques ?

For each document, itshould be reviewed. Technical Review inthe sense, for each screen,
developer will write a Technical Specificaton. Itshould be reviewed by developer and
tester. Il y a une révision de la spécification fonctionnelle, une révision des cas de test unitaires et une révision du code, etc.

Sur quelle base allez-vous rédiger des cas de test?

J'écrirais les cas de test basés sur les spécifications fonctionnelles et les BRD et quelques autres.
cas de test utilisant les connaissances du domaine.

Expliquez le concept ETVX ?

E- Entry Criteria
Tâche
V- Validation
X- ExitCriteria

CRITÈRES D'ADMISSION : Entrée avec 'condition' attachée.

Par exemple, le document SRS approuvé est le critère d'entrée pour la phase de conception.

TASK: Procedures.
Préparation de HLD, LLD, etc.

VALIDATION : Activités de qualité de construction et de vérification

par exemple, examens techniques

EXIT CRITERIA: Outputwith 'conditon' atached.

Document de conception approuvé
Il est important de suivre le concept ETVX pour toutes les phases du SDLC.

Quels sont les principaux composants clés dans les applications Web et le client et le serveur
applications? (Différences)

Pour les applications Web : Une application Web peut être mise en œuvre en utilisant n'importe quel type de technologie.
comme Java, .NET, VB, ASP, CGI et PERL. En fonction de la technologie, nous pouvons dériver le
composants.

56
Let'stake Java Web Applicaton. Itcan be implemented in 3 ter architecture. Presentaton
Tier de présentation (jsp, html, dthml, servlets, struts). Tier métier (Java Beans, EJB, JMS) Données
Tier (Bases de données comme Oracle, SQL Server, etc.)

Si vous prenez .NET Application, Présentation (ASP, HTML, DHTML), Couche Métier (DLL) et Données
Niveau (Base de données comme Oracle, SQL Server, etc.)

Applications Client-Serveur : Elle n'aura que 2 niveaux. L'un est la Présentation (Java, Swing) et
Niveau de données (Oracle, SQL Server). S'il s'agit d'une architecture client-serveur, l'ensemble de l'application doit
être installé sur la machine cliente. Chaque fois que vous apportez des modifications à votre code, encore une fois, cela a
to be installed on allthe clientmachines. Where as in Web Applicatons, Core Applicaton
sera hébergé sur le serveur et le client peut être léger Client (navigateur). Quels que soient les changements que vous
do, you haveto installthe applicaton inthe server. NO needto worry about the clients.
Parce que vous n'installerez rien sur la machine cliente.

Si le client a identifié des bogues, à qui les a-t-il signalés ?

Il fera rapport au Chef de Projet. Le Chef de Projet organisera une réunion avec tous les
dirige (Responsable Développement, Responsable Test et Responsable des Exigences) puis soumet une Demande de Changement

Ensuite, identifiez tous les écrans qui vont être impactés par le bug. Ils prendront
le code et corrigez-le et envoyez-le à l'équipe Testng.

Qu'est-ce que la révision technique formelle ?

La révision technique devrait être effectuée par l'équipe de membres. Le document, qui va
être examiné, ceux qui ont préparé et les examinateurs devraient se réunir et faire l'examen de cela
document. Il est appelé Révision par les pairs. S'il s'agit d'un document technique, il peut être appelé formel.
Examen technique, je suppose. Cela varie selon la politique de l'entreprise.

À quelle phase le rôle de testeur commence-t-il ?

Dans le SDLC, après la complétion du document FRS, le responsable des tests prépare le document des cas d'utilisation et

document de plan de test, puis le rôle du testeur commence.

Métriques logicielles

La mesure est fondamentale à toute discipline d'ingénierie

Pourquoi les métriques ?
Nous ne pouvons pas contrôler ce que nous ne pouvons pas mesurer !
- Les métriques aident à mesurer la qualité
- Sert de tableau de bord

les principales métriques sont : taille, calendrier, défauts. Dans cela, il y a des sous-métriques principales.

TestCoverage = Number of units (KLOC/FP)tested /total size ofthe system

Coût du test (en %) = Coût des tests / coût total * 100
Coût pour localiser un défaut = Coût des tests / le nombre de défauts localisés

57
Defects detected intestng (in %) = Defects detected intestng /total system defects*100
Critères d'acceptation testés = Critères d'acceptation testés / total des critères d'acceptation

En fait, combien de cas de test positifs et négatifs écrirez-vous pour un module ?

Cela dépend du module et de la complexité de la logique. Pour chaque cas de test, nous pouvons identifier
+points et -points. En fonction des critères, nous rédigerons les cas de test. Si c'est un processus crucial.
ou écran. Nous devrions vérifier l'écran, dans toutes les conditions aux limites.

Qu'est-ce que la fiabilité des logiciels ?

C'est la probabilité que le logiciel fonctionne sans échec pendant une période spécifiée de temps dans un
environnement spécifié. La fiabilité des logiciels est mesurée en termes de temps moyen entre les pannes.
Échec (MTBF). Par exemple, si le MTBF = 10000 heures pour un logiciel moyen, alors il ne devrait pas
échec après 10000 heures de fonctionnement continu.

Quels sont les principaux bugs que vous avez identifiés et combien y en a-t-il ?
considérés comme de vrais insectes ?

Si vous prenez un écran, disons, il a 50 conditions de test, dont j'ai identifié

5 defects which are failed. I should givethe descripton defect, severity and defect
classification. Tous les défauts seront pris en compte.

La classification des défauts est :

GRP : Graphical Representaton
LOG : Erreur Logique
DSN : Erreur de conception
STD : Standard Error
TST : Cas de test incorrect
TYP : Erreur typographique (Erreur Cosmo tc)

Quelle est l'utilisation principale de la préparation d'une matrice de traçabilité ?

La matrice de traçabilité est préparée afin de vérifier les cas de test conçus contre chacun.
exigence, offrant ainsi une opportunité de vérifier que toutes les exigences sont couvertes dans
tester l'application.
(Ou)
Pour vérifier les cas de test et les scripts de test préparés avec les exigences des utilisateurs. Pour surveiller
les changements, les améliorations survenues pendant le développement du projet.

Qu'est-ce que le six sigma ? Expliquez.

Six Sigma
A quality disciplinethatfocuses on productand service excellenceto create a culturethat
exige la perfection dans la cible, à chaque fois.

Niveaux de qualité Six Sigma

58
Produits avec une précision de 99,9997 %, avec seulement 3,4 défauts par million d'opportunités.

Le Six Sigma est conçu pour améliorer considérablement la performance d'une entreprise, améliorant la qualité.
et productivité. En utilisant des produits, processus et normes de service existants,
Ils optent pour la méthodologie Six Sigma MAIC pour améliorer la performance.

MAIC est défini comme suit :

Mesurer : Rassemblez les bonnes données pour évaluer avec précision un problème.
Analysez : Utilisez des outils statistiques pour identifier correctement les causes profondes d'un problème.

Améliorez : Corrigez le problème (pas le symptôme).

Contrôle : Mettre en place un plan pour s'assurer que les problèmes restent résolus et que les gains soient soutenus.

Rôles et Responsabilités Clés :

Les rôles clés dans tous les efforts Six Sigma sont les suivants :
Sponsor : Cadre d'entreprise dirigeant l'organisation.
Champion : Responsable de la stratégie, du déploiement et de la vision Six Sigma.
Propriétaire du processus : Propriétaire du processus, produit ou service en cours d'amélioration responsable de
des gains durables à long terme.
Les Maîtres Ceintures Noires : Coachs Ceintures Noires experts dans tous les outils statistiques.
Ceintures noires : Travailler sur 3 à 5 projets de 250 000 $ par an ; créer 1 million $ de valeur par an.
Ceinture Verte : Travailler avec des projets ceinture noire.

Qu'est-ce que le TRM ?

TRM signifie Matrice des responsabilités des tests.

TRM : --- Il indique la cartographie entre les facteurs de test et les étapes de développement...

Facteurs de test comme :

Facilité d'utilisation, fiabilité, portabilité, autorisation, contrôle d'accès, piste de vérification, facilité de fonctionnement
maintenable... Comme ça...
Étapes de développement...
Collecte des exigences, analyse, conception, codage, test et maintenance

59
 {"what_are_cookies":"Qu'est-ce que les cookies ?","advantages_and_disadvantages":{"advantages":"Quels sont les avantages des cookies ?","disadvantages":"Quels sont les inconvénients des cookies ?"}}

Les cookies sont des messages que les serveurs web transmettent à votre navigateur lorsque vous visitez Internet.
sites. Votre navigateur stocke chaque message dans un petit fichier. Lorsque vous demandez une autre page
Du serveur, votre navigateur renvoie le cookie au serveur. Ces fichiers sont généralement
contient des informations sur votre visite de la page web, ainsi que toute information que vous avez
volontaire, comme votre nom et vos intérêts. Les cookies sont le plus souvent utilisés pour suivre
activité du site web. Lorsque vous visitez certains sites, le serveur vous donne un cookie qui agit comme votre
carte d'identité. Lors de chaque retour sur ce site, votre navigateur renvoie ce cookie
au serveur. De cette manière, un serveur web peut rassembler des informations sur les pages web qui sont
utilisé le plus, et quelles pages recueillent le plus de visites répétées. Seulement le site web qui
le cookie peut le lire. De plus, les serveurs web ne peuvent utiliser que les informations que vous
fournir ou choisir ce que vous faites lors de la visite du site web comme contenu dans les cookies. Acceptation
un cookie ne donne pas accès à un serveur à votre ordinateur ou à vos informations personnelles
Les serveurs ne peuvent lire que les cookies qu'ils ont définis, donc les autres serveurs n'ont pas
accès à vos informations. De plus, il n'est pas possible d'exécuter du code à partir d'un cookie, et non
Il est possible d'utiliser un cookie pour livrer un virus.

Quelle est la différence entre une entreprise basée sur des produits et une entreprise basée sur des projets

Entreprise ?

Une entreprise basée sur des produits développe des applications pour des clients mondiaux, c'est-à-dire qu'il n'y a pas de spécificité.
clients. Ici, les exigences sont rassemblées à partir du marché et analysées avec des experts.
Une entreprise basée sur des projets développe des applications pour des clients spécifiques. Les exigences.
sont recueillis auprès du client et analysés avec le client.

60