Quel est le processus de test de l'application Android et les problèmes courants ?

1. Tests automatisés

Les tests automatisés comprennent principalement plusieurs parties, les tests automatisés des fonctions de l'interface utilisateur, les tests automatisés des interfaces et d'autres tests automatisés spécialisés.

1.1 Tests automatisés des fonctions de l'interface utilisateur

Les tests automatisés des fonctions de l'interface utilisateur, également appelés tests automatisés, sont principalement des tests automatisés basés sur l'interface de l'interface utilisateur. Les clics sur les fonctions de l'interface utilisateur sont réalisés via des scripts, remplaçant les tests automatisés manuels.

L'avantage de ce test est de libérer efficacement la main-d'œuvre de test pour des tests de fonctions de fonctionnalités d'interface très répétitifs et d'utiliser l'exécution de scripts pour obtenir un retour rapide et efficace des fonctions.

Mais les inconvénients de ce type de test sont également évidents, notamment des coûts de maintenance élevés, des erreurs de jugement faciles, une compatibilité insuffisante, etc. Parce qu'elle est basée sur les opérations de l'interface, la stabilité de l'interface est devenue la plus grande contrainte pour la maintenance des scripts. Les interactions d'interface qui changent fréquemment signifient que les scripts de scénarios de test doivent être constamment mis à jour, occupant une grande quantité de ressources de test.

=

Des erreurs de jugement sont susceptibles de se produire principalement parce que l'identification basée sur les contrôles de l'interface utilisateur peut facilement conduire à un chargement lent ou anormal en raison des conditions du réseau, de la configuration de l'appareil, de l'environnement de test, etc., entraînant des jugements inexacts lors de l'exécution des cas de test, et affectent ainsi la précision du test. Une compatibilité insuffisante signifie principalement que l'exécution de scripts de test sur différents appareils, différents systèmes d'exploitation, différents environnements matériels, etc. entraînera des situations imprévisibles, conduisant à des résultats d'exécution de scénario de test inexacts.

Sur la base de la comparaison ci-dessus des avantages et des inconvénients, dans les tests automatisés de la fonction UI, nous implémentons principalement le test du chemin principal de l'APP et effectuons des tests automatisés de la fonction UI pour les modules fonctionnels qui nécessitent un grand nombre d'exécutions répétées, des vérifications répétées et la faible fréquence des modifications de l'interface utilisateur.

La nécessité d'un grand nombre d'exécutions et de vérifications répétées signifie que le taux d'utilisation après l'automatisation est élevé et que la fréquence des modifications de l'interface utilisateur est faible, ce qui signifie que les coûts de maintenance ultérieurs ne sont pas élevés pour nous, ces trois types. des cas d'utilisation sont la comparaison entrées-sorties. Pour la partie supérieure, nous accorderons la plus haute priorité à la pratique des tests automatisés des fonctions de l'interface utilisateur.

Au cours du processus de test d'automatisation des fonctions de l'interface utilisateur, les contrôles, les cas de test et les ensembles de tests pertinents peuvent être triés et gérés efficacement, et les travaux reproductibles peuvent être fusionnés en temps opportun pour réduire le gaspillage de ressources. Lorsque la fonction de l'interface utilisateur change, elle peut également être maintenue à moindre coût, réduisant ainsi les coûts de maintenance.

1.2 Tests automatisés d'interface

Dans la section tests automatisés des fonctions de l'interface utilisateur, nous avons mentionné les contraintes de l'automatisation : la stabilité. C'est précisément parce que l'interface de l'interface utilisateur est instable que le coût de l'automatisation des fonctions de l'interface utilisateur est relativement élevé. Nous pensons donc naturellement à la partie la plus stable et la plus propice à l'automatisation que les fonctions de l'interface utilisateur, à savoir l'interface.

L'interface d'une APP peut changer en raison des différentes demandes des chefs de produit à différentes étapes, mais l'interface derrière elle est généralement relativement stable, ce qui nous offre une bonne garantie d'effectuer des tests automatisés.

Nous devons préparer les interfaces appelées par l'APP, les trier et les résumer en fonction des modules fonctionnels, les hiérarchiser pour l'automatisation, comprendre la signification de chaque interface, la plage de valeurs des différents paramètres et produire diverses sorties pour différentes entrées Inventaire la situation et résumer les retours d’erreur ou d’exception pour garantir l’efficacité et l’exhaustivité du test d’interface.

