mnxfst / ptest-server Goto Github PK

By default the TSPlanExecutor uses the TSPlanBasicExecutionContext. The caller must be able to provide an pre-configured context or a different context implementation

The implementation of the TSMain component just provides a echo server but must accept incoming test plans and runtime settings. These configuration must be executed and return a result to the caller ... maybe using a callback URL?!

The random value generator fetches it destination variable names from the value generator configuration while the other activities follow the contextExportVars rule.

The cache of results needs to be flushed from time to time automatically

Some variables being printed out using the log4j activity or any other activity do not follow a specific format but the simple result of toString(). In order to have any influence of the toString() result, a formatter is required which must be given as global configuration and being referenced within the desired activities.

Implement missing recurrence types

Each activity must be configured such that it could write 0..n variables to the context. This behavior must be supported by the activity configuration set such that it looks like:

The tag name is used for referencing the known variable within the activity whereas the value names the context variable to be
used for storing the value.

Next to the min, max and average runtime the median value must be added

The WaitTimeActivity must be configured to either fetch the wait time from the configuration or a given context variable.

It is required to have a decrement activity to work on a given numerical variable

During a test run we had to incorporate hard-coded variable formatters that need to be removed later on.

In some cases it is required to add some global configuration which is independent from the fixed test plan and adds some more flexibility. For these cases there must be an additional parameter providing settings to the server.

Most of the values generated are being stored within the context which handles serializables instead of a specific implementation. Therefore the generators should return the same type.

Using a proxy configuration does not work due to unknown reasons. Analyze, check and fix required.

Make TimestampActivity configurable such that the value is either stored in the durable or the transient value storage

Global variables must be introduced to be used within the test plan activities without the need to reinitialize them for each
test plan run. These variable could, for example, hold the name of the test plan, the environment identifier or any information about the current executor

Implement an IF-expression evaluation activity which evaluates a given expression and forwards to a configured activity according to the result

Count up errors and check for error types

ContextLog4jActivity fetches replacement values from the transient storage but must be configurable to handle durable values as well

Context variables being used in the test plan, eg. within the log4j activity, must be able to contain simple operations like subtraction, addition and concatenation: ${endTimestamp-initTimestamp}

Context variables may be accessed within the test plan using the ${varName} notation. In order to allow complex objects, it is required to evaluate variables like ${varName.attribute} using the getter notation

The address generator must create randomized addresses

Implement a JMS queue writer which either takes the contents of a context variable and writes it to the queue / topic or a pre-defined value

The ptest-server is expected to run in a distributed environment having n parallel ptest-server instances. Since the client needs to know about the (accumulated) results each run produces, there must be a way to return those information to the client.

Since the execution is triggered using a HTTP server call, the results could be included in the response. Unfortunately this works only for a small number of test plan recurrences. Therefore either the client must provide a callback URL the server must be aware or the client needs to constantly poll results from different source (eg. database).

Another way to handle this could be a central ptest-server instance or another dedicated control instance which is ordered to execute a distributed test case, colllects all results, stores them using a unique session identifier and provides the data on a different HTTP call back to the caller. In that case the caller could constantly pull for results and must not provide a callback url.

The current random UUID generator does not ensure the uniqueness of values being generated within different JVMs. Since there will only be one ptest-server instance per hardware instance, adding the MAC address will add uniqueness by definition.