Tests manuels

Les tests effectués par des humains sans outil tiers ne sont rien d'autre que des tests manuels.
Ou
Test effectué directement par le testeur via des entrées au clavier et à la souris dans l'application sous test.
rien d'autre que des tests manuels.
Qu'est-ce que le test ?

Le test est un processus de vérification du logiciel pour vérifier s'il répond aux exigences ou non avec le
intention de trouver des erreurs.

Ou
Le test n'est rien d'autre qu'une détection, c'est un processus d'exécution de l'application de manière contrôlée avec
l'intention de trouver des erreurs.
Ou
Pour s'assurer que notre application fonctionne conformément aux exigences du client ou non.
Exigences
Ms - Word, feuille Excel pour rédiger des cas de test, des rapports de bogues et des versions pour les tests, c'est tout.

Quel est le but des tests ?

Pour obtenir un produit de qualité.

Pour détecter les bugs.
Pour gagner en confiance dans le logiciel.
Pour réduire le retravail.
Le client pourra faire son travail.
Pour garantir que la fonctionnalité complète est mise en œuvre.

Qu'est-ce que la qualité ?

Un produit de qualité est exempt de bogues, est livré à temps, dans le budget, et répond aux exigences du client.
et maintenable.
Pourquoi la qualité ?

1) Réduire le retravail.

2) Pour satisfaire les exigences des clients

Qu'est-ce qui est maintenable ?

Que le logiciel soit facile à maintenir en production et que tout problème survenant puisse être résolu.
facilement avec moins d'efforts et moins de coûts.

Qualités des testeurs

[Link] de rupture de test
2. Adopter le point de vue du client
3. Maintenir une bonne communication avec les développeurs
4. Doit avoir une bonne connaissance du SDLC
5. Doit être capable de faire des rapports techniques

Quand commencez-vous les tests ?

Après avoir obtenu le document SRS, nous préparerons des cas de test pendant que les développeurs se préparent.
Nous préparons les cas de test et après avoir publié la version à partir d'eux, nous passerons à
exécution.

Quand arrêter de tester ?

C'est très difficile à déterminer. Beaucoup de modernesapplications logiciellessont si complexes, et fonctionnent dans
tel qu'un environnement interdépendant

Ainsi, des facteurs communs sont en jeu pour décider quand arrêter les tests.

•Délais (délais de sortie, délais de test.)

•Cas de test complétés avec un certain pourcentage réussi.
Le budget de test est épuisé
La couverture du code / des fonctionnalités / des exigences atteint un point spécifié
Le taux auquel les Bugs peuvent être trouvés est trop faible
La période de test Beta ou Alpha se termine
Le risque dans le projet est en dessous de la limite acceptable.

Contrôle de la qualité :

Un ensemble d'activités conçu pour évaluer un produit de travail développé.

Ou
Toutes les étapes nécessaires ont été prises pour répondre aux exigences de qualité.

LE CONTRÔLE DE QUALITÉ mesure la qualité d'un produit

Assurance qualité
Toutes ces idées planifiées et nécessaires pour fournir une confiance adéquate que le produit/service sera
satisfaire les exigences de qualité données.

L'ASSURANCE QUALITÉ mesure la qualité des processus utilisés pour créer un produit de qualité

Quelle est la différence entre l'AQ et le QC ?

Q. A Q.C
C'est un processus de vérification c'est un processus de validation
Cela prévient les problèmes il identifie les problèmes
Préparer le plan de test mettre en œuvre le plan de test
Vérifie les rapports génère les rapports

Document de spécification des exigences logicielles (SRS), contenant :

• Introduction
ƒ But
ƒ Portée
Contraintes majeures et références
• Exigences fonctionnelles
Diagramme contextuel
Diagramme de décomposition fonctionnelle
ƒ Fonctions Systèmes
Exigences de la base de données
Exigences de l'interface utilisateur
Exigences d'interface logicielle externe / compatibilité
Exigences des rapports
Exigences de sécurité
• Spécifications des cas d'utilisation
Critères d'acceptation

Chef de projet : (rôles, responsabilités)

Préparation du Document des exigences logicielle (SRS)

Équipe de Développement de Formation, Équipe de Test
Gestion des exigences tout au long des activités du cycle de vie du projet.
Préparation du document de conception détaillée
•Cas de test unitaire et cas de test d'intégration
•Conseils sur la programmation et les normes / conventions de codage associées

Responsable QA :

Préparation du plan de test système

Formation de l'équipe de test
Préparation du calendrier
Allocation de module
Avis sur le processus de test
Interaction avec le client
•Vérifier les rapports de statut

Équipe de test (testeurs et responsable de test) :

Le test est la compétence de base de toute organisation de test.

•Comprendre l'application sous test

•Préparer la stratégie de test
•Aider à la préparation du plan de tests.
• Concevoir des conditions de haut niveau
•Développer des scripts de test
 Comprendre les données impliquées
•Exécuter tous les cas de test assignés
Enregistrer les défauts dans le système de suivi des défauts
•Retester les défauts corrigés
•Assister le responsable des tests dans ses fonctions
•Fournir des retours lors des triages de défauts
•Automatiser les scripts de test

Compréhension de SQL

Qu'est-ce que la vérification et la validation ?

V&V est un processus qui aide à déterminer si les exigences logicielles sont complètes, correctes et si le logiciel est
Chaque phase de développement remplit les exigences et les conditions imposées par la phase précédente, etc.

La vérification implique généralement des examens, des plans, des réunions et l'évaluation de documents, de plans.
exigences et spécifications de code cela peut être fait avec l'aide de listes de contrôle, listes de problèmes, marche
à travers des réunions d'inspection

