Automated Clicktest Server

A Clicktest simulate a user. Therefore a visual destkop is set-up and Release Manager (RM) takes control over the mouse and keyboard to automate various events. Throu screenshots Release Manager (RM) checks wherever a test is successfull or not.

Since this test can automatically be triggered throu source-code-changes we have some advantages:

A failed test is always connected to a commit (and can reject the commit).
We save cpu-power and money because tests are not triggered when nothing have been changed.

Since only native applications are tested you might think it does not fit for webtests but remember that a browser is a native applications. Thats why webtests are supported throu browsertests. Neat!

Ein Clicktest simuliert ein phyischen Benutzer. Deshalb muss ein virtueller Bildschirm aufgesetzt werden und der Release Manager (RM) übernimmt hier die Kontrolle über die Maus und die Tastatur um verschiedene Testszenarien durch zu führen. Anhand von Bildschirmfotos prüft der Release Manager (RM) ob ein Testfall (Testcase) erfolgreich war oder nicht.

Diese Tests werden in der Regel automatisch durchgeführt beim Einchecken von Quellcodeänderungen. Dadurch entstehen bestimmte Vorteile:

Ein Testdurchlauf ist immer Verbunden mit einer Quelltext-Änderung (und kann bei Fehlschlag den Commit auch abweisen).
Es wird immer Prozessorleistung eingespart wenn keine Änderung erfolgte.

Die Testfälle werden normalerweise automatisch durchgeführt, sie können aber auch manuell angestoßen werden.

Diese Lösung ist sowohl für Native-Applikationen als auch Webtests möglich, letztendlich ist der Browser auch eine Native-Applikation. So werden Webtests durch Klicktests ermöglicht. Nice!

Un test de clic simule un utilisateur physique. C’est pourquoi un écran virtuel doit être mis en place et le Release Manager (RM) prend ici le contrôle de la souris et du clavier pour exécuter différents scénarios de test. Sur la base de captures d’écran, le Release Manager (RM) vérifie si un cas de test (Testcase) a réussi ou non.

Ces tests sont généralement effectués automatiquement lors de l’archivage des modifications du code source. Il en résulte certains avantages :

Une exécution de test est toujours liée à une modification du code source (et peut également rejeter le commit en cas d’échec).
La puissance du processeur est toujours économisée si aucune modification n’a été effectuée.

Les cas de test sont normalement exécutés automatiquement, mais ils peuvent aussi être déclenchés manuellement.

Cette solution est possible aussi bien pour les applications natives que pour les tests web, en fin de compte le navigateur est aussi une application native. Ainsi, les tests web sont rendus possibles par des tests de clics. Sympa !

Una prueba de clic simula un usuario físico. Por lo tanto, hay que configurar una pantalla virtual y el gestor de versiones (RM) toma el control del ratón y el teclado para realizar diversos escenarios de prueba. Mediante capturas de pantalla, el gestor de versiones (RM) comprueba si un caso de prueba ha tenido éxito o no.

Estas pruebas suelen realizarse automáticamente cuando se registran los cambios en el código fuente. Esto tiene ciertas ventajas:

La ejecución de una prueba siempre está vinculada a un cambio en el código fuente (y también puede rechazar la confirmación si falla).
La energía del procesador siempre se guarda si no se hace ningún cambio.

Los casos de prueba se ejecutan normalmente de forma automática, pero también pueden activarse manualmente.

Esta solución es posible tanto para las aplicaciones nativas como para las pruebas web; en última instancia, el navegador también es una aplicación nativa. Así, las pruebas web son posibles gracias a las pruebas de clic. ¡Bien!

点击测试模拟了一个物理用户。因此，必须设置一个虚拟屏幕，由发布经理（RM）控制鼠标和键盘来执行各种测试场景。使用截图，发布管理器（RM）检查一个测试案例是否成功。

这些测试通常是在检查源代码的变化时自动进行的。这有一定的好处。

测试运行总是与源代码的变化联系在一起（如果测试失败，也可以拒绝提交）。
如果不做任何改变，处理器功率总是被保存。

测试用例通常是自动执行的，但也可以手动触发。

这种解决方案对本地应用程序和网络测试都是可行的；最终，浏览器也是一个本地应用程序。因此，网络测试是通过点击测试实现的。很好!