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

โšก Rรฉsumรฉ intelligent

Les tests d'application valident un produit logiciel dans son intรฉgralitรฉ plutรดt qu'une seule unitรฉ, en couvrant l'interface, les fonctionnalitรฉs, la base de donnรฉes et le comportement en charge. Cette page explique le cycle de vie en quatre รฉtapes, les trois mรฉthodologies de test, la planification des tests, les outils, les indicateurs et les bonnes pratiques spรฉcifiques aux applications mobiles.

  • (I.e. Dรฉfinition: Les tests d'application examinent l'application complรจte afin de dรฉtecter les erreurs avant sa mise en production.
  • ๐Ÿชœ Quatre รฉtapes : Planifiez ร  partir des exigences, รฉlaborez des cas d'utilisation et des scripts, exรฉcutez des tests fonctionnels, puis exรฉcutez des tests de charge.
  • ๐Ÿงฉ Trois segments : Les applications web, de bureau et mobiles requiรจrent chacune une combinaison diffรฉrente de types de tests.
  • โฌ› Mรฉthodologies : Les tests en boรฎte noire, en boรฎte blanche et en boรฎte grise ciblent respectivement le comportement, le code et la structure.
  • ๐Ÿšช Critรจres d'entrรฉe et de sortie : Les conditions convenues dรฉterminent le dรฉbut et la fin des essais.
  • ๐Ÿ“ˆ Mรฉtrique: La densitรฉ des dรฉfauts, la couverture des tests et les fuites de dรฉfauts indiquent si les tests fonctionnent correctement.
  • ๐Ÿ“ฑ Objectif mobile : La fragmentation, les chemins d'installation et le nombre limitรฉ d'appareils physiques dominent les tests mobiles.

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

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

Les tests d'applications sont dรฉfinis comme un type de test de logiciel effectuรฉ via des scripts dans le but de dรฉtecter des erreurs dans le logiciel. Il traite des tests pour lโ€™ensemble de lโ€™application.

Il contribue ร  amรฉliorer la qualitรฉ de vos applications tout en rรฉduisant les coรปts, en maximisant le retour sur investissement et en รฉconomisant du temps de dรฉveloppement.

En gรฉnie logiciel, les tests d'applications peuvent รชtre effectuรฉs dans diverses catรฉgories telles que l'interface graphique, les fonctionnalitรฉs, la base de donnรฉes (backend), les tests de charge, etc.

Pour les tests d'applications, les cycles de vie des tests impliquent diffรฉrentes phases, notamment l'analyse des exigences, la planification des tests, l'analyse des tests, la conception des tests, l'exรฉcution des tests et le rapport de bogues, etc.

Ces phases se rรฉsolvent en un cycle de vie court et rรฉpรฉtable que chaque application suit.

Comment tester une application ?

Les applications et produits logiciels prรฉsentent un certain nombre de variations en termes de fonctionnalitรฉs qu'ils prennent en charge ainsi que de processus qu'ils mettent en ล“uvre. Ainsi, les tests dโ€™application garantissent quโ€™un programme ou une application particulier fonctionne correctement.

Tester une application

Un cycle de vie pour les tests dโ€™applications comprend quatre รฉtapes.

  • ร‰tape 1) Concevoir des plans de tests en fonction des exigences de l'application
  • ร‰tape 2) Dรฉvelopper des cas de tests manuels et des scripts de tests automatisรฉs
  • ร‰tape 3) Exรฉcuter des tests fonctionnels pour valider les exigences de l'application
  • ร‰tape 4) Exรฉcuter des tests de charge et optimiser les performances des applications

Le type de tests exรฉcutรฉs dรฉpend du type dโ€™application testรฉe. Les tests dโ€™applications sont classรฉs en 3 segments.

  • Tests d'applications Web
  • Tests d'applications de bureau
  • Test d'application mobile
Test d'applications Types de tests exรฉcutรฉs
  • Test d'applications Web
  • Fonctionnel et Test de performance
  • Test multi-navigateurs
  • Tests de charge et de contrainte
  • Tests de rรฉgression et de conformitรฉ
  • User Acceptance Test
  • Test bรชta
  • Tests exploratoires et de fumรฉe
  • Prise en charge multilingue et tests de compatibilitรฉ
  • Tests d'applications de bureau
  • Test de l'interface utilisateur
  • Tests d'utilisabilitรฉ
  • Test de performance
  • Tests de compatibilitรฉ (logiciel/matรฉriel)
  • Essais fonctionnels
  • Test de sรฉcuritรฉ
  • Test d'application mobile
  • Test de l'interface utilisateur
  • Tests basรฉs sur des rรจgles
  • Les tests de rรฉgression
  • Essais fonctionnels
  • Test de sรฉcuritรฉ

