What is MTest?

What's new?

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

New approach in Configuration Management
The test project configuration has become easier and more convenient, the configuration setup can also be saved and distributed, which enables standardized configurations within a team or organization.

MARS requirements included in test documentation

Change Impact Analysis on MARS Requirements

► Read about all new features in the Release Notes

System requirements

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

• Matlab^® R2011b to R2018b
• 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: Excel^® 2003 and higher
• Please note: When working with Testwell CTC++, Microsoft Visual Studio^® 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+

Update to the latest version

• You should keep a backup of your old MTest installation (simply rename the MTest directory to MTest_x using the "old" version number)
• Then proceed according to the installation instructions given below. 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 can reuse all your project settings directly (they are not part of the program installation).
• When using a floating license and changing from MTest 3.x to 4.x, please copy your license configuration to the new major-version-specific MTest lismo directory (see MTest client configuration above; use subdir 4_0 instead of 3_0).

Installation

• If you receive MTest in one zip file, please extract it into a folder. Please keep all the subdirectories.
• Suggestions:
  • D:\Programme\mtest
  • x:\project\matlab\mtest
  • %MATLAB_ROOT%\toolbox\mtest
• Include the ...\mtest\bin directory into your MATLAB Path (only the \bin directory).
• See also Chapter 2 of the User Guide

Quick start

• Open MATLAB^®, navigate to the MTest installation directory and execute >> mtm
• 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.0 (December 2019)

New Command for Starting MTest

• Now, MTest can be started using the command >> mtest. This opens the main GUI and loads the most recent project. To start MTest without any project being loaded, use the command >> mtest('none').

New Configuration Management

• With the new release of MTest, we now provide a method for configuring your test projects more conveniently. You can define configurations on each available test level, i.e. test project, test model, test object, test group, and test sequence, respectively. Furthermore, you are given the opportunity to refer to an external configuration so that test project setups can be standardized to provide a global/company-wide configuration. However, configuration parameters can be overwritten through specific test level configurations. This new management supersedes configurations that - in the past - have been specified within the MTest_UserPrefGUI.m and the MTc_RCToptProjectSettings.m, respectively. In addition, the configuration parameters are also grouped within categories so that options can be found more easily. You can access the configuration management from the menu bar of MTest main GUI via "Organization / Manage Project Configuration". The first time you open the new MTest it care of migrating previous configurations.

Integration of MARS Requirements into the Test Documentation

• Now, requirements that have been formalized with MARS are represented in the requirements catalog. An overview of the particular MARS artifacts related to the requirement is now provided. In conjunction with the new configuration management, you can now define the source of requirements that shall act as the reference for traceability and metric computation. Available options are:

• External requirements (e.g. as imported via Excel)
• MARS formalizations (e.g. as created with the MTest Specification Editor).
Therefore, the requirement catalog was enhanced to support documentation for users that work with MARS formalizations only. In order to generate this updated catalog representation for existing test project you are advised to save your existing MARS document again.

Change Impact Analysis Available for MARS Requirements

• With regard to requirement changes, MTest can now automatically update the attributes "description" and "status" of the MARS formalizations that link to a changed requirement. For MARS formalizations affected by a change, its "description" attribute will automatically reflect the new requirement description. Similarly, the "status" attribute changes to 'reqchanged'.

Online Parameter Modification for SiL Tests of TargetLink Models

• TargetLink users can now speed up SiL testing by taking advantage of online parameter modifications, which render the regeneration of code unnecessary in case of parameter variations within test sequences, i.e. code is generated only once per test object. The feature is enabled by activating the respective checkbox in the MTest batch test GUI. Please note: This feature is only available to users of TargetLink 4.0 and newer.

Test Case Generation by Variation of Synced Lists

• Users of the test case variation feature can now mark lists of variation points that are kept in sync during test case generation. Such lists will be not considered for a full combination, instead those value groups enter the combinatorics as single-entries.

Further Enhancements of MARS

• Now, MARS supports unrestricted use of nested "defines", i.e. event defines are available to state define and vice versa. Nested defines do work recursively, as well.
• The status tags 'new' and 'proposed' became deprecated. A quick fix solution is available in the MTest Specification Editor. The following mapping is used to replace the old values in order to ensure consistency to MTCD documents and assessment files:
• 'new' -> 'created'
• 'proposed' -> 'described'
Also, MARS users can now make use of value tolerances within the expression 'change with a slope [+- myValue]'.

Adaptions Assessment Utility Functions

• The following assessment utility functions are now capable of handling vectors containing NaN values:
• MTa_differentiate
• MTa_isFall
• MTa_isRaise

Bug Fixes

• Fixes the issue of the model coverage aggregation slowing down the simulations within the batch test. Now, the model coverage is aggregated after the execution of the last test sequence of the batch run. This works even when not all test sequences of a test group have been selected. Note: Aggregation is not performed if the batch test is aborted by the user by clicking the "Stop" button. (#7313)
• Fixes an issue where the testbed's Simulink Data Dictionary could not be found although it was present and linked to the testbed model file. (#7339)
• Fixes a bug where names of logged signals containing blanks, new lines and/or special characters could not be displayed properly in the MTest Specification Editor. In the past this could have yielded syntax errors within *.io files. (#7407)
• Fixes the issue of not showing a blank "Project Settings" window in case a project was actually loaded in MTest. Instead of empty attribute fields, those fields showed the content of the currently loaded project. This caused confusion with users thinking they change the current project settings. (#7431)
• Fixes the issue where the source model was compiled during each test sequence import. This significantly slowed down the entire import process. (#7463)
• See #7463. (#7464)
• Fixes an issue where parameters of type Enumeration have erroneously been casted to double. (#7487)
• Fixes an issue where the simulation of test beds - using a a variable-step solver - in the base workspace yields a time vector unequal to the length of the signal output output vector(s). (#7592)