La validation implique généralement des tests réels et commencera après l'achèvement de la vérification.

Qu'est-ce que la vérification ?

La vérification et la validation (v&v) est un processus qui aide à déterminer si les exigences du logiciel sont
complet, correct et si le s/w de chaque phase de développement respecte les exigences et conditions,
imposé par la phase précédente, etc.
La vérification implique généralement des examens et des réunions pour évaluer des documents, des plans, du code,
exigences et spécifications. Cela peut être fait avec des listes de vérification, des listes de problèmes, des visites guidées, et
réunions d'inspection.
La validation implique généralement des tests réels et se déroule après que les vérifications sont terminées.
La vérification nécessite plusieurs types de revues, y compris la revue des exigences, les balades de code,
Inspections de code, revues de conception, revues de revues.... Les utilisateurs du système (développeurs) seront impliqués
dans ces critiques pour trouver les défauts avant qu'ils ne construisent un système. Certains des exemples que nous avons discutés
Veuillez vérifier celui-ci. Pour un processus de développement efficace, chaque exemple de vérification est lié.
avec un autre (Cela dépend également du type de projet...)

La validation est réalisée simplement en exécutant des fonctions de la vie réelle (par exemple, si vous vérifiez le
l'ampoule fonctionne ou non, alors vous devriez l'allumer ...) .Ici aussi, des exemples de validations sont liés avec
l'un l'autre, la production efficace de l'entrée d'une autre validation (dépend du type de projet)

La vérification répond à la question : « Construisons-nous le bon produit ? »

Validation des adresses, "Construit-on le produit correctement ?"

En fonction du type de projet, les exemples de vérification varieront... Voici quelques normes.
exemples
Exemples de vérification :-

Vérification
Réalisé par Livrable
Exemple
Exigence Développeurs, Réviser l'énoncé des exigences prêt à être
Critique Client traduire dans le système
Le document de conception et de configuration du système est prêt
Revues de conception Développeur pour programme informatique
Code Logiciel informatique prêt pour les tests ou prêt pour plus
Développeurs
Guides pas à pas inspection détaillée
Le logiciel est prêt pour les tests par les développeurs
Inspections de code Développeurs
et Testeurs

Validation Exécuté
Livrable
Exemples Par
l'unité logicielle est prête pour les tests avec une autre unité ou
Tests unitaires Développeurs
composants.
Des portions du système prêtes pour les tests avec d'autres
Développeurs de tests intégrés
parties du système.
Test de système Testeurs Un système informatique testé, basé sur ce qui a été spécifié
Acceptation par l'utilisateur
Utilisateurs Système informatique testé basé sur les besoins de l'utilisateur ...
Test

Résumé :
1. La vérification et la validation sont essentielles dans les tests de logiciels.
Cela commence lorsque le projet commence.
3. Cela minimise le coût des tests.
4. La vérification est une méthode non exécutable.
5. La validation est une méthode exécutée physiquement.

Qu'est-ce qu'un 'walkthrough' ?

Un 'walkthrough' est une réunion informelle à des fins d'évaluation ou d'information. Peu ou pas
Une préparation est généralement requise.

Ou

C'est unune réunion informelle à des fins d'information. Aucune préparation n'est requise. juste partager les idées.

Personnes impliquées
Les personnes suivantes ont assisté à la réunion :
 Architecte. L'architecte a organisé et présidé la réunion. Il voulait créer une menace.
modèle tôt dans la phase de conception, pour influencer les décisions de conception subséquentes.
Analyste d'affaires. L'analyste d'affaires a été invité à la réunion pour répondre et clarifier.
questions concernant les objectifs de sécurité et les principaux cas d'utilisation. Notez que l'entreprise
l'analyste est un participant facultatif et pourrait ne pas être nécessaire si l'architecte peut répondre au
questions.
Développeur. Le développeur voulait comprendre les implications sécuritaires de divers conceptions.
et choix de mise en œuvre.
Responsable des tests. Le responsable des tests a été invité à la réunion car l'architecte voulait la menace
modèle pour aider à définir la stratégie de test. Le responsable des tests voulait savoir où se concentrer.
tests de sécurité.
Remarque : Cette réunion n'impliquait aucun personnel opérationnel ou de réseau. Assurez-vous de le savoir.
vos contraintes opérationnelles. Si nécessaire, consultez votre personnel informatique concernant la politique corporative pertinente.
politiques ou autres contraintes d'infrastructure.

Directives de réunion
L'architecte a défini les lignes directrices de la réunion suivantes :

La réunion devait être limitée à une heure.

Une seule personne nommée prendrait des notes. Dans ce cas, le développeur a été invité à prendre des notes.
notes.
L'équipe enregistrerait les problèmes qui devaient être mis hors ligne pour une discussion plus approfondie.

L'architecte a spécifié le temps qu'il souhaitait consacrer à chaque étape afin que la réunion
devrait être terminé en une heure. Il voulait que les étapes 1, 2 et 3 soient complétées en environ 20
minutes et le reste du temps de réunion à consacrer à l'identification des menaces et des vulnérabilités. Il
a également permis de consacrer du temps à une conclusion de réunion de cinq minutes.

Qu'est-ce qu'une 'inspection' ?