Comparaison des tests d'applications Web, de bureau et mobiles

Ces trois segments partagent un cycle de vie similaire, mais diffรจrent considรฉrablement quant aux dรฉfaillances qu'ils subissent. Identifier les zones ร  risque permet de cibler les investissements en tests.

Point de diffรฉrence Web Bureau Mobile
Fonctionne sur Un navigateur sur un rรฉseau Une machine installรฉe Un tรฉlรฉphone portable ou une tablette
Variable principale Navigateur et version Operasystรจme et matรฉriel de test Appareil, version du systรจme d'exploitation et taille de l'รฉcran
Dรฉpendance au rรฉseau toujours connectรฉ Souvent hors ligne Intermittent, et doit survivre ร  la perte
Le plus grand risque Rendu et chargement multiplateformes Installation et compatibilitรฉ Fragmentation entre les appareils
Gestion des interruptions Rarement pertinent Rarement pertinent Appels, notifications et batterie faible
Chemin de mise ร  jour Cรดtรฉ serveur, instantanรฉ pour tous L'utilisateur installe un correctif Examen de l'App Store, dรฉploiement progressif

Le mobile prรฉsente le plus grand nombre de variables incontrรดlables, c'est pourquoi il est traitรฉ sรฉparรฉment plus loin sur cette page.

Mรฉthodologies de tests dโ€™applications

La mรฉthodologie de test est la mรฉthode structurรฉe permettant de garantir qu'une application logicielle est testรฉe de maniรจre exhaustive. Une mรฉthodologie de test dรฉsorganisรฉe et inadรฉquate peut engendrer un produit instable.

Il existe trois maniรจres d'effectuer les tests.

  • Noir Box Tests
  • Blanc Box Tests
  • Gris Box Tests

Noir Box Tests

Noir Box Tests technique est couramment utilisรฉe pour les tests Tests fonctionnels, Tests non fonctionnels, et les tests de rรฉgression. Dans les tests en boรฎte noire, les stratรฉgies utilisรฉes sont

  • Tests de classe d'รฉquivalence
  • Test de valeur limite
  • Table de dรฉcision
  • Tableaux de transition d'รฉtat

Blanc Box Tests

Test de la boรฎte blanche Il est gรฉnรฉralement utilisรฉ pour tester le code logiciel afin de vรฉrifier les failles de sรฉcuritรฉ internes, les chemins d'accรจs dรฉfectueux ou mal structurรฉs, le bon fonctionnement des boucles conditionnelles, etc. Dans les tests en boรฎte blanche, les stratรฉgies utilisรฉes sont les suivantes :

  • Code Analyse de la couverture
  • Couverture de chemin

Gris Box Tests

Cette technique de test est une combinaison de Black Box Des tests, ainsi que des tests en boรฎte blanche, sont effectuรฉs pour dรฉterminerโ€ฆ Dรฉfauts basรฉ sur une structure ou une utilisation dโ€™application inappropriรฉe.

Plan de test pour les tests d'applications

Le Plan de test Le document est dรฉrivรฉ du produit Description, la spรฉcification des exigences logicielles SRS ou les documents de cas d'utilisation. Lโ€™objectif du test est de savoir quoi tester, comment tester, quand tester et qui testera. Le document du plan de test est utilisรฉ comme support de communication entre l'รฉquipe de test et les responsables de test.

Un plan de test standard pour les tests d'applications doit dรฉfinir les fonctionnalitรฉs suivantes :

  • Dรฉfinir la portรฉe des tests
  • Dรฉfinir l'objectif des tests
  • Approche pour lโ€™activitรฉ de test
  • Calendrier des tests
  • Punaise tracroi et reportage

Critรจres d'entrรฉe et de sortie pour les tests d'application

Le plan de test prรฉconise l'รฉtablissement de critรจres d'entrรฉe et de sortie formels, mais il est important de les prรฉciser. Sans cela, une phase de test risque soit de commencer avec une version instable, soit de se prolonger sans objectif final dรฉfini.

