Théorie fondamentale des tests

Les tests ne sont pas une science exacte. Il n'y a pas de définitions claires et bien établies qui peuvent être rassemblées dans un dictionnaire et apprises avant une entrevue. Chaque projet informatique est unique, ce qui génère une énorme quantité d'informations différentes, souvent contradictoires. Comprendre les processus et les approches devient important dans les tests, comme dans toute profession. Il est important non seulement de connaître le nom de tel ou tel processus, le type de test, mais ce que c'est et pourquoi il est nécessaire sur le projet.

Passons aux concepts de base.

Le test logiciel est une vérification de la conformité des résultats réels et attendus du comportement du programme, effectuée sur un ensemble fini de tests choisis d'une certaine manière.



Le but des tests est de vérifier que le logiciel répond aux exigences, de garantir la confiance dans la qualité du logiciel, de rechercher des erreurs évidentes dans le logiciel, qui doivent être identifiées avant que les utilisateurs du programme ne les trouvent.



Pourquoi des tests logiciels sont-ils nécessaires?

• Le processus de test garantit que le logiciel fonctionnera selon les besoins.
• Cela réduit les cycles de codage en identifiant les problèmes au début de la phase de développement. La détection des problèmes plus tôt dans la phase de développement garantit une utilisation correcte des ressources et évite les augmentations de coûts.
• , .
• , , , .

