consol / sakuli Goto Github PK

Sakuli is an end-2-end testing and monitoring tool for web sites and common UIs with multiple monitoring integrations

JavaScript 6.29% Shell 3.09% Visual Basic 0.56% Perl 1.45% PowerShell 1.43% PHP 1.90% Java 81.39% CSS 0.15% Batchfile 0.23% HTML 3.17% Makefile 0.07% Dockerfile 0.03% TSQL 0.25%

testing testautomation e2e e2e-tests e2e-monitoring application-monitoring monitoring nagios omd icinga

sakuli's Introduction

Attention: EOL of Sakuli 1

Sakuli was completely rewritten in node and typescript and is now available in version 2:

https://sakuli.io

https://github.com/sakuli

There will be no further maintenance of Sakuli 1, it is easily possible and suggested to migrate existing tests to Sakuli 2.

An end-to-end testing tool for web sites and common UIs with multiple monitoring integrations

About the project

Sakuli simulates user actions on graphical user interfaces (web, fat client, citrix, …), and provides the obtained information (runtime, result, screenshots) to third party (e.g. Nagios compatible monitoring) systems.

Sakuli is written in Java and runs on many platforms:

The Sakuli project brings together two Open-Source end-to-end testing tools which perfectly fit together: Sahi for web-based tests (by injecting JavaScript code into the browser), as well as the screenshot-based testing tool Sikuli, which allows the execution of keyboard and mouse actions on screen areas that have been defined by previously recorded screenshots and are recognized using the OpenCV engine.

Key Features

Platform-independent UI testing tool
End-2-End monitoring of application functionality and quality
Combines two automation technologies:
- DOM based web testing
- Image pattern based UI automation (for non-web content)
Scalable from single-client up to multi-node container setup for parallel execution
Integration of test results into
- Monitoring systems (e.g. Nagios/Icinga)
- CI builds (e.g. Jenkins)

Documentation

The complete versions of our documentation you can find under:

consol.github.io/sakuli

Dev version: latest vX.X.X-SNAPSHOT version
Stable/Latest version: v1.2.0

Quick links

Project Homepage - www.sakuli.org

Download

Sakuli Examples

Blog Entries

Publications

Events

Media

Change Log

Support

@sakuli_e2e

Sakuli Short Overview Presentation

Sakuli UI Introduction

https://github.com/ConSol/sakuli-ui

sakuli's People

Contributors

Stargazers

Watchers

sakuli's Issues

screen capturing (windows)

make a movie of Sakuli tests, throw away if test was successful

make sahi exception output more clear

create sakuli-examples repository

Remove .idea directory

It's not a good style to include configurations for IDEs, because ...

... they could contain absolute pathes
... there can be problems when used with different versions
... it enforces a certain style for the developer
... private configurations can leak in

If you need some specific e.g. run configurations, use maven profiles instead. Everything should be in maven, nothing else.

publish doucmenation as html site

use https://readthedocs.org/ to publish our makrdown documentation
update links in readme

optional threshold in endOfStep

Make threshold parameter in endOfStep optional so

testCase.endOfStep("nomatterhowlong");

never gets warning.

screen capturing (linux)

make a movie of Sakuli tests, throw away if test was successful

translate documentation in english

consequent namings

host/service names
variable names

Sometimes unclear to see what has to be replaced by user

function waitForWindow

e.g.

var loginregion = screen.waitForWindow("enter credentials", 10);

=> Bring window to foreground using its title

Avoid creating extra Spring context

In SakuliStarter an extra, starter context is created which is not really necessary and is used only during the startup phase.

For this simple case it is much better to create the two initial starter services by hand in order to make things less complex and easier to understand.

introduce Mouse actions

region.mouseOver()

(hold mouse button for drag and drop)
mouseLeftDown
mouseLeftUp
/right/
/middle/

killproc.vbs

check JavaServiceWrapper

http://wrapper.tanukisoftware.com/doc/german/download.jsp

=> useful?

DB-Check: duplicate screenshot

test sahi v5 compatibility & upgrade

rename folder _sakuli_test_suites to tests

too long
redundance

=> rename to 'test_suites'
=> check comments and logs 'testsuite' => 'test suite'

