Testplan Editor/en - Versionsgeschichte

Cg: /* Condition Variables */

2024-11-07T17:21:43Z

Condition Variables

← Nächstältere Version		Version vom 7. November 2024, 17:21 Uhr
Zeile 248:		Zeile 248:
	Condition variables provide an easy to use control mechanism over which testcase items are executed during a run.		Condition variables provide an easy to use control mechanism over which testcase items are executed during a run.

	By specifying a list of boolean condition variables in this field (semicolon or comma separated), the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>"). ~~Prefix a variable's name with a '-' (minus) to check for a false value (i.e. skip the test if the variable is true).~~		By specifying a list of boolean condition variables in this field (semicolon or comma separated), the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>").

			Prefix a variable's name with a '-' (minus) to negate the check (i.e. skip the test if the variable is true).

	After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.		After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.

Cg: /* Condition Variables */

2024-11-07T17:19:20Z

Condition Variables

← Nächstältere Version		Version vom 7. November 2024, 17:19 Uhr
Zeile 248:		Zeile 248:
	Condition variables provide an easy to use control mechanism over which testcase items are executed during a run.		Condition variables provide an easy to use control mechanism over which testcase items are executed during a run.

	By specifying a list of boolean condition variables in this field (semicolon separated), the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>").		By specifying a list of boolean condition variables in this field (semicolon or comma separated), the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>"). Prefix a variable's name with a '-' (minus) to check for a false value (i.e. skip the test if the variable is true).

	After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.		After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.

Cg: /* Condition Variables */

2024-11-07T17:04:50Z

Condition Variables

← Nächstältere Version		Version vom 7. November 2024, 17:04 Uhr
Zeile 252:		Zeile 252:
	After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.		After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.

	These variables are managed in the testplan's environment. Therefore, you can also access these variables via regular environment blocks or via the low level code API (environmentAt: / environmentAt:put: calls). Condition variables can be used to disable individual test cases or to guide execution through different paths depending on previous actions. A typical application is to read out the system under tests configuration by a pre-action or first test case step, then setting condition variables, and execute only specific subsets of the suite, depending on the outcome.		These variables are managed in the testplan's environment. Therefore, you can also access these variables via regular environment blocks or via the low level code API (environmentAt: / environmentAt:put: calls). Condition variables can be used to disable individual test cases or to guide execution through different paths depending on previous actions.

			A typical usage is to read out the system under tests configuration by a pre-action or first test case step, then setting condition variables, and execute only specific subsets of the suite, depending on the outcome.

	More complex conditional execution is possible by wrapping individual test case actions into a compound block and placing condition test actions into that.		More complex conditional execution is possible by wrapping individual test case actions into a compound block and placing condition test actions into that.

Cg: /* Condition Variables */

2024-11-07T17:04:11Z

Condition Variables

← Nächstältere Version		Version vom 7. November 2024, 17:04 Uhr
Zeile 246:		Zeile 246:

	=== Condition Variables ===		=== Condition Variables ===
	Condition variables provide an easy to use control mechanism over which testcase items are executed during a run. By specifying a list of boolean condition variables in this field, the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>"). After the execution, the success-state is written to the variables named in the "''Set Variables''" field.		Condition variables provide an easy to use control mechanism over which testcase items are executed during a run.

			By specifying a list of boolean condition variables in this field (semicolon separated), the testcase item will only be executed if all of those variables contain a "<CODE>true</CODE>" value (non-existing variables are treated like being "<CODE>true</CODE>").

			After the execution, the success-state is written to the variables named in the "''Set Variables''" field. These written variables must exist and be writable.

	These variables are managed in the testplan's environment. Therefore, you can also access these variables via regular environment blocks or via the low level code API (environmentAt: / environmentAt:put: calls). Condition variables can be used to disable individual test cases or to guide execution through different paths depending on previous actions. A typical application is to read out the system under tests configuration by a pre-action or first test case step, then setting condition variables, and execute only specific subsets of the suite, depending on the outcome.		These variables are managed in the testplan's environment. Therefore, you can also access these variables via regular environment blocks or via the low level code API (environmentAt: / environmentAt:put: calls). Condition variables can be used to disable individual test cases or to guide execution through different paths depending on previous actions. A typical application is to read out the system under tests configuration by a pre-action or first test case step, then setting condition variables, and execute only specific subsets of the suite, depending on the outcome.

	More complex conditional execution is possible by wrapping individual test case actions into a compound block and placing condition test actions into that.		More complex conditional execution is possible by wrapping individual test case actions into a compound block and placing condition test actions into that.

			Variables are shown in a red color (in the test case item), if not existing or not writable.

	=== Adding Pre and Post Execution ===		=== Adding Pre and Post Execution ===