Une inspection est plus formalisée qu'une 'visite guidée', généralement avec 3 à 8 personnes, y compris un
modérateur, lecteur et un enregistreur pour prendre des notes. Le sujet de l'inspection est généralement un document
tel qu'un cahier des charges ou un plan de test, et le but est de trouver des problèmes et de voir ce qui est.
manquant, il ne faut rien réparer. Les participants devraient se préparer à ce type de réunion en lisant à travers le
document ; la plupart des problèmes seront trouvés durant cette préparation. Le résultat de la réunion d'inspection
doit être un rapport écrit. Une préparation minutieuse pour les inspections est un travail difficile et laborieux, mais est
l'un des moyens les plus rentables pour garantir la qualité. Les employés qui ont le plus de compétences en
Les inspections sont comme le 'frère aîné' dans la parabole de 'Pourquoi est-il souvent difficile pour la direction d'obtenir
sérieux au sujet de l'assurance qualité ? Leur compétence peut avoir une faible visibilité mais elle est extrêmement précieuse
pour toute organisation de développement logiciel, car la prévention des bogues est de loin plus rentable que la correction des bogues
détection.

Types de tests
Qu'est-ce que le test en boîte blanche ?

Ce n'est rien d'autre que de tester la partie structurelle de l'application.

Ou

C'est une approche de test qui examine la structure du programme d'application et dérive des cas de test de
la logique du programme d'application.

Ceci est aussi appelé

test de boîte ouverte

ou test structurel

ou test de boîte claire

ou test de boîte en verre

Cela est entièrement pris en charge par les développeurs ou le département de développement.

Pour effectuer ce test, une sensibilisation au logiciel est requise.

Pour effectuer ce test, un manuel de code intermédiaire est requis.

Lors de ce test, les ingénieurs de test doivent suivre les techniques WBT.

Techniques WBT :

ceci sont 3

test d'exécution

Qu'est-ce que le test boîte noire ?

Ce n'est rien d'autre que de tester la partie fonctionnelle de l'application. Pas besoin de connaître la logique interne de
code.

Tests unitaires

Les tests des composants logiciels individuels

Ou

Tester la fonctionnalité individuelle de l'application n'est rien d'autre que des tests unitaires.

Test de module

Tester les fonctionnalités combinées d'une application n'est rien d'autre que le test de module.
Tests d'intégration

Tester les modules combinés de l'application n'est rien d'autre que des tests d'intégration.

Tests exhaustifs

La dernière instruction exécutable dans un composant.

Qu'est-ce qu'un document de référence ? Peux-tu en citer deux ?

Le document dont le résultat certifié d'une étape est transmis à une autre étape n'est rien d'autre que la ligne de base.
document.

Exemple : le 1stLa version de SRS est considérée comme un document de référence.

Qu'est-ce que le SDLC ?

SDLC signifie cycle de vie du développement logiciel. Il précise comment exactement vous développez un logiciel à travers
Les diverses étapes et procédures suivies pour développer un logiciel ne sont rien d'autre que le SDLC.

(Ou)

Cela commence quand s/w 1stle temps introduit et se termine lorsque le logiciel n'est plus utilisé.

STLC signifie cycle de vie des tests logiciels. Il spécifie comment effectuer des tests pour atteindre la qualité et détecter les bogues.
avec une procédure systématique n'est rien d'autre que le STLC.

(Ou)

Cela commence à la fin de la phase de demande, c'est-à-dire au niveau de la conception, et se termine lorsque le logiciel n'est plus.
en cours d'utilisation.

Quels types de tests avez-vous effectués ?

Utilisabilité, fonctionnalité, tests de régression, un peu impliqué dans les tests de base de données.

Quel est le résultat des tests ?

Un produit de qualité.

Quel type de test un testeur effectue-t-il ?

Les tests en boîte noire, tels que l'utilisabilité, la fonctionnalité, les tests de base de données, la régression, etc.

Après la fin des tests, que livreriez-vous au client ?

 Document de plan de test

Documents de scénarios de test

Document de cas de test

Rapports de défaut

Rapports d'état (mensuels, hebdomadaires, quotidiens)

Scripts de test

Document de validation de projet/produit.

Qu'est-ce qu'un cas de test ?

Un cas de test est un document qui décrit l'ENTRÉE, l'ACTION, l'ÉVÉNEMENT et la RÉPONSE ATTENDUE
déterminer si la fonctionnalité d'une application fonctionne correctement ou non.
Un cas de test est une séquence d'étapes pour tester le comportement correct d'une fonctionnalité/d'une caractéristique d'un
application.
Ce n'est rien d'autre qu'un document qui contient un ensemble d'entrées et de résultats d'exécution basés sur
conditions pour déterminer une fonctionnalité d'une application.
C'est purement pris en charge par les testeurs
En utilisant des cas de test, nous pouvons vérifier si l'application fonctionne correctement ou non.

Statut
Passer
Échouer

Qu'est-ce qu'un bon cas de test ?

À mon avis, quel cas de test couvre le maximum de fonctionnalités, trouve efficacement les défauts, facile à
Utilisé, facile à comprendre, ne fait pas de choses inutiles est appelé un bon cas de test.

Critères d'entrée
Plan de test approuvé
Spécification des exigences
ECP et BVA préparé
Modèle de cas de test
Tout document de conception
Critères de sortie

Le cas de test doit être examiné et approuvé.

C'est un document qui contient un ensemble d'entrées possibles et d'exécutions pour des résultats attendus basés sur
conditions pour déterminer une caractéristique de l'application.
Utilisations

En utilisant des cas de test, nous pouvons vérifier si l'application fonctionne correctement ou non.

Qu'est-ce qu'un bon cas de test ?

Un bon cas de test est celui qui a une forte probabilité de trouver une zone encore non découverte.

Celui qui (le nombre minimum de cas de test) couvre le maximum de fonctionnalités est appelé un bon cas de test.

Ou

Un bon cas de test n'a pas plus d'étapes et couvre plus de fonctionnalités en un seul coup.

