Tests logiciels - Niveaux

Il existe différents niveaux au cours du processus de test. Dans ce chapitre, une brève description de ces niveaux est fournie.

Les niveaux de test incluent différentes méthodologies qui peuvent être utilisées lors des tests de logiciels. Les principaux niveaux de tests logiciels sont:

Test fonctionel
Test non fonctionnel

Test fonctionel

Il s'agit d'un type de test de boîte noire basé sur les spécifications du logiciel à tester. L'application est testée en fournissant une entrée, puis les résultats sont examinés qui doivent se conformer à la fonctionnalité pour laquelle elle était prévue. Les tests fonctionnels d'un logiciel sont effectués sur un système complet et intégré pour évaluer la conformité du système aux exigences spécifiées.

Il y a cinq étapes qui sont impliquées lors du test de fonctionnalité d'une application.

Pas	La description
je	La détermination de la fonctionnalité que l'application prévue est censée exécuter.
II	La création de données de test en fonction des spécifications de l'application.
III	La sortie basée sur les données de test et les spécifications de l'application.
IV	L'écriture de scénarios de test et l'exécution de cas de test.
V	La comparaison des résultats réels et attendus en fonction des cas de test exécutés.

Une pratique de test efficace verra les étapes ci-dessus appliquées aux politiques de test de chaque organisation et s'assurera donc que l'organisation maintient les normes les plus strictes en matière de qualité logicielle.

Test unitaire

Ce type de test est effectué par les développeurs avant que la configuration ne soit remise à l'équipe de test pour exécuter formellement les cas de test. Les tests unitaires sont effectués par les développeurs respectifs sur les unités individuelles des zones attribuées au code source. Les développeurs utilisent des données de test différentes des données de test de l'équipe d'assurance qualité.

Le but des tests unitaires est d'isoler chaque partie du programme et de montrer que les différentes parties sont correctes en termes d'exigences et de fonctionnalités.

Limitations des tests unitaires

Les tests ne peuvent pas détecter tous les bogues d'une application. Il est impossible d'évaluer chaque chemin d'exécution dans chaque application logicielle. Il en va de même pour les tests unitaires.

Il existe une limite au nombre de scénarios et de données de test qu'un développeur peut utiliser pour vérifier un code source. Après avoir épuisé toutes les options, il n'y a pas d'autre choix que d'arrêter les tests unitaires et de fusionner le segment de code avec d'autres unités.

Test d'intégration

Les tests d'intégration sont définis comme les tests de parties combinées d'une application pour déterminer si elles fonctionnent correctement. Les tests d'intégration peuvent être effectués de deux manières: les tests d'intégration ascendante et les tests d'intégration descendants.

N ° Sr.	Méthode de test d'intégration
1	Bottom-up integration Ces tests commencent par des tests unitaires, suivis de tests de combinaisons d'unités progressivement de plus haut niveau appelées modules ou builds.
2	Top-down integration Dans ce test, les modules de niveau le plus élevé sont testés en premier et progressivement, les modules de niveau inférieur sont testés par la suite.

Dans un environnement de développement logiciel complet, les tests ascendants sont généralement effectués en premier, suivis des tests descendants. Le processus se termine par plusieurs tests de l'application complète, de préférence dans des scénarios conçus pour imiter des situations réelles.

Test du système

Le test du système teste le système dans son ensemble. Une fois tous les composants intégrés, l'application dans son ensemble est testée rigoureusement pour vérifier qu'elle répond aux normes de qualité spécifiées. Ce type de test est effectué par une équipe de test spécialisée.

Les tests du système sont importants pour les raisons suivantes -

Le test du système est la première étape du cycle de vie du développement logiciel, où l'application est testée dans son ensemble.
L'application est testée minutieusement pour vérifier qu'elle répond aux spécifications fonctionnelles et techniques.
L'application est testée dans un environnement très proche de l'environnement de production où l'application sera déployée.
Les tests système nous permettent de tester, vérifier et valider à la fois les exigences de l'entreprise et l'architecture de l'application.

Les tests de régression

Chaque fois qu'une modification est apportée à une application logicielle, il est fort possible que d'autres zones de l'application aient été affectées par cette modification. Les tests de régression sont effectués pour vérifier qu'un bogue corrigé n'a pas entraîné une autre violation de fonctionnalité ou de règle métier. Le but des tests de régression est de s'assurer qu'une modification, telle qu'une correction de bogue, ne doit pas entraîner la découverte d'une autre erreur dans l'application.

