What is MTest?

What's New?

► Read about all new features in the release notes

Highlights in MES Test Manager^® (MTest) v.7.2

ReqIF export of MARS requirements. You can now comfortably export formalized requirements created with MARS to the *.reqif file format. This export file is created automatically when saving the *.mars file in the MTest Specification Editor.

Testbed generation now supports resolving of referenced subsystems. With this release we support referenced subsystems (as introduced in R2019b). While generating a testbed referenced subsystems are handled in analogy to referenced models, i.e. they are converted to subsystems. Additionally, we now resolve all links to libraries and/or referenced models and subsystems by default. This helps you to ensure an invariant testbed for models that make use of references.

Installation

• If you receive MTest in one zip file, please extract it into a folder. Please keep all the subdirectories.
• Suggestions:
  • C:\Programs\MTest
  • x:\project\matlab\mtest
  • %MATLAB_ROOT%\toolbox\MTest
• (Optional) Include the ...\mtest\bin directory into your MATLAB^® path (only the \bin directory, all path setting is handled by MTest).
• See also Chapter 2 of the User Guide.

If you want to run MTest and MXAM concurrently, run MTest's and MXAM's path initialization before running MTest and MXAM:

• Copy the MTest_MXAM_SideBySide.m script from the demo folder of your MTest installation. For example into your MATLAB^® startup folder.
• Change the values of the ``mxamRoot`` and ``mtestRoot`` variables to your MTest and MXAM installation locations.
• Execute the script manually or let MATLAB^® execute it on each start.
• You may now start MTest and MXAM in any succession.
• See also Chapter 2 of the User Guide.

Update to the Latest Version

• You should keep a backup of your old MTest installation (just rename the MTest directory to MTest_x using the "old" version number)
• Then proceed according to the installation instruction given above. If you use the previous MTest directory, you do not have to include the mtest\bin directory in your MATLAB^® path again.
• After installation you reuse all your project settings directly (they are not part of the program installation).
• When using a floating license and changing to a new major release (from MTest 5.x to 6.x), please copy your license configuration to the new major-version-specific MTest lismo directory (see MTest client configuration above; use subdir 6_0 instead of 5_0).

System Requirements

The following system requirements must be in place to use MTest:

• Matlab^® R2011b to R2019b
• Targetlink^® (base suite) V3.X to V4.4
• Windows^® 7, 32-bit and 64-bit versions or Windows^® 10 (for running MATLAB^®)
• System requirements when using MTest with EXCEL: Microsoft^® Excel^® 2003 and higher
• Please note: When working with Testwell CTC++, Microsoft^® Visual Studio^® or Microsoft^® Windows^® SDK is a prerequisite. The user must have write access to the compiler installation folder.
• System requirements when using MTest with CTE/TESTONA: CTE 3.x or TESTONA 4.x/5.x+

Quick Start

• Open MATLAB^®, navigate to the MTest installation directory and execute >> mtest
• During the first start up, MTest asks for your project preferences (name, short name, model directory, test directory, ...)
• See also Chapter 2 of the User Guide

Suggestions

If you have any suggestions to help us improve the MES Test Manager^® (MTest), please do not hesitate to contact us:
Email: mtest@model-engineers.com

Release Notes - MTest v.7.2 (September 2020)

• ReqIF Export of MARS Requirements
  Formalized requirements created with MARS can be exported to *.reqif file format now. The export file is created automatically when saving the *.mars file in the MTest Specification Editor.
  The file is stored alongside your *.mars file under: \\editorWorkspace\_\... _.reqif
  Info: As of yet, the specifications of defines are not exported to the *.reqif file. This will be done in a future release.
