- 1 Black Box Test
- 2 Bridged Actions
- 3 Compound Block
- 4 Compound Step
- 5 ".csf" File
- 6 Elementary Block
- 7 Elementary Step
- 8 Environment
- 9 Environment Freeze Value
- 10 ".elf" File
- 11 ".ets" File
- 12 Freeze Value
- 13 Functional ID (FID)
- 14 Gray Box Test
- 15 Groovy
- 16 Groovy Elementary Block
- 18 Node Elementary Action Block
- 19 Pin - Consuming Pin
- 20 Pin - Parameter Pin
- 21 Pin - Triggering Pin
- 22 Python Elementary Action Block
- 23 Script Actions
- 24 Shell/Batch Script Elementary Block
- 25 Smalltalk Elementary Block
- 26 Stderr
- 27 Stdout
- 28 SUT (System Under Test)
- 29 Syntactic Sugar
- 30 TestSuite Element
- 31 Transcript
- 32 Verdict
- 33 VersionID (VID)
- 34 White Box Test
- 35 Abbreviations
Black Box Test
In a "black box test", the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.
The opposite being a "White Box Test", which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).
Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy" or "VisualBasic".
Mixed mode testing is called "Grey Box Testing".
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
See Compound Block in the Tree Elements documentation.
A step inside an activity diagram, whose action definition is a compound block. When triggered, such a step will execute another activity diagram.
See Compound Block in the Tree Elements documentation.
each pair specifies an attribute or required capability of the connection. Typically, these are generated via the GUI browser's "Connection" dialog and kept as attachments inside the suite.
An non-compound action block. I.e. any action which is not defined by an activity diagram, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
See Elementary Block in the Tree Elements documentation.
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
See Elementary Block in the Tree Elements documentation.
Variables are bundled together in so called Environments, which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.
During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
Typically, the top-level suite's environment (so called "ProjectEnvironment") is used most of the time.
Environment Freeze Value
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.
elf" stands for "Expecco Log File" and is the native format in which result files are written. "
elf" files contain all of the execution, trace and data-flow information and the original suite as executed. "
elf"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "
elf" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can (in theory) be read and processed by third party tools.
ets" stands for "Expecco Test Suite". These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "
.ets" files should not be manipulated manually, as the consistency of the suite may be harmed.
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Functional ID (FID)
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.
Gray Box Test
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
See "Grey Box Testing" in Wikipedia.
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a language very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.
Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it executes at full Java speed.
Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable from the local machine via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with multiple hosts in a distributed system or when testing both ends of a communication protocol.
See "Groovy Elementary Blocks" in the Expecco API Document and Elementary Block in the Tree Elements documentation.
Groovy Elementary Block
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
See "Groovy Elementary Blocks" in the Expecco API Document and Elementary Block in the Tree Elemens documentation.
Node Elementary Action Block
You have to install "node" and "npm" from the official website: https://nodejs.org/en/download.
See "NodeJS Elementary Blocks" in the Expecco API document and Elementary Block in the Tree Elements documentation.
Pin - Consuming Pin
An input pin of a step, which does consumes its input value when the step starts to execute. Technically, this takes the next input value from the queued values pending in the input-basket. Consuming pins are used when an input pin gets its value from another step's output pin.
Pin - Parameter Pin
An input pin of a step, which does not consume its input value and which does not trigger the step. Used for constants and parameters, especially if the step is to be used in a loop.
Pin - Triggering Pin
An input pin of a step, which triggers the execution of a step. A step will only start to execute, when all of its triggering pins have received a value.
Python Elementary Action Block
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite.
You have to install "python" and "pip" from the official website: https://www.python.org/downloads.
See "Bridged Python Elementary Blocks" in the Expecco API document.
Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others. In contrast to "bridged actions", these are called as host-commands, where a new interpreter is started for every action invokation. This has the advantage, that any existing script can be easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter.
Shell/Batch Script Elementary Block
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter. See "ShellScript Elementary Blocks" in the expecco elementary block documentation.
Smalltalk Elementary Block
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code will be executed inside expecco itself. See "Smalltalk Elementary Blocks" in the Expecco API Documentation.
Short for Standard Error. This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile. If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "Extras" - "Settings" - "Execution" - "Tracing" - "Show Stdout/Stderr in Transcript".
Short for Standard Output. This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile. If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "Extras" - "Settings" - "Execution" - "Tracing" - "Show Stdout/Stderr in Transcript".
SUT (System Under Test)
The tested system.
Expecco interacts with this either in a pure black box (only talking to external interfaces), or gray to white box fashion (some or a lot of knowledge about internals of the SUT are known).
Technically, black box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc. White box tests can access data structures and interfaces internal to the SUT.
In expecco, White Box Tests are done by implanting code into the SUT via code injection techniques. Depending on the type of technology and environment used, this injection (or instrumentation) may be possibly dynamically (Java or .NET) or has to be done statically by linking expecco-support libraries to the program (C, C++)
A feature of (typically) a programming language, which does not give you more semantic features, but instead exists for the convenience of the user. Typically "syntactic sugar" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively.
"Testsuite" is the term used for a packaged test project. It contains a collection of Tree Elements like testplans, blocks and datatypes as well as optional resources, attachments and documentation.
Test suites can be imported into other test suites and can therefore also be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.
Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.
The "Transcript Window" is the expecco console window, which can be opened via "Extras" - "Tools" - "Transcript". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged).
If not open, those messages will be sent to "stderr" instead.
The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
if all went well, and the execution did not encounter any problems
the execution detected an error in the System Under Test (SUT). For example, it measured a wrong value, detected invalid behavior of the SUT, invalid protocol behavior etc.
the test itself ran into some error. This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. For example, if a file containing test-data could not be found, if a division by zero occurred etc.
the test had no chance to perform its testing operations. For example, if a machine could not be reached in the network, if a resource (operator, measurement device, test-device etc.) was not available, etc.
The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
- for a FAIL, he has to inform the developer of the SUT, to fix the problem in the product.
- for an ERROR, he has to inform the test-developer/analyst, to fix the problem in the test-case
- for INCONCLUSIVE, he has to check for the availability of required devices and possibly inform the network administrator or test-lab-manager. After that, he can rerun the test without a need to contact either the product-development, nor the test-development team.
Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict. If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "UUID"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.
White Box Test
Designates a test which executes within the System Under Test and uses or refers to (but also depends on) the internals of the System Under Test. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).
White Box Tests have both advantages and disadvantages.
- + because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.
- - because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.
In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.
See also: Black Box Test
Common used abbreviations in this document are:
- ALM - Application Lifecycle Management
- CB - Compound Block
- ".csf" - Connection Settings File (file suffix)
- DCE - Distributed Computing Environment (an RPC mechanism)
- DLL - Dynamic Link Library (a synonym for "SO" = Shared Object)
- EB - Elementary Block
- ".elf" - Expecco Log File (file suffix)
- ".ets" - Expecco Test Suite (file suffix)
- FID - Functional ID
- GUI - Graphical User Interface
- QM - Quality Management
- RPC - Remote Procedure Call
- ".png" - a bitmap image file format (file suffix)
- SO - Shared Object (a synonym for DLL)
- SUT - System Under Test
- UI - User Interface (often actually meaning: Graphical-UI)
- UUID - Universal Unique Identifier
- VID - Version ID