Forum Discussion

clay's avatar
clay
Contributor
7 years ago
Solved

Why does TestComplete to "hang" during certain actions?

I have noticed that TestComplete appears to "hang" or have long delays during certain actions.  Specifically, I have noticed at these times:

 

1.  Playback during test execution.  What does it mean when the progress bar says "Playback" during the execution of a test?  Sometimes there are short delays, but then TestComplete will be delayed for minutes at a time waiting on "Playback".  What is going on during "Playback"?

 

2.  After a keyword test completes its execution and I am waiting for the log to be displayed, it seems to take a very long time to produce the log report.  At times, TestComplete goes into a "flickering" mode, where the controls on the application seem to flash on and off very fast.  The flickering does not stop until I activate another application and then return to TestComplete.  When I reactivate TestComplete the flickering stops and the log report is generated rather quickly.

 

3.  Sometimes the test application will lock up.  TestComplete will do likewise and gridlock is not broken until I kill either TestComplete or the application.  sometimes I have to kill both applications.

 

If anyone has any insight into what the underlying causes are, I would greatly appreciate your thoughts.

  • tristaanogre's avatar
    tristaanogre
    7 years ago
    clay wrote:

    With respect to #1 - is it possible that the name mapping criteria is confusing TC, causing it to have to look harder to find an object before it can push something? 

     

    The procedures where I am seeing this behavior do not have any looping going on (yet).  However, the application we are testing creates and destroys GUI objects dynamically during run-time.  Furthermore, the object types and settings are fairly generic, so I have found the name mapping aspect for this test system to be a challenge.

    Well, locating an object that is mapped is, kind of, an internal loop, especially if you are using the Extended Find feature of NameMapping.  Basically, if you have a button that, natively, is something like.

     

    Sys.Browser.Page('http://www.test.com'').Panel(0).Panel(0).Table(0).Cell(1,1).Panel(1).Table(1).Cell(1,3).SubmitButton('Save')

    the Extended find feature with NameMapping could reduce this to

     

    NameMapping.Sys.browser.pageTest.buttonSave

    Basically, all those panels and tables and cells, since they aren't strictly necessary for interacting with the component and are non functional containers are "telescoped" and you will see buttonSave have the "Extended Find" flag checked beside it.  In this situation, TestComplete does a search down the tree from the page to the button to locate and find the button to click on it.  The more intermediate levels that are "collapsed" by the Extended Find, the longer this search can take.  So, if I remap my object as 

     

    NameMapping.Sys.browser.pageTest.Table1.buttonSave

    And have the extended find on both Table1 and buttonSave, this DOES speed up the process because it's a faster search to get to Table1.. and then a faster search from table1 to the button.  The more layers you add in between, the faster it is.  For example, I could turn off the Extended Find search on buttonSave if I map it like so.

     

    NameMapping.Sys.browser.pageTest.Table1.cell13.buttonSave

    Basically, Table1 has the Extended Find option turned on but the subsequent containing cell and button do not because they are direct children.  This is a faster search than the aforementioned one.  This is why Aliases are used instead because I can keep that mapping with the table and the cell but then collapse it back to something manageable by doing

     

    Aliases.pageTest.buttonSave

     

    So... yes... NameMapping identification could be the culprit in #1... but there are ways of correcting that by being more concientious of your mapping... and, if you start to see performance problems, go back and make adjustments.

3 Replies

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    7 years ago

    1) Basically, something is being executed in your automation work that does not have a corresponding text that is pushed to the message stack of the Indicator object.  If, for example, you have a rather long segment of script code being executed with while, for, etc., loops that take time to execute, you may see this behavior (I have that).  If you want to have some kind of indicator as to what's happening, you can 'push' text to the indicator object to display so you aren't left wondering "What's going on here?"

     

    2) I've noticed this.  It happens, for me, most often when I have a LOT of tabs open in my workspace in TestComplete.  If I only have one or two tabs open, this doesn't happen.  Don't ask my why, exactly, this makes a difference but I suspect that it has to do with needing to see if Visualizer images on edit panels need to be updated, re-organzing the tabs to insert the new log tab, etc.  Try closing all but one or two edit tabs in your workspace and see if that fixes it.

     

    3) This one happens for me as well... but usually if I'm attempting to interrupt TestComplete's test run when it's in the middle of a "Wait" call on a web page or other object.  Somehow, this throws TC into a tizzy.  I think SmartBear support is already aware of it, but I'd still report it using their support portal.

    • clay's avatar
      clay
      Contributor
      7 years ago

      With respect to #1 - is it possible that the name mapping criteria is confusing TC, causing it to have to look harder to find an object before it can push something? 

       

      The procedures where I am seeing this behavior do not have any looping going on (yet).  However, the application we are testing creates and destroys GUI objects dynamically during run-time.  Furthermore, the object types and settings are fairly generic, so I have found the name mapping aspect for this test system to be a challenge.

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago
        clay wrote:

        With respect to #1 - is it possible that the name mapping criteria is confusing TC, causing it to have to look harder to find an object before it can push something? 

         

        The procedures where I am seeing this behavior do not have any looping going on (yet).  However, the application we are testing creates and destroys GUI objects dynamically during run-time.  Furthermore, the object types and settings are fairly generic, so I have found the name mapping aspect for this test system to be a challenge.

        Well, locating an object that is mapped is, kind of, an internal loop, especially if you are using the Extended Find feature of NameMapping.  Basically, if you have a button that, natively, is something like.

         

        Sys.Browser.Page('http://www.test.com'').Panel(0).Panel(0).Table(0).Cell(1,1).Panel(1).Table(1).Cell(1,3).SubmitButton('Save')

        the Extended find feature with NameMapping could reduce this to

         

        NameMapping.Sys.browser.pageTest.buttonSave

        Basically, all those panels and tables and cells, since they aren't strictly necessary for interacting with the component and are non functional containers are "telescoped" and you will see buttonSave have the "Extended Find" flag checked beside it.  In this situation, TestComplete does a search down the tree from the page to the button to locate and find the button to click on it.  The more intermediate levels that are "collapsed" by the Extended Find, the longer this search can take.  So, if I remap my object as 

         

        NameMapping.Sys.browser.pageTest.Table1.buttonSave

        And have the extended find on both Table1 and buttonSave, this DOES speed up the process because it's a faster search to get to Table1.. and then a faster search from table1 to the button.  The more layers you add in between, the faster it is.  For example, I could turn off the Extended Find search on buttonSave if I map it like so.

         

        NameMapping.Sys.browser.pageTest.Table1.cell13.buttonSave

        Basically, Table1 has the Extended Find option turned on but the subsequent containing cell and button do not because they are direct children.  This is a faster search than the aforementioned one.  This is why Aliases are used instead because I can keep that mapping with the table and the cell but then collapse it back to something manageable by doing

         

        Aliases.pageTest.buttonSave

         

        So... yes... NameMapping identification could be the culprit in #1... but there are ways of correcting that by being more concientious of your mapping... and, if you start to see performance problems, go back and make adjustments.