Les critรจres d'entrรฉe Cette condition doit รชtre remplie avant le dรฉbut de l'exรฉcution.

  • Les exigences et le SRS sont examinรฉs et validรฉs.
  • Le plan de test et les cas de test sont rรฉdigรฉs et approuvรฉs.
  • La version est dรฉployรฉe dans un environnement de test stable et rรฉussit un test de non-rรฉgression.
  • Les donnรฉes de test et les comptes ou appareils requis sont disponibles.
  • Un dรฉfaut tracL'outil King est configurรฉ et l'รฉquipe y a accรจs.

Critรจre de sortie dรฉmontrer que la phase a atteint son objectif.

  • Tous les cas de test prรฉvus sont exรฉcutรฉs et les rรฉsultats enregistrรฉs.
  • Aucun dรฉfaut critique ou de haute gravitรฉ ne reste ouvert.
  • La couverture convenue par rapport aux exigences est atteinte.
  • Les dรฉfauts mineurs restants sont documentรฉs et acceptรฉs par l'entreprise.
  • Le rapport de synthรจse des tests est validรฉ.

Outils de test d'applications

Il existe diffรฉrents outils de test pour les tests d'applications. La sรฉlection des outils dรฉpend du type de test que vous souhaitez effectuer. Pour diffรฉrentes plates-formes, diffรฉrents outils sont recommandรฉs. Les outils de test d'applications garantissent les performances, la convivialitรฉ et la fonctionnalitรฉ des applications sur une variรฉtรฉ d'appareils.

En voici quelques-uns.

Remarque : IBM Rational Robot, longtemps commercialisรฉ aux cรดtรฉs de RFT, a รฉtรฉ retirรฉ du marchรฉ. Rational Functional Tester est actuellement le produit. IBM L'offre รฉtant limitรฉe, les nouveaux projets ne doivent pas รชtre conรงus autour de Robot.

Indicateurs clรฉs pour les tests d'application

L'exรฉcution des tests atteste de l'activitรฉ, mais pas de l'efficacitรฉ. Un petit nombre d'indicateurs permet de vรฉrifier si les tests dรฉtectent effectivement des dรฉfauts et si l'application converge vers une qualitรฉ de version acceptable.

  • Couverture de test: La proportion d'exigences ayant au moins un cas de test associรฉ. Une faible couverture signifie des comportements non testรฉs, quel que soit le taux de rรฉussite.
  • Densitรฉ des dรฉfauts : Le nombre de dรฉfauts est classรฉ par ordre de grandeur, gรฉnรฉralement par millier de lignes de code ou par module. Cela permet d'identifier les composants qui nรฉcessitent une refonte plutรดt que des tests supplรฉmentaires.
  • Dรฉfaut de fuite : Dรฉfauts dรฉtectรฉs en production divisรฉs par le nombre total de dรฉfauts constatรฉs. Une augmentation des fuites est le signe le plus clair que les tests prรฉalables ร  la mise en production sont insuffisants.
  • Efficacitรฉ d'รฉlimination des dรฉfauts : Pourcentage de dรฉfauts dรฉtectรฉs avant la mise en production par rapport au total des dรฉfauts. Un taux supรฉrieur ร  90 % est un objectif courant.
  • Taux d'exรฉcution des tests : Des affaires sont intentรฉes contre des affaires prรฉvues, tracUn systรจme de rรฉglage par cycle permet de dรฉtecter les glissements dรจs le dรฉbut, et non ร  la porte de sortie.

TracIl faut privilรฉgier la tendance plutรดt qu'une mesure isolรฉe. Un cycle pris isolรฉment est peu rรฉvรฉlateur.

Test des meilleures pratiques pour les tests d'applications

Choisir la bonne stratรฉgie pour les tests dโ€™applications est un moyen garanti de dรฉtecter les dรฉfauts de lโ€™application. Il devient donc extrรชmement important que lโ€™รฉquipe dโ€™assurance qualitรฉ suive un ensemble de processus standard pour dรฉtecter plus dโ€™erreurs et en moins de temps.

Pour les tests d'applications, certaines des meilleures pratiques incluent

  • Dรฉfinir les spรฉcifications fonctionnelles
  • Revvues et inspections
  • Critรจres formels dโ€™entrรฉe et de sortie
  • Variations des tests fonctionnels
  • Tests multiplateformes
  • Exรฉcution de tests automatisรฉs

Dรฉfis des tests dโ€™applications

