matrice de test MbUnit problèmes optimisation performace dans les tests automatisés ui

Question

Nous utilisons actuellement MBUnit pour les tests unitaires et les tests interface utilisateur. Pour le coût d'installation de tester l'interface utilisateur pour les axes de la matrice de test sont assez élevés (login, instance de navigateur, accédez à la page etc). Afin d'éviter la mise en place ces derniers pour chaque test, nous comptons en partie sur AssemblyFixture pour gérer certains d'entre eux.

Cependant, car il est impossible de filtrer certains cas où ils ne sont pas applicables à certaines combinaisons, il est impossible pour nous d'utiliser vraiment une telle optimisation. Donc, actuellement, nous faisons partie de la configuration par test cas, horriblement inefficace.

Nous pourrions si les déclarations à l'intérieur du code de test pour vérifier les combinaisons correctes mais nous ne veulent pas non plus. Il pollue le code de test.

Comment les gars faites-vous ces optimisations? ou la gestion de la matrice de test? Y at-il une meilleure pratique, dans un autre cadre de test?

Answer 1

Jusqu'à récemment, je l'ai toujours pensé UI Automation comme test de boîte noire où mes tests de l'interface utilisateur en voiture contre un site web se complète seul ou application. En conséquence, les tests exécutés sous la contrainte de l'exécution normale et sont soumis à une foule de questions d'environnement généraux.

J'ai récemment adopté la notion de tests de l'interface utilisateur « superficielle » et « profond » où chaque série de tests obtenus sous une configuration optimisée pour faciliter les différences environnementales et d'accélérer les choses. Par exemple, le contrôleur de connexion est permuté avec un mécanisme qui évite OAuth connexion en tête et est codé en dur avec les noms d'utilisateur fixes. Le catalogue de produits de base de données recherche et saute codé en dur avec quelques éléments fixes. Le backend de commerce électronique est permutée pour effectuer des opérations rapides qui acceptent / rejettent les transactions basées sur la carte de crédit et le montant.

Dans une configuration « superficielle » je peux effectuer des tests « en profondeur » contre la logique de l'interface utilisateur. Lorsque je passe à une configuration « profonde », elle ressemble à la production et je peux réaliser « superficielle » tester des composants totalement intégrés tels que connexion, catalogue de produits, recherche, etc.

Il faut une combinaison de stratégies de test.

Answer 2

Peut être ui-test automatisation meilleure l'article de -practices est utile pour vous. Il a quelques exemples comment améliorer les performances de l'automatisation tests ui par les connexions minimizig et les changements de contexte.