Cg: /* Selective Execution */

2024-11-05T14:10:00Z

Selective Execution

← Nächstältere Version		Version vom 5. November 2024, 14:10 Uhr
Zeile 125:		Zeile 125:
	*'''Dynamic Selection by Pre-Execution Checks'''<br>If present, the pre-execution action is run before the actual test case. If it generates a non-successful result, the corresponding test case is skipped (a corresponding post-execution action is also skipped, if present).		*'''Dynamic Selection by Pre-Execution Checks'''<br>If present, the pre-execution action is run before the actual test case. If it generates a non-successful result, the corresponding test case is skipped (a corresponding post-execution action is also skipped, if present).

	*'''Dynamic Selection by Condition Variables'''<br>You can attach a ''condition variable'' or a set of condition variables to a testcase. If a name or list of names is specified in the "''Check Condition Variable''" field, all of them must contain a boolean <code>true</code> value, otherwise, the test case is skipped with an inconclusive outcome. The variables must be defined in the testplan's environment (or the project's top environment) as boolean variables. If not present, it is treated as if "false".<p>In addition, it is possible to update a condition variable (or a set of condition variables) depending on the outcome of a test case. All variables listed in the "''set condition variable''" field will be set to <code>true</code>, if the test case passed, <code>false</code> otherwise. Output condition variables must be present in the environment as writable boolean variables.<br>These two allow for a simple conditional execution of individual test cases. Of course, these variables are also visible in the network as regular environment variables. Therefore, more complex checks can be performed using arbitrarily complex logic there.		*'''Dynamic Selection by Condition Variables'''<br>You can attach a ''condition variable'' or a set of condition variables to a testcase. If a name or list of names is specified in the "''Check Condition Variable''" field, all of them must contain a boolean <code>true</code> value, otherwise, the test case is skipped with an inconclusive outcome. The variables must be defined in the testplan's environment (or the project's top environment) as boolean variables. If not present, it is treated as if "false".<p>In addition, it is possible to update a condition variable (or a set of condition variables) depending on the outcome of a test case. All variables listed in the "''set condition variable''" field will be set to <code>true</code>, if the test case passed, <code>false</code> otherwise. Output condition variables must be present in the environment as writable boolean variables.<p>These two allow for a simple conditional execution of individual test cases. Of course, these variables are also visible in the network as regular environment variables. Therefore, more complex checks can be performed using arbitrarily complex logic there.

	*'''Sub-Testplans'''<br>Finally, by dropping another test-plan into the test-case area, all of its test-cases are embedded and are treated as a single test-case in the outer test-plan. Thus, hierarchies of testplans can be created, which can of course still be executed individually.		*'''Sub-Testplans'''<br>Finally, by dropping another test-plan into the test-case area, all of its test-cases are embedded and are treated as a single test-case in the outer test-plan. Thus, hierarchies of testplans can be created, which can of course still be executed individually.

Cg: /* Selective Execution */

2024-11-05T14:09:14Z

Selective Execution