Un bon cas de test satisfait les critères signifie :

Trouver des défauts efficacement

Facile à entretenir

Économique à utiliser

Facile à comprendre et ne fait pas de choses inutiles.

Comment allez-vous préparer des cas de test ?

En utilisant des documents comme le BRS, le CRS, le SRS (à travers les exigences), nous préparons des cas d'utilisation en utilisant l'utilisation.
dans les cas où nous préparons des cas de test.

Comment préparez-vous un bon cas de test ?

Chaque entreprise suit son propre format pour les cas de test. Mais l'objectif final est de couvrir tout le
fonctionnalité pour tester le projet.

Comment allez-vous vérifier que vos cas de test couvrent toutes les exigences ?

En utilisant une matrice de traçabilité (TRM)

Qu'est-ce que le TRM ?

Il montre la relation entre les exigences et les cas de test correspondants.

Ou

C'est la correspondance entre les exigences et les cas de test.

CRM signifie Matrice de Référence Croisée

C'est la cartographie entre les exigences et les cartes (cartes de conception).

Comme je veux dire

Nombre minimum de cas de test = nombre d'entrées * 1,6

Par exemple : supposez que vous ayez une page web pour l'addition de deux nombres

Alors tu as entré 1 :

Entrée 2 :

Somme :

Dans ce formulaire, nous avons deux objets d'entrée (entrée 1, entrée 2)

Donc, le nombre minimum de cas de test pour ce formulaire sera

Cas de test = objet d'entrée 1*1,6= (c'est-à-dire) 2*1,6=3,2 (le minimum de cas de test doit être de 3) mais maximum
peut varier.

Qu'est-ce qu'un scénario de test ?

Le scénario de test représente une série d'actions qui sont associées ensemble depuis la phase d'initiation jusqu'à
achèvement

Cela spécifie la vue d'ensemble de la fonctionnalité totale d'un objet.

Critères d'entrée :

plan de test approuvé

spécification des exigences (ou) SRS

tout document de conception

modèle de scénario de test

Critères de sortie

le scénario de test doit être examiné et approuvé.

Qu'est-ce qu'un critère d'entrée ?

C'est une condition que l'entrée de la phase doit satisfaire pour entrer dans la phase n'est rien d'autre que l'entrée.
critères.

Qu'est-ce qu'un critère de sortie ?

C'est une condition dont la sortie de la phase doit satisfaire pour sortir de la phase n'est rien d'autre qu'une sortie.
critères.

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

Un ensemble de valeurs est utilisé dans le test ou qui est nécessaire pour exécuter le test basé sur le cas de test.
Nous allons préparer les données de test.

Qu'est-ce qu'une erreur ?

Une erreur dans le code est appelée une erreur.

Qu'est-ce qu'un défaut ou un problème ?

Cette erreur est trouvée par l'ingénieur de test pendant la période de test, cela s'appelle un défaut ou un problème.

Qu'est-ce qu'un bug ?

Ce défaut ou problème est accepté par le département de développement ou le développeur est appelé un bug.

Qu'est-ce qu'une faute ?

Une manifestation d'une erreur dans le logiciel. Un défaut. Une étape, un processus ou une définition de données incorrecte dans un
programme informatique

Qu'est-ce que l'échec ?

L'incapacité d'un système ou d'un composant du système à effectuer une fonction requise dans les spécifications
Des limites. Un échec peut se produire lorsqu'un défaut est rencontré.

Tests de haut en bas

Sans la présence de sous-modules, tester l'application en utilisant le module principal est appelé top.
à des tests de détection.

Bouchon

Au lieu d'un sous-module, nous devons faire appel à des programmes temporaires appelés stub.
Tests de bas en haut

Sans la présence du module principal, tester l'application en utilisant le sous-module est appelé de bas en haut.
test supérieur.

Conducteurs

Au lieu du module principal, nous devons utiliser un programme temporaire appelé pilote.

Test de sand wich

La combinaison des approches de haut en bas et de bas en haut est appelée test en sandwich.

C'est la dernière étape des tests d'intégration.

Tests statiques

La vérification effectuée sans exécuter le code du système. Cela s'appelle également analyse statique.

Ou

Sans exécuter les tests, la fonctionnalité est appelée test statique.

IUG

Test dynamique

La vérification et la validation effectuées qui exécutent le code du système sont appelées tests dynamiques.

Conducteur de test ou banc d'essai

Un programme ou un outil de test utilisé pour exécuter des tests. Il est également connu sous le nom de banc d'essai.

Qu'est-ce que le test de bout en bout ?

Ce n'est rien que des tests système. Le terme test système désigne la combinaison de tests de fonctionnalité.
&non test de fonctionnalité.

Fuite de défaut

Le défaut qui peut être trouvé et reproduit par les utilisateurs/client de la même manière que nous (test)
ingénieur) incapable de trouver au moment du test. Cela s'appelle aussi 'fuite de défauts'.

Techniques de test boîte noire :

1. Partitionnement d'équivalence
 2. Analyse des valeurs limites
Graphisme rentable
4. Deviner l'erreur

Partitionnement d'équivalence : les tests des entrées seraient sélectionnés à partir de chaque portion de BVA.

Analyse des valeurs aux limites : tester les entrées aux limites. Haut, bas

Graphisme coût-efficace : une représentation graphique des entrées et des effets de sortie associés
qui peuvent être utilisés pour concevoir des cas de test.

Erreur de devinette :

Test de validation rapide :

Test d'ergonomie

Comment comprendre et naviguer dans l'application n'est rien d'autre que des tests d'utilisabilité.