• 1 — (Testing shows presence of defects). , , , . , , .
• 2 — (Exhaustive testing is impossible). , . , .
• 3 — (Early testing). , , .
• 4 — (Defects clustering). – . . , .
• 5 — (Pesticide paradox). , . « », , , , , .
• 6 — (Testing is concept depending). - . , , , , .
• Principe 7 - Idée fausse sur l'absence d'erreurs (mettre fin à l'absence-d'erreurs à l'erreur) . L'absence de défauts constatés lors des tests ne signifie pas toujours que le produit est prêt à être commercialisé. Le système doit être convivial et répondre aux attentes et aux besoins de l'utilisateur.

Assurance de la qualité (AQ) et contrôle de la qualité (CQ) - ces termes sont similaires aux termes interchangeables, mais il existe toujours une différence entre l'assurance de la qualité et le contrôle de la qualité, bien qu'en pratique les processus présentent certaines similitudes.



QC (Quality Control) - Contrôle de la qualité du produit - analyse des résultats des tests et de la qualité des nouvelles versions du produit lancé.

Les tâches de contrôle de la qualité comprennent:

• vérifier l'état de préparation du logiciel pour la publication;
• vérification du respect des exigences et de la qualité de ce projet.

QA (Quality Assurance) - Assurance qualité des produits - explorer les opportunités de changer et améliorer le processus de développement, améliorer la communication au sein de l'équipe, où les tests ne sont que l'un des aspects de l'assurance qualité.



Les objectifs d'assurance qualité comprennent:

• vérification des caractéristiques techniques et des exigences logicielles;
• l'évaluation des risques;
• planifier des tâches pour améliorer la qualité des produits;
• préparation de la documentation, de l'environnement de test et des données;
• essai;
• l'analyse des résultats des tests, ainsi que la rédaction de rapports et autres documents.

La vérification et la validation sont deux concepts étroitement liés aux processus de test et d'assurance qualité. Malheureusement, ils sont souvent confus, bien que les différences entre eux soient assez importantes.



La vérification est le processus d'évaluation d'un système pour voir si les résultats de la phase de développement en cours remplissent les conditions qui ont été formulées au début.



La validation est la détermination de la conformité du logiciel développé avec les attentes et les besoins de l'utilisateur, ses exigences pour le système.



: 310, , «», . , , «». , . , , , . «» — , «» — . , .







La documentation utilisée sur les projets de développement de logiciels peut être divisée en deux groupes:

1. Documentation du projet - comprend tout ce qui concerne le projet dans son ensemble.
2. La documentation produit fait partie de la documentation de conception, allouée séparément, qui se rapporte directement à l'application ou au système développé.

Étapes de test:

1. L'analyse du produit
2. Travailler avec les exigences
3. Développer une stratégie de test et planifier des procédures de contrôle qualité
4. Création de la documentation de test
5. Test de prototype
6. Test de base
7. Stabilisation
8. Exploitation

Étapes de développement logiciel - les étapes que les équipes de développement logiciel traversent avant que le programme ne devienne disponible pour un large éventail d'utilisateurs.



Le produit logiciel passe par les étapes suivantes:

1. analyse des exigences du projet;
2. conception;
3. la mise en oeuvre;
4. tests de produits;
5. mise en œuvre et soutien.

Conditions

Les exigences sont une spécification (description) de ce qui doit être mis en œuvre.

Les exigences décrivent ce qui doit être mis en œuvre sans détailler le côté technique de la solution.



Exigences relatives aux exigences:

1. Exactitude - chaque exigence doit décrire avec précision la fonctionnalité souhaitée.
2. Vérifiabilité - l'exigence doit être formulée de telle manière qu'il existe des moyens de vérifier sans ambiguïté si elle est remplie ou non.
3. Exhaustivité - chaque exigence doit contenir toutes les informations nécessaires dont le développeur a besoin pour implémenter la fonctionnalité.
4. Sans ambiguïté - l'exigence est décrite sans abréviations non évidentes et formulations vagues et ne permet qu'une interprétation sans ambiguïté de ce qui est écrit.
5. — .
6. — ( ). .
7. — .
8. — .
9. — , .

Défaut (bug) - écart du résultat réel par rapport à celui attendu.



Un rapport de bogue est un document décrivant la situation qui a conduit à la découverte d'un défaut, en indiquant les raisons et le résultat attendu.



Attributs du rapport de défauts:

1. Identifiant unique (ID) - attribué automatiquement par le système.
   
   
2. Sujet (brève description, résumé) - une essence brièvement formulée du défaut selon la règle «Quoi? Où? Lorsque?"
3. Description détaillée (Description) - une description plus large de l'essence du défaut (spécifiée facultativement).
   
   ...
4. Étapes à reproduire - une description séquentielle des actions qui ont conduit à l'identification du défaut. Il est nécessaire de décrire avec le plus de détails possible, en indiquant les valeurs d'entrée spécifiques.
   
   
5. (Actual result) — , , .
6. (Expected result) — , , .
   
   
7. (Attachments) — , -.
8. (, Severity) — .
9. (, Priority) — .
10. (Status) — . - .
11. (environment) – , .

Severity vs Priority

La gravité indique le degré de dommage causé au projet par l'existence d'un défaut. La gravité est exposée par le testeur.



Graduation de la gravité des défauts:

• Le
  
  test de blocage (S1 - Blocker) d'une partie importante de la fonctionnalité n'est pas du tout disponible. Erreur de blocage qui rend l'application inopérante, à la suite de quoi il devient impossible de continuer à travailler avec le système testé ou ses fonctions clés.
• (S2 – Critical)
  
  , -, , , , - , workaround ( / ), .
• (S3 – Major)
  
  - /-, , workaround, - . visibility – , , , .
• (S4 – Minor)
  
  GUI, , . , .
• Trivial (S5 - Trivial)
  
  presque toujours des défauts dans l'interface graphique - fautes de frappe dans le texte, inadéquation de la police et de la teinte, etc., ou une erreur mal reproductible qui ne concerne pas la logique métier, un problème avec des bibliothèques ou des services tiers, un problème qui n'a aucun effet sur la qualité globale du produit.

La priorité indique la rapidité avec laquelle le défaut doit être corrigé. La priorité est définie par le responsable, le chef d'équipe ou le client. Gradation de



priorité des défauts (priorité):

• P1 High L'
  
  erreur doit être corrigée dès que possible. sa présence est essentielle au projet.
• P2 Moyen L'
  
  erreur doit être corrigée, sa présence n'est pas critique, mais doit être résolue.
• P3 (Low)
  
  , .

:

• (epic) — , .
• (story) — (), 1 .
• (task) — , .
• - (sub-task) — / , .
• (bug) — , .

• (Development Env) – , , , Unit-. .
• (Test Env) – . . , , . .
• (Integration Env) – , . end-to-end , , . , . – , .
• (Preview, Preprod Env) – , : , - , . , «». end-to-end , / (User Acceptance Testing (UAT)), L3 L2 DryRun ( ). L3 .
• (Production Env) – , . L2 , , . L3.

• Pre-Alpha: . . . .
• Alpha: . — . - . . .
• Beta: . , .
• Release Candidate (RC) : Sur la base des commentaires du test bêta, vous apportez des modifications au logiciel et souhaitez tester des corrections de bogues. À ce stade, vous ne voulez pas apporter de modifications drastiques aux fonctionnalités, mais simplement rechercher des bogues. RC peut également être rendu public.
• Libération: tout fonctionne, le logiciel est rendu public.

Les principaux types de tests logiciels

Un type de test est un ensemble d'activités visant à tester les caractéristiques spécifiées d'un système ou de sa partie, en fonction d'objectifs spécifiques.

1. Classification en exécutant du code pour l'exécution:
   
   
   • — . , . «». — .
   • — . , / . — , . , , .
   
   
   
2. :
   
   
   • — , , // .
   • — , White Box Black Box . , .
   • — , – , .
   
   
   
3. :
   
   
   • — - ( , subprograms, subroutines, ) . , .
   • — , ( , ).
   • — , , .
   • — , - .
   
   
   
4. :
   
   
   • .
   • .
   
   
   
5. 
   
   
   • — , .
   • — , .
   
   
   
6. :
   
   
   • (smoke test) — , , .
   • (critical path) — , .
   • (extended) — .
   
   
   
7. :
   
   
   • - — . - .
   • - — . , .
   
   
   
8. :
   
   
   • (functional testing) — ( ).
   • (non-functional testing) — , , , « ».
     
     
     1. (performance testing) — , , .
     2. (load testing) — , , .
     3. (scalability testing) — .
     4. (volume testing) — , .
     5. (stress testing) — , .
     6. (installation testing) — , , .
     7. (GUI/UI testing) — .
     8. (usability testing) — , .
     9. (localization testing) — (, ).
     10. (security testing) — , .
     11. (reliability testing) — .
     12. Test de régression - test de fonctionnalités précédemment testées après avoir apporté des modifications au code de l'application, pour s'assurer que ces modifications n'ont pas introduit d'erreurs dans des domaines qui n'ont pas été modifiés.
     13. Re-test / test de confirmation - test au cours duquel les scripts de test qui ont détecté des erreurs lors de la dernière exécution sont exécutés pour confirmer le succès de la correction de ces erreurs.
   
   
   

La conception des tests est l'étape des tests logiciels, au cours de laquelle les cas de test (cas de test) sont conçus et créés.



Techniques de conception de tests:

1. (equivalence partitioning) — , , ( ) .
2. (boundary value testing) — () .
3. (pairwise testing) — , -.
4. (State-Transition Testing) — .
5. (Decision Table Testing) — , , .
6. (Exploratory Testing) — , -: .
7. (Domain Analysis Testing) — , .
8. (Use Case Testing) — Use Case ( — ).

Le test en boîte blanche est une méthode de test logicielle qui suppose que la structure interne / le dispositif / la mise en œuvre du système sont connus du testeur.



Selon l'ISTQB, le test en boîte blanche est:

- un test basé sur une analyse de la structure interne d'un composant ou d'un système;

- conception de test basée sur la technique de la boîte blanche - procédure d'écriture ou de sélection de cas de test basée sur l'analyse de la structure interne d'un système ou d'un composant

Pourquoi White Box? Le programme testé pour le testeur est une boîte transparente dont il voit parfaitement le contenu.



Test de la boîte grise- méthode de test du logiciel, qui suppose une combinaison d'approches White Box et Black Box. Autrement dit, nous ne connaissons que partiellement la structure interne du programme.



Le test de la boîte noire - également connu sous le nom de test basé sur les spécifications ou test de comportement - est une technique de test qui repose uniquement sur les interfaces externes du système testé.



Selon l'ISTQB, le test boîte noire est:

- le test, à la fois fonctionnel et non fonctionnel, qui n'implique pas la connaissance de la structure interne d'un composant ou d'un système;

- conception de test basée sur la technique de la boîte noire - une procédure d'écriture ou de sélection de cas de test basée sur une analyse de la spécification fonctionnelle ou non fonctionnelle d'un composant ou d'un système sans connaître sa structure interne.

Documentation de test

Un plan de test est un document qui décrit l'ensemble de la portée des tests, de la description de l'installation, de la stratégie, du calendrier, des critères de début et de fin des tests, à l'équipement requis dans le processus d'exploitation, des connaissances spéciales, ainsi que l'évaluation des risques. avec des options pour leur résolution. ...



Le plan de test doit répondre aux questions suivantes:

• Que faut-il tester?
• Que vas-tu tester?
• Comment allez-vous tester?
• Quand allez-vous tester?
• Critères de démarrage du test.
• Critères de terminaison des tests.

Les principaux points du plan de test:



La norme IEEE 829 énumère les points que le plan de test devrait comprendre:

a) identificateur du plan de test;