← Nächstältere Version		Version vom 5. November 2024, 14:09 Uhr
Zeile 125:		Zeile 125:
	*'''Dynamic Selection by Pre-Execution Checks'''<br>If present, the pre-execution action is run before the actual test case. If it generates a non-successful result, the corresponding test case is skipped (a corresponding post-execution action is also skipped, if present).		*'''Dynamic Selection by Pre-Execution Checks'''<br>If present, the pre-execution action is run before the actual test case. If it generates a non-successful result, the corresponding test case is skipped (a corresponding post-execution action is also skipped, if present).

	*'''Dynamic Selection by Condition Variables'''<br>You can attach a ''condition variable'' or a set of condition variables to a testcase. If a name or list of names is specified in the "''Check Condition Variable''" field, all of them must contain a boolean <code>true</code> value, otherwise, the test case is skipped with an inconclusive outcome. The variables must be defined in the testplan's environment (or the project's top environment) as boolean variables.<p>In addition, it is possible to update a condition variable (or a set of condition variables) depending on the outcome of a test case. All variables listed in the "''set condition variable''" field will be set to <code>true</code>, if the test case passed, <code>false</code> otherwise.<br>These two allow for a simple conditional execution of individual test cases. Of course, these variables are also visible in the network as regular environment variables. Therefore, more complex checks can be performed using arbitrarily complex logic there.		*'''Dynamic Selection by Condition Variables'''<br>You can attach a ''condition variable'' or a set of condition variables to a testcase. If a name or list of names is specified in the "''Check Condition Variable''" field, all of them must contain a boolean <code>true</code> value, otherwise, the test case is skipped with an inconclusive outcome. The variables must be defined in the testplan's environment (or the project's top environment) as boolean variables. If not present, it is treated as if "false".<p>In addition, it is possible to update a condition variable (or a set of condition variables) depending on the outcome of a test case. All variables listed in the "''set condition variable''" field will be set to <code>true</code>, if the test case passed, <code>false</code> otherwise. Output condition variables must be present in the environment as writable boolean variables.<br>These two allow for a simple conditional execution of individual test cases. Of course, these variables are also visible in the network as regular environment variables. Therefore, more complex checks can be performed using arbitrarily complex logic there.

	*'''Sub-Testplans'''<br>Finally, by dropping another test-plan into the test-case area, all of its test-cases are embedded and are treated as a single test-case in the outer test-plan. Thus, hierarchies of testplans can be created, which can of course still be executed individually.		*'''Sub-Testplans'''<br>Finally, by dropping another test-plan into the test-case area, all of its test-cases are embedded and are treated as a single test-case in the outer test-plan. Thus, hierarchies of testplans can be created, which can of course still be executed individually.

Matilk: /* Log Processor Action */

2024-04-17T12:07:07Z

Log Processor Action

← Nächstältere Version		Version vom 17. April 2024, 12:07 Uhr
Zeile 268:		Zeile 268:
	However, for very special reports, or if specific data has to be extracted and postprocessed, it may be useful to process the generated raw activity data before it is used or instead of being used as input to the report generator.		However, for very special reports, or if specific data has to be extracted and postprocessed, it may be useful to process the generated raw activity data before it is used or instead of being used as input to the report generator.

	The "''Log Processor''" field allows for an action block to be specified, which gets the raw log as input and may produce a cooked-up version of it as output. If the log processor has no output, the ~~oriinal~~ activity log will be passed on to the report generator.		The "''Log Processor''" field allows for an action block to be specified, which gets the raw log as input and may produce a cooked-up version of it as output. If the log processor has no output, the original activity log will be passed on to the report generator.

	Arbitrary processing, filtering, renaming or archival of the raw data is possible in this action. Of course, some knowledge about the structure of that raw data is required, and you should consult the class browser and/or open a data inspector on a generated raw log for this. You will find an example in the "d11_LOG_Processing_Example.ets" suite (in "projects/examples"). Also, the reflection library now contains activityLog processing actions in the "Analysis" folder, and a sample testplan.		Arbitrary processing, filtering, renaming or archival of the raw data is possible in this action. Of course, some knowledge about the structure of that raw data is required, and you should consult the class browser and/or open a data inspector on a generated raw log for this. You will find an example in the "d11_LOG_Processing_Example.ets" suite (in "projects/examples"). Also, the reflection library now contains activityLog processing actions in the "Analysis" folder, and a sample testplan.