Test de re-test et test de régression

Retester : le retesting signifie exécuter à nouveau les cas de test sur la même version, c'est-à-dire que je veux dire qui est
déjà testé en fournissant plusieurs données de test.

Comme max, min, -ve, +ve, zéro, int, float, etc.

Les tests de régression : cela signifie exécuter les mêmes cas de test sur la version modifiée.

Comme je veux dire, qui est déjà testé chaque fois que des changements sont apportés ou que de nouvelles fonctionnalités sont ajoutées.
ajoutez assurez-vous que les changements n'affectent pas la fonctionnalité précédente.

Les tests de régression se déclinent en deux types

Tests de régression des bogues
Tests de régression fonctionnelle

Par exemple.

S'il y a 1000 cas de test à exécuter dans la première version... Et parmi les 1000 cas de test, 100 échouent et
900 passe....

supposons dans 1000 cas de test 3rd,7th,12th, 20th..... comme ça jusqu'à 100 cas de test échoués

initialement, alors que nous exécutons les cas de test (1000) le 3rdle cas de test a échoué, nous allons alors procéder
retester cela pour clarifier s'il s'agit d'un bug ou non ? Avant d'envoyer le rapport de bug avec le
statut de 'nouveau' Et de la même manière, nous procéderons à des retests sur les cas de test échoués restants comme
7th, 12th, 20th.....
Puis, après la correction des bogues, chaque fois que la version modifiée (2ème version) est reçue, fonctionnelle
Les tests de RÉGRESSION doivent être effectués sur les 900 cas de test et les 100 cas de test échoués restants.
sont des tests de régression de bogue. Supposons dans cela 3rdon a échoué encore une fois alors nous ferons
retest pour clarification si cela a été corrigé ou non ? si ce n'est pas corrigé avant d'envoyer le bug
avec le statut de 'réouvert' et la régression des tests de bogues sur 100 cas de test et la régression fonctionnelle
test sur 900 cas de test et sur un total de 1000 cas de test, nous procéderons à des tests de régression.

Quel est le premier, le retesting ou le test de régression ?

Les tests sont d'abord

en général, les tests de régression commencent à partir de la construction initiale (1stla construction) et les tests de régression commencent à partir de la modification

