PyUseCase

PyUseCase est un logiciel de test de GUI pour PyGTK.
tests de GUI maintenable avec une utilisation Recorder Case
Enregistrement de l'intention plutôt que la mécanique
Le moyen le plus naturel pour créer des tests via une interface utilisateur est simplement de mener à bien les actions que vous souhaitez exécuter et avoir un outil qui peut les enregistrer, puis les reproduire plus tard. Ceci est un moyen simple et rapide de créer des tests de l'interface graphique et il existe de nombreux outils qui font cela.
La plupart des outils coupler les essais étroitement à l'interface graphique
Les problèmes commencent lorsque vous avez quelques tests et les modifications de l'interface graphique. L'enregistrement peut être un excellent moyen de créer des tests, mais il est une manière terrible de maintenir un grand nombre d'entre eux. Il est source d'erreurs, frustrant et beaucoup de temps une fois que vous avez quelques tests. La première génération d'outils enregistré positions de pixels et a cassé dès que vous avez changé votre résolution d'écran. Outils L'offre d'aujourd'hui en termes de la mécanique de l'interface graphique: trouver une table avec un nom et cliquez dans la troisième colonne de la quatrième ligne. Ils peuvent survivre aux changements d'écran et des réaménagements mineurs de l'interface graphique, mais pas grand chose d'autre. Les scripts enregistrés sont denses et ne transmettent pas le but de l'essai, et sont un livre fermé à toutes les personnes non-techniques (et parfois à tout le monde sauf l'auteur de l'outil).
Le problème est essentiellement une question de couplage. Les essais et de l'interface graphique sont étroitement couplés les uns aux autres et ne peuvent pas varier confortablement indépendamment l'un de l'autre. Ce point est bien faite par Robert C. Martin dans son blog ici et sa conclusion est que le test de l'interface graphique est intrinsèquement fragile et vous devriez faire aussi peu de ce que vous pouvez sortir avec.
Cela semble plutôt défaitiste bien. Il ya une énorme valeur à être en mesure de démontrer ce que vos tests font à un utilisateur du système. Si les tests de contourner l'interface utilisateur, puis ce processus exige une bonne quantité de compétences techniques et beaucoup de confiance de la part de votre utilisateur. Et de toute façon, les développeurs de logiciels à résoudre des problèmes de couplage tout le temps. La réponse est, comme d'habitude, d'introduire un autre niveau d'indirection.
Briser le couplage avec une carte d'interface
Les gens d'affaires et les utilisateurs travaillent généralement dans des cas d'utilisation. Ce sont des descriptions de haut niveau d'une séquence d'actions dans une langue qu'ils comprennent:-à-dire celle du domaine. L'idée d'une "utilisation Recorder Case" est donc un outil qui permet d'enregistrer et de rejouer ces séquences et ainsi capturer l'esprit de l'utilisateur. Cela permettra alors compréhension accrue, moins de dépendance sur la forme exacte de l'interface graphique et un réglage plus facile de tests existants sans recourir à nouveau en cliquant sur tous les boutons.
Le mécanisme de base est que nous maintenons une correspondance entre les actions qui peuvent actuellement être réalisées avec notre interface graphique et les états dans cette langue de domaine. les changements de l'interface graphique signifient alors que cette cartographie unique doit être mis à jour, mais les tests peuvent rester intacte, continuer à décrire ce qui doit être fait sur le plan conceptuel. Cette cartographie prend la forme d'un fichier externe au PyUseCase 3.0 et la prochaine JUseCase 3.0, tandis que dans les anciennes versions, il prend la forme d'instrumentation dans le code de l'application.
Vérification du comportement par l'intermédiaire des journaux et texttest
Donc, notre cas d'utilisation enregistreur peut enregistrer et rejouer usecases pour nous. Mais comment pouvons-nous vérifions que ce que nous voyons à l'écran est correct? La plupart des outils GUI font en permettant le script de test pour contenir «affirmations», qui ressemblent un peu de widget, et vérifier que certains biens de celui-ci est égale à une valeur codée en dur. Cela crée encore plus de dépendance sur la mise en page d'interface actuelle et ne peut pas être "enregistré" en aucune façon naturelle, mais doit être programmé après le fait. Pas de "usecase" serait naturellement contenir cette information: si elle l'a fait se transformerait en un script de test.
Cette discussion est pas sur le site texttest pour rien. Si nous ne pouvons obtenir notre application pour produire un journal de ce que l'interface graphique ressemble nous pouvons vérifier ce qu'il fait en surveillant le contenu de ce journal à l'aide texttest. PyUseCase 3.0 fait pour vous: il génère un type journal ASCII-art de l'apparition d'interface actuelle et surveille modifications. L'application peut compléter avec sa propre exploitation forestière comme il le souhaite. Avec d'autres enregistreurs de cas d'utilisation de l'application a besoin de construire son propre journal à cet effet pour le moment.
Synchronisation des tests par instrumentation de code
Presque tous les efforts de test GUI sont en proie à des problèmes avec les assurant que le script attend assez longtemps avant de continuer quand quelque chose se passe en arrière-plan. Les solutions vont de façons arcanes d'attendre un certain widget à avoir une certaine apparence (encore plus de dépendances sur GUI-mécanique) pour "sommeil" déclarations généreusement éparpillés autour. Quels échouer lorsque le système est chargé et provoquent les tests à exécuter beaucoup plus lentement qu'ils ne le feraient autrement. Toute personne sans connaissance intime du code est mal équipé pour résoudre ces problèmes, mais le faire est une partie vitale de l'écriture de tests.
De cas d'utilisation Enregistreurs introduisent le concept d'un "événement d'application". Ceci est essentiellement une certaine instrumentation dans le code qui indique au cas d'utilisation enregistreur qui est arrivé quelque chose qui doit être attendu, permettant ainsi l'enregistreur pour enregistrer et rejouer attend ainsi que des clics. Ceux-ci sont décrits plus en détail ici.
l'enregistrement de macros ainsi que des tests
Haut niveau, "usecases" facilement manipulables sont utiles pour d'autres choses que des tests. Ils sont également très utile pour les utilisateurs du système qui peuvent créer leurs propres macros pour les séquences d'actions qu'ils effectuent fréquemment.
Ils sont connus comme des «raccourcis GUI» ici. Un cas d'utilisation enregistreur permet généralement une application de demander un "toolbar" de ce qui contient des contrôles pour l'enregistrement et les rejouer qui peuvent être insérés dans l'interface graphique de l'application comme vous le souhaitez. En plus de permettre aux utilisateurs de créer des macros, ils peuvent également être utilisés pour créer encore plus élevés abstractions de niveau pour la «langue du test" décrit ci-dessus, l'aide testeurs dans l'exécution des actions répétées pour atteindre un certain écran pour les tests. Ceux-ci sont décrits plus en détail ici.
Plus d'informations peuvent être trouvées sur la page d'accueil du projet

Quoi de neuf dans cette version:.

• Support Très basique pour wxPython était ajouté.
• Il ya aussi un certain nombre d'améliorations et de corrections de bugs pour PyGTK. Notamment, gtk.Dialog.run est désormais pris en charge sans nécessiter de modifications de code source.
• Python 2.6 et PyGTK 2.12 ou une version ultérieure doivent maintenant.
• L'interface d'instrumentation-legacy a été supprimé.

Exigences :

• Python
• PyGTK
• texttest