Zeile 275:		Zeile 275:

	Notice that there are both per-testcase log processors and a an overall (per testplan) log processor.		Notice that there are both per-testcase log processors and a an overall (per testplan) log processor.
	The ~~later~~ ~~one get~~ a collection (i.e. Array) of individual activity logs as input, which it should process in an enumeration loop.		The latter gets a collection (i.e. Array) of individual activity logs as input, which it should process in an enumeration loop.

	<!--		<!--

Sv: /* Execution Settings */

2023-08-11T17:32:15Z

Execution Settings

← Nächstältere Version		Version vom 11. August 2023, 17:32 Uhr
Zeile 185:		Zeile 185:

	*'''Loop (Stop on Error or Failure / Success)'''<br>This check box toggles looping on or off. If on, the execution of the test plan will be repeated until an error or failure (success) is encountered or otherwise the time limit for the execution is reached. The stop on condition feature is useful to catch sporadic error-behavior of a system under test. For example, to run a test unattended over night, but stop when a certain condition arises.		*'''Loop (Stop on Error or Failure / Success)'''<br>This check box toggles looping on or off. If on, the execution of the test plan will be repeated until an error or failure (success) is encountered or otherwise the time limit for the execution is reached. The stop on condition feature is useful to catch sporadic error-behavior of a system under test. For example, to run a test unattended over night, but stop when a certain condition arises.

			*'''Loop (Skip successful tests when looping)'''<br>This check box toggles, if only failed or inconclusive tests should be run when looping. This is useful, when you want to retry failed tests until all testcases in the testplan are successful.

	*'''Loop Count'''<br>This field is used to set a maximum loop count for the test plan execution. To loop endless just leave the field blank.		*'''Loop Count'''<br>This field is used to set a maximum loop count for the test plan execution. To loop endless just leave the field blank.

Cg: /* expecco ALM Settings */

2023-08-10T08:53:04Z

expecco ALM Settings

← Nächstältere Version		Version vom 10. August 2023, 08:53 Uhr
Zeile 227:		Zeile 227:
	These settings are only relevant if expecco is used as a "slave test execution engine" for AIDYMO (formerly called "''expecco ALM''"). They are ignored if expecco is running as a stand alone application (e.g. by the test developer) or started manually by a test engineer (see [[Command_Line_Options\|"Command Line Options"]]).		These settings are only relevant if expecco is used as a "slave test execution engine" for AIDYMO (formerly called "''expecco ALM''"). They are ignored if expecco is running as a stand alone application (e.g. by the test developer) or started manually by a test engineer (see [[Command_Line_Options\|"Command Line Options"]]).

	*'''Visible in AIDYMO'''<br>This checkbox determines whether the ~~testplan~~ is visible in [[~~expecco ALM~~\|expecco ALM/AIDYMO]]. Such externally visible test plans can later be executed automatically by AIDYMO. Invisible test plans are useful for the test developer, to leave partial tests, setup, shutdown or cleanup sequences in the test suite, which are not meant for public use (or use by the automatic test scheduler).		*'''Visible in AIDYMO'''<br>This checkbox determines whether the test plan is visible in [[Expecco_ALM_Overview/en\|expecco ALM/AIDYMO]]. Such externally visible test plans can later be executed automatically by AIDYMO. Invisible test plans are useful for the test developer, to leave partial tests, setup, shutdown or cleanup sequences in the test suite, which are not meant for public use (or use by the automatic test scheduler).
	*'''Operator Needed'''<br>This checkbox determines whether an operator is required during execution of the test. AIDYMO will then ask a human operator to supervise/perform the test.		*'''Operator Needed'''<br>This checkbox determines whether an operator is required during execution of the test. AIDYMO will then ask a human operator to supervise/perform the test.
	*'''Cases Visible in AIDYMO'''<br>This checkbox determines whether test cases are individually selectable for execution in AIDYMO. If unchecked, only the whole test plan can be configured for an automatic run. You should only turn this check on, if the test cases are independent from each other, and do not need state from a previous test case or leave the system under test in a state needed by another test case. Otherwise, it is better to define multiple test plans, each with its individual setup/shutdown actions to leave the system under test in a defined state, and let the test manager choose among those plans, instead of individual test cases.		*'''Cases Visible in AIDYMO'''<br>This checkbox determines whether test cases are individually selectable for execution in AIDYMO. If unchecked, only the whole test plan can be configured for an automatic run. You should only turn this check on, if the test cases are independent from each other, and do not need state from a previous test case or leave the system under test in a state needed by another test case. Otherwise, it is better to define multiple test plans, each with its individual setup/shutdown actions to leave the system under test in a defined state, and let the test manager choose among those plans, instead of individual test cases.