construire(2ndconstruire

Tests de volume de données ou tests de volume

Lors de ce test, les ingénieurs de test estiment le stockage en termes de nombre d'enregistrements.

Tests de sécurité

Que l'application offre ou non la confidentialité des données clients.

Test de stockage

Estimer la limite de stockage en termes d'octets n'est rien d'autre que des tests de stockage.

Test d'authentification

Cycle de vie des tests

préparation du plan de test (unité, intégration,...)

concevez vos cas de test

préparer des données de test et des procédures de test

exécuter les cas de test conformément aux procédures

préparer des rapports de défaut

tests de régression après correction de défaut de vérification

Comment suivre un défaut ?
Identifier l'échec du test
signalement de défaut
résoudre le problème
analyser le problème
reproduire le problème
problème complet

SDLC

Qu'est-ce que le SDLC ?

Il spécifie comment exactement vous développez un logiciel à travers diverses étapes et procédures suivies pour développer un
s/w n'est rien d'autre que le SDLC.

Projet S/W.

Les problèmes liés aux logiciels sont résolus par des ingénieurs en logiciels grâce au processus d'ingénierie logicielle, appelés logiciels.
projet.

Il y a 6 phases

1. collecte d'informations
2. analyse
3. conception
4. codage
5. test
6. publication et maintenance

Collecte d'informations :

Dans cette phase, les analystes d'affaires rassemblent les exigences et préparent le BRS.

Cette fois, ils vérifient si les exigences sont spécifiées correctement ou non et si le
le client fournit des informations complètes ou non.

Analyse :

Dans cette phase, l'analyste principal ou le chef de projet prépare le document de spécifications des exigences logicielles avec l'aide du document de spécifications des exigences commerciales.

Ce document se compose de 2 sous-documents.

specification des exigences du système (SRS)

2. spécification des exigences fonctionnelles (REF)

SRS – contient les détails du s/w, h/w, o/s

FRS – contient les détails des fonctionnalités à utiliser dans le projet.

Et aussi dans cette phase, ils vérifient

Que les exigences des clients soient des choses réalisables ou non

Et des choses testables ou non

Et répond à la question du coût ou non.

Conception :

Dans cette phase, le designer crée deux types de documents.

HLD
2. LLD

HLD --- consiste en le module principal du projet de la racine à la feuille et plusieurs modules LLD.

LLD --- se compose de sous-modules du module principal et accompagnés de diagrammes de flux, diagrammes E.R.
préparé par le designer interne.

Et aussi dans cette phase, ils vérifient

Que le HLD et le LLD soient définis correctement ou non.

Que les HLD et LLD soient complets ou non.

Que ce soit en suivant des diagrammes de flux de données et des diagrammes ER ou non.

Codage :

Le design doit être traduit en forme (langage) de programmation.

Les langages de programmation comme C, C++ et JAVA, qui sont utilisés pour le codage.

Des outils de programmation comme les compilateurs, les interprètes et les débogueurs sont utilisés pour générer le code.

Un type spécifique d'application choisit le bon langage de programmation.

Test

Une fois le code généré, les tests commenceront en utilisant différents types de méthodologies comme
WBT, BBT avec l'aide de leurs techniques.

WBT-- Ce n'est rien d'autre que le test de la partie structurelle de l'application.

BBT - Ce n'est rien d'autre que le test de la partie fonctionnelle de l'application. Aucune connaissance des éléments internes n'est nécessaire.
logique du code.

Publier et maintenir :

Après avoir effectué

Qu'est-ce que le test ?

Les tests sont un processus de vérification du logiciel pour vérifier s'il répond aux exigences.
ou pas avec l'intention de trouver des erreurs.

Qu'est-ce que la qualité ?

Un produit de qualité est sans bogue, livré à temps, dans le budget, répond aux attentes du client.
exigences et maintenable.
BRS :
Le BRS définit les exigences du client à développer.
SRS :
Le SRS définit les exigences fonctionnelles à développer et le système
exigences à utiliser.
Re vues
Une technique de test au niveau du document lors de cette révision, les personnes responsables sont

estimation de l'exhaustivité et de la justesse du document correspondant.

Qu'est-ce qu'un 'walkthrough' ?
Un 'walkthrough' est une réunion informelle pour l'évaluation ou l'information.
objectifs et inconduite des personnes en assurance qualité. Dans cela, ils peuvent voir tout le
norme de codage et également les suivre manuellement. Peu ou pas de préparation est
nécessaire. De plus, la visite guidée n'a pas de minutes de la réunion. Cela peut se produire à tout moment.

temps. pas de calendrier tel que.

Le guide est disponible à la fois pour les tests et le codage.
Qu'est-ce qu'une 'ins pection' ?

Une inspection est plus formalisée qu'une 'visite', généralement avec 3-8 personnes.
y compris un modérateur, un lecteur et un preneur de notes. Le sujet de la
l'inspection est généralement un document tel qu'un spécification des exigences ou un plan de test, et
l'objectif est de trouver des problèmes et de voir ce qui manque, pas de réparer quoi que ce soit.

Les participants doivent se préparer pour ce type de réunion en lisant le document.

la plupart des problèmes seront trouvés pendant cette préparation. Le résultat de l'inspection
la réunion devrait être un rapport écrit. Une préparation approfondie pour les inspections est

un travail difficile et laborieux, mais c'est l'un des méthodes les plus rentables pour garantir
qualité. Les employés qui sont les plus compétents en matière d'inspections sont comme le 'frère aîné'
dans la parabole de 'Pourquoi est-il souvent difficile pour la direction de prendre la qualité au sérieux
assurance ?'. Leur compétence peut avoir une faible visibilité mais elle est extrêmement précieuse pour
toute organisation de développement logiciel, puisque la prévention des bogues est de loin plus coûteuse

plus efficace que la détection de bugs.

Qu'est-ce que la vérification ?

Vérification et validation (v&v) est un processus qui aide à déterminer si le s/w
les exigences sont complètes, correctes et si le logiciel de chaque phase de développement est rempli

les exigences et les conditions, imposées par la phase précédente, etc.

La vérification implique généralement des révisions et des réunions pour évaluer des documents,

plans, code, exigences et spécifications. Cela peut être fait avec des listes de contrôle,
listes de problèmes, guides, et réunions d'inspection.
La validation implique généralement des tests réels et a lieu après les vérifications.
terminé.

La vérification répond à la question : « Construisons-nous le bon produit ?

Validation des adresses, "Construisons-nous le Droit de produit ?

Qu'est-ce que le test boîtes blanches ?

Ce n'est rien d'autre que tester la partie structurelle de l'application.

Ou
C'est une approche de test qui examine la structure du programme d'application et
dérive des cas de test de la logique du programme d'application.
Ceci est également appelé
test de boîte ouverte
 ou test structurel
ou test de boîte claire
ou test de boîte en verre
Il existe 4 techniques de test en boîte blanche :
[Link] de chemin de base
[Link] de la structure de contrôle
[Link] technique Test
[Link] de mutation
1. Test de chemin de base :
Pendant ce test, les programmeurs se concentrent sur l'exécution des programmes.
sans aucune erreur d'exécution. Pour effectuer ce test, le programmeur correspondant
suit l'approche ci-dessous.
• Écrivez un programme en ce qui concerne la LLD (Conception de Bas Niveau)

• Dessinez un graphique de flux pour ce programme.

• Calculer la complexité cyclomatique.

Exécutez ce programme plusieurs fois pour couvrir toutes les zones exécutables.

Ex :
- -------
- -------- Condition
Si (?)
-------
------- T F
sinon
-------
-------
--------
-------- Complexité cyclomatique
2(1+1)

Il faut exécuter le programme ci-dessus 2 fois pour couvrir toutes les exécutables.

domaines. Un programmeur a confiance qu'un programme fonctionne uniquement lorsque le

la complexité cyclomatique est atteinte en exécutant les programmes conçus.
REMARQUE : Le programme ci-dessus doit être exécuté 2 fois
 Une fois pour vérifier si la condition est satisfaite ou non
La prochaine fois, vérifiez si la condition else est satisfaite ou
pas, sans erreurs d'exécution.
2. Tests de structure de contrôle :
Lors de ce test, le programmeur correspondant se concentre sur
la justesse de l'exécution du programme dans ce test, ils vérifient chaque déclaration de
exécution du programme. Dans ce test, ils vérifient chaque état d'entrée et sortie des instructions

état.
Débogage
3. Programme de test technique :
Pendant ce test, les programmeurs se concentrent sur l'exécution
vitesse d'un programme. Si la vitesse d'exécution n'est pas raisonnable, alors les programmeurs
effectuer des modifications dans la structure du programme sans perturber la fonctionnalité
Un B
du programme.
Programme d'échange
i. c=a;
a=c+b;
1. Tests de capacité aux États-Unis

2. Testing fonctionnel
3. Non - Fonctionnel Te piqûre
[Link] d'utilisabilité :
En général, l'équipe de test séparée commence l'exécution des tests par l'utilisabilité.
test. Pendant ce test, l'équipe se concentre sur la convivialité du logiciel
construire des écrans. Les tests d'utilisabilité se composent de 2 sous-tests.
a) Test de l'interface utilisateur
b) Manuels de support Test
a) Tests d'interface utilisateur : -
Dans les tests d'interface utilisateur, la version du logiciel est testée pour

