Tests d'applications mobiles : comment spécifier la stratégie de test et les normes de test ?

  • L'élaboration d'une stratégie de test de projet est une étape importante qui peut aider l'équipe de test à clarifier les objectifs des tests, la portée des tests, les méthodes de test, les ressources de test, les risques de test, etc., améliorant ainsi l'efficacité et la qualité des tests.
  • Cet article est une synthèse de quelques expériences et partages théoriques. Ce n’est pas tout à fait exact et tout le monde est invité à en discuter.

1. Contenu de la stratégie de test

  • La stratégie de test comprend les aspects suivants :
    • Niveau de test : fait référence aux tests de logiciels à différents niveaux selon les différentes étapes du processus de développement logiciel, tels que les tests unitaires, les tests d'intégration, les tests système, les tests d'acceptation, etc.
    • Rôles et responsabilités : Cela fait référence à la nécessité de définir clairement chaque rôle et les responsabilités de ce rôle dans la stratégie de test. Par exemple, les chefs de projet, les chefs d'équipe de test, les ingénieurs de test, etc.
    • Exigences environnementales : fait référence à la description de l'environnement système requis pour les tests, y compris les logiciels, le matériel, l'environnement réseau, etc.
    • Analyse des risques : fait référence à l'identification et à l'évaluation de divers risques pouvant affecter la qualité et la progression du test, et à la formulation des contre-mesures correspondantes.
    • Progression des tests : fait référence à la formulation d'un calendrier de tests raisonnable basé sur le plan du projet et la disposition des ressources, ainsi qu'au suivi et au contrôle de l'exécution des activités de test.

2. Le processus de spécification des stratégies de test

  • Le processus général d’élaboration d’une stratégie de test est le suivant :
    • Analyser le produit : Comprendre les caractéristiques, les fonctions, les besoins, les utilisateurs, le marché, etc. du produit pour mieux le comprendre.
    • Développer des stratégies de test : sur la base de l'analyse du produit, créer des stratégies de test pour différents niveaux de test, déterminer l'orientation et les difficultés des tests, la profondeur et l'étendue des tests, les méthodes et technologies de test, etc.
    • Objectifs de test spécifiques : Répertorier toutes les fonctionnalités logicielles (fonction/performance/GUI) qui peuvent devoir être testées, et définir les indicateurs de qualité et les critères d'acceptation correspondants.
    • Définir des normes de test : Développer des normes ou des règles pour juger divers indicateurs au cours du processus de test, tels que le niveau de défaut, l'état du défaut, les conditions de clôture des défauts, etc.
    • Disposition des ressources : sur la base du plan du projet et de la situation des ressources, déterminer la quantité de main-d'œuvre, d'équipement et de matériaux à utiliser dans le projet, et répartir raisonnablement les tâches et les responsabilités.
    • Environnement de test : décrivez l'environnement système requis pour les tests, y compris les logiciels, le matériel, l'environnement réseau, etc., et assurez-vous qu'il est cohérent ou proche de l'environnement utilisateur réel.

3. Élaborer des normes de test (portée des tests, normes)

  • L'élaboration de normes de test constitue une partie importante de la stratégie de test.
  • La portée des tests et les normes partagées ci-dessous proviennent de l'expérience résumée dans mon travail.
  • Cependant, les caractéristiques de chaque projet sont différentes et les normes et la portée les plus appropriées doivent être formulées en fonction des caractéristiques du projet.
  1. test de nouveaux produits
    • Ce type de produit est le premier à être lancé en ligne. Théoriquement, tous les codes pour ce type de produit sont neufs et non testés, donc la norme de test est la suivante : toutes les fonctions du produit réussissent 100 % du processus aller et 20 % du processus inverse.
  2. Tests d'itération de version
    • La différence entre ce type de test et les tests de nouveaux produits est que le produit dispose déjà d'une version en ligne et que cette version est développée sur la base de la version précédente. Par conséquent, le test se concentre sur le code nouvellement ajouté et sur les modifications apportées au code d'origine. Et une attention particulière doit être accordée à la couverture de la situation d'installation, de sorte que la norme de test est la suivante : le nouveau code et le code affecté réussissent 100 % du processus aller et 20 % du processus inverse. Et les fonctions de base du produit doivent également garantir qu'il n'y a pas d'anomalies dans le processus de transfert, comme les fonctions de connexion et les fonctions de paiement.
  3. Test de correction de bugs de la même version
    • Parfois, il est nécessaire de lancer une version de la même version qui corrige des crashs ou des bugs après la collecte de données sans ajouter de nouvelles fonctions métiers. Pour ce type de test, s'il s'agit de corriger un bug visible, vous devez vérifier si le bug a été corrigé. S'il s'agit d'un bug invisible, il s'agit d'un test normal des fonctions principales du produit. Par conséquent, la norme de test est la suivante : vérifier que le bug a été corrigé (lorsque le bug est visible) et que les fonctions pertinentes se trouvent à proximité de l'emplacement où le bug s'est produit. Il n'y a aucune anomalie dans le processus de progression des fonctions essentielles du produit.
  • Remarque : toutes les normes de test sont théoriquement : aucun bug dans la plage de test spécifiée. Cependant, il existe des bogues dans le travail de production réel qui ne peuvent pas être corrigés avant la date limite du projet, ou le coût de la correction des bogues est supérieur aux avantages apportés par la correction des bogues. Par conséquent, lorsque nous rencontrons cette situation, nous évaluerons en collaboration avec la planification et le développement pour déterminer si le bug doit être corrigé. Si les trois parties réussissent, il peut y avoir des cas où les bugs ne sont pas complètement corrigés et le test se terminera et le produit sera lancé.

—————————————————————————————————————————————————— ——————————————————————————————
Je suis mon propre blog. Non. [Compétences essentielles pour les tests de logiciels] téléchargera les tests liés des informations de temps en temps. Vous pouvez cliquer sur le code QR sous l'article pour l'obtenir ~
Insérer la description de l'image ici

Je suppose que tu aimes

Origine blog.csdn.net/weixin_40883833/article/details/133050489
conseillé
Classement