Après le démarrage du test d'automatisation de l'interface, un document d'interface doit être conservé avec l'ingénieur de développement. À l'avenir, s'il y a une augmentation ou une diminution du nombre d'interfaces, ou des modifications associées aux interfaces existantes, l'ingénieur de test peut le savoir immédiatement. et effectuer des tests automatisés sur l'interface. Apporter les ajustements correspondants aux cas d'utilisation.

1.3 Autres tests automatisés spéciaux

En plus des deux catégories d'automatisation ci-dessus, nous pouvons également utiliser l'automatisation pour effectuer des tests spéciaux afin de nous aider à améliorer la qualité et l'efficacité de nos tests. Ici, nous devons réfléchir avec diligence dans notre travail de test quotidien, en réfléchissant aux tâches qui peuvent être réalisées grâce à l'automatisation, aux tests qui peuvent être automatisés pour améliorer l'efficacité des tests, aux points de fonction qui peuvent être automatisés pour réaliser une surveillance des tests à long terme, etc.

Par exemple, dans le projet dont je suis responsable, il y a une fonction Lors des tests manuels, nous ne pouvons la vérifier qu'avec un nombre limité de clics, et la fréquence des clics est faible. Cependant, grâce à des scripts, nous pouvons y parvenir. des tests plus rapides et plus efficaces pour les opérations de clic à long terme, nous pouvons utiliser l'automatisation pour y parvenir. Non seulement il peut être exécuté sur votre propre équipement de test, mais il peut également être exécuté sur différents appareils. Ce test automatisé est efficace et peut améliorer l’efficacité et la qualité des tests. Bien que ce test ne soit pas ajouté à l'ensemble des cas d'utilisation de l'automatisation des fonctions de l'interface utilisateur pour diverses raisons, dans la version actuelle, l'automatisation nous a effectivement apporté une aide très utile, et c'est ce que nous devons prôner.

En bref, nous pouvons utiliser divers outils et méthodes de test automatisés pour nous aider dans les tests, ce qui mérite d'être reconnu.

2. Tests de performance

Dans le système de test du projet dont je suis responsable, les tests de performance comprennent principalement trois dimensions de tests de performance, à savoir les tests de performance dans la dimension temporelle, les tests de performance dans la dimension ressources et les tests de maîtrise.

2.1 Dimension temporelle

Les tests de performances dans la dimension temporelle font principalement référence à la réponse temporelle des fonctionnalités fonctionnelles après une opération de clic. Nous connaissons mieux le temps de chargement du premier écran, le temps d’ouverture du saut de réponse après clic, etc.

Il existe de nombreuses façons d'effectuer des tests de performances dans la dimension temporelle. Vous pouvez utiliser des enregistrements d'écran pour calculer le temps, vous pouvez également utiliser des horodatages dans le programme pour calculer le temps, vous pouvez également utiliser des scripts tiers pour calculer le temps, ou vous-même. peut utiliser la reconnaissance d'image pour calculer le temps. Technologie pour calculer le temps, etc.

Pendant le processus de test, nous devons effectuer des recherches préalables sur l'outil en conjonction avec le projet lui-même. S'agit-il d'un test ponctuel ou nécessite-t-il des tests continus ? Doit-il être converti en un outil pour une durée ultérieure ? -utilisation à terme ? Doit-il être utilisé sur un seul appareil ? Il est nécessaire de considérer la compatibilité pour une utilisation dans différents environnements d'appareils, si l'outil est open source ou fournit une interface de données pour une intégration ultérieure avec la plateforme de test de l'équipe, etc.

2.2 Dimension des ressources

Les tests de performances dans la dimension des ressources font principalement référence à la consommation de diverses ressources système lors de l'utilisation de l'APP, notamment le processeur, la mémoire, l'alimentation, le trafic, etc.

Le choix des outils de test dépend des différents terminaux de test. Les dimensions qui doivent être surveillées pendant le test sont également déterminées en fonction du projet. Les méthodes de test spécifiques ne seront pas abordées ici.

Ce qu'il faut dire ici, c'est que les tests de performances dans la dimension des ressources peuvent effectuer deux parties du travail, l'une consiste à tester les performances pendant le processus de test et l'autre est la collecte de données de performances en ligne.

Les tests de performances pendant le processus de test peuvent être évalués en fonction des besoins de test de l'entreprise. Quels scénarios doivent être testés ? S'agit-il d'un test ponctuel pour la version actuelle ou d'un test comparatif pour chaque version suivante ? les données de performances de la machine locale ? , vous devez toujours collecter des données de performances sur plusieurs appareils, il vous suffit de tester cette application, vous devez toujours faire des tests comparatifs avec des produits concurrents, etc.

