Forum Discussion

kirk_bottomley's avatar
kirk_bottomley
Contributor
11 years ago
Solved

Different Variable Values For Different Workstations


I do apologize for asking this question again, but I still can't find out how to do this, and the lack of this one technique is holding up our ability to integrate TC in our process.



 We have one machine to write tests, and five TestExecute licenses to run the tests on individual workstations. Each workstation can, and do, have the applications being tested installed in a myriad of paths. They also use different SQL servers, setups, etc. so I put as much information in Project Suite variables as I could, with the plan of modifying each workstation's copy of the variables to suit it.



 As I understood it, when a workstation opens a project in shared mode, a folder is created for that workstation (and is), where it would have its own version of Project and Project Suite variables. There are two files, (project).mds.tcLS and (project).pjs.tcLS, that apparently have the variable names, but the values themselves are encoded.



 As it stands, the only machine we have that can successfully run the tests written is the machine that wrote them, because I'm unable to customize the variables for each workstation. How can I accomplish this?


6 Replies

Sort By
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    11 years ago
    Hi Kirk,



    Unfortunately, TestExecute has no means to edit Project/Project Suite/Network variables as well as enable/disable test items (which are also per-user in the networked mode). Also it is not possible to manage (add/delete) from the master machine test logs (even from TestComplete) that were created on another machine when running tests in networked mode using TestExecute. Logs can be managed only from the machine that they were created on. (Obviously, I am not talking about direct edit of the relevant configuration files, but in order to do this you must either ask Support or discover by yourself what encoding is used by TestComplete.)



    The bad news is that the above is not going to be changed and thus you basically have only two options:

    a) Write a code like in the sample provided by Kateryna that will correct the values of the variables; or

    b) Write a code that will read variables' values from the file and assign them (values) to the variables.
  • Kateryna's avatar
    Kateryna
    Contributor
    11 years ago
    Hi there!



    If I understood you properly, I had the same issue. I  had problems with DBTabled because they use exact name of the workstation. I wrote a small script that changes that name (name in the connection string) into the name of the current computer (Delphi script):




    procedure Test;


     var i, tbls, tablename, computername;


     begin


       tbls := aqObject.GetProperties(DBTables);


       computername:= Sys.HostName;


       for i := 0 to tbls.Count - 1 do


       begin


         tablename:= tbls.Item(i).Value; 


         tablename.ConnectionString := 'Provider=SQLOLEDB.1;'+'Integrated Security=SSPI;'+'Persist Security Info=False;'+'Initial Catalog=NL3_TestComplete;'+'Data Source='+computername;


       end;


     end;



    I guess you can do something similar in your case. This script works during test execution. 

  • kirk_bottomley's avatar
    kirk_bottomley
    Contributor
    11 years ago


    Thanks for the response, Kateryna! Unfortunately, that's not the issue I'm having. My issue is more related to the use of variables in TestExecute distributed tests.



    What I want to do is write tests and scripts using Project and ProjectSuite variables that relate to SQL server names and installation paths, as well as different test data. Then when I open that project using Test Execute on the different workstations, be able to assign values to those variables for each workstation.



    As an example, we have different paths for where the program being tested is installed depending on if it's a 32 or 64 bit windows machine. Of course, the clients can install wherever they want as well.

    So when I write a test that uses data in the installation path, I "soft code" it, and retrieve the actual path at runtime from the variable. It works for Machine X, where I wrote the test, because I can change the variables right from the ProjectSuite workspace, but Machine Y running TestExecute has it's own needs, and I don't know where to change Machine Y's instances of the ProjectSuite variables.



    I'm not sure I'm explaining it clearly, and I wouldn't be surprised if I'm doing it completely wrong.