Présentation des tests logiciels

Le test logiciel est une évaluation du logiciel par rapport aux exigences recueillies auprès des utilisateurs et des spécifications du système. Les tests sont effectués au niveau de la phase du cycle de vie du développement logiciel ou au niveau du module dans le code du programme. Les tests logiciels comprennent la validation et la vérification.

Validation du logiciel

La validation est un processus consistant à examiner si le logiciel répond ou non aux exigences de l'utilisateur. Il est réalisé à la fin du SDLC. Si le logiciel correspond aux exigences pour lesquelles il a été réalisé, il est validé.

  • La validation garantit que le produit en cours de développement est conforme aux exigences de l'utilisateur.
  • La validation répond à la question - "Développons-nous le produit qui répond à tous les besoins de l'utilisateur de ce logiciel?".
  • La validation met l'accent sur les exigences des utilisateurs.

Vérification du logiciel

La vérification est le processus de confirmation si le logiciel répond aux exigences de l'entreprise et est développé conformément aux spécifications et méthodologies appropriées.

  • La vérification garantit que le produit en cours de développement est conforme aux spécifications de conception.
  • La vérification répond à la question: "Développons-nous ce produit en suivant fermement toutes les spécifications de conception?"
  • Les vérifications se concentrent sur la conception et les spécifications du système.

Les cibles du test sont -

  • Errors- Ce sont de réelles erreurs de codage commises par les développeurs. De plus, il y a une différence dans la sortie du logiciel et la sortie souhaitée, est considérée comme une erreur.

  • Fault- Lorsqu'une erreur existe, un défaut se produit. Une erreur, également connue sous le nom de bogue, est le résultat d'une erreur qui peut entraîner une défaillance du système.

  • Failure - on dit que l'échec est l'incapacité du système à exécuter la tâche souhaitée. Une panne se produit lorsqu'une panne existe dans le système.

Test manuel vs test automatisé

Les tests peuvent être effectués manuellement ou à l'aide d'un outil de test automatisé:

  • Manual- Ce test est effectué sans l'aide d'outils de test automatisés. Le testeur logiciel prépare les cas de test pour différentes sections et niveaux du code, exécute les tests et rapporte le résultat au gestionnaire.

    Les tests manuels demandent du temps et des ressources. Le testeur doit confirmer si les bons cas de test sont utilisés ou non. La majeure partie des tests implique des tests manuels.

  • AutomatedCe test est une procédure de test réalisée à l'aide d'outils de test automatisés. Les limites des tests manuels peuvent être surmontées à l'aide d'outils de test automatisés.

Un test doit vérifier si une page Web peut être ouverte dans Internet Explorer. Cela peut être facilement fait avec des tests manuels. Mais pour vérifier si le serveur Web peut supporter 1 million d'utilisateurs, il est tout à fait impossible de tester manuellement.

Il existe des outils logiciels et matériels qui aident les testeurs à effectuer des tests de charge, des tests de résistance et des tests de régression.

Approches de test

Les tests peuvent être menés selon deux approches -

  • Test de fonctionnalité
  • Test de mise en œuvre

Lorsque la fonctionnalité est testée sans prendre en compte l'implémentation réelle, on parle de test de boîte noire. L'autre aspect est connu sous le nom de test en boîte blanche où non seulement la fonctionnalité est testée, mais la façon dont elle est mise en œuvre est également analysée.

Les tests exhaustifs sont la meilleure méthode souhaitée pour un test parfait. Chaque valeur possible dans la plage des valeurs d'entrée et de sortie est testée. Il n'est pas possible de tester chaque valeur dans un scénario du monde réel si la plage de valeurs est large.

Test en boîte noire

Il est effectué pour tester la fonctionnalité du programme. Il est également appelé test «comportemental». Le testeur dans ce cas, a un ensemble de valeurs d'entrée et des résultats souhaités respectifs. En fournissant une entrée, si la sortie correspond aux résultats souhaités, le programme est testé «ok», et problématique dans le cas contraire.