Les tests de régression sont importants pour les raisons suivantes -

Minimisez les lacunes dans les tests lorsqu'une application avec des modifications apportées doit être testée.
Tester les nouvelles modifications pour vérifier que les modifications apportées n'ont affecté aucun autre domaine de l'application.
Atténue les risques lorsque des tests de régression sont effectués sur l'application.
La couverture des tests est augmentée sans compromettre les délais.
Augmentez la vitesse de commercialisation du produit.

Test d'acceptation

C'est sans doute le type de test le plus important, car il est effectué par l'équipe d'assurance qualité qui évaluera si l'application répond aux spécifications prévues et satisfait aux exigences du client. L'équipe d'assurance qualité disposera d'un ensemble de scénarios et de cas de test pré-écrits qui seront utilisés pour tester l'application.

Plus d'idées seront partagées sur l'application et plus de tests pourront être effectués dessus pour évaluer sa précision et les raisons pour lesquelles le projet a été lancé. Les tests d'acceptation ne visent pas seulement à signaler de simples fautes d'orthographe, des erreurs esthétiques ou des lacunes d'interface, mais également à signaler tout bogue dans l'application qui entraînera des pannes du système ou des erreurs majeures dans l'application.

En effectuant des tests d'acceptation sur une application, l'équipe de test réduira les performances de l'application en production. Il existe également des exigences légales et contractuelles pour l'acceptation du système.

Test alpha

Ce test est la première étape des tests et sera réalisé entre les équipes (développeurs et équipes QA). Les tests unitaires, les tests d'intégration et les tests système lorsqu'ils sont combinés sont appelés tests alpha. Au cours de cette phase, les aspects suivants seront testés dans l'application -

Fautes d'orthographe
Liens brisés
Directions nuageuses
L'application sera testée sur des machines avec les spécifications les plus basses pour tester les temps de chargement et les éventuels problèmes de latence.

Tests bêta

Ce test est effectué une fois que le test alpha a été effectué avec succès. Lors des tests bêta, un échantillon du public cible teste l'application. Les tests bêta sont également connus sous le nom depre-release testing. Les versions de test bêta du logiciel sont idéalement distribuées à un large public sur le Web, en partie pour donner au programme un test «dans le monde réel» et en partie pour fournir un aperçu de la prochaine version. Dans cette phase, le public testera les éléments suivants -

Les utilisateurs installeront, exécuteront l'application et enverront leurs commentaires à l'équipe du projet.
Erreurs typographiques, flux d'application déroutant et même plantages.
En obtenant les commentaires, l'équipe de projet peut résoudre les problèmes avant de diffuser le logiciel aux utilisateurs réels.
Plus vous résolvez de problèmes qui résolvent de vrais problèmes d'utilisateurs, plus la qualité de votre application sera élevée.
Avoir une application de meilleure qualité lorsque vous la publiez au grand public augmentera la satisfaction des clients.

Tests non fonctionnels

Cette section est basée sur le test d'une application à partir de ses attributs non fonctionnels. Les tests non fonctionnels consistent à tester un logiciel à partir des exigences qui sont de nature non fonctionnelle mais importantes telles que les performances, la sécurité, l'interface utilisateur, etc.

Certains des types de tests non fonctionnels importants et couramment utilisés sont décrits ci-dessous.

Test de performance

Il est principalement utilisé pour identifier les goulots d'étranglement ou les problèmes de performances plutôt que pour trouver des bogues dans un logiciel. Il existe différentes causes qui contribuent à réduire les performances d'un logiciel -

Retard du réseau
Traitement côté client
Traitement des transactions de base de données
Équilibrage de charge entre les serveurs
Rendu des données

Les tests de performance sont considérés comme l'un des types de tests importants et obligatoires en ce qui concerne les aspects suivants:

Vitesse (c.-à-d. Temps de réponse, rendu et accès aux données)
Capacity
Stability
Scalability

Les tests de performance peuvent être qualitatifs ou quantitatifs et peuvent être divisés en différents sous-types tels que Load testing et Stress testing.

Test de charge

Il s'agit d'un processus de test du comportement d'un logiciel en appliquant une charge maximale en termes d'accès au logiciel et de manipulation de grandes données d'entrée. Cela peut être fait à la fois dans des conditions de charge normales et de pointe. Ce type de test identifie la capacité maximale du logiciel et son comportement aux heures de pointe.

