Forum Discussion

blacy's avatar
blacy
Contributor
11 years ago

Executing test scripts on different servers

I am using TestComplete 10.40. I have recorded several keyword tests. I wolud now like to execute these test on a development server and then a QA server. Any thoughts on best way to do this?

7 Replies

  • karkadil's avatar
    karkadil
    Valued Contributor
    Chris, if your suggestion is to have duplicate of the tests for each environment, then this is a bad solution. 



    In case of Script tests such things as server name should be stored in the variables and during test run correct server name is read and used. Or, for instance, server name can be stored in the config file. I don't know how to achieve this in Keyword tests, but there should be a way (using variables, for instance). And I believe, it will require manual editing of the Keyword tests, not just recording.
  • Marsha_R's avatar
    Marsha_R
    Icon for Champion Level 3 rankChampion Level 3
    We have our name mapping file in source control but we always merge it manually.  When we have changes, one person in our group takes copies of all the changed files and makes one master copy.  We all test with that one and once any issues are resolved, then whoever did the merge checks it in.  
  • We have the same setup with environment details being stored in project/suite variables, but I have a TestComplete userform displayed at the beginning of the run for the user to set the values when it's run manually. I read values from a spreadsheet and let them choose from my pre-defined list and set the variables accordingly. 



    When it's scheduled (run via command line), I just don't display the form and expect the values to come in with the command line call.



    Then in my name mapping file, I've used wildcards for all environment specific objects so the test doesn't care what environment it's running against. For instance, instead of the URL for a page being mapped as "http://www.website.com/portal/index.aspx", it's mapped as "*/portal/index.aspx".



    Doing it this way, you don't have to edit the test itself (or have a duplicate copy) whenever you want  to change the environment.
  • karkadil's avatar
    karkadil
    Valued Contributor
    Install TestComplete or TestExecute on those computers and run your tests.
  • let me explain a bit better. I can point to either server. However, when I recorded my keyword tests I did on the developer server (which we call Betea). Now all the links and objects have Beta in all the links and objects names. I would like to change at a global level so our QA sever (which we call Staging) and have them run succesfully. Anyway to change at a global level. I understand LoadComplete allows to easily switch servers but their is an addtional cost for that product. Tyring to find a way to do with in TestComplete 10.40 which we have
  • chrisb's avatar
    chrisb
    Regular Contributor
    If I am understanding your issue correctly then you need two versions of the same project. One to run against your beta environment and one to run against your staging environment. If this is the case then try using source control.



    You can maintain your Beta test project scripts in one repository and a different version in another repository.



    http://support.smartbear.com/viewarticle/55775/



  • chrisb's avatar
    chrisb
    Regular Contributor
    Agreed. That's how my project is set up. Configuration stuff like test environment details are stored in the project suite variables. We have a development version of the project suite that test development is done in and then a staging version where the new and updated scripts get merged into. It's a bit of a hack as we have 2 versions of the project suite pj's file (holds project suite vars) but it works. Yes, they should really be moved out into a configuration file! How well this would work with keyword tests I don't know. I suspect there are things like the namemapping file that won't play well with source control. So, in principle having two versions of your project is valid once you move out any configuration and test environment specific stuff into variables or config files. You just have to do a lot of tricky work with figuring out which files should merge, be overwritten etc.