• Testbed Generation Supports Resolving of Referenced Subsystems (#7923, #7957)
  With this release we support the resolving of referenced subsystems (as introduced in R2019b) during testbed generation. Referenced subsystems are handled in analogy to referenced models, i.e. they are converted to subsystems. This only affects the testbed, there will be no changes to the source model.
• New Default Handling of Library Links and Model/Subsystem References
  When generating a testbed all links to libraries and referenced models/subsystems are resolved by default. This only affects the testbed, there will be no changes to the source model.
  The respective elements are converted to subsystems to ensure an invariant testbed. However, the behavior can be changed by means of the respective project configuration parameters. These are:
  • TargetLinkResolveRefModels - Valid options are:
  0: The testbed will refer to the original referenced TargetLink models
  1: All references to TargetLink models will be resolved (i.e. converted to subsystems)
  The default value is 1.
  • EmbeddedCoderResolveRefModels - Valid options are:
  0: The testbed will refer to the original reference Simulink/Embedded Coder models or subsystems
  1: All references to Simulink/Embedded Coder models or subsystems will be resolved (i.e. converted to subsystems)
  The default value is 1.
  • TestbedBreakLinks - Valid options are:
  0: Original links to libraries will remain in the testbed
  1: Links to libraies will be broken (i.e. converted to subsystems)
  The default value is 1.

• Improved Synchronization of Workspace and TargetLink DD (#7110, #7988)
  In order to vary parameters that are defined as Data Dictionary variables (ddv) MTest now ensured ddv parameters are synchronized with your test (sequence) data prior to each simulation. Previously, this was only handled in batch mode.
  With this release it is also ensured that the synchronization also takes place when simulating the test sequence manually via the main GUI.

• Improved Handling of Coverage Data (#8060, #8477)
  Coverage data handling is improved such that MTest will clear possibly outdated data from the project. This ensures that the test sequence and coverage reports always contain up-to-date data. This ensures that no "old" coverage data is present, for instance, in case a test sequence re-simulation has failed. You are advised to rerun your TargetLink Code Coverage simulations when updating to MTest 7.2.
  Info: Already determined code coverage data will not be deleted after the regeneration of code.

• Display Effective Interface Data in Test Sequence Report (#8335)
  The sections "Test Input" and "Test Output" of the Test Sequence Report show the respective signal data as specified in the Effective Test Interface.

• Requirements Traceability for Generated Test Sequences (#8109, #8357)
  Test sequences - generated from MARS formalizations - do also link to external requirements now. This is particularly beneficial for users that refer to external requirements as the base for requirements traceability. Please note that the requirement link of the respective MARS formalization is used.

• Ignore Coverage of Subsystems Within Libraries (#8256)
  In case subsystems to-be-excluded from coverage measurement reside within a library, those subsystems can now be ignored when using the option.

• Source for Signals Names (#8500)
  Now, the user has the possibility of specifying the source for naming the testbed's input and output signals. The selection is made using the project configuration parameter
  "SourceForSignalNaming". Valid options are:
  0: signal names are used
  1: port names are used
  The default value is 0.
  Please note: For interface bus signals it may be the case that we still have to fall back on using the respective signal names of the bus elements.

• Further Bug Fixes
  #6900:   We ensured a unique namespace of MTest-internal functions (e.g. findfiles.m renamed to MTu_findfiles.m) in order to avoid name clashes between MTest and customer (utility) functions.
  #8036:   Fixes the issue that an MTest_Configuration.m file is created in the current folder while changing from the current project to "No project selected...". Note: The configuration was empty, thus not affecting the project.
  #7235:   Fixes the issue of not opening the proper Data Dictionary (i.e of the source model) while adding a new test object to the project.
  #7920:   This solves the issue of MTest not being able to open the Model Coverage Dialog when using MATLAB R2019a and newer.
  #8123:   This fix solves the issue of not measuring the MCDC coverage when the option "ReGenerate TestBeds" is enabled during Batch Test. Instead, a default setting (Condition, and Decision Coverage) was used.
  #8146:   Fixes an issue of generated assessment whose the trigger condition contains a duration expressed by means of an equation. Now, a proper parenthesization is ensured.
  #8196:   This fix ensures the reset of the TargetLink Simulation mode when changing the test project.
  #8235:   Fixes the issue of testbeds not properly reflecting the structure of buses defined in the TargetLink Data Dictionary.
  #8285:   This fix will prevent that expected output definitions during measurement data import will be copied into output data files. Under certain circumstances, this could have led to confusing evaluation results. This safeguards that expected output definitions will have an impact on other evaluation methods.
  #8295:   Solves the error of vector length mismatch during MiL simulation. This issue could have occured for MiL simulations in fast restart mode while the Simulink configuration parameter LimitDataPoints is active. Now, we try to deactivate it.
  #8296:   Solves the "s-function not found" issue when running a Batch Run with a TargetLink model, using the Fast Restart option. In case no code was generated before, this particular combination of actions could result in the code generation not triggering during the batch run.
  #8326:   Fixes the issue where the MTCD specification document is repeatedly imported after each batch action while simulating the testbed in fast restart mode.
  #8334:   This fix catches the error that occurs while trying to open the model coverage dialog via the MTest GUI in case the Simulink Verification and Validation Toolbox or Simulink Coverage Toolbox are installed on the user's system but do not feature a valid license for those toolboxes.
  #8339:   Fixes an issue when generating assessments based on formal requirements that refer to parameters that are of integer data type.
  #8358:   Solves the issue of global simulation parameter (e.g. Variable-Step Solver) not being applied to Embedded Coder models during Batch Test.
  #8384:   Fixes an issue that lead to a crash while trying to using the MARS expression 'the system starts' within a define.
  #8393:   Fixes an issue where, in rare cases, the TargetLink code coverage data contained outdated datasets. We make sure that there is only one data set of TargetLink code coverage per test sequence. Old data, e.g. from previous runs, is not considered and thus it is made sure that the code coverage data originates from the latest test sequence execution.
  #8436   This fixes an issue where buses have not been resolved properly in order to make the individual bus elements (i.e. signals) available in the *_interface.io file.
  #8451:   This fix ensures that the testbed generation includes the automatic rescan of the testbed's TargetLink Bus Ports. Please note: To be able to rescan the ports, the testbed needs to be capable of being updated. Therefore, the testbed needs test data in order to be compilable. You may get an error message regarding a failed bus port update upon initial testbed generation. The testbed is still build correct whatsoever. You are advised to regenerate the testbeds after you have imported a test sequence.
  #8456:   See #8393.
  #8472:   Fixes an issue with the testbeds of a triggered subsystems. Here, function calls were misinterpreted as data types and thus trigger signals mistakenly underwent a data type conversion.
  #8490:   Improvement to the file header descriptions of MTest_BatchProject.m and MTest_ExecuteBatchTest.m.
  #8493:   This fix reacts to warnings during testbed generation in MATLAB 2020a due to deprecated block parameters of the Data Type Conversion block.
  #8510:   Previously, when the code generation failed, there were error messages claiming an invalid Simulink object within the testbed, that occurred in all MTest actions thereafter. This fix ensures the validity of the testbed even after a failed code generation.
  #8536:   See #8436.
  #8548:   With this fix we ensure that the TargetLink simulation mode is always set back to MiL when regenerating the testbed.