Cg: /* expecco ALM Settings */

2023-08-10T08:51:55Z

expecco ALM Settings

← Nächstältere Version		Version vom 10. August 2023, 08:51 Uhr
Zeile 227:		Zeile 227:
	These settings are only relevant if expecco is used as a "slave test execution engine" for AIDYMO (formerly called "''expecco ALM''"). They are ignored if expecco is running as a stand alone application (e.g. by the test developer) or started manually by a test engineer (see [[Command_Line_Options\|"Command Line Options"]]).		These settings are only relevant if expecco is used as a "slave test execution engine" for AIDYMO (formerly called "''expecco ALM''"). They are ignored if expecco is running as a stand alone application (e.g. by the test developer) or started manually by a test engineer (see [[Command_Line_Options\|"Command Line Options"]]).

	*'''Visible in AIDYMO'''<br>This checkbox determines whether the testplan is visible in [[expecco ALM\|AIDYMO]]. Such externally visible ~~testplans~~ can later be executed automatically by AIDYMO. Invisible ~~testplans~~ are useful for the test developer, to leave partial tests, setup, shutdown or cleanup sequences in the test suite, which are not meant for public use (or use by the automatic test scheduler).		*'''Visible in AIDYMO'''<br>This checkbox determines whether the testplan is visible in [[expecco ALM\|expecco ALM/AIDYMO]]. Such externally visible test plans can later be executed automatically by AIDYMO. Invisible test plans are useful for the test developer, to leave partial tests, setup, shutdown or cleanup sequences in the test suite, which are not meant for public use (or use by the automatic test scheduler).
	*'''Operator Needed'''<br>This checkbox determines whether an operator is required during execution of the test. AIDYMO will then ask a human operator to supervise/perform the test.		*'''Operator Needed'''<br>This checkbox determines whether an operator is required during execution of the test. AIDYMO will then ask a human operator to supervise/perform the test.
	*'''Cases Visible in AIDYMO'''<br>This checkbox determines whether ~~testcases~~ are individually selectable for execution in AIDYMO. If unchecked, only the whole ~~testplan~~ can be configured for an automatic run. You should only turn this check on, if the ~~testcases~~ are independent from each other, and do not need state from a previous test case or leave the system under test in a state needed by another test case. Otherwise, it is better to define multiple ~~testplans~~, each with its individual setup/shutdown actions to leave the system under test in a defined state, and let the test manager choose among those plans, instead of individual ~~testcases~~.		*'''Cases Visible in AIDYMO'''<br>This checkbox determines whether test cases are individually selectable for execution in AIDYMO. If unchecked, only the whole test plan can be configured for an automatic run. You should only turn this check on, if the test cases are independent from each other, and do not need state from a previous test case or leave the system under test in a state needed by another test case. Otherwise, it is better to define multiple test plans, each with its individual setup/shutdown actions to leave the system under test in a defined state, and let the test manager choose among those plans, instead of individual test cases.

	<!--* '''MON'''<br>-->		<!--* '''MON'''<br>-->