Dans cette méthode de test, la conception et la structure du code ne sont pas connues du testeur, et les ingénieurs de test et les utilisateurs finaux effectuent ce test sur le logiciel.

Techniques de test en boîte noire:

  • Equivalence class- L'entrée est divisée en classes similaires. Si un élément d'une classe réussit le test, on suppose que toute la classe est passée.

  • Boundary values- L'entrée est divisée en valeurs finales supérieures et inférieures. Si ces valeurs réussissent le test, on suppose que toutes les valeurs intermédiaires peuvent également réussir.

  • Cause-effect graphing- Dans les deux méthodes précédentes, une seule valeur d'entrée à la fois est testée. Cause (entrée) - L'effet (sortie) est une technique de test où des combinaisons de valeurs d'entrée sont testées de manière systématique.

  • Pair-wise Testing- Le comportement du logiciel dépend de plusieurs paramètres. Dans les tests par paires, les multiples paramètres sont testés par paires pour leurs différentes valeurs.

  • State-based testing- Le système change d'état lors de la fourniture de l'entrée. Ces systèmes sont testés en fonction de leurs états et de leurs entrées.

Test en boîte blanche

Il est effectué pour tester le programme et sa mise en œuvre, afin d'améliorer l'efficacité ou la structure du code. Il est également connu sous le nom de test «structurel».

Dans cette méthode de test, la conception et la structure du code sont connues du testeur. Les programmeurs du code effectuent ce test sur le code.

Voici quelques techniques de test en boîte blanche:

  • Control-flow testing- Le but du test de flux de contrôle est de mettre en place des cas de test qui couvrent toutes les déclarations et conditions de branchement. Les conditions de branchement sont testées pour être à la fois vraies et fausses, de sorte que toutes les déclarations puissent être couvertes.

  • Data-flow testing- Cette technique de test met l'accent sur toutes les variables de données incluses dans le programme. Il teste où les variables ont été déclarées et définies et où elles ont été utilisées ou modifiées.

Niveaux de test

Le test lui-même peut être défini à différents niveaux de SDLC. Le processus de test est parallèle au développement logiciel. Avant de passer à l'étape suivante, une étape est testée, validée et vérifiée.

Les tests séparément sont effectués uniquement pour s'assurer qu'il n'y a plus de bogues ou de problèmes cachés dans le logiciel. Le logiciel est testé à différents niveaux -

Test unitaire

Pendant le codage, le programmeur effectue des tests sur cette unité de programme pour savoir si elle est sans erreur. Les tests sont effectués selon une approche de test en boîte blanche. Les tests unitaires aident les développeurs à décider que les unités individuelles du programme fonctionnent selon les exigences et sont sans erreur.

Test d'intégration

Même si les unités de logiciel fonctionnent correctement individuellement, il est nécessaire de savoir si les unités, si elles étaient intégrées ensemble, fonctionneraient également sans erreurs. Par exemple, la transmission d'arguments et la mise à jour des données, etc.

Test du système

Le logiciel est compilé en tant que produit, puis il est testé dans son ensemble. Cela peut être accompli en utilisant un ou plusieurs des tests suivants:

  • Functionality testing - Teste toutes les fonctionnalités du logiciel par rapport à l'exigence.

  • Performance testing- Ce test prouve l'efficacité du logiciel. Il teste l'efficacité et le temps moyen mis par le logiciel pour effectuer la tâche souhaitée. Les tests de performance sont effectués au moyen de tests de charge et de tests de résistance où le logiciel est soumis à une charge élevée d'utilisateurs et de données dans diverses conditions d'environnement.

  • Security & Portability - Ces tests sont effectués lorsque le logiciel est destiné à fonctionner sur différentes plates-formes et accessible par nombre de personnes.

Test d'acceptation