Sur cette base, évaluez s'il est nécessaire de mettre en œuvre des cas de test via des scripts automatisés pour une réutilisation ultérieure. Si des tests comparatifs longitudinaux ultérieurs avec des versions historiques sont nécessaires, il est nécessaire de garantir que l'environnement de test et l'équipement de test sont aussi cohérents que possible pour rendre les résultats des tests plus authentiques et fiables.

Un autre petit point à ajouter est que le traitement et le calcul des données de test peuvent être mis en œuvre via des scripts automatisés, économisant ainsi le coût des ressources informatiques humaines. Si nécessaire, vous pouvez également créer une plate-forme simple et stocker toutes les données de test sur la plate-forme pour une analyse et une référence ultérieures.

La collecte de données de performances en ligne nécessite que les ingénieurs de développement communiquent les données pertinentes pendant le processus de mise en œuvre de la fonction. Une fois la fonction publiée, les données en ligne doivent être récupérées, traitées et calculées pour découvrir d'éventuels problèmes. Avec la coopération des journaux de l'ingénieur de développement et des journaux des utilisateurs ayant rencontré des erreurs, nous pouvons localiser, analyser et résoudre les problèmes de performances associés.

2.3 Test de maîtrise

En tant qu'expérience utilisateur la plus intuitive, le test de maîtrise est également un incontournable pour de nombreux tests de performances. Il n'est pas nécessaire d'entrer ici dans les détails sur la méthode de réalisation des tests de maîtrise, mais il y a quelques points à noter :

Le premier est la manière dont nous planifions les cas d'utilisation pour le test de maîtrise, et le second est la manière dont nous planifions les cas d'utilisation du test de maîtrise. nous utilisons les données des résultats du test pour l'analyse et l'analyse après le test de maîtrise. La troisième amélioration concerne la manière dont nous devons surveiller la maîtrise des données en ligne après la publication de l'APP.

Concernant la conception des cas de tests de maîtrise, ils doivent être conçus en fonction des fonctions principales de l'APP et des parcours utilisateur courants. Il est préférable de disposer de données en ligne pour prendre en charge cette partie, plutôt que de simplement y penser. Les chemins de saut de la plupart des utilisateurs de l'APP obtenus à l'aide de données sont ce sur quoi nous devons nous concentrer. En outre, nous devons également prêter attention aux chemins sujets aux retards surveillés dans les données en ligne pendant le processus de test.

L'analyse et l'utilisation des données après le test de maîtrise, ainsi que le suivi des données de maîtrise en ligne, nécessitent une planification et un dépannage conjoints par les ingénieurs de test et les ingénieurs de développement. Cet article ne développera pas cela.

3. Test de stabilité

Concernant cette partie, vous pouvez partir des deux étapes de la phase de test avant la sortie de l'APP et de l'étape d'exploitation en ligne après la sortie, et effectuer le travail séparément.

Dans la phase de test, nous pouvons effectuer des tests de stabilité autour des tests Monkey et de la revue de code. Les équipes qualifiées peuvent également utiliser des outils d'analyse de code statique à ce stade. Au cours du processus de test Monkey, une attention particulière doit être accordée à l'équipement, à l'environnement et à la fréquence d'exécution des tests. Les problèmes découverts au cours du processus doivent également être analysés dans une certaine mesure, et une attention particulière doit être accordée aux pièces sujettes à des problèmes. . La procédure pas à pas du code peut être combinée avec des modules sujets aux pannes lors des tests fonctionnels pour effectuer des procédures pas à pas ciblées, promouvoir le développement et la programmation en binôme, et vérifier les problèmes possibles dans ces modules. En ce qui concerne l'analyse de code statique, les étudiants en développement doivent résoudre les problèmes analysés et développer de bonnes habitudes de codage pour éviter la fuite de problèmes associés.

En phase d'exploitation, nous pouvons effectuer des tests de stabilité autour du reporting et de l'analyse des données de crash du réseau externe. Cette partie repose davantage sur les ingénieurs de développement. Cependant, au cours de ce processus, les ingénieurs de test peuvent analyser les données rapportées et localiser certaines données de base des crashs, telles que les systèmes courants, les modèles, etc., pour améliorer et optimiser la stabilité du test sexuel quotidien. .

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!