b) Introduction;

c) éléments de test;

d) Caractéristiques à tester;

e) Caractéristiques à ne pas tester;

f) approche;

g) Critères de réussite / échec de l'élément;

h) Critères de suspension et exigences de reprise;

i) Tester les produits livrables;

j) Tâches de test;

k) les besoins environnementaux;

l) Responsabilités;

m) les besoins en personnel et en formation;

n) Calendrier;

o) risques et imprévus;

p) Approbations.



Une liste de contrôle est un document qui décrit ce qui doit être testé. La liste de contrôle peut être de niveaux de détail complètement différents.



Le plus souvent, la liste de contrôle ne contient que des actions, sans le résultat attendu. La liste de contrôle est moins formalisée.



Un scénario de test est un artefact qui décrit un ensemble d'étapes, des conditions spécifiques et des paramètres nécessaires pour tester l'implémentation d'une fonction testée ou d'une partie de celle-ci.



Attributs du scénario de test:

• Conditions préalables - une liste d'actions qui amènent le système à un état approprié pour effectuer une vérification de base. Ou une liste de conditions dont le respect indique que le système est dans un état approprié pour effectuer le test principal.
• Étapes - une liste d'actions qui transfèrent le système d'un état à un autre, afin d'obtenir un résultat, sur la base duquel il est possible de conclure que la mise en œuvre répond aux exigences.
• Résultat attendu - ce qu'ils devraient obtenir en fait.

Résumé

Essayez de comprendre les définitions, pas de les mémoriser. Et si vous avez une question, vous pouvez toujours nous la poser sur la chaîne de télégramme @qa_chillout .