Search tips

apple banana
Find rows that contain at least one of the two words.

+apple +juice
Find rows that contain both words.

+apple macintosh
Find rows that contain the word 'apple', but rank rows higher if they also contain 'macintosh'.

+apple -macintosh
Find rows that contain the word 'apple' but not 'macintosh'.

+apple ~macintosh
Find rows that contain the word 'apple', but if the row also contains the word 'macintosh', rate it lower than if row does not. This is "softer" than a search for '+apple -macintosh', for which the presence of 'macintosh' causes the row not to be returned at all.

+apple +(>turnover >strudel)
Find rows that contain the words 'apple' and 'turnover', or 'apple' and 'strudel' (in any order), but rank 'apple turnover' higher than 'apple strudel'.

Find rows that contain words such as 'apple', 'apples', 'applesauce', or 'applet'.

"some words"
Find rows that contain the exact phrase 'some words' (for example, rows that contain 'some words of wisdom' but not "some noise words").

By continuing to use this site you agree to the use of cookies. For more information and to find out how to change this click here. Accept Cookies
Please enable cookies in your browser for this website.
Advanced search

Configuration Management and Simultaneous Work on a vTESTstudio Project

Last updated: 2019-05-20

For the configuration management of a vTESTstudio project the following facts and policies apply:

  • Work on a vTESTstudio project is file-based. All test design sources as CAPL and C# code, test tables, parameters and so on are stored as files on the file system.
  • These files can be managed by the use of common configuration management systems (e.g. Subversion).
  • At least the following files have to be checked-in into the configuration management system:
    • vTESTstudio project file (*.vtsoproj)
    • Trace item file (*.vtraceitem)
    • Variant property file (*.varprop)
    • Test case attribute file (*.vattribute)
    • Files for test system variables that are not directly stored in the project file (*.vsysvar)
    • Files of the test design editors (*.can, *.cs, *.vtt, *.vtsd, *.vsd)
    • Parameter files, waveform files and classification tree files (*.vparam, *.vwf, *.vct)
  • Depending on the test design and test execution workflow in a department it might be necessary as well to check-in the following files:
    • Executable test unit (*.vtuexe):
      If a colleague, who has no vTESTstudio license, shall execute the test unit in CANoe, the executable test unit has to be checked-in as well. This might also be necessary if continuous testing (e.g. via Jenkins) is used.
    • Database, system variables and diagnostic description files of the system environment (*.dbc, *.arxml, *.cdd, …):
      These files are used both from within the vTESTstudio project and the CANoe configuration. They have to be managed within the configuration management system either together with the vTESTstudio project or the CANoe configuration (in case they are not located on a network drive).
  • The following files do not have to be checked-in:
    • Folder obj_<vTESTstudioProjectName> (temporary files)
    • User settings file (*.settings)

For the simultaneous work on a vTESTstudio project under version control the following policies apply:

  • Even if the vTESTstudio project file (*.vtsoproj) is a XML file, conflicts can arise if this file needs to be merged. Therefore modifications to a project file should only be done by a single user at a time. The file should be locked in the configuration management system while being modified.
  • Changes in the project file are caused by:
    • Changes in the project tree, e.g. add/rename/delete of test units and add/rename/delete of files
    • Changes in the Library View, i.e. add/rename/delete of libraries
    • Changes in the system environment, e.g. add/rename/delete of networks or database references
    • Changes in variant properties
    • Changes in test case attribute definitions
    • Changes in test system variables stored within the project file
  • Simultaneously working on a project in general is not a problem in case the users are not working with the same files. E. g. one user can make changes in a parameter file, while another user changes the graphical design and a third user edits a CAPL script.
  • Program files (CAPL, C#) and parameter files are text-based files. They can be merged by the use of a configuration management system.
  • Files like test tables, test diagrams, waveforms and classification trees are XML-based, but not meant to be merged automatically or manually. It must be avoided that several users work simultaneously with those files.
  • To avoid possible issues when working with more than one user at the same project file, - besides locking the project file - it could be an option to create multiple vTESTstudio projects. Within these projects the library concept can be used to utilize the same source files.
Article Options
Views: 3267