Test noir / gris-boîte de l'API de repos et de l'interface utilisateur

Question

Nous choisissons le système d'acceptation automatisé pour commencer à utiliser (commutateur) dans notre société. Actuellement, la plupart des cas de test de backend sont rédigés par notre ancien testeur à Python et pour de nouveaux testeurs, il est difficile d'utiliser et de la maintenir; Pour UI, nous utilisons le Framework de robot .

J'aimerais utiliser quelque chose de standard afin que de nouveaux "testeurs typiques de la rue" puissent commencer à utiliser et pourtant, il devrait être assez flexible.

Dans mes tests précédents, les testeurs utilisaient Soapui ou même Apache Jmètre avec Groovy Scripting, mais pour une raison quelconque, les personnes de ma société actuelle ne l'aiment pas.

Nous envisageons Fitnesse ou framework robot.

Exigences:

• Il doit être utilisé pour les deux backend (API de repos, certains contrôles à base de DB) et les tests d'interface utilisateur
• Il devrait utiliser une langue simple afin que même les non-programmeurs / testeurs puissent comprendre les cas de test (les propriétaires de produits devraient pouvoir déterminer si tous les critères d'acceptation sont couverts)
• Il devrait soutenir l'intégration avec Jenkins
• Il devrait prendre en charge le versement des cas de test afin que, pour une version de produit particulière, nous puissions également consulter les cas de test pertinents. À l'heure actuelle, nous utilisons TestRail (Test Case Management SW); Donc, serait bien si cela l'intègre (au moins il est possible de le programmer afin d'envoyer des résultats de test) ou de le remplacer complètement

Je viens de jouer rapidement avec Fitessse et pour moi, la forme tabulaire semble assez laide. Aussi au premier abord, le doc n'est pas génial (je n'ai pas trouvé possible de "commandes", par exemple des assertions, de certaines boucles) et de la documentation pour par exemple. Le repos est encore pire (aucun).

Aussi je n'ai vu aucun appareil pour les chèques DB. Ainsi, à la fin, un développeur doit être impliqué pour programmer et maintenir des luminaires personnalisés, ce qui me semble pire que vous utilisez notre suite de test de python cultivée à domicile.

Des idées, une expérience?

merci, Radek

PS: J'ai également posé cette question dans le forum d'assurance qualité, mais il est beaucoup moins actif que Stackoverflow, désolé pour cette duplication.

Answer 1

Je ne peux pas parler à l'utilisation de Fitnesse, mais Framework de robot rencontre toutes les choses que vous demandez et Suite. Je le choisis pour mes projets pour les raisons suivantes:

1. Vous pouvez utiliser un seul outil (et donc un format de reporting unique) pour savon - et Rest -Based Services, validation de la base de données, Test de l'interface utilisateur Web , et même test d'application de bureau . Il peut également être utilisé pour l'intégration et les tests unitaires, bien qu'il existe souvent de meilleurs outils pour ce travail.
2. Vous pouvez utiliser des tests de robots pour implémenter des tests manuels à l'aide du dialogues bibliothèque ou sur mesure bibliothèque. J'ai constaté une vitesse d'accélération significative dans le débit de testeur lorsqu'elles ont exécuté des tests manuels écrits dans le robot que lors de l'exécution de tests similaires écrits dans Microsoft Word. Malheureusement, il n'y a pas beaucoup d'écriture sur le Web à propos de cette fonctionnalité puissante, mais vous pouvez obtenir le même type de rapports, de contrôle de la version, de marquage, etc. de tous vos tests d'acceptation, manuel et automatisé.
3. Si vous investissez dans la création d'une bonne bibliothèque de mots clés, les tests peuvent être facilement lisibles (et écrit!) par des non-testeurs
4. Il y a un Plugin robot pour Jenkins qui fait naviguer Résultats de test faciles
5. robot framework tests suites sont fichiers texte brut , donc ils peuvent être versés vers le côté de votre code.
6. La sortie de test est très simple à comprendre et à analyser le fichier XML. Il peut également générer sortie de style Xunit pour l'intégration avec autres outils. Le robot est également livré avec des outils permettant de convertir ce XML aux journaux et rapports respectueux des êtres humains. Le Interface de l'écoute facilite la capture ou la diffusion des résultats de test en direct .
7. Il existe un nombre croissant de Plugins d'outils et de rédaction qui fonctionnent avec robot, de sorte que les membres de votre équipe puissent utiliser les outils qu'ils sont les plus à l'aise.
8. robot est très extensible - Les bibliothèques de mots-clés peuvent être Écrit dans presque toutes les langues - nativement en python, ainsi que Java si vous courez avec Jython ou des langues .NET si vous courez avec IronPython. Et avec le Interface de la bibliothèque à distance , vous pouvez écrire des mots-clés dans n'importe quel langue pouvant ouvrir une prise et agir en tant que serveur.

Comme pour les appareils de données pour les tests de base de données, il existe un Generic bibliothèque de données basée sur Java , et un générique Library de base de données Python qui peut se connecter à n'importe quelle base de données commune . Il y a aussi une bibliothèque spécifiquement pour parler à MongoDB .

liée à la question que vous avez sur la question de la version, le robot a un très puissant Mécanisme de marquage que vous pourriez trouver utile. Par exemple, vous pouvez étiqueter tous les tests avec la version du produit avec lequel ils accomplissent. Ensuite, vous venez de tout vérifier, mais utilisez des robots Options de ligne de commande < / a> Pour sélectionner uniquement les tests marqués avec une version particulière. En tant qu'enfonge latéral du marquage, les rapports décomposent les statistiques de la passe / de l'échec par balise.

Le robot n'est pas un système de test parfait, mais c'est un très bon. Je dirais qu'il y a beaucoup de cadres de test aussi bons, mais je ne suis pas sûr qu'il y en ait objectivement mieux. Certainement pour les choses que vous avez énumérées qui sont importantes pour vous, Robot Framework fait tout ce dont vous avez besoin.

Answer 2

J'étais dans un scénario presque similaire plus tôt. Nous avons dû décider entre RF, Fitessse et IBM's Stax / Stax

Nous avons choisi le cadre de robot et cela a bien fonctionné.

1. Il doit être utilisé pour les deux backend (API de repos, certaines vérifications de base de données) et interface utilisateur Tests - pour le repos, RF's Demandes Bibliothèque avec différentes bibliothèques de DB peut être utilisée ensemble.
2. Il devrait utiliser une langue simple, donc même les programmeurs / testeurs peuvent comprendre les cas de test (les propriétaires de produits devraient pouvoir voir Si tous les critères d'acceptation sont couverts) - RF est destiné à faire précisément cela.
3. Il devrait soutenir l'intégration avec Jenkins - RF a un Jenkins Plugin
4. il devrait prendre en charge la version des cas de test afin que pour un particulier Version du produit Nous pouvons également consulter les cas de test pertinents en ce moment - RF Tags fonctionnera bien pour cette

Il existe un framework de robot API , donc son assez programmable selon les exigences d'intégration.