gearman encryption

CFP for Software-QS-Tag 2015 in Nuernberg

Bewerbug für Konferenzen in 2015:
* Software-QS-Tag in Nürnberg

finish xvnc install documentation & ansible recipe

introduce sakuli.screenshots.wait

After calling the screenshot routine, wait 1-2s. Some screenshots currently do not show the application's error anymore but everything already closed.

=> introduce new property:
sakuli.screenshots.wait = 2
(see also #13)

suppress sahi logs selectively

For pure web tests, a combination of sahi/phantomJS would be perfect. This would allow the browser to run headless. As long as sahi logs all input values (also passwords...), a full browser windows must be started to fill the password field with sikuli. Only then it does not get logged.
=> Find a solution for sahi not to log certain data.

headless execution on windows

use virtualbox display driver

Installation automation

http://izpack.org/

rename application method closeApp

Application.open()
Application.closeApp()

=> Application.close()

rename sakuli.encryption.interface.testmode

name is misleading.
Proposal: sakuli.encryption.disabled = true

introduce typeX method

e.g.

screen.typeX(Key.TAB, 6);
screen.typeX(Key.TAB, Key.SHIFT, 6);

region.typeX = function(keys, optModifier, n);

woud type TAB key 6 times.

Firefox MOZ_DISABLE_OOP_PLUGINS

rename function names

Sakuli.Environment.js:

pasteClipboard => pasteFromClipboard?
or
copyIntoClipboard => copyClipboard?

decryptSecret => decrypt (all other decrypt methods do not contain "Secret")

Duplicate Definition (environment & screen):
paste
pasteMasked
pasteAndDecrypt
type
typeMasked
typeAndDecrypt

Add method to Application class to run shell commands directly

Check if the SikuliX-Class have an implemenation for that or:
- use Runtime-Java-Class for calling directly CMD commands (maybe OS independent implementation possible)

clear clipboard on end of test

could contain sensible data

change java-version to java8

change the src code level to jdk8, if the aspectj compiler plugin allows that

http://stackoverflow.com/questions/25209339/spring-aspectj-weaving-for-java-8-using-aspectj-maven-plugin

Pre-parsing step definitons

Steps are defined at the end of every logical section of a test. Hence, only at the very end of a test all step names are known to Sakuli. This is not the case if there is an exception during the tests; all steps after the exit point won't be sent to Nagios. PNP4Nagios then assumes that the number of data sources has changed, the XML file will be updated only with the number fo steps which were passed until the exception. => RRDtool will only graph some data sources.

Possible solution: parse tets case before execution so that all steo definitions are known to Sakuli. Then, even in the case of an exception, all perfdata labels can be sent to Nagios which are neccessary for pnp4nagios to print the graph properly.

move folder vb_scripts up

old:
sakuli/scripts/helper/vb_scripts/

new:
sakuli/scripts/helper/

Typo: Strg+v

sakuli_environment.js, line 105: = STRG+V

introduce waitForImageCase

A dialogue which is apperaring "sometimes" can only be catched in this way:

if (screen.exists("dialog",30))  {
  screen.click("okbutton");
}

If the dialogue is not apperaring, Sakuli has to wait 30 seconds - useless.

waitForImageCase(
   "bild1", sec, _functionhandler1,
   "bild2", sec, _functionhandler2
);

would solve the problem. Sakuli would wait for two images at the same time and execute one of two function handlers.

clarify / rename property sakuli.log.exception.onResumeOnException

make screenshot creation on "throw" optional

screenshots are not always needed if exceptions are "thrown".

check logging documentation

Avoid usage of system properties for internal context propagation

Since system properties should be used only for Since system properties are global variables they should be used only in certain cases. I.e. when getting information from the outside they might be appropriate as an alternative for command line arguments. However, for internal propagation of context information they are not so suitable, because they are global and pollute the global namespace. It's much better to set up the context in a local scope and propagate it to the place where required.

I.e. for setting up logging with custom pathes it is better to build up the log configuration dynamically instead of relying on standard external variable substitution.

See the SakuliStarter class as entry point.

try to reenable the automatic generation of the markdown API documentation
maybe try to generate the doc from java