Facilité d'utilisation (Compréhensibilité)

Apparence et Ressenti (Attrait)

Vitesse dans l'interface (courtes navigations)
Ceci est appliqué sur chaque écran dans la construction du logiciel.
b) Manu en tant que Support Te sting : -
 Également connu sous le nom de « Aide - test de documents ». Pendant ce test, le

l'équipe de test se concentre sur la justesse et l'exhaustivité des documents d'aide

Manuels d'utilisation.

REMARQUE : En général, l'équipe de test effectue des tests d'interface utilisateur et ensuite

réalise des tests fonctionnels et non fonctionnels. À la fin des tests

processus, l'équipe de test se concentre sur le test de support des manuels
Recevoir la version de l'équipe de développement.
Test de l'interface utilisateur

(Test d'Utilisabilité)
Test fonctionnel et non fonctionnel
Manuels Support Test
Qu'est-ce que le test unitaire ?

Tester la fonctionnalité individuelle d'une application n'est rien d'autre que le test unitaire.
Ou
Tester la petite partie d'une application n'est rien d'autre que des tests unitaires.
Qu'est-ce que le test modulaire ?
Le test des fonctionnalités combinées d'une application n'est rien d'autre que le test modulaire.
Qu'est-ce que le test d'intégration ?
Tester les modules combinés d'une application n'est rien d'autre que des tests d'intégration.
2. Té fonctionnel aiguillon
Un niveau de test du modérateur durant lequel l'équipe de test
se concentre sur les exigences des clients en termes de fonctionnalité. Au cours de ce test,
l'équipe de test applique les sous-tests ci-dessous sur la version du logiciel.

i) Test de fonctionnalité
ii) Tests de sanitation
i) Test de fonctionnalité : -
Lors de ce test, l'équipe de test se concentre sur la justesse de
toutes les fonctionnalités par rapport aux exigences. Dans ce test, l'équipe de test
suit la couverture ci-dessous.
Couverture GUI / Couverture comportementale
(Changements dans les propriétés des objets à l'écran)
Couverture de la gestion des erreurs

(Prévention des opérations incorrectes)

Couverture du domaine d'entrée
 (Prendre la bonne taille et le bon type d'entrées)

Couverture des manipulations

(Renvoyer un résultat correct)
Couverture Backend
(L'impact des opérations des écrans front-end sur les tables arrière-plan)
Ordre des fonctionnalités Couverture
Tests de sanitation : -
Ceci est également connu sous le nom de « test de poubelle ». Lors de ce test, l'équipe de test
identifie des fonctionnalités supplémentaires dans la version du logiciel par rapport au client

exigences.
3. Non-fonctionnels ty T esting:
Un niveau complexe dans les tests système durant lequel l'équipe de test
se concentre sur des caractéristiques supplémentaires du logiciel.
i. Test de récupération
ii. Test de compatibilité
iii. Test de configuration
iv. Test inter-système
v. Tests d'installation
Tests de Charge
vii. Tests de résistance
viii. Test de volume de données
Test de récupération : -
On l'appelle aussi « Test de fiabilité ». Pendant ce test, l'équipe
valide si le changement de version du logiciel passe du mode anormal au mode normal
mode.

(Anormal)

Procédures de sauvegarde et de récupération

Normal
ii) Test de compatibilité : -
Également connu sous le nom de « Test de Portabilité ». Pendant ce test, l'équipe de test

valide si la version du logiciel fonctionne sur les plateformes attendues par le client ou
pas ? Les plateformes sont des systèmes d'exploitation, des compilateurs, des navigateurs et d'autres systèmes

logiciel.

iii) Test de configuration : -

Il est également connu sous le nom de « test de compatibilité matérielle ». Pendant ce test, le

l'équipe de test valide si le logiciel que le logiciel construit est pris en charge
différentes technologies, dispositifs matériels ou non ?

Ex : Différentes technologies d'imprimante, diverses technologies de réseau, etc.

Système Inter Test
On l'appelle aussi test "DE LA FIN À LA FIN". Au cours de ce test, l'équipe
valide si la construction du logiciel coexiste avec d'autres logiciels à partager
ressources communes ou non ?
Tests d'installation :
Lors de ce test, les ingénieurs en test valident combien d'espace est occupé par le
application et si elle valide que l'application offre une navigation facile
étapes à suivre pour l'installation. C'est aussi appelé test de port.

Qu'est-ce que le test de charge ?

L'exécution de notre build s/w et la configuration et la charge attendues par le client

estimer la vitesse de traitement s'appelle le test de charge. ceci est également appelé
tests de scalabilité. Les tests de scalabilité signifient le nombre d'utilisateurs simultanés.

Qu'est-ce que le test de résistance ?

L'exécution de notre construction de logiciels et la configuration attendue par le client et plus encore

que la charge prévue par le client pour estimer la charge de pointe est appelée test de résistance.

Qu'est-ce que le test de saturation ?

Lorsqu'un système fonctionne à un niveau de vitesse élevé pendant une période prolongée, ce test
effectue plusieurs fois plus de transactions en une journée entière si le système peut s'arrêter
travaillant après que le nombre de transactions a été traité en raison de fuites de mémoire ou d'autres problèmes

Les défauts donc, les tests de trempage offrent une opportunité d'identifier de tels défauts.

Tests de volume Da ta : -
Lors de ce test, l'équipe de test estime la limite maximale de données gérées par
notre construction de logiciel.

Test de Stora gé :
au cours de ce test, les ingénieurs d'essai estiment la limite de stockage en termes d'octets.
Tests de sécurité
Lors de ce test, les ingénieurs de test valident si l'application fournit
la vie privée ou pas des données du client (opérations utilisateur)

Tests d'authentification :
Lors de ce test, les ingénieurs d'essai vérifient si l'application dispose d'une connexion.
écran ou non signifie si notre application permet à des utilisateurs valides ou non avec
identifiant de connexion et mot de passe.

Tests de contrôle d'accès :

il est utilisé pour vérifier si l'utilisateur a les permissions ou non pour accéder à
données(services)
par exemple : gestionnaire, administrateur, utilisateur d'authentification, etc. ont les autorisations pour

accédez aux données.

Test parallèle : -
Il est également connu sous le nom de « Test Comparatif » ou « Test Concurrentiel ». Pendant cela
test, l'équipe de test compare la récente version du logiciel avec les versions précédentes
du logiciel construit ou avec le logiciel concurrent sur le marché pour estimer
compétitivité. Ce test ne s'applique qu'aux produits logiciels.
Test ad hoc : -
En général, chaque équipe de test effectue des tests planifiés, mais l'équipe de test
adopte parfois des tests informels en raison de certains défis ou risques.
Manque de temps, manque de ressources, manque de taille d'équipe, manque de compétences, etc.

Ce test informel est également connu sous le nom de test Ad-hoc. Il y a

différents styles dans les tests Ad-hoc.
Buddy T teste : -
Un développeur et un testeur travaillent ensemble en tant qu'amis pour s'entraider à
identifier les défauts tôt. En raison du manque de temps, les développeurs et les testeurs travaillent

ensemble.
Ex : 1:1 (ou) 2:1 (ou) 3:1 (préférable)
ou
En raison du manque de temps, la direction regroupe les programmeurs et les testeurs comme

« Amis ». Chaque groupe d'amis se compose de programmeurs et de testeurs.

Test de paire : -
ce test est effectué par 2 testeurs, l'un est Sr. et l'autre est Jr. parmi eux pour trouver le
des défauts sur la même fonctionnalité, ici le testeur senior partage son expérience avec le testeur junior.

tester (nouveau)
lorsque le nouveau testeur manque de connaissances sur l'application
ou
En raison du manque de connaissance du domaine du projet, la direction regroupe un testeur senior.

& un programmeur junior sont développés et ont mené des tests, tout cela s'appelle
Test en binôme.
Test de singe : -
En raison du manque de temps, l'équipe de test se concentre sur certains des principaux
activités dans la construction de logiciels pour les tests. Ce type de test est connu sous le nom de « Monkey »

test de "testing" ou "test de chimpanzé" ou "test de gorille".

Test exploratoire : -
 En raison du manque de documentation appropriée du logiciel en cours de développement, le test
les ingénieurs s'appuient sur leur expérience passée, discutent avec d'autres, parcourent Internet ou
Exécutez des projets similaires et contactez les personnes du côté client si possible. Ce style de
les tests sont appelés « Test Exploratoire ».
ou
Les tests exploratoires sont une approche dans les tests de logiciels avec un apprentissage simultané.
conception de tests et exécution des tests. Pendant que le logiciel est testé, le testeur apprend
des éléments qui, associés à l'expérience et à la créativité, génèrent de bons nouveaux tests à réaliser.

Semis défectueux : -
Pour évaluer l'efficacité des ingénieurs de test, les programmeurs ajoutent quelques bogues.
à la construction. Cette tâche s'appelle semence de défaut / débogage.
test alpha(non- conventionnel)
tester l'application sur le site du développeur par l'utilisateur final.
Tests bêta ntional):
Tester l'application sur le site du client par le client.
En cryptage et test de décryptage :
c'est entièrement pris en charge par le département de développement. coder et décoder les données est

