Settings ExecutionSettings/en
Inhaltsverzeichnis
Execution Settings[Bearbeiten]
Separate Processes for Long Running Activities[Bearbeiten]
This check toggle controls if multiple activities are allowed to execute in parallel (are executed by separate threads). By default, this is enabled, but in rare situations, it makes sense to disable this feature for some test projects. Usually these are badly formulated activities, which do not care for synchronized access to shared data or data bases, and may therefore be not prepared for parallel execution.
Instead of disabling this feature, you should instead use synchronisation mechanisms in your activity diagram (i.e. either use trigger-out/trigger-in connections to enforce sequential execution, or use explicit semaphore actions to ensure mutual exclusion while doing such critical operations).
This parameter is stored in the test suite, not in the private per-user settings.
Start Process After[Bearbeiten]
Due to the fact that starting up new processes (execution threads) is a relatively slow operation and takes up some processing power, the expecco system delays the creation of new processes for some time, in order to allow for short activities to finish without creating of a new process. If an activity is finished within that time duration, no new process is created. Effectively, short-term activities are sequentially executed, as long as their processing takes less than this time duration.
This parameter is stored in the test suite, not in the private per-user settings.
Max. Number of Processes[Bearbeiten]
This limits the number of parallel executing separate processes. Because a process is a somewhat expensive resource in a computer (memory, disk space etc.), allowing for an arbitrary number of separate processes might lead to a slowdown or even blocking of the computer's operation.
Effectively, expecco will keep a pool of worker threads for execution, which process pending activities. The max. number of worker threads is set by this parameter.
This parameter is stored in the test suite, not in the private per-user settings.
Max. Number of Executors per Testsuite[Bearbeiten]
This limits the number of executors that can execute within the same test suite at the same time. This parameter is used with special test plans, which run tests from the same test suite in parallel on multiple systems-under-test, or if expecco is operated as an execution slave (runtime) and multiple execution jobs for the same suite are coming from a central QM management system.
Max. Number of ExpeccoNET Test-Executions[Bearbeiten]
This limits the number of test execution jobs from a QM-management system that can run in parallel. This parameter is only used if expecco application is used as a test slave processor (for remote test execution, under the control of an expecco ALM or other QM management system).
Max. Recursion Level[Bearbeiten]
This parameter limits the nesting of activities during execution (i.e. the nesting of compound activities which invokes another compound activity). If this limit is reached, an error is raised, which leads to the current test case to be reported as erroneous.
This parameter is stored in the test suite, not in the private per-user settings.
Max. Cleanup Time[Bearbeiten]
This parameter limits the max. execution time of cleanup actions. This allows for cleanup actions which try to communicate with dead connections to be terminated and thus avoids blocking. If a cleanup action executes longer, a dialog is shown, asking if a hard termination (i.e. termination without cleanup) or a wait for the action is desired by the user. If expecco is executed in non-interactive mode (slave-mode or executed via command line), the dialog is not shown. Instead, the cleanup action is hard terminated automatically after the max. cleanup time.
This parameter is stored in the test suite, not in the private per-user settings.
Slow Motion Delay[Bearbeiten]
This parameter introduces a delay between the execution of individual activities. This is useful in demonstration or replay situations, where the user wants to visually follow and monitor the execution of the individual steps. It is also sometimes useful when debugging a test, to slow down the process artificially.
Show "Do Not Disturb" Banner[Bearbeiten]
If checked, a banner window is shown during the execution of a test plan. This is useful to prevent other users from touching the machine, especially preventing them from stopping or disturbing an ongoing, long running test. It is especially useful on the test floor, where test machines are shared among different users.