La plupart du temps, les tests de charge sont effectués à l'aide d'outils automatisés tels que Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Les utilisateurs virtuels (VUsers) sont définis dans l'outil de test automatisé et le script est exécuté pour vérifier le test de charge du logiciel. Le nombre d'utilisateurs peut être augmenté ou diminué simultanément ou progressivement en fonction des besoins.

Test de stress

Les tests de résistance comprennent le test du comportement d'un logiciel dans des conditions anormales. Par exemple, cela peut inclure la suppression de certaines ressources ou l'application d'une charge au-delà de la limite de charge réelle.

L'objectif des tests de résistance est de tester le logiciel en appliquant la charge au système et en prenant en charge les ressources utilisées par le logiciel pour identifier le point de rupture. Ce test peut être effectué en testant différents scénarios tels que -

Arrêt ou redémarrage des ports réseau de manière aléatoire
Activer ou désactiver la base de données
Exécuter différents processus qui consomment des ressources telles que le processeur, la mémoire, le serveur, etc.

Tests d'utilisation

Les tests d'utilisabilité sont une technique de boîte noire et sont utilisés pour identifier toute (s) erreur (s) et améliorations du logiciel en observant les utilisateurs à travers leur utilisation et leur fonctionnement.

Selon Nielsen, la convivialité peut être définie en termes de cinq facteurs, à savoir l'efficacité d'utilisation, la capacité d'apprentissage, la capacité de mémoire, les erreurs / la sécurité et la satisfaction. Selon lui, l'utilisabilité d'un produit sera bonne et le système est utilisable s'il possède les facteurs ci-dessus.

Nigel Bevan et Macleod considèrent que la convivialité est l'exigence de qualité qui peut être mesurée comme le résultat d'interactions avec un système informatique. Cette exigence peut être remplie et l'utilisateur final sera satisfait si les objectifs prévus sont atteints efficacement avec l'utilisation de ressources appropriées.

Molich a déclaré en 2000 qu'un système convivial devrait remplir les cinq objectifs suivants: facile à apprendre, facile à retenir, efficace à utiliser, satisfaisant à utiliser et facile à comprendre.

Outre les différentes définitions de l'utilisabilité, il existe des normes et des modèles de qualité et des méthodes qui définissent l'utilisabilité sous la forme d'attributs et de sous-attributs tels que ISO-9126, ISO-9241-11, ISO-13407 et IEEE std. 610.12, etc.

Test de l'interface utilisateur et de la convivialité

Le test de l'interface utilisateur consiste à tester l'interface utilisateur graphique du logiciel. Les tests d'interface utilisateur garantissent que l'interface graphique fonctionne selon les exigences et testée en termes de couleur, d'alignement, de taille et d'autres propriétés.

D'autre part, les tests d'utilisabilité garantissent une bonne interface graphique conviviale qui peut être facilement manipulée. Les tests d'interface utilisateur peuvent être considérés comme une sous-partie des tests d'utilisabilité.

Test de sécurité

Les tests de sécurité consistent à tester un logiciel afin d'identifier les failles et les lacunes du point de vue de la sécurité et de la vulnérabilité. Voici les principaux aspects que les tests de sécurité doivent garantir -

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Le logiciel est protégé contre les vulnérabilités connues et inconnues
Les données du logiciel sont sécurisées
Le logiciel est conforme à toutes les réglementations de sécurité
Vérification et validation des entrées
Attaques d'insertion SQL
Défauts d'injection
Problèmes de gestion de session
Attaques de script intersite
La mémoire tampon déborde de vulnérabilités
Attaques par traversée de répertoire

Test de portabilité

Les tests de portabilité comprennent le test d'un logiciel dans le but de garantir sa réutilisabilité et de pouvoir également le déplacer d'un autre logiciel. Voici les stratégies qui peuvent être utilisées pour les tests de portabilité -

Transfert d'un logiciel installé d'un ordinateur à un autre.
Construire un exécutable (.exe) pour exécuter le logiciel sur différentes plates-formes.

Les tests de portabilité peuvent être considérés comme l'une des sous-parties des tests de système, car ce type de test comprend le test global d'un logiciel en ce qui concerne son utilisation dans différents environnements. Le matériel informatique, les systèmes d'exploitation et les navigateurs sont au cœur des tests de portabilité. Certaines des conditions préalables aux tests de portabilité sont les suivantes:

Les logiciels doivent être conçus et codés en tenant compte des exigences de portabilité.
Des tests unitaires ont été effectués sur les composants associés.
Des tests d'intégration ont été effectués.
L'environnement de test a été établi.