technologie approximative: QATOK

Le 11 décembre, environ Tech aura lieu au bureau d'Odnoklassniki à Saint-Pétersbourg: QATOK - un événement dédié à l'assurance qualité dans les projets informatiques et tout ce qui s'y rapporte. Avec des collègues de OK, Mail.ru et Qameta Software, nous parlerons des mesures de performances dans les applications Android, discuterons de la visualisation de la couverture des autotests, verrons pourquoi PageObject est déjà obsolète et qu'il est temps de le remplacer.

Inscrivez-vous sur ok.tech: QATOK

Si vous souhaitez voir les descriptions des rapports et le calendrier, nous vous invitons à cat.

Réinventer PageObject - Anatoly Ostapenko, Mail.Ru

Dans les grandes applications à page unique, l'utilisation du modèle PageObject est gênée par le fait que vous devez décrire les localisateurs et les actions avec un très grand nombre d'éléments sur une page dans une classe. De ce fait, l'écriture des autotests ralentit et la qualité du code en souffre. Je vais parler de la manière dont nous avons abandonné le modèle classique de PageObject dans les tests automatiques de l'interface utilisateur et ce que nous avons proposé en retour. À propos de la façon dont la nouvelle solution est liée à la génération de code, comment elle aide à réaliser un typage strict des tests et comment elle accélère leur écriture.

Mesures de performances dans l'application Android - Anton Smolyanin, OK

Les camarades de classe sont un énorme service avec plus de 70 millions d'utilisateurs. Si nous parlons d'appareils mobiles, la majorité utilise OK.RU sur les smartphones fonctionnant sous Android. Pour cette raison, nous prenons très au sérieux les performances de notre application Android. Dans le rapport, je vais expliquer pourquoi, en principe, traiter les mesures, afficher des graphiques d'accélération, partager l'historique de la façon dont les sections lentes de l'application ont été trouvées et corrigées, et prêter également attention aux recommandations de Google à ce sujet.
Ensuite, nous comprendrons les outils, commencerons par ce que vous pouvez voir dans Android Studio, puis nous discuterons des utilitaires de la console. Après cela, je partagerai des astuces de vie sur la façon de configurer l'application pour augmenter la précision des mesures et éventuellement intégrer tout dans le processus de test. À la fin du rapport, je parlerai des problèmes qui ont dû être résolus sur cette voie.

Visualisation de la couverture de l'autotest - Artem Eroshenko, Qameta Software

Les méthodes modernes de mesure de la couverture ne sont bonnes que pour le développement. Dans le même temps, la quantité d'informations utiles provenant des rapports de couverture est extrêmement faible. D'une part, toutes les lignes de code n'ont pas été impliquées au cours des tests. En revanche, la seule information importante est le pourcentage de couverture. De plus, c'est intéressant non pas la valeur absolue, mais le delta avec le précédent. Artyom présentera quelques solutions simples qui vous permettront d'évaluer la couverture des tests écrits par l'automatisation des tests.

1. Tests API. Il y a un fanfaron, lors de son exécution nous collectons également un fanfaron. Nous considérons le revêtement comme un diff de deux swagers. Vous pouvez voir ce qui est couvert, ce qui ne l'est pas et quelles données.
2. Tests Web. Lors de l'exécution des tests, nous collectons des informations sur les éléments, les pages et les actions. En conséquence, nous obtenons le format suivant:
   
   1. La page
   2. Les éléments
   3. Actions
   4. Tests.

Tout cela est envoyé au plugin. Sur la page, nous dessinons les éléments qui ont été affectés lors des tests. Plus d'informations supplémentaires: une liste de tests sur la page vidéo.

Vous pouvez ainsi répondre très rapidement aux questions suivantes:

1. Ce qui est couvert et ce qui ne l'est pas.
2. Comment couvert (juste cliqué ou vérifié le texte).
3. Quels tests passent par cette page.
4. Quels éléments sont les plus couramment utilisés. En général, il est préférable d'éviter cela car il s'agit d'un point de défaillance potentiel.
5. Pointez le test, voir la vidéo de Selenoid.
6. Connecté à Selenium. Peut être facilement complété pour Puppeteer et pour toute autre chose. Il sera utile de comprendre ce qui est vérifié et pourquoi.

Calendrier du rapport:

19:00 - 19:40 PageObject obsolète, il est temps de trouver un remplaçant - Anatoly Ostapenko, Mail.Ru
19:40 - 20:30 Mesures des performances dans l'application Android - Anton Smolyanin, OK
20h30 - 21h00 Pause café, pizza, chat, réseautage
21:00 - 21:40 Visualisation de la couverture des autotests - Artem Eroshenko, Qameta Software

Nous attendons tous ceux qui souhaitent discuter avec des experts dans le domaine de l'assurance qualité lors de la réunion du 11 décembre à leur bureau de Saint-Pétersbourg.

Venez, ce sera intéressant et utile!

Inscrivez-vous sur ok.tech: QATOK