User Manual

Release 10/17, Revision 40.017

TESSY Version 4.0

Razorcat Development GmbH

Imprint

Razorcat Development GmbH

Witzlebenplatz 4
Germany, 14057 Berlin
tel: +49 (030) 53 63 57 0
fax: +49 (030) 53 63 57 60
e-mail: support@razorcat.com
internet: http://www.razorcat.com

Windows is a registered trademark of Microsoft. TESSY and CTE are registered trademarks of
Razorcat Development GmbH.
All other registered or unregistered trademarks referenced herein are the property of their respective
owners and no trademark rights to the same is claimed.

Liability exclusion

Razorcat Development GmbH assumes no liability for damage that is caused by improper installation
or improper use of the software or the non-observance of the handling instructions described in this
manual.

Thanks

Various contents are based on application notes and publications on TESSY written by Frank Bü-
chner, Hitex Development Tools GmbH. We would like to thank Frank for his valuable contribution
and commitment in supporting TESSY and spotlighting functionalities and features.

TESSY 4.0 Manual iii

Contents

Preface xvii
About TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
How to use this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Subject matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Safety Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Core workflow and registration for safety information . . . . . . . . . . . . xxiii
Verification and certification of TESSY . . . . . . . . . . . . . . . . . . . . xxiv
Instrumentation for coverage measurement . . . . . . . . . . . . . . . . . . xxiv
Adaptation to target environment . . . . . . . . . . . . . . . . . . . . . . . xxv
Operating limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
New features in TESSY 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Software variant management . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Optimizations in command line mode . . . . . . . . . . . . . . . . . . . . xxviii
Support for test driven development . . . . . . . . . . . . . . . . . . . . . xxviii
UUID for all TESSY objects . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Auto-reuse in command line execution . . . . . . . . . . . . . . . . . . . . xxix
Excluding individual tests . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

1 Installation and registration 1

1.1 Technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Requesting a license key . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Registrating the license . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 The License Manager . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Using license part-time on another computer . . . . . . . . . . . . . . . . . 11
1.5.1 Checking-out the license . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Using license part-time on a computer with no internet connection . 13

TESSY 4.0 Manual v

 2 Migrating from TESSY 3.x to 4.x 16
2.1 Importing previous projects . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 General handling 18
3.1 Creating databases and working with the file system . . . . . . . . . . . . . 19
3.1.1 Creating a project database . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Creating, importing, cloning, editing, deleting a project . . . . . . . 25
3.1.3 Creating a template project . . . . . . . . . . . . . . . . . . . . . . 26
3.1.4 Moving the project directory . . . . . . . . . . . . . . . . . . . . . 26
3.1.5 Handling with equally named projects . . . . . . . . . . . . . . . . 27
3.1.6 Using a specific environment setting . . . . . . . . . . . . . . . . . 29
3.1.7 Updating the database . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Understanding the graphical user interface . . . . . . . . . . . . . . . . . . 31
3.2.1 Menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3 Perspectives and perspective (tool) bar . . . . . . . . . . . . . . . . 32
3.2.4 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.5 Status bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Using the context menu and shortcuts . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Basic knowledge 40
4.1 Unit testing of embedded software . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Standards that require testing . . . . . . . . . . . . . . . . . . . . 41
4.1.2 About unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2.1 What is unit testing? . . . . . . . . . . . . . . . . . . . . 42
4.1.2.2 What are the benefits? . . . . . . . . . . . . . . . . . . . 42
4.1.3 Considerations for unit testing . . . . . . . . . . . . . . . . . . . . 43
4.1.3.1 Which units are good test candidates? . . . . . . . . . . . 43
4.1.3.2 What is not in the scope of unit testing? . . . . . . . . . 43
4.1.3.3 Why is regression testing necessary? . . . . . . . . . . . . 44
4.1.3.4 Who should conduct the tests? . . . . . . . . . . . . . . . 44
4.1.3.5 What is special for testing embedded software? . . . . . . 45
4.1.4 Methods for unit testing . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.4.1 a. Test application . . . . . . . . . . . . . . . . . . . . . 45
4.1.4.2 b. Original binary test . . . . . . . . . . . . . . . . . . . 46
4.1.4.3 Pros and cons . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vi TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM) . . . . . . . . . . . . . . . . . . . 49
4.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Steps to take . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3 Example is_value_in_range . . . . . . . . . . . . . . . . . . . . . 56
4.2.3.1 Test-relevant aspects . . . . . . . . . . . . . . . . . . . . 56
4.2.3.2 Forming classes . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3.3 A first range specification . . . . . . . . . . . . . . . . . 57
4.2.3.4 A second range specification . . . . . . . . . . . . . . . . 58
4.2.3.5 Extending the tree by a boundary class . . . . . . . . . . 59
4.2.3.6 Another interesting test case specification . . . . . . . . . 60
4.2.3.7 The completed classification tree . . . . . . . . . . . . . . 61
4.2.3.8 The completed test case specification . . . . . . . . . . . 63
4.2.3.9 Another test case specification . . . . . . . . . . . . . . . 64

5 Practical exercises 67
5.1 Quickstart 1: Unit test exercise is_value_in_range . . . . . . . . . . . . . 69
5.1.1 Creating a test project . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2 Specifying the target environment . . . . . . . . . . . . . . . . . . 72
5.1.3 Adding the test object and analyzing the C-source file . . . . . . . . 73
5.1.4 Editing the test object interface . . . . . . . . . . . . . . . . . . . 76
5.1.5 Designing test cases . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.6 Adding test cases and test steps . . . . . . . . . . . . . . . . . . . 77
5.1.7 Entering test data . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.8 Executing the test . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1.9 Repeating the test run with coverage instrumentation . . . . . . . . 83
5.1.10 Analyzing the coverage . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.10.1 The flow chart view . . . . . . . . . . . . . . . . . . . . . 86
5.1.10.2 The Branch (C1) Coverage view . . . . . . . . . . . . . . 86
5.1.10.3 The MC/DC Coverage view . . . . . . . . . . . . . . . . 86
5.1.10.4 Analyzing . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.1.11 Creating a report . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.1.12 Repeating the test run with requirements . . . . . . . . . . . . . . 92
5.1.12.1 Importing requirements . . . . . . . . . . . . . . . . . . . 92
5.1.12.2 Committing the requirements document . . . . . . . . . . 94
5.1.12.3 Linking test cases with requirements . . . . . . . . . . . . 95
5.1.12.4 Creating a planning coverage report . . . . . . . . . . . . 96
5.1.12.5 Executing the test and examining the coverage . . . . . . 99
5.1.13 Reusing a test object with a changed interface . . . . . . . . . . . . 102
5.1.13.1 Changing the interface of the test object . . . . . . . . . 102

TESSY 4.0 Manual vii

 5.1.13.2 Assigning the changed interface of the test object . . . . 107
5.2 Quickstart 2: The Classification Tree Editor (CTE) . . . . . . . . . . . . . 110
5.2.1 Creating classifications . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.2 Creating classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.3 Entering test data . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.4 Creating test cases . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.3 Quickstart 3: Component test exercise interior_light . . . . . . . . . . . . 121
5.3.1 Creating the test project . . . . . . . . . . . . . . . . . . . . . . . 123
5.3.2 The heartbeat function . . . . . . . . . . . . . . . . . . . . . . . . 124
5.3.3 Preparing the test interface . . . . . . . . . . . . . . . . . . . . . . 127
5.3.4 Adding test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.3.5 Editing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.3.6 Configuring the work tasks . . . . . . . . . . . . . . . . . . . . . . 132
5.3.7 Designing scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3.7.1 First scenario . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3.7.2 Second scenario . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.8 Executing the scenarios . . . . . . . . . . . . . . . . . . . . . . . . 138
5.3.9 Evaluating the scenarios . . . . . . . . . . . . . . . . . . . . . . . . 139
5.4 Quickstart 4: Exercise C++ . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.5 Quickstart 5: Test driven development (TDD) . . . . . . . . . . . . . . . . 144

6 Working with TESSY 150

6.1 Menu Bar Entries: Setting up the basics . . . . . . . . . . . . . . . . . . . 154
6.1.1 File menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.1.2 Edit menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.3 Window menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.4 Windows > Preferences menu . . . . . . . . . . . . . . . . . . . . 155
6.1.5 Help menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.2 Overview perspective: Organizing the test . . . . . . . . . . . . . . . . . . 161
6.2.1 Structure of the Overview perspective . . . . . . . . . . . . . . . . 161
6.2.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.2.2.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 163
6.2.2.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 163
6.2.2.3 Creating tests . . . . . . . . . . . . . . . . . . . . . . . . 165
6.2.2.4 Analyzing modules . . . . . . . . . . . . . . . . . . . . . 165
6.2.2.5 Creating variant modules . . . . . . . . . . . . . . . . . . 168
6.2.2.6 Executing tests . . . . . . . . . . . . . . . . . . . . . . . 174
6.2.2.7 Instrumentation settings . . . . . . . . . . . . . . . . . . 177
6.2.2.8 Viewing test results . . . . . . . . . . . . . . . . . . . . . 178

viii TESSY 4.0 Manual

 6.2.2.9 Hiding irrelevant test objects . . . . . . . . . . . . . . . . 179
6.2.2.10 Search filter function . . . . . . . . . . . . . . . . . . . . 181
6.2.2.11 Creating reports . . . . . . . . . . . . . . . . . . . . . . . 182
6.2.2.12 Batch test operations . . . . . . . . . . . . . . . . . . . . 186
6.2.2.13 Importing and exporting . . . . . . . . . . . . . . . . . . 189
6.2.3 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.2.3.1 General tab . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.2.3.2 Sources tab . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.2.3.3 Linker tab . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.2.3.4 Coverage tab . . . . . . . . . . . . . . . . . . . . . . . . 196
6.2.3.5 Attributes tab . . . . . . . . . . . . . . . . . . . . . . . . 199
6.2.3.6 Specification / Description / Comment tabs . . . . . . . 200
6.2.4 Requirements Coverage view . . . . . . . . . . . . . . . . . . . . . 201
6.2.5 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.2.5.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 202
6.2.5.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 202
6.2.5.3 Creating test cases and test steps . . . . . . . . . . . . . 204
6.2.5.4 Creating test steps automatically . . . . . . . . . . . . . . 205
6.2.5.5 Test cases and steps created within the CTE . . . . . . . 208
6.2.5.6 Test cases and steps inherited from a variant module . . . 209
6.2.5.7 Renumbering test cases . . . . . . . . . . . . . . . . . . . 209
6.2.6 Test Results view . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.2.7 Evaluation Macros view . . . . . . . . . . . . . . . . . . . . . . . . 211
6.2.8 Console view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.2.8.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 212
6.2.8.2 Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.9 Suspicious Elements view . . . . . . . . . . . . . . . . . . . . . . . 213
6.2.10 Variants view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3 C/C++: Editing the C-source . . . . . . . . . . . . . . . . . . . . . . . . 217
6.3.1 Opening the C/C++ perspective . . . . . . . . . . . . . . . . . . . 217
6.3.2 Structure of the C/C++ perspective . . . . . . . . . . . . . . . . . 218
6.3.3 Editor view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.3.3.1 Editing the C-source file . . . . . . . . . . . . . . . . . . 219
6.3.4 Project Explorer view . . . . . . . . . . . . . . . . . . . . . . . . . 220
6.3.5 Outline view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.3.5.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 221
6.3.6 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.3.7 Console view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

TESSY 4.0 Manual ix

 6.4 Requirement management . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.4.1 Structure of the Requirement Management perspective . . . . . . . 224
6.4.2 RQMT Explorer view . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.4.2.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 226
6.4.2.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 227
6.4.2.3 Creating requirements and organizing a document structure227
6.4.2.4 Importing requirements . . . . . . . . . . . . . . . . . . . 228
6.4.2.5 Committing requirements . . . . . . . . . . . . . . . . . . 231
6.4.2.6 Renaming a document / alias . . . . . . . . . . . . . . . 233
6.4.3 Requirements List view . . . . . . . . . . . . . . . . . . . . . . . . 234
6.4.3.1 Icon of the view tool bar . . . . . . . . . . . . . . . . . . 235
6.4.4 Requirement Editor view . . . . . . . . . . . . . . . . . . . . . . . 235
6.4.4.1 Icon of the view tool bar . . . . . . . . . . . . . . . . . . 235
6.4.4.2 Viewing requirements, versions, IDs . . . . . . . . . . . . 236
6.4.4.3 Editing requirements . . . . . . . . . . . . . . . . . . . . 237
6.4.5 Validation Matrix view / VxV Matrix view . . . . . . . . . . . . . . 238
6.4.5.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 239
6.4.6 Test Means view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.4.6.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 240
6.4.7 Link Matrix view . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.4.7.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 240
6.4.7.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 241
6.4.7.3 Adding and removing elements . . . . . . . . . . . . . . . 241
6.4.7.4 Updating requirement links . . . . . . . . . . . . . . . . . 244
6.4.8 Suspicious Elements view . . . . . . . . . . . . . . . . . . . . . . . 245
6.4.8.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 246
6.4.8.2 Determine changes that caused suspicious status . . . . . 246
6.4.9 Attached Files view . . . . . . . . . . . . . . . . . . . . . . . . . . 250
6.4.9.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 250
6.4.10 Attributes view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
6.4.10.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 251
6.4.10.2 Editing attributes of a requirement . . . . . . . . . . . . . 252
6.4.11 History view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.11.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 254
6.4.12 Differences view / Reviewing changes . . . . . . . . . . . . . . . . 254
6.4.12.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 255
6.4.13 Related Elements view . . . . . . . . . . . . . . . . . . . . . . . . 256
6.4.14 Problems view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

x TESSY 4.0 Manual

 6.4.15 Document Preview . . . . . . . . . . . . . . . . . . . . . . . . . . 259
6.4.15.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 260
6.4.15.2 Editing the requirement as HTML version . . . . . . . . . 260
6.4.16 Requirements Coverage view . . . . . . . . . . . . . . . . . . . . . 261
6.4.16.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 261
6.4.16.2 Planning tab . . . . . . . . . . . . . . . . . . . . . . . . 262
6.4.16.3 Execution tab . . . . . . . . . . . . . . . . . . . . . . . . 263
6.4.16.4 Linking requirements with test cases . . . . . . . . . . . . 264
6.5 TEE: Configuring the test environment . . . . . . . . . . . . . . . . . . . . 266
6.5.1 Starting the TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
6.5.2 Structure of the TEE . . . . . . . . . . . . . . . . . . . . . . . . . 268
6.5.3 Icons of the tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . 269
6.5.4 Status indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6.5.5 Viewing all available configurations . . . . . . . . . . . . . . . . . . 272
6.5.6 Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
6.5.7 Customizing the configurations . . . . . . . . . . . . . . . . . . . . 275
6.5.7.1 Enabling configurations . . . . . . . . . . . . . . . . . . . 276
6.5.7.2 Adding configurations . . . . . . . . . . . . . . . . . . . . 277
6.5.7.3 Adjusting enabled configurations . . . . . . . . . . . . . . 278
6.5.7.4 Assigning an existing configuration file to your project . . 281
6.6 TIE: Preparing the test interface . . . . . . . . . . . . . . . . . . . . . . . 282
6.6.1 Structure of the TIE perspective . . . . . . . . . . . . . . . . . . . 283
6.6.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6.6.3 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6.6.4 Interface view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
6.6.4.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 285
6.6.4.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 285
6.6.4.3 Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 285
6.6.4.4 Interface elements . . . . . . . . . . . . . . . . . . . . . 286
6.6.4.5 Setting passing directions . . . . . . . . . . . . . . . . . . 287
6.6.4.6 Setting the data format . . . . . . . . . . . . . . . . . . . 289
6.6.4.7 Setting passing direction of special data types . . . . . . . 290
6.6.4.8 Defining stubs for functions . . . . . . . . . . . . . . . . 291
6.6.4.9 Other interface settings . . . . . . . . . . . . . . . . . . . 293
6.6.4.10 Creating new variables . . . . . . . . . . . . . . . . . . . 294
6.6.4.11 Using alias names . . . . . . . . . . . . . . . . . . . . . . 295
6.6.5 Plot Definitions view . . . . . . . . . . . . . . . . . . . . . . . . . 296
6.6.5.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 297

TESSY 4.0 Manual xi

 6.6.5.2 Creating plots . . . . . . . . . . . . . . . . . . . . . . . . 297
6.6.5.3 Reporting plots . . . . . . . . . . . . . . . . . . . . . . . 299
6.7 CTE: Designing the test cases . . . . . . . . . . . . . . . . . . . . . . . . 300
6.7.1 The basic idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.7.2 Starting CTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.7.3 Structure of the CTE perspective . . . . . . . . . . . . . . . . . . . 301
6.7.4 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
6.7.5 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
6.7.6 Classification Tree view . . . . . . . . . . . . . . . . . . . . . . . . 302
6.7.6.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 302
6.7.6.2 Structure of the Classification Tree view . . . . . . . . . . 303
6.7.6.3 Creating classifications, classes and test cases . . . . . . . 304
6.7.7 Test Data view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
6.7.7.1 Assigning test data to the CTE . . . . . . . . . . . . . . 308
6.7.8 Test data assignment precedence rules . . . . . . . . . . . . . . . . 309
6.8 TDE: Entering test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
6.8.1 Structure of the TDE perspective . . . . . . . . . . . . . . . . . . . 312
6.8.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
6.8.3 Test Results view . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.4 Evaluation Macros view . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.5 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.6 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.7 Test Data view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
6.8.7.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 316
6.8.7.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . 316
6.8.7.3 Viewing the interface of the test object . . . . . . . . . . 317
6.8.7.4 Entering values . . . . . . . . . . . . . . . . . . . . . . . 320
6.8.7.5 Set passing to IRRELEVANT . . . . . . . . . . . . . . . . 326
6.8.7.6 Entering evaluation modes . . . . . . . . . . . . . . . . . 327
6.8.7.7 Ignoring values for a test step . . . . . . . . . . . . . . . 328
6.8.7.8 Generating test steps automatically . . . . . . . . . . . . 329
6.8.7.9 Changing inherited values . . . . . . . . . . . . . . . . . 332
6.8.7.10 Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
6.8.7.11 Static local variables . . . . . . . . . . . . . . . . . . . . 334
6.8.8 Test Definition view . . . . . . . . . . . . . . . . . . . . . . . . . . 335
6.8.9 Declarations / Definitions view . . . . . . . . . . . . . . . . . . . . 336
6.8.10 Prolog/Epilog view . . . . . . . . . . . . . . . . . . . . . . . . . . 337
6.8.10.1 Defining and overwriting inherited code . . . . . . . . . . 339

xii TESSY 4.0 Manual

 6.8.10.2 Entering C code . . . . . . . . . . . . . . . . . . . . . . . 341
6.8.10.3 Using evaluation macros . . . . . . . . . . . . . . . . . . 342
6.8.11 Stub Functions view . . . . . . . . . . . . . . . . . . . . . . . . . . 346
6.8.11.1 Using Stub Functions . . . . . . . . . . . . . . . . . . . . 347
6.8.12 Usercode Outline view . . . . . . . . . . . . . . . . . . . . . . . . 350
6.8.13 Plots view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
6.8.13.1 Test Item Tree . . . . . . . . . . . . . . . . . . . . . . . 352
6.8.13.2 Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
6.8.14 Plot Definitions view . . . . . . . . . . . . . . . . . . . . . . . . . 353
6.9 CV: Analyzing the coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 354
6.9.1 Structure of the CV perspective . . . . . . . . . . . . . . . . . . . 355
6.9.2 Instrumentation for coverage measurements . . . . . . . . . . . . . 355
6.9.3 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
6.9.4 Called Functions view / Code view . . . . . . . . . . . . . . . . . . 359
6.9.5 Flow Chart view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
6.9.5.1 Icons of the view tool bar . . . . . . . . . . . . . . . . . 361
6.9.5.2 Viewing functions . . . . . . . . . . . . . . . . . . . . . . 361
6.9.5.3 Selecting elements . . . . . . . . . . . . . . . . . . . . . 363
6.9.5.4 Searching for uncovered decisions and unreached branches 363
6.9.6 Statement (C0) Coverage view . . . . . . . . . . . . . . . . . . . . 364
6.9.6.1 Coverage percentage . . . . . . . . . . . . . . . . . . . . 365
6.9.7 Branch (C1) Coverage view . . . . . . . . . . . . . . . . . . . . . . 365
6.9.7.1 Coverage percentage . . . . . . . . . . . . . . . . . . . . 366
6.9.8 Decision Coverage view . . . . . . . . . . . . . . . . . . . . . . . . 366
6.9.9 MC/DC Coverage view . . . . . . . . . . . . . . . . . . . . . . . . 367
6.9.9.1 Selecting decisions . . . . . . . . . . . . . . . . . . . . . 369
6.9.10 MCC Coverage view . . . . . . . . . . . . . . . . . . . . . . . . . . 369
6.9.11 Coverage Report views . . . . . . . . . . . . . . . . . . . . . . . . 369
6.10 IDA: Assigning interface data . . . . . . . . . . . . . . . . . . . . . . . . . 370
6.10.1 Structure of the IDA perspective . . . . . . . . . . . . . . . . . . . 371
6.10.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
6.10.3 Test Project view . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
6.10.4 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
6.10.5 Compare view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
6.10.5.1 Comparing interfaces and assigning changes . . . . . . . . 373
6.10.5.2 Assigning test cases to other test objects . . . . . . . . . 374
6.11 SCE: Component testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
6.11.1 Creating component tests . . . . . . . . . . . . . . . . . . . . . . . 377

TESSY 4.0 Manual xiii

 6.11.2 Preparing the test interface . . . . . . . . . . . . . . . . . . . . . . 379
6.11.3 Configuring the work tasks . . . . . . . . . . . . . . . . . . . . . . 380
6.11.4 Designing the test cases . . . . . . . . . . . . . . . . . . . . . . . . 382
6.11.5 Editing scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
6.11.5.1 Adding Function Calls . . . . . . . . . . . . . . . . . . . 383
6.11.5.2 Entering test data for time steps . . . . . . . . . . . . . . 384
6.11.5.3 Checking return values of component functions . . . . . . 386
6.11.5.4 Checking the calling sequence . . . . . . . . . . . . . . . 386
6.11.5.5 Checking if a function is not called . . . . . . . . . . . . 387
6.11.5.6 Checking stub function parameters . . . . . . . . . . . . . 388
6.11.6 Executing the scenarios . . . . . . . . . . . . . . . . . . . . . . . . 388
6.12 Backup, restore, version control . . . . . . . . . . . . . . . . . . . . . . . . 389
6.12.1 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
6.12.2 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
6.12.2.1 Restore into the original location . . . . . . . . . . . . . . 390
6.12.2.2 Restore into another location . . . . . . . . . . . . . . . . 391
6.12.3 Version control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
6.13 Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
6.13.1 Starting TESSY in headless mode . . . . . . . . . . . . . . . . . . 393
6.13.2 Invoking tessycmd.exe . . . . . . . . . . . . . . . . . . . . . . . . . 394
6.13.3 Usage of tessycmd.exe . . . . . . . . . . . . . . . . . . . . . . . . 394
6.13.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
6.13.5 Example: DOS script . . . . . . . . . . . . . . . . . . . . . . . . . 396

7 Troubleshooting 398
7.1 Contacting the TESSY support . . . . . . . . . . . . . . . . . . . . . . . . 399
7.2 Solutions for known problems . . . . . . . . . . . . . . . . . . . . . . . . . 403
7.2.1 TESSY does not start or gives errors when starting . . . . . . . . . 403
7.2.2 TESSY gives errors when quitted . . . . . . . . . . . . . . . . . . . 404
7.2.3 License server does not start or gives errors . . . . . . . . . . . . . 405
7.2.4 Working with constant variables . . . . . . . . . . . . . . . . . . . 406
7.2.4.1 Assignment of read-only variables . . . . . . . . . . . . . 407

Appendix 411

A Abbreviations 412

B Glossary 414

xiv TESSY 4.0 Manual

C List of Figures 419

D List of Tables 430

Index 433

TESSY 4.0 Manual xv

xvi TESSY 4.0 Manual
Preface

About TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

How to use this manual . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Subject matter . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Safety Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Core workflow and registration for safety information . . . . . . . . . xxiii
Verification and certification of TESSY . . . . . . . . . . . . . . . . xxiv
Instrumentation for coverage measurement . . . . . . . . . . . . . . xxiv
Adaptation to target environment . . . . . . . . . . . . . . . . . . . xxv
Operating limits . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
New features in TESSY 4.0 . . . . . . . . . . . . . . . . . . . . . . . . xxvii
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Software variant management . . . . . . . . . . . . . . . . . . . . xxvii
Optimizations in command line mode . . . . . . . . . . . . . . . . . xxviii
Support for test driven development . . . . . . . . . . . . . . . . . xxviii
UUID for all TESSY objects . . . . . . . . . . . . . . . . . . . . . xxviii
Auto-reuse in command line execution . . . . . . . . . . . . . . . . xxix
Excluding individual tests . . . . . . . . . . . . . . . . . . . . . . . xxix

TESSY 4.0 Manual xvii

Preface

About TESSY

The test system TESSY was developed by the Research and Technology Group of Daimler.
The former developers of the method and tool at Daimler were:
Klaus Grimm
Matthias Grochtmann
Roman Pitschinetz
Joachim Wegener

TESSY has been well-tried in practice at Daimler and is since applied successfully. TESSY is
commercially available since spring 2000 and is further developed by Razorcat Development
GmbH.

TESSY offers an integrated graphic user interface conducting you comfortably through the
unit test. There are special tools for every testing activity as well as for all organizational
and management tasks.

Dynamic testing is indispensable when testing a software system. Today, up to 80% of the
development time and costs go into unit and integration testing. It is therefore of urgent
necessity to automate testing processes in order to minimize required time and costs for
developing high-quality products. The test system TESSY automates the whole test cycle;
unit testing for programs in C/C++ is supported in all test phases. The system also takes
care of the complete test organization as well as test management, including requirements
coverage measurement and traceability.

xviii TESSY 4.0 Manual

 How to use this manual

How to use this manual

Apply for our e-mail list if you want to be informed of a new version of TESSY
manual by sending an e-mail to support@razorcat.com.

Refer as well to our detailed application notes regarding compiler/target settings

and other specific themes that are available in the Help menu of TESSY (“Help”
> “Documentation”).

Subject matter

The structure of the manual guides you through working with TESSY from the start to
the specific activities possible. In order:

section matter

Preface Describes New features in TESSY 4.0 and contains important informa-
tion about Safety Manual and Troubleshooting.

1 Installation Lists all technical requirements to work with TESSY and describes how
and to install the software.
registration

2 Migrating Lists the changed and new functions and handling within the new version.
from TESSY This will help you when switching from TESSY version 3.x to the new
3.x to 4.x TESSY 4.x.

3 General Explains the workflow of Creating databases and working with the file
handling system. Check this section carefully to know how to handle your project
data! The TESSY interface and basic handling is explained in the follo-
wing sections Understanding the graphical user interface and Using the
context menu and shortcuts.

4 Basic Contains a brief introduction about unit testing with TESSY and the
knowledge classification tree method.

continue next page

TESSY 4.0 Manual xix

Preface

section matter

5 Practical In this chapter you will get to know TESSY with the help of exe-
exercises rcises that are prepared to follow easily though most functions of TESSY:

Quickstart 1: Unit test exercise is_value_in_range is a very basic

example to give you a fast introduction.
Quickstart 2: The Classification Tree Editor (CTE) gives a short and
easy introduction of handling with the Classification Tree Editor (CTE).
It continues the Quickstart 1: Unit test exercise is_value_in_range.
Quickstart 3: Component test exercise interior_light gives you a
complete overview about working with TESSY, including all main
functions of unit testing, e.g. requirement management.
Quickstart 4: Exercise C++ gives gives a short and easy introduction
of handling with a C++ source file.

We recommend strongly to check the practical exercises!

It is very much easier to learn by doing than learning by
just reading. Exercise first and then check the detailed
information in the corresponding section of chapter “Wor-
king with TESSY”.

6 Working with Explains in detail the unit test activities possible with TESSY.
TESSY
As you will notice, the headlines of the sections follow the acti-
ons taken during a test. TESSY provides different editors and windows
(“perspectives” and “views”) for different configurations and steps
taken during and after a test. You will find the name of the perspective
or view as well as the description of the step within the headline, e.g.
6.7 CTE: Designing the test cases.
Therefore, if you need help at some point, ask either “How do I handle
. . . ?” or “Where am I?” and follow the headlines.

Important: Read the General handling first, because ba-

sic functions of each editor are explained there.

7 Troubleshooting Contains information of Solutions for known problems and how to get in
touch with the TESSY support if needed.

continue next page

xx TESSY 4.0 Manual

 How to use this manual

section matter

Appendix Contains a list of tables, a list of figures, a list of used abbreviations as

well as definitions of used terms in the glossary. Check the glossary when
you need some explanations of terms!
The index in the very end of this manual provides the positions of your
theme of interest.

Table 0.1: Where to find - matters of the several parts of the TESSY manual

Helpers

• The Index in the very end of this manual helps you by looking up a theme by a
keyword.
The sidearrow
• Various information is clearly represented within tables, e.g. icons and indicators shows where to
find information
(symbols of the interface) and their meanings. For a fast access to all tables consult and references.
the List of Tables in the appendix of this manual.

• Figures are used to demonstrate information described before. You may as well check
the List of Figures to find those figures.

• All cross references as well as the content directory are active links (blue colored),
so you can easily switch to the referenced chapter or section.

Information box

Gray bordered information boxes

provide further information and explanations for the respective issues and operations
to be executed. The information will give you an overview, while the practical part
is explained in the following section.

Font characters and signs

To help you to work with this manual, different font characters and signs are used to mark
specific information:

TESSY 4.0 Manual xxi

Preface

what for example

Þ instructions you are supposed to Þ Open the TESSY interface.

follow immediately

> navigation through a menue Þ Select “File” > “Open . . . ”

[. . . ] variable Þ Switch to “[project root]\tessy”

bold accentuation Important:

typewriter input (you need to type this in- Enter Test Example .
italic formation) or output (message
from system)

“typewriter path of data “C:\Program Files\Razorcat”

in quotes”

“quotes” indicate keys, buttons, etc. Þ Select “File” > “Open . . . ”

Ctrl+C Keyboard characters are not Ctrl+C for pressing control and c
marked in supposition they are
commonly known.

Table 0.2: Font characters

Important: You urgently need to know this for operating correctly!

Warning: There might be some damages to your data if you do not operate
correctly! Please follow instructions carefully.

A light bulb provides hints, references and additional information on handling with
TESSY for better usability.

xxii TESSY 4.0 Manual

 Safety Manual

Safety Manual

Core workflow and registration for safety information

Important: If you work with TESSY in a safety-relevant environment, please

read this chapter carefully and register for our safety customer e-mail-list to be
informed about known problems as described below!

TESSY can be used for testing of safety-relevant software. Therefore, the core workflow
of TESSY as well as the release and test process of the TESSY product has been certified
according to ISO 26262-08:2011 and IEC 61508-3:2010. Our quality management system
ensures proper handling of all development processes for the TESSY product and constantly
improves all procedures concerning quality and safety.

Figure 0.1: Core workflow of TESSY

The figure above shows the core workflow of TESSY that is fully automated and subject
to tool qualification. All other tool capabilities like editing or environment and interface
settings are additional features out of scope of the tool qualification. The core workflow of
TESSY has been certified according to ISO 26262:2011 and IEC 61508:2010. Starting from
editing of test data, the core workflow covers test execution, evaluation of test results and
report generation. Additionally, the coverage measurements have been verified according
to our certified safety plan. Please note, that the Classification Tree Editor (CTE) which

TESSY 4.0 Manual xxiii

Preface

covers test preparation activities is not part of the certified core workflow of TESSY.
Safety-relevant problems arising in released TESSY versions will be reported (once they
are detected) and regarded closely to have them fixed as fast as possible. If you work
with TESSY in a safety-related environment, please register for our safety customer
e-mail-list:

Þ Send an e-mail to support@razorcat.com

Þ Topic: “Known problems requested”

Þ Content: your contract data

You will be informed about current and newly arising “known problems” as well as worka-
rounds.

Verification and certification of TESSY

The “Tool Qualification Pack” (TQP) is an additional purchase of documents and tests
for TESSY, provided as baseline for the certification process in order to qualify TESSY as
a software verification tool according to DO-178B/C.
Please contact via support@razorcat.com.

Additionally, TESSY has been qualified by the german certification authority TÜV SÜD
Rail GmbH as a testing tool for usage in safety-related software development according to
ISO 26262 and IEC 61508. The TÜV certificate and a certification report is available on
http://www.razorcat.com.

The TQPack contains tests for ANSI-C compliant source code using the GNU GCC compiler
that is part of the TESSY installation. Using an embedded compiler/debugger for a specific
microcontroller requires adaptation of the TQPack for this specific target environment.
This can be provided as an engineering service by Razorcat.

Instrumentation for coverage measurement

When executing tests using coverage measurements, it is recommended that all tests are
executed once with and once without coverage instrumentation. TESSY uses a copy of
the original source file when creating the test application. This copy of the source file
will be instrumented for coverage measurements. Usually both test runs yield the same
result, indicating that the instrumentation did not change the functional behavior of the
test objects.

xxiv TESSY 4.0 Manual

 Safety Manual

Please note, that the source code will be instrumented even if no coverage measurement
has been selected in the following cases:

• When using the call trace feature

• When using static local variables

Some extra code will be added at the end of the copied source file in the following cases:

• When testing static functions

• When using static global variables

Please keep this behavior in mind when preparing and executing tests with TESSY.

Adaptation to target environment

When running tests on a specific target platform, adaptations of compiler options and
target debugger settings may be needed within the respective target environment. The
verification of the TESSY core workflow covers tests conducted on a Windows host system
using the GNU GCC compiler. In order to verify the transmission of test data and expected
results to and from the target device, there are tests available that may be executed using
the adapted target environment. These tests check the communication layers of the test
driver application.

For details on how to run these tests refer to the application note “048 Using Test
Driver Communication Tests.pdf” within the TESSY installation directory.

It is recommended to run these tests with your specific compiler/target environment.

Operating limits

TESSY is constructed for usage as a unit testing tool in order to verify the functional
correctness of the function under test. The following restrictions and prerequisites for
TESSY apply:

TESSY 4.0 Manual xxv

Preface

• The source code to be tested shall be compilable without errors and warnings
by the compiler of the respective microcontroller target. TESSY may fail
analyzing the interface of the module to be tested, if there are syntactical
errors within the source code.

• TESSY does not check any runtime behavior or timing constraints of the
function under test.

• The test execution on the target system highly depends on the correct con-
figuration of the target device itself, the correct compiler/linker settings
within the TESSY environment and other target device related settings within
TESSY (if applicable). Any predefined setup of the TESSY tool for the sup-
ported devices requires manual review by the user to ensure proper operation
of the unit testing execution.

• The usage of compiler specific keywords and compiler command line settings
may require additional tests for tool qualification. Correct operation of the
TESSY toolset with respect to the Qualification Test Suite (QTS) test results
is only provided for ANSI compliant C code.

Since TESSY v4.x the test driver code will be generated and attached at the end of (a
copy of) each source file. The following restrictions apply:

• All types used within usercode must be available within the source file of the
respective test object.

• When using usercode definitions/declarations on module level, all used types

must be available within all source files of the module.

For backward compatibility, you can disable the usage of the new CLANG parser and test
driver generation by setting the attribute “Enable CLANG” to “false” within the project
configuration using the environment editor TEE.

xxvi TESSY 4.0 Manual

 New features in TESSY 4.0

New features in TESSY 4.0

Note the chapter Migrating from TESSY 3.x to 4.x and check as well the Practical
exercises to learn about TESSY´s new features!

C++

TESSY now integrates the CLANG parser for analysis of C++ source files and provides
a new test driver generator to support testing of all C++ features including templates
and derived classes. The interface and constructors of each C++ class are available for
testing and the TDE provides convenient editing of test data. Powerful reuse of test data
by assigning the new to the old C++ interface elements allows easy regression testing.

Warning: If you open an existing module created with TESSY v3.2 or earlier,
you will be warned that this module will be converted to the new interface data-
base format. Please refer to Analyzing modules for more information about the
available options.

Please note that Component testing of C++ modules is not yet supported.

Software variant management

Testing different but related configurations of software is now supported by the variant
management of modules and test cases: Starting from a base module with test cases for
all variants you can derive sub modules for each individual variant configuration. Such
variant modules can overwrite or delete the base test cases or provide additional test cases
specific for the given variant. Changes to the base module and tests will be propagated to
all sub modules automatically.

Refer to Creating variant modules and Test cases and steps inherited from a variant module
for details about creating and editing test cases within variant modules.

TESSY 4.0 Manual xxvii

Preface

Optimizations in command line mode

The test execution (building the test driver and execution on the target) can now run in
parallel depending on the number of available cores of the host PC. Also the restore of
TMB files now runs in parallel. These optimizations greatly reduce the time required for
automated test runs, especially on continuous integration servers (e.g. Jenkins).

Support for test driven development

Support for test driven development has been added: You can now add test objects to
modules without having a source file in place. For such test objects you can also add varia-
bles for values being used for calculations by the test object according to the specification.
In this way, you can prepare your tests before any code is available. Later when the first
code is implemented, all tests can be assigned to the real implementation modules using
the normal IDA assign operation.

Refer to Quickstart 5: Test driven development (TDD) for an example on how to use
this feature.

UUID for all TESSY objects

All the following model elements of TESSY will get a UUID assigned to uniquely identify
them even after save and restore via TMB files on different computers:

• Test collections and folders

• Modules

• Test objects

• Test cases and test steps

xxviii TESSY 4.0 Manual

 New features in TESSY 4.0

Figure 0.2: UUID property of TESSY objects

Existing projects will be updated automatically when opened using TESSY v4.

Auto-reuse in command line execution

Enhanced auto-reuse in command line execution mode provides more stable regression test
results in case of slightly changed interfaces as follows:

• New unused struct or union members

• New unused defines

• Changed called function hierarchy

• Removed interface elements or defines

All those interface changes will be ignored when opening modules in command line mode.

Excluding individual tests

Tests that cannot be executed for some reason (e.g. which would fail due to null pointer
access) can be excluded from the test execution. Such tests are displayed faded and they
are automatically skipped when executing all tests of a test object.

TESSY 4.0 Manual xxix

Preface

Figure 0.3: Exclude test items from the test

xxx TESSY 4.0 Manual

1 Installation and registration

1.1 Technical requirements

• Windows 10 (32bit/64bit), Windows 8 (32bit/64bit), Windows 7

(32bit/64bit), Windows Vista (32bit/64bit) or Windows XP (ServicePack
2 or higher).

• TESSY 4.0 can be installed and run in parallel to any previous major TESSY
version.

• For the reports you need at least Adobe Reader 7.0.

• To run TESSY 4.0 you need at least a 1.5 GHz CPU and 2 GB RAM for
TESSY.

1.2 Setup

Warning: Deactivate your firewall or virus scanner temporarily while installing

TESSY! Otherwise the firewall can cause problems during the installation. Note
that some firewalls and anti-virus software can limit the functionality of applica-
tions, including TESSY and might need to be modified. For further help ask the
producer of the firewall or anti-virus software.

Important: You need local administrator privileges to install TESSY!

TESSY allows you to have multiple TESSY installations with different versions on the same
computer. You do not have to uninstall an older version.

TESSY 4.0 Manual 1

1 Installation and registration

To install TESSY 4.0 on your computer,

Þ insert the TESSY-DVD into the DVD drive and wait for the setup program to
start OR start the installation program manually (“tessy[version number].exe”).

The InstallAware Wizard will start. This will take a few moments.

Þ When the InstallAware Wizard is ready, click “Next”.

Figure 1.1: InstallAware Wizard

Þ Read the license agreement carefully. Check the box to accept and click “Next”.

Þ Now select the setup type: “Complete” (default) is recommended. click “Next”.

Þ Select the destination folder (default “C:\Program Files\Razorcat”) and

click “Next”.

2 TESSY 4.0 Manual

 1.2 Setup

Figure 1.2: Destination Folder

Þ Select the TESSY testarea folder (“Folder for temporary files:”; default
“C:\tessy”) click “Next”.

Figure 1.3: TESSY Testarea Folder

Þ Select the program folder (default “TESSY 4.0”) and decide, whether the
installation on the system is for “all users” or for a certain user. Click “Next”.

TESSY 4.0 Manual 3

1 Installation and registration

Figure 1.4: Program folder and user selection

Þ Start the installation by clicking “Next”.

The installation will take a few moments.

Figure 1.5: Installing process of TESSY

Þ When the InstallAware Wizard is completed, click “Finish”.

4 TESSY 4.0 Manual

 1.3 Registration

Figure 1.6: Installation is completed

Now you have completed the installation of TESSY.

1.3 Registration

Important: To register TESSY 4.x you need access to the internet!

1.3.1 Requesting a license key

Þ Start TESSY by selecting in Windows “Start” > “All Programs” > “TESSY
4.0” > “TESSY 4.0” (see fig. 1.7).

TESSY 4.0 Manual 5

1 Installation and registration

Figure 1.7: Starting TESSY 4.0

If a valid license is found, TESSY will start. If there is no valid license, the License Manager
will start with a License Key Request popup window (see figure 1.9).

To start the request manually,

Þ start the License Manager by selecting in Windows “Start” > “All Programs”
> “TESSY 4.0” > “Floating License Manager”.

Þ Click on “License” > “Request” (see figure 1.8).

Figure 1.8: Starting the key request

6 TESSY 4.0 Manual

 1.3 Registration

The License Key Request popup window will appear (see figure 1.9).

Figure 1.9: License key request popup window

Þ Click on “Online Request” and fill out the form for a license key request.

TESSY 4.0 Manual 7

1 Installation and registration

Figure 1.10: Form for the license key request

You will get a license key via e-mail within a license key file. The license key file is a plain
text file with the ending .txt.

Important: The license key file is not generated and send out automatically,
therefore it can take up to a workday until you receive it!

1.3.2 Registrating the license

When you have received the license key file (*.txt file),

Þ open the license manager.

Þ If you have already received a license key file: Click on “Done”.

The Configure window for the License Server will open (see figure 1.11).

8 TESSY 4.0 Manual

 1.3 Registration

Figure 1.11: Configure menu of the license server

Þ Under “License Key File” choose your license key file (*.txt).

Þ Tick the box “Autostart” to start the license server hereafter in the background.
The system will try to set the autostart. If you do not have administrator
privileges, the autostart is set for your windows user.

Þ Optional: You can run the license server as service (select “Service” under
“Run Local Server”). The default is “Application”. If you wish to remove the
service from the registry, tick the accordingly box under “Settings”.

Important: You need administrator privileges to run the license

server as service and to remove it from the registry!

Þ Click on “OK”.

The license server will start automatically. If not, click on (Start Local
Server).

Þ Close the License Manager and start TESSY by selecting “Start” > “All Pro-
grams” > “TESSY 4.0” > “TESSY 4.0”.

TESSY 4.0 Manual 9

1 Installation and registration

1.3.3 The License Manager

Þ To start the License Manager manually select “Start” > “All Programs” >
“TESSY 4.0” > “TESSY 4.0” > “Floating License Manager”.

Þ To start the server manually click on the icon (Start Local Server).

Þ To stop the server manually click on (Stop Local Server).

Þ To configure the server click on (Configure).

Þ To check your license key file click on (Check). This can be useful to
determine the error if the server does not start.

Figure 1.12: License key check successful: this license key is correct

1.4 Uninstallation

Important: By uninstalling TESSY the project root will not be deleted, neither
your project data or your configuration file will be deleted. But anyway make sure
that your data is saved.

To uninstall and remove all components of TESSY,

Þ in Windows click “Start” > “All Programs”.

Þ “TESSY 4.0” > “Uninstall TESSY”

All components of TESSY will be removed. This will take a few seconds.

10 TESSY 4.0 Manual

 1.5 Using license part-time on another computer

1.5 Using license part-time on another computer

Important: For using your TESSY license part-time on another computer, you
need a “Floating License”.

You can check-out your TESSY floating license on your computer and import it on another
computer to work with TESSY on another system.

This check-out option Checking-out a

License
• is only possible with a TESSY floating license.

• is for 30 days altogether: You can check-out the license for one, for two or
up to 30 days each time, but overall for 30 days at the most.

• means, that you can use TESSY EITHER on computer 1 or on computer 2.

When you check-out the license on computer 1 for three days, you can not
use TESSY on computer 1 for the three days.

Important: It is not possible to return a checked-out license prematurely to

the computer from which the licenses were checked-out!

To check how many days are left for the check-out:

Þ In Windows klick on “Start” > “All Programs” > “TESSY 4.0” > “Floating
License Manager”.

Þ In the license manager click on “License” > “Info”.

Þ Next to “State” the amount of days for possible check-outs left will be displayed
(see figure 1.13).

Important: If the state says “disabled” contact your administrator!

TESSY 4.0 Manual 11

1 Installation and registration

Figure 1.13: The license info shows the possible days for checking out the license

1.5.1 Checking-out the license

Þ In the menu bar click on “License” > “Check Out. . . ” (see figure 1.14).

Þ Choose the amount of days. The Registration Information will be filled out
automatically (see figure 1.15).

Þ Click “ok” and save the file.

You can now use this license file on your second computer. To register the
license refer to section 1.3.2 Registrating the license.

Figure 1.14: Checking out the TESSY license

12 TESSY 4.0 Manual

 1.5 Using license part-time on another computer

Figure 1.15: Determine the amount of days for the check-out

You do not have to check-in your license again on computer 1! The license will be
activated automatically.

1.5.2 Using license part-time on a computer with no internet connection

To be able to use the TESSY floating licence on another computer with no internet con-
nection the procedure described in section 1.5 Using license part-time on another computer
needs to be modified.

Þ Open license manager on your computer with NO internet connection (see

1.3.3 The License Manager).

Þ In the menu bar click “License” > “Request...”.

Þ Copy the first 12 characters in “Registration Information” (see figure 1.9).

Þ Transmit these 12 charcters to your computer WITH internet connection.

Þ Insert the transmitted 12 characters into “Registration Information” (see figure

1.15) when checking-out your computer WITH internet connection (see section
1.5.1 Checking-out the license).

Þ Choose the amount of days, click “ok”, and save the license file.

Þ Make this file available on your computer with NO internet connection.

Þ You can now register this license file on your computer with NO internet con-
nection (see section 1.3.2 Registrating the license).

TESSY 4.0 Manual 13

1 Installation and registration

Figure 1.16: Transmitting the license file to a computer with no internet connection

14 TESSY 4.0 Manual

TESSY 4.0 Manual 15
 2 Migrating from TESSY 3.x to 4.x

In the new version of TESSY you will find some new functions as mentioned in section
New features in TESSY 4.0.

2.1 Importing previous projects

You will have to convert your projects to use them with the new TESSY 4.x version. When
you open a project, TESSY will ask you if you want to convert your project. By clicking
“Yes” TESSY will convert the project automatically.

Warning: Once you have converted your project it cannot used by TESSY 3.x
anymore! If you want to use your project with TESSY 3.x, make a copy of the
project.

Figure 2.1: Updating a project

16 TESSY 4.0 Manual

TESSY 4.0 Manual 17
 3 General handling

This chapter explains how to create databases for your test, how to work with the different
files and the graphical user interface of TESSY and provides some information about useful
shortcuts to work more efficient.

3.1 Creating databases and working with the file system . . . . . . . . . 19

3.1.1 Creating a project database . . . . . . . . . . . . . . . . . . 20
3.1.2 Creating, importing, cloning, editing, deleting a project . . . . 25
3.1.3 Creating a template project . . . . . . . . . . . . . . . . . . 26
3.1.4 Moving the project directory . . . . . . . . . . . . . . . . . 26
3.1.5 Handling with equally named projects . . . . . . . . . . . . . 27
3.1.6 Using a specific environment setting . . . . . . . . . . . . . . 29
3.1.7 Updating the database . . . . . . . . . . . . . . . . . . . . 29
3.2 Understanding the graphical user interface . . . . . . . . . . . . . . 31
3.2.1 Menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3 Perspectives and perspective (tool) bar . . . . . . . . . . . . 32
3.2.4 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.5 Status bar . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Using the context menu and shortcuts . . . . . . . . . . . . . . . . 37
3.3.1 Context menu . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

18 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

3.1 Creating databases and working with the file system

The following table provides a fast overview about TESSY’s file system and databases:

What does

Workspace Contains all Eclipse-related settings for TESSY (layout/size of

windows/perspectives/views) and the list of projects (the file
projects.xml). You can close TESSY, move the projects.xml somewhere
else, delete the entire directory, restart TESSY and restore the
projects.xml.

tessy.pdbx (file) Project file for the location of a TESSY project. The project can be
opened via double-click. Contains the basic settings of a project and
can be renamed.

Project root Specifies the root directory of your project, so that all paths (e.g.
sources, includes, etc.) can be related to this root. Every project will
have an own project root. The project root is saved in the project file
(tessy.pdbx) which allows you to transfer projects to other computers.

Source root Optional directory to specify source and include paths to this source
root independently from the project root (e.g. if you want source files
to reside in another directory outside the project root). The source
root as an absolute path is intentionally not saved in the project file
(tessy.pdbx), only its existence is indicated. Therefore the source root
needs to be selected when opening a project on a different computer.
When opening such a project using the command line, the source root
needs to be provided as command line argument. For more information
about the CLI mode please refer to section 6.13 Command line
interface.

Configuration Contains appropriate target environments for the project database

file which can be defined with the Test Environment Editor and will be
stored by default under [project root]/tessy/config.

persist (folder) Contains the databases for the project, one for requirements and test
collections, the other one for test data.

work (folder) Contains all temporary files generated during the test process. This
entire directory can be deleted without loosing any data of the TESSY
project.

continue next page

TESSY 4.0 Manual 19

 3 General handling

What does

TMB files Format to store your backups, usually under

[project root]/tessy/backup.

Table 3.1: File system and databases of TESSY

3.1.1 Creating a project database

Þ Start TESSY by selecting “All Programs” > “TESSY 4.0” > “TESSY 4.0”.

Loading TESSY will take a few seconds.

The Select Project dialog will open. At top you can see the path of your
workspace (see figure 3.1).

If you already have opened a project before, TESSY will automati-

cally open the last project again on startup. To create a new project,
select “File” > “Select Project” in the menu bar.

Figure 3.1: Path of the workspace

Creating a new
project
Þ Click on (Create Project).

The Project Configuration dialog opens (see figure 3.2).

20 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

Figure 3.2: Creating a new project

Þ Enter the name of your project, e.g. Sample .

Þ Optional: Enter a description of your project.

Þ Select a project root: Click on “. . . ” and select a directory where your de-
velopment project resides, i.e. where source and header files are located and
where a sub directory “tessy” containing the test project shall be created (see
figure 3.3).
All the project-related TESSY databases containing information on
the test environment, referenced source files, compiler, debugger,
etc. will be stored within a sub folder of the project root and all
paths into your project will relate to this root.

Figure 3.3: Selecting a folder for the project root.

TESSY 4.0 Manual 21

 3 General handling

Þ Optional: Extend the “Advanced Settings” by clicking on the plus (see figure
3.4).

Advanced You have the following advanced option settings:

Settings
Source Root Use this option to provide an alternative root location for source files
if you want your source files to reside in another location than the
project root. In this case all path name references to source files and
include paths will automatically be collapsed using the source root
location.

Important: The source root location will be remem-

bered locally on each computer and the given absolute
path will by default not be stored into the TESSY pro-
ject file (tessy.pdbx). This means that if this option is
enabled and you want to open this project on another
computer, you will always be asked for the source root
location during the startup process.

Configuration Enter the path to a specific configuration file or leave the field blank
File to use the default configuration. TESSY will create a new
configuration file containing only the GNU/GCC compiler. Refer to
section 6.5.6 Configuration files about how to customize this
configration file.

Project You can choose a different location if you would like to locate the test
Location project files into another sub directory of the project root.

Important: The location has to be within the project

root directory!

continue next page

22 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

Database It is recommended to use the same directory as the project location

Location but you can choose another sub directory of the project root if you
want to separate the project database files from the other
configuration files of your test project.

If you tick the box “Store database in user profile” the database will
be stored in a directory named using the project identifier GUID
located within the “.tessy_persist” directory within the user
profile.

Backup This directory will be used to store all backup and settings files of
Location your project which are vital for your project in order to restore it on
another computer. Refer to section 6.12 Backup, restore, version
control for information about files that are relevant for version control.

It is recommended to use the default location but you can also choose
a different location preferably within the project root. It will be used
as standard for the backup and restore dialog.

Table 3.6: Options of the Project Configuration dialog

The project root and source root

By default the project root contains your development project, i.e. the source files,
and one sub folder “tessy” that contains all TESSY related files.
Additionally you can specify the source root to locate source and header files outside
the project root.
TESSY will use paths relative to those root paths for all files, e.g. references to
source and config files. This ensures that you can move whole projects to new
locations.
Please keep in mind that the source root location will always be remembered locally
on each computer and the given absolute path will not be stored into the TESSY
project file (tessy.pdbx). If you transfer a project with an indicated source root
to another computer, you need to provide the source root (e.g. as command line
argument when running in CLI mode). When opening such a project with the GUI,
TESSY will remind you and ask for the source root location.

TESSY 4.0 Manual 23

3 General handling

Figure 3.4: Creating a new project

Þ Click “OK”.

Now TESSY creates automatically a sub folder “tessy” within the project root
directory. This folder contains (within sub folders) the configuration file and
the persistence databases. This will take a few seconds. Afterwards TESSY
will restart (if another project was open before) and open the newly created
project automatically.

24 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

3.1.2 Creating, importing, cloning, editing, deleting a project

In the Select Project dialog you can create, import, clone, edit and remove or delete your
project with selecting the project and click on the icon in the tool bar:

Creates a new project.

Imports an existing project.

Clones a project: TESSY creates a complete copy of a project and adds it to the
project list. A new name is required.

Opens the Project Configuration dialog.

Important: Project root, project location and database location

cannot be modified subsequently!

Removes a project from the workspace. If you want to delete all data including
project and database location, tick the box “Delete project contents on disk”.

Warning: Deleted files cannot be restored! Before deleting make

sure the project is not needed anymore or backup the project as
described in section 6.12 Backup, restore, version control.

Table 3.8: Tool bar options of the Select Project dialog

TESSY 4.0 Manual 25

3 General handling

With a right-click you can open the context menu for further options:

Figure 3.5: Context menu of the Select Project dialog

3.1.3 Creating a template project

With a right-click on a project in the project list you can mark a project as “Template
Project” (see figure 3.5).

This will have the following effects:

• The project cannot be opened anymore!

• Doubleclicking the project or marking the project and click “Open Project”
will start the Project Configuration Dialog and the “Clone Project” command
(see section 3.1.2 Creating, importing, cloning, editing, deleting a project).

• Doubleclicking the PDBX file of the template project will start the Project
Configuration Dialog and the “Clone Project” command.

At anytime you can remove the mark as template project. The project will then
be a normal project and you can open it as usual.

3.1.4 Moving the project directory

You can move your whole project directory and then import the project again:

Þ Either double-click on the tessy.pdbx file or use the Import Project button.

TESSY will ask you, if the project was moved or copied (see figure 3.6).

26 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

Þ Answer this question correctly and click “OK”.

If the project was copied, e.g. you want to create a new project as a copy of
the original one, a new project identifier needs to be assigned to distinguish
the new project from the original one. TESSY will do this automatically.

Figure 3.6: Project identifier handling

3.1.5 Handling with equally named projects

In the “Select Project” dialog all projects are listed with name and local path.

Figure 3.7: Project Example1 is created.

TESSY 4.0 Manual 27

3 General handling

It is possible to handle projects with equal names. The table below explains in which way
TESSY will replace projects within the projects list if they have identical names:

status operation behavior and tip

Project named You create a new project You will get a warning:
’Alpha’ exists in ’Alpha’ in another “Project with identical name will be
location ’xy’. location. removed from the project list.”
The new project appears in the project
list, the old project will be removed from
the list (but not deleted!).

If you want to open the old project

again,
Þ click on “Import” and open the old
project. In that case the newer project
will again be removed from the list.

Project ’Alpha’ You try to create a new You will get an error, it is not possible to
exists in location project ’Alpha’ in the create the project, because two projects
’xy”. same location. cannot share the same location.

Þ Change the location of the new

project.

Project ’Alpha’ You open an existing You will get a note

exists in location project ’Alpha’ (either “Information: Project ’Alpha’ replaced
’xy’. with click on “Import” or within the project list.”
within the command line The second project appears in the
interface) in another project list, the first project will be
location ’Beta’. removed from the list (but not deleted!).

If you want to open the other project

again,
Þ click on “Import” and open the other
project.

Table 3.11: Handling of projects with equal names

28 TESSY 4.0 Manual

 3.1 Creating databases and working with the file system

3.1.6 Using a specific environment setting

Important: This section is only recommended for advanced users that have
already worked with TEE. For basic handling we recommend to continue with
section 3.2 Understanding the graphical user interface and following sections and
then return to this section.

TESSY will create a specific configuration file for each project database. This way you
can share the environment settings with other members of your development team. The
configuration file is stored within your project root together with other project related
files. Such a configuration file contains only the compiler/target environments you want
to use. All other environment configurations are not visible for the user as long as this file
is assigned to a given project database.

To customize the configuration file within the Test Environment Editor (TEE)

Þ refer to section 6.5.6 Configuration files.

3.1.7 Updating the database

After the update you cannot open the project in previous versions of TESSY!

TESSY will recognize, if an upate of the database is necessary (see figure 3.8).

TESSY 4.0 Manual 29

3 General handling

Figure 3.8: TESSY notifies, that a database update is necessary

When you want to open the project, you will be asked to update the database
(see figure 3.9).

Þ Click “OK”.

Figure 3.9: A database update is necessary

30 TESSY 4.0 Manual

 3.2 Understanding the graphical user interface

3.2 Understanding the graphical user interface

When TESSY starts the first time, the graphical user interface (GUI) will open within the
Overview perspective.
Please check the terminology shown in the figure “TESSY interface” and the explanations
beneath. This terminology will be used throughout this manual.

Figure 3.10: TESSY interface and its terminology

3.2.1 Menu bar

The menu bar provides actions as “File”, “Windows” etc. Within the “Help” you find the
online help of TESSY. Many of these actions may also be available within the context
menu of individual views, if the actions are applicable for the items within the view.

TESSY 4.0 Manual 31

3 General handling

3.2.2 Tool bar

At the global tool bar of TESSY interface you can select a project, save changes etc. By
rolling over an icon with the cursor a tooltip will tell you the purpose of each icon. There
may also be individual tool bars within the views. Here you find the tools for operating,
e.g. to start the test execution .

Save all changes in any views or editors by clicking the save icon .

3.2.3 Perspectives and perspective (tool) bar

TESSY contains several perspectives to present information based on different tasks in the
test workflow (“Requirement Management”, “Overview”, “TIE” etc.). Each perspective
offers several views. In the perspective bar (containing the perspective names) you can
switch between the different perspectives. The perspectives - from the left to the right -
follow the actions taken while preparing, running and evaluating a test.
Every perspective name has several right click menu options (the context menu).
By clicking on the left symbol you can open other perspectives (see figure 3.11):

Figure 3.11: Open other perspectives

32 TESSY 4.0 Manual

 3.2 Understanding the graphical user interface

3.2.4 Views

Figure 3.12: Test Project view within the Overview perspective

Every view in each perspective contains possibilities of configurations or provides presen-

tations of data. Some views are common to several perspectives (such as the properties
of sources), and some are specific to one perspective (such as the plots in the TIE).

Notice that the views appear differently combined with other views, e.g. the view Test
Results within the Overview perspective is combined with the Test Items view, but within
the TDE perspective it is combined with the Test Project view. The reason for the different
combinations is to give you a fast overview and comparison between various information
within each project step.

You can change the appearance of views for you own needs and open views of one per-
spective into another perspective: Adding views to
a perspective
Þ Activate (open) the perspective where you want to add a view.

Þ Click “Window” > “Show View”.

A window displaying all views will open (see figure 3.13).

Þ Select the view you want to open.

Þ Click “OK”.

The selected view is added to the active perspective.

TESSY 4.0 Manual 33

 3 General handling

Figure 3.13: Adding views to a perspective

Changing view Change the position of views with drag and drop:
position
Þ Click on a name of a view and move it where you like: You can move views
to another location within the same group of views or into another group of
views or even outside the current window.

Þ Right-click on the perspective switch and choose “Reset” to switch back to the
original positions of all views of the respective perspective (see figure 3.14).

Figure 3.14: Move the views separately. To switch back, use “Reset”.

34 TESSY 4.0 Manual

 3.2 Understanding the graphical user interface

To switch back all positions of perspectives and views: Resetting

workbench
Þ Choose “Window” > “Reset Workbench” from the menu bar (see figure 3.15).

Figure 3.15: To switch back all positions of views and perspectives use “Reset
Workbench”.

You can maximize and minimize views for better visibility. Maximize and
minimize views
To maximize a view,

Þ use the button within the right corner (see figure 3.16) or double click on the
tab of the view.

Figure 3.16: Minimizing and maximizing views

The view will be maximized and other views of the perspective will be minimized, displayed
by the view symbol on the left and the right (see figure 3.17).

To restore all views,

Þ click on the “Restore”-button on the upper left side.

TESSY 4.0 Manual 35

3 General handling

Figure 3.17: Maximized view with minimized views on the right and the restore-button
on the left

There are navigation views that present hierarchical structured data. Selections on such
tree items may cause other views or the editor pane to change the information being
displayed.

All views are context sensitive: If you select an item within one view, another view
might display other information. If something is not displayed correctly, make sure
you selected the desired item.

3.2.5 Status bar

The status bar provides status information about the application and current status, e.g.
the directory of the project root and the configuration file.

36 TESSY 4.0 Manual

 3.3 Using the context menu and shortcuts

3.3 Using the context menu and shortcuts

3.3.1 Context menu

Most contents, tabs etc. have options that are displayed in the context menu, which is
retrieved with a right click. It shows main operations as “Copy”, “Paste”, “Delete” etc.
The context menu is context sensitive and changes as different items are selected (see
figure 3.18).

Figure 3.18: Using the context menu with right click.

3.3.2 Shortcuts

You can operate within TESSY with several shortcuts by using the keyboard:

Important: For using shortcuts make sure to be in editing mode of the current
view! Otherweise the shortcut will not work.

Warning: You cannot reverse the deleting of data. Before deleting make sure
this database is really not needed anymore.

Function Shortcut / Keys Comment

copy Ctrl+C

continue next page

TESSY 4.0 Manual 37

 3 General handling

Function Shortcut / Keys Comment

cursor positioning tab Moves the cursor to the next input section on
right alternatively the right side of the line.
Ctrl+right arrow key Only within TDE.

cursor positioning Shift+tab Moves the cursor to the input section on the left
left alternatively side of the line.
Ctrl+left arrow key Only within TDE.

cut Ctrl+X Only possible for folders, modules and (synthe-

tic) testobjects, not for test items.

delete Del Only possible if the item to delete does not con-
tain any data or folders or modules!
Only manually created test cases can be deleted!
You cannot delete test cases created by CTE.
This prevents possible inconsistencies within the
CTE document.

generate test report Ctrl+R

new folder Shift+Ins

new module Ins Only possible, if a test collection or folder is se-

lected.

paste Ctrl+V

rename F2

start test execution Ctrl+E Executes a testobject.

Table 3.19: Shortcuts and key functions

Drag & Drop You can also operate with “drag & drop”, which is the same as “cut & paste”.

Shortcuts for certain views are described in the related section within chapter 6
Working with TESSY.

38 TESSY 4.0 Manual

 4 Basic knowledge

This chapter offers a brief introduction about unit testing with TESSY and the classification
tree method. It provides basic knowledge for organizing and executing a unit test in general
and in particular with TESSY. The chapter about the classification tree method helps you
to understand the logical system and to use the CTE.

4.1 Unit testing of embedded software . . . . . . . . . . . . . . . . . . 41

4.1.1 Standards that require testing . . . . . . . . . . . . . . . . . 41
4.1.2 About unit testing . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Considerations for unit testing . . . . . . . . . . . . . . . . 43
4.1.4 Methods for unit testing . . . . . . . . . . . . . . . . . . . 45
4.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 The Classification Tree Method (CTM) . . . . . . . . . . . . . . . . 49
4.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Steps to take . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3 Example is_value_in_range . . . . . . . . . . . . . . . . . . 56

40 TESSY 4.0 Manual

 4.1 Unit testing of embedded software

4.1 Unit testing of embedded software

Testing is an integral part of the software development process for embedded sys-
tems and its necessity to attain software quality is undisputed. This section gives a
comprehensive overview on aspects of unit tests of embedded software.

4.1.1 Standards that require testing

International standards like IEC 61508 require module tests. According to part 3 of IEC
61508, the module test shall show that the module under test performs its intended
function, and does not perform unintended functions. The results of the module testing
shall be documented.

IEC 61508 classifies systems according to their safety criticality. There are four safety
integrity levels (SIL), where 1 is the lowest level and 4 the highest, i.e. systems at level 4
are considered to be the most critical to safety. Even for applications of low criticality (i.e.
at SIL 1), a module test is already “highly recommended”. The tables contained in the
annexes of IEC 61508, Part 3 specify the techniques that should be used, e.g. for module
testing the technique “functional and black box testing” is highly recommended at SIL 1
already. Other techniques, such as dynamic analysis and testing are recommended at SIL
1 and highly recommended at SIL 2 and higher.

Part 4 of IEC 61508 defines a (software) module as a construction that consists of pro-
cedures and/or data declarations, and that can interact with other such modules. If we
consider embedded software which is written in the C programming language, we can take
a C-level function as a module. To prevent a mix-up between C-level functions and C
source modules, we will refer to the C-level functions as units from now on.

Also other standards like the British Def Stan 00-55, ISO 15504 or DO-178B require
module testing (where the nomenclature ranges from “module” to “unit” to “component”).
However, all standards have more or less the same requirements for that kind of test: the
tests have to be planned in advance, test data has to be specified, the tests have to be
conducted, and the results have to be evaluated and documented.

TESSY 4.0 Manual 41

4 Basic knowledge

4.1.2 About unit testing

4.1.2.1 What is unit testing?

During unit testing of C programs, a single C-level function is tested rigorously, and is
tested in isolation from the rest of the application. Rigorous means that the test cases are
specially made for the unit in question, and they also comprise of input data that may be
unexpected by the unit under test. Isolated means that the test result does not depend on
the behavior of the other units in the application. Isolation from the rest of the application
can be achieved by directly calling the unit under test and replacing the calls to other unit
by stub functions.

Unit testing tests at the interface of the unit, and unit testing does not consider the internal
structure of the unit, and therefore unit testing is considered as black-box testing. The
interface of the unit consists of the input variables to the unit (i.e. variables read by the
unit) together with the output variables (i.e. variables written by the unit). A variable can
both be an input and an output (e.g. a variable that is incremented by the unit), and the
return value of the unit - if present - is always an output. The structure of a test case
follows from the structure of the interface.

Unit testing is conducted by executing the unit under test with certain data for the input
variables. The actual results are compared to those predicted, which determines if a test
case has passed or failed.

Unit testing (of C-level functions, as described) is well suited to fulfill the requirements of
module testing for IEC 61508, because unit testing is

• functional, because the functionality of the unit is tested, and

• a black-box, because the internals of the unit are not taken into account,
and

• dynamic, because the test object is executed during the test.

4.1.2.2 What are the benefits?

• Finding errors early: Unit testing can be conducted as soon as the unit to
be tested compiles. Therefore, errors inside the unit can be detected very
early.

42 TESSY 4.0 Manual

 4.1 Unit testing of embedded software

• Saving money: It is general knowledge that errors which are detected late
are more expensive to correct than errors that are detected early. Hence, unit
testing can save money.

• Reducing complexity: Instead of trying to create test cases that test the
whole set of interacting units, the test cases are specific to the unit under
test. Test cases can easily comprise of input data that is unexpected by
the unit under test or by even random input test data, which is rather hard
to achieve if the unit under test is called by a fully-functioning unit of the
application. If a test fails, the cause of the failure can be easily identified,
because it must stem from the unit under test, and not from a unit further
down the calling hierarchy.

• Giving confidence: After the unit tests, the application is made up of single,
fully tested units. A test for the whole application will be more likely to
pass, and if some tests fail, the reason will have probably stemmed from the
interaction of the units (and not from an error inside a unit). The search for
the failure can concentrate on that, and must not doubt the internals of the
units.

4.1.3 Considerations for unit testing

4.1.3.1 Which units are good test candidates?

Unit testing verifies that certain input data generates the expected output data. Therefore,
units that do data processing in its widest sense, e.g. generation of data, analysis of data,
sorting, making complex decisions, difficult calculations are best suited for unit testing. To
find such units, the application of metrics (e.g. the cyclomatic complexity according to
McCabe) may be appropriate.

Other criteria for selecting units to test may be how critical the functionality is to the unit’s
operation, or how often a unit is used in the application.

4.1.3.2 What is not in the scope of unit testing?

The interaction of the units is not tested during the unit test. This includes the semantic of
the parameters passed between units (e.g. the physical unit of the values), and the timely
relationships between units (e.g. does a unit fulfill its task fast enough to let a calling
unit fulfill their tasks also at the required speed?) In addition, the interrupt behavior of
the application is not in the scope of unit testing. Questions like “Does my interrupt
really occur every 10 ms?” or “Which interrupt prolonged my unit unacceptably?” are
not addressed by unit testing, because unit testing explicitly aims at testing the functional
behavior of the unit isolated from environmental effects such as interrupts.

TESSY 4.0 Manual 43

4 Basic knowledge

4.1.3.3 Why is regression testing necessary?

Regression testing is the repetition of tests that have already passed after the implementa-
tion of bug fixes or improvements in the software. Regression testing proves that a change
in the software did not result in any unexpected behavior. Regression testing is a key
to software quality. Obviously, the practice of regression testing requires the automation
of the tests, because the effort to repeat the tests manually is too high. Even for non-
repetitive unit tests, the proper tool support will save you lots of time, but tool support is
indispensable for the repetition of the unit tests.

4.1.3.4 Who should conduct the tests?

The dilemma: It is commonly accepted that a software developer is badly suited to test
his own software, especially if the complete implementation, or the compliance of the
implementation with the specification is an issue (blindness against own faults). If the
developer has forgotten to implement a certain functionality, it is likely he will also forget
a test that will reveal the missing functionality. If the developer has misinterpreted the
specification, it is likely that his tests will pass in spite of the wrong functionality.

On the other hand, experience has shown that a tester, who should test a code not written
by him must put a lot of effort into understanding the function´s interface. The tester
must find out the meaning of the variables, and which values to use to conduct certain
tests. E.g., if the test specification requires the test of something “green”, which variable
(or variables) represents the color, and which value of the variable represents green? The
prediction of the expected results poses similar problems.

If the developer does not do tests, this gives rise to additional efforts, because the failed
test has to be passed to the developer, he has to reproduce the failure, correct the problem,
and then normally a concluding external regression test has to take place. Furthermore,
additional effort rises due to the fact that the developer will not hand out his software to
the QA department without having done at least some tests. This duplicated test effort
could be saved if the developer immediately starts testing by using the externally predefined
test cases.

The way out: A way out of that dilemma could be that a tester, who has not written the
code, specifies the test cases according to the functional specification of the unit, including
the expected results. He can use abstract data for this (e.g. color = green). The set of test
cases is handed over to the developer of the software. For him, it should be no problem to
set the input variables to the required values (e.g. the appropriate RGB value for green).
If a test fails, the developer can immediately correct the problem and re-run all tests that

44 TESSY 4.0 Manual

 4.1 Unit testing of embedded software

have passed so far (regression testing). Testing is seen as an additional step during the
implementation of software, in comparison to the compiling step, where the compiler finds
all syntax errors, and the developer corrects them interactively, verifying his changes by
subsequent compiler runs.

However, standards require the organizational separation of development and test, due
to the initial mentioned reason of blindness against own faults. Possibly, it could be
sufficient to only separate the specification of the test cases from the development, and to
consider the conduction of predefined test cases not to suffer under the above mentioned
blindness.

Furthermore, a developer´s time is often considered as too valuable to be wasted on testing,

which is why developer testing is not found often in practice. However, this is going to be
reconsidered.

4.1.3.5 What is special for testing embedded software?

For embedded software it is essential that the unchanged source code with all the non-
ANSI keywords and non-ANSI peculiarities is used for testing. For instance, some cross
compiler for embedded systems allow for bit fields that are smaller than the integer size,
e.g. 8-bit wide bit fields in a 16-bit application. This is forbidden by the ANSI C standard,
but justifiable by the perfect adaptation to the embedded system. Naturally, the unit test
results are worthless, if this illegal size cannot be maintained during the tests. This requires
specialized tools. Furthermore, it is also essential that the concluding tests at least execute
on the actual hardware, i.e. the embedded microcontroller. This is a challenge, but there
are ways to attenuate this. Using a cross compiler for the microcontroller in question is a
prerequisite, preferably the exact version that will be used also for the user application.

4.1.4 Methods for unit testing

Unit test tools can follow two technical approaches towards unit test: The test application
approach uses a special application for conducting the unit tests. This is the usual approach.
The original binary test uses the unchanged user application for testing.

4.1.4.1 a. Test application

The usual method for unit test tools to conduct unit tests is to generate a test driver (also
called test harness) and compile the test driver together with the source code of the unit

TESSY 4.0 Manual 45

4 Basic knowledge

under test. Together they form the test application. The test driver includes startup code
for the embedded microcontroller, the main() function entry, and a call to the unit under
test. If required, the test driver contains also code for stub functions and the like. For each
unit to test, an own test application is created. This test application is used to conduct the
unit tests. For that, the test application is loaded into an execution environment capable
of executing the test application. This execution environment is normally a debugger
connected to an (instruction set) simulator, an in-circuit emulator stand-alone or connected
to a target system, a JTAG or BDM debugger or the like. After test data is transferred to
the execution environment, (the test data may already be included in the test application),
tests are conducted and the results are evaluated.

To execute the test application on the actual hardware, the test application must not only
be compiled using a cross compiler for the microcontroller in question, but also the test
application must fit into the memory present on the actual hardware. Also, the startup
code of the test application must take into account peculiarities of the actual hardware,
e.g. the enabling of chip selects and the like. Making the test application fit into memory
can be simplified by using an in-circuit emulator, which provides emulation memory, and
serves as a kind of generalized hardware platform for the microcontroller in question.

When the actual hardware has to be used and if memory on this hardware is very limited, the
test application must be minimized to fit into this memory. This is especially challenging for
single chip applications, where only the internal memory of the microcontroller is available.
If test data is included in the test application (and memory is limited), a single test
application can only include a few test cases, which in turn means several test applications
for the test of one unit, which is cumbersome. An approach which avoids this, keeps the
test data separated from the test application, which allows not only for a minimized test
application, but also allows you to change the test data without having to regenerate the
test application.

4.1.4.2 b. Original binary test

Another approach is to use the unchanged user application for unit testing. This resembles
the manual test that is usually done by a developer after the application is completed.
The complete application is loaded into the execution environment, and the application is
executed until the unit to be tested is eventually reached. Then the input variables are set
to the required values, and the test is conducted.

46 TESSY 4.0 Manual

 4.1 Unit testing of embedded software

4.1.4.3 Pros and cons

The advantage of the Original Binary Test approach is that the unit under test is tested
exactly in its final memory location. There is no extra effort (or hassle) for compiling and
linking a test application, because the user application is used, which is already compiled
and linked or had to be compiled and linked anyway. Because the user application must
fit in the memory anyway, problems regarding the size of the application can be neglected.
Even applications that already reside in the ROM of the hardware can be tested. Even if
the cross compiler used to compile the user application is no longer at hand, tests are still
feasible.

However, this Original Binary Test approach has some disadvantages compared to using a
test application:

• There is no control over the test execution. It depends on the user applica-
tion, when the unit under test is reached. It may be the case that the unit
under test is never reached, or only after some special external event has
happened, e.g. the push of a button of the actual hardware and an interrupt
resulting from this.

• During the Original Binary Test, stub functions cannot be used. This is clear
because the application is already linked using the current functions that are
called by the unit under test. A unit is always tested using the other units of
the application. Therefore, the unit under test is not isolated from the rest
of the application, and errors of called units may show up during the test of
the unit under test.

• It is not possible to use arbitrary test data for the unit test. For instance, if
the unit under test gets its test data by a pointer pointing to a memory area,
the amount test data must fit into this memory area, which was allocated by
the user application.

Apart from its easy usage, which possibly could be the only means to do some unit testing
at all, the Original Binary Test has strong disadvantages, which are essential for proper
unit testing and therefore one could even insist that it is not a unit test in its strictest
sense.

4.1.5 Conclusion

Besides being required by standards, unit testing reduces the complexity of testing, finds
errors early, saves money, and gives confidence for the test of the whole application. If
used in the right way, unit testing can reduce development/test time and therefore reduce

TESSY 4.0 Manual 47

4 Basic knowledge

the time-to-market. To conduct regression tests, test automation is indispensable. This

requires tool support.

48 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

4.2 The Classification Tree Method (CTM)

The objective of the Classification Tree Method (CTM) is to transform a (functional)

definition of a problem systematically into a set of error-sensitive, low redundancy
set of test case specifications. This document gives a comprehensive overview of the
CTM.

4.2.1 General

Testing is a compulsory step in the software development process. The planning of such
testing often raises the same questions:

• How many tests should be run?

• What test data should be used?

• How can error-sensitive tests be created?

• How can redundant tests be avoided?

• Have any test cases been overlooked?

• When is it safe to end testing?

Anyone who has been confronted with such issues will be glad to know that the CTM offers
a systematic procedure to create test case specifications based on a problem definition.

The objective of the CTM is to transform a (functional) definition of a problem systema-

tically into a set of error-sensitive, low redundancy set of test case specifications. The
systematic approach yields a high probability that the resulting set of test specifications is
complete and no relevant tests are overlooked. Naturally, correct usage of the method and
an appropriate integration in the development process are prerequisites. Having a complete
set of tests gives evidence when it is safe to end testing.

The CTM is applied by a human being. Therefore, the outcome of the method depends
on the experiences, reflections, and appraisals of the user of the CTM. Most probably
two different users will come out with a different set of test case specifications for the
same functional problem. Both sets could be considered to be correct, because there is no
absolute correctness. It should be clear that there are set of test cases that are definitively
wrong or incomplete. Because of the human user, errors cannot be avoided. One remedy
is the systematic inherent in the method. This systematic guides the user and stimulates

TESSY 4.0 Manual 49

4 Basic knowledge

his creativity. The user shall specify test cases with a high probability to detect a fault in
the test object. Such test cases are called error-sensitive test cases. On the other hand,
the user shall avoid that too many test cases are specified, that are superfluous, i.e. do not
increase test intensiveness or test relevance. Such test cases are called “redundant” test
cases. It is advantageous, if the user is familiar with the field of application the method is
applied in.

The CTM is a general method: It can not only be applied to module/unit testing of embed-
ded software, but to software testing in general and also to functional testing of problems,
that are not software related. The prerequisite to apply the method is to have available
a functional specification of the behaviour of the test object. The CTM incorporates se-
veral well-known approaches for test case specification, e.g. equivalent partitioning, and
boundary value analysis.

The CTM stems from the former software research laboratory of Daimler in Berlin, Ger-
many.

4.2.2 Steps to take

a. Defining the functional problem

The first step is to describe the expected behaviour of the test object, e.g. “If the button is
pushed, the light will go on; if the button is released, the light will go off”. Data processing
software normally solves functional problems, since input data is processed according to an
algorithm (the function) to become output data (the solution).

b. Determining the test-relevant aspects

Analyse the functional specification. This means, you think about this specification with
the objective to figure out the test-relevant aspects of the specification. An aspect is
considered relevant if the user expects that aspect to influence the behaviour of the test
object during the test. In other words, an aspect is considered relevant if the user wants
to use different values for this aspect during testing. To draw the tree, these aspects are
worked on separately. This reduces the complexity of the original problem considerably,
what is one of the advantages of the CTM.

Example for a test-relevant aspect

Consider systems that measures distances in a range of some meters, e.g. the distance to
a wall in a room. Those systems usually send out signals and measure the time until they

50 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

receive the reflected signal. Those systems can base on two different physical effects: One
can use sonar to determine the distance, whereas the other can use radar.

The question is now: Is the temperature of the air in the room a test relevant aspect for the
test of these measurement systems? The answer is yes for one system and no for the other:

The speed of sound in air (sonar) is dependent on the temperature of the air. Therefore, to
get exact results, the sonar system takes this temperature into account during the calculation
of the distance. To test if this is working correct, you have to do some tests at different
temperatures. Therefore, the temperature is a test-relevant aspect for the sonar system. On
the other hand we all know that the speed of a radar signal, that travels at the speed of light,
is independent from the temperature of the air it travels in (it did not even need air to travel).
Therefore, the temperature of the air is not a test-relevant aspect for the testing of the radar
system. It would be superfluous to do testing at different temperatures.

This example shows that it needs careful thinking to figure out (all) test relevant aspects.
It would lead to poor testing if someone simply takes the test cases for the radar system
and applies them to the sonar system without adding some temperature-related test cases.
Additionally, this example illustrates that it is advantageous to have some familiarity with the
problem field at hand when designing test cases.

c. Classifying the values of a test-relevant aspect

After all test relevant aspects are determined, the values that each aspect may take are
considered. The values are divided into classes according to the equivalence partitioning
method: Values are assigned to the same class, if the values are considered equivalent for
the test. Equivalent for the test means that if one value out of a certain class causes a test
case to fail and hence reveals an error, every other value out of this class will also cause
the same test to fail and will reveal the same error.
In other words: It is not relevant for testing which value out of a class is used for testing,
because they all are considered to be equivalent. Therefore, you may take an arbitrary
value out of a class for testing, even the same value for all tests, without decreasing the
value of the tests. However, the prerequisite for this is that the equivalence partitioning
was done correctly, what is in the responsibility of the (human) user of the CTM.

Please note:

• Equivalent for the test does not necessarily mean that the result of the test
(e.g. a calculated value) is the same for all values in a class.

• Equivalence partitioning must be complete in mathematical sense: Every

possible value of a test relevant aspect must be assigned to a class.

TESSY 4.0 Manual 51

4 Basic knowledge

• Equivalence partitioning must be unique in mathematical sense: A value of

a test relevant aspect must be assigned to a single class, and not to several
classes.

Example for equivalence partitioning: Ice Warning

An ice warning indication in the dashboard of a car shall be tested. This ice warning indication
depends on the temperature reported by a temperature sensor at the outside of the car, which
can report temperatures from -60°C to +80°C. At temperatures above 3°C the ice warning
shall be off, at lower temperatures it shall be on.

It is obvious that the temperature is the only test-relevant aspect. To have an reasonable
testing effort, we do not want to have a test case for every possible temperature value.
Therefore, all possible temperature values need to be classified according to the equivalence
partitioning method.
It is best practice to find out if invalid values may be possible. In our case a short circuit or
an interruption of the cable could result in an invalid value. Therefore, we should divide the
temperature in valid and invalid values first. The invalid values can relate to temperatures
that are too high (higher than 80°C) and to ones that are too low (lower than -60°C). It is
tempting to form two classes out of the valid temperatures: The first class shall contain all
values that result in the ice warning display being on (from -60°C to 3°C) and the other class
shall contain all values that result in the ice warning display being off (from 3°C to 80°C).

Figure 4.1: Initial equivalence partitioning for “ice warning”

The equivalence partitioning in the figure above leads to at least four test cases, because we
need to take a value out of each class for the tests.

d. Repeating equivalence partitioning

An equivalence class can be sub-divided according to additional aspects. This equivalence

partitioning on several levels reduces the complexity of equivalence partitioning, because

52 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

you can consider each class isolated from the other classes and decide, if and how it
needs to be sub-divided or not. Furthermore, this equivalence partitioning on several levels
documents the thoughts resp. stages of work until the final equivalence partition. This
serves understandability and traceability of the result. Also it allows easily reverting steps
if the final equivalence partition has become too fine granulated.

Example for repeated equivalence partitioning

For the example ice warning, the classification of the valid values is not detailed enough,
because according to the equivalence partitioning method, it would be sufficient to use a
single, arbitrary value out of a class for all the tests. This could be for instance the value
2°C out of the class of temperatures, for which the ice warning display is on. In consequence,
no test with a minus temperature would check if the ice warning display is on. To avoid this
consequence, you could divide this class further according to the sign of the temperature:

Figure 4.2: Repeated equivalence partitioning for “ice warning”

Result: Classification tree

Using the CTM, the result of the repetition of equivalence partitioning for all test relevant
aspects is depicted in the CT. The root represents the functional problem, the test relevant
aspects. Test relevant aspects (classifications) are drawn in nodes depicted by rectangles.
Classes are ellipses.

TESSY 4.0 Manual 53

4 Basic knowledge

Figure 4.3: A possible CT for “ice warning”

e. Using boundary values

The idea behind using boundary values is that values at the borders of a range of values are
better suited to form error-sensitive test cases than values in the middle. The idea behind
boundary values analysis is contrary to equivalence partitioning, because one method takes
a set of values as equivalent and the other method prefers special values in such a set.
Despite the fact that the idea behind boundary values analysis is exactly the opposite of
equivalence partitioning, both approaches can be expressed in the CTM.

f. Testing a hysteresis

The current problem specification of the ice warning-example does not mention hysteresis.
It may be tempting to extend the current problem specification in that fast changes in
the state of the ice warning display shall be avoided. For instance, the ice warning display
shall be switched off only after the temperature has risen to more than 4°C. This could be
realized by a hysteresis function. The necessary test cases for such a hysteresis function
can be specified by the CTM.

g. Specifying test cases

Test cases are specified in the so-called combination table below the CT. The leaf classes
of the CT form the head of the combination table. A line in the combination table depicts
a test case. The test case is specified by selecting leaf classes, from which values for the

54 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

test case shall be used. This is done by the user of the method, by setting markers in the
line of the respective test cases in the combination table.

Figure 4.4: Result of the CTM: tree (above) with combination table (below)

It may be tempting to combine every class with every other class during the specification
of the test cases. Besides the fact, that not every combination might be possible for logical
reasons, it is not the intention of the CTM to do so, it could be done automatically by a
tool. This would lead to many test cases, with the disadvantages of loss of overview and
too much effort for executing the test cases.

The objective of the CTM is to find a minimal, non-redundant but sufficient set of test
cases by trying to cover several aspects in a single test case, whenever possible. Similar
to the drawing of the tree, it depends on the appraisal and experience of the user of the
method, how many and which test cases are specified.

Obviously the size of the tree influences the number of test cases needed:
A tree with more leaf classes naturally results in more test cases than a tree with less leaf
classes. The number of leaf classes needed at least for a given tree is called the minimum
criterion. It can be calculated from the consideration that each leaf class should be marked
in at least one test case, and that some leaf classes cannot be combined in a single test
case, because the classes exclude each other.
Similar a maximum criterion can be calculated, which gives the maximal number of test
cases for a given CT. A rule of thumb states that the number of leaf classes of the tree gives
the order of magnitude for the number of test cases required for a reasonable coverage of
the given tree.

TESSY 4.0 Manual 55

4 Basic knowledge

4.2.3 Example is_value_in_range

Problem definition:

A start value and a length define a range of values. Determine if a given value is within the
defined range or not. Only integer numbers are to be considered.

Figure 4.5: The problem “is_value_in_range” depicted graphically

It is obvious, that completed testing is practically impossible, because we get 65536 * 65536 *
65536 = 281.474.976.710.656 test cases, even if we assume only 16 bit integers. If we would
assume 32 bit integers . . . well, we better do not.

4.2.3.1 Test-relevant aspects

The start of the range and the length can be regarded as test relevant aspects. This is
convenient since, according to the problem definition, a range of values is defined by a
start value and a length. It reflects the intention to use different values for the start and
the length during testing.

We should have some test cases, which result in inside, and other test cases which result in
outside. We call the corresponding aspect position, because the position of the value under
test with respect to the range determines the result. So the three test-relevant aspects
to be used for classifications are initial value, length and position and they thus form the
basis of the CT:

Figure 4.6: The initial CT with three test-relevant aspects

56 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

4.2.3.2 Forming classes

Now classes are formed for the base classifications according to the equivalence partitioning
method. Usually, the problem specification gives us hints how to form the classes. E.g.
if the problem specification would state: “If the start value is greater than 20, the length
value doubles”, then we should form a class for start values greater than 20 and a class for
start values smaller or equal to 20.

Unfortunately, the problem specification at hand is too simple to give us similar hints.
However, since the start value can take on all integer numbers, it would be reasonable to
form a class for positive values, a class for negative values, and another class for the value
zero. It would also be reasonable to form just two classes, e.g. one class for positive start
values including zero and the other class for negative start values. This depends on ones
emphasis having zero as value for the start of the range in a test case or not.

Figure 4.7: The CT for is_value_in_range, 2nd step

Because of the systematic inherent in the CTM, and because range_length is an integer
as well as range_start, it is stringent to use for range_length the same classes as for
range_length. This results in the following tree:

Figure 4.8: The CT for is_value_in_range, 3rd step

4.2.3.3 A first range specification

To specify a first range (to be used in the first test case), we have to insert a line in the
combination table and to set markers on that line:

TESSY 4.0 Manual 57

4 Basic knowledge

Figure 4.9: A first specification for the range in the combination table

Two markers are set on the line for the first specification. One marker selects the class
positive for the start of the range. The other marker selects the class positive for the
length of the range. A range with the start value of, say, 5 and a length of 2 would accord
to the specification. This first specification was named trivial.

4.2.3.4 A second range specification

We can insert a second line in the combination table and specify a much more interesting
tests case:

Figure 4.10: A second specification for the range in the combination table

For the second specification again two markers are set. They specify that a negative value
shall be used both for the start and for the end of the range. Hence a range with the start
value of -5 and a length of -2 would accord to the second specification. But this value
pair raises some questions: Shall the value -6 lie inside the range? Or shall the value -4 lie
inside the range? Or shall no value at all lie inside the range, if the length of the range is
negative? Each opinion has its supporters and it is hard to decide what is to be considered
correct. Actually, at this point it is out of our competence to decide what is correct. We
have found a problem of the specification!

58 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

It is a valuable result to find a problem (omission or contradiction) in the functional

problem specification, and that it was achieved in the case during test case speci-
fication for the functional problem. It is generally more likely to detect a problem
in the functional specification if the test case specification is systematic. The CTM
is a systematic method for test case specification. Hence, the CTM provides good
means to detect problems in the functional problem specification.

Probably a test case using a negative length would not have been used if the test case
specification would have been done spontaneous and non-systematic. But a negative length
is completely legal for the functional problem specification that was given above. If you
consider that the problem specification at hand was a very simple one, you may imagine
how likely it is to overlook a problem in a more comprehensive and complicated problem
specification.

4.2.3.5 Extending the tree by a boundary class

In case we are not satisfied with the fact that a fixed single positive value, e.g. 5, may serve
as value for the start of the range in all test cases, we can sub-divide the class positive
according to a suitable classification. In our example, we classify according to the size.
The idea behind this is to have a class containing only a single value, in our case the
highest positive value existing in the given integer range. We use this value because it is
an extreme value, and as we know, using extreme values (or boundary values) in test cases
is well-suited to produce error-sensitive (or interesting) test cases.

Figure 4.11: The CT for is_value_in_range, 4th step

In the figure above, the positive values for the start of the range are subdivided according to
their size. This results in the two classes normal positive and maximal positive. The class

TESSY 4.0 Manual 59

4 Basic knowledge

maximal positive holds the highest possible positive value (i.e. MAX_INT), and the class
normal positive holds all other positive values. This satisfies mathematical completeness.

Remark 1: Another possibility to classify the positive start values would have been for
instance to classify in odd and even values. This would have been completely legal. This
would have been probably also sensible for e.g. a problem of number theory, but not
target-oriented for the problem at hand.

Remark 2: Please note that for the moment we do not know and we need not to know
the size (in bits) of the integers used in the problem at hand. We simply specify “the
highest positive value in the given integer range”. This keeps our test case specification
abstract! E.g. our test case specification is appropriate for any integer size. As soon as we
assume we use e.g. 16 bit integers, and therefore parameterize our test case by specifying
32767 as value in the class maximal positive, we loose this abstraction. E.g. if we port the
parameterized test case to a 32 bit integer system, the test case looses its sense. This is
not the case if we port the abstract test case specification.

4.2.3.6 Another interesting test case specification

With the CT extended according to figure 4.11 The CT for is_value_in_range, 4th step,
we can insert an additional line in the combination table and specify again an interesting
range for a third test case:

Figure 4.12: The third range specification provokes a wrap-around

The third range specification in the figure above combines the highest positive number for
the start value of the range with a positive length, i.e. the range exceeds the given integer
range.

60 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

The situation with the third range specification is similar to the situation depicted in the
figure above. The situation raises some questions: Will the situation be handled sensible
and gracefully by the test object? Or will it crash due to the overflow? Will the negative
values on the left hand side ibe accounted to lie inside the range or not? And what is correct
with respect to the last question? The problem specification above does not give an answer
to the latter question, again we have found a weak point in the problem specification.

To sum up, designing test cases according to the CT method has revealed two problems
of the problem specification and has lead to interesting test cases so far.

4.2.3.7 The completed classification tree

Figure 4.13: The completed CT for is_value_in_range

In the figure above, one possible completed CT is depicted. Classifications are depicted by
rectangles, classes by ellipses. The “range” node is a composition with two classifications
as child elements. This tree is discussed in the following:

TESSY 4.0 Manual 61

4 Basic knowledge

• Analogous to the class maximal positive for the start value of the range, a
class maximal negative is introduced. The idea behind this class is to combine
the maximal negative start value with a negative length of the range, what
shall provoke an underflow or negative wraparound. This idea comes from
the systematic in the CTM: If a positive wrap-around is seen as an interesting
test case, also a negative wrap-around should be exercised.

• An example for a composition is given by range. A composition may be used

for a relation “consists of”. In our case, the range consists of a start value
and a length.

• The final tree features still the three initial classes positive, zero, and negative
for the length of the range. It is important to note that the tree reveals at
a glance that nothing like maximal positive length or similar is considered to
be useful for the testing problem at hand.

• It is obvious that a position can either be inside or outside the range, hence
this classification suggests itself. Furthermore, it is obvious that there are
two different areas outside the range: below the range and above the range.
This is reflected in the classification position outside. (If the tree would miss
such a classification, it may well be considered incorrect).

• The class inside of the classification position could well be a leaf class of the
classification tree. However, in the CT in the figure above, this class is sub-
divided further in the sub-classes range_start, opposite_border, and inlying.
This is done to force the use of boundary values in the test cases. If a test
case specification selects the class range_start, the value that shall be chec-
ked if it is inside the range or not shall take the value of the start of the range,
that is the lowest value that is considered to be inside the range, a boundary
value. The class opposite_border is intended to create an analogous test
case specification, but using the highest value that is considered to be inside
the range. The class range_start and the class opposite_border both contain
only a single value. All other values inside the range are collected in the class
inlying; this class exists mainly because of the requirement for completeness
of equivalence partitioning. A similar approach to use boundary values is
visible in the classes at border for positions outside the range.

62 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

4.2.3.8 The completed test case specification

In the next figure, the same CT is depicted with a completed combination table, what
results in a complete test case specification for the functional problem:

Figure 4.14: The completed test case specification

The test case specification above lists 14 test cases. Please note that these are specified
by the user and depend on its judgment. Based on the CT it is possible for some values
to be determined that provide clues to the number of test cases required.

The first value is the number of test cases, if each leaf class is included at least once in a
test case specification. This number is known as the minimum criterion. In our example,
the largest amount of leaf classes, namely seven, belong to the base classification position.
Seven is thus the value of the minimum criterion. The maximum criterion is the number
of test cases that results when all permitted combinations of leaf classes are considered.

In our example, the maximum criterion amounts to 105 (i.e. 5 * 3 * 7). The maximum
criterion takes into account that it is not possible to select e.g. a negative length and
a positive length for the same test case specification, because this is impossible by the
construction of the tree. The maximum criterion takes not into account that it is not

TESSY 4.0 Manual 63

4 Basic knowledge

possible to select e.g. a zero length and inlying, because this is not impossible by the
construction of the tree, but by the semantics of the function problem.

A reasonable number of test case specifications obviously lies somewhere between the
minimum and the maximum criterion. As a rule of thumb, the total number of leaf classes
gives an estimate for the number of test cases required to get sufficient test coverage. In
the test case specification, the CT has 15 leaf classes, what fits well to 14 test cases.

By the test case specification in the figure above, you can deduct how the functional
problem specification was extended with respect to the questions raised in sections “A
second range specification” and “Another interesting test case specification”:

• “If the length of the range is negative, are there values that can be inside the
range?” The answer is “yes”, because in test case specification no. 5 and
no. 6 a negative length shall be used and the position of the value shall be
inside the range.

• “If the length of the range exceeds the given integer range, shall negative
values be inside the range?” Test case specification no. 12 clarifies that this
should not be the case.

The leaf class inlying is selected for only one test case specification (no. 1). This reflects the
fact that this class exists only because of the requirement for mathematical completeness
of equivalence partitioning, and not because the inlying values are considered to produce
error-sensitive test cases.

4.2.3.9 Another test case specification

Here is an alternative test case specification to the functional problem specification at hand
depicted:

Figure 4.15: An alternative test case specification

64 TESSY 4.0 Manual

 4.2 The Classification Tree Method (CTM)

What are the differences to the more elaborated test case specification in the section
above?

• The start value of the range is not mentioned in the CT. This means, the
start value is not considered to be a test-relevant aspect by the user of the
CTM. In consequence, any arbitrary value can be used as start value in the
four test cases. This value can be fix for all test cases, but does not have to
be.

• The problem of a negative length is completely neglected. For the problem

specification from section Problem which specifies a length to be an integer
and hence also the length to be negative, this is a serious flaw.

• The problem of wrap-around is neglected. This may be considered to be an

esoteric problem, and therefore it could be accepted that it is not mentioned
in the alternative test case specification.

• The usage of boundary values is not forced by the alternative test case specifi-
cation. This is questionable, because boundary values produce error-sensitive
test cases. The alternative test case specification minimizes testing effort (by
specifying only four test cases), but this is at the cost of thoroughly testing.

But the point is not which test case specification is better. The main point is:

Test case specification according to the CTM visualizes testing ideas!

TESSY 4.0 Manual 65

66 TESSY 4.0 Manual
5 Practical exercises

This chapter will show you on the basis of prepared exercises how to work with TESSY:

• The Quickstart 1: Unit test exercise is_value_in_range is a very basic example of

how to operate with TESSY.
• The Quickstart 2: The Classification Tree Editor (CTE) gives a short and easy
introduction of operating with the Classification Tree Editor (CTE). It continues the
Quickstart 1.
• The Quickstart 3: Component test exercise interior_light shows on the basis of a
simple example how component testing works with TESSY.
• The Quickstart 4: Exercise C++ gives a short and easy introduction of handling
with a C++ source file.
• The Quickstart 5: Test driven development (TDD) gives a short introduction into
test driven development with TESSY. You should be familiar with the overall hand-
ling of TESSY before doing this exercise.

5.1 Quickstart 1: Unit test exercise is_value_in_range . . . . . . . . . . 69

5.1.1 Creating a test project . . . . . . . . . . . . . . . . . . . . 70
5.1.2 Specifying the target environment . . . . . . . . . . . . . . . 72
5.1.3 Adding the test object and analyzing the C-source file . . . . . 73
5.1.4 Editing the test object interface . . . . . . . . . . . . . . . . 76
5.1.5 Designing test cases . . . . . . . . . . . . . . . . . . . . . 77
5.1.6 Adding test cases and test steps . . . . . . . . . . . . . . . . 77
5.1.7 Entering test data . . . . . . . . . . . . . . . . . . . . . . 79
5.1.8 Executing the test . . . . . . . . . . . . . . . . . . . . . . 82
5.1.9 Repeating the test run with coverage instrumentation . . . . . 83
5.1.10 Analyzing the coverage . . . . . . . . . . . . . . . . . . . . 85
5.1.11 Creating a report . . . . . . . . . . . . . . . . . . . . . . . 90
5.1.12 Repeating the test run with requirements . . . . . . . . . . . 92
5.1.13 Reusing a test object with a changed interface . . . . . . . . 102
5.2 Quickstart 2: The Classification Tree Editor (CTE) . . . . . . . . . . 110
5.2.1 Creating classifications . . . . . . . . . . . . . . . . . . . . 111

TESSY 4.0 Manual 67

5 Practical exercises

5.2.2 Creating classes . . . . . . . . . . . . . . . . . . . . . . . . 113

5.2.3 Entering test data . . . . . . . . . . . . . . . . . . . . . . 113
5.2.4 Creating test cases . . . . . . . . . . . . . . . . . . . . . . 116
5.3 Quickstart 3: Component test exercise interior_light . . . . . . . . . 121
5.3.1 Creating the test project . . . . . . . . . . . . . . . . . . . 123
5.3.2 The heartbeat function . . . . . . . . . . . . . . . . . . . . 124
5.3.3 Preparing the test interface . . . . . . . . . . . . . . . . . . 127
5.3.4 Adding test cases . . . . . . . . . . . . . . . . . . . . . . . 129
5.3.5 Editing data . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.3.6 Configuring the work tasks . . . . . . . . . . . . . . . . . . 132
5.3.7 Designing scenarios . . . . . . . . . . . . . . . . . . . . . . 132
5.3.8 Executing the scenarios . . . . . . . . . . . . . . . . . . . . 138
5.3.9 Evaluating the scenarios . . . . . . . . . . . . . . . . . . . 139
5.4 Quickstart 4: Exercise C++ . . . . . . . . . . . . . . . . . . . . . 140
5.5 Quickstart 5: Test driven development (TDD) . . . . . . . . . . . . 144

68 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

5.1 Quickstart 1: Unit test exercise is_value_in_range

In this exercise we will get to know the basic functionality of testing with TESSY. We will
operate with the example “is_value_in_range” which will give you a fast introduction and
an overview as well as the terms of importance.

Figure 5.1: Operational sequences in TESSY

TESSY 4.0 Manual 69

 5 Practical exercises

Central test A unit test in TESSY is divided into the following central test activities:
activities
• Determining test cases.

• Entering test data and expected values.

• Executing the test.

• Evaluating and documenting the test.

Usually you would import your requirements first. To keep this exercise understan-
dable for beginners, we will first exercise a simple project, then import some basic
requirements and restart the test!

We will now follow a simple source code example to show how to excercise those activities
with TESSY.

Example “is_value_in_range”

A start value and a length define a range of values.

Function: Determine if a given value is within the defined range or not. Only integer
numbers are to be considered.

5.1.1 Creating a test project

If you have not created the project “Example1” yet, do as follows:

To understand TESSY´s file system and databases, consult section 3.1 Creating
databases and working with the file system.

Þ Start TESSY by selecting “All Programs” > “TESSY 4.x” > “TESSY 4.x”.

Þ If the “Open Project” dialog will open, click on (Create Project).

If another project is opened within TESSY, click “File” > “Select Project” >
“New Project” and then click on .

The Project Configuration dialog opens (see figure 5.2).

70 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.2: Creating the new project “Example1”.

Þ Enter Example1 as name of the project.

Þ Leave the automatically created Project Root as it is (default

C:\[User]\Projects\TESSY\[Projectname]) and click “OK”.

TESSY now creates the project “Example1” (see figure 5.3). This will take a
few seconds.

Figure 5.3: New project “Example1” is created

Þ Click “Open Project”.

TESSY now opens your project. This will take a few seconds.

TESSY 4.0 Manual 71

 5 Practical exercises

Organizing The project “Example1” is opened within the Overview perspective. You can create diffe-
“Example1” rent folders within a test collection, each containing modules with various test objects. To
keep it simple, we will create now one test collection with one folder.

We start within the view “Test Project”:

Þ In the Test Project view click on the icon (New Test Collection) in the tool
bar of the view.

Þ Enter Is_value_in_range and press the “Enter”-key.

Þ Click on (New Folder), enter ExampleFolder , click “Enter”.

Þ Click on (New Module), enter ExampleModule , click “Enter”.

The module relates to one or many source files which are to be tested.

Figure 5.4: Test collection “Is_value_in_range” with an example folder and module

Rename or delete a module or a folder by using the context menu (right click >
“rename” or “delete”) or the key F2.

5.1.2 Specifying the target environment

Usually at this point you will have to specify the target environment, that is to determine
the compiler, the target and the microcontroller. You will do that in the “Test Environment
Editor” which we will get to know later.

Please notice beneath in the Properties view at tab “General” that the GNU GCC compiler
is already selected for this module (see figure 5.5), which is enough for our example.

72 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.5: GNU GCC compiler is selected by default.

Now we will add the source file to the module. The source file contains the C-function to
be tested: C-source file

Figure 5.6: The source code of the C-Function to be tested

5.1.3 Adding the test object and analyzing the C-source file

We will use the example C-source file “is_val_in_range.c” which is stored under
“C:\Program files\Razorcat\TESSY_4.x\Examples\IsValueInRange”.

TESSY 4.0 Manual 73

 5 Practical exercises

Copy the C-source file, paste it in the project root an add it to the module:

Þ Open the Windows Explorer.

Þ Copy the source file “is_val_in_range.c” in a folder which is located in the

project root, e.g. “c:\MyProjects\TESSYProjectABC\sources”.

It is useful to relate all sources, includes etc. to the project root.

You have a better overview about all sources, includes etc.

Þ Switch back to TESSY.

Þ In the Test Project view select the module (“Example Module”).

Þ In the Properties view switch to tab “Sources”.

Þ Click on (Add Source).

Adding the
C-source

Figure 5.7: Adding the C-source file.

Þ Select the source file “is_val_in_range.c” from the folder where you just
pasted the source.

Þ Click “Open”. The C-source file will be added.

Þ In the Test Project view above click on (Analyze Module) to start the
module analysis (see figure 5.8).

74 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.8: Analyzing the module, that is the C-source file.

TESSY now analyzes the C-source file, this will take a few seconds. After successful
processing,

Þ click on the white arrow in front the module: .

TESSY will as well analyze the C-source file by just clicking on the white arrow
after adding the C-source file.

Now all functions which were defined in the C-source file are displayed as children of the
module above within the Test Project view (see figure 5.9).

Figure 5.9: The function of the C-source is displayed as child of the module.

Our sample C-source file contains only one function, our test object “is_value_in_range”.

TESSY 4.0 Manual 75

 5 Practical exercises

The term “test object” indicates the functions within the module we are attempting
to test.

5.1.4 Editing the test object interface

Þ Switch to the TIE (Test Interface Editor).

Figure 5.10: Perspective TIE - Test Interface Editor

Determine Now we can edit the interface information for every test object and determine which values
passing directions are input and which ones are output variables. Input values are all interface elements that
are read by the test object. Output values are written by the test object.

Upon opening the module, TESSY will try to set the default passing directions (input or
putput) automatically. You can change these default interface settings to your needs.

In our sample the passing directions are already defined, you do not have to take
actions.

Þ In the Interface view open the Parameter paragraph to see the inputs and
output values that are already defined in our example (see figure 5.11)

76 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.11: The inputs and outputs are already defined

5.1.5 Designing test cases

Usually now you would design the test cases, either manually or within the Classification
Tree Editor (CTE), based on specifications of your test object.

Since the CTE is a subject for its own, we will not make use of the CTE in this example,
but simply enter some ad-hoc test data manually.

To learn about the CTE refer to section 6.7 CTE: Designing the test cases or follow
the Quickstart 2: The Classification Tree Editor (CTE).

5.1.6 Adding test cases and test steps

Now we will add three test cases each with one test step within the Test Items view:

Þ Switch to Overview perspective and to view Test Items.

TESSY 4.0 Manual 77

 5 Practical exercises

Figure 5.12: Test Items view

Þ Select the test object in the Test Project view.

Þ In the Test Items view click on (New Test Case).

The first test case is created and a test step is automatically added.

In TESSY every test case has at least one test step.

Þ Add two further test cases.

Þ Expand the test cases by clicking on the arrows in front of the test cases.

Adding test cases

Figure 5.13: Three test cases were added in the Test Items view

78 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Please notice the following habits of this view:

• The first number is the number of the test case, the number in brackets shows the
quantity of the test steps included.
• Test case numbers will be counted continuously: If you delete test cases, new test
cases will get a new number and existing test cases will not be renumbered.
• If you cannot click on “New Test Case” or “New Test Step” because the icons are
inactive, you might be in the wrong selection: Select the test object within the
Test Project view, then select the Test Items view.

5.1.7 Entering test data

Now we will define some input and output values:

Þ Switch to the perspective “TDE - Test Data Editor”. The TDE will also open
with a double click on a test case or a test step.

In the Test Data view you can see the test cases and steps in tabular form.

Þ Under “Inputs” click on the arrow to open “struct range r1”.

Þ For test case 1 (1.1) enter 3 for “range_start”.

Þ Enter 2 for “range_len”.

Þ Enter 4 for “v1”.

Þ Click on (Save) to save your inputs.

After saving, the symbol of the test object in the Test Project view as well as
the symbol of the test case in the Test Items view turns yellow to indicate that
the test case is ready to run (see figure 5.14).

Þ Under “Outputs” click on the arrow ahead “Return”.

Þ Enter “yes” for the return value.

TESSY 4.0 Manual 79

5 Practical exercises

Figure 5.14: Data is entered, test step turns yellow and test case is ready to run.

Please notice the changes of the test object icon to indicate different conditions:

Empty gripper: Test object is analyzed but has no test case.

Gripper with white object: Test object has test cases but no data.
Gripper with yellow object: At least one test step is ready to be executed.

Þ Now enter data for the other two test cases as shown in table 5.18.

test step: 1.1 2.1 3.1

range_start: 3 20 0

range_length: 2 8 5

v1: 4 22 6

expected return: yes no no

Table 5.18: Entering data for test object is_value_in_range.

80 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

• Test case 1.1: The range starts at 3 and has a length of 2. Therefore, the range
ends at 5 and the given value 4 is supposed to be inside of the range (yes).
• Test case 2.1: The range starts at 20 and has a length of 8. Therefore, the range
ends at 28 and the given value 22 is supposed to be inside of the range. Because we
want to force an incorrect output, we state this to be not inside of the range (no).
• Test case 3.1: The range starts at 0 and has a length of 5. Therefore, the range
ends at 5 and the given value 6 is supposed NOT to be inside of the range (no).

Figure 5.15: Entering data for test object is_value_in_range

The test step icons in the Test Items view will now turn to yellow (see figure 5.16). This
indicates that we are now ready to run the test.

Figure 5.16: The test cases are ready to test

TESSY 4.0 Manual 81

5 Practical exercises

5.1.8 Executing the test

Þ Click on (Start Test Execution) in the tool bar of the Test Project view.

A progress dialog will be shown while TESSY generates, compiles and links the
test driver and runs the test. This will take a few seconds.

After the test run, test case icons (within TDE) should be (see figure 5.17):

• Within the Test Data view the second test step is marked with a red cross
and the expected result “no” is marked red to indicate, that the result did
not match the expected result (the actual result is “yes”).

• Within the Test Project view the test collection, folder, module and test
object are marked with a red cross to indicate, that not all results did match
the expected results.

• The Test Items view indicates with a red cross, that test case 2 did not match
the expected result.

Figure 5.17: TDE after test run is_value_in_range

Þ Switch to the Overview perspective.

82 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.18: Test results of is_value_in_range

You can see the results of every test step within the Test Results view.

5.1.9 Repeating the test run with coverage instrumentation

To analyze the source code coverage of the test, repeat the test run with the branch,
MC/DC and MCC-coverage instrumentation:

Þ In the tool bar of the Test Project view click on the arrow next to the Execute
Test icon and select “Edit Test Execution Settings . . . ”.

Þ In the following dialog tick the boxes “Run” (default) and “Create New Test
Run”.

Þ Choose the instrumentation “Test Object” and untick the box “Use preselected
coverage”.

Þ Tick the boxes for “Branch Coverage (C1)” and “Modified Condition / Decision
Coverage (MC/DC)” (see figure 5.19).

Þ Click on “Execute”.

TESSY 4.0 Manual 83

5 Practical exercises

Figure 5.19: Selecting Branch and MC/DC Coverage for test run

A progress dialog will be shown while TESSY generates, compiles and links the test driver
and runs the test. This will take a few seconds.

Figure 5.20: Execute Test dialog while running the test

84 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

5.1.10 Analyzing the coverage

Þ Switch to the Coverage Viewer (CV) perspective.

Figure 5.21: The Coverage Viewer displays the coverage of is_value_in_range

The CV shows the results of the coverage measurement of a previously executed test. Analyzing with
the CV
You can select a default coverage measurement as well for your whole project or
any specific module or test object. Refer to section 6.2.3.4 Coverage tab.

TESSY 4.0 Manual 85

5 Practical exercises

5.1.10.1 The flow chart view

The flow chart view displays the code structure and the respective coverage in graphical
form. Within each flow chart, you will see the decisions and branches of the function being
displayed. Green and red colors indicate whether a decision has been fully covered or a
branch has been reached.

5.1.10.2 The Branch (C1) Coverage view

The Branch C1 Coverage view displays the branch coverage for each individual test case
and test step as well as the total coverage for all test cases and test steps.

Figure 5.22: Branch coverage is_value_in_range

5.1.10.3 The MC/DC Coverage view

The MC/DC-Coverage view displays the coverage of the currently selected decision within
the flow chart view (see figure 5.23). If no decision is selected (as initially when starting
the CV), the MC/DC Coverage view is empty.

86 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.23: Decision coverage is_value_in_range

The current example is_value_in_range has only simple decisions, for which MC/DC is
the same as branch coverage.

5.1.10.4 Analyzing

In our example you can see in the flowchart, that

• three test cases were executed (each with one test step).

• the first decision has an else branch on the right, that was executed three
times.

• the if branch on the left of the first decision was not reached and is therefore
marked red.

• the first decision was not fully covered, so it is marked red.

• the second decision was fully covered and is therefore marked green.

• the else branch on the right of the second decision was reached two times,
the else branch was reached once.

TESSY 4.0 Manual 87

5 Practical exercises

Þ Select the red branch of the first decision (the if branch).

The respective code section is highlighted within the source code view (see
figure 5.24). This allows finding out the execution path of the selected test
step.

Figure 5.24: Code section of the if branch of the first decision

88 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Þ Select the second decision.

The respective code section is highlighted within the source code view (see
figure 5.25).

Figure 5.25: Code section of the second decision

TESSY 4.0 Manual 89

5 Practical exercises

5.1.11 Creating a report

Þ In the Test Project view of the Overview perspective click on the arrow next
to the Generate Report icon and select “Edit Test Details Report Set-
tings. . . ”.

Þ In the dialog click on the button “Browse. . . ” and select your project folder
‘”Example1”.

Þ Click on “Make New Folder” and create a folder “Reports” (see figure 5.26).

Þ Click on “OK” and “Generate”.

Figure 5.26: Creating the folder for reports

TESSY creates the report within the new folder. This will take a few seconds.

The selection of the folder is stored and will be used for any further
report generation.

When finished, TESSY will open the file automatically.

90 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Important: If you get an error “No matching program found for the
file . . . ”, then the Adobe Reader is not installed, which you need to open
the reports (PDF files). Download and install the Adobe Reader from
http://get.adobe.com/reader/ and generate the report again.

Figure 5.27: Content of the test report is_value_in_range

Now you have completed your first test project!

If you use a Version Control System (VCS) providing keyword expansion to embed
version control information in your source files, TESSY will display such expanded
keywords within the test report. The following keywords are available: $Revision$
(Revision number), $Author$ (User who checked in the revision) and $Date$ (Date
and time stamp for the revision).

You can change the default Razorcat logo within the reports to your own company
logo: In the menu bar select “Window” > “Preferences” > “Test Report Options”.
Klick on “Browse” and select your logo image file (PNG, JPG or GIF).

TESSY 4.0 Manual 91

 5 Practical exercises

5.1.12 Repeating the test run with requirements

We will now import some very basic requirements and repeat some steps of this exercise.
Requirement This way you get to know the feature of requirement management and you can consolidate
Management the just learned workflows.

5.1.12.1 Importing requirements

Þ Copy the example requirements document “Is Value In Range Re-

quirements.txt” into a folder of your test project “TESSYPro-
jectABC”. It is located within the TESSY installation directory
\Razorcat\[TESSY-Version]\Examples\IsValueInRange.

Þ Switch to the Requirement Management perspective.

Þ Right click within the blank RQMT Explorer view and select “Import” from
the context menu (see figure 5.28).

Figure 5.28: Importing a requirement

92 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

In the following Import dialog you can import various file formats. In our example we select
the file we just copied into our project:

Þ Click on “. . . ” and select the file “Is Value In Range Requirements.txt” from
your project.

Þ Leave the File Content Type and the Target Document as it is and click “OK”
(see figure 5.29).

Figure 5.29: Import dialog

The newly imported requirement document will be displayed in the RQMT Explorer view
(see figure 5.30).

Figure 5.30: The new requirement document

Þ Right click the document and select “Properties” from the context menu.

Þ Change the alias to “IVIR” and click “OK” (see figure 5.31).

The document alias will be used for reporting, in order to have an abbreviation of
the document name when building the requirement identifier, e.g. IVIR-[1.0] in
our example.

TESSY 4.0 Manual 93

 5 Practical exercises

Figure 5.31: Changing the alias of the new requirement document

5.1.12.2 Committing the requirements document

Committing Before linking any tests to a requirement, the respective requirements document needs to
be checked in as initial revision:

Þ Select the document and click on (Commit Changes) in the global tool bar.

Þ Enter “Initial revision” as commit comment and click “OK” (see figure 5.32).

An initial revision of the requirement document will be created.

Figure 5.32: Comment for the initial revision of the commit

TESSY manages different versions of a requirements document. You can track

any changes either from importing updated versions or from any modifications that
you did directly within TESSY.

94 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

5.1.12.3 Linking test cases with requirements

Þ Switch to the Overview perspective and select the test object.

Þ Select the Requirements Coverage view.

Þ Click on (Always show unlinked Requirements) in the Requirements Co-

verage view.

The view shows the imported requirements and the module, test object and
test cases in a tree-based arrangement.

Important: If the view says “No requirements available”, select

the test object in the Test Project view!

Use the toggle buttons on the right to link modules, test objects or test cases
to requirements:

Þ Link the first test case with the first requirement.

Þ Link the second test case with the second requirement (see figure 5.33).

The third requirement is not linked.

Figure 5.33: Linking test cases with requirements

TESSY 4.0 Manual 95

5 Practical exercises

Remember the values of our test cases:

• Test case 1.1: range start 3, length 2, given value 4, supposed to be inside of the
range (yes)
• Test case 2.1: range start 20, length 8, given value 22. Because we wanted to force
an incorrect output, we stated this to be not inside of the range (no).

Þ Switch to the TDE perspective.

Þ In the Test Item view select the first test case and have a look at the Test
Definition view: It shows the requirements we just linked with our test cases.

Þ Select the second test case.

The second requirement will be displayed (see figure 5.34).

Since we did not link any requirement to the third test case, the “Linked
Requirements” will be empty when selecting the third test case.

Figure 5.34: Test Definition view within TDE with linked requirement

5.1.12.4 Creating a planning coverage report

At this stage we can already generate a report showing the planned test case for our
requirements:

Þ Switch to the Test Project view of the Overview perspective and click on the
arrow next to the Generate Report icon .

Þ Select “Edit Planning Coverage Report Settings. . . ” (see figure 5.35).

96 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.35: Editing the settings of a Planning Coverage Report

Þ A dialog for the settings for the Planning Coverage Report will open.

Figure 5.36: Dialog of the settings for the Planning Coverage Report

TESSY 4.0 Manual 97

 5 Practical exercises

Þ Select an output directory for the report (default: C:\tessy\report).

Þ Select the first four Report Options (default).

Þ Select the Requirement.

Þ Do NOT select any Test Means.

Þ Click on “Generate”.

A planning coverage report will be created.

Planning
Coverage Report

Figure 5.37: Planning coverage report of the IVIR requirement document

The report shows the available requirements and the linked test cases. It provides an
overview about the planned tests if all requirements are covered by at least one test case.
Since we have links to two of our requirements, the resulting requirement coverage should
be as shown above.

98 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Notice the usage of the requirement document name and alias within the report!
It is important to select an appropriate alias in order to get useful report outputs.

We have planned test cases for the first two requirements, whereas the third requirement
is not yet linked with any test case, because there are no tests available to validate this
requirement.

5.1.12.5 Executing the test and examining the coverage

We will now execute our tests again to see the results of the test cases with respect to the
linked requirements within the execution coverage report.

Þ Switch to the Overview perspective and execute our test object

is_value_in_range again: Click on the Execute Test icon .

Þ Generate a test details report to review the results on test object level: Click
on the arrow next to the Generate Report icon (see figure 5.38).

Figure 5.38: Generating a Test Details Report

The report will open automatically.

Þ Have a look at the second page.

The report will show additional paragraphs with the linked requirements after
the overview pages and for each test case (see figure 5.39):

TESSY 4.0 Manual 99

 5 Practical exercises

Test Details
Report

Figure 5.39: Part of the generated test report of is_value_in_range

Execution Now we will generate a coverage report showing the test case results with respect to our
Coverage Report requirements:

Þ In the global tool bar click on the arrow next to the Generate Report icon
and select “Generate Execution Coverage Report” (see figure 5.40).

Figure 5.40: Creating an Execution Coverage Report

100 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

TESSY creates the coverage report showing the available requirements and the
results of the linked test cases. It provides an overview about the current test
status, e.g. if tests for any requirements are failed.

Since one of our test cases was passed while the other one was failed, the
resulting requirement coverage should be as in figure 5.41.

Test Coverage
Report

Figure 5.41: Coverage Report of is_value_in_range

The first requirement has one test case linked which was successfully executed, the second
requirement has also one test case linked, but this one failed. The third requirement has
still no test case assigned.

Now you successfully finished the exercise is_value_in_range.

TESSY 4.0 Manual 101

 5 Practical exercises

5.1.13 Reusing a test object with a changed interface

If the interface of the test object changes, TESSY will indicate the changes with specific
test readiness states. With the Interface Data Assigner (IDA) you can assign the elements
Using IDA of a changed (new) interface to the elements of the old one.

In this section we will change the interface of the test object by editing the C-source and
exercise a reuse operation within the IDA.

Important: Make sure to keep the original C-source file “is_val_in_range.c”

and edit a copy. Do not change the original file in folder “C:\Program fi-
les\Razorcat\tessy_4.0\examples\IsValueInRange”!

5.1.13.1 Changing the interface of the test object

The target of this section is to show you the three different test readiness states
“changed”, “deleted” and “new”.

Therefore we will first change a test object and add two new test objects cal-
led “delete” and “new”. In a second step we will remove the “delete” object so it
appears as deleted. The names are chosen to illustate the test readiness states.

Þ Switch back to the Overview perspective.

102 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.42: Overview perspective after test run (with requirements)

Þ Select the module and “Edit Source” from the context menu (see figure 5.43).

Figure 5.43: Use the context menu to edit a source

The C-source is opened.

Þ Select the line “result is_value_in_range (struct range r1; value v1) ”
(see figure 5.44).

TESSY 4.0 Manual 103

 5 Practical exercises

Figure 5.44: Editing the C-source file is_val_in_range.c

Changing the
C-source
Þ Edit the line as shown in figure 5.45

Figure 5.45: Changed C-source file of is_value_in_range

Þ Now add a “delete” object and a “new” object as shown in figure 5.46

104 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

Figure 5.46: Adding a “delete” and “new” object

Þ Save the changes with “File” > “Save” and close the file.

Þ Click on to analyze the module.

In the Test Project view you can see now three test objects with different test
readiness states (see figure 5.47):

Figure 5.47: Changed and new test objects of is_value_in_range

The test object is_value_in_range has changed. You see the test object, but
there is no operation possible. You have to start a reuse operation.

The test objects “deleted” and “new” are newly available since the last in-
terface analysis. You have to add test cases, test steps and enter data for a
test.

Deleted test objects that did not contain any test cases and test steps are not
displayed anymore because they are considered as not important. If you want to
display a deleted test object, you have to add at least one test case and one test
step!

TESSY 4.0 Manual 105

5 Practical exercises

Before deleting the test object “deleted”, we will have to add some test cases with test
steps:

Þ Switch to the Test Item view and add a test case and a test step.

Þ Switch to the Overview perspective and to the Test Project view.

Þ Select the module and “Edit Source” from the context menu.

Þ Remove the test object “deleted” as shown in figure 5.48.

Figure 5.48: Remove the code for test object “deleted”.

Þ Save the changes with “File” > “Save” and close the file.

Þ Click on to analyze the module.

In the Test Project view you can see now three test objects with three different
test readiness states (see figure 5.49):

Figure 5.49: Changed and new test objects of is_value_in_range

The test object is_value_in_range is still displayed as changed since there

was no reuse operation yet.

106 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

The test object “deleted” has been removed. You still see the object, but there
is no operation possible.

The test object “new” is not shown anymore as “newly available”, because the
last interface analysis already detected the object as new.

Important: Note that removed and changed test objects require a reuse ope-
ration before you can further operate on them!

5.1.13.2 Assigning the changed interface of the test object

Warning: If you do not assign the interface object, you will loose the test data
entered for parameter v1 and the global variable v1 will have no values after the
reuse operation!

Þ Switch to IDA perspective.

Þ Double click the test object “is_value_in_range” in the Test Project view to
assign its interface.

Please notice (see figure 5.50):

• On the right side within the IDA perspective you see the Compare view with the
test object is_value_in_range.
• Within the Compare view you can see the old interface of our test object
is_value_in_range and the new one. The red exclamation mark within the new
interface indicates the need to assign this interface object before starting the reuse.
• The title of the view shows the old name versus the newly assigned name. In our
case the names are the same since only the interface did change.

TESSY 4.0 Manual 107

5 Practical exercises

Figure 5.50: Changed, deleted and new test object of is_value_in_range

Þ Assign the interface object “long v1” either by using the context menu or just
drag and drop from the left side (see figure 5.51).

Figure 5.51: Use drag and drop in IDA

The red exclamation mark turns to a green check .

Þ Commit the assignments by clicking on (Commit) in the menu bar of the

Compare view.

The data of all test cases and test steps will be copied from the old interface
to the current test object interface.

108 TESSY 4.0 Manual

 5.1 Quickstart 1: Unit test exercise is_value_in_range

The test object changes to yellow to indicate that all test cases are ready
to be executed again.

Please notice the following habits:

• Removed and changed test objects require a reuse operation before you can further
operate on them.
• Those test objects that remained unchanged will automatically be reused, e.g. they
will be ready to use without further activities required.
• Removed test objects will only be displayed as “removed”, if they did contain any
test cases and test steps.

TESSY 4.0 Manual 109

5 Practical exercises

5.2 Quickstart 2: The Classification Tree Editor (CTE)

To understand the handling and create a simple classification tree we consider some aspects
from the Quickstart 1: Unit test exercise is_value_in_range.

We will continue with the quickstart example “is_value_in_range”. If you

have not done the exercise, proceed with the Quickstart 1: Unit test exercise
is_value_in_range up to section Designing test cases.

After editing the test object interface and switching to the CTE, the root “is_value_in_range”
of the classification tree appears on the draw pad.

Important: If you cannot see the root on the draw pad, move the scrollbar at
the bottom or enlarge the window.

Figure 5.52: CTE with the root “is_value_in_range”

110 TESSY 4.0 Manual

 5.2 Quickstart 2: The Classification Tree Editor (CTE)

Example is_value_in_range

Our three test-relevant aspects are the start value of the range, the length and the
position, which is a given value under test (v1). We should have test cases which result in
“inside the range”, and other test cases which result in “outside”, to have a high coverage
of possibilities.
So the three test-relevant aspects to be used for classifications are start value, length and
position and they thus form the basis of a classification tree.

In the ’Advanced Knowledge’ of this manual you find detailed information of using
The Classification Tree Method (CTM).

5.2.1 Creating classifications

Þ Select the root tree item (“is_value_in_range”).

Þ Create a new classification either using the context menu (“New” > “Classifi-
cation”) or press Ins (see figure 5.53).

Figure 5.53: Creating a new classification with the context menu

Þ Double click the new classification or press F2 to start the inline editor for the
tree item.

Þ In the window Element Properties rename the new classification to

range_start.

TESSY 4.0 Manual 111

5 Practical exercises

Figure 5.54: Renaming the new classification

Þ Create two further classifications range_length and position .

Figure 5.55: Classifications of is_value_in_range

Within the draw pad you can move the classifications with drag and drop: Select
either a classification, a sub tree (click on ) or select all (click on ) and press
the mouse button until the cursor turns into a cross with four arrows , then
move the selection.

112 TESSY 4.0 Manual

 5.2 Quickstart 2: The Classification Tree Editor (CTE)

5.2.2 Creating classes

Þ Now create the classes “positive”, “zero” and “negative” for the classifications
range_start und range_length: Right click the classification and select “New”
> “Class” or select the classification and press Ins.

Þ Create the classes “inside” and “outside” for the classification “position”.

Þ In the tool bar click on (Arrow Layout) to rearrange the tree for a better
overview.

Try the several layouts for the tree, e.g. leftdown or horizontal
may give you a better overview.

Now the classification tree should look like in figure 5.56.

Figure 5.56: Simple classification tree for is_value_in_range

5.2.3 Entering test data

Þ Select the class “positive” of the classification “range_start”.

Þ In the Test Data view on the right enter the value 3 as range start (see figure
5.57).

Important: To enter the data it might be necessary to enlarge the

window or to change the width of the first column containing the
interface elements.

TESSY 4.0 Manual 113

5 Practical exercises

Figure 5.57: Entering data in CTE

Now enter more test data for the other classes of the classification “range_start”:

Þ Select the class “zero” and enter 0 as range_start.

Þ Select the class “negative” and enter -3 as range_start.

When selecting a tree item within the classification tree you will see
the test data entered for this tree item within the Test Data view.

Notice the following habits:

• The name of the selected item will be displayed as column header in the Test Data
view (see red marked sections in figure 5.57, here: “positive”).
• The class will be marked with a blue dot (when selected) to indicate that test data
is assigned.
• All tree items with test data assigned will be marked by a yellow dot when not
selected (e.g. select the root “is_value_in_range”).

114 TESSY 4.0 Manual

 5.2 Quickstart 2: The Classification Tree Editor (CTE)

Figure 5.58: Entering more data in CTE

Now enter test data for the classes of the classification “range_length”: Entering values
for
Þ Select the class “positive” of the classification “range_length” and enter 2 as “range_length”
range_length.

Þ Select the class “zero” and enter 0 as range_length.

Þ Select the class “negative” and enter -2 as range_length.

Notice the following habits:

• All tree items with assigned test data are marked with a yellow dot, when not
selected.
• When selecting a tree item, you will see the test data entered for this item within
the Test Data view.
• When selecting any interface element within the Test Data view, all classification
tree elements that contain test data for this interface element will be marked with
a blue dot.

TESSY 4.0 Manual 115

5 Practical exercises

Figure 5.59: Blue dots indicate that “range_start” elements contain data

5.2.4 Creating test cases

Now create 9 test cases:

Þ Select the pane on the lower left (test item list).

Þ Create the test cases either using the context menu (“New” > “Testcase”, see
figure 5.60) or press Ins.

Figure 5.60: Creating test cases in the test item list

Test cases are defined by setting markings in the combination table: If you move the mouse
pointer over the combination table, connecting lines to the classes of the classification tree
are drawn. If the mouse pointer is placed over a point of intersection it is changed to a
circle.

116 TESSY 4.0 Manual

 5.2 Quickstart 2: The Classification Tree Editor (CTE)

Þ Select the first test case in the test item list.

Þ Move the mouse over the line of the first test case.

Þ Click on the circles that connect the first test case with the two positive classes.

The test data for the test case 1 is displayed within the Test Data view (see
figure 5.61). The test data is read-only because it is defined by the marks set
within the combination table.

Figure 5.61: Defining test cases in the combination table of CTE

Þ Create more marks within the combination table for the other test ca-
ses to cover completely all classes of the classifications “range_start” and
“range_length” with your test cases.

For example the CTE could look like in figure 5.62.

TESSY 4.0 Manual 117

5 Practical exercises

Figure 5.62: Completed table with all test cases for example “is_value_in_range”

Certainly there are various possibilities of combining the classes within the test
cases.

As you can see the classification “position” is still not marked for any test item. This would
be rated as an error because each class of the classification tree should be marked at least
within one test item.

We also did choose all possible combinations for the first two classifications. In a
real example you would need to select only the most interesting combinations in order to get
a reasonable number of test cases.

Þ Select the test cases one after another and review the test data resulting from
your mark settings being displayed within the Test Data view (see figure 5.63).

Þ Click on to save the classification tree.

118 TESSY 4.0 Manual

 5.2 Quickstart 2: The Classification Tree Editor (CTE)

Figure 5.63: Test data is displayed when selecting a test case in the combination table

Þ Switch to the TDE perspective.

Figure 5.64: Test data displayed within TDE

TESSY 4.0 Manual 119

5 Practical exercises

You will see the test cases updated with the test data values entered within the CTE
perspective.

Please notice the following habits:

• Test items with values stemming from the CTE perspective are marked with new
status indicators: (test case) and (test steps).
• Values stemming from the CTE are read-only. If you want to change them, switch
back to the CTE perspective and do your changes there.

120 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3 Quickstart 3: Component test exercise interior_light

To understand the handling in this chapter we assume you have worked with
TESSY in unit testing. If not, please proceed with the Quickstart 1: Unit test
exercise is_value_in_range first and come back to this chapter afterwards.

If you have already worked with former versions of TESSY, this chapter may help
you to learn the differences in handling with TESSY 3.x!

Integration testing of functions = component testing

Isolated testing or testing of isolated functions is unit testing.

Testing a component of interacting functions, consisting e.g. of push() and pop()
calls is a very simple example for Integration testing: Functions that do not
necessarily have a calling relation but work together, e.g. operating on common
data, with the objective to achieve a common goal.
At least one of the functions combined in a component must be callable from the
outside of the component to stimulate the functionality of the component.
Normally several functions are callable from external. We call these functions
“component functions”. A test for a component is no longer a single function
call but a sequence of calls to the component functions.

The calls to the component functions stimulate the component. Like testing
of a single function, a test case for a component also comprises of input and output
data. A component may have internal functions that can not be called from the
outside of the component, but only from functions inside the component.
Relevant for the result of a component test is the sequence of the calls from within
the component to (callable) functions in other components. This is with respect to
the number of the calls, the order of the calls, and the parameters passed by the
calls to other components.
Obviously, the functionality of the functions in a component and the interfaces
between them are tested by component testing, at least for the most part. Hence,
component testing can be considered well as integration testing for the functions in
the component.

TESSY 4.0 Manual 121

5 Practical exercises

You already know the basic functionality of a unit test. We will now follow a simple source
code example to show how to excercise component testing with TESSY.

Example interior_light

The interior light of a car shall be controlled by two inputs: The door and the
ignition of the car.
The functional specification comprises of three simple requirements:

• If the door is closed, the interior light shall go on.

• The interior light shall go off after 5 seconds at the latest.
• If the ignition is switched on, the interior light shall go off immediately.

Figure 5.66: Example interior_light; ECU = Electronic Control Unit

The specification above is obviously not complete. Especially the initial state of door,
ignition, and light is not given. It is not specified what shall happen e.g. if the ignition
is switched off after it was switched on, etc. But this simple specification is sufficient to
demonstrate temporal component testing with TESSY.

For simplicity, we assume that the initial state shall be

• Door = open
• Ignition = off
• Light = off

122 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3.1 Creating the test project

Þ Create a test project “interior_light” (if you need any help, consult section
Quickstart 1: Unit test exercise is_value_in_range).

Þ Copy the C-source file “interior_light.c” which is stored under

“C:\Program files\Razorcat\TESSY_4.0\Examples”.

Þ Paste it into your project root and add it to the module.

Þ Open the module.

The C-source code will now be analyzed, afterwards the test project view dis-
plays the functions of the source (see figure 5.67).

Figure 5.67: Test Project view with new project interior_light

Þ In the Properties view switch the Kind of Test to “Component” (see figure
5.68).

Important: By default, “Unit” is selected. This is the point where

unit testing and component testing begin to part!

TESSY 4.0 Manual 123

5 Practical exercises

Figure 5.68: Selecting “Component” in the module properties

Now the only test object displayed has the default name “Scenarios” (see figure 5.69).

Figure 5.69: Scenario of a component test

This is different to unit testing with TESSY, where the names of the possible test objects
in interior_light.c (i.e. the functions) would be listed instead.

5.3.2 The heartbeat function

You can open the C-source file with a rightclick onto the module and choosing “Edit
Source” from the context menu. The C++-Perspective will open and the file will be
displayed (see figure 5.70).

124 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

Figure 5.70: C-source code interior_light

TESSY 4.0 Manual 125

5 Practical exercises

This implementation features a heartbeat function, the tick() function. The implementa-
tion assumes that tick() is called every 10 ms. Based on this assumption, for the timer the
value “500” is calculated.

Heartbeat Function

To be able to test the temporal behaviour of a component in a simulated environ-

ment, a simulated time base needs to be available. This means, a certain function inside
the component is called in known equidistant times (e.g. every 10 ms). The calls to this
function represent the “heartbeat” of the component. They provide a time reference for the
testing of the temporal behaviour of the component.
The heartbeat function is usually called “handler function” or “work task” or simply “tick”.

Figure 5.72: If a heartbeat function exists, timely behavior can be tested.

126 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3.3 Preparing the test interface

Þ Switch to the TIE perspective.

Figure 5.73: The initial interface

In the section “External Functions” of the interface, the two functions LightOff()
and LightOn() are listed. These two functions are used (called) by the component
“Interior Light”, but these two functions are not implemented in interior_light.c.
The component “Interior Light” expects these two functions to be provided by anot-
her component of the application.
However, we want to test the component “Interior Light” without that other com-
ponent, i.e. isolated from the rest of the application. Therefore, we direct TESSY
to provide replacements, i.e. stub functions for these two functions.

TESSY 4.0 Manual 127

5 Practical exercises

To create the stubs:

Þ Rightclick the function “LightOff()” and choose “Create Stub” (see figure
5.74).

Þ Repeat for the function “LightOn()”.

The dots with the blue border will change to blue filled dots .

Figure 5.74: Creating the stubs

In section “Component Functions”, all functions of the component “Interior-Light” are

listed.

The passing direction of the variable timer is “Irrelevant”, because it is not used by
init(). Since we are only interested in the variables “sensor_door”, “sensor_ignition”,
and “state_door” as input, we manually set the passing direction for these variables to
“In”:

Þ Click in a cell and choose “In” for “sensor_door”, “sensor_ignition”, and

“state_door” (see figure 5.75).

Figure 5.75: The final passing directions of variables used by init()

Þ Save the changes by clicking on .

128 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3.4 Adding test cases

Þ Add two test cases in the Test Items view.

Þ Switch to the SCE perspective (or doubleclick a test case, in this case the SCE
perspective will open automatically).

Þ The bracket of the scenarios in the Test Project view will open to indicate that
it contains test cases but no data (see figure 5.76).

Figure 5.76: Test Project view with a component test

You can add a description to the test cases (see figure 5.77):

1. Door cloed: Light off after 5 seconds.

2. Door closed and ignition on: Light off immediately.

These are the two scenarios we are going to test.

Figure 5.77: Adding a description to test cases

TESSY 4.0 Manual 129

5 Practical exercises

5.3.5 Editing data

The view Test Data of Scenarios is similar to unit testing:

Þ Go to the view Test Data of Scenarios within the SCE perspective.

Þ Doubleclick the value cells in the INIT column to open the inline editor (see
figure 5.78).

Figure 5.78: Inline editor of the view Test Data of ’Scenarios’

Þ Choose the following selections:

sensor_door = open

sensor_ignition = off

state_door = open

Figure 5.79: View Test Data of ’Scenarios’

Þ Use the same data for the second scenario.

Þ Save by clicking on .

130 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

The view External Function Calls displays the two functions LightOn() and LightOff()
that the component “Interior-Light” supposes in another component. TESSY provides
stub functions for these two functions during component testing.

Figure 5.80: View External Function Calls

Please notice that you can rename the test cases: Renaming Test
Cases
Þ Rightclick a test case and choose “Rename” from the context menu.

The new name will be displayed in the center of the SCE perspective (see figure
5.81).

Figure 5.81: The names of the test cases are displayed in tabs of the view Work Task

TESSY 4.0 Manual 131

5 Practical exercises

5.3.6 Configuring the work tasks

As we know, the implementation of the component Interior Light assumes that the function
tick() is called every 10 ms, i.e. the function tick() is the work task or handler task or he-
artbeat of the component. To enable TESSY for temporal component testing, Tessy must
know about this, i.e. we must specify tick() as work task for the component manually.

To specify tick() as work task:

Þ Select the tick().

Þ Click on (Set as Work Task) in the tool bar (see figure 5.82).

The icon of the function will change from to .

Figure 5.82: Setting the Work Task

5.3.7 Designing scenarios

5.3.7.1 First scenario

Since we want to test the temporal behavior of the component, we need to establish a
time base:

Þ Within the Scenario view in the center of the SCE perspective click on
(Insert Time Steps).

Þ Click three more times to include all in all 4 time steps.

The scenario consists of 4 calls to the work task, in our case tick(). The calls occur at 0
ms, 10 ms, 20 ms, 30 ms simulated time.
To stimulate the component besides the calls to tick(), you can simply drag and drop a
function to the scenario.

Þ Drag the init() from the Component Function view to the Scenario view (see
figure 5.83).

132 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

Figure 5.83: Dragging the function onto the scenario

Now we stimulate the component actually. We drag the component function set_sensor_door()
to 30 ms simulated time:

Þ Drag the component function set_sensor_door() to 30 ms simulated time (see

figure 5.84).

Figure 5.84: set_sensor_door() is dragged to 30 ms simulated time

Now you have to specify a value for the parameter of set_sensor_door() in the properties
of set_sensor_door():

Þ Open the Properties view and click in the cell under “value”.

Þ Enter “closed”.

The value will be displayed in the parameter of the time step function (see
figure 5.85).

TESSY 4.0 Manual 133

5 Practical exercises

Figure 5.85: The parameter of set_sensor_door() is set

In the scenario above, after the fourth call to tick(), TESSY calls the component function
set_sensor_door() with the parameter value “closed”. This should cause the component
to react by calling LightOn(). We know from the implementation of Interior Light that
this call will happen one tick later, i.e. after TESSY has called tick() a fifth time, at 40
ms simulated time.

Þ Specify the expected result by dragging the function LightOn() from the Ex-
ternal Function Calls tab to 30 ms simulated time (see figure 5.86).

Figure 5.86: Dragging the function

134 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

The scenario above expects the call to LightOn() to happen at 30 ms simulated time, i.e.
prior to the fifth call to tick(). This is indicated by the time frame “30 - 30 ms”. We know
that the call will occur one tick later, and we want to treat this behavior as correct:

Þ Extend the time frame in the properties to 10 ms (see figure 5.87).

Figure 5.87: Extending the time frame

Notice that the icon of the test object has changed to yellow , indicating that
the scenario is executable (the purple sign indicates a comment or description).

Besides the call to LightOn(), we also expect a call to LightOff(). Since the ignition will
not be operated in this scenario, we expect the call to LightOff() to occur 5 seconds after
the call to set_sensor_door() at the latest:

Þ Drag LightOff() to 30 ms and extend the time frame by 5000 ms (see figure
5.88).

Þ Save the data.

TESSY 4.0 Manual 135

5 Practical exercises

Figure 5.88: Setting the call “LightOff” and extending the time frame

In the scenario above, we have specified that we expect the call to LightOff() after
5 seconds at the latest, i.e. we would take a call to LightOff() after, say, 4 seconds
as a correct result.
If we would want to accept only the occurrence of the call to LightOff() at 5030 ms
of simulated time as correct, we then could use the context menu’s Insert Time
Step At. . . command to create this point in time and assign the expected call to
LightOff() to 5030 ms of simulated time, of course with the property “Time Frame”
set to 0 and not to 5300.

136 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3.7.2 Second scenario

Alike the first scenario:

Þ Insert some time steps into the scenario.

Þ Drag and drop the component function set_sensor_door() to 10 ms simulated

time.

Þ Set the value of the parameter to “closed”.

Þ To specify the expected behavior, drag and drop the function LightOn() from
the External Function Calls tab to 10 ms simulated time.

Þ Increase the time frame for LightOn() by 10ms.

Þ Drag and drop the function “set_sensor_ignition” to 40 ms simulated time.

Þ Select the 40 ms time step: The test data view will show a new column named
“40 ms”. Set the value of the variable “sensor_ignition” to “on” and set the
other values to be ignored (see figure 5.89).

Þ Save the data.

The time step will now get a small yellow icon indicating that test data is fully
available.

Figure 5.89: Setting values to “ignore”

Þ To specify the expected behavior, drag and drop the function LightOff() from
the External Function Calls tab to 40 ms simulated time.

The second scenario is now complete (see figure 5.90).

TESSY 4.0 Manual 137

5 Practical exercises

Figure 5.90: Designing the second scenario

The expected result of this action is the interior light going off immediately, i.e. after
the next call to the work task tick(). This is specified in the scenario by dragging
and dropping the function LightOff() to 40 ms simulated time and by increasing the
time frame by 10 ms.
This is performed very similar as in the first scenario.

5.3.8 Executing the scenarios

To execute the scenatios,

Þ click on in the tool bar of the Test Project view.

138 TESSY 4.0 Manual

 5.3 Quickstart 3: Component test exercise interior_light

5.3.9 Evaluating the scenarios

After the scenarios have been executed, the color of the scenario icons changes to green.
This indicates an overall “passed” verdict (see figure 5.91).

Figure 5.91: The scenarios of the component “passed” the test

TESSY 4.0 Manual 139

5 Practical exercises

5.4 Quickstart 4: Exercise C++

To understand the overall handling and create a simple classification tree we consider
some aspects from the Quickstart 1: Unit test exercise is_value_in_range. Follow the
steps below to import a C++ project with sample test cases:

Þ In TESSY click on “File” > “Select Project”.

Þ In the “Select Project” dialog click on the icon (Import Project) .

Þ Select the TESSY Project File under

“C:\Program files\Razorcat\tessy_4.0\Examples\C++”

Þ Click “Open”.

Figure 5.92: Importing a project

TESSY will show an example project within the project list. Such an example
project will be copied completely to a user defined location when being opened.
(see figure 5.93).

140 TESSY 4.0 Manual

 5.4 Quickstart 4: Exercise C++

Figure 5.93: Cloning the project.

Þ Double-click the C++ example project and choose an appropriate location.

Figure 5.94: Cloning the project.

The project root will be displayed within the bottom line of TESSY.

Þ Click “OK”.

TESSY 4.0 Manual 141

5 Practical exercises

Figure 5.95: The project root is displayed within the bottom line of TESSY.

TESSY needs to restart and will open the project automatically.

After the restart the window “Restore Database” is displayed.

Þ Click “OK”.

142 TESSY 4.0 Manual

 5.4 Quickstart 4: Exercise C++

Figure 5.96: Restoring the database

TESSY will now restore the files.

Þ After a few seconds the new project will be displayed within the Test Project
view of TESSY.

Figure 5.97: Test project view with the C++ project

Please review the test cases defined for some selected test objects. You will find more
explanation and comments on the specifics of C++ testing within the application note
“Using C++”.

TESSY 4.0 Manual 143

5 Practical exercises

5.5 Quickstart 5: Test driven development (TDD)

The test driven development support in TESSY allows to prepare tests already before
any source code is available. If you have specification of what the individual software
functions should do, you can manually create (synthetic) test objects and their (synthetic)
interface variables. Afterwards you can create test cases and fill them with data as for
normal test objects. Once the first version of the software is available, you need to assign
the test objects to their respective implementation functions and you can start running
the tests against the implementation. To create synthetic test objects for test driven
development:

Þ Create a module without assigning a source file. Only modules in this initial
state allow to create synthetic test objects.

Þ Add new test objects by clicking on the icon (New Test Object). Rename
the newly created test objects.

Figure 5.98: Adding synthetic test objects.

Each synthetic test object has an initially empty interface. To add variables:

Þ Change to the TIE perspective.

144 TESSY 4.0 Manual

 5.5 Quickstart 5: Test driven development (TDD)

Figure 5.99: Adding synthetic variables.

Þ Click on the icon (New Variable) to create input and output variables.
You can create variables of all basic types to build the necessary interface.
Afterwards you can create test cases.

Þ Change to the CTE perspective.

Figure 5.100: Creating test cases for TDD.

Þ Assign values to CTE tree nodes as with normal variables.

Þ Change to the TDE perspective.

TESSY 4.0 Manual 145

5 Practical exercises

Figure 5.101: Filling test cases for TDD.

Þ Enter all required test data and expected values.

The test cases will get a yellow icon if they are completely filled with test data. You cannot
execute the tests because there is no source file to be tested available yet. But you can
create a test details report showing the specification of all test cases:

Figure 5.102: Test specification report for TDD.

146 TESSY 4.0 Manual

 5.5 Quickstart 5: Test driven development (TDD)

When a first version of the source file is available, add this file to your module. Now you
can analyze the module and you will see the functions contained within the source file and
the test objects that you prepared for test driven development. It doesn’t matter if the
implemented test objects have other names, you can assign test objects within the next
step.

Figure 5.103: Implementation source file available for TDD.

To assign or reuse test objects:

Þ Change to the IDA perspective.

Þ Assign test objects as described within Compare view.

Figure 5.104: Assignment of synthetic test objects to the implemented functions.

Þ Commit changes within the Compare view.

TESSY 4.0 Manual 147

5 Practical exercises

Important: When assigning synthetic test objects to the real implementation,

the synthetic variables will not appear within the new interface because the pur-
pose of this assignment is to assign the values of all synthetic variables to their
respective implemented variables.

In the example shown within figure 5.104 you can see that the implementation uses a
struct to hold all parameters whereas the synthetic test object has all values within scalar
variables. Such differences can be resolved using the IDA assignment as it would be done
for normal interface changes.

The test object “calc_add” is now ready for execution, all prepared test cases and data
are available.

Figure 5.105: Readily assigned TDD test cases.

148 TESSY 4.0 Manual

 6 Working with TESSY

This chapter provides detailed information of the test activities possible with TESSY. The headlines
of the sections follow the actions taken during a test and refer to the corresponding perspectives
and views, e.g. “CTE: Designing the test cases”.
The subsections describe the views of each perspective, displaying used icons and status indicators
and giving quickly answers to your questions of “What can I do within this view?” and “How do
I do . . . ?”. So if you need help at some point, ask “Where am I?”. You should find the answer
easily within this chapter. If you have questions about the workflow, consult chapter 5 Practical
exercises.

Some views are displayed within various perspectives. Because views are context
sensitive, not every operation is possible within every perspective. In this case the
manual will refer to the respective section and perspective, where all operations of
the view are possible.

6.1 Menu Bar Entries: Setting up the basics . . . . . . . . . . . . . . . 154

6.1.1 File menu . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.1.2 Edit menu . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.3 Window menu . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.4 Windows > Preferences menu . . . . . . . . . . . . . . . . . 155
6.1.5 Help menu . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.2 Overview perspective: Organizing the test . . . . . . . . . . . . . . 161
6.2.1 Structure of the Overview perspective . . . . . . . . . . . . . 161
6.2.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 162
6.2.3 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 191
6.2.4 Requirements Coverage view . . . . . . . . . . . . . . . . . 201
6.2.5 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . 201
6.2.6 Test Results view . . . . . . . . . . . . . . . . . . . . . . . 210
6.2.7 Evaluation Macros view . . . . . . . . . . . . . . . . . . . . 211

150 TESSY 4.0 Manual

 6.2.8 Console view . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.2.9 Suspicious Elements view . . . . . . . . . . . . . . . . . . . 213
6.2.10 Variants view . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3 C/C++: Editing the C-source . . . . . . . . . . . . . . . . . . . . 217
6.3.1 Opening the C/C++ perspective . . . . . . . . . . . . . . . 217
6.3.2 Structure of the C/C++ perspective . . . . . . . . . . . . . 218
6.3.3 Editor view . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.3.4 Project Explorer view . . . . . . . . . . . . . . . . . . . . . 220
6.3.5 Outline view . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.3.6 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 222
6.3.7 Console view . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.4 Requirement management . . . . . . . . . . . . . . . . . . . . . . 223
6.4.1 Structure of the Requirement Management perspective . . . . 224
6.4.2 RQMT Explorer view . . . . . . . . . . . . . . . . . . . . . 225
6.4.3 Requirements List view . . . . . . . . . . . . . . . . . . . . 234
6.4.4 Requirement Editor view . . . . . . . . . . . . . . . . . . . 235
6.4.5 Validation Matrix view / VxV Matrix view . . . . . . . . . . . 238
6.4.6 Test Means view . . . . . . . . . . . . . . . . . . . . . . . 239
6.4.7 Link Matrix view . . . . . . . . . . . . . . . . . . . . . . . 240
6.4.8 Suspicious Elements view . . . . . . . . . . . . . . . . . . . 245
6.4.9 Attached Files view . . . . . . . . . . . . . . . . . . . . . . 250
6.4.10 Attributes view . . . . . . . . . . . . . . . . . . . . . . . . 251
6.4.11 History view . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.12 Differences view / Reviewing changes . . . . . . . . . . . . . 254
6.4.13 Related Elements view . . . . . . . . . . . . . . . . . . . . 256
6.4.14 Problems view . . . . . . . . . . . . . . . . . . . . . . . . 258
6.4.15 Document Preview . . . . . . . . . . . . . . . . . . . . . . 259
6.4.16 Requirements Coverage view . . . . . . . . . . . . . . . . . 261
6.5 TEE: Configuring the test environment . . . . . . . . . . . . . . . . 266
6.5.1 Starting the TEE . . . . . . . . . . . . . . . . . . . . . . . 267
6.5.2 Structure of the TEE . . . . . . . . . . . . . . . . . . . . . 268
6.5.3 Icons of the tool bar . . . . . . . . . . . . . . . . . . . . . 269
6.5.4 Status indicators . . . . . . . . . . . . . . . . . . . . . . . 270
6.5.5 Viewing all available configurations . . . . . . . . . . . . . . 272
6.5.6 Configuration files . . . . . . . . . . . . . . . . . . . . . . 274
6.5.7 Customizing the configurations . . . . . . . . . . . . . . . . 275

TESSY 4.0 Manual 151

6 Working with TESSY

6.6 TIE: Preparing the test interface . . . . . . . . . . . . . . . . . . . 282

6.6.1 Structure of the TIE perspective . . . . . . . . . . . . . . . 283
6.6.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 283
6.6.3 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 283
6.6.4 Interface view . . . . . . . . . . . . . . . . . . . . . . . . 284
6.6.5 Plot Definitions view . . . . . . . . . . . . . . . . . . . . . 296
6.7 CTE: Designing the test cases . . . . . . . . . . . . . . . . . . . . 300
6.7.1 The basic idea . . . . . . . . . . . . . . . . . . . . . . . . 300
6.7.2 Starting CTE . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.7.3 Structure of the CTE perspective . . . . . . . . . . . . . . . 301
6.7.4 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 301
6.7.5 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 301
6.7.6 Classification Tree view . . . . . . . . . . . . . . . . . . . . 302
6.7.7 Test Data view . . . . . . . . . . . . . . . . . . . . . . . . 308
6.7.8 Test data assignment precedence rules . . . . . . . . . . . . 309
6.8 TDE: Entering test data . . . . . . . . . . . . . . . . . . . . . . . 312
6.8.1 Structure of the TDE perspective . . . . . . . . . . . . . . . 312
6.8.2 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 313
6.8.3 Test Results view . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.4 Evaluation Macros view . . . . . . . . . . . . . . . . . . . . 314
6.8.5 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.6 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 314
6.8.7 Test Data view . . . . . . . . . . . . . . . . . . . . . . . . 315
6.8.8 Test Definition view . . . . . . . . . . . . . . . . . . . . . 335
6.8.9 Declarations / Definitions view . . . . . . . . . . . . . . . . 336
6.8.10 Prolog/Epilog view . . . . . . . . . . . . . . . . . . . . . . 337
6.8.11 Stub Functions view . . . . . . . . . . . . . . . . . . . . . 346
6.8.12 Usercode Outline view . . . . . . . . . . . . . . . . . . . . 350
6.8.13 Plots view . . . . . . . . . . . . . . . . . . . . . . . . . . 351
6.8.14 Plot Definitions view . . . . . . . . . . . . . . . . . . . . . 353
6.9 CV: Analyzing the coverage . . . . . . . . . . . . . . . . . . . . . 354
6.9.1 Structure of the CV perspective . . . . . . . . . . . . . . . . 355
6.9.2 Instrumentation for coverage measurements . . . . . . . . . . 355
6.9.3 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 358
6.9.4 Called Functions view / Code view . . . . . . . . . . . . . . 359
6.9.5 Flow Chart view . . . . . . . . . . . . . . . . . . . . . . . 360
6.9.6 Statement (C0) Coverage view . . . . . . . . . . . . . . . . 364

152 TESSY 4.0 Manual

 6.9.7 Branch (C1) Coverage view . . . . . . . . . . . . . . . . . . 365
6.9.8 Decision Coverage view . . . . . . . . . . . . . . . . . . . . 366
6.9.9 MC/DC Coverage view . . . . . . . . . . . . . . . . . . . . 367
6.9.10 MCC Coverage view . . . . . . . . . . . . . . . . . . . . . 369
6.9.11 Coverage Report views . . . . . . . . . . . . . . . . . . . . 369
6.10 IDA: Assigning interface data . . . . . . . . . . . . . . . . . . . . . 370
6.10.1 Structure of the IDA perspective . . . . . . . . . . . . . . . 371
6.10.2 Status indicators . . . . . . . . . . . . . . . . . . . . . . . 371
6.10.3 Test Project view . . . . . . . . . . . . . . . . . . . . . . . 371
6.10.4 Properties view . . . . . . . . . . . . . . . . . . . . . . . . 372
6.10.5 Compare view . . . . . . . . . . . . . . . . . . . . . . . . 372
6.11 SCE: Component testing . . . . . . . . . . . . . . . . . . . . . . . 376
6.11.1 Creating component tests . . . . . . . . . . . . . . . . . . . 377
6.11.2 Preparing the test interface . . . . . . . . . . . . . . . . . . 379
6.11.3 Configuring the work tasks . . . . . . . . . . . . . . . . . . 380
6.11.4 Designing the test cases . . . . . . . . . . . . . . . . . . . 382
6.11.5 Editing scenarios . . . . . . . . . . . . . . . . . . . . . . . 383
6.11.6 Executing the scenarios . . . . . . . . . . . . . . . . . . . . 388
6.12 Backup, restore, version control . . . . . . . . . . . . . . . . . . . 389
6.12.1 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
6.12.2 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
6.12.3 Version control . . . . . . . . . . . . . . . . . . . . . . . . 391
6.13 Command line interface . . . . . . . . . . . . . . . . . . . . . . . 393
6.13.1 Starting TESSY in headless mode . . . . . . . . . . . . . . . 393
6.13.2 Invoking tessycmd.exe . . . . . . . . . . . . . . . . . . . . 394
6.13.3 Usage of tessycmd.exe . . . . . . . . . . . . . . . . . . . . 394
6.13.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 395
6.13.5 Example: DOS script . . . . . . . . . . . . . . . . . . . . . 396

TESSY 4.0 Manual 153

6 Working with TESSY

6.1 Menu Bar Entries: Setting up the basics

Figure 6.1: Menu bar of TESSY

The menu bar provides global operations such as project handling commands, editing
commands, window settings, TESSY preferences and the help contents.

6.1.1 File menu

File menu entry setting options

“Select Project” Opens the dialog “Select Project”. If you select another project,
TESSY closes the current project, restarts and opens the
selected project.

“New Project” Opens the dialog “Create Project”. Refer to section 3.1.1
Creating a project database.

“Import Project” Opens the windows explorer. Choose a project and click “Open”.

“Edit Project” Opens the dialog “Project Configuration”. Refer to section 3.1.1
Creating a project database.

“Close Project” Closes the current project. TESSY will restart and show the
dialog “Select Project”.

“Edit Environment” Opens the TEE, the Test Environment Editor. Refer to chapter
6.5 TEE: Configuring the test environment.

“Database Backup” Refer to chapter 6.12 Backup, restore, version control.

“Exit” Quits TESSY.

Table 6.1: File menu options

154 TESSY 4.0 Manual

 6.1 Menu Bar Entries: Setting up the basics

6.1.2 Edit menu

Here you will find common actions as “Delete” or “Undo”, “Redo” etc. You can use as
well the context menu. Refer to section 3.3 Using the context menu and shortcuts.

6.1.3 Window menu

Window menu setting options

“Show . . . ” Switch to the various perspectives or show additional views

within the current perspective to customize it to your needs.
You can as well use the graphical user interface. Refer to section
3.2 Understanding the graphical user interface.

“Reset Workbench” With a click you reset the positions of all perspectives and views
to the default setting.

Table 6.2: Window menu options

6.1.4 Windows > Preferences menu

Figure 6.2: Preferences menu of TESSY

TESSY 4.0 Manual 155

6 Working with TESSY

Within section “Preferences” of the Windows menu you find many options for setting basic
functions to your needs:

Preferences menu setting options

“Preferences” In this section you can setup an instrumentation for coverage

> “Coverage Settings” measurement that will be the default for all of your projects (see
figure 6.4).

You can still set up a different instrumentation for

every test collection, folder, module or test run. Re-
fer so section 6.2.3.4 Coverage tab within the Pro-
perties view.

TESSY includes various pre-defined coverage measurements for

common known safety standards. You can as well

• modify the existing selections (tick a box),

• choose the test type for the selection (unit or component

test),

• define your own (click on “Create”) coverage selections,

• import (click on “Import”) and export coverage

instrumentation settings as XML file.

To define a default instrumentation for your project, select from

the pull-down list on top.

“Preferences” Within this section you can

> “Dialog Settings”
• set the default directories for imports of test objects,
exports for test objects and modules and for adding
includes and source files,

• decide, which confirmation dialogs will be shown.

continue next page

156 TESSY 4.0 Manual

 6.1 Menu Bar Entries: Setting up the basics

Preferences menu setting options

“Preferences” TESSY supports the static analysis tools “Cppcheck” and

> “Static Analysis” “PC-Lint”.
To enable static analysis,

• go to “Path to executable” and select your cppcheck.exe

or lint-nt.exe. On the preference page you can also specify
the options passed to the analysis tool, and whether the
static analysis is to be run in the environment context of
a module (see figure 6.3).

• To perform the static analysis, right-click on a module

and select "Analyze Source" from the context menu. Any
issues that have been found will be printed on the console
and listed in the Problems view.

Please note that if you change the options on the preference

page such that the message output format is different from the
default setting used by TESSY, the Problems view may not be
able to correctly parse and display the output.

“Preferences” Within this section you can choose if selections and settings
> “Test Execution should be remembered, e.g. if you tick unter “Remember test
Settings” instrumentation settings” the option “Globally for all test
objects” the last used coverage selection will be used, see
section 6.2.2.7 Instrumentation settings.

“Preferences” Within this section you can personalize TESSY’s behaviour

> “Test Interface within the Interface view, such as
Settings”
• sorting order

• hide empty sections

• show available types for test objects

“Preferences” Within this section you can personalize TESSY’s behaviour

> “Test Project within the Test Project view, such as
Settings”
• sorting order

• showing the Overview perspective when starting

• showing the Problems view on error

continue next page

TESSY 4.0 Manual 157

6 Working with TESSY

Preferences menu setting options

“Preferences” Within this section you can

> “Test Report Options”
• change the output directory for the various TESSY reports

• change the filenames

• change the default Razorcat logo within the reports to

your own company logo (PNG, JPG or GIF files are
possible) (see figure 6.2)

• choose an output format (PDF, HTML or DOCX)

If you move the mouse over the entry, a tooltip will

give you further information of the options!

Table 6.3: Preferences menu options

The following preferences will be stored within backup files when saving the whole project
database as described within Backup, restore, version control:

• Coverage settings

• Dialog settings

• Test execution settings

• Test report options

158 TESSY 4.0 Manual

 6.1 Menu Bar Entries: Setting up the basics

Figure 6.3: Static Analysis in the Preferences menu

The static analysis settings are used for calling the respective static analyzer tool. You need
to enter the path to the binary and change the command line options to your needs.

Figure 6.4: Pre-defined coverage instrumentation settings

For a selection of the most applicable safety standards, there are pre-defined coverage set-
tings available according to the recommendations given within those standards. You can

TESSY 4.0 Manual 159

6 Working with TESSY

choose a coverage setting for the appropriate standard and level as default for all modules
of your project. When running tests with coverage instrumentation, the respective settings
will be applied automatically.

You can as well define your own coverage settings if the standard you are using is not
available within the list.

6.1.5 Help menu

Help menu setting options

“About TESSY” Shows information i.e. the TESSY verson.

“User Manual” Opens the TESSY User Manual.

“Documentation . . . ” Contains various documentation for compiler and targets and

frequently asked questions (PDF files).

“Create Support File” Creates a support file. Refer to section 7.1 Contacting the
TESSY support.

“Start Shell” Starts a bash shell that can be used to try out the command line
execution of TESSY. The PATH variable is already set to the
bin directory of the currently running TESSY installation, so
that you can run tessycmd immediately. Refer to section 6.13
Command line interface.

Table 6.5: Help menu options

160 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2 Overview perspective: Organizing the test

Important: If you have not created a project yet, do so as described in the

chapter “Basic handling” in section 3.1.1 Creating a project database!

Figure 6.5: Overview perspective

6.2.1 Structure of the Overview perspective

pane location function

(default)

Test Project view upper left To organize the project: Create test collections, modules
and test objects; execute the test, create reports and have
a fast overview on your project.

Properties view lower left To edit all properties, e.g. adding sources or including
paths to your modules.

continue next page

TESSY 4.0 Manual 161

 6 Working with TESSY

pane location function

(default)

Requirement lower left To select and link the requirements that you managed
Coverage view within the Requirement management perspective.

Test Items view upper right To create test cases and test steps manually.

Test Results view upper right To view the test results.

Evaluation upper right To view evaluation macro results if the usercode of the test
Macros view object contains any.

Console view lower right To display messages of sub processes invoked during test
execution, e.g. compiler calls.

Suspicious lower right To review changes of requirements, modules or test objects

Elements view that require updating the linked test cases.

Table 6.6: Structure of the Overview perspective

6.2.2 Test Project view

Test Project view

Figure 6.6: Test Project view within the Overview perspective

162 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.2.1 Icons of the view tool bar

icon action / shortcut / comment

Imports files (type depends on the selection).

Exports files.

Resets a module (deletes all contents of the module!).

Analyzes the C-source file(s) of the module.

Defines a batch test.

Executes the test (Ctrl + E).

Generates various test reports. The test details report for a test object will be
generated as default (Ctrl + R).

Inserts a new test collection.

Inserts a new folder (Shift + Ins), optional for organizing your test project.

Inserts a new module (Ins). Modules will contain the test objects available
within the C-source files to be tested, i.e. C functions.

Hides irrelevant test objects.

Table 6.7: Tool bar icons of the Test Project view

6.2.2.2 Status indicators

indicator status / meaning

Test collecion containing folder(s) (optional) and module(s).

Folder containing module(s) (optional).

Module containing the test object(s).

continue next page

TESSY 4.0 Manual 163

6 Working with TESSY

indicator status / meaning

Module containing a comment, a description or a specification.

Variant module that was created with the “Create Variant” option.

Some interface settings need manual inspection (e.g. undetermined array

sizes).

The test object was analyzed but has no test case.

The test object has test cases but no data.

At least one test case has any data.

At least one test case is ready to be executed.

The test object interface has changed. A reuse operation within IDA is requi-
red.

The C-source of the test object has changed. A new function has been added.

The test object has been removed. You still see the object, but there is no
operation possible. Only displayed when the test object contained any test
cases before the removal.

The test object is suspicious.

The test execution has been aborted for this test object.

The test object contains a comment, a description or a specification.

The test result of a test run is failed. This may be either due to a mismatch
of actual and expected results or if the coverage did not achieve the minimum
coverage.

Test results and coverage of the test run are both OK.

The coverage did not achieve the required minimum coverage. The red part
of the bar indicates the missing percentage of coverage, e.g. more red means
less achieved coverage.

continue next page

164 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

indicator status / meaning

The coverage achieved the minimum coverage, but the minimum coverage
was less than 100.

Table 6.8: Status indicators of the Test Project view

6.2.2.3 Creating tests

You need at least one test collection to organize your test, and within at least one module Creating the test
and one test object. Folders and further test collections are optional and just have the
purpose to organize your test project.

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

Þ Click on the icon (New Test Collection) on the tool bar of the view.

Þ Enter a name and click “OK”.

Þ Click on (New Folder), enter a name and click “OK”.

Þ Click on (New Module), enter a name and click “OK”.

6.2.2.4 Analyzing modules

Important: To analyze a module it is necessary to select an execution environ-

ment, add at least one C-source file and required include paths for header files
and add defines necessary for analyzation/compilation of the source file(s), see
section 6.2.3 Properties view. If you need to learn more about this workflow, have
a look at the Practical exercises.

TESSY 4.0 Manual 165

 6 Working with TESSY

Analyzing the To analyze a module (the C-source file),

C-source file
Þ in the tool bar click on (Analyze Module) to start the module analysis.

TESSY now analyzes the C-source file, this will take a few seconds.
After successful processing,

Þ click on the white arrow in front the module: .

TESSY will as well analyze the C-source file by just clicking on the white arrow
next to the module after adding the C-source file.

Now all functions which were defined in the C-source file are displayed as children of the
module above within the Test Project view (see figure 6.7).

Figure 6.7: The function of the C-source is displayed as child of the module.

When using the CLANG parser (which is the default since TESSY v4.0), opening older
modules created with TESSY v3.2 and before will show the following warning:

166 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.8: Warning when opening older modules with CLANG enabled

The following options are available in such a case:

• If you want to convert the module and start working with the CLANG mode,
select “OK” which will do all necessary conversion. Refer to the restrictions
that apply: Operating limits. Please create a backup of your project before
converting the modules.

• If you have a legacy project and just want to execute tests, select “Cancel”
and change the attribute “Enable CLANG” to false within your project con-
figuration using the TEE Adjusting enabled configurations. If you did this
successfully, there will be no more warning when opening the module.

When working with the CLANG mode there are several parser options which can all be set
in the TEE:

Parser option Description

Enable Create Default If set to true, the TESSY parser creates a default constructor if it
Constructors is missing.

Enable Create Function If set to true, external functions that are called are by default
Stubs marked to create stub code unless they are listed in attribute
“Function Stub Exclude List”.

Enable Create Method If set to true, undefined called methods are marked to create stub
Stubs code unless they are listed in attribute “Method Stub Exclude
List.”

continue next page

TESSY 4.0 Manual 167

6 Working with TESSY

Parser options Description

Enable Define Variables If set to true, external variables that are used are marked to be
defined unless they are listed in attribute “Variable Exclude List”.

Enable Exceptions If set to true, TESSY enables exceptions for the test object and
generates a try-catch block around it. Also the TIE displays an
artificial global variable called throws exception which can be set
to OUT in order to test an exception thrown be the test object.
By default the attribute is set to true.

Function Stub Exclude The comma separated list of functions is excluded from automatic
List stub creation.

Method Stub Exclude The comma separated list of methods is excluded from automatic
List stub creation.

Variable Exclude List The comma separated list of variables is excluded from being
automatically defined.

Table 6.13: CLANG parser options and descriptions

General information about editing the environment can be looked up in the section TEE:
Configuring the test environment.

Important: Setting changes of the parser options made in TEE will be effective
when analyzing a module. Some of the options only apply when initially analyzing
modules. In this case it is necessary to reset a module before starting the analysis
to see the effects of the latest changes.

For more information about the parser options and more attributes available within
the environment editor TEE please refer to the application note “Environment
Settings (TEE)” in TESSY (“Help” > “Documentation”).

6.2.2.5 Creating variant modules

Module testing of software variants often require very similar tests that only differ in small
parts. Therefore the comfortable reuse and adaption of existing tests reduces the testing

168 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

effort for each variant of the software.

TESSY provides a variant management for test modules so that basic tests within a base
test module can be inherited, altered or removed and additional tests can be added by sub
modules covering the test of each software variant.

A base module serves as parent for all variant sub modules. It contains the information
that will be shared with all variants. Any module can be used as base module (i.e. can be
the parent of sub modules). If the parent module has changed If you have i.e. created a
module with some test cases, you can create a variant:

Þ Create a new folder i.e. with the name “Variant 1”.

Þ Rightclick on the folder and select “New Variant Modules” from the context
menu (see figure 6.9).

Figure 6.9: Create Variant Modules

TESSY 4.0 Manual 169

6 Working with TESSY

Þ Choose the parent module and click on “OK” (see figure 6.10).

Þ The variant will be displayed within the Test Project view with the icon .

Figure 6.10: Selecting the parent module of the variant

Figure 6.11: Test Project view with a module and a variant module.

170 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

If the parent module has changed, TESSY will mark the children with an exclamation
mark. The mouseover states, that the module needs to be synchronized with its parent
(see figure 6.12).

Figure 6.12: The variant module needs to be synchronized with the parent.

To synchronize the module with the parent:

Þ Rightclick the module and select “Synchronize Module” from the context menu.

Figure 6.13: Synchronizing a module with the parent

TESSY 4.0 Manual 171

6 Working with TESSY

The Synchronize Module dialog is displayed. The parent and all child modules
will be shown and can be synchronized in one step.

Figure 6.14: Synchronize Module dialog

For the first synchronization or if a modules interface has changed, the IDA will be opened
to assign the parent modules interface to the child module interface. You will be asked if
the IDA perspective shall be opened:

Figure 6.15: Interface assignment needed

172 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

The assignments made within IDA will be saved for future synchronizations of the child
module(s). When invoking the “Synchronize Module” operation again (e.g. after changes
to the parent module), the last used assignments will be applied without showing the
“Synchronize Module” dialog.
If you want to force a new assignment of the parent module interface to the child module
interface, you can analyze the child module which will reset the interface assignments. A
subsequent module synchronization will then show the IDA again.

The following indicators display the status of the inherited test cases and test steps within
the Test Items view:

icon meaning

The small triangle indicates that the test case or test step is inherited.

The filled triangle indicates that the inherited data of the test case and test
step was overwritten.

The inherited test case or test step was deleted.

The test case or test step was added for this variant test object.

Table 6.18: Status indicators of inherited test cases or test steps

Important: Deleted test cases/steps are only faded out within the child module.
They can be made available again using “Restore Deleted” from the context menu.

Figure 6.16: Test cases and test steps that were inherited of a variant module

TESSY 4.0 Manual 173

6 Working with TESSY

6.2.2.6 Executing tests

After entering test data for a particular test object you are ready to execute the test.
During this process, TESSY will perform the following steps:

• Generate the test driver based on the interface information and user code
provided.

• Link the test driver to the test object to create an executable file.

• Run the test with the selected coverage instrumentation.

Generating the test driver

The test driver is necessary to call the function under test and will be gene-
rated automatically. Test driver and the function under test form a complete
(embedded) test application, including the startup code for it, and will use an
appropriate compiler for the particular embedded microcontroller architecture. If
the function under test uses external variables that are not defined, the test driver
generated by TESSY can define those variables.

Once the test driver has been compiled, it can be run as often as required.
You can select a subset of your test cases and run the test again by just selecting
the run option. Changes to test data and expected results might require building a
new test driver. TESSY will check this automatically and generate a new driver.

Stub functions

If the function under test itself calls other functions (subroutines), TESSY
can provide replacement functions (stubs) for the missing subroutines with the test
driver. TESSY features two types of stub functions:

• Stub functions for which you may provide the C source code for the
bodies of the stub functions.
• Stub functions for which TESSY is able to check if the expected value for
a parameter is passed into the stub function and for which TESSY is able to
provide any value specified by the user as return value of the stub function.

174 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

To execute a test: Executing the

test
Þ Click on the arrow next to the icon Start Test Execution in the tool bar
of the Test Project view.

Þ Click on “Edit Test Execution Settings”.

A progress dialog will be opened (see figure 6.17).

Þ Choose the desired options and click “Execute”.

A progress dialog will be shown while TESSY generates, compiles and links the
test driver and runs the test. This will take a few seconds.

Meaning of the Test Execution Settings:

Action Meaning

“Force Check Interface” An analysis of the interface is forced.

“Force Generate Driver” Usually TESSY recognises if the driver has to be

generated. In this case it can be forced.

With “Run” (checked) The test will be executed.

Without “Run” (unchecked) Only the test driver will be generated.

“Abort On Missing Stub Building the test driver application will be aborted with an
Code” error if there are non-void stub functions without any code
provided to return a value. You can uncheck this action to
ignore this error if you are sure that the return values of
your stub functions are not used. (For more information
please refer to Defining stubs for functions.)

Table 6.23: Test Execution Settings - Actions

TESSY 4.0 Manual 175

6 Working with TESSY

Option Meaning

“Create New Test Run” A new history in the module will be generated.

“Test Cases Separately” The download and execution process of the test driver will
be started separately for each test case. This provides an
initial state of memory (and variables) for each test case
and is useful if the test cases shall be executed
independently. The disadvantage of this approach is an
increased execution time. (Due to start/stop of debugger
and download of test driver.) It is recommended to set this
option for dedicated test objects only.

Table 6.24: Test Execution Settings - Options

Figure 6.17: Test Execution Settings

176 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.2.7 Instrumentation settings

Within the Test Execution Settings dialog you can select the various possible coverage
instrumentation for this test run (see figure 6.17):

Þ Select from the pull-down menu if the coverage shall be used for the test object
or the test object and the called functions.

Þ Untick the box “Use preselected Coverage”.

Þ Select the coverage instrumentation (more than one possible).

The coverage instrumentation is now used for this test run, even if you have
selected a different coverage instrumentation as default for your project (see
section 6.1.4 Windows > Preferences menu) or for the module or test object
within the Properties view (see section 6.2.3.4 Coverage tab).

“Use preselected Coverage”

If you tick the box “Use preselected Coverage”, coverage selection will be
applied according to the following rules:

• If a coverage selection is set in the Properties view (see section 6.2.3.4 Co-
verage tab), that selection will be used.

• If no coverage selection is set in the Properties view, but in the Test Exe-
cution Settings of the Windows > Preferences menu the option “Remember
instrumentation settings” is set, the last used selection will be used.

• If no coverage selection is set and the option “Remember instrumentation

settings” is not set, no instrumentation will be used.

For more information about the coverage measurements refer to the application
note “Coverage Measurement” in TESSY (“Help” > “Documentation”).

TESSY 4.0 Manual 177

 6 Working with TESSY

6.2.2.8 Viewing test results

Viewing test After a test run, the Test Project view gives an overview about the coverage, if selected:
results

Figure 6.18: Coverage displayed within the Test Project view

• The actual results will be compared with the expected values according to
the evaluation mode. The result will be either failed or passed.

• The last step of test execution is the generation of an XML result file. This
file contains all test data and the actual results. It will be used for reporting.

The results of every coverage measurement can be reviewed in the CV (Coverage Viewer)
See 6.9 CV:
Analyzing the as soon as the test was carried out. For details refer to section 6.9 CV: Analyzing the
coverage
coverage.

Please notice the following habits:

• A green tick will indicate that all actual values comply with the expected values with
respect to the evaluation modes and the coverage reached at least the minimum
coverage.
• A red cross will indicate that either some actual values yield failed results or the
coverage did not reach the minimum coverage.
• If the interface has changed, the test object will indicate changes with test readiness
states (see Status indicators).
• The time of the test run is stated within the Test Project view:

Important: The results of the coverage measurement are also part of the
test result for a test object, e.g. if all outputs yield the expected result but the
coverage was less than the minimum coverage, the test result will be failed.

178 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Warning: Using the option “Reset Module” from the context menu will delete
the module with all test results!

6.2.2.9 Hiding irrelevant test objects

In the Test Project View test objects that are not relevant for the project can be hidden
by setting a test object filter:

Þ Click on (Toggle Test Object Filter) in the tool bar.

The Filter Configuration dialog will open (see figure 6.19).

Figure 6.19: Filter Configuration Dialog

Þ Select the test objects you wish to hide in the dialog that is shown.

Þ Once a filter has been set, you can toggle it on and off by clicking on .

Þ To modify an existing test object filter, click on the arrow next to the button
and select the “Select Test Object Filter” command.

TESSY 4.0 Manual 179

6 Working with TESSY

Figure 6.20: A filter has been set but is currently disabled (filtered test objects appear
faded).

Figure 6.21: The Filter is enabled, the affected test objects are hidden.

Figure 6.22: Clicking on the arrow opens the “Select Test Object Filter” dialog.

180 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Important: The filter setting will be saved for each filtered test object within
the test database. When saving and restoring modules as TMB files, these filter
settings will also be persisted and restored.

6.2.2.10 Search filter function

Figure 6.23: Search filter function of the test project view

The search filter helps to find and select elements by their name. Typing into the search
field will result in the Test Project View being updated after a small delay such that
only matching elements and their ancestors and descendants are displayed. Elements are
automatically expanded to be visible, with the exception of modules that need to be
analyzed.

Figure 6.24: Searching for “foo”

TESSY 4.0 Manual 181

6 Working with TESSY

6.2.2.11 Creating reports

Important: All reports are generated as PDF files. You need the Adobe
Reader to open the files. Download and install the Adobe Reader from
http://get.adobe.com/reader/.

The following reports are available in TESSY:

Test Details Report Contains information about the test cases, their
properties and values, linked requirements and
if test cases failed or were successful.

The Test Details report is based on the XML

result file which is created after every test run
and stored within the latest test run.
A test report can be generated as soon as
TESSY has finished running a test.

Test Overview Report

Contains information about the test objects and

the test case results in grafical form (pie chart).

The Test Overview Report summarizes the

results of a selected set of test objects. The
report can be generated based on already
executed test objects or right after the
execution of the selected test objects.

continue next page

182 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Planning Coverage Report

Contains information about the requirements
linked to test cases and the planned validation.

Planning coverage summarizes the achieved

coverage of requirements by test cases. Each
link of a test case to a requirement will be
counted. This report provides information
about the planning progress of the test project,
since it will show all requirements that have not
yet been planned to be tested by at least one
test case.

Execution Coverage Report Contains information about the validation of

requirements after test run.

Execution coverage summarizes the achieved

coverage of requirements based on executed
tests. The results of test runs (i.e. the result of
each test case) will be propagated to the list of
requirements by creating requirement
evaluations for all linked requirements, if any
link was set. This report provides an overview
about the result status of the test project since
it will show all requirements for which the
linked test cases are failed for any reason.

Table 6.31: Reports available within TESSY

All reports are created as PDF documents based on XML data files. These XML
data files can also be used for generating reports or further processing if desired.

To create a report within TESSY: Creating reports

Þ Click in the Test Project view (i.e. within the Overview perspective) on the
arrow next to the Generate Report icon .

Þ Select the report you wish to create (see figure 6.25).

TESSY creates the report within the new folder. This will take a few seconds.

TESSY 4.0 Manual 183

 6 Working with TESSY

When finished, TESSY will open the file automatically.

Important: The first time you create a report, the “Edit Settings” dialog will
be opened automatically. These settings are memorized and used for the following
reports.

Figure 6.25: Creating a report

Change settings To change settings:

of a report
Þ Click on the arrow next to the Generate Report icon .

Þ Select “Edit [report] Settings. . . ”.

the settings dialog for the selected report will be opened.

You can as well change basic settings, e.g. output directories, filenames and the
logo on the reports. Refer to section 6.1.4 Windows > Preferences menu.

Optional settings of the different reports and their default values:

184 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

report settings default

Test Details Report folder selection C:\tessy\report

show usercode yes
show test step details yes
hide results (show test data only) no

Test Overview folder selection C:\tessy\report

Report show test object result pie chart yes
show test object list yes
show test case results bar chart yes
show coverage charts yes

Planning Coverage folder selection C:\tessy\report

Report show overview pie chart yes
show requirements list yes
show test item list yes
selection of requirement document selected, if only one available
selection of test means no

Execution Coverage folder selection C:\tessy\report

Report show overview pie chart yes
show requirements list yes
show test item list yes
selection of requirement document selected, if only one available
selection of test means no

Table 6.34: Available settings of the reports

To clear a report output directory: Clear Report

Output directory
Þ Within the Windows Explorer go to the report output directory. The directory
is displayed within the Test Project view unter “Edit [...] Report Settings”
.

Þ Make sure the reports or the directory is not needed anymore!

Þ Delete the reports or the directory.

TESSY 4.0 Manual 185

 6 Working with TESSY

6.2.2.12 Batch test operations

Batch Test TESSY provides a batch test feature with various operations for test execution and re-
porting. You can define which operations shall be performed and which settings shall be
used. This setup can be saved into batch script (TBS) files for test automation using the
command line interface of TESSY (see chapter 6.13 Command line interface).

Open the batch operation settings:

Þ In the Test Project view right click a project, a module or a test object.

Þ Select “Define Batch Operation. . . ” from the context menu (see figure 6.26).

The window “Define Batch Operation” will be opened.

Figure 6.26: Context menu “Define Batch Operation”

186 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.27: Defining the batch operation

To select the test objects for the batch test:

Þ Under “Test Objects” choose the project or modules or test objects for the
batch test. Click “Select All” to select all at once (see figure 6.28).

Figure 6.28: Selecting all text objects

TESSY 4.0 Manual 187

6 Working with TESSY

The right side of the window is context sensitive:

Þ Switch to the setting by either marking the operation on the left side or use
the tabs on the upper right side (see figure 6.29). The optional settings for
this operation will then be shown on the right side of the window.

Figure 6.29: Editing the settings of each batch operation

You can create a TBS file for command line execution by saving the batch test settings:

Þ In the batch operation settings window click on (Save batch file as. . . ).

Þ Choose the type of the file and click “Save” (see figure 6.30).

188 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.30: Saving the settings of a batch operation as TBS file

6.2.2.13 Importing and exporting

The Test Project view provides the import and export of test data and module backup files
(*.TMB):

Þ Select a folder, module or test object.

Þ In the toolbar click on to import or to export the data.

The kind of import/export depends on the selection:

selection type of file

folder import: *.TMB files

module export: *.TMB file

test object import and export: test data

TESSY 4.0 Manual 189

6 Working with TESSY

When importing test data for individual test objects there are following options (see figure
6.31):

• “Update passing directions”: If you tick the box, the passing directions of
all interface variables will be set according to the passing directions specified
within the import file. All other interface variables will be set to IRRE-
LEVANT. The test object will be ready to execute when using this option
because all variable with passing directions IN, OUT or INOUT will be filled
with values.

• “Overwrite/append test cases”: Either delete existing test cases before im-
porting or append any imported test cases at the end of the test case list.

Figure 6.31: Import settings of data import

When exporting data there are following options (see figure 6.32):

• The conversion of the export settings is only applicable, if ASAP conversion

is enabled! Please refer to table “General tab of Properties view” in section
General tab.

• Input/Expected versus Input/Actual: Either export the expected or the actual

result values. The latter is only available if the test has been executed and
actual results are present.

190 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.32: Export settings of data export

6.2.3 Properties view

Properties view

Figure 6.33: Properties view

TESSY 4.0 Manual 191

6 Working with TESSY

The Properties view is divided into several tabs on the left and provides various settings
which are explained in the following:

6.2.3.1 General tab

The General tab (see figure 6.33) is used to determine the test environment. Following
options are available:

Option Function

Test The path has been specified during database creation and is not adjustable
Directory here.

Name Name of the element, e.g. test collection or module.

Environment Specifies your target compiler (debugger/emulator/simulator) combination

to be used for test execution. To enable the test environment see chapter
6.5 TEE: Configuring the test environment and section 6.5.7.1 Enabling
configurations.
The GNU toolset is already available by default.

Kind of Test Unit: Enables the unit test of TESSY.

Component: Enables the component test of TESSY.

Features “Enable ASAP”: TESSY provides a close integration to the ASAP

standard, allowing the usage of ASAP conversion rules for physical to
integer conversion of test data. If ASAP is ticked, you will find additional
attributes within the Attributes tab in which you have to specify your
ASAP file.

For more information refer to our application notes in the

Help menu in the menu bar (“Help” > “Documentation” >
“Using ASAP Information”).

Table 6.44: General tab of the Properties view

192 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.3.2 Sources tab

Figure 6.34: The Compiler pane in the Sources tab of the Properties view

In the upper pane of the Sources tab the source files to be tested are added. All exported Adding the
functions will be displayed if the module is opened. Some additional compiler options can C-source file
be specified on module level by selecting the module entry, other options can be specified
for each source file in the list.

To add a C-source file:

Þ Click on (Add Source).

Þ Select your C-source file.

Þ Click “Open”. The C-source file will be added.

To remove a C-source file:

Þ Select a source file and “Remove File” from the context menu.

To replace a C-source file:

Þ Select a source file and “Replace File” from the context menu.

Þ From the next dialog, select another source file.

TESSY 4.0 Manual 193

6 Working with TESSY

The lower Compiler pane of the Sources tab displays information about the item
selected from the upper Sources pane. Some of the displayed options (e.g. Includes) in the
lower Compiler pane can be specified in the Test Environment Editor and will be inherited
from there.

What kind of information is visible depends which tab is selected:

Module options apply to all source files unless otherwise specified on file level.
File options apply to one selected source file and will overwrite options that are
specified on module level.

Tab Optional function within the Compiler pane

Includes Add an include path of the headers which are included within the
source file.

Defines Define a macro for the preprocessor:

Þ Click on and enter the name of the define without the normally
used option of your target compiler, e.g. -D. TESSY will use the
appropriate option automatically.

Macros have to be separated by a comma or semicolon.

Options Specify additional directives for your target compiler for your needs. Note
that macros for the preprocessor and include paths have to be specified
within the Defines tab respectively within the Includes tab.

All compiler options added here will be used for the compilation of the
source file when building the test driver application.

continue next page

194 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Tab Optional function within the Compiler pane

Settings Depending on the selected item in the Sources pane the following features
can be enabled (box is checked) or disabled (box is unchecked) in the
Compiler pane:

• Static Functions: When enabled, static functions can be tested and

are added in the test object list of the module. The source code will
be instrumented.

• Inline Functions: When enabled, Inline Functions can be tested and

are added in the test object list of the module.

• Static Local Variables: When enabled, access to static local

variables may be used as normal input or output variables within
TESSY. The source code will be instrumented.

• Hide Functions: When enabled, all functions of the selected source

file are removed in the test object list of the module. This option is
useful for additional C-source files needed for testing (e.g.
implementation of stub functions for called functions), since they
are not relevant for testing and reporting.

• Enable User Includes: When enabled, all included header files of the
source file(s) are included in the user code.

Table 6.48: Optional functions of the Sources tab of the Properties view

Figure 6.35: The Setting tab of the Properties view with module selected

TESSY 4.0 Manual 195

 6 Working with TESSY

6.2.3.3 Linker tab

Figure 6.36: The Linker Options tab of the Properties view

Any linker options like object files or libraries can be added here. You can use predefined
variables like $(PROJECTROOT) or $(SOURCEROOT) as described in section Creating
databases and working with the file system. It is recommended to add such linker options
using the environment editor TEE: Configuring the test environment.

6.2.3.4 Coverage tab

Figure 6.37: The Coverage tab of the Properties view

While you have probably chosen an instrumentation for coverage measurements as default
for your whole project as described within section 6.1.4 Windows > Preferences menu,
See 6.1.4
Windows > within the Properties view you can enable a different coverage measurement on folder or
Preferences menu
test collection level or for a single module:

Þ In the Test Project view select your module, for which you want to choose the
coverage measurement.

196 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Þ In the Properties view select your coverage selection in the pull-down menu
(see figure 6.38).

Figure 6.38: Selection of the coverage measurement in the pull-down menu

The pre-selected coverage instrumentations according to the selected safety standard level
will be displayed.
TESSY supports the following instrumentations:

• Statement Coverage (C0)

• Branch Coverage (C1)

• Decision Coverage (DC)

• Modified Condition / Decision Coverage (MC/DC)

• Multiple Condition Coverage (MCC)

• Entry Point Coverage (EPC)

• Function Coverage (FC)

TESSY 4.0 Manual 197

 6 Working with TESSY

To edit the coverage selection of a measurement:

Þ Click on the button “Preferences”.

Þ Edit the instrumentation to your needs by ticking or unticking the boxes or

creating a new coverage selection according to your required safety standard
and level with a click on “Create”.

Figure 6.39: Defining coverage measurements

See 6.2.2.6 You can choose a different instrumentation for each test run. The options will be shown
Executing tests
within the Execute Test dialog (refer to section 6.2.2.6 Executing tests).

See 6.9 CV: To analyze the coverage refer to chapter 6.9 CV: Analyzing the coverage. For more
Analyzing the
coverage information about coverage measurements and usage of coverage analysis refer to the
application note “Coverage Measurement” in TESSY (“Help” > “Documentation”).

198 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.3.5 Attributes tab

Figure 6.40: The Attributes tab of the Properties view

The Attributes tab specifies settings required by the compiler or the target environment of
the module. Most attributes were preset and inherited from the Test Environment Editor
(TEE).

You can change the default values or add new attributes to the Attributes pane: Insert attributes

Changes are carried out only locally and do not influence other modules.

To create a new attribute:

Þ Click on (New Attribute).

The Edit Attribute Properties dialog will ne opened.

Þ Enter an attribute name and select an appropriate type, e.g. String. Available
types are String, Boolean, Integer, Real, File, Folder and Url.

Þ Select appropriate flags, depending on the type selected.

TESSY 4.0 Manual 199

6 Working with TESSY

Figure 6.41: Creating a new attribute

To edit an existing attribute:

Þ Click on (Edit Attribute).

The Edit Attribute Properties dialog will ne opened.

You can remove user defined attributes. You cannot remove default attributes, only reset
the value to its default state, if changed before.

To remove an attribute respectively reset a default attribute:

Þ Click on .

6.2.3.6 Specification / Description / Comment tabs

Those tabs provide editable textboxes to be used for specifications, descriptions and com-
ments by the tester.

200 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.4 Requirements Coverage view

Figure 6.42: Requirements Coverage view

Within the Requirements Coverage view you can link the requirements with your test cases.
We will describe this view in section 6.4 Requirement management > 6.4.16 Requirements
Coverage view.

6.2.5 Test Items view

In the Test Items view you get an overview about your test cases and test steps, and you
can as well create test cases and test steps manually without using the Classification Tree Test Items view
Editor (CTE, see section 6.7). This is useful for simple test objects with a few test cases
that can be documented in a few words manually.

Figure 6.43: Test Items view

TESSY 4.0 Manual 201

6 Working with TESSY

6.2.5.1 Icons of the view tool bar

icon action / shortcut / comment

Displays expected results.

Displays evaluation macros results.

Displays call trace results.

Executes selected test cases.

Adds new test case.

Generates test steps automatically i.e. within a range.

Adds new test step.

Renumbers the test cases and test steps.

Expands all test cases.

Collapses all test cases.

Table 6.55: Tool bar icons of the Test Items view

6.2.5.2 Status indicators

indicator status / meaning

The test case has no data.

The test case contains any data.

At least one test step of the test case is ready to be executed.

Test case passed: The actual results did match the expected results.

continue next page

202 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

indicator status / meaning

Test case failed: The actual result of at least one test step did not match the
expected results.

Test case variant that was inherited from a parent module..

New test step within a variant module..

Inherited and overwritten test case of a variant module..

Inherited and deleted test case of a variant module..

Test Case Generator: This test case generates test steps automatically, i.e. if
you enter a range. It does not contain any data yet.

Test Case Generator with data: This test case has automatically generated
test steps.

Inherited and overwritten generator test case.

The test step has no data.

The test step contains any data.

The test step is ready to be executed.

Test step passed: The actual result did match the expected results.

Test step failed: The actual result did not match the expected results.

Test step variant that was inherited from a parent module.

New test step within a variant module.

Inherited and overwritten test step of a variant module.

Inherited and deleted test step of a variant module.

Inherited and overwritten generator test step.

continue next page

TESSY 4.0 Manual 203

 6 Working with TESSY

indicator status / meaning

The test case has been created by the CTE and therefore can be changed only
within CTE. The test case does not contain any data.

The test case has been created by the CTE and therefore can be changed only
within CTE. The test case does contain some data.

The test case has been created by the CTE and therefore can be changed only
within CTE. At least one test step is ready to be executed.

The test step has been created by the CTE and therefore can be changed only
within CTE. It does not contain any data.

The test step has been created by the CTE and therefore can be changed only
within CTE. It does contain some data.

The test case has been created by the CTE and therefore can be changed only
within CTE. At least one test step is ready to be executed.

Table 6.56: Status indicators of the Test Items view

6.2.5.3 Creating test cases and test steps

Creating test To create test cases and test steps:

cases
Þ Switch to the Test Items view.

Þ Click on (New Test Case).

The first test case is created and a test step is automatically added.

Þ Add further test steps with a click on (New Test Step).

204 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.44: First test case with one test step

Please notice the following habits of this view:

• The first number is the number of the test case, the number in brackets shows the
quantity of the test steps included.
• Test case numbers will be counted continuously: If you delete test cases, new test
cases will get a new number and existing test cases will not be renumbered.
• If you cannot click on “New Test Case” oder “New Test Step” because the icons
are inactive, you might be in the wrong selection: Select the test object within
the Test Project view, then select the Test Items view.
• If you double click a test case, the TDE will be openened to enter test data. Make
sure to adjust or review the passing directions first in the TIE.

Every test step contains a complete set of test data. For instance, the mechanism of test
steps can be used to achieve an initialization of the test object before executing the test
step that checks the actual test condition of the current test case.

6.2.5.4 Creating test steps automatically

You can generate test steps automatically, i.e. with ranges of input values:

Þ Click on the arrow next to the “New Test Case” icon .

Þ Select “New Generator Test Case” (see figure 6.45).

TESSY 4.0 Manual 205

6 Working with TESSY

Figure 6.45: Selecting the test case generator

A new test case will be created. The star symbol indicates, that this test case is generated
and you cannot add any test steps, because these will be generated automatically (see
figure 6.46).

Figure 6.46: A new test case generator is created

To fill the data and generate the test steps, you will use the Test Data view within the
TDE perspective:

Þ Follow the description of section 6.8.7.8 Generating test steps automatically.

After generating the test steps, the icon of the test case within the Test Items view will
change to yellow as well as test steps (see figure 6.47).

206 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.47: The test steps were generated and are ready to be executed

The test steps are read only! You can change the type of the test case and test steps to
“normal”. That way you can edit the test steps as usual.
To change the status to normal,

Þ Rightclick the test case and select “Change Test Case Type to Normal” (see
figure 6.48).

Figure 6.48: Selecting “Change Test Case Type to Normal”

TESSY 4.0 Manual 207

 6 Working with TESSY

Changing test The test case and test steps are changed to type “normal” but will indicate originally being
case to type generated with a status (see figure 6.49).
normal

Figure 6.49: The test case and test steps originally being generated

You can reverse the action with a righclick and choose “Change Test Case Type to Gene-
rator” from the context menu.

6.2.5.5 Test cases and steps created within the CTE

If test cases and test steps were assigned within CTE, the icons of test cases and test
steps within the Test Items view are displayed with a CTE symbol to indicate that you can
change those test cases only within CTE (see figure 6.50).

Figure 6.50: Test cases created by CTE

208 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.5.6 Test cases and steps inherited from a variant module

If test cases and test steps were inherited of a variant module as described in chapter
6.2.2.5 Creating variant modules, you can add, delete and overwrite the test steps and
data. The icons will indicate each status:

Figure 6.51: Test cases and test steps that were inherited of a variant module

Important: Deleted test cases/steps are only faded out within the child module.
They can be made available again using “Restore Deleted” from the context menu.

6.2.5.7 Renumbering test cases

After deleting test cases or test steps, you can renumber the existing test cases and steps:

Þ Click on (Renumber Test Cases).

A notice will appear that all test cases will be renumbered (see figure 6.52).

Þ Click “OK”.

TESSY 4.0 Manual 209

6 Working with TESSY

Figure 6.52: All test cases will be renumbered

6.2.6 Test Results view

Figure 6.53: Test Results view

After a test run the Test Results view will display the coverage measurement results and
the results of expected outputs, evaluation macros and call traces, if applicable.

Important: The view is context sensitive: If the Test Results view is empty,
make sure a test run is selected within the Test Project view!

210 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.7 Evaluation Macros view

Figure 6.54: Evaluation Macros view

This view lists the detailed results of the evaluation macros if the usercode of the test
object contains any evaluation macros, see 6.8.10.3 Using evaluation macros. The results
are displayed wherever they occur within the usercode, e.g. within stub functions or test
step epilogs. You can select the filter items on the left side to show only the evaluation
macro results for e.g. the first test step. The list of results on the right will be filtered
accordingly.

6.2.8 Console view

Figure 6.55: Console view

The Console view displays messages of sub processes invoked during the compilation and
execution process of the test driver application. It provides a quick overview about any
error messages.

TESSY 4.0 Manual 211

6 Working with TESSY

6.2.8.1 Icons of the view tool bar

icon action / shortcut / comment

Clears the Console view.

Locks the scrolling function.

Opens the console.

Table 6.64: Tool bar icons of the Console view

6.2.8.2 Handling

You can enable the console view to be shown whenever an error occurs during C-source
analysis or test driver compilation:

Þ In the menu bar blick on “Window”.

Þ Open the “Preferences”.

Þ Click on “Test Execution Settings” and check the setting “Show console on
error” (see figure 6.56.

Figure 6.56: Preference “Show console on error”

212 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

6.2.9 Suspicious Elements view

Since the view refers to changes of requirements, this issue is discussed in section 6.4.8
Suspicious Elements view.

6.2.10 Variants view

Figure 6.57: Variants View

The variants view supports the variant management in TESSY: You can create a variant
tree according to the software variant structure you are going to test. These testing variants
are useful for tagging TESSY modules to certain software variants which facilitates filtering
and creation of variant TESSY modules.

Tip: You do not need to create a variant tree in order to create variant modules.
Any module can be a parent module of another. The variant tree just helps to
keep the module variant tree in sync with the actual inheritance structure of the
software variants being tested.

A module can be assigned to a variant using the properties section “Variants”:

Þ Select the module

Þ Switch to the “Variants” tab and select the respective variant

TESSY 4.0 Manual 213

6 Working with TESSY

Figure 6.58: Assign a variant to a module

Let’s assume you have the following structure of base tests that shall be cloned as variant
modules in order to test all software variants:

Figure 6.59: Example test collection with base modules

To create variant modules for each of the base modules do the following:

Þ Create a new test collection for each variant and choose (New Variant
Modules...) from the context menu.

Þ Within the “Create Variant Modules” dialog select all base modules that shall
be cloned as variant modules.

214 TESSY 4.0 Manual

 6.2 Overview perspective: Organizing the test

Figure 6.60: Create variant modules dialog: Filtering and selection

Þ You can filter the modules being displayed by seleting the desired variant. Only
potential parent modules according to the variant hierarchy will be displayed.

Figure 6.61: Test Project view with new variant modules

TESSY 4.0 Manual 215

6 Working with TESSY

The new variant modules will be created within the selected test collection (including the
folder hierarchy if the option “Take over folder hierarchy” was checked). The properties of
a variant module shows the assigned variant and the parent module which can be edited
using the edit button (see figure 6.62).

Figure 6.62: Properties view variants tab for editing the parent module

Important: All test data of a variant module will be deleted if you select
another parent module.

216 TESSY 4.0 Manual

 6.3 C/C++: Editing the C-source

6.3 C/C++: Editing the C-source

Important: The C/C++ perspective is not displayed by default! Open the

perspective as described below!

Figure 6.63: Perspective C/C++

Within the C/C++ perspective you can edit your C-source file.

6.3.1 Opening the C/C++ perspective

Þ Within the Test Project view right click the desired test object or module.

Þ Select “Edit Source” (see figure 6.64).

TESSY 4.0 Manual 217

6 Working with TESSY

Figure 6.64: Opening the C/C++ perspective

6.3.2 Structure of the C/C++ perspective

pane location function

(default)

Project Explorer left To view the includes and the functions of the C-source
view file.

Editor view upper middle To edit the C-cource file.

Outline view right To overview all functions of the C-source file.

Console view lower middle Same view as within the Overview perspective.

Properties view lower middle Same view as within the Overview perspective.

in
Table 6.70: Structure of the C/C++ perspective

Important: Most party of this view are usual Eclipse functions! Please refer
to the Eclipse documentation: http://help.eclipse.org/

218 TESSY 4.0 Manual

 6.3 C/C++: Editing the C-source

6.3.3 Editor view

Editor view

Figure 6.65: Editor view within the C/C++ perspective

Important: The Editor view is not a normal view in Eclipse sense, therefore
you cannot move the view as other views of the perspectives!

6.3.3.1 Editing the C-source file

Þ Open the C/C++ perspective with a right click on the desired test object or
module within the Test Project viewk.

Þ Select “Edit Source” (see figure 6.66).

TESSY 4.0 Manual 219

6 Working with TESSY

Figure 6.66: Opening the C/C++ perspective

Þ Edit the C-source file.

The view is context sensitive: If you choose a function within the Outline view,
the function will be highlighted within the Editor view!

6.3.4 Project Explorer view

Figure 6.67: Project Explorer view within the C/C++ perspective

220 TESSY 4.0 Manual

 6.3 C/C++: Editing the C-source

Within this view you can browse easily between the includes and have an overview of all
functions of the C-source file.
The view is context sensitive: If you choose a function within the Project Explorer view,
the function will be highlighted within the Editor view.

6.3.5 Outline view

The Outline view displays all functions of the C-source. Outline view

The view is context sensitive: If you choose a function within the Outline view, the function
will be highlighted within the Editor view (see figure 6.68).

Figure 6.68: Outline view within the C/C++ perspective

6.3.5.1 Icons of the view tool bar

icon action / shortcut / comment

Sorts the functions in alphabetica order.

Hides fields.

Hides static members.

Hides non-public members.

continue next page

TESSY 4.0 Manual 221

 6 Working with TESSY

icon action / shortcut / comment

Hides all inactive elements.

Table 6.73: Tool bar icons of the Outline view

6.3.6 Properties view

The Properties view displays all the properties which you organized within the Overview
6.2.3 perspective. Most operations are possible.
Properties view
For changing a source switch to the Properties view within the Overview perspective.

6.3.7 Console view

The Console view displays messages of sub processes invoked during the compilation and
execution process of the test driver application. It provides a quick overview about any
error messages. Same view as within the Overview perspective, see section 6.2.8 Console
view.

222 TESSY 4.0 Manual

 6.4 Requirement management

6.4 Requirement management

The basis for all testing activities should be a precise functional specification of the system
under test. All testing activities should be caused by requirements described within the
functional specification and each change of the requirements need to be tracked in order
to adjust the tests if necessary. That is the reason why TESSY incorporates a requirement
management solution that provides a basic environment for requirements engineering with
the following features:

• Exporting and importing requirements

• Creating new requirements

• Comparing requirement versions

• Linking test cases with requirements

• Automatic versioning of requirement changes

• Adding images to requirements

• Marking different versions of requirements as semantically equivalent

There is a plugin available for the integration of Polarion. For more informa-
tion please refer to the application note “Polarion Export” in TESSY (“Help” >
“Documentation”)

You will use different views and perspectives for your requirement management:
6.4.1 Structure
1. To create and import requirements, track changes and versionize your requirements of the Requirement
Management
use the Requirement Management perspective. perspective

6.4.16
2. To link requirements with test cases use the Link Matrix view or the Requirements Requirements
Coverage view
Coverage view of the Overview perspective.

TESSY 4.0 Manual 223

6 Working with TESSY

6.4.1 Structure of the Requirement Management perspective

Figure 6.69: Requirement Management perspective

pane location function

(default)

RQMT Explorer view left To create requirements.

Requirements List view upper center To view imported requirements as list for a selected
document or folder.

Requirement Editor view upper center To organize the requirements, e.g. adding infor-
mation as text or images, opens only after double
clicking on a requirement in the RQMT Explorer view.

Test Means view lower center To list the available test means, up to unit test and
component test.

Validation Matrix view / upper center To assign requirements to test means, only visible
VxV Matrix view when there is a validation matrix and after double
clicking on it.

Link Matrix view lower center To link requirements with modules, test objects, test
cases and other requirements.

Attached File view lower center To attach files to requirements.

Attributes view lower center To edit a list of attributes for a requirement.

continue next page

224 TESSY 4.0 Manual

 6.4 Requirement management

pane location function

(default)

Suspicious Elements view lower center To have a quick look over all suspicious (modified)
elements.

History view right To display the version history of the selected require-
ment or document.

Related Elements view right To display linked elements for a selected requirement
and compare these versions.

Problems view right

Document Preview right To edit the HTML contents of the requirements, only
visible after double clicking the respective require-
ment.

Requirements Coverage Overview To select and link the requirements.

view perspective!

Table 6.75: Structure of the Requirement Management perspective

Important: To gather all information about managing requirements within

this chapter, we will describe the Requirement Coverage view in this chapter,
although the workflow makes it reasonable to place this view within the Overview
perspective.

6.4.2 RQMT Explorer view

Figure 6.70: RQMT Explorer view

TESSY 4.0 Manual 225

 6 Working with TESSY

RQMT Explorer The RQMT Explorer view displays an overall view of all requirements of a requirement
view document. If you double click a requirement, the requirement editor will open to display
all information of the specific requirement (see figure 6.71).

Figure 6.71: Double clicking on a requirement opens the requirement editor

6.4.2.1 Icons of the view tool bar

icon action / shortcut / comment

Creates a new document.

Creates a new chapter.

Creates a new requirement.

Creates a new text section.

Creates a new validation and verification matrix.

Locks the marked item.

For editing the document hierarchy.

Generates a document report.

Deletes the marked item.

Syncs selection with editor.

continue next page

226 TESSY 4.0 Manual

 6.4 Requirement management

icon action / shortcut / comment

Adds filter.

Table 6.76: Tool bar icons of the RQMT Explorer view

Please note that with a rightclick on an element usually a context menu opens. It
contains the same buttons as shown in table 6.76. Depending on the circumstances
there might be more options available.

6.4.2.2 Status indicators

indicator status / meaning

The requirement document is locked.

Table 6.77: Status indicators of the RQMT Explorer view

6.4.2.3 Creating requirements and organizing a document structure

To create requirements: Creating

requirements
Þ In the RQMT Explorer view tool bar click on (New Document).

Þ Then click on (New Requirement (Insert)) to create a requirement.

The RQMT Explorer view also offers the option to organize the document structure. You
can adapt it to your needs and therefore gain a better overview over sometimes numerous
elements. This includes the opportunity to add chapters and text elements to documents
as well as text elements to chapters (see figure 6.72).

To create new elements of all kind in the document structure use the RQMT Explorer tool
bar (see table 6.76) or the context menu after a rightclick on the respective element. By
default new elements are placed at the end of the document or chapter column and new
documents appear on document level. It is possible to drag chapters, test elements and
requirements into the desired position, even into other documents.

TESSY 4.0 Manual 227

6 Working with TESSY

Figure 6.72: Example for the document structure within the RQMT Explorer view

6.4.2.4 Importing requirements

In the following you find a brief overview about importing requirements. For
more detailed information please refer to the application note “Importing Exporting
Requirements” in TESSY (“Help” > “Documentation”)

Þ Right click a document or right click within the blank RQMT Explorer view and
select “Import” from the context menu (see figure 6.73). When no document
is selected, the import will create a new document.

228 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.73: Importing requirements

Þ The Import dialog opens (see figure 6.74).

Figure 6.74: Import dialog

Þ Click on “. . . ” and select the file with the requirements.

TESSY 4.0 Manual 229

 6 Working with TESSY

Þ Select the File Content Type. For the possible types see table below.

TESSY will pre-select the content type according to the contents of

the currently selected file. If the file cannot be imported, this field
will be empty. You can select a content type that you think the
file contains and start importing. TESSY will then show the errors
within the file.

Þ Select the Target Document and click “OK”.

If no existing document has been selected, the new requirements will

be imported into a new document. You can also select any existing
document within the list to update this document. Whether you will
see existing requirement documents or validation matrices depends
on the file content type.

Formats of You can import following formats of requirement sources:

requirement
sources Format Comment

*.txt Simple ASCII format were each line is recognized as a requirement. This is
the very basic format that allows importing all sorts of text as requirements.

*.reqif Requirements interchange format (ReqIF), used for import/export of requi-

rements from third party requirement management tools (e.g. DOORS and
Polarion). For further information see http://www.omg.org/spec/ReqIF

*.csv, *.tsv Comma or tab separated ASCII text with a headline indicating the column
names. This format allows specifying requirement id, version and all other
available requirement properties.

*.xml TESSY specific XML format which provides specifying the chapter structure of
a requirement document. All available requirement properties may be specified
within this format. It is the recommended exchange format when importing
requirements from any other requirement management systems.

Table 6.82: Possible formats of requirement sources

The newly imported requirement document will be displayed in the RQMT Explorer view
(see figure 6.75).

230 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.75: The new requirement document

The asterisk (*) indicates that the requirement is new and not commited yet. A mouseover New imported
shows a tooltip (see figure 6.76). requirement

Important: New imported requirements need to be committed (see section

6.4.2.5 Committing requirements).

Figure 6.76: The asterix and a mouseover shows the status “new”.

6.4.2.5 Committing requirements

The requirements document needs to be checked-in as initial revision: Committing

requirements
Þ Select the document within the RQMT Explorer view and click on (Commit
Changes) in the global tool bar.

You can commit all changes or changes of selected elements (see figure 6.77).

TESSY 4.0 Manual 231

6 Working with TESSY

Figure 6.77: Committing options

Þ Enter a comment and click “OK” (see figure 6.78).

Figure 6.78: Comment for the initial revision of the commit

An initial revision of the requirement document will be created.

By ticking the box “Increment major version” a major version with a new
version number will be created.

If requirements have been changed, every commit creates a new requirement ver-
sion. The reason for this is traceability, only with these different requirement
versions changes in the requirements can be traced.

232 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.79: After the commit

You can also discard the changes you made by clicking on (Discard Changes)
in the global tool bar. This will restore the last checked in status. With a click
on the little arrow next to the icon you can set whether you want to discard all
changes or changes of selected elements only.

6.4.2.6 Renaming a document / alias

You can rename a requirement document and assign an alias which is useful for the repor-
ting, because you have an abbreviation of the document name when building the require-
ment identifier. The identifier will be: [document alias]:[id]-[version]. To rename or give
an alias:

Þ Right click the document and select “Properties” from the context menu.

Þ Change the name or choose an alias (in this Project: “Example1” it is “IVIR’)
and click “OK”.

Figure 6.80: Changing the alias of the new requirement document

TESSY 4.0 Manual 233

6 Working with TESSY

The new alias “IVIR” will be used within the Requirements List view and the document
preview (see figure 6.81). (The document preview will only be visible after double clicking
the respective requirement.)

Figure 6.81: The alias of a requirement is used in various views

Information about editing requirements can be found in section 6.4.4.3 Editing

requirements.

6.4.3 Requirements List view

Figure 6.82: Requirements List view

234 TESSY 4.0 Manual

 6.4 Requirement management

6.4.3.1 Icon of the view tool bar

icon action / comment

Shows all descendants.

Table 6.87: Tool bar icons of the Requirements List view

6.4.4 Requirement Editor view

Figure 6.83: Double clicking on a requirement opens the Requirement Editor

The Requirement Editor will also open by double clicking in a requirement in the Require-
ment List view.

6.4.4.1 Icon of the view tool bar

icon action / comment

Adds an image to the element.

Table 6.88: Tool bar icon of the Requirements List view

TESSY 4.0 Manual 235

 6 Working with TESSY

6.4.4.2 Viewing requirements, versions, IDs

Within the Requirement Editor the requirements are displayed with text, figures, if available,
versions and IDs (see figure 6.84).

Figure 6.84: Requirements Editor with test and a figure

Requirements Every requirement has an explicit ID and a version number. TESSY provides the following
List view two mechanisms for assigning requirement version numbers:

• Automatic: TESSY assigns and increments version numbers automatically

if the import file does not contain version numbers. This is the normal
behavior when importing requirements from text files or spreadsheets. When
checking-in requirements, you can decide to increment the major or minor
version number (e.g. major 1.0 to 2.0 or minor 1.0 to 1.1).

• Using external version numbers: It is possible to use existing requirement

version numbers from the import file. This is useful if you get requirements
from an external requirements management tool and need to import exactly
the same version numbers that where already assigned to the requirements.
The only prerequisite for this kind of import is the consistency of the version
numbers.

Using external When using external version numbers, the following checks of the imported data will be
version numbers performed when importing:

• If any requirement content is changed but the version number is not changed,
TESSY will change the minor version number (e.g. from 1.0 to 1.1).

• If the version number was changed but no requirement content was changed,
a warning will be reported.

• If the new version number is less than the highest existing version number
for a requirement, an warning will be reported.

236 TESSY 4.0 Manual

 6.4 Requirement management

Gaps within the numbering of requirement IDs are allowed.

The numbering should be ascending.

6.4.4.3 Editing requirements

To edit a requirement:

Þ Double click on the requirement you want to edit.

The requirement will be opened within the requirement editor in the center of
the Requirement Management perspective.

Þ After editing, click on to save the changes.

TESSY will now create a locally modified version of the requirement which will
be illustrated with a “>” in front of the requirement name (see figure 6.85).

Figure 6.85: The first requirement was modified

Þ Commit your changes with a click on .

Þ A new version of the requirement will be created and you need to decide either
to increment the major or the minor version number within the check-in dialog
(see figure 6.78).

If you did only minor changes or want to commit a draft update of a require-
ment, you can decide to increment only the minor version. In all other cases,
it is recommended to increment the major version.

After committing, the ID of the requirement will be updated to display the

new version (see figure 6.86).

TESSY 4.0 Manual 237

6 Working with TESSY

Figure 6.86: The first requirement has the version number 2.0

6.4.5 Validation Matrix view / VxV Matrix view

Figure 6.87: VxV Matrix view

The VxV matrix supports the assignment of requirements to the test means used for
validation of the requirement. This helps filtering out those requirements that are to be
tested with unit and component testing. The assignments within the VxV matrix will be
used for requirement filtering for reporting.

238 TESSY 4.0 Manual

 6.4 Requirement management

6.4.5.1 Icons of the view tool bar

icon action / shortcut / comment

Adds all test means to the matrix.

Adds all requirements to the matrix.

Removes all unused items.

Table 6.93: Tool bar icons of the VxV Matrix view

6.4.6 Test Means view

Figure 6.88: Test Means view

Requirements will be tested using different test means, e.g. unit test, system test or review.
The default test means used within TESSY are for unit and component testing. You can
filter your requirements by test mean for later reporting issues.

TESSY 4.0 Manual 239

 6 Working with TESSY

6.4.6.1 Icons of the view tool bar

icon action / shortcut / comment

Creates a new test mean.

To edit the selected test mean.

Deletes the selected test mean (Del). Only test means that are not used can
be deleted.

Table 6.94: Tool bar icons of the Test Means view

6.4.7 Link Matrix view

Figure 6.89: Link Matrix view

Within the Link Matrix view you can link modules, test objects and test cases with re-
Link Matrix view quirements. It shows the link relationship of the elements currently contained within the
matrix.

6.4.7.1 Icons of the view tool bar

icon action / shortcut / comment

Transposes the matrix, i.e. changes the rows and columns (Ctrl+T).

Adds all currently linked elements based on the elements selected within the
first column of the matrix.

240 TESSY 4.0 Manual

 6.4 Requirement management

Adds all unlinked requirements.

Adds all unlinked test cases.

Removes selected elements (Delete) from the Link Matrix. Does NOT delete
the element but removes it from the view.

Removes all elements from the Link Matrix. Does NOT delete the element.

Table 6.95: Tool bar icons of the Link Matrix view

6.4.7.2 Status indicators

indicator status / meaning

The link is suspicious. Indicates that changes in the respective requirement

need to be updated.

No link possible. Indicates that it is not possible to add a link here.

Table 6.96: Status indicators of the Suspicious Elements view

6.4.7.3 Adding and removing elements

To add elements to the Link Matrix view:

Þ Drag & drop requirements, modules, test objects or test cases into the matrix.
The elements will be shown within one of the rows in the first column if they
are dropped there. If they are dropped in one of the right columns, they will
appear on top of the respective rows of the matrix.

To exchange rows or colums, click on within the view tool bar.

Þ Click on to add all unlinked requirement.

Þ Click on to add all unlinked test cases.

Þ Use the context menu entry “Add to Link Matrix” within the RQMT Explorer
view, Test Project view or Test Items view.

TESSY 4.0 Manual 241

6 Working with TESSY

Figure 6.90: Adding elements to the Link Matrix view

To remove elements from the Link Matrix view:

Þ Click on (Remove All Elements) in the tool bar to remove all currently
displayed elements.

Þ Click on (Remove Selected Element) in the tool bar will remove the currently
selected element within a row of the matrix (if any element is selected).

This will only remove the elements from the matrix view, no changes
will be made to the elements themselves. They are not deleted in
the process and set links remain unchanged.

Important: Test cases can not be added to the Link Matrix view in the
Requirement Management view. To do so you have to switch to the Overview
perspective (see figure 6.91). Test cases can also be added to the Link Matrix in
the TDE perspective or the SCE perspective.

242 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.91: Adding Test Cases to the Link Matrix view in the Overview perspective

Please notice the following habits:

• The Link Matrix view is available within the Overview perspective and within the
Requirement Management perspective.
• The Link Matrix view will also be visible within the TDE perspective and the SCE
perspective if elements had already been added.
• The current contents of the Link Matrix are remembered when restarting TESSY
but the matrix itself is not persisted in any way. You can add or remove elements
and this will not cause any changes to the elements.
• The search button “Add All Elements Linked to Elements in Rows” allows finding
and adding the elements that are linked to the elements currently displayed within
the rows of the matrix.
• Setting links or changing elements will cause dependent elements to become suspi-
cious. Please refer to section 6.4.8 Suspicious Elements view for details.

TESSY 4.0 Manual 243

 6 Working with TESSY

6.4.7.4 Updating requirement links

If requirements have changed, the links within the Link Matrix view will be declared sus-
picious with an exclamation mark (see figure 6.92).

Figure 6.92: Link Matrix view with suspicious elements

General handling of links:

Þ A double click on a link within the matrix will delete the link and another
double click will create the link again.

Updating To update suspicious links:

suspicious links
Þ Double click a link within the matrix. Click “Yes” in the opening popup window
if you want to update the selected link.

Þ Right click a cell and select “Update Selected Suspicious Link” from the context
menu. The selected link will be updated.

Þ Right click a row and select “Update Suspicious Links” from the context menu.
All links within the selected row will be updated.

244 TESSY 4.0 Manual

 6.4 Requirement management

6.4.8 Suspicious Elements view

Figure 6.93: Suspicious Elements view

The Suspicious Elements view allows finding out the reason why an element is suspicious. Suspicious
In this case the version number has changed and a short description has been added. Elements view

During the testing process modules, test objects and test cases will be linked to
requirements indicating that the respective requirements are tested by the linked
elements.
Whenever a requirement changes because of modifications or because a new version
has been checked in, the linked elements will become suspicious and need to be
reviewed. The suspicious status will be indicated by an exclamation mark icon
decorator, i.e. for a suspicious test object.

TESSY 4.0 Manual 245

6 Working with TESSY

6.4.8.1 Icons of the view tool bar

icon action / shortcut / comment

Sets elements semantic equal (all elements or selected element).

Updates links (all links or selected link).

Compares the versions.

Table 6.103: Tool bar icons of the Suspicious Elements view

“Set elements semantic equal” should only be used in situations where the change
of a requirement does not change its meaning such as spelling corrections, format-
ting etc. In all other cases the link should be updated.

6.4.8.2 Determine changes that caused suspicious status

When you have linked the test object and some test cases, any changes to the linked
requirements will cause the linked elements to become suspicious. Please switch to the
Overview perspective to be able to see that.

Figure 6.94: Suspicious test object and test cases in the Overview perspective

Determine the related modified requirements that causes the status of a test object being
suspicious within the Suspicious Elements view:

Þ Select the suspicious test object within the Test Project view. (Again you have
to do that within the Overview perspective.)

246 TESSY 4.0 Manual

 6.4 Requirement management

The Suspicious Elements view will display the changed requirements (see figure
6.95).

Figure 6.95: Suspicious test object and linked modified requirements

As you can see in figure 6.95 above, the requirement text of the requirement “[IVIR:3-
2.2]:Zero” has been edited. Therefore it has the addition “MODIFIED”.

TESSY 4.0 Manual 247

 6 Working with TESSY

If you select a test case in the Overview perspective, the Suspicious Elements view will also
show the changed requirement(s) (see figure 6.96).

Figure 6.96: Selecting the suspicious test case shows the modified requirement(s)

Differences view Within the Differences view you can determine the exact differences:

Þ Click on (Compare Versions).

The Differences view shows all changes of the requirement (see figure 6.97).

248 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.97: Comparing the versions of the requirement

You need to determine if the change of the requirement affects the linked test cases and
adapt the test data if necessary.

If no changes to the test cases are required, update the link to acknowledge the requirement
change. Therefore click on (Update Link). The suspicious icon will then disappear for
the respective test case.

For more information about the Difference view go to section 6.4.12 Differences
view / Reviewing changes.

You can also update requirement links in the Link Matrix view.

TESSY 4.0 Manual 249

 6 Working with TESSY

6.4.9 Attached Files view

Figure 6.98: Attached Files view

Attached Files The Attached Files view allows adding arbitrary files to the selected requirement. You can
view add additional documents with detailed information about the requirement. The files will
be stored within the TESSY database.

6.4.9.1 Icons of the view tool bar

icon action / shortcut / comment

Adds the selected file (Ctrl+N).

Creates a new folder (Ctrl+B).

To edit a name or description of the selected folder or file (Alt+C).

Deletes the selected file (Del).

Table 6.106: Tool bar icons of the Attached Files view

250 TESSY 4.0 Manual

 6.4 Requirement management

6.4.10 Attributes view

Figure 6.99: Attributes view

The Attributes view allows adding arbitrary attributes for the selected requirement or re- Attributes view
quirement document.

Important: New attributes should be created for the requirement document.

They will then be inherited to each requirement of the document and can be
overwritten on requirement level.

There are three predefined attributes named “Content Type”, “Enable Evaluation” and
“Enable Suspicious Calculation” on document level that control the behavior of the requi-
rement evaluation and suspicious calculation for elements linked to requirements.

6.4.10.1 Icons of the view tool bar

icon action / shortcut / comment

Creates a new attribute (Ctrl+N).

Edits the selected attribute (Ctrl+E or double click).

Deletes the selected attribute (Del).

Table 6.107: Tool bar icons of the Attributes view

TESSY 4.0 Manual 251

6 Working with TESSY

6.4.10.2 Editing attributes of a requirement

Figure 6.100: Editing the requirement settings within the Attributes view

To edit an attribute:

Þ Within the RQMT Explorer view select a requirement, a requirement document,

or a requirement chapter.

The Attributes view will display the attributes for the selected element.

Þ Right click the desired attribute and select “Edit” from the pull-down menu.

Þ Change value, name or description of the attribute if possible or add an des-

cription.

Please note that it is not always possible to edit all of the given opportunities.
Usually it is possible to edit the value but name and description can only be edited
where the attribute was originally created. Type and version of a requirement can
not be edited.

252 TESSY 4.0 Manual

 6.4 Requirement management

For example you can edit the “Content Type” version of a requirement in the Attribute
Settings. This is necessary to enable the HTML Document View and the HTML Editing.
The "Content Type" of a document needs to be “HTML” instead of “PLAIN”.

To do so change the “type” to HTML (instead of plain text):

Þ Select the desired requirement document within the RQMT Explorer view.

Þ Right click the attribute “Content Type” within the Attributes view and select
“Edit”.

Þ Change the value to “HTML” and click “OK” (see figure 6.101).

Figure 6.101: Changing the “Content Type” attribute to HTML

For more information about editing requirements in the HTML editor go to section
6.4.15.2 Editing the requirement as HTML version.

TESSY 4.0 Manual 253

 6 Working with TESSY

6.4.11 History view

Figure 6.102: History view

6.4.11.1 Icons of the view tool bar

icon action / shortcut / comment

Two versions of a requirement are set to be semantically equal if their contents

reflect the same semantics but minor changes were made, e.g. spelling errors.

Unsets semantic equal. You need to have two versions of a requirement

selected to do this operation.

Compares the versions.

Table 6.110: Tool bar icons of the History view

6.4.12 Differences view / Reviewing changes

Differences view The Differences view will be displayed within the lower pane, which provides a direct
comparison of the respective requirement versions printed as text (see figure 6.103).

Reviewing Each requirement has a version history showing all of its changes.
changes To review the changes between any two versions of the history or between a historic version
and the current version,

254 TESSY 4.0 Manual

 6.4 Requirement management

Þ select either two versions within the history view to compare these versions or
select only one version within the view if you want to compare it against the
current version.

Þ Click on (Compare) in the toolbar.

Figure 6.103: Differences view

6.4.12.1 Icons of the view tool bar

icon action / shortcut / comment

Navigates to the left.

Navigates to the right.

Switches on or off the matching of words.

Switches on or off the ignoring of cases.

continue next page

TESSY 4.0 Manual 255

6 Working with TESSY

icon action / shortcut / comment

Switches on or off the ignoring of whitespace.

Sets the layout to vertical.

Sets the layout to horizontal.

Table 6.112: Tool bar icons of the Differences View

6.4.13 Related Elements view

In this view you can see the links of requirements to other requirements, e.g. when creating
refined requirements based on a given requirements document.

After selecting a requirement in RQMT Explorer this view presents all linked elements of
the respective requirement. It shows all sub requirements or the linked main requirements
divided into Incoming Links and Outgoing Links.

Figure 6.104: Related Elements view and its interrelations

256 TESSY 4.0 Manual

 6.4 Requirement management

Figure 6.105: Related Elements view

Figure 6.106: Related Elements view with Incoming and Outgoing Links

TESSY 4.0 Manual 257

6 Working with TESSY

6.4.14 Problems view

In this view information about possible errors that appear e.g. in the process of test execu-
tions is displayed. It is divided into four columns: Message, Location, File and Line. The
first column gives you a detailed error message with all necessary information. The other
three contain all available information about where the error is located.

Figure 6.107: Problems view with error message

The Problems view also appears in the Overview perspective.

Within the pull-down menu in the Problems view it is possible to select the respective
module in the Test Project view in the Overview perspective or to copy it to the clip
board:

icon action

Selects the problematic area in the Project view.

Copies to Clipboard.

Deletes the message.

Table 6.113: Icons of the content menu

258 TESSY 4.0 Manual

 6.4 Requirement management

6.4.15 Document Preview

Important: You have to open the Document Preview by double clicking on

the appropriate requirement document!

Figure 6.108: View Document Preview

TESSY 4.0 Manual 259

6 Working with TESSY

6.4.15.1 Icons of the view tool bar

icon action / comment

Displays the test means within the requirement document.

Displays the sub requirements in the requirement document.

Toggles to the HTML inline editor (only available of the “Content Type” of
the document is “HTML”).

Exports the HTML version as HTML file.

Refreshes the view. Necessary after editing any requirement.

Table 6.114: Tool bar icons of the Document Preview

6.4.15.2 Editing the requirement as HTML version

After you created or imported requirements, you can edit them as HTML version:

Þ Click on the icon (Toggle HTML Editing).

Þ If a note is displayed, that the “Content Type” must be set to HTML, refer
to section 6.4.10.2 Editing attributes of a requirement. After changing the
content type to HTML, refresh the Document Preview with a click on .

Þ Click in a field with any description of a requirement. An HTML inline editor

appears.

Þ With a click on the icon you can switch between the WYSIWYG editor
and plain HTML (see figure 6.109).

Figure 6.109: HTML editing within the inline editor (WYSIWYG and plain HTML)

260 TESSY 4.0 Manual

 6.4 Requirement management

6.4.16 Requirements Coverage view

Important: By default you will find the Requirements Coverage view within
the Overview perspective!

Figure 6.110: Requirements Coverage view with no linked requirements

Within the Requirements Coverage view you will link the test cases with the requirements. Requirements
You will as well have an overview of the requirements coverage. This is the reason why Coverage view
you will find this view within the Overview perspective. within the
Overview
perspective
6.4.16.1 Icons of the view tool bar

icon action / shortcut / comment

Shows only suspicious links in the Planning tab.

Shows all requirements, including unlinked requirements in the Planning tab.

Updates all links in the Planning tab.

continue next page

TESSY 4.0 Manual 261

6 Working with TESSY

icon action / shortcut / comment

Refreshes the view in the Planning and Execution tab. With a click on the
little arrow next to the icon you can set on which selection you want to auto
refresh. You can also disable the auto refresh function (see figure 6.111).

Filters requirements in the Planning tab (component test, unit test, require-
ments without assigned test means).

Table 6.116: Tool bar icons of the Requirements Coverage view

Figure 6.111: Setting or disabling the options of auto refreshing

6.4.16.2 Planning tab

The current status of the links between modules, test objects, test cases and requirements
reflects the current state of your requirements coverage. This coverage can be examined
on arbitrary levels of your test project.

You can also create a report that shows the currently achieved planning coverage in the
test Project view.

Icons of the Planning tab

icon meaning

Requirements on test modul level and their linking status.

continue next page

262 TESSY 4.0 Manual

 6.4 Requirement management

icon meaning

Requirements on test object level their linking status.

Requirements on test case level their linking status.

Linked requirements in total.

Table 6.117: Tool bar icons of the Planning tab

6.4.16.3 Execution tab

After execution of any tests, the test results are stored within test runs. The test result of
a test run covers the requirements that were linked to modules, test objects or test cases at
the time the test was executed. Therefore, the actual execution coverage result may differ
from the planning coverage result. The execution coverage view is read-only, because this
just displays the results. Any changes to requirement links need to be carried out within
the planning coverage view.

You can create a report that shows the currently achieved execution coverage.

Icons of the Execution tab

icon meaning

Test cases with achieved test results for linked requirements.

Total number of test cases with achieved test results for linked requirements.

Passed test cases with achieved test results for linked requirements.

Failed test cases with achieved test results for linked requirements.

Table 6.118: Tool bar icons of the Execution tab

TESSY 4.0 Manual 263

 6 Working with TESSY

6.4.16.4 Linking requirements with test cases

Linking The idea behind linking requirements to modules and test objects is based on the following
requirements process:
with test cases
• First the complete list of requirements is gathered.

• Then each applicable requirement is assigned to modules that implement

functionality referenced by the requirement.

• For further break down of the assignment individual test objects are linked
to the requirements. This especially makes sense if the module has a large
number of linked requirements.

• At last there is a small subset of all available requirements that must be

verified. To be taken in consideration the requirement linking for a given test
object must be further broken down to test case level.

Important: Please note that only linked requirements of test cases will be ana-
lyzed. Unlinked requirements on test case level will not be taken in consideration.

For this process TESSY provides the Requirement Coverage view within the Overview
perspective. It is divided into two tabs:

• The Planning tab (see section 6.4.16.2 Planning tab) is the editor for all
requirement links to modules, test objects and test cases.

• The Execution tab (see section 6.4.16.3 Execution tab) provides quick over-
view about the achieved test results for linked requirements.

Important: When selecting objects on upper levels of the test project, the
calculation of the test planning/execution links can take a moment.

The content that is displayed in the Planning tab or the Execution tab of the Requirement
Coverage view depends on the current selection in the Test Project view of the Overview
perspective. If not already linked with any requirement, all available requirements will be
displayed; otherwise only the linked requirements will be displayed.

If you want to display the requirements on test cases level, you need to select the respective

264 TESSY 4.0 Manual

 6.4 Requirement management

test case in the Test Items view of the Overview perspective.

You can choose to display all available requirements by clicking on “Always show un-
linked requirements” in the Requirement Coverage view. Once chosen, this remains active
for other selections as well.

TESSY 4.0 Manual 265

6 Working with TESSY

6.5 TEE: Configuring the test environment

Figure 6.112: Test Environment Editor (TEE)

To execute a test, you need to create and configure a new module. The necessary settings,
besides the source files that you want to test, are the following:

• include paths and defines for the source files

• the compiler of a microcontroller target and debugger, i.e. the desired test
environment

• compiler and linker options

• debugger settings

• other optional module settings, e.g. ASAP conversion files

We do that within the “Test Environment Editor”, the TEE.

For a complete list of all the available attributes and possible values refer to the
application note “Environment Settings (TEE)”.

266 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

With the installation of TESSY, the configurations for all supported compiler and tar-
get environments (including necessary settings and files) were copied to the TESSY
installation directory. You need to enable the compiler and targets that you want to
use and add them to your configuration file as described in the following sections.
Their default settings may need to be adapted to your needs, e.g. the installation
path of the compiler or target debugger is one of the settings that normally need
to be changed to your local values. Settings which have already been used with a
previous version of TESSY were also taken over during installation.

The TEE configuration management allows you to create variants of compiler and
target settings and assign them to a module. We recommend to save your settings
in a specific configuration file, which is the default when creating a new project
database (see section 6.5.6 Configuration files). This allows easy sharing of specific
environment configurations between developers of the same development team.

As a result you have all your basic settings at one central place, i.e. include
paths, additional compiler options, etc. Once configured, you can start testing
immediately using the required configuration for all your modules.

6.5.1 Starting the TEE

To open the TEE:

Þ In the menu bar click on “File” > “Edit Environment” (see figure 6.113).

The TEE will start with the custom configuration file assigned to this project
database.

TESSY 4.0 Manual 267

6 Working with TESSY

Figure 6.113: Call of the Test Environment Editor (TEE)

6.5.2 Structure of the TEE

Important: TEE is not an eclipse-based program and does not provide views
and perspectives! Therefore you cannot drag and drop the panes.

pane location function

(default)

General left Section General lists all supported compiler and target envi-
ronments which were configured with default settings.

Configurations left Section Configurations lists all supported compiler and target
combinations. The settings of these combinations have been
inherited by the paragraph General. The section displays a
configuration file with default environments.

Attributes right Displays all attributes of an item as soon as it is selected in

the left pane.

Table 6.123: Structure of TEE

268 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

The configuration file

When you have created your project database with the default settings, you
will already have a configuration file assigned to the project database. The name of
this file will be displayed within the lower right side in the status bar of TESSY.
This configuration file will be edited when opening TEE.

Figure 6.114: Configuration file

6.5.3 Icons of the tool bar

icon action / shortcut / comment

Collapses the selected item.

Expands the selected item.

continue next page

TESSY 4.0 Manual 269

6 Working with TESSY

icon action / shortcut / comment

Copies a compiler, including the target and environment sub tree. Icon is only
active when a compiler is selected.

Copies a target, including the environment sub tree. Icon is only active when
a target is selected.

Copies an environment. Icon is only active when an environment is selected.

Deletes the selected item.

Table 6.124: Tool bar icons of the TEE

6.5.4 Status indicators

The following table shows the indicators of status and their meaning which are used by
TEE.

indicator status / meaning

Item added as Windows environment variable for all processes, i.e. the make
call or the slave call, spawned using this test environment.

Item added to path variable of the execution environment.

Item disabled.

Item disabled because of an inherited parent item being disabled. Example: A

compiler item within section “Configurations” gets this item if the respective
compiler item within section “General” is disabled.

Error.

Error, but the cause is somewhere within the attributes inherited by item.
Check for errors upwards or downwards within the configuration hierarchy and
fix the error there.

Information.

continue next page

270 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

indicator status / meaning

The information comes from another item upwards or downwards within the
configuration hierarchy.

Attribute inherited. The attributes in section “Configurations”, i.e. compi-

ler, targets, environment, are normally inherited from the respective section
“General”.

Compiler active.

Compiler inactive, probably overwritten or replaced by another item down-

wards the configuration hierarchy.

Target active.

Target inactive, probably overwritten or replaced by another item downwards

the configuration hierarchy.

Environment active.

Environment inactive, probably overwritten or replaced by another item do-

wnwards the configuration hierarchy.

Warning of error within the attributes of the item. This needs to be resolved
somewhere else within the configuration hierarchy.

Warning, but the cause is somewhere within the attributes inherited by this
item. Check for warnings and errors upwards within the configuration hierarchy
and fix the errors there.

Table 6.125: Status indicators of TEE

Example:

The directory is added to the Windows path variable and also added as Win-
dows environment variable. The attribute has been inherited.

TESSY 4.0 Manual 271

 6 Working with TESSY

Different fonts as TEE will display the attributes in different fonts to indicate the following situations:
indicators
Normal letters Represent factory settings respectively default settings from paragraph
“General” and have been inherited.

Bold Value has been defined the first time for the attribute.

Italic Factory setting respectively default setting from paragraph “General”

has been overwritten

6.5.5 Viewing all available configurations

The TEE provides predefined configurations for all supported compiler and target
environments. By default, at least the GNU GCC and GNU GCC (C++) environ-
ments will be enabled and all your compiler/target environments used in previously
installed versions of TESSY, if any, and only basic attributes are visible for the user.

Visualizing all To visualize all settings, compiler and targets:

attributes
Þ In the tool bar select the option “Show All” from the pull-down menu (see
figure 6.115).

Figure 6.115: Visualizing all items within TEE

272 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

Under “Configurations” more sections are now visible, e.g. “System”, which
contains the compiler and targets possible to use (see figure 6.116).

Figure 6.116: Compiler and targets possible to use in TESSY

You can see the enabled GNU GCC and GNU GCC (C++) environments. All other prede-
fined configurations are disabled (see figure 6.117).

Figure 6.117: Enabled and disabled configurations within TEE

When you select any item on the left pane, the attributes will be shown in the right pane
(see figure 6.118).

TESSY 4.0 Manual 273

6 Working with TESSY

Figure 6.118: Attribute settings of the Eclipse target

You can refresh the panes in TEE by pressing F5.

6.5.6 Configuration files

A system default configuration file contains the settings for all supported compiler
and target environments and has been installed with TESSY into the installation
directory. The configuration file assigned to the project database contains all settings
that are changed compared to the system default configuration. The contents of
this file are displayed within section “File”.

274 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

Configuration files of the respective sections will be stored in following default folders:

paragraph storage, file(s), function

System stored under C:\Program Files\Razorcat\TESSY_3.x\config

• configuration.default.xml: Contains factory settings of TESSY. This

file will not be changed.

• configuration.system.xml: Contains all your changes made in

paragraphs “General” and “Configurations” and will be stored within the
user profile.

The System section is read only! Change your settings by drag ’n drop compiler
and targets onto the file section. Changes are possible within the General section.

File Stored within the configuration file of the project

[PROJECTROOT]\tessy\config\configuration.xml

Table 6.130: Contents, functions and storage location of configuration files

6.5.7 Customizing the configurations

The following steps are necessary to customize the configuration file of the currently open
project:

• Enable the compiler/target environments that you want to use for testing
(see section 6.5.7.1 Enabling configurations).

• Add the desired compiler/target environments to the “FILE” section (see

section 6.5.7.2 Adding configurations).

• Review and adjust the attributes (see section 6.5.7.3 Adjusting enabled con-
figurations).

You need administrator privileges to change the contents of the “General” section!
If you do not have enough privileges, TEE will inform you and save your changes
in a user specific file.

TESSY 4.0 Manual 275

 6 Working with TESSY

6.5.7.1 Enabling configurations

A configuration consists of a combination of compiler, target and a default environment.

Enable To enable a compiler or target,

configurations
Þ select “Show All” from the pull-down menu to display all supported compiler
and target environments.

Þ Either in section General or under “Configuration > System” select the compiler
or target.

Þ Select “Enable Compiler” respectively “Enable target” from the context menu
or press Ctrl+E (see figure 6.119).

TEE will remove the red cross from the icon to indicate, that the item is
enabled.

Figure 6.119: Enable compiler

After enabling your desired compiler/targets, we recommend to select “Hide Disabled”

from the filter menu to have a better overview.

276 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

6.5.7.2 Adding configurations

You make a configuration available as compiler/target environment for usage within TESSY
by adding it to the configuration file. To add an environment, copy an available configu-
ration environment from section “System” onto section “File” by either using the context
menu or drag and drop:

Þ Rightclick the compiler and choose “Add to File Section” from the context
menu (see figure 6.120) or “grap” the compiler with the mouse and drop it
onto the file section (see figure 6.121).

The compiler will be added to the list under “File”.

Þ Change the settings to your needs, e.g. delete some debuggers if they are not
necessary for your test environment.

Important: Do all necessary settings within section “File”, because

all contents of this section will be saved into your configuration file.
Only changed values of attributes will be saved, not the inherited
values from other sections!

Figure 6.120: Adding an environment to a configuration file by using the context menu

TESSY 4.0 Manual 277

6 Working with TESSY

Figure 6.121: Adding an environment to a configuration file by drag and drop

6.5.7.3 Adjusting enabled configurations

Normally you need to change some settings for your specific environment. Some of the
settings will be checked for validity. The TEE will check all enabled configurations and
displays error and warning signs as soon as an error has been found, e.g. if the “Compiler
Install Path” must be corrected.

Important: Please note that all customizations need to be be done within

section “File” in the lower part (“Configurations”) of the TEE to have them sa-
ved into the custom configuration file.The only exceptions would be the compiler
and target installation paths: Those path settings should be carried out within
the sections “Compiler” and “Targets” in the upper part (“General”) of the TEE.
Those sections are saved either into the installation directory or into a configura-
tion file within the user profile.

If you do as explained above, computer specific path settings are kept out of the configu-
ration file which you will probably share with other testers on different computers. On the
other hand your customizations made in the “Configurations” part of the TEE are saved in
the configuration file. So this part of your customizations will automatically be available
to other testers as well.

278 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

Important: Be aware that customized files in the upper part (“General”) of the
TEE, e.g. the “Makefile Template” and the “Linker File” amongst others that
sometimes need to be customized, have to be copied into the TESSY project.
The best way is to copy customized files from the “General” part of the TEE into
the “config” folder of the project root. After that is done the respective attributes
need be updated in the TEE.

Adding and editing attributes

TEE preserves all default settings. You can revert the default values with “Restore
Factory Value” in the context menu (right click the attribute).

To edit an attribute, Editing attributes

Þ right click an attribute in the Attributes pane.

Þ Select “Edit Attribute” from the context menu.

Þ If you want to change only an attribute value, select “Edit Attribute Value”
from the context menu.

Depending on the attribute type, either a standard selection dialog for that
kind of information will appear (e.g. Browse for Folder in case of directories)
or the inline editor for the value will be activated.
If you have changed a default value other than the factory setting, the attribute
will be displayed in italics.

Þ If you want to delete the attribute value, select “Reset Attribute” from the
context menu or press Del.

This will either remove the local value and show the inherited value or delete
the whole attribute entry, if it is only defined locally in this section.

To add an attribute, Adding attributes

Þ right click in the Attributes pane.

Þ Select “New Attribute” from the context menu.

The New Property dialog will open.

You see different attribute types available: String, Boolean, Number, Float,
File and Directory.

TESSY 4.0 Manual 279

6 Working with TESSY

Þ Specify the desired type.

Important: The type cannot be changed once the attribute is cre-

ated!

Þ Check the desired specific attribute flags. This depends on the type used. For
description see table below.

Þ Click “OK”.

flag description

Inheritable This flag will always be ticked by default. It controls the inheritance of
the attribute: The attribute will be available in all (child) section nodes.
Some basic attributes are defined at the main nodes, e.g. compiler. Each
supported compiler will inherit these basic attributes.

validate This flag may be important for directory or file types. The attribute value
will be validated by TEE, e.g. whether the path or file is available. An error
sign will indicate that the file or directory could not be found.

Read only This flag makes it impossible to change a default value by using the attribute
pane of the module properties dialog.

Always Valid Internal flag of TEE

As List Using this flag, the attribute value will be handled as list of values (comma
separated). The values may be edited using a special list dialog. This is
useful for file or directory types.

Multiline Provides a text window for multiline editing.

System Internal flag of TEE.

Hex Format This flag is useful in combination with the number type. TEE will convert
all inputs (e.g. a decimal value) to a hex value, e.g. 1 > 0x01.

Visible This flag makes the attribute visible in the attribute pane of the module
properties dialog (and within the test report).

Not Empty Checks whether the value is not empty. An error sign will indicate that the
attribute does not have a value.

continue next page

280 TESSY 4.0 Manual

 6.5 TEE: Configuring the test environment

flag description

System Internal flag of TEE.

Environment This flag is useful during test execution and during the make process:
Variable TESSY will create an environment variable within the process space of the
process that will be used for test execution (e.g. running the slave process)
and for make (e.g. building the test driver).

Important: The environment variable will only be recogni-

zed by TESSY if a plus-sign is used in front of the Make
Call value.

Add to PATH This flag is useful for attributes of type directory. Like described above
Variable for the flag “Environment Variable”, the respective directory value will be
added to the PATH variable of the process space used for test execution
and make.

Makefile Vari- Adds this variable to the generated makefile for compilation/linking of the
able test driver application. You can use this variable within the makefile for
include paths or other settings required during the make process. A varia-
ble named “My Include Path” will be added to the generated makefile as
MY_INCLUDE_PATH with the respective value.

Table 6.136: Meanings of flags in the attribute properties

6.5.7.4 Assigning an existing configuration file to your project

If you want to assign an existing customized configuration file to your project, do as follows: Assigning a
configuration file

Þ In the menu bar of TESSY select “File” > “Edit Project. . . ”

The Project Configuration dialog opens.

Þ Open the “Advanced Settings”.

Þ Under “Configuration File” click on “. . . ”, choose your file and click “Open”.

Click “OK”.

TESSY 4.0 Manual 281

6 Working with TESSY

6.6 TIE: Preparing the test interface

Figure 6.122: Perspective TIE - Test Interface Editor

Within the TIE you determine which values are input and which ones are output variables.
Input values are all interface elements that have to be set before execution of a test
object. Output values are compared with the expected values after test execution.

After configuring the test environment of a module and opening the module the
analysis of the respective source files starts. The functions found within the source
files will be available as test objects, TESSY will try to assign useful default passing
directions automatically.
You need to specify missing information that TESSY could not determine automa-
tically, i.e. array dimensions or values of enumeration constants. This can happen
due to the usage of the “sizeof” operator when declaring arrays or enumeration
constants.

282 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

6.6.1 Structure of the TIE perspective

pane location function

(default)

Test Project view upper left Same view as within the Overview perspective.

Properties view lower left Same view as within the Overview perspective.

Interface view upper right To display all interface elements of the test object and
to provide the edit fields to enter passing directions of
variables as well as additional information.

Plot Definitions right To create and configure plots (same view as within the
view TDE perspective).

Table 6.138: Structure of TIE

6.6.2 Test Project view

The Test Project view displays your test project which you organized within the Overview 6.2.2 Test
Project view
perspective.

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

6.6.3 Properties view

The Properties view is context sensitive: You can view the passing direction of a variable Passing directions
(e.g. IN, OUT, IRRELEVANT) if you select the variable within the Interface view. Then of a variable
the Properties view will display the passing direction and the type information (see figure
6.123).

TESSY 4.0 Manual 283

6 Working with TESSY

Figure 6.123: Information of passing direction and type

6.6.4 Interface view

Figure 6.124: Interface view

284 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

6.6.4.1 Icons of the view tool bar

icon action / shortcut / comment

Highlights the next undefined value.

Highlights the previous undefined value.

Creates a new variable.

External functions.

Internal functions.

External variables.

Global Variables.

Function.

Stub function.

Table 6.139: Icons of the Interface view

6.6.4.2 Status indicators

status status / meaning

indicator

Function with advanced stub funcion.

Function with global stub function.

Table 6.140: Status indicators of the Interface view

6.6.4.3 Handling

You can browse through the interface items of the currently selected test object. An arrow
in front indicates further levels (see figure 6.125).

TESSY 4.0 Manual 285

 6 Working with TESSY

Important: In some windows versions you need to move the mouse over the
view to see the arrows! They will fade-out when the view is not active.

Figure 6.125: White arrow indicating further levels, black arrow when expanded

6.6.4.4 Interface elements

Interface The variables are either read within the function (IN), written within the function (OUT),
elements both read and written (INOUT), to be altered by usercode (EXTERN), or they are simply
not used within the function (IRRELEVANT).

The TIE classifies all recognized interface elements of the test object into the following
sections:

External Functions All functions which are not defined within the source file(s) of
the module. These functions are called from the test object.

Local Functions All functions defined within the source file(s). These functions
are called from the test object.

External Variables External declared variables which are not defined within the
source file(s).

Global Variables Global variables and module local static variables which are
defined within the source file(s).

286 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

Parameter Parameter of the test object. You can browse through the
structures by clicking on the plus sign to see the basic compo-
nents.

Return Return value of the test object.

Unused Contains all sections and the related interface elements which
are not used in the current test object.

6.6.4.5 Setting passing directions

The passing direction reflects the kind of usage for each variable while testing the
test object. You can specify how TESSY treats a value for an interface variable either
to provide the value before test execution (IN) or to keep the value for evaluation
and reporting after test execution (OUT).

To set the passing directions: Setting passing

directions
Þ Click in the relevant cell of the element in the column “Passing”.

A drop-down menu will be displayed with the available options IN, OUT, IN-
OUT and IRRELEVANT.

Þ Select a suitable passing direction.

You have to specify one of the following passing directions for each interface element:

• provide an input value for that interface element, because the element is only
read by the test object (IN),

• evaluate and report the results of that interface element, because the element
is only written by the test object (OUT),

• both provide a value and evaluate the result, because the interface element
is both read and written by the test object (INOUT),

• provide a value within the UCE (Usercode Editor) of TESSY (EXTERN) .

With this setting, the interface element is visible in the scope of the user
code and may be set using C code,

• not use the interface element at all (IRRELEVANT). In this case, you will
not see this variable for all further testing activities.

TESSY 4.0 Manual 287

6 Working with TESSY

The following table shows possible passing directions of the different types of interface
elements:

direction: IN OUT INOUT EXTERN IRRELEVANT

element:

external variable x x x x x

global variable x x x x x

parameter x x x

return x x x

Table 6.144: Possible passing directions of the interface elements

Automatic analysis of the passing directions

During processing when opening the module, TESSY analyzes the passing directions auto-
matically and stores its findings in the interface database. This information is available in
the TIE as default values of the passing directions. TESSY analyzes the usage of individual
interface elements by the test object.

Warning: Although TESSY usually correctly recognizes all interface settings,

open the TIE for every test object and make sure that the values are set correctly
or do match your needs!

Depending on that usage, the following passing directions will be set as default:

read only IN

write only OUT

read and write INOUT

not used IRRELEVANT

In case that the passing directions or any other interface information could not be deter-
mined the respective fields in the TIE will be empty, i.e. if TESSY could not calculate

288 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

the size of an array dimension (indicated with a question mark), you have to set them
manually. Reset passing direction to default TESSY analyzes the usage of individual
interface elements by the test object. Change the passing direction of an interface element
to suite your needs.

Reset the passing direction for all interface elements of one section:

Þ Select the respective section and “Reset to Default Passing” from the context
menu (see figure 6.126).

Figure 6.126: Resetting passing directions

Reset the passing direction only for an individual interface element:

Þ Select the respective interface element and “Reset to Default Passing” from
the context menu.

6.6.4.6 Setting the data format

You can change the data format: Setting the data

format
Þ In the row “Data Format” click into the cell to open the pull-down menu.

Þ Click on a format to change it either to “Decimal”, “Hexadecimal” or “Binary”

(see figure 6.127) and click on (Save).

TESSY 4.0 Manual 289

 6 Working with TESSY

Figure 6.127: Setting the data format

Important: If you change the data format, all newly entered values within the
Test Data view of the TDE will be formatted into the new format. Existing data
will not be formatted!

6.6.4.7 Setting passing direction of special data types

Pointers and complex data types will be treated slightly different as normal data types.

Pointers

Interface elements of pointer type have two passing directions:

Pointers Both the passing direction of the pointer itself and the passing direction of the target
to which it points have to be specified. The passing direction of the pointer and the
target can be set independently, but they are checked or corrected by TIE to ensure valid
combinations.

Complex data types

Complex data types as “Structure” and “Union” have a dependency between their passing
direction of the overall structure/union and the passing directions of their components. To
avoid invalid combinations the TIE checks the setting of passing directions for these data
types in the following manner:

290 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

• When the passing direction of one component is set, TIE determines the
resulting passing direction for the overall structure/union and set them au-
tomatically.

• When the passing direction for the overall structure is set, all components
are automatically set to the same passing direction.

Arrays

The passing direction of the data type “Array” will be set for the entire array to the same
direction. Only one passing direction will be defined for the whole array and all elements. If
the array is made up of structured array elements (e.g. structures), it is possible to define Arrays
different passing directions for the components of these structures.

Array as parameters will be shown as pointers within the interface. They can be initialized
with NULL or pointing to a dynamic object (see figure 6.128).

Figure 6.128: Array as pointer NULL

6.6.4.8 Defining stubs for functions

The TIE displays all functions used by the test object either in section External Functions
or Local Functions and it provides an interface to define stubs for these functions that will
be executed instead of the original function. TIE distinct two different stub functions:

• A stub function for which you can enter C code.

• An advanced stub function that allows to provide values for parameters

and return values of stub functions like normal variables in the TDE.

TESSY 4.0 Manual 291

 6 Working with TESSY

You can define stubs globally for all test objects of the module or create a stub
independently of the global module setting.

The following restrictions apply to advanced stubs:

• Advanced stub variables cannot be created for arrays and pointer to arrays

• Pointers that are components of structs or unions will always be handled as

IRRELEVANT

• Multiple calls to advanced stubs will always use the same input values and
the results of the last call will be taken as output values

Important: Stub functions returning a value should be implemented with stub

code that returns a defined value. If no stub code is provided for such non-void
functions, a random value will be returned which depends on the current memory
layout and stack contents. Therefore TESSY aborts the test driver generation
in such a case with an error. You can select to ignore this error within the test
execution preference pages if you are sure that the return values of your stub
functions are not used. (For more information see Executing tests)

Creating a stub To create a stub

function
Þ rightclick the function and choose “Create Stub” from the context menu (see
figure 6.129).

Figure 6.129: Create a stub function within the context menu

292 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

You can create stubs either for external or local functions which will be executed instead
of the original functions. There are several options available:

• Create stubs for all functions at once for all test objects of the module (global
setting).

• Create stubs for a single function for all test objects of the module (global
setting).

• Create stubs for the current test object.

• Change settings for the current test object.

The enhancement to normal stub functions are advanced stub functions, that allow to
provide values for parameters and return values of stub functions like normal variables.
TESSY checks if the stub is called by the test object with the specified parameter values,
otherwise the test fails. You can also provide a return value for further processing by the
test object. This reveals if the test object handles the return values of the stub function
correctly.

To create an advanced stub, Creating an

advanced stub
Þ rightclick the function and choose “Create Advanced Stub” from the context function
menu.

You can create advanced stubs either for external or local functions. There are several
options available:

• Create advanced stubs for all functions at once for all test objects of the
module (global setting).

• Create advanced stubs for the current test object.

• Change settings for the current test object.

6.6.4.9 Other interface settings

For test execution the information on data types of the test object interface has to be
complete. The dimensions for arrays, the values of the enumeration constants for enu-
merations, and the dimensions for bitfields have to be defined. If these values have been
automatically recognized by TESSY while opening the module, the respective text field

TESSY 4.0 Manual 293

6 Working with TESSY

will show the calculated value for every data type. In this case, it is not possible to change
these values.

If a value for an interface element has not been recognized automatically, the respective
text field will be empty or contain the value -1. In case of arrays TIE will also use question
marks to indicate this issue, i.e. array[?]. In all those cases you have to add values
manually.

Warning: Wrong array dimensions or wrong values for enumeration constants

can cause the test object to crash during test execution! TIE cannot check for
plausibility of used values!

6.6.4.10 Creating new variables

You can create new (synthetic) variables for usage within your test cases based on all basic
C/C++ types as well as based on all types available within your source files. To create a
new variable:

Þ click on the icon (New Variable).

Figure 6.130: Create a new variable

294 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

Within the New Variable dialog:

Þ Specify the name of the variable.

Þ Select a type and whether it shall be a pointer or an array.

Þ Click “OK”.

The new variable will be shown within the TIE view with the default passing direction
“INOUT”. Adjust the passing direction to your needs.

6.6.4.11 Using alias names

TESSY provides an alias name mechanism to mirror the usage of #define to access
variables during the whole testing cycle (e.g. access to individual bits of common bitfield
structures). You will see your variables within TESSY named exactly as the defines you
are using in your code to access these variables.

Figure 6.131: Example code snippet for alias names

To activate the usage of alias names:

Þ Change the value of the TEE attribute “Use Alias Names” to “true” (Refer to
chapter 6.5.7.3).

TESSY 4.0 Manual 295

6 Working with TESSY

Figure 6.132: Show alias names preferences

Þ Check the “Show Alias Names” preferences button.

Instead of the real variable name “door_light_c.b.b0” that you are not using within your
code, you will now see the virtual name “door_light_left_b” given through the define
within the TESSY interface and within the test reports.

6.6.5 Plot Definitions view

Important: In TESSY version 3.2 and higher the single Plots view has split in
two separate views, the Plots view and the Plot Definitions view!

Figure 6.133: Plot Definitions view

296 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

The Plot Definitions view displays the plots for a selected test object or test run. Within
the view you can create or configure plots for a selected test object.

6.6.5.1 Icons of the view tool bar

icon action / shortcut / comment

Creates a new plot with no variables.

Deletes the selected plot respectively removes the selected variable from its
plot.

Expands the tree.

Collapses the tree.

Table 6.160: Icons of the Plot Definitions view

6.6.5.2 Creating plots

TESSY can handle different kind of plots:

A test case plot spanns over all values of all test cases of the selected vari-
ables.
A test step plot provides one curve for each test case spanning over all values of
the test steps of this test case. This requires at least two test steps for each test
case to define a valid curve.
An array plot creates plots for array type variables. There will be one curve
spanning over the array values for each test step.

Variables can be dragged from the TIE or TDE onto the Plot Definitions view, and plots
and variables can be dragged and dropped within the Plot Definitions view.

To add variables to the plot: Adding variables

to plot
Þ Drag and drop the variables to the Plot Definitions view (see figure 6.134.).

TESSY 4.0 Manual 297

6 Working with TESSY

Figure 6.134: Adding variables to a plot

The table below shows the different possibilities:

drag source onto result

scalar or array variable empty area A new plot containing the variable is created.
from TIE or TDE
plot The variable is added to the plot if possi-
ble. (1)

variable from Plot empty area The variable is moved to a new plot. (2)
Definitions view
another plot The variable is moved to the other plot.
(1, 2)

plot from Plot empty area A copy of the plot is created. (3)
Definitions view

Table 6.162: Drag and drop handling with the Plots and Plot Definitions view

298 TESSY 4.0 Manual

 6.6 TIE: Preparing the test interface

(1) Restrictions apply: A scalar variable cannot be added to an array plot, and whole
arrays cannot be added to a test case or test step plot (whereas single array elements can
be added to test case or test step plots).
(2) If CTRL is being pressed while dropping the variable, it will be copied instead of moved
to the other plot.
(3) Only applies if CTRL is being pressed while dropping the plot.

6.6.5.3 Reporting plots

Only the plots that are ticked with “Use in Report” will be displayed within the reports
(see figure 6.135).

Figure 6.135: Using plots in report

TESSY 4.0 Manual 299

6 Working with TESSY

6.7 CTE: Designing the test cases

Figure 6.136: CTE perspective

6.7.1 The basic idea

After preparing a test in the TIE, you need to create well designed test case specifications.
The Classification Tree Method provides a systematical approach to create test case defini-
tions based on the functional specification of the function or system to be tested. TESSY
includes the specialized Classification Tree Editor CTE which assists you in creating low
redundant and error sensitive test cases.

The basic concept of the Classification Tree Method is to first partition the set of possible
inputs for the test object separately and from different aspects, and then to combine them
to obtain redundancy-free test cases covering the complete input domain.

6.7.2 Starting CTE

Þ Switch to the CTE perspective.

300 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

6.7.3 Structure of the CTE perspective

pane location function

(default)

Test Project view upper left Displays your test project. For editing your test project
switch to the Overview perspective.

Properties view lower left Displays the properties of your test project, e.g. sources
to the test object.

Classification center To edit the classification tree.

Tree view

Test Data view right Allows to assign test data to classification tree elements.

Table 6.164: Structure of the CTE perspective

6.7.4 Test Project view

The Test Project view displays your test project which you organized within the Overview 6.2.2 Test
Project view
perspective.

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

6.7.5 Properties view

The Properties view displays all the properties which you organized within the Overview
perspective. Most operations are possible. 6.2.3
Properties view

For changing any module related settings switch to the Properties view within the Overview
perspective.

TESSY 4.0 Manual 301

 6 Working with TESSY

6.7.6 Classification Tree view

Classification
Tree view

Figure 6.137: Classification Tree view

Maximize the CTE window within the Classification Tree view to avoid additional
scroll bars and to always show the whole CTE window contents within the view.

6.7.6.1 Icons of the view tool bar

icon action / shortcut / comment

Prints the classification tree (Ctrl + P).

Gives a print preview.

Undoes the last move or edit operation within the classification tree pane.

Cuts the selection (Ctrl + X).

continue next page

302 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

icon action / shortcut / comment

Copies the selection (Ctrl + C).

Paste (Ctrl + V).

Delete (Del).

Selects all leaves that are children of the current selection (Ctrl + L).

Selects the whole CT (Ctrl + A).

Adjusts the tree horizontal (Shift + H).

Adjusts the tree vertical (Shift + V).

Displays the tree in a horizontal layout.

Displays the tree in an arrow layout.

Displays the tree in a leftdown layout.

Displays the tree in a rightdown layout.

Zooms in.

Zooms out.

Table 6.165: Tool bar icons of the Classification Tree view

6.7.6.2 Structure of the Classification Tree view

pane location function

(default)

test item list lower left Defining test cases, test sequences and test steps. Every test
item creates a new line in the table pad.

draw pad upper right Drawing the classification tree with a root, classifications and
classes.

continue next page

TESSY 4.0 Manual 303

 6 Working with TESSY

pane location function

(default)

table pad lower right Marking classes of the classification tree in order to define
test cases, test sequences and test steps. Every test item
creates a new line in the table pad.

Table 6.166: Structure of Classification Tree view

6.7.6.3 Creating classifications, classes and test cases

A test case is formed through the combination of classes from different classifications.
For each test case exactly one class of each classification is considered. The combined
classes must be logical compatible; otherwise the test case is not executable. You should
choose as many test cases that all aspects, not only individual but also in combination, are
considered enough.

The method offers a graphical representation of the recursive partitioning of classifications

and classes as classification tree. The classifications are drawn as named rectangles. The
respective classes are arranged below. To specify the test cases as combination of classes
the classification tree is used as the head of a combination table wherein the classes, which
are to be combined, are marked.

Creating To create classifications:

classifications
Þ Select the root tree item.

Þ Use the context menu (“New” > “Classification”, see figure 6.138) or press
Ins.

304 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

Figure 6.138: Creating a new classification with the context menu

To edit the classification:

Þ Double click the new classification or press F2 to start the inline editor for the
tree item.

Within the draw pad you can move the classifications with drag and drop: Select
either a classification, a sub tree (click on ) or select all (click on ) and press
the mouse button until the cursor turns into a cross with four arrows , then
move the selection.

To create classes: Creating classes

Þ Right click the classification and select “New” > “Class” or select the classifi-
cation and press Ins.

Try the several layouts for the tree for a better overview, e.g. (Arrow Layout),
leftdown or horizontal !

You can assign test data to all interface variables for each tree node of the clas-
sification tree. This speeds up testing because the test data will be assigned
automatically to the test cases via the marked class nodes (refer to section 6.7.7
Test Data view).

TESSY 4.0 Manual 305

 6 Working with TESSY

Creating test To create test cases:

cases
Þ Select the pane on the lower left (test item list).

Þ Create the test cases either using the context menu (“New” > “Testcase”, see
figure 6.139) or press Ins.

Figure 6.139: Creating test cases in the test item list

Test cases are defined by setting markings in the combination table:

Þ Move the mouse pointer over the combination table.

Connecting lines to the classes of the classification tree are drawn. If the mouse
pointer is placed over a point of intersection it is changed to a circle.

Þ Click on a circle to connect a test case with a class.

Þ Click on to save the classification tree.

If you connect a test case with a class, the respective test data assigments of the
class will be assigned to the test case. If you want to review the resulting test data
assignments for the whole test case, select the test case within the test item list.
The Test Data view will now display the assignments for the test case.

The test data is displayed read-only because it is defined by the marks set
within the combination table and cannot be changed here.

306 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

Figure 6.140: Classification Tree with test data for class h

Notice the following habits:

• All tree items with assigned test data are marked with a yellow dot, when not
selected.
• When selecting a tree item, you will see the test data entered for this item within
the Test Data view.
• When selecting any interface element within the Test Data view, all classification
tree elements that contain test data for this interface element will be marked with
a blue dot.

Þ Switch to the TDE perspective.

TESSY 4.0 Manual 307

 6 Working with TESSY

Figure 6.141: The first two test cases are read only and created within the CTE

Please notice the following habits:

• Test items with values stemming from the CTE perspective are marked with new
status indicators: (test case) and (test steps).
• Values stemming from the CTE are read-only. If you want to change them, switch
back to the CTE perspective and do your changes there.

6.7.7 Test Data view

6.8.7 Test Whether using the CTE or creating the test cases manually within the TDE perspective,
Data view
you will use the Test Data view to enter the values. Because some operations and overviews
are only possible within the TDE perspective, switch to chapter 6.8.7 Test Data view to
learn how to use the Test Data view.

6.7.7.1 Assigning test data to the CTE

Instead of assigning test data directly to all variables of the test object interface for each
test case, you can assign them using the tree nodes of the classification tree. For each tree
node you can assign values to variables.
Child nodes inherit the values from their parent nodes, but you can as well overwrite
inherited variable values for a child tree node. Inherited values are marked with (see
also figure 6.142).

308 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

Figure 6.142: Showing data of a tree node

When combining leaf classes of the classification tree to test cases, the variable assignments
of the marked tree nodes will be assigned to the respective test case. In this way, you can
assign all test data within the classification tree and get your test cases automatically filled
by setting marks within the combination table.

To assign test data to a variable of the test object interface:

Þ Select a tree node within the CTE tree.

The Test Data view on the right hand will show the test object interface with
the value assignments for this tree node as well as inherited values of parent
nodes of the tree node.

Þ Double click in the value cell and enter the value.

Þ Click on to save the entries.

When selecting a test case within the test item list you will see the resulting test data
assignments according to the marks of the test case within the Test Data view.

6.7.8 Test data assignment precedence rules

When assigning test data to tree nodes of the classification tree, the same variable can be
assigned within different locations of the tree and each assignment can have another value
for the variable. The resulting value for such a variable (for a given test case) depends on
the classes being marked for a test case.
When calculating the variable assignments for a test case, CTE collects all marked tree

TESSY 4.0 Manual 309

6 Working with TESSY

branches where the variable is assigned. A tree path is defined as the list of tree nodes up
to the root starting at the tree node where the variable is assigned. The tree paths are
sorted by position of their leaf nodes: The sort order is from left to right.

The following precedence rules for tree paths apply:

1. Left to right precedence: Tree paths are compared starting from the root until they
diverge. The rightmost diverged node wins.

2. Longer path precedence: If one tree path is a full sub path of the other, the longer
path wins.

The example below (see figure 6.143) shows different assignments of variable “x” within a
classification tree. The resulting value for “x” is indicated for each test case.

Figure 6.143: Variable assignments in classification trees

The resulting value for the test cases will be calculated like follows:

1. For the first test case the variable is assigned in class “b” which is a longer path than
the assignment within the root, so the value of class "b" will be taken.

310 TESSY 4.0 Manual

 6.7 CTE: Designing the test cases

2. For the second test case we have values within class “b” and class “e”. The tree
paths diverge below the root node and the classification “O” is on the right side so
that the value of class “e” will be taken.

3. In the third test case there are values within the root node and within classes “b” and
“c”. Both tree paths of the classes are longer than the root path and the classification
“B” is on the right side so that the value of class “c” will be taken.

4. In the fourth test case we have the tree paths of classes “b” and “g” that diverge at
the root. Because classification “O” is in the right side, the value of class “g” will
be taken.

5. In this test case all marked classes refer to the value defined within the root node so
that the value of the root node will be taken.

TESSY 4.0 Manual 311

6 Working with TESSY

6.8 TDE: Entering test data

Figure 6.144: TDE perspective

6.8.1 Structure of the TDE perspective

pane location function

(default)

Test Project view upper left Same view as within the Overview perspective.

Test Results view upper left Same view as within the Overview perspective.

Evaluation upper left Same view as within the Overview perspective.

Macros view

Test Items view lower left Same view as within the Overview perspective.

Properties view lower left Same view as within the Overview perspective.

Test Data view upper right To enter test data and expected values, after the test
execution, reviewing passed, failed and undefined values.

continue next page

312 TESSY 4.0 Manual

 6.8 TDE: Entering test data

pane location function

(default)

Test Definition lower center To display the test case specification, the optional des-
view cription and linked requirements of the current test case.

Declaration view lower center To define own variables for the user code.

Prolog/Epilog lower center To specify usercode that will be executed at a certain

view point in time during the test execution.

Plots view lower center To visualize graphically the test results.

Usercode Outline lower right To display the usercode that will be executed at a certain
view point in time during the test execution.

Plot Definitions lower right To create and configure plots (same view as within the
view TDE perspective).

Table 6.178: Structure of TDE

Usercode

TESSY provides an interface to specify the usercode that will be executed

at a certain point in time during the test execution. Using the usercode views
(i.e. Prolog/Epilog view and Usercode Outline view) you can specify such C code
fragments or emulator scripts depending on the selected target configuration.

6.8.2 Test Project view

The Test Project view displays your test project which you organized within the Overview 6.2.2 Test
Project view
perspective.

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

TESSY 4.0 Manual 313

 6 Working with TESSY

6.8.3 Test Results view

6.2.6 Test The Test Results view displays the coverage measurement results and the results of a test
Results view
run of expected outputs, evaluation macros and call traces, if applicable. It is the same
view as within the Overview perspective.

6.8.4 Evaluation Macros view

6.2.7
Evaluation Macros This view lists the detailed results of the evaluation macros if the usercode of the test object
view
contains any evaluation macros. The results are displayed wherever they occur within the
usercode, e.g. within stub functions or test step epilogs. It is the same view as within the
Overview perspective.

6.8.5 Test Items view

6.2.5 Test Within the Test Items view you get an overview about your test cases and test steps which
Items view
you organized within the Overview perspective or the CTE (see section 6.7).

To create test cases and test steps manually without using the Classification Tree Editor,
switch to the Test Items view within the Overview perspective.

6.8.6 Properties view

The Properties view displays all the properties which you organized within the Overview
6.2.3 perspective. Most operations are possible.
Properties view
For changing a source switch to the Properties view within the Overview perspective.

Type information The view is context sensitive: You can view the passing direction and all type information
of a variable of the variable (i.e. the basic type, the size as well as any modifiers and pragmas) if you
select the variable within the Test Data view (see figure 6.145).

314 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.145: Type information of the variable long range_start

6.8.7 Test Data view

Figure 6.146: Test Data view

Whether using the CTE or creating the test cases manually within the TDE perspective,
you will use the Test Data view to enter or review the input values and expected results of
all test cases and test steps.

Important: CTE exported values are read-only within the TDE perspective.
The cells are insensitive. Switch to the CTE perspective to change such values if
necessary (respectively the underlying document).

TESSY 4.0 Manual 315

6 Working with TESSY

6.8.7.1 Icons of the view tool bar

icon action / shortcut / comment

Highlights the next failed value.

Highlights the previous failed value.

Highlights the next passed value.

Highlights the previous passed value.

Highlights the next undefined value.

Highlights the previous undefined value.

Highlights the next modified value.

Highlights the previous modified value.

Shows all actual values.

Highlights all undefined values.

Highlights all modified values.

Shows only failed test cases.

Shows only failed test steps.

Links with the Test Item view.

Table 6.179: Tool bar icons of the Test Data view

6.8.7.2 Status indicators

The following table shows the indicators of status and their meaning which are used by the
Test Data view.

316 TESSY 4.0 Manual

 6.8 TDE: Entering test data

indicator status / meaning

Test step passed: The actual result did match the expected results.

Test step failed: The actual result did not match the expected results.

Test step generated: The test step was generated by the test case generator
but has no executable data yet.

Test step generated with data: The test step was generated by the test case
generator and executable test steps were generated.

Table 6.180: Status indicators of the Test Data view

6.8.7.3 Viewing the interface of the test object

The Test Data view displays the interface of the test object. On the left side of the Test Data view
you see the following interface elements and icons:

Important: Interface elements with the passing direction “Irrelevant” or “Ex-

tern” will NOT be displayed within the TDE!

element / icon means

Inputs and Input values are all interface elements that are read by the test object.
Outputs Output values are written by the test object respectively are the expected
results.
Within the TIE you determine which values are Inputs and which are
Outputs. TESSY tries to find out the default passing directions (input or
output) automatically when analyzing the source files.

Globals Globals are the global variables referenced by your test object. Global
variables can contain global static variables and static local variables that
are defined within functions.

Parameter Parameters of the functions of the test object.

Dynamics Pointer targets, referenced through a pointer of the test object interface.

continue next page

TESSY 4.0 Manual 317

6 Working with TESSY

element / icon means

Return Return variables.

(white arrow) The arrow is displayed when an element has child elements. Click on the
arrow to expand.
If you want to expand all child elements, use the context menu (“Expand
all”).

(blue dot) Function

Table 6.181: Interface elements and icons of the Test Data view

Every variable will be assigned to one of the interface elements described above, e.g.
Parameter, Global etc. Initially, the Dynamics section will always be empty. The colums
on the right represent the test steps where the values of the variables are defined.

Please notice the following habits of this view:

• Select a column by clicking on the number of the test step. The selected column is
marked in blue (compare figure 6.147).
• Move the mouse pointer over the number of the test step to see the name of the
test step within a tool tip (compare figure 6.147).
• Select all values for a variable by clicking on the variable in the left column.
• If you select the icon “Highlight Undefined Values” in the tool bar, all variables that
do not contain any data are marked in yellow (compare figure 6.147).

318 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.147: Test step 1.1 is selected and undefined values are highlighted in yellow.

To choose the test steps you want to see in the Test Data view you need to select them in
the Test Item view (Ctrl + click) first. Make sure that (Link with the Test Item View)
is enabled in the Test Data view tool bar. After that only the selected test steps will be
displayed (see figure 6.148).

Figure 6.148: Test Data view showing selected test steps.

TESSY 4.0 Manual 319

 6 Working with TESSY

6.8.7.4 Entering values

Entering values Values for interface elements are entered into the cells of the Test Data view. The values
will be checked and/or converted when leaving the cell or when changing to any neighboring
cell.

The TDE provides undo/redo functionality for all changes within the Test Data view!

Validation of test data values

By default, all imported or manually entered test data values are checked for syn-
tactical correctness, truncated to the type size and optionally formatted. The truncation of
values depends on which kind of number format was used:

• Decimal numbers will be checked against the minimum and maximum value of the
respective data type. When entering -10 for an unsigned type you will see a value
of 0 as test data. If the value is less than the minimum, the minimum value will be
used, if it is more than the maximum, the maximum value will be used.
• Hexadecimal and binary numbers will be truncated to the number of bytes available
for the respective data type, regardless if the type is signed or unsigned. When
entering 0xF11 for an 8 bit type you will see a value of 0x11 as test data. Also when
entering a binary 0b1100001111 you will see a value of 0b00001111 as test data.
• Missing leading zeros will be filled up for hexadecimal and binary values. If you enter
0x12 for a 16 bit value, you will see a value of 0x0012 as test data.

After the truncation of the value to the available data type size, it will be formatted according
to the data format configured within TIE. Suppose you have an 8 bit signed value with data
format “Decimal” and you enter a value of 0xF05: The value will firstly be truncated to 0x05
and then formatted as decimal number so that you will see 5 as test data value.

Important: If you change the data format within TIE, only newly entered test
data will be formatted according to the new format. If you want to change the
format of the available test data for a certain variable, you need to use the “Con-
vert to Data Format” menu entry within TDE. Make sure the box “Enable Value
Checking and Conversion” is checked within the menu “Window” > “Preferences”
> “Test interface Settings”.

Important: When running the test with undefined values, the initial value passed
to the test object depends on the default initialization of the compiler.

320 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Clicking into a cell activates the inline editing mode and you can enter arbitrary values:

Þ Click in a cell and press enter.

Now you are in the inline editing mode (editing mode).

Þ Enter the value.

You can navigate between the cells with CTRL + cursor left/right.

You can apply the available operations of the context menu to multiple cells depending on
the current selection within the Test Data view:

• If you select a single variable of the interface tree, all values of all test steps
for this variable will be affected.

• If you select a test step column, all variables of this test step will be affected.

• If you select an array, a struct or a union, all components of this element will
be affected.

The current selection is highlighted in blue. You need to select a test step column
before right clicking for the context menu, because the right click will not select
the test step column.

In case of union variables, the respective components can be displayed by doubleclicking

the cell (see figure 6.149).

TESSY 4.0 Manual 321

 6 Working with TESSY

Figure 6.149: Clicking in the cell opens the components

Setting defines Defines

Þ Double click in a cell or press ENTER to be in the inline editing mode.

Þ Press Ctrl + Space.

A window will open with all known defines.

Þ Choose your define with a doubleclick.

Enums Enums

Þ Click in a cell.

A dropdown menu will open showing the available enum constants (see figure
6.150.

Þ Choose any constant or click into the inline editor field to enter any other
suitable value.

322 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.150: Clicking in the cell opens the available enums

Input values

Input values are all interface elements that need to have a defined value at the beginning
of the execution of a test object. These values are included in the calculation of the output
values during test execution or will be used as a predicate of a condition.

There are three types of input values: Types of input

values
• Global and external variables, used by the test object.

• Function parameters, transferred during function call.

• Dynamic objects: They represent pointer targets, referenced through a poin-

ter of the test object interface (they are not really dynamic, variables will be
created for each one within the generated test driver).

TESSY 4.0 Manual 323

6 Working with TESSY

Vector values for advanced stub functions

External called functions can be defined as advanced stub functions to provide the return
value and the expected parameter values within the Test Data view. If a test object calls
an external function multiple times the same return value would be returned for each
invocation and also the parameters would be checked against the same parameter values
as specified within TDE. In order to provide different values for each invocation of the
advanced stub, you can enter multiple values as a vector written within braces, e.g. 1,2
(see figure 6.151). In this example the return value of the stub will be 1 for the first
call, 2 for the second call. You can also specify a vector value for the expected parameter
values.

Figure 6.151: Entering values as vector for an advanced stub

Expected values

Expected values are the calculated results regarding the input values for the test object after
test execution. TESSY will compare both expected and actual values after test execution.
The result will be either failed or passed.

Important: The values are compared with the evaluation mode equal (==).
To change the evaluation mode refer to section Entering evaluation modes.

324 TESSY 4.0 Manual

 6.8 TDE: Entering test data

There are three types of expected values: Types of

expected values
• Global or external variables: They can always be expected values as they
have a valid value after execution of a test object.

• The return value of a function.

• Dynamic objects: Referenced through a pointer that is either an input or

expected value, dynamic objects continue to be accessible after execution of
a test object. They can therefore also be expected values, just like global
variables.

Initializing test data

You can initialize all interface variables of a test step at once.

Þ Rightclick the variable and choose “Initialize Test Data. . . ” from the context
menu.

The “Initialize Values” dialog opens.

You can use following options:

option means

Pattern a pattern in hexadecimal format, i.e. 0xff

Value a specific value only

Random a range of generated values for the initialization. The random values
will adhere to the min/max limits of each interface variable type

Ignore values all input and expected values will be set to “*none*”

Initialize all all array elements will be initialized. Otherwise only visible array
array elements elements will be initialized

Table 6.193: Options of initializing values

TESSY 4.0 Manual 325

6 Working with TESSY

The following table shows the initialization values for certain data types:

type contents

Integer 0x00000000
i.e. if 0x42 is entered as pattern, all int variables will be initialized
with 0x42424242.

Float 0.0

Char the pattern or numerical value

Struct all sub components are initialized according to their type

Union the first sub component is initialized as active component

Enum the first enum constant is used as initialization value

Array all array elements are initialized according to their type if option “Ini-
tialize all Array Elements” is used

Pointers Pointers are initialized with NULL provided that they do not point to
dynamic objects

Table 6.194: Initialization values for data types

6.8.7.5 Set passing to IRRELEVANT

It is possible to set the passing direction of variables that are not needed for testing any
more to “IRRELEVANT” in the Test Data Editor. Right click the variables you want to
hide and choose “Set Passing to IRRELEVANT” in the context menu. You can undo this
by choosing “Restore Passing” in the same menu if necessary.

Figure 6.152: Passing direction set to irrelevant.

326 TESSY 4.0 Manual

 6.8 TDE: Entering test data

The chosen variable will still be displayed and marked as “[IRRELEVANT]”. When saving
the test data the passing direction of this variable is updated and the variable will no longer
appear within the Test Data view.

Important: Passing directions set to irrelevant that have been saved can only
be restored in the Test Interface Editor (TIE) (see section 6.6.4.5 Setting passing
directions).

6.8.7.6 Entering evaluation modes

Using the evaluation mode allows to specify how to compare the actual value (calculated
during the test run) with your specified expected value. The evaluation mode together
with the expected value will be used to process the test results after the test run.

The default evaluation mode is equal (==).

To enter another evaluation mode: Evaluation modes

Þ Click in a cell.

Þ Enter the desired evaluation mode within the inline editor mode (see figure
6.153).

Figure 6.153: Entering evaluation mode “unequal” within the inline editor

TESSY 4.0 Manual 327

6 Working with TESSY

The following evaluation modes are available:

evaluation written as means

mode

equal == Checks the expected value and actual value for Equality.
This is the default setting.

unequal != Checks the expected value and actual value for inequality.

greater > Checks if the actual value is greater than the expected value.

less < Checks if the actual value is less than the expected value.

greater or >= Checks if the actual value is greater or equal to the expected
equal value.

less or <= Checks if the actual value is less or equal to the expected value.
equal

range [1:10] Checks if the actual value is within a range, here: range 1 to
10.

deviation 100 +/- 1 Checks if the actual value equals the expected value but takes
100 +/- 1% into account a deviation value. The deviation can either be
an absolute value or a percentage, i.e. the following expected
values would yield OK: 99, 100, 101.

Table 6.196: Evaluation modes

6.8.7.7 Ignoring values for a test step

By default, values have to be assigned for all variables with passing directions “IN” or
“INOUT”. It can be useful to not overwrite a value calculated in the last test step. In this
case you can use the special value “*none*”:

Þ Rightclick a value and choose “Ignore Value” within the contextmenu.

328 TESSY 4.0 Manual

 6.8 TDE: Entering test data

6.8.7.8 Generating test steps automatically

You can generate test cases and steps automatically, i.e. test steps of a range of input
values which you enter in the TDE:

Þ Create a generator test case within the Test Items view as described in section
6.2.5.4 Creating test steps automatically.

Þ Switch back to the Test Data view.

Þ Enter your values and a range of an input value, i.e. [6:9] as in our example
(see figure 6.154).

TESSY can generate the test cases stepwise: Enter a semicolon and the step size
behind the range, e.g. [6:15;3] would give you the values 6, 9, 12 and 15.
You can also enter specific values, e.g. [1,5,8] would be the values 1, 5 and 8.
Combinations are as well possible: [2:8;2,11,15,20:22] would be 2, 4, 6, 8, and 11,
15, 20, 21 and 22.

Figure 6.154: Generator test case 4 has a range value from 6 to 9 for parameter v1

Þ Save your inputs with a click on in the TESSY tool bar.

TESSY 4.0 Manual 329

6 Working with TESSY

TESSY will now automatically create a test step for every value within the
range you entered (see figure 6.155).

You might need to expand or scroll the Test Data view to see all the
test steps!

Figure 6.155: Four test steps are generated for every value within the range “6 to 9”.

The test steps are read only because they were generated!

You can change the type of the test case and test steps to “normal”. That way you can
edit the test steps as usual.

To change the status to normal,

Þ switch to the Test Items view.

Þ Rightclick the test case and select “Change Test Case Type to Normal” (see
figure 6.156).

330 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.156: Selecting “Change Test Case Type to Normal”

The test case and test steps are changed to type “normal” but will indicate originally being Changing test
generated with a status within the Test Items view (see figure 6.157). case to type
normal

Figure 6.157: The test case and test steps originally being generated.

You can reverse the action with a rightclick and choose “Change Test Case Type to Gene-

TESSY 4.0 Manual 331

6 Working with TESSY

rator” from the context menu.

6.8.7.9 Changing inherited values

Inherited modules and their test objects need to be snychronized (see Creating variant
modules) to get the inherited test cases and test steps with all inherited values. The Test
Data view shows inherited and overwritten values with different colors.

Please notice the following restrictions for editing of inherited values:

• Dynamic objects will be inherited from the parent test object. Additional dynamic
objects cannot be created within the inherited test object.
• CTE test cases cannot be edited within the inherited test object. Any changes need
to be done within the parent test object.
• Inherited user code (e.g. prolog/epilog) cannot be overwritten with “empty” user
code. It is recommended to add a comment stating why the inherited usercode has
been overwritten instead.

Figure 6.158: Inherited value coloring within Test Data view

See figure 6.158 for the color coding of values displayed within Test Data view:

• Inherited values are displayed in light blue.

• New variables of the variant test object are shown like normal values without
special highlighting. The variable “border_size” was introduced within the
variant source code, therefore there are no inherited values.

332 TESSY 4.0 Manual

 6.8 TDE: Entering test data

• Overwritten values are displayed in darker blue. The value 48 is overwritten

and the tooltip will show the inherited values for such overwritten values.

• The test step 3.1 has been deleted: The inherited values are displayed for
information only. The test step will be skipped when executing the test.

• The additional test step 4.1 cannot have any inherited values. All values are
displayed as normal.

6.8.7.10 Pointers

Þ Rightclick the pointer value cell to open the context menu.

The context menu offers the following possibilities to assign a value for a pointer:

option means

Set Pointer The value of the selected pointer will be set to NULL. The text box will be
NULL filled with NULL.

Set Pointer You can select another interface element or a component of a structure or
Target union and assign its address to the pointer. The cursor will change, when
you move the mouse pointer over a variable:

The object type fits the pointers target type. You can assign the pointer.

The object type does not match the pointers target type. You cannot
assign the pointer.

When you click on an element, the variable name of that element will be
entered into the field next to the pointer. During test execution, the address
of the variable will be assigned into the input field of the pointer.

continue next page

TESSY 4.0 Manual 333

6 Working with TESSY

option means

Create pointer Allows to create a new object as target object for the pointer. The address
target value of the object will be assigned to the pointer. The type of the created object
depends on the target type of the pointer.

Þ Choose “Create Pointer Target Value” from the context menu.

Þ Enter a valid C identifier as name for the new target object.
Þ Click “OK”.

A new target object will be listed in the dynamic objects section of the TDE.

Array as It is also possible to create an array as target value using the Dimension
Target Value option of the Create Pointer Target dialog:

Þ Tick the check box for” As Array of Size” to enter an appropriate size
into the input field.
Þ Click “OK”.

The name of the new object appears in the input field of the pointer value.
TDE will create an array of the pointers target type. The pointer will point
to the first array element.
Within the Dynamics section, you will see the newly created target object.
You can enter values, like for every other interface element.

Table 6.205: Value assignments for pointers

6.8.7.11 Static local variables

Variables defined as static local variables within the test object or called functions can also
be tested. Since such variables are not accessible from outside the location where they
are defined, TESSY instruments the source code and adds some code after the variable
definition to get a pointer to the memory location of the variable. All static local variables
can only be accessed after the code containing the variable definition has been executed.
You need to keep this in mind when providing input values or checking results for such
variables. The following restrictions apply for static local variables:

• The first time when the code of a static local variable definition is executed,
the variable will get the initialization value assigned from the source code.
It is not possible to set the initial value from TESSY. You need at least one
test step to initialize the variable by executing the definition code. The next
test step can then supply an input value for the variable.

334 TESSY 4.0 Manual

 6.8 TDE: Entering test data

• The same applies for expected values: If the source code of the variable
definition has not been executed, the result value of the respective variable is
not accessible and will be displayed as *unknown* in this case. This situation
may arise when the variable definition is located within a code block which
has not been executed, e.g. within an if statement block.

6.8.8 Test Definition view

Figure 6.159: Test Definition view within TDE with linked requirement

The Test Definition view displays the test case specification, the optional description and
linked requirements of the current test case in individual input fields. The test case speci-
fication should enable the tester to provide concrete input values and expected results.

The Test Definition view is context sensitive! To display the specifications, definitions and
requirements for a test case:

Þ Select a test case within the Test Items view (see figure 6.159).

Important: The contents are not editable if the test cases have been created
and exported using the CTE!

TESSY 4.0 Manual 335

6 Working with TESSY

6.8.9 Declarations / Definitions view

Figure 6.160: Declarations/Definitions view

Within the Declarations/Definitions view you can define your own helper variables that may
then be used within the user code. If you just want to declare a variable that is already
available within linked object files, you do this within the declarations section. If you want
to create a new variable, you need to enter the declaration into the declarations section
and the respective definition into the definitions section. The variable can then be used
within the prolog/epilog and stub function code.

Important: TESSY provides the means to add new variables within the TIE
perspective (see section 6.6 TIE: Preparing the test interface). Such variables
can be used like normal interface variables of the test object which is much more
convenient than defining them here in the Declarations/Definition view.

336 TESSY 4.0 Manual

 6.8 TDE: Entering test data

6.8.10 Prolog/Epilog view

Figure 6.161: Prolog/Epilog view

Within the Prolog/Epilog view you can specify usercode that will be executed at a certain
point in time during the test execution. The C part of the usercode will be integrated into
the test driver and executed at the places specified. The following figure outlines the call
sequence of the usercode parts.

Figure 6.162: Call sequence of the usercode parts

TESSY 4.0 Manual 337

6 Working with TESSY

The figure shows the interaction of the usercode sections with the assignment of test data
provided within TDE and the result values that are saved into the test database and eva-
luated against the expected results.
During the test object call, the code specified for the stub functions (if any functions are
called from your test object) will be executed depending on the code logic of your test
object.

Within the prolog/epilog code you can reference the global variables used by your test
object that have one the passing directions IN, OUT, INOUT or EXTERN. The following
special macros are available within the prolog:

• TS_REPEAT_COUNT is a variable that controls the number of repeated

calls of the test object, the default is 1.

• TS_CURRENT_TESTCASE, TS_CURRENT_TESTSTEP contains the

current test case and test step number. This can be used to do different
things for certain test cases.

• TS_TESTOBJECT_RETURN contains the return value of the latest test

object call (if the test object has a return value). This value can be used
within evaluation macros in the test step prolog.

• TS_THIS is available for C++ methods only and allows to access members
of the current “this” object (e.g. “TS_THIS.member = 5;”).

It is recommended to define specific prolog/epilog code instead of using the macros

TS_CURRENT_TESTCASE/TS_CURRENT_TESTSTEP

Example

Have a look at figure 6.161 Prolog/Epilog view in the beginning of this section. The
test step 1.1 prolog contains the code TS_REPEAT_COUNT=2, and the Repeat Count for
this prolog/epilog section was set to 5.
The whole prolog / test object call / epilog sequence will be repeated five times and the test
object will be called twice in every repetition of this loop. Since there are 5 loops, the test
object will be called 10 times in total.

338 TESSY 4.0 Manual

 6.8 TDE: Entering test data

6.8.10.1 Defining and overwriting inherited code

In some cases it is useful to specify a common prolog/epilog for all test steps or for the
test steps of a certain test case. For this reason, you can enter prolog/epilog on test object
or on test case level. Such a default prolog/epilog will be inherited to the respective child
test steps. In this way you avoid to copy the same prolog/epilog multiple times to each
test step. Default prolog/epilog can be overwritten on test case/step level for individual
test cases/steps if desired.

Figure 6.163: TESSY provides default prolog/epilog on test object level to be inherited
to test cases and test steps

For both prolog and epilog, there are up to three tabs available, depending on the selected
object:

Test objects:

• “Test Object” - The test object’s own prolog/epilog

• “Default for Test Cases” - The default prolog/epilog that will be inherited to
all test cases of this test object

• “Default for Test Steps” - The default prolog/epilog that will be inherited to
all test steps of this test object

TESSY 4.0 Manual 339

6 Working with TESSY

Test cases:

• “Test Case” - The test case’s own or inherited prolog/epilog

• “Default for Test Steps” - The default prolog/epilog for the test steps belon-
ging to that test case

Test steps:

• “Test Step” - The test step’s own or inherited prolog/epilog

Figure 6.164: TESSY allows Prolog/Epilog being inherited from test case or test object

Important: To edit the default prolog/epilog, select the corresponding test

object or test case and edit the code via the “Default for Test Cases” and “Default
for Test Steps” tabs.

340 TESSY 4.0 Manual

 6.8 TDE: Entering test data

6.8.10.2 Entering C code

The Prolog/Epilog view provides a popup menu containing variables for convenient edi-
ting.

Figure 6.165: Prolog/Epilog functions

To show this menu,

Þ use the Usercode Outline view to mark the test case or test step for which you
want to set the usercode.

Þ Click into the Prolog or Epilog section of the Prolog/Epilog view and enter the
usercode.

Þ Press CTRL + Space or type the first letters and press CTRL + Space.
The popup menu appears (see figure 6.165), showing all available names re-
spectively the filtered list according to the characters you already typed.

Important: TS_REPEAT_COUNT is only usable within the prolog section!

TESSY 4.0 Manual 341

 6 Working with TESSY

To edit the prolog/epilog for a test case/test step,

Þ Use the Usercode Outline view to navigate and select a test case or test step
from the tree.

Þ Enter the code within the Prolog/Epilog view.

A new node will automatically appear at the corresponding place in the outline
tree (see figure 6.166).

Figure 6.166: Editing C code

6.8.10.3 Using evaluation macros

Within the test step epilog or within stub functions, you can evaluate any variable or expres-
sion using the evaluation macros. These predefined macros allow to check an expression
against an expected value. The result is stored within the test report like the evaluation
of normal output variables of the test object.
Evaluation macros can only be used within the following Usercode sections:

• test step epilog

• stub function code

Evaluation A popup menu contains all available interface variables and symbolic constants for con-
macros venient editing as well as the available evaluation macros, e.g. TESSY_EVAL_U8 for
unsigned character values:

Þ Press CTRL + Space.

342 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.167: Call the popup menu by pressing CTRL + space

Þ Select the evaluation macro for the specific data type of the variable which
shall be evaluated. The only difference of the evaluation macros is the type of
argument for the actual and expected value, see table below for a description
of the available types.

Þ Now the template can be edited.

Example: Below is an example showing the template in the second row and the edited
evaluation macro underneath.

Figure 6.168: Editing the evaluation macro templates

TESSY 4.0 Manual 343

6 Working with TESSY

Both value arguments given to the evaluation macro may be of any value that fits
the specified eval macro type. By convention, the first (left side) value should be
the actual value that shall be checked and the second (right side) value should be
the expected result. Like this you will get the same order of values within the test
report as for normal output values.

evaluation macro name C type

TESSY_EVAL_U8 unsigned, 1 byte

TESSY_EVAL_S8 signed, 1 byte

TESSY_EVAL_U16 unsigned, 2 byte

TESSY_EVAL_S16 signed, 2 byte

TESSY_EVAL_U32 unsigned, 4 byte

TESSY_EVAL_S32 signed, 4 byte

TESSY_EVAL_U64 unsigned, 8 byte

TESSY_EVAL_S64 signed, 8 byte

TESSY_EVAL_FLOAT float

TESSY_EVAL_DOUBLE double

TESSY_EVAL_LONGDOUBLE long double

Table 6.217: Available types of evaluation macros

operator meaning

== equal

!= unequal

< less

continue next page

344 TESSY 4.0 Manual

 6.8 TDE: Entering test data

operator meaning

> greater

<= less or equal

>= greater or equal

Table 6.218: Operators of evaluation macros

Each invocation of an evaluation macro results in an additional entry within the test report.
All evaluation macros will be added to the list of actual/expected values of the current test
step. The results will be displayed within the Usercode Outline view and the Evaluation
Macros view.

It is possible to format the output of the evaluation macros as binary value, decimal or
hexadecimal (default setting) by appending one of the following format specifiers at the
end of the evaluation macro name:

binary %bin, e.g. “Value printed as bin%bin”

decimal %dec, e.g. “Value printed as dec%dec”

hexadecimal %hex, default setting.

The report shown below contains all possible evaluation macro name formats. The format
specifier itself will be omitted within the final evaluation macro name.

Figure 6.169: Formatting of evaluation macro values

TESSY 4.0 Manual 345

6 Working with TESSY

6.8.11 Stub Functions view

Figure 6.170: Stub Functions view without contents

The Stub Functions view displays the code for all stub functions. Normally all stub code
is defined on test object level.

In the Stub Functions view you can insert stub code for test steps, test cases, and test ob-
jects. The code fragments will be be combined into a single stub funktion implementation
and will be called in the order as shown in figure 6.171. If you don’t want to execute the
parent fragments for specific test cases or test steps, you need to add a return statement
within the respective stub code fragment.

Figure 6.171: Test execution direction using stub code

346 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Important: Stub code must be provided for all non-void stub functions in
order to return a valid value as result of the stub function call. If there are stub
functions without stub code, the test execution will be aborted with an error. If
the return value of a stub function is not used by the test object, you should add
at least a comment here.

Please note the error icon at the stub function name in figure 6.170 indicating that stub
code is missing. You can switch off this check by unchecking the respective test execution
preference. This preference setting will be stored within the preferences backup file as
described within Windows > Preferences menu.

Figure 6.172: TESSY Preferences: Abort on missing stub code

6.8.11.1 Using Stub Functions

Within the stub function code you can reference the parameters passed to the stub function
and also global variables used by your test object. The following special macros are available
within the stub body:

• TS_CALL_COUNT contains the number of calls to this stub function for

the current test step. This count will restart from one for each test step.

• TS_CURRENT_TESTCASE, TS_CURRENT_TESTSTEP contains the

current test case and test step number. This can be used to provide dif-
ferent values for certain test cases.

TESSY 4.0 Manual 347

6 Working with TESSY

Figure 6.173: Stub Functions view with code using TS_CALL_COUNT macro

It is recommended to define test case/step specific stub code instead of using the
macros TS_CURRENT_TESTCASE/TS_CURRENT_TESTSTEP.

Example for the use of test object, test case and test step specific stub code:

Figure 6.174: Stub Code Levels in the Usercode Outline view

If only stub code of e.g. the test step should be executed, you need to set a return at the
end of the inserted code on test step level. If only stub code of the test step and the test
case should be executed, you need to set a return at the end of the inserted code on test
case level. Stub code on test module level will be overwritten.

It is recommended to read the sections Usercode Outline view and Prolog/Epilog

view to fully understand the handling of stub code.

348 TESSY 4.0 Manual

 6.8 TDE: Entering test data

TESSY will automatically generate the code to execute a test including all the stub code
you inserted in the Stub Functions view. Below you can see brief examples of inserted
stub code on test object level, test case level and test step level on the left along with the
automatically generated code resulting from that on the right.

Figure 6.175: Stub code examples on test object, test case and test step level

In the automatically generated test code (see figure 6.176) you can recognize the test
execution direction as shown in figure 6.171.

TESSY 4.0 Manual 349

6 Working with TESSY

Figure 6.176: Automatically Generated Test Code

For more information about the Usercode Outline view and navigating within the test items
see section Usercode Outline view.

6.8.12 Usercode Outline view

Figure 6.177: Usercode Outline view

The Usercode Outline view displays the usercode and stub function code that will be exe-
cuted at a certain point in time during the test execution and that you just defined in the
Prolog/Epilog view or Stub Functions view. Use this view to navigate within the test items
when editing prolog/epilog or stub function code.

The view shows entries for each location where usercode is defined. Click on a test case
or test step to see the inherited stub function code for the selected test item.

350 TESSY 4.0 Manual

 6.8 TDE: Entering test data

Figure 6.178: Usercode Outline view showing inherited stub code

The Stub Functions view shows the stub code to be executed for the test step 1.1 that is
currently selected within the Usercode Outline view. Please note the hint within the text
field title indicating that the stub code is inherited from the test object level.

Figure 6.179: Usercode Outline view showing inserted stub code

Now there is an inserted stub function code entry selected within the Usercode Outline
view. The entry indicates that the stub code is inserted for test step 2.1 which is also
indicated within the text field title.

6.8.13 Plots view

Important: In TESSY version 3.2 and higher the single Plots view has split in
two separate views, the Plots view and the Plot Definitions view!

TESSY 4.0 Manual 351

6 Working with TESSY

Figure 6.180: Plots view

The Plot view displays the included test items and chart(s) for a plot selected in the Plot
Definitions view. The number of different charts per plot depends on the plot mode:

• test case plot: one chart for all included test items

• test step plot: one chart per included test case

• array plot: one chart per included test step

For test step and array plots the chart can be selected by navigating the test item tree.

Important: If you use other evaluation modes than equal (e.g. <, <=, >,
>=, !=, [Range]), it is not possible to display the expected values within the plot
chart. Displaying the expected values is only possible when using the evaluation
mode == (equal). See section 6.8.7.6 Entering evaluation modes.

6.8.13.1 Test Item Tree

The test item tree on the left-hand side of the Plot view shows all test items included in
the selected plot, as defined in the Plot Definitions view via the “Set Included Test Items”
command.
This tree is for navigating the different charts of a plot, if there is more than one chart
available.

352 TESSY 4.0 Manual

 6.8 TDE: Entering test data

6.8.13.2 Chart

The chart displays the values of the variables included in the selected plot. The values are
color-coded:

• Yellow line: Input values

• Blue line: Expected values

• Green line: Actual values

• Red cross: Failed values

For expected values, dotted blue lines represent the upper and lower bound of expected
values such as 10 ± 5.

Only variables that have “Use in Report” checked in the Plot Definitions view are shown in
the chart. Selecting a variable in the Plot Definitions view will highlight the corresponding
value series in the Plot view.

6.8.14 Plot Definitions view

The Plot Definitions view allows creating and configuring plots from within the TIE and
TDE perspective. For details refer to section 6.6.5 Plot Definitions view within chapter
TIE: Preparing the test interface.

TESSY 4.0 Manual 353

6 Working with TESSY

6.9 CV: Analyzing the coverage

Figure 6.181: Perspective CV - Coverage Viewer

The Coverage Viewer (CV) displays the results of the coverage measurement of a previously
executed test, which is either

• an overall instrumentation for your whole project, which you selected in

the preferences menu of TESSY (see section 6.1.4 Windows > Preferences
menu), or

• an instrumentation which you selected within the Properties view for your
module or test object under test (see section 6.2.3.4 Coverage tab), or

• an instrumentation which you selected for your test run (see section 6.2.2.6
Executing tests).

The available information displayed and the sub windows shown within the CV depends
on the coverage options selected during the test run. The CV will be updated with the
coverage information of the currently selected test object whenever you switch to the CV
or when you select another test object within the Test Project view.

354 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.1 Structure of the CV perspective

pane location function

(default)

Test Project view upper left Same view as within the Overview perspective.

Called Functions middle left Contains the test object itself and the functions called
view from the test object.

flow chart view upper Displays the graphical representation of the control struc-
middle ture of the currently selected function (only displayed
when a coverage mesurement was selected for a test run!).

Coverage views upper / Displays the results for the selected coverage instrumen-
middle tation.
right

Code view lower pane Displays the source code of the currently selected function
(and highlighting selected decisions/branches).

Report views lower pane Displays the ASCII based coverage summary reports for
the selected instrumentation.

Table 6.224: Structure of CV

6.9.2 Instrumentation for coverage measurements

TESSY supports the following coverage measurements:

• C0 (Statement Coverage)

• C1 (Branch Coverage)

• MC/DC (Modified Condition / Decision Coverage)

• MCC (Multiple Condition Coverage)

• DC (Decision Coverage)

• EPC (Entry Point Coverage) - only for unit tests

• FC (Function Coverage) - only for component tests

TESSY 4.0 Manual 355

6 Working with TESSY

For more information about coverage measurements and usage of coverage ana-
lysis refer to the application note “Coverage Measurement” in TESSY (“Help” >
“Documentation”).

There are no views for the Entry Point Coverage (EPC) and the Function Coverage
(FC)! The results are displayed only within the Test Overview Report (see section
6.2.2.11 Creating reports) or the Test Project view (see figure 6.182).

Figure 6.182: Results of the EPC are displayed within the Test Project view

356 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

The following figure 6.183 displays a component test with a Function Coverage instrumen-
tation result (amongst others).

Figure 6.183: Coverage results within the CV perspective (component testing)

Please notice:

• If you move the mouse over the result within the Test Project view, the percentage
of the coverage for the respective item will be displayed.
• The Called Functions view displays the coverage result for every function.

TESSY 4.0 Manual 357

 6 Working with TESSY

6.9.3 Test Project view

Figure 6.184: Test Project view within the CV perspective

6.2.2 Test The Test Project view displays your test project which you organized within the Overview
Project view
perspective.

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

After a test run you will see columns being added to the Test Project view for each ap-
plied coverage measurement. The coverage icons provide an overview about the reached
coverage for each test object as well as cumulated for modules, folders and test collecti-
ons.

358 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.4 Called Functions view / Code view

Figure 6.185: Called Functions view

The Called Functions view contains the test object itself and all called functions of the test
object. It displays the achieved coverage of the current test run. By clicking on a function,
you can review the source code within the Code view and see the code structure within
the flow chart view.

To highlight the source code within the code view:

Þ Click on (Toggle Code Coverage Highlighting) in the tool bar of the Code
view.

The statements, branches or conditions of the source code will be marked

within the Code view according to the selected coverage measurement. If the
respective code location have been covered successfully, i.e. 100% coverage
has been reached for this code part, it will be marked in green. Otherwise
the code location will be marked in red indicating that it has not been fully
covered.

To highlight a specific code location:

Þ Select an element within the Flow Chart view.

The respective source code lines will be marked within the Code view.

TESSY 4.0 Manual 359

6 Working with TESSY

To have a quick overview of the coverage:

Þ Within the Called functions view move the mouse over the function.

All the coverages will be displayed (see figure 6.185).

6.9.5 Flow Chart view

Figure 6.186: Flow Chart view

The flow chart view displays the code structure and the respective coverage in graphical
form.

You might want to learn the functions of the flow chart view with an easy example:
Consult section 5.1.10 Analyzing the coverage of the Practical exercises.

360 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.5.1 Icons of the view tool bar

icon action / shortcut / comment

Searches the next uncovered decision.

Searches the previous uncovered decision.

Searches the next unreached code branch.

Searches the previous unreached connection.

Zooms out.

Zooms in.

Table 6.231: Tool bar icons of the Test Items view

6.9.5.2 Viewing functions

To display a flow chart of a function:

Þ Click on a function within the Called Functions view.

The code structure of the function will be displayed in the flow chart view.

Zoom in or out using the tool bar icons or the entries from the chart menu.

Within each flow chart, you will see the branches and decisions of the function being Viewing
displayed in green and red colors, which indicates whether the respective decision has been Functions
fully covered or the respective branch has been reached:

green = 100 % coverage

red = less than 100 % coverage: at least one condition combination was not executed

If none of DC, MC/DC or MCC coverage has been selected for the last test execution, the
decision elements remain grey, but they are still selectable in order to find the respective
line of code in the source code view.

TESSY 4.0 Manual 361

6 Working with TESSY

The following elements are displayed within the flow chart of the CV:

if decision

The if branch on the left side was not re-

ached, the else branch on the right side was
reached three times. The decision was not fully
covered.

for or while loop

The loop body was not reached, instead

the exit out of the loop was executed once. The
loop decision was not fully covered.

switch statement

The first case branch was reached once,

the second case branch and the default branch
were not reached.

do while loop

The loop body was only reached once (without

repeated execution of the loop body branch)
and the exit branch was reached. The loop
decision was not fully covered.

Table 6.233: Elements of the Flow Chart view

362 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.5.3 Selecting elements

You can select decisions, branches and code statement elements within the flow chart. The
respective code section will then be highlighted within the source code view. Since not all
connection lines within the flow chart are branches in terms of the C1 branch definition,
some of the connection lines may not be selectable.

If an element (e.g. the ? operator and statements containing boolean expressions) also
appears in green or red, the element contains sub flow charts that can be visualized with
a right click on the respective element. CV will insert a new tab for the condition.

6.9.5.4 Searching for uncovered decisions and unreached branches

The CV provides search functionality for decisions and branches that are not fully covered
respectively reached through all the executed test cases. The decisions and branches are
already marked in red, but the search function can assist in finding all uncovered decisions
or unreached branches.

Þ Select the respective icon from the tool bar (i.e. ).

The chart will change into the search result mode, marking the found element
in blue.

Figure 6.187: Unreached code branch is marked blue

TESSY 4.0 Manual 363

6 Working with TESSY

6.9.6 Statement (C0) Coverage view

Figure 6.188: Statement coverage

The Statement (C0) Coverage view displays the statement coverage for each individual
test case and test step as well as the total coverage for all test cases (and test steps). The
coverage information in this view is calculated for the selected function within the Called
Functions view.

If you selected only the C0 coverage instrumentation for test execution, you will see the
code branches marked in red and green within the flow chart; “else” branches, that do not
exist within the code, will be displayed in the Flow Chart view in grey.

Also the loop branches of while, for and do statements that are irrelevant for C0 coverage
will be displayed in grey.

The flow chart shows code branches and not individual statements and also blocks of
statements will be shown as one block instead of individual items for each statement.

364 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

If you select individual test cases or test steps within the test case list, the respective
statements covered by those test steps will be marked within the flow chart, i.e. the
code branch containing these statements will be marked. This allows finding out the
execution path of the selected test step. By selecting multiple test steps, review the
resulting cumulated statement coverage within the flow chart. The total coverage number
will also be updated with the C0 statement coverage for the selected test cases / test
steps.

6.9.6.1 Coverage percentage

The coverage percentage is the relation between the total numbers of statements of the
currently selected function compared to the number of reached statements. This coverage
calculation includes the currently selected test cases and test steps within the test case
/ test step list (see figure IsValueStatementCoverageC0-1). By default, all test cases are
selected when opening the CV.

6.9.7 Branch (C1) Coverage view

Figure 6.189: Branch coverage

TESSY 4.0 Manual 365

6 Working with TESSY

The Branch (C1) Coverage view displays the branch coverage for each individual test case
and test step as well as the total coverage for all test cases (and test steps). The coverage
information in this view is calculated for the selected function within the Called Functions
view.

If you selected only the C1 coverage instrumentation for test execution, you will see only
the C1 branches marked in red and green within the flow chart.

If you select individual test cases or test steps within the test case list, the respective
branches covered by those test steps will be marked within the flow chart. This allows
finding out the execution path of the selected test step. By selecting multiple test steps,
review the resulting cumulated branch coverage within the flow chart. The total coverage
number will also be updated with the C1 branch coverage for the selected test cases / test
steps.

6.9.7.1 Coverage percentage

The coverage percentage is the relation between the total numbers of branches of the
currently selected function compared to the number of reached branches. This coverage
calculation includes the currently selected test cases and test steps within the test case /
test step list. By default, all test cases are selected when opening the CV.

6.9.8 Decision Coverage view

Refer to the description of the MC/DC Coverage view. The only difference is the calculation
according to the definition of the decision coverage.

366 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.9 MC/DC Coverage view

Figure 6.190: MC/DC coverage view

The MC/DC Coverage view displays the coverage of the currently selected decision within
the flow chart view (see figure 6.190). If no decision is selected (as initially when starting
the CV), the MC/DC Coverage view is empty.

When selecting a decision, the respective combination table according to the MC/DC
coverage definition will be displayed within the MC/DC-Coverage view (see figure 6.191).

TESSY 4.0 Manual 367

6 Working with TESSY

Figure 6.191: MC/DC coverage

The combination table contains all atomic conditions of the decision. The conditions are
the basic atoms of the decision which remain after removing the or, and and not operators
from the decision. TESSY calculates the MC/DC set of true/false combinations of the
condition atoms that fits best to the test steps executed during the test run.
The last table column contains the test step that caused the execution of the decision with
the true/false combination of the respective table row. If one or more of the condition
combinations were not reached during the test run, the test step column of those rows will
be marked in red.

368 TESSY 4.0 Manual

 6.9 CV: Analyzing the coverage

6.9.9.1 Selecting decisions

Þ Select a decision by clicking on the respective control flow element within the
flow chart view.

The code fragment will be marked within the source code view.

The decisions are either green or red depending on the degree of coverage. If no coverage
information is available, i.e. when you ran the test without any of DC, MC/DC or MCC
instrumentation selected, the decisions within the flow chart will appear in grey and the
Coverage view will not be available (N/A).

6.9.10 MCC Coverage view

Refer to the description of the MC/DC Coverage view. The only difference is the calculation
according to the definition of the MCC coverage.

6.9.11 Coverage Report views

There are up to five coverage reports available depending on the instrumentation mode
selected for test execution. They contain the summarized coverage information of the last
test execution:

• The statement (C0) coverage report contains some meta information (e.g.
number of statements, reached statements, total statement coverage) and
the source code of the test object.

• The branch (C1) coverage report contains some meta information (e.g. num-
ber of branches, reached branches, total branch coverage) and the source
code of the test object.

• The decision coverage report lists all decisions of the test object code inclu-
ding the coverage tables with the respective decision condition combinations.

• The MC/DC coverage report lists all decisions of the test object code inclu-
ding the coverage tables with the respective MC/DC condition combinations.

• MCC coverage report also lists all decisions of the test object code including
the coverage tables with the respective MCC condition combinations.

TESSY 4.0 Manual 369

6 Working with TESSY

6.10 IDA: Assigning interface data

Figure 6.192: IDA perspective

For coherent testing it is essential to realize changes of the interface of test objects and to
re-execute previously passed tests to assure that any changes of the source do not cause
the previous passed tests to fail. This is often summed up with the keywords “regression
testing”.

If the interface of a test object changes, TESSY will indicate the changes with specific
status indicators at the test object icon. With the Interface Data Assigner (IDA) you can
assign the elements of a changed (new) interface to the respective elements of the old one
and start a reuse. The reuse operation will copy all existing test data to the newly assigned
interface elements.

To appropriately react to changes, TESSY needs to know the current structure of the
interface. Therefore it determines for each module the available functions and their
interfaces by analyzing the source code. This information is stored in the interface
database so that TESSY knows about any changes and can keep track of test data
assignments made for a whole module or just for individual test objects.

370 TESSY 4.0 Manual

 6.10 IDA: Assigning interface data

6.10.1 Structure of the IDA perspective

pane location function

(default)

Test Project view upper left Displays your test project. For editing your test project
switch to the Overview perspective.

Properties view lower left Displays the properties of your test project, e.g. sources to
the test object.

Compare view right Displays two interfaces, either of the same test object (old
and new interface) or of different test objects. You can
assign the changes by drag & drop.

Table 6.237: Structure of the IDA perspective

6.10.2 Status indicators

The following test object status indicators are relevant when reusing test data.

indicator status / meaning

The test object has changed. You see these test objects, but there is no operation
possible. You have to start a reuse operation.

The test object is newly available since the last interface analysis. You have to
add test cases and test steps and enter data for a test.

The test object has been removed or renamed. You still see these test objects,
but there is no operation possible. You have to assign this test object to any other
and start the reuse operation.

Table 6.238: Status indicators of test objects

6.10.3 Test Project view

The Test Project view displays your test project which you organized within the Overview 6.2.2 Test
Project view
perspective.

TESSY 4.0 Manual 371

 6 Working with TESSY

Important: We recommend to do any changes of the test project structure

within the Test Project view of the Overview perspective. The view layout of this
perspective is optimized for this purpose!

6.10.4 Properties view

The Properties view displays all the properties which you organized within the Overview
6.2.3 perspective. Most operations are possible.
Properties view

For changing a source switch to the Properties view within the Overview perspective.

6.10.5 Compare view

The Compare view shows two versions of an interface depending on the TESSY objects
selected for comparison:

• For a single module or test object, it shows the old interface on the left side
and the new interface on the right side.

• When assigning two different modules or test objects, it shows the interface
of the source object on the left side and the interface of the target object on
the right side.

Figure 6.193: Compare view

372 TESSY 4.0 Manual

 6.10 IDA: Assigning interface data

The Compare view will be used for reuse operations of whole modules or individual test
objects as well as when assigning test data from one test object (or module) to another
test object of the same or different module.

6.10.5.1 Comparing interfaces and assigning changes

Within the Compare view you can see the old interface of our test object and the new
one. The red exclamation mark within the new interface indicates the need to assign this
interface object before starting the reuse.
The title of the view shows the old name versus the newly assigned name.

To assign changes:

Þ Use the context menu or just drag and drop from the left side (see figure
6.194).

The red exclamation mark turns to a green check .

Figure 6.194: Use drag and drop in IDA

TESSY 4.0 Manual 373

6 Working with TESSY

You can assign single functions and just commit the assignments for this function
(the other functions will stay in state “changed” and can be reused later). Or you
can assign and reuse whole modules (which is convenient when there are just little
changes within the function interfaces.

To commit assignments:

Þ Click on (Commit) in the menu bar of the Compare view.

The data of all test cases and test steps will be copied from the old interface to the current
test object interface. The test object changes to yellow to indicate that all test cases
are ready to be executed again. If there are missing test data within the new interface
(e.g. due to additional variables being used by the test object), the icon will show an in-
termediate test object state . In this case you need to add any missing test data within
the test data editor.

Please notice the following habits:

• Removed and changed test objects require a reuse operation before you can further
operate on them.
• Unchanged test objects have been automatically reused when opening a module, i.e.
they will be ready to use without further activities required.
• Removed test objects will only be displayed as “removed”, if they did contain any
test cases and test steps.

6.10.5.2 Assigning test cases to other test objects

You can use the IDA to assign test cases from one test object to another test object
within the current project. Both test objects can be either from the same or from different
modules. It is also possible to assign the contents of whole modules to other modules.

Important: When assigning test cases to another test object, the target test
object contents will be overwritten completely!

374 TESSY 4.0 Manual

 6.10 IDA: Assigning interface data

To assign test cases to another test object:

Þ Change to the IDA perspective.

Þ At first drag the target test object into the right side of the Compare view (or
placeholder view).

Þ Secondly drag the source test object into the left side of the Compare view.

Þ Assign the interfaces to your needs. Variables that cannot be assigned can
be left out of scope (they will just not be used). Additional variables of the
target test object that cannot be assigned from the source test object will be
left empty after the assignment.

To commit assignments:

Þ Click on (Commit) in the menu bar of the Compare view.

The data of all test cases and test steps will be copied from the source test object to
the target test object. The target test object changes to yellow if every variable of
the interface could be assigned from the source test object. Otherwise it will display an
intermediate test object state indicating that only parts of the test data are available.

TESSY 4.0 Manual 375

6 Working with TESSY

6.11 SCE: Component testing

The component test feature is only used for integration testing. You do not need
this feature for unit testing.

Figure 6.195: Perspective SCE - Scenario Editor

The component test feature within TESSY supports testing of several functions (repre-
senting the software component) that interact with themselves as well as with underlying
called functions (of other components). The main difference to unit testing of individual
functions is the focus of testing on the external interface of the component instead of in-
ternal variables or control flow. You should be familiar with the overall usage of TESSY for
the normal unit testing. Some features like usercode and stub functions are still available
for component testing, but the respective editors will be found at different locations.

The component test feature allows creating calling scenarios of functions provided by a
software component. Within these scenarios, the internal values of component variables and
any calls to underlying software functions can be checked. TESSY provides the Scenario
Editor (SCE) for this purpose. All scenario-related inputs are available through the SCE.
Instead of having individual test objects and test cases for the component functions, the
component test itself provides a special node called “scenarios” seen as one test object. The
test cases belonging to the scenarios node are the different scenarios for the component.

376 TESSY 4.0 Manual

 6.11 SCE: Component testing

Within one scenario, you can set global input variables, call component functions, check
the calling sequence of underlying software functions and check global output variables.
The content of each scenario may be divided into the following parts:

• setting the input variables

• calling component functions

• checking calls to underlying functions

• setting/checking variables during scenario execution

• executing usercode and eval macros

• checking the output variables

The Usercode Editor (UCE) is not available for component testing, because the prolog/e-
pilog code and definitions/declarations sections can be edited directly within the SCE. You
will find C-code fragments that can be added into the scenario control flow. Also the code
for stub functions can be edited directly within SCE.

6.11.1 Creating component tests

The component test management is based on TESSY modules alike a unit test. In contrary
to unit testing you will probably use multiple source files instead of only one file. Other
parts of the testing process stay basically the same:

Þ Create a new module as described in section 6.2.2.3 Creating tests.

Þ Include all the source files, include paths and defines necessary to analyze the
source code of the component.

Þ Activate “Component” as kind of test (see figure 6.196).

As environment the default GNU GCC compiler is used. This means the component
tests will be executed on the Windows PC, using the microprocess of the PC as
execution environment. If you use a cross compiler for an embedded microcontroller,
you run the tests either on the actual microcontroller hardware or on a simulation
of the microcontroller in question.

TESSY 4.0 Manual 377

6 Working with TESSY

Figure 6.196: Component test

In contrast to normal unit tests, you will only see one special test object called
“Scenarios” (see figure 6.197).

Figure 6.197: Scenarios of a component test

378 TESSY 4.0 Manual

 6.11 SCE: Component testing

6.11.2 Preparing the test interface

The interface of the component is a summarized interface of all the non-static component
functions:

Figure 6.198: Interface of the scenarios

The External Functions section marked with the icon lists the interface to the under-
lying software functions, if any external function is called from the component. These
external functions can be replaced by stub functions like within the normal unit test. The
Component Functions section marked with the icon lists all the component functions,
i.e. the functions visible from outside the component. Local static functions will not be
listed here. The meaning of the status indicators for component functions is as follows:

status status / meaning

indicator

Function is not used for component test.

The variables used by this function are not available within the component
test interface of the scenario. These variables are set to IRRELEVANT.

The variables used by this function will be available within the scenario and
the passing direction may be adjusted.

continue next page

TESSY 4.0 Manual 379

6 Working with TESSY

status status / meaning

indicator

Table 6.248: Status indicators of the Interface view of a component test

6.11.3 Configuring the work tasks

The time based scenario description within SCE is based on time steps that represent
the cyclic calls to a special handler function of the component. Such a handler function
controls the behavior of a time-sliced component implementation.
The handler function needs to be selected as work task prior to executing any scenarios:

Þ Select the desired function.

Þ Click on (Set as Work Task) in the tool bar.

The icon of the function will change from to (see figure 6.199).

Figure 6.199: Two component functions were set as work task within the Component
Functions view

You can select one or more of the component functions.

You can select several component functions as work tasks. This will be useful
when testing several components together which all have a handler function.

The Work Task Configuration view allows more detailed settings for the work tasks.

380 TESSY 4.0 Manual

 6.11 SCE: Component testing

Figure 6.200: Work Task Configuration view

You can drop component functions directly into this view to configure them as work tasks.
The view provides the following global settings:

• Time Unit (default is “ms”) which is just the display representation to be

used within the GUI and reports.

• Mode Variable Name (not used by default) which optionally provides calling
the work tasks depending on the value of the selected variable. All scalar
variables can be selected here.

For each work task, you can specify the following settings:

• Start Time: Determines the point in time where this work task shall be called
the first time for each scenario. The default is 0 ms which causes the work
task being called immediately starting with the first time step.

• Cycle Time: Determines the elapsed amount of time after which the work
task shall be called again. The default is 10 ms which causes the work task
being called for every 10 ms time step.

• Mode: If a global Mode Variable Name is selected, you can specify for which
value of this variable the respective work task shall be called. During test
execution, this work task will only be called within its specified start and
cycle time, if the mode variable has the specified value.

The order of appearance within the Work Task Configuration view reflects the actual calling
sequence of the work tasks for each time step of the scenario. You can reorder the work
tasks via drag and drop.

TESSY 4.0 Manual 381

6 Working with TESSY

Another global setting is the calculated cycle time which depends on the cycle times of
the given work tasks. It will be calculated automatically from the cycle times of the given
work tasks.

Figure 6.201: Calculated cycle time

Within the example in figure 6.201, the resulting global cycle time (i.e. the step width of
the time steps of the scenarios) will be 10 ms, because this is the greatest common divisor
of all the given work task cycle times (i.e. 20 and 50 ms in this example).

6.11.4 Designing the test cases

Testing a component requires a set of scenarios that stimulate the component and check
the behavior of the component. Such a scenario contains calls to component functions
and other possible actions and expected reactions of the component. A scenario can be
seen as a test case for the component. Therefore, TESSY displays the list of scenarios
within the Test Item view like normal test cases but with a different icon. There are two
possibilities for creating scenarios: Either by creation them ad hoc or by developing them
systematically using the classification tree method supported by CTE within TESSY.

After synchronizing the CTE test cases there will be the respective number of scenarios
within TESSY. You can add additional scenarios using the context menu within the scenario
list. To edit the scenario, start the scenario editor SCE. The (empty) scenarios will be
displayed within SCE providing the specification and description of the designed scenario
test cases.

382 TESSY 4.0 Manual

 6.11 SCE: Component testing

6.11.5 Editing scenarios

Any scenario has two different tasks to fulfill:

• The stimulation of the component like any external application would do it.
This includes normal behavior as well as abnormal behavior which should
check the error handling of the component.

• Checking the reaction of the component caused by the scenario stimulation.

We will examine the different possibilities to check expected behavior of the component
under test. There are at least the following methods available:

• Checking return values of component functions called while stimulating the

component.

• Checking the values of global variables (of the component).

• Checking the calling sequence of underlying external functions of the com-

ponent. This would check the interface to any underlying components used
by the component under test.

• Checking parameters of calls to underlying external functions (implemented

as stub functions).

• Providing return values from calls to underlying external functions (imple-

mented as stub functions) to the component.

The following sections describe the required settings for the above mentioned check met-
hods.

6.11.5.1 Adding Function Calls

Stimulating calls to component functions or checking of calls to underlying external functi-

ons can be added to time steps:

Þ Drag and drop the functions from the component functions onto the desired
time step (see figure 6.202).

TESSY 4.0 Manual 383

6 Working with TESSY

Figure 6.202: Adding Function Calls

There are some settings required for the function calls depending on the kind of function:

• component function: Parameter values need to be provided.

• component function: The return value has to be checked directly (for scalar
types) or assigned to a variable for later evaluation.

• external called function: The expected time frame of the call to these functi-
ons needs to be specified. This defines the time range starting from the
current time step, where a call to this function is rated as successful with
respect to the calling sequence.

6.11.5.2 Entering test data for time steps

You can set input values or check output values of any variable at every time step of the
scenario. According to your settings within TIE you have access to all variables available
within the component interface. The test data can be entered within the Test Data view
of the scenario perspective. When you select a time step, the Test Data view provides a
column named like the time step for entering either new test data values or editing existing
ones (see figure 6.203)

384 TESSY 4.0 Manual

 6.11 SCE: Component testing

Figure 6.203: The Test Data view of ’Scenarios’

The Test Data view provides most of the editing features like for the normal unit testing.
After entering any values, the icon of the respective time step will change indicating the
test data status. The Test Data view shows columns for all time steps that contain test
data plus one column for the currently selected time step.

Time step indicator icons for test data (see also figure 6.204):

• Grey indicator: Some input values are assigned but some are still missing and
need to be provided. Select “*none*” for input values of time steps that you
do not want to assign.

• Yellow indicator: At least all input values are assigned for this time step. The
output values do not need to be assigned to execute a scenario.

Figure 6.204: Indicator icons for the test data

TESSY 4.0 Manual 385

6 Working with TESSY

Important: All time steps with test data need to have a yellow indicator before
the scenario can be executed!

The icon of the scenario will change to yellow if there are no more time steps with a grey
indicator.

6.11.5.3 Checking return values of component functions

When dragging component functions into the scenario, you need to provide the parameter
values. For scalar values, you can simply add decimal or floating point numbers depending
on the type of variable. You can also provide a symbolic name of a variable with the
corresponding type. This name will be added into the test application without any checking.
If the symbolic name does not exist, there will be error messages when compiling the test
application. Either provide a value (for scalar return value types) or specify the symbolic
name of a variable which the return value shall be assigned to (in this case, the variable
provided should be of the same type like the return value type).

6.11.5.4 Checking the calling sequence

The calling sequence of calls to underlying external functions may be checked on an abstract
level within the scenario. Not the absolute calling sequence will be evaluated, but the
existence of function calls within a given period of time within the scenario. This provides
a robust mechanism for call trace checking that ignores the internal implementation of the
component. How does it work? You specify the following information within the scenario
for each expected function call:

• The time step where you expect the call at the earliest.

• The number of expected consecutive calls to the function (default is 1).

• Optionally a period of time (the time frame) from that starting point where
the invocation of the function call is still successful with respect to the ex-
pected behavior of the component.

Both these settings are available for each expected call to an external function. The time
frame is zero by default indicating that the expected function call shall take place within
the same time step.

386 TESSY 4.0 Manual

 6.11 SCE: Component testing

If you specify the time frame as 60 like within the example above, this indicates that
the expected call could take place within time step 20ms, 30ms or up to 80ms to be
successful.

The exact sequence of the calls to those functions will not be examined, any of them
may be called within the given time frame interval. The report shows the result of the
evaluation of the call trace for the example above. The actual call trace entry contains the
time step where this call occurred, the expected call trace entry shows the expected time
frame period.

The following table shows the possible evaluation results for the call trace of the example
calls to function crossed_50() and crossed_75().

time step Result for call to Result for call to cros-

crossed_50() [40 ms] sed_75() [40-80 ms]

40ms ok ok

50ms failed ok

60ms failed ok

70ms failed ok

80md failed ok

90ms failed failed

Table 6.258: example: possible evaluation results

If you need to check the exact calling sequence, you should set the time frame to zero.
Other functions called in between the expected function calls are ignored. On the other
hand, the time frame provides you with a powerful way to describe expected behavior of
the component without knowing details about the exact implementation.

6.11.5.5 Checking if a function is not called

You may check that a function is not called within a given time interval. The example
below checks that the function crossed_75()is not called within 100ms after the stimulation
of the component by setting the expected call count to zero.

TESSY 4.0 Manual 387

6 Working with TESSY

Figure 6.205: A function is not called

The crossed icon shows the special value of the expected call count, indicating a check
that the function shall not be called.

6.11.5.6 Checking stub function parameters

Because called external functions need to be replaced by stub functions, you can check
the parameter values like during unit testing, depending on the type of stub function you
choose.

For more information refer to section 6.6.4.8 Defining stubs for functions.

6.11.6 Executing the scenarios

After implementing and editing the scenarios within SCE, execute the scenarios:

Þ Select the desired scenario test cases and execute the test using the Execute
Test button within the toolbar.

388 TESSY 4.0 Manual

 6.12 Backup, restore, version control

6.12 Backup, restore, version control

With TESSY you can easily backup modules into a directory and check in into a version
control system. Modules can also be restored from that directory which facilitates checking
out modules from the version control system onto another computer and restoring the test
database.

You can backup individual modules, folders or whole test collections. The backups will be
stored as TMB files. Restoring the files is either possible within the original folder or as
well from another location.

6.12.1 Backup

Þ In the menu bar select “File” > “Database Backup” > “Save. . . ”.

The Save Database dialog will be opened with your module already selected
(see figure 6.206).

Figure 6.206: Save Database dialog

Þ Decide, which modules you want to save by either selecting them separatly or
pressing the button “Select All”.

Þ Decide, if you want to save the coverage settings, test report options or dialog
settings from the Windows > Preferences menu.

TESSY 4.0 Manual 389

 6 Working with TESSY

Þ If you have linked your test cases with any requirement documents, you can
choose to save the referenced requirement documents as well. In this case the
requirements will be saved within the TMB file.

Þ Click “OK”.

Backup

The “Backup Folder” displays the backup directory of the current project. We
recommend to use this directory for any backup and restore operations.

Figure 6.207: Files of the backup

For each module there will be a file named like the path to the module starting from
the test collection. The file name will be escaped using URL encoding which replaces for
instance the space character with a “%20”. The preferences are stored within separate files
within the “preferences” subdirectory.

6.12.2 Restore

6.12.2.1 Restore into the original location

Þ Select “File” > “Database Backup” > “Restore. . . ”.

The Restore Database dialog will be opened.

Þ Select the directory with the backup.

The box “Modules” now shows the hierarchy of modules that can be restored
from the given TMB files within the backup directory (see figure 6.208).

390 TESSY 4.0 Manual

 6.12 Backup, restore, version control

Þ If there are any requirement document backups, the respective requirement

documents will appear within the box “Requirements”.

Make sure you ticked the boxes with the requirements to import
them!

Þ Click “OK”.

Figure 6.208: Restore Database dialog

6.12.2.2 Restore into another location

You can also restore TMB backup files into another than the original location: If you
select any folder for which there are no corresponding TMB backup files, restore any of
the available TMB files as children of this folder. The original test collections and folders
of the TMB files will be restored as sub folders of the current folder instead.

6.12.3 Version control

We recommend to save backups of all test relevant files into a version control system on
a regular basis. At least when the test development is completed, the whole test setup
should be saved as backup.

TESSY 4.0 Manual 391

6 Working with TESSY

Þ Follow the steps described above to create the necessary files.

Þ Save the following files and contents of directories into your version control
system:

PDBX file
Contents of the config directory
Contents of the backup directory

Figure 6.209: Data and files within the project directory

The directory work contains only temporary files created during development and
execution of the tests. You can delete this complete directory to save disk space
after the testing work is completed.

The directory persist contains the current databases of the test project. This directory
and the sub directories will be restored when restoring TMB backup files. The valuable
contents of this directory will be saved into the TMB files created during the backup
process.
When you restore the whole project onto another computer, the directory persist will be
restored from the TMB backup files.

392 TESSY 4.0 Manual

 6.13 Command line interface

6.13 Command line interface

TESSY provides a command line interface which allows writing batch script files that
control various operations within a TESSY project. The command line operations are
available by invoking an executable program called “tessycmd.exe”.
The program can be called either from a DOS command line shell or from a DOS batch
script or other script formats that support calling DOS executables.

Before invoking any tessycmd.exe commands you need to start TESSY. The tessycmd.exe
will connect to a running instance of TESSY in order to execute any commands. You
can run TESSY either in GUI mode with a graphical user interface (when started normally
using TESSY.exe) or in headless mode without a GUI (when started using tessyd.exe).

For information about the usage of TESSY together with continuous integration
servers like Jenkins refer to the application note “Continuous Integration with
Jenkins” (“Help” > “Documentation”).

6.13.1 Starting TESSY in headless mode

For test automation on continuous integration servers or nightly builds it is required to

start TESSY in headless mode (i.e. without displaying a GUI). TESSY provides a special
starter application for this purpose called tessyd.exe. When invoking tessyd.exe within your
batch script, it will start TESSY in headless mode and wait until the TESSY application
is ready to receive commands via tessycmd.exe.

At the end of your script you should shutdown TESSY using the same tessyd.exe application
with the parameter “shutdown”. The calling sequence for running batch tests would be
like follows:

tessyd.exe --file <tessy.pdbx file>

tessycmd <commands>

tessyd.exe shutdown

When running TESSY in headless mode, the console output will be written into a
file “console.log” within the directory:
%USERPROFILE%\.tessy_40_workspace\.metadata

TESSY 4.0 Manual 393

6 Working with TESSY

6.13.2 Invoking tessycmd.exe

The executable that provides all command line operations is available within the TESSY in-
stallation directory: Program Files\Razorcat\TESSY_[version]\bin\tessycmd.exe

Þ Start a DOS shell.

Þ Change to the directory “bin”.

Þ Call the executable.

Figure 6.210: DOS command line shell

6.13.3 Usage of tessycmd.exe

The available commands provide means to create, select and list TESSY objects, i.e. a
project, test collection, folder, module, test object. After invoking any create commands,
the respective new TESSY object will be selected. You can invoke further commands to
manipulate any previously created or selected TESSY objects.

You need to call all commands according to the following sequence:

• Connect to TESSY.

• Select or create TESSY objects.

• Invoke commands to start operations on the selected TESSY objects.

• Disconnect from TESSY.

394 TESSY 4.0 Manual

 6.13 Command line interface

Important: If you are not connected, invoking any commands will fail. Multiple
connects will also cause an error.

The current state (connection and selection of TESSY objects) of the tessycmd.exe execu-
table is managed by the currently running TESSY application. If you restart TESSY, the
state of tessycmd.exe will be reset to the initial state, i.e. disconnected.

6.13.4 Commands

command operation

tessycmd -h displays a complete list of the available

commands

tessycmd -h <name fragment> displays a list of the commands matching the

given name fragment

tessyd -f <name of pdbx file> imports and opens the project referred by the
given .pdbx file

tessyd -p <name of project> opens the given project (must be already

available within the project list)

tessycmd connect connects to the running TESSY instance

tessycmd list-projects lists the available projects

tessycmd disconnect disconnects from TESSY

Table 6.266: Excerpt of the possible commands of the command line interface

To execute tessycmd.exe within any directory, add the directory “bin” of the
TESSY installation to the windows path environment variable.

TESSY 4.0 Manual 395

6 Working with TESSY

6.13.5 Example: DOS script

You will find the following example DOS script within the TESSY installation directory:

Program Files\Razorcat\TESSY_4.0\Examples\CommandLine\cmd_line_example.bat

The script is prepared to import TESSY backup files (TMB files) into the currently open TESSY
project. It will create a new test collection “Examples” and import the existing TMB files into a
newly created folder. After the import, it executes the imported modules:

Þ Start TESSY, create a new project and open this project.

Þ Start a DOS command shell.
Þ Change to the bin directory of the TESSY installation:
C:\Program Files\Razorcat\TESSY_4.0\bin
Þ Invoke the DOS batch script “cmd_line_example.bat”. Alternatively, double-click on
the file “cmd_line_example.bat” which invokes the DOS script within a new DOS
shell. There is a pause command at the end which causes the DOS shell to remain
open after execution of the script.

396 TESSY 4.0 Manual

 7 Troubleshooting

For compiler/target settings refer to our application notes available in the Help
menu of TESSY (“Help” > “Documentation”)!

If you have troubles with errors or do not know how to proceed:

• Check this manual and make sure that you have operated correctly.
• Check section 7.2 Solutions for known problems.
• Check our application notes that are available in the Help menu of TESSY (“Help”
> “Documentation”).
• Check our website for commonly asked questions and current issues
http://www.razorcat.com.

7.1 Contacting the TESSY support . . . . . . . . . . . . . . . . . . . . 399

7.2 Solutions for known problems . . . . . . . . . . . . . . . . . . . . . 403
7.2.1 TESSY does not start or gives errors when starting . . . . . . 403
7.2.2 TESSY gives errors when quitted . . . . . . . . . . . . . . . 404
7.2.3 License server does not start or gives errors . . . . . . . . . . 405
7.2.4 Working with constant variables . . . . . . . . . . . . . . . . 406

398 TESSY 4.0 Manual

 7.1 Contacting the TESSY support

7.1 Contacting the TESSY support

If you have further questions or if there is a problem you could not solve with the documentations
described above, please contact our Technical Support per e-mail: support@razorcat.com
Include in your support request e-mail:

• your contact data

• a short description of your question or problem
• the TESSY Support File if you get errors
• a screenshot showing the error message and related view contents of the GUI

The TESSY Support File (TGZ file) contains information about test object in-
cluding data, compiler, project settings etc. It helps the support to detect the
cause of your problem.

Creating the TESSY Support File

Þ In TESSY, select the module or test object that is causing the problem.
Þ Click “Help” in the menu bar.
Þ “Support” > “Create Support File”
Þ Tick the box “Preprocessed sources” if possible.

Important: The box “Preprocessed Sources” is not ticked by de-

fault. This avoids that confidental sources might be included ac-
cidentally. Whenever you can afford to provide the sources to the
support, tick the box “Preprocessed Sources”. In most cases it is
necessary for successful problem investigation.

TESSY 4.0 Manual 399

7 Troubleshooting

Figure 7.1: Dialog for creating the TESSY Support File

Þ Click “OK”.
Þ Choose a folder and a name for the file and click “Save”.
The TESSY Support File (TGZ file) is created.

Tipps for a better TESSY Support File

1. Reduce unnecessary information:

Þ Before reproducing the problem, switch to the Console view of the perspective “Over-
view”.
Þ In the tool bar click on the icon (Clear Console).
All messages will be deleted.

400 TESSY 4.0 Manual

 7.1 Contacting the TESSY support

2. Enable TESSY to display additional information:

Þ In the main menu bar select “Help” > “Logging”.

Þ Select a process, the level (if selectable) and “on” as the table beneath “Table Name”
explains (see table below).

It is possible to enable logging for all process steps.

Figure 7.2: Dialog for logging settings

The additional information can relate to different process steps within TESSY. Enable the logging
of the information you suspect the problem to stem from:

Process step Log if . . .

Process Creation parts of TESSY do not start correctly or TESSY is not able
to start the test system (e.g. debugger).

Parser problems occur during analysis of the source code to determine

test objects and their interfaces. Often caused by incorrect
syntax.

continue next page

TESSY 4.0 Manual 401

7 Troubleshooting

Process step Log if . . .

Instrumenter problems occur during instrumentation of the source code to

determine code coverage.

Makefile Commands the test application (slave) or the test driver (master) cannot
be created or are created incorrectly.

Target Communication problems occur in the communication between TESSY and

the debugger (e.g. the test system).

High level you want to log the general TESSY activities. Seldom required
to find a problem.

Low level you want to log debugger-specific activities. Often very useful.

Table 7.7: Information to log and add to TESSY Support File

Þ You can save the settings for logging with ticking the box “Remember current
settings . . . ”.

3. Reproduce the problem:

Þ Do the actions again that lead to the problem (e.g. opening the module).

Þ Keep the respective element selected that caused the problem (e.g. the test
object in case of errors while executing) when creating the support file.

4. Create the support file, now including all log messages.

402 TESSY 4.0 Manual

 7.2 Solutions for known problems

7.2 Solutions for known problems

7.2.1 TESSY does not start or gives errors when starting

Error message: diverse errors, maybe none

Error description: TESSY does not start or displays exceptions within all GUI windows
(views).

Specific occurrence Error occurs when starting TESSY or while in use.

or requirement:

Possible cause: There might be a problem due to corrupted files needed for the
Eclipse TESSY product startup.

Solution:

Delete the following directories in given order. After every deletion try to start TESSY
again. If it fails, delete the next directory.

Important: Close TESSY completely before deleting any of those directories!

The following example path names reflect a TESSY version 4.0.5. You need to
adjust the path names for the TESSY version you are currently using!

1. Delete folder %userprofile%\.tessy_v4.0.5.

2. Delete the file %userprofile%\.tessy_40_workspace\preferences.xml.

Important: This will reset your preference settings to the defaults!

3. Delete folder %userprofile%\.tessy_40_workspace\.metadata.

Important: This will reset your window layout of the GUI to the
default settings!

4. Delete folder %userprofile%\.tessy_v4.0.5.

TESSY 4.0 Manual 403

7 Troubleshooting

5. Delete folder %userprofile%\.tessy_40_workspace.

Important: After this you need to re-import all your projects into
the project list again! The most simple way to do this is to double-
click on the respective “tessy.pdbx” file.

7.2.2 TESSY gives errors when quitted

Error message: SQLException

SQL State: 08006
Error Code: 40000
Insufficient data while reading from the network - expected a
minimum of 6 bytes and received only 0 bytes. The
connection has been terminated.

SQLException
SQL State: 08001
Error Code: 40000
java.net.ConnectException: Fehler beim Herstellen der
Verbindung zu Server localhost auf Port 1527 mit Meldung
Connection refused: connect.

Error description: When quitting TESSY, one of the error messages above is
displayed.

Specific occurrence Error occurs when quitting TESSY.

or requirement:

Possible cause: Two versions of TESSY were startet at the same time.

Solution:

If you want to use both versions of TESSY at the same time, you can change the config
file:

Important: The functions of the command line tool are limited if you use both
TESSY versions at the same time! The tool works with the TESSY version that
was startet at last.

404 TESSY 4.0 Manual

 7.2 Solutions for known problems

Þ Open the config file of TESSY under

%APPDATA%\Razorcat\Tessy\[TESSY Version]\config\tessy.conf.

Þ Remove the hashmark in front of the server port from the database.

# Port to use by derbyd

TESSY_DERBYD_PORT=40000

7.2.3 License server does not start or gives errors

Error message: Diverse, e.g. A license server is not running.

Error description: The license server does not start, or you get an error when
starting it.

Specific occurrence -
or requirement:

Possible cause: Corrupt/incorrect license key.

Solution:

Check your license key:

Þ Start the License Manager manually if it has not startet yet: “Start” > “All
Programs” > “TESSY” > “Floating License Manager”.

Þ Click on (Check) to check your license key file.

Þ Check the error message (see figure 7.3).

Figure 7.3: License key check unsuccessful: license key is incorrect for the host id

TESSY 4.0 Manual 405

7 Troubleshooting

In many cases you can already determine the problem with the help of the error message.
In case of the error “No maching hostid for key” the license key does not match to the
host id of your computer:

Þ Configure the correct license key file in the manager: Click on (Configure)
and select the correct license key file. Click “OK”.

Þ Click on to check the license key file again.

Þ If the error still appears, contact our support (see Contacting the TESSY
support) to get a new license key file.

7.2.4 Working with constant variables

Setting a variable declared with the “const” modifier keyword may result in undefined beha-
vior and lead to error messages. In those cases set the variable passing to “IRRELEVANT”
in the TIE. After that was done the test shall pass through without any restriction.

Figure 7.4: Variable passing set to “IRRELEVANT”

Important: Please note that normally constant variables are read-only variables
and can not be assigned.

406 TESSY 4.0 Manual

 7.2 Solutions for known problems

7.2.4.1 Assignment of read-only variables

If read-only variables need to be assigned, choose from the following solutions:

1. Undefine the const modifier in the properties view (for individual modules)
The modifier "const" needs to be removed in order to write to such variables. You can
remove this modifier without changing the source file using a special define that replaces
the "const" keyword with nothing.

Þ In the Test Project view click on the module you want to test.

Figure 7.5: Properties view with undefined const modifier

Þ To add a define that replaces the "const" keyword with an empty content click
on (see figure 7.5) in the Properties view. The New Define popup window
opens.

Þ Enter a define with the name "const" and an empty value as shown below (see
figure 7.6).

TESSY 4.0 Manual 407

7 Troubleshooting

Figure 7.6: New Define popup window

Assignments to read-only variables are now possible in the chosen module. When this
define is in place, all variables with the "const" modifier will appear as if the "const" has
not been used (i.e. the variables are not "const" any more and can be changed during the
test execution).

2. Modify the Makefile Template in the TEE (for global use)

Þ In the menu bar click “File” > “Edit Enviroment...”.

Þ In the TEE right click in “Makefile Template” > click “Open with Editor”.

Þ In the respective file, e.g. “ts_make_socket file.tpl” when using the GCC
compiler, add “-Dconst=” in the line “S_COMP_OPTIONS” (see figure 7.7).

408 TESSY 4.0 Manual

 7.2 Solutions for known problems

Figure 7.7: Edit the Makefile Template

After saving the Makefile Template (e.g. “ts_make_socket.tpl”) constant variables are
generally replaced with an empty content.

TESSY 4.0 Manual 409

 Appendix

TESSY 4.0 Manual 411

 A Abbreviations

API Application Programming Interface

C0 Statement Coverage
C1 Branch Coverage
CTE Classification Tree Editor
CV Coverage Viewer
DC Decision Coverage
DOS Disk Operating System
EPC Entry Point Coverage
ECU Electronic Control Unit
FAQ Frequently Asked Questions
FC Function Coverage
GUI Graphical User Interface
GUID Global Unique Identifier
HTML Hyper Text Markup Language
IDA Interface Data Assigner
IEC International Electrotechnical Commission
ISO International Standards Organization
MC/DC Modified condition/decision coverage
MCC Multiple condition coverage
OBT Original binary test
PDB TESSY Project Database (TESSY Version < 3)
PDBX TESSY Project Database (TESSY Version >= 3)
QTS Qualification Test Suite
RQMT Requirement
SCE Scenario Editor
SIL Safety Integrity Level
TBS TESSY Batch Script
TC Test Case
TD Test Definition
TDB Test Database
TDE Test Data Editor

412 TESSY 4.0 Manual

 A Abbreviations

TEE Test Environment Editor

TIE Test Interface Editor
TMB TESSY Module Backup
TS Test Step
UCE User Code Editor
XML Extensible Markup Language

TESSY 4.0 Manual 413

 B Glossary

Batch Testing A testing procedure in which multiple test objects are executed automa-
tically one after each other without further user interaction.

Branch Coverage Is usually abbreviated “C1”. Roughly spoken: Branch Coverage reveals,
if all branches were executed, for example, an if-instruction has two branches, the
then-branch and the else-branch.

C1 Test During a C1 test, each branch of the test object will be instrumented with a
counter to monitor, how often a branch of the program is run through.

Classification Tree The objective of the Classification Tree Method is to determine a

sufficient but minimum number of test cases. It is a systematic approach to test
planning by test case specifications and priorizations.

Code Coverage A test object is considered to consist of items like branches, conditions,
etc. Code coverage measures, how many of the items were exercised during the
tests. This number is related to the total number of items and is usually expressed in
percent. TESSY features C1 coverage (branch coverage) and C2 coverage (MC/DC:
Modified Condition)

Component Functions are functions that are callable from external.

Component Testing is the test of interacting test objects, i.e. interacting functions in
the sense of C. These functions can be a (single) calling hierarchy of functions, but
we will consider this mainly as unit testing. We consider as a component mainly a
set of functions that interact e.g. on common data and do not necessarily call each
other. Component testing then is testing of such a set of functions. The units do
not need to be in a calling hierarchy; they may only interact on data, like push() and
pop() of the abstract data type “stack”. A component according to this specification
may also be called a “module”, and its testing “module testing” respectively.

414 TESSY 4.0 Manual

 B Glossary

Debugger A computer program that is used to test and debug other programs (the “tar-
get” program). The code to be examined might alternatively be running on an
instruction set simulator (ISS), a technique that allows great power in its ability to
halt when specific conditions are encountered but which will typically be somewhat
slower than executing the code directly on the appropriate (or the same) processor.
Some debuggers offer two modes of operation - full or partial simulation, to limit
this impact.

Enums Type of the C language specification which allows to define a list of aliases which
represent integer numbers.

Expected Values Values expected to be calculated by the test object. The result values
are checked against the expected values after the test run.

Hysteresis Dependence of a system not just on its current environment but also on its
past. This dependence arises because the system can be in more than one internal
state.

Interface Data Assign editor (IDA) If the interface elements of the test object have
changed, you can assign the new interface elements to the old. Your test data will
be assigned automatically.

Input Values Function parameters, global and external variables which have effect on the
behavior of the function.

Interface Description Information about the passing direction and type of interface ele-
ments (parameter, global variables and extern variables). The interface description
is determined automatically by TESSY and is made visible / changeable in the TIE.

Integration Testing consists of a sequence of calls and can be considered either as unit
testing for a calling hierarchy of functions or as a component testing for a set of inte-
racting functions not necessarily calling each other. Component testing is integration
testing of the functions in the component.

Modified Condition / Decision Coverage (MC/DC) MC/DC coverage takes the struc-
ture of a decision into account. Each decision is made up from conditions, which are
combined by logical operators (and, or, not). Roughly spoken, to get 100 percent
MC/DC for a decision, each condition in the decision requires a pair of test cases,
that

TESSY 4.0 Manual 415

B Glossary

• differs in the boolean value for that condition, and

• has the same boolean value for all other conditions, and
• produces true and false in the outcome of the whole decision

n conditions require n+1 test cases

Module A TESSY module comprises primarily of the test object (in C a function in the
sense of C) and source files, compiler settings, interface description and test data.
You can pool modules in projects.

Module Testing is a semantic term for testing a collection of cooperating functions

(units).

Output Values The same as an expected value in the TESSY context. Both terms are
used in equivalence within this manual. The output (repectively expected) values
are evaluated against the actual result values after the test run.

Project Root See explanatory box on page 23.

Regression Testing Regression testing is the repetitive running of already successfully

completed test cases. The intention of regression testing is to verify that modi-
fications and enhancements to a test object do not break the already successfully
completed tests.

Requirement Documented need of what a test should perform and important input for the
verification process. Requirements show what elements and functions are necessary
for the test.

Requirement Management Management of different types of requirements that need to

be covered by at least one test.

Requirement, Functional Describes the features, specific behavior, business rules and
general functionality that the proposed system must support.

Requirement, Non-Functional Specifies criteria that can be used to judge the operation
of the test.

Search Query Search definitions processed by a search engine.

416 TESSY 4.0 Manual

 B Glossary

Stub Function Piece of code used to stand in for some other programming functionality.
A stub may simulate the behavior of existing code (such as a procedure on a remote
machine) or be a temporary substitute for yet-to-be-developed code.

System Testing Test of the application (software or software and hardware) as a whole.

Test Data Editor (TDE) With the TDE you can enter the input values and expected
values for the test run.

TESSY Support File Contains information about test objects including data, compiler,
project settings etc. It helps the support to detect the cause of a problem. In section
Contacting the TESSY support it is explained how to create a TESSY Support File.

Test Case Element that encapsulates the abstract test definition, e.g. the specification
and description of a test, and the concrete test data managed within test steps.

Test Definition Describes a test to be performed on the test system in textual format.
A test definition abstractly describes the inputs and the expected outcome of a test
and refers to a list of requirements which shall be validated with this test.

Test Driver C-source files generated by TESSY for the test execution. These files are
compiled and linked in order to build an application that prepares the input data,
call the test object and store the actual result data.

Test Environment Information about the test object, the compiler used, the target de-
bugger or emulator and more settings.

Test Object The function to be tested.

Test Run One execution of a test object with the given test cases. The result of a test
run is stored within an XML result file that may be further processed by external
tools.

Test Suite A collection of test objects with test scenarios and/or test cases that were
created to fulfill a certain test objective.

Test Interface Editor (TIE) With the TIE you can view all interface elements and review
or set the passing direction and/or other information of the interface elements.

Unit A single function, i.e. test object of a C program single function; the smallest
reasonable test object of a C program.

TESSY 4.0 Manual 417

B Glossary

Usercode In the usercode you can enter C code, which is executed before or after test
cases/test steps during the execution of a test object.

Workspace The space at local disk where the TESSY application reads and writes data.
Place for configuration and temporary report data. Project data can be saved sepa-
rately.

418 TESSY 4.0 Manual

C List of Figures

0.1 Core workflow of TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

0.2 UUID property of TESSY objects . . . . . . . . . . . . . . . . . . . . . . . . xxix
0.3 Exclude test items from the test . . . . . . . . . . . . . . . . . . . . . . . . xxx

1.1 InstallAware Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Destination Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 TESSY Testarea Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Program folder and user selection . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Installing process of TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Installation is completed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Starting TESSY 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8 Starting the key request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.9 License key request popup window . . . . . . . . . . . . . . . . . . . . . . . 7
1.10 Form for the license key request . . . . . . . . . . . . . . . . . . . . . . . . 8
1.11 Configure menu of the license server . . . . . . . . . . . . . . . . . . . . . . 9
1.12 License key check successful: this license key is correct . . . . . . . . . . . . 10
1.13 The license info shows the possible days for checking out the license . . . . . 12
1.14 Checking out the TESSY license . . . . . . . . . . . . . . . . . . . . . . . . 12
1.15 Determine the amount of days for the check-out . . . . . . . . . . . . . . . . 13
1.16 Transmitting the license file to a computer with no internet connection . . . 14

2.1 Updating a project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Path of the workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Creating a new project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Selecting a folder for the project root. . . . . . . . . . . . . . . . . . . . . . 21
3.4 Creating a new project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Context menu of the Select Project dialog . . . . . . . . . . . . . . . . . . . 26
3.6 Project identifier handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Project Example1 is created. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 TESSY notifies, that a database update is necessary . . . . . . . . . . . . . . 30
3.9 A database update is necessary . . . . . . . . . . . . . . . . . . . . . . . . . 30

TESSY 4.0 Manual 419

C List of Figures

3.10 TESSY interface and its terminology . . . . . . . . . . . . . . . . . . . . . . 31

3.11 Open other perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Test Project view within the Overview perspective . . . . . . . . . . . . . . . 33
3.13 Adding views to a perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.14 Move the views separately. To switch back, use “Reset”. . . . . . . . . . . . 34
3.15 To switch back all positions of views and perspectives use “Reset Workbench”. 35
3.16 Minimizing and maximizing views . . . . . . . . . . . . . . . . . . . . . . . . 35
3.17 Maximized view with minimized views on the right and the restore-button on
the left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.18 Using the context menu with right click. . . . . . . . . . . . . . . . . . . . . 37

4.1 Initial equivalence partitioning for “ice warning” . . . . . . . . . . . . . . . . 52

4.2 Repeated equivalence partitioning for “ice warning” . . . . . . . . . . . . . . 53
4.3 A possible CT for “ice warning” . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Result of the CTM: tree (above) with combination table (below) . . . . . . . 55
4.5 The problem “is_value_in_range” depicted graphically . . . . . . . . . . . . 56
4.6 The initial CT with three test-relevant aspects . . . . . . . . . . . . . . . . . 56
4.7 The CT for is_value_in_range, 2nd step . . . . . . . . . . . . . . . . . . . . 57
4.8 The CT for is_value_in_range, 3rd step . . . . . . . . . . . . . . . . . . . . 57
4.9 A first specification for the range in the combination table . . . . . . . . . . 58
4.10 A second specification for the range in the combination table . . . . . . . . . 58
4.11 The CT for is_value_in_range, 4th step . . . . . . . . . . . . . . . . . . . . 59
4.12 The third range specification provokes a wrap-around . . . . . . . . . . . . . 60
4.13 The completed CT for is_value_in_range . . . . . . . . . . . . . . . . . . . 61
4.14 The completed test case specification . . . . . . . . . . . . . . . . . . . . . 63
4.15 An alternative test case specification . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Operational sequences in TESSY . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Creating the new project “Example1”. . . . . . . . . . . . . . . . . . . . . . 71
5.3 New project “Example1” is created . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 Test collection “Is_value_in_range” with an example folder and module . . . 72
5.5 GNU GCC compiler is selected by default. . . . . . . . . . . . . . . . . . . . 73
5.6 The source code of the C-Function to be tested . . . . . . . . . . . . . . . . 73
5.7 Adding the C-source file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.8 Analyzing the module, that is the C-source file. . . . . . . . . . . . . . . . . 75
5.9 The function of the C-source is displayed as child of the module. . . . . . . . 75
5.10 Perspective TIE - Test Interface Editor . . . . . . . . . . . . . . . . . . . . . 76
5.11 The inputs and outputs are already defined . . . . . . . . . . . . . . . . . . 77
5.12 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

420 TESSY 4.0 Manual

 C List of Figures

5.13 Three test cases were added in the Test Items view . . . . . . . . . . . . . . 78
5.14 Data is entered, test step turns yellow and test case is ready to run. . . . . . 80
5.15 Entering data for test object is_value_in_range . . . . . . . . . . . . . . . . 81
5.16 The test cases are ready to test . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.17 TDE after test run is_value_in_range . . . . . . . . . . . . . . . . . . . . . 82
5.18 Test results of is_value_in_range . . . . . . . . . . . . . . . . . . . . . . . . 83
5.19 Selecting Branch and MC/DC Coverage for test run . . . . . . . . . . . . . . 84
5.20 Execute Test dialog while running the test . . . . . . . . . . . . . . . . . . . 84
5.21 The Coverage Viewer displays the coverage of is_value_in_range . . . . . . . 85
5.22 Branch coverage is_value_in_range . . . . . . . . . . . . . . . . . . . . . . 86
5.23 Decision coverage is_value_in_range . . . . . . . . . . . . . . . . . . . . . . 87
5.24 Code section of the if branch of the first decision . . . . . . . . . . . . . . . 88
5.25 Code section of the second decision . . . . . . . . . . . . . . . . . . . . . . 89
5.26 Creating the folder for reports . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.27 Content of the test report is_value_in_range . . . . . . . . . . . . . . . . . 91
5.28 Importing a requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.29 Import dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.30 The new requirement document . . . . . . . . . . . . . . . . . . . . . . . . 93
5.31 Changing the alias of the new requirement document . . . . . . . . . . . . . 94
5.32 Comment for the initial revision of the commit . . . . . . . . . . . . . . . . . 94
5.33 Linking test cases with requirements . . . . . . . . . . . . . . . . . . . . . . 95
5.34 Test Definition view within TDE with linked requirement . . . . . . . . . . . 96
5.35 Editing the settings of a Planning Coverage Report . . . . . . . . . . . . . . 97
5.36 Dialog of the settings for the Planning Coverage Report . . . . . . . . . . . . 97
5.37 Planning coverage report of the IVIR requirement document . . . . . . . . . 98
5.38 Generating a Test Details Report . . . . . . . . . . . . . . . . . . . . . . . . 99
5.39 Part of the generated test report of is_value_in_range . . . . . . . . . . . . 100
5.40 Creating an Execution Coverage Report . . . . . . . . . . . . . . . . . . . . 100
5.41 Coverage Report of is_value_in_range . . . . . . . . . . . . . . . . . . . . . 101
5.42 Overview perspective after test run (with requirements) . . . . . . . . . . . . 103
5.43 Use the context menu to edit a source . . . . . . . . . . . . . . . . . . . . . 103
5.44 Editing the C-source file is_val_in_range.c . . . . . . . . . . . . . . . . . . 104
5.45 Changed C-source file of is_value_in_range . . . . . . . . . . . . . . . . . . 104
5.46 Adding a “delete” and “new” object . . . . . . . . . . . . . . . . . . . . . . 105
5.47 Changed and new test objects of is_value_in_range . . . . . . . . . . . . . . 105
5.48 Remove the code for test object “deleted”. . . . . . . . . . . . . . . . . . . . 106
5.49 Changed and new test objects of is_value_in_range . . . . . . . . . . . . . . 106
5.50 Changed, deleted and new test object of is_value_in_range . . . . . . . . . 108

TESSY 4.0 Manual 421

C List of Figures

5.51 Use drag and drop in IDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.52 CTE with the root “is_value_in_range” . . . . . . . . . . . . . . . . . . . . 110
5.53 Creating a new classification with the context menu . . . . . . . . . . . . . . 111
5.54 Renaming the new classification . . . . . . . . . . . . . . . . . . . . . . . . 112
5.55 Classifications of is_value_in_range . . . . . . . . . . . . . . . . . . . . . . 112
5.56 Simple classification tree for is_value_in_range . . . . . . . . . . . . . . . . 113
5.57 Entering data in CTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.58 Entering more data in CTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.59 Blue dots indicate that “range_start” elements contain data . . . . . . . . . 116
5.60 Creating test cases in the test item list . . . . . . . . . . . . . . . . . . . . . 116
5.61 Defining test cases in the combination table of CTE . . . . . . . . . . . . . . 117
5.62 Completed table with all test cases for example “is_value_in_range” . . . . . 118
5.63 Test data is displayed when selecting a test case in the combination table . . 119
5.64 Test data displayed within TDE . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.66 Example interior_light; ECU = Electronic Control Unit . . . . . . . . . . . . 122
5.67 Test Project view with new project interior_light . . . . . . . . . . . . . . . 123
5.68 Selecting “Component” in the module properties . . . . . . . . . . . . . . . 124
5.69 Scenario of a component test . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.70 C-source code interior_light . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.72 If a heartbeat function exists, timely behavior can be tested. . . . . . . . . . 126
5.73 The initial interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.74 Creating the stubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.75 The final passing directions of variables used by init() . . . . . . . . . . . . . 128
5.76 Test Project view with a component test . . . . . . . . . . . . . . . . . . . . 129
5.77 Adding a description to test cases . . . . . . . . . . . . . . . . . . . . . . . 129
5.78 Inline editor of the view Test Data of ’Scenarios’ . . . . . . . . . . . . . . . . 130
5.79 View Test Data of ’Scenarios’ . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.80 View External Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.81 The names of the test cases are displayed in tabs of the view Work Task . . . 131
5.82 Setting the Work Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.83 Dragging the function onto the scenario . . . . . . . . . . . . . . . . . . . . 133
5.84 set_sensor_door() is dragged to 30 ms simulated time . . . . . . . . . . . . 133
5.85 The parameter of set_sensor_door() is set . . . . . . . . . . . . . . . . . . . 134
5.86 Dragging the function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.87 Extending the time frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.88 Setting the call “LightOff” and extending the time frame . . . . . . . . . . . 136
5.89 Setting values to “ignore” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.90 Designing the second scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 138

422 TESSY 4.0 Manual

 C List of Figures

5.91 The scenarios of the component “passed” the test . . . . . . . . . . . . . . . 139

5.92 Importing a project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.93 Cloning the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.94 Cloning the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.95 The project root is displayed within the bottom line of TESSY. . . . . . . . . 142
5.96 Restoring the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.97 Test project view with the C++ project . . . . . . . . . . . . . . . . . . . . 143
5.98 Adding synthetic test objects. . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.99 Adding synthetic variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.100 Creating test cases for TDD. . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.101 Filling test cases for TDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.102 Test specification report for TDD. . . . . . . . . . . . . . . . . . . . . . . . 146
5.103 Implementation source file available for TDD. . . . . . . . . . . . . . . . . . 147
5.104 Assignment of synthetic test objects to the implemented functions. . . . . . . 147
5.105 Readily assigned TDD test cases. . . . . . . . . . . . . . . . . . . . . . . . . 148

6.1 Menu bar of TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.2 Preferences menu of TESSY . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.3 Static Analysis in the Preferences menu . . . . . . . . . . . . . . . . . . . . 159
6.4 Pre-defined coverage instrumentation settings . . . . . . . . . . . . . . . . . 159
6.5 Overview perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.6 Test Project view within the Overview perspective . . . . . . . . . . . . . . . 162
6.7 The function of the C-source is displayed as child of the module. . . . . . . . 166
6.8 Warning when opening older modules with CLANG enabled . . . . . . . . . . 167
6.9 Create Variant Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.10 Selecting the parent module of the variant . . . . . . . . . . . . . . . . . . . 170
6.11 Test Project view with a module and a variant module. . . . . . . . . . . . . 170
6.12 The variant module needs to be synchronized with the parent. . . . . . . . . 171
6.13 Synchronizing a module with the parent . . . . . . . . . . . . . . . . . . . . 171
6.14 Synchronize Module dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.15 Interface assignment needed . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.16 Test cases and test steps that were inherited of a variant module . . . . . . . 173
6.17 Test Execution Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.18 Coverage displayed within the Test Project view . . . . . . . . . . . . . . . . 178
6.19 Filter Configuration Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.20 A filter has been set but is currently disabled (filtered test objects appear
faded). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.21 The Filter is enabled, the affected test objects are hidden. . . . . . . . . . . 180
6.22 Clicking on the arrow opens the “Select Test Object Filter” dialog. . . . . . . 180

TESSY 4.0 Manual 423

C List of Figures

6.23 Search filter function of the test project view . . . . . . . . . . . . . . . . . . 181

6.24 Searching for “foo” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.25 Creating a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.26 Context menu “Define Batch Operation” . . . . . . . . . . . . . . . . . . . . 186
6.27 Defining the batch operation . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.28 Selecting all text objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.29 Editing the settings of each batch operation . . . . . . . . . . . . . . . . . . 188
6.30 Saving the settings of a batch operation as TBS file . . . . . . . . . . . . . . 189
6.31 Import settings of data import . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.32 Export settings of data export . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.33 Properties view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.34 The Compiler pane in the Sources tab of the Properties view . . . . . . . . . 193
6.35 The Setting tab of the Properties view with module selected . . . . . . . . . 195
6.36 The Linker Options tab of the Properties view . . . . . . . . . . . . . . . . . 196
6.37 The Coverage tab of the Properties view . . . . . . . . . . . . . . . . . . . . 196
6.38 Selection of the coverage measurement in the pull-down menu . . . . . . . . 197
6.39 Defining coverage measurements . . . . . . . . . . . . . . . . . . . . . . . . 198
6.40 The Attributes tab of the Properties view . . . . . . . . . . . . . . . . . . . 199
6.41 Creating a new attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.42 Requirements Coverage view . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.43 Test Items view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.44 First test case with one test step . . . . . . . . . . . . . . . . . . . . . . . . 205
6.45 Selecting the test case generator . . . . . . . . . . . . . . . . . . . . . . . . 206
6.46 A new test case generator is created . . . . . . . . . . . . . . . . . . . . . . 206
6.47 The test steps were generated and are ready to be executed . . . . . . . . . 207
6.48 Selecting “Change Test Case Type to Normal” . . . . . . . . . . . . . . . . . 207
6.49 The test case and test steps originally being generated . . . . . . . . . . . . 208
6.50 Test cases created by CTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6.51 Test cases and test steps that were inherited of a variant module . . . . . . . 209
6.52 All test cases will be renumbered . . . . . . . . . . . . . . . . . . . . . . . . 210
6.53 Test Results view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.54 Evaluation Macros view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.55 Console view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.56 Preference “Show console on error” . . . . . . . . . . . . . . . . . . . . . . . 212
6.57 Variants View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.58 Assign a variant to a module . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.59 Example test collection with base modules . . . . . . . . . . . . . . . . . . . 214
6.60 Create variant modules dialog: Filtering and selection . . . . . . . . . . . . . 215

424 TESSY 4.0 Manual

 C List of Figures

6.61 Test Project view with new variant modules . . . . . . . . . . . . . . . . . . 215

6.62 Properties view variants tab for editing the parent module . . . . . . . . . . 216
6.63 Perspective C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.64 Opening the C/C++ perspective . . . . . . . . . . . . . . . . . . . . . . . . 218
6.65 Editor view within the C/C++ perspective . . . . . . . . . . . . . . . . . . . 219
6.66 Opening the C/C++ perspective . . . . . . . . . . . . . . . . . . . . . . . . 220
6.67 Project Explorer view within the C/C++ perspective . . . . . . . . . . . . . 220
6.68 Outline view within the C/C++ perspective . . . . . . . . . . . . . . . . . . 221
6.69 Requirement Management perspective . . . . . . . . . . . . . . . . . . . . . 224
6.70 RQMT Explorer view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.71 Double clicking on a requirement opens the requirement editor . . . . . . . . 226
6.72 Example for the document structure within the RQMT Explorer view . . . . . 228
6.73 Importing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.74 Import dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.75 The new requirement document . . . . . . . . . . . . . . . . . . . . . . . . 231
6.76 The asterix and a mouseover shows the status “new”. . . . . . . . . . . . . . 231
6.77 Committing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.78 Comment for the initial revision of the commit . . . . . . . . . . . . . . . . . 232
6.79 After the commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.80 Changing the alias of the new requirement document . . . . . . . . . . . . . 233
6.81 The alias of a requirement is used in various views . . . . . . . . . . . . . . . 234
6.82 Requirements List view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.83 Double clicking on a requirement opens the Requirement Editor . . . . . . . 235
6.84 Requirements Editor with test and a figure . . . . . . . . . . . . . . . . . . . 236
6.85 The first requirement was modified . . . . . . . . . . . . . . . . . . . . . . . 237
6.86 The first requirement has the version number 2.0 . . . . . . . . . . . . . . . 238
6.87 VxV Matrix view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.88 Test Means view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.89 Link Matrix view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.90 Adding elements to the Link Matrix view . . . . . . . . . . . . . . . . . . . . 242
6.91 Adding Test Cases to the Link Matrix view in the Overview perspective . . . 243
6.92 Link Matrix view with suspicious elements . . . . . . . . . . . . . . . . . . . 244
6.93 Suspicious Elements view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.94 Suspicious test object and test cases in the Overview perspective . . . . . . . 246
6.95 Suspicious test object and linked modified requirements . . . . . . . . . . . . 247
6.96 Selecting the suspicious test case shows the modified requirement(s) . . . . . 248
6.97 Comparing the versions of the requirement . . . . . . . . . . . . . . . . . . . 249
6.98 Attached Files view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

TESSY 4.0 Manual 425

C List of Figures

6.99 Attributes view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

6.100 Editing the requirement settings within the Attributes view . . . . . . . . . . 252
6.101 Changing the “Content Type” attribute to HTML . . . . . . . . . . . . . . . 253
6.102 History view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.103 Differences view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
6.104 Related Elements view and its interrelations . . . . . . . . . . . . . . . . . . 256
6.105 Related Elements view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
6.106 Related Elements view with Incoming and Outgoing Links . . . . . . . . . . . 257
6.107 Problems view with error message . . . . . . . . . . . . . . . . . . . . . . . 258
6.108 View Document Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
6.109 HTML editing within the inline editor (WYSIWYG and plain HTML) . . . . . 260
6.110 Requirements Coverage view with no linked requirements . . . . . . . . . . . 261
6.111 Setting or disabling the options of auto refreshing . . . . . . . . . . . . . . . 262
6.112 Test Environment Editor (TEE) . . . . . . . . . . . . . . . . . . . . . . . . . 266
6.113 Call of the Test Environment Editor (TEE) . . . . . . . . . . . . . . . . . . . 268
6.114 Configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
6.115 Visualizing all items within TEE . . . . . . . . . . . . . . . . . . . . . . . . 272
6.116 Compiler and targets possible to use in TESSY . . . . . . . . . . . . . . . . 273
6.117 Enabled and disabled configurations within TEE . . . . . . . . . . . . . . . . 273
6.118 Attribute settings of the Eclipse target . . . . . . . . . . . . . . . . . . . . . 274
6.119 Enable compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
6.120 Adding an environment to a configuration file by using the context menu . . 277
6.121 Adding an environment to a configuration file by drag and drop . . . . . . . 278
6.122 Perspective TIE - Test Interface Editor . . . . . . . . . . . . . . . . . . . . . 282
6.123 Information of passing direction and type . . . . . . . . . . . . . . . . . . . . 284
6.124 Interface view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
6.125 White arrow indicating further levels, black arrow when expanded . . . . . . 286
6.126 Resetting passing directions . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
6.127 Setting the data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
6.128 Array as pointer NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
6.129 Create a stub function within the context menu . . . . . . . . . . . . . . . . 292
6.130 Create a new variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
6.131 Example code snippet for alias names . . . . . . . . . . . . . . . . . . . . . 295
6.132 Show alias names preferences . . . . . . . . . . . . . . . . . . . . . . . . . . 296
6.133 Plot Definitions view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
6.134 Adding variables to a plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
6.135 Using plots in report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
6.136 CTE perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

426 TESSY 4.0 Manual

 C List of Figures

6.137 Classification Tree view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

6.138 Creating a new classification with the context menu . . . . . . . . . . . . . . 305
6.139 Creating test cases in the test item list . . . . . . . . . . . . . . . . . . . . . 306
6.140 Classification Tree with test data for class h . . . . . . . . . . . . . . . . . . 307
6.141 The first two test cases are read only and created within the CTE . . . . . . 308
6.142 Showing data of a tree node . . . . . . . . . . . . . . . . . . . . . . . . . . 309
6.143 Variable assignments in classification trees . . . . . . . . . . . . . . . . . . . 310
6.144 TDE perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
6.145 Type information of the variable long range_start . . . . . . . . . . . . . . . 315
6.146 Test Data view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
6.147 Test step 1.1 is selected and undefined values are highlighted in yellow. . . . 319
6.148 Test Data view showing selected test steps. . . . . . . . . . . . . . . . . . . 319
6.149 Clicking in the cell opens the components . . . . . . . . . . . . . . . . . . . 322
6.150 Clicking in the cell opens the available enums . . . . . . . . . . . . . . . . . 323
6.151 Entering values as vector for an advanced stub . . . . . . . . . . . . . . . . . 324
6.152 Passing direction set to irrelevant. . . . . . . . . . . . . . . . . . . . . . . . 326
6.153 Entering evaluation mode “unequal” within the inline editor . . . . . . . . . . 327
6.154 Generator test case 4 has a range value from 6 to 9 for parameter v1 . . . . . 329
6.155 Four test steps are generated for every value within the range “6 to 9”. . . . 330
6.156 Selecting “Change Test Case Type to Normal” . . . . . . . . . . . . . . . . . 331
6.157 The test case and test steps originally being generated. . . . . . . . . . . . . 331
6.158 Inherited value coloring within Test Data view . . . . . . . . . . . . . . . . . 332
6.159 Test Definition view within TDE with linked requirement . . . . . . . . . . . 335
6.160 Declarations/Definitions view . . . . . . . . . . . . . . . . . . . . . . . . . . 336
6.161 Prolog/Epilog view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
6.162 Call sequence of the usercode parts . . . . . . . . . . . . . . . . . . . . . . . 337
6.163 TESSY provides default prolog/epilog on test object level to be inherited to
test cases and test steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
6.164 TESSY allows Prolog/Epilog being inherited from test case or test object . . 340
6.165 Prolog/Epilog functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
6.166 Editing C code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
6.167 Call the popup menu by pressing CTRL + space . . . . . . . . . . . . . . . . 343
6.168 Editing the evaluation macro templates . . . . . . . . . . . . . . . . . . . . 343
6.169 Formatting of evaluation macro values . . . . . . . . . . . . . . . . . . . . . 345
6.170 Stub Functions view without contents . . . . . . . . . . . . . . . . . . . . . 346
6.171 Test execution direction using stub code . . . . . . . . . . . . . . . . . . . . 346
6.172 TESSY Preferences: Abort on missing stub code . . . . . . . . . . . . . . . 347
6.173 Stub Functions view with code using TS_CALL_COUNT macro . . . . . . . 348

TESSY 4.0 Manual 427

C List of Figures

6.174 Stub Code Levels in the Usercode Outline view . . . . . . . . . . . . . . . . 348

6.175 Stub code examples on test object, test case and test step level . . . . . . . 349
6.176 Automatically Generated Test Code . . . . . . . . . . . . . . . . . . . . . . . 350
6.177 Usercode Outline view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
6.178 Usercode Outline view showing inherited stub code . . . . . . . . . . . . . . 351
6.179 Usercode Outline view showing inserted stub code . . . . . . . . . . . . . . . 351
6.180 Plots view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
6.181 Perspective CV - Coverage Viewer . . . . . . . . . . . . . . . . . . . . . . . 354
6.182 Results of the EPC are displayed within the Test Project view . . . . . . . . 356
6.183 Coverage results within the CV perspective (component testing) . . . . . . . 357
6.184 Test Project view within the CV perspective . . . . . . . . . . . . . . . . . . 358
6.185 Called Functions view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
6.186 Flow Chart view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
6.187 Unreached code branch is marked blue . . . . . . . . . . . . . . . . . . . . . 363
6.188 Statement coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
6.189 Branch coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
6.190 MC/DC coverage view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
6.191 MC/DC coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
6.192 IDA perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
6.193 Compare view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
6.194 Use drag and drop in IDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
6.195 Perspective SCE - Scenario Editor . . . . . . . . . . . . . . . . . . . . . . . 376
6.196 Component test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
6.197 Scenarios of a component test . . . . . . . . . . . . . . . . . . . . . . . . . 378
6.198 Interface of the scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
6.199 Two component functions were set as work task within the Component Functi-
ons view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
6.200 Work Task Configuration view . . . . . . . . . . . . . . . . . . . . . . . . . 381
6.201 Calculated cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
6.202 Adding Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
6.203 The Test Data view of ’Scenarios’ . . . . . . . . . . . . . . . . . . . . . . . 385
6.204 Indicator icons for the test data . . . . . . . . . . . . . . . . . . . . . . . . . 385
6.205 A function is not called . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
6.206 Save Database dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
6.207 Files of the backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
6.208 Restore Database dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
6.209 Data and files within the project directory . . . . . . . . . . . . . . . . . . . 392
6.210 DOS command line shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

428 TESSY 4.0 Manual

 C List of Figures

7.1 Dialog for creating the TESSY Support File . . . . . . . . . . . . . . . . . . 400

7.2 Dialog for logging settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
7.3 License key check unsuccessful: license key is incorrect for the host id . . . . 405
7.4 Variable passing set to “IRRELEVANT” . . . . . . . . . . . . . . . . . . . . 406
7.5 Properties view with undefined const modifier . . . . . . . . . . . . . . . . . 407
7.6 New Define popup window . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
7.7 Edit the Makefile Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

TESSY 4.0 Manual 429

 D List of Tables

0.1 Where to find - matters of the several parts of the TESSY manual . . . . . . xxi
0.2 Font characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

3.1 File system and databases of TESSY . . . . . . . . . . . . . . . . . . . . . . 20

3.6 Options of the Project Configuration dialog . . . . . . . . . . . . . . . . . . 23
3.8 Tool bar options of the Select Project dialog . . . . . . . . . . . . . . . . . . 25
3.11 Handling of projects with equal names . . . . . . . . . . . . . . . . . . . . . 28
3.19 Shortcuts and key functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.18 Entering data for test object is_value_in_range. . . . . . . . . . . . . . . . . 80

6.1 File menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.2 Window menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.3 Preferences menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.5 Help menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.6 Structure of the Overview perspective . . . . . . . . . . . . . . . . . . . . . 162
6.7 Tool bar icons of the Test Project view . . . . . . . . . . . . . . . . . . . . . 163
6.8 Status indicators of the Test Project view . . . . . . . . . . . . . . . . . . . 165
6.13 CLANG parser options and descriptions . . . . . . . . . . . . . . . . . . . . 168
6.18 Status indicators of inherited test cases or test steps . . . . . . . . . . . . . . 173
6.23 Test Execution Settings - Actions . . . . . . . . . . . . . . . . . . . . . . . . 175
6.24 Test Execution Settings - Options . . . . . . . . . . . . . . . . . . . . . . . 176
6.31 Reports available within TESSY . . . . . . . . . . . . . . . . . . . . . . . . 183
6.34 Available settings of the reports . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.44 General tab of the Properties view . . . . . . . . . . . . . . . . . . . . . . . 192
6.48 Optional functions of the Sources tab of the Properties view . . . . . . . . . 195
6.55 Tool bar icons of the Test Items view . . . . . . . . . . . . . . . . . . . . . . 202
6.56 Status indicators of the Test Items view . . . . . . . . . . . . . . . . . . . . 204
6.64 Tool bar icons of the Console view . . . . . . . . . . . . . . . . . . . . . . . 212
6.70 Structure of the C/C++ perspective . . . . . . . . . . . . . . . . . . . . . . 218
6.73 Tool bar icons of the Outline view . . . . . . . . . . . . . . . . . . . . . . . 222
6.75 Structure of the Requirement Management perspective . . . . . . . . . . . . 225

430 TESSY 4.0 Manual

 D List of Tables

6.76 Tool bar icons of the RQMT Explorer view . . . . . . . . . . . . . . . . . . . 227

6.77 Status indicators of the RQMT Explorer view . . . . . . . . . . . . . . . . . 227
6.82 Possible formats of requirement sources . . . . . . . . . . . . . . . . . . . . 230
6.87 Tool bar icons of the Requirements List view . . . . . . . . . . . . . . . . . . 235
6.88 Tool bar icon of the Requirements List view . . . . . . . . . . . . . . . . . . 235
6.93 Tool bar icons of the VxV Matrix view . . . . . . . . . . . . . . . . . . . . . 239
6.94 Tool bar icons of the Test Means view . . . . . . . . . . . . . . . . . . . . . 240
6.95 Tool bar icons of the Link Matrix view . . . . . . . . . . . . . . . . . . . . . 241
6.96 Status indicators of the Suspicious Elements view . . . . . . . . . . . . . . . 241
6.103 Tool bar icons of the Suspicious Elements view . . . . . . . . . . . . . . . . 246
6.106 Tool bar icons of the Attached Files view . . . . . . . . . . . . . . . . . . . . 250
6.107 Tool bar icons of the Attributes view . . . . . . . . . . . . . . . . . . . . . . 251
6.110 Tool bar icons of the History view . . . . . . . . . . . . . . . . . . . . . . . 254
6.112 Tool bar icons of the Differences View . . . . . . . . . . . . . . . . . . . . . 256
6.113 Icons of the content menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
6.114 Tool bar icons of the Document Preview . . . . . . . . . . . . . . . . . . . . 260
6.116 Tool bar icons of the Requirements Coverage view . . . . . . . . . . . . . . . 262
6.117 Tool bar icons of the Planning tab . . . . . . . . . . . . . . . . . . . . . . . 263
6.118 Tool bar icons of the Execution tab . . . . . . . . . . . . . . . . . . . . . . . 263
6.123 Structure of TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
6.124 Tool bar icons of the TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6.125 Status indicators of TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
6.130 Contents, functions and storage location of configuration files . . . . . . . . 275
6.136 Meanings of flags in the attribute properties . . . . . . . . . . . . . . . . . . 281
6.138 Structure of TIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6.139 Icons of the Interface view . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
6.140 Status indicators of the Interface view . . . . . . . . . . . . . . . . . . . . . 285
6.144 Possible passing directions of the interface elements . . . . . . . . . . . . . . 288
6.160 Icons of the Plot Definitions view . . . . . . . . . . . . . . . . . . . . . . . . 297
6.162 Drag and drop handling with the Plots and Plot Definitions view . . . . . . . 298
6.164 Structure of the CTE perspective . . . . . . . . . . . . . . . . . . . . . . . . 301
6.165 Tool bar icons of the Classification Tree view . . . . . . . . . . . . . . . . . 303
6.166 Structure of Classification Tree view . . . . . . . . . . . . . . . . . . . . . . 304
6.178 Structure of TDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
6.179 Tool bar icons of the Test Data view . . . . . . . . . . . . . . . . . . . . . . 316
6.180 Status indicators of the Test Data view . . . . . . . . . . . . . . . . . . . . . 317
6.181 Interface elements and icons of the Test Data view . . . . . . . . . . . . . . 318
6.193 Options of initializing values . . . . . . . . . . . . . . . . . . . . . . . . . . 325

TESSY 4.0 Manual 431

D List of Tables

6.194 Initialization values for data types . . . . . . . . . . . . . . . . . . . . . . . . 326

6.196 Evaluation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
6.205 Value assignments for pointers . . . . . . . . . . . . . . . . . . . . . . . . . 334
6.217 Available types of evaluation macros . . . . . . . . . . . . . . . . . . . . . . 344
6.218 Operators of evaluation macros . . . . . . . . . . . . . . . . . . . . . . . . . 345
6.224 Structure of CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
6.231 Tool bar icons of the Test Items view . . . . . . . . . . . . . . . . . . . . . . 361
6.233 Elements of the Flow Chart view . . . . . . . . . . . . . . . . . . . . . . . . 362
6.237 Structure of the IDA perspective . . . . . . . . . . . . . . . . . . . . . . . . 371
6.238 Status indicators of test objects . . . . . . . . . . . . . . . . . . . . . . . . . 371
6.248 Status indicators of the Interface view of a component test . . . . . . . . . . 380
6.258 example: possible evaluation results . . . . . . . . . . . . . . . . . . . . . . 387
6.266 Excerpt of the possible commands of the command line interface . . . . . . . 395

7.7 Information to log and add to TESSY Support File . . . . . . . . . . . . . . 402

432 TESSY 4.0 Manual

Index

Advanced Stub Functions, 293, 324 Cloning a project, 25

Advanced Stubs, 293, 324 Code Coverage, 414
Assigning changed Interface, 107 Command Line Interface, 393
Attributes Committing Requirements, 231
Adding, 279 Compare View, 107, 372
Editing, 279 Compiler, 272
View, 251 GNU GCC, 72, 272
GNU GCC (C++), 272
Backup, 389
Component Functions, 414
Location, 24
Component Functions View, 380
Batch
Component Testing, 414
Operation, 186
Config File, 19
Test, 186, 414
Configuration
Branch Coverage View, 86, 365
Enabling, 276
C Code Configuration File, 19, 22, 274
Editing, 342 Assigning a, 281
Entering, 341 Console View, 211
C-source file Context Menu, 37
Analyzing the, 73 Coverage
Editing the, 103 Branch Coverage, 177, 196, 354, 414
C/C++, 217 Code, 414
C1 Test, 414 Decision Coverage, 177, 196, 354
Check-out TESSY Floating License, 11 Entry Point Coverage, 177, 196, 354
CLANG Parser, 166 Function Coverage, 177, 196, 354
Classes Instrumentation, 155, 177, 196, 354
Creating, 304 Measurements, 155, 196, 354
Classification Modified Condition / Decision Co-
Creating, 304 verage, 177, 196, 354, 415
Tree, 414 Multiple Condition Coverage, 177, 196,
Tree Editor, 300 354
Tree View, 302 Safety Standards, 155

TESSY 4.0 Manual 433

Index

Settings, 155, 177, 196 Expected Values, 415

Statement Coverage, 177, 196, 354 Exporting
Viewer, 85, 354 Coverage Instrumentation Settings, 155
CTE, 300 Test Data, 189
CV, 85, 354 External Function Calls View, 131

Data Format File System, 19

Setting the, 289 Flow Chart, 360
Database Location, 24 Flow Chart View, 86
Database Update, 29 Format
Debugger, 414 Data (TIE), 289
Decision Coverage View, 366 Formats
Declarations/Definitions View, 336 Requirements, 230
Delete Function Coverafe (FC), 355
Compiler, 270
Generating
Environment, 270
Test Cases, 205, 329
Folder, 37
Test Driver, 174
Module, 37
Generator Test Case, 205, 329
Target, 270
GNU GCC (C++) Compiler, 272
Test Case, 37
GNU GCC Compiler, 72, 272
Dialog Settings, 155
Differences View, 248, 254 Heartbeat Function, 126
Directories Settings, 155 Help
DO-178B, 155 by Problems, 398
Menu, 160
Edit Source, 103
Hysteresis, 415
Editing
HTML of Requirements, 260 IDA, 102, 370, 415
Editor View, 219 IEC 61508, xxiii, 155
Entry Point Coverage (EPC), 355 Importing
Enums, 322, 415 Coverage Instrumentation Settings, 155
Equally Named Projects, 27 Requirements, 92
Eval Macros, 342 Test Data, 189
Eval Modes, 327 Inheritance of attributes, 269
Evaluation Inherited Values, 332
Macros, 342 Inline Mode, 321
Macros View, 211 Input Values, 415
Modes, 327 Instrumentation Settings, 177
Executing a Test, 174 Integration Testing, 415

434 TESSY 4.0 Manual

 Index

Interface TIE, 76, 282

Changes, 102 Perspective Bar, 32
Data Assign Editor, 102, 370 Plot Definitions View, 296
Description, 415 Plots
ISO 26262, xxiii, 155 View, 351
Pointers, 290, 333
License Key File, 5 Project
License Key Request, 5 Clone a, 25
License Transmit, 13 Creating a, 20
Link Matrix view, 240 Database, 19
Location Directory, 26
Backup, 24 Equally named, 27
Database, 24 Location, 24
Project, 24 Root, 19, 74
Settings, 155
Maximum Criterion, 55
Template, 26
MC/DC, 415
Project Explorer View, 220
MC/DC Coverage View, 86, 367
Prolog/Epilog View, 337
MCC Coverage View, 369
Properties View, 191, 283, 314
Menu Bar, 31
Minimum Criterion, 55
Registration, 5
Module, 72, 416
Regression Testing, 102, 370, 416
Module Testing, 416
Rename, 37
Multiple Stub Calls, 324
Renumbering Test Cases, 209

Outline View, 221 Repeat Count, 337

Output Values, 416 Report

Overview Perspective, 72, 161 Creating a, 90, 182

Directories, 155
PDBX-File, 19 Execution Coverage, 182
Perspective, 32 Names, 155
C/C++, 217 Planning Coverage, 96, 182
CTE, 300 Test Details, 90, 182
CV, 85, 354 Test Overview, 182
IDA, 102, 370 Requirement, 416
Overview, 72, 161 Alias, 233
Requirement Management, 92, 224 Committing, 231
SCE, 376 Coverage, 261
TDE, 79, 312 Creating, 225
TEE, 72, 266 Editing, 237

TESSY 4.0 Manual 435

Index

Engineering, 225 Status Bar, 36

Formats, 230 Stub
Functional, 416 Advanced, 293, 324
HTML Editing, 260 Creating, 293
Import, 228 Functions, 174, 291, 416
Importing, 92 Stub Functions View, 346
Linking of, 261 Support, 398
Management, 92, 223, 416 Support File, 398
Non-Functional, 416 Suspicious Elements, 244, 245
Renaming Document, 233 System Testing, 417
Sources, 230
Versioning of, 254 Target, 272
Requirement Editor View, 235 Target Passing, 290
Requirements List View, 234 TDE, 79, 312, 417
Restore, 389 TEE, 72, 266
Reuse, 102, 370 Template Project, 26
RQMT Explorer View, 93, 225, 230 TESSY Support File, 398
Running a Test, 174 Test
Definition, 417
Save Data, 389 Definition View, 335
Saving Changes, 32 Driver, 417
SCE, 376 Environment, 417
Scenario Editor, 376 Environment Editor, 72, 266
Search Filter Function, 181 Execution, 174
Search Query, 416 Interface Editor, 76, 282, 417
Settings Items View, 77, 201
Coverage, 155 Means view, 239
Dialog, 155 Project View, 72, 162
Directories, 155 Regression, 416
Project, 155 Results View, 210
Report, 155 Run, 174, 417
Shortcuts, 37 Suite, 417
Source System, 417
Analyzing the, 73 Test Case, 417
Editing the, 103 Generator, 205, 329
Root, 22 Renumbering, 209
source file Test Data
Adding a, 193 Editor, 79, 312, 417
Statement Coverage View, 364 Exporting, 189

436 TESSY 4.0 Manual

 Index

Importing, 189 Document Preview, 259

View, 315 Editor, 219
Test Object, 75, 417 Evaluation Macros, 211
Changing Interface, 103 External Function Calls, 131
External Functions, 286 Flow Chart, 86
External Variables, 286 History, 254
Global Variables, 286 Interface, 76
Local Functions, 286 Link Matrix, 240
TIE, 76, 282, 417 MC/DC Coverage, 86, 367
Tool Bar, 32 MCC Coverage, 369
Troubleshooting, 398 Outline, 221
Type Information, 283, 314 Plot Definitions, 296
Type Modifier, 283, 314 Plots, 351
Project Explorer, 220
Union, 321 Prolog/Epilog, 337
Unit, 417 Properties, 72, 191, 283, 314
Updating a database, 29 Related Elements, 256
Usercode, 337, 350, 418 Requirements Coverage, 261
TS_CALL_COUNT, 348 Requirements Editor, 235
TS_CURRENT_TESTCASE, 338, 347 Requirements List, 234
TS_CURRENT_TESTSTEP, 338, 347 Reset Position, 34
TS_REPEAT_COUNT, 338 RQMT Explorer, 93, 225, 230
Usercode Outline View, 350 Statement (C0) Coverage, 364
Stub Functions, 346
Variant Management, 168 Suspicious Elements, 245
Inherited Values, 332 Test Data, 79, 315
Vector Values, 324 Test Definition, 335
Version Control, 231, 236, 237, 389 Test Items, 77, 201
View, 33 Test Means, 239
Attached Files, 250 Test Project, 72, 162
Attributes, 251 Test Results, 210
Branch (C1) Coverage, 86, 365 Usercode Outline, 350
Classification Tree, 302 VxV Matrix, 238
Compare, 107, 372 Work Task Configuration, 380
Component Functions, 380
Console, 211 Work Task Configuration View, 380
Work Tasks, 132, 380
Decision Coverage, 366
Workspace, 19, 418
Declaration/Definition, 336
Differences, 248, 254

TESSY 4.0 Manual 437