appelé comme encryption

la conversion des données d'un format à un autre est appelée décryptage.
Tests de beauté :
les tests de l'interface utilisateur sont également appelés tests de beauté ou tests cosmétiques.

Tests statiques
Vérification effectuée sans exécuter le code du système. On l'appelle aussi
analyse statique.
Ou
Sans exécuter la fonctionnalité de test, on l'appelle test statique.
E.g.: GUI, Usability

Test dynamique
La vérification et la validation effectuées qui exécutent le code du système sont appelées
tests dynamiques.
Test de bon sens :
Les tests de santé sont orientés vers la fonctionnalité globale. Que le build publié soit
stable ou pas pour des tests ultérieurs. Cela s'appelle aussi acceptation de build
test (BAT). Après avoir reçu la version initiale, l'équipe de test effectue des tests pour trouver
déterminer si la construction fonctionne ou non. Quelle est la première technique de test appliquée
sur la construction ? Vérifiez si la construction est acceptable pour 1. Tous les éléments du menu sont

ouvert ou pas
Tous les éléments du menu s'ouvrent ou non
2. Tous les champs de texte acceptent-ils des valeurs au clavier ou non.

3. Tous les objets répondent ou non, etc.

Lorsque nous recevons la version initiale de l'équipe de développement, nous effectuons une vérification de bon sens.

test. si la construction fonctionne correctement en termes des facteurs suivants Facile

pour comprendre, facile à utiliser, courtes navigations. Avec une signification de s/o
nous devons appliquer ce test (nouvelle version)