Lors du test d'une application, un testeur peut rencontrer de nombreux dรฉfis.

  • Problรจmes identifiรฉs uniquement lorsque l'utilisateur appelle
  • Incapacitรฉ ร  anticiper lโ€™impact du changement
  • Aucune visibilitรฉ sur les erreurs applicatives et opรฉrationnelles
  • Long

Test d'application mobile

Comme les tests d'applications Web, Mobile Les tests d'applications reposent รฉgalement sur la mรชme stratรฉgie et la mรชme mรฉthodologie. La diffรฉrence peut rรฉsider dans les outils utilisรฉs ; voici quelques outils couramment utilisรฉs pour les tests d'applications mobiles : Appium, TestComplete, Robotium et Espresso.

Les types d'applications mobiles sont classรฉs en trois sections.

  • Application Web - Les utilisateurs y accรจdent via un rรฉseau comme Internet ou un intranet
  • Application native - Elle est dรฉveloppรฉe pour une plate-forme spรฉcifique et installรฉe sur un appareil informatique
  • Application hybride : elle combine des รฉlรฉments du Web et des applications natives, comme par exemple Facebook.

Pour la plupart des plateformes mobiles, vous pouvez utiliser de simples CSS, HTML, JS, etc.

Exemples de cas de test pour les tests d'applications mobiles

Une stratรฉgie complรจte d'application de test mobile comprend une infrastructure d'appareils et de rรฉseau, une sรฉlection d'appareils cibles et une combinaison efficace d'outils de test manuels et automatisรฉs pour couvrir ร  la fois tests non fonctionnels et fonctionnels.

Pour les applications mobiles, les รฉlรฉments ร  tester sont

  • Installation
  • OTA
  • Wi-Fi
  • Cรขble de donnรฉes
  • Bluetooth
  • Dรฉsinstallation
  • Logo de l'application
  • Splash
  • Peu de mรฉmoire
  • Commentaires visuels
  • Demande de sortie
  • Dรฉmarrage/redรฉmarrage de l'application

Dรฉfis des tests mobiles

Avec l'augmentation du nombre d'utilisateurs et d'appareils mobiles, tester une application mobile devient de plus en plus complexe. Tester une application mobile diffรจre considรฉrablement de tester une application web pour ordinateur. Les dรฉfis courants rencontrรฉs lors des tests mobiles sont :

  • Couverture complรจte des tests
  • Gestion de la fragmentation (diffรฉrentes versions du systรจme d'exploitation, processeur, mรฉmoire)
  • Absence de plan de test
  • Pression temporelle
  • Manque d'appareils physiques
  • Diversitรฉ dans la plateforme et le systรจme d'exploitation

FAQ

Les tests systรจme vรฉrifient la conformitรฉ de l'application intรฉgrรฉe aux spรฉcifications. Les tests applicatifs consistent ร  tester l'application finale au niveau de l'interface, des fonctionnalitรฉs, de la base de donnรฉes et de la charge, et se poursuivent souvent jusqu'ร  la phase de validation.

Analysez les appareils utilisรฉs par les utilisateurs rรฉels, et non les modรจles les plus rรฉcents. Une approche courante consiste ร  se concentrer sur les dix appareils physiques les plus utilisรฉs, tout en couvrant un plus large รฉventail de systรจmes d'exploitation et de combinaisons d'รฉcrans grรขce ร  un parc d'appareils cloud.

Les deux. Automatisez les tests de rรฉgression stable, les tests multi-navigateurs et les scรฉnarios de charge qui se rรฉpรจtent ร  chaque cycle. Conservez les tests exploratoires, d'utilisabilitรฉ et ponctuels manuels, car leur automatisation coรปte plus cher que les dรฉfauts qu'ils permettraient de dรฉtecter.

Oui. Fournissez le cahier des charges fonctionnel ou les rรฉcits utilisateurs, et un assistant IA gรฉnรจre des scรฉnarios positifs, nรฉgatifs et limites avec les rรฉsultats attendus. Un responsable des tests les vรฉrifie par rapport ร  la liste des exigences avant leur intรฉgration au plan de test.

En partie. Les localisateurs autorรฉparateurs rรฉidentifient les รฉlรฉments lorsque l'interface change, et l'IA peut regrouper les dรฉfaillances pour distinguer les vรฉritables dรฉfauts des anomalies temporelles. Les causes profondes, comme les temps d'attente non respectรฉs, nรฉcessitent toujours l'intervention d'un dรฉveloppeur.

Rรฉsumez cet article avec :