Lorsque le logiciel est prêt à être remis au client, il doit passer par la dernière phase de test où il est testé pour l'interaction et la réponse de l'utilisateur. Ceci est important car même si le logiciel répond à toutes les exigences de l'utilisateur et si l'utilisateur n'aime pas la façon dont il apparaît ou fonctionne, il peut être rejeté.

  • Alpha testing- L'équipe de développeurs effectue elle-même des tests alpha en utilisant le système comme s'il était utilisé dans l'environnement de travail. Ils essaient de découvrir comment l'utilisateur réagirait à une action dans le logiciel et comment le système devrait réagir aux entrées.

  • Beta testing- Une fois le logiciel testé en interne, il est remis aux utilisateurs pour l'utiliser dans leur environnement de production uniquement à des fins de test. Ce n'est pas encore le produit livré. Les développeurs s'attendent à ce que les utilisateurs à ce stade apportent des problèmes infimes, qui ont été ignorés.

Les tests de régression

Chaque fois qu'un produit logiciel est mis à jour avec un nouveau code, une nouvelle fonctionnalité ou une nouvelle fonctionnalité, il est testé de manière approfondie pour détecter tout impact négatif du code ajouté. Ceci est connu sous le nom de test de régression.

Documentation de test

Les documents de test sont préparés à différentes étapes -

Avant de tester

Les tests commencent par la génération des cas de test. Les documents suivants sont nécessaires pour référence -

  • SRS document - Document des exigences fonctionnelles

  • Test Policy document - Ceci décrit dans quelle mesure les tests doivent avoir lieu avant de lancer le produit.

  • Test Strategy document - Ceci mentionne les aspects détaillés de l'équipe de test, la matrice de responsabilité et les droits / responsabilité du responsable de test et de l'ingénieur de test.

  • Traceability Matrix document- Il s'agit d'un document SDLC, qui est lié au processus de collecte des exigences. À mesure que de nouvelles exigences se présentent, elles sont ajoutées à cette matrice. Ces matrices aident les testeurs à connaître la source de l'exigence. Ils peuvent être tracés en avant et en arrière.

Pendant le test

Les documents suivants peuvent être requis lors du démarrage et de la réalisation du test:

  • Test Case document- Ce document contient la liste des tests à réaliser. Il comprend un plan de test unitaire, un plan de test d'intégration, un plan de test système et un plan de test d'acceptation.

  • Test description - Ce document est une description détaillée de tous les cas de test et des procédures pour les exécuter.

  • Test case report - Ce document contient un rapport de cas de test à la suite du test.

  • Test logs - Ce document contient des journaux de test pour chaque rapport de cas de test.

Après le test

Les documents suivants peuvent être générés après les tests:

  • Test summary- Ce résumé de test est une analyse collective de tous les rapports et journaux de test. Il résume et conclut si le logiciel est prêt à être lancé. Le logiciel est publié sous le système de contrôle de version s'il est prêt à être lancé.

Tests vs contrôle qualité, assurance qualité et audit

Nous devons comprendre que les tests logiciels sont différents de l'assurance qualité logicielle, du contrôle qualité logiciel et de l'audit logiciel.

  • Software quality assurance- Il s'agit de moyens de suivi des processus de développement logiciel, par lesquels il est assuré que toutes les mesures sont prises conformément aux normes d'organisation. Cette surveillance est effectuée pour s'assurer que les méthodes de développement logiciel appropriées ont été suivies.

  • Software quality control- Il s'agit d'un système pour maintenir la qualité du produit logiciel. Il peut inclure des aspects fonctionnels et non fonctionnels du produit logiciel, qui améliorent la bonne volonté de l'organisation. Ce système garantit que le client reçoit un produit de qualité pour ses besoins et le produit certifié comme «apte à l'emploi».

  • Software audit- Il s'agit d'un examen de la procédure utilisée par l'organisation pour développer le logiciel. Une équipe d'auditeurs, indépendante de l'équipe de développement, examine le processus logiciel, la procédure, les exigences et d'autres aspects de SDLC. Le but de l'audit logiciel est de vérifier que le logiciel et son processus de développement sont à la fois conformes aux normes, règles et réglementations.