Forum Discussion

slecault's avatar
slecault
Contributor
13 years ago

Visualizer pictures

The idea of having a picture of each intervention (keyboard, mouse) is nice, but the storage...



I am looking for a way within the code, or after a run has completed to gather all the new pictures.  These should be grouped by scenarios (directories) and numbered with a sequence starting a 0001 for each group. The "_Diff" and "original files would be excluded in my case, mainly because the original source is unknown and the update is not an option for me (way to slow). Also, more than one file can have the exact same time including the seconds, so a regular sort does not work.



I would like to compare these with previous runs when a problem occurs or for in depth comparison



Presently I have arround 50 tests scenarios and I end up with over 4 thousand files in the same directory.  The project is just beginning, we will have a few thousands of scenarios, will I have to turn off that "visualizer feature?  Running automated tests, I cannot predict where errors will occur, it does help to look at pictures to see what happened.



Are there any plans to improve this feature or suggestions to get these results?

9 Replies

Sort By
  • AlexeyK's avatar
    AlexeyK
    SmartBear Alumni (Retired)
    13 years ago

    Stephane,


    You are right that the images take space on the disk. That is why, we recommend to disable Visualizer after you create and debug a new test and it went into "production". The purpose of Test Visualizer is to let you understand what happens in the application, when you are creating a new test, or when you are trying to fix an error and need screenshots for this.


    TestComplete projects include the Post image on error setting that is enabled by default. It commands TestComplete to post the screen image to the log when an error occurs. To view the setting, right-click your project in the Project Explorer and select "Edit | Properties" from the context menu. This will invoke the project editor and activate its Properties page. Select the Playback category on the left, and you will see the Post image on error property on the right, at the bottom.

  • slecault's avatar
    slecault
    Contributor
    13 years ago
    One useful feature would be to have the choice of what is stored with visualizer:

    __ Picture

    __ XML



    This choice would apply also to the playback update.  For my part, I would turn off XML files in visualizer that are way larger than pictures and slowing down the process to a none usable feature.  The remaining pictures would give me a kind of on screen documentation of my tests.  The playback/update would also be useful after copying/inserting code (because no picture are besides the new lines).



    So I am asking SmartBear team is this something feasible in a future release?
  • AlexeyK's avatar
    AlexeyK
    SmartBear Alumni (Retired)
    13 years ago

    Stephane,


    Thank you for the suggestion.


    XML files are created on test recording, or on updating Visualizer images. Currently, we are discussing an approach to archive (zip) .xml files. This will reduce their overall size 10-30 times. Do you think this would be acceptable for you?

  • slecault's avatar
    slecault
    Contributor
    13 years ago
    The size of these XML files is at the center of an issue that I have reported to support.  When I create a new script for my Delphi application, each step (key or mouse) generates an XML of approx. 430KB.  When I try to update (visualiser) one of these scripts during playback, each XML files goes to 6700KB (there was an improvement to reduce the size of the files but it is still to slow to use). 



    A running script that took 30 seconds to run takes between 3-4 minutes to update.  This is simply unusable for me, my script times out most of the time.  And our obejective is between 1500-2000 scripts, so 3 minutes each...



    So zipping the xml would be good, but won't help me. Still the choice could be left to the user to select what is kept (XML, JPG or both or none).   I do not understand why during playback/update the xml is different and bigger than when initially created.
  • AlexeyK's avatar
    AlexeyK
    SmartBear Alumni (Retired)
    13 years ago

    Stephane,


    The size of these XML files is at the center of an issue that I have reported to support.  When I create a new script for my Delphi application, each step (key or mouse) generates an XML of approx. 430KB.  When I try to update (visualiser) one of these scripts during playback, each XML files goes to 6700KB (there was an improvement to reduce the size of the files but it is still to slow to use).


    As far as I know, this is a known issue. I spoke to several developers, and they said they were working on it, and it would be fixed in one of future releases.

    However, I'd suggest that you contact our Support Team and send them a sample test project, a sample application and a problem description, so that the guys could check whether everything works fine for you.


    Still the choice could be left to the user to select what is kept (XML, JPG or both or none).


    I have registered your query in our database as a suggestion. We need to analyze the situation and decide what we can do.

  • slecault's avatar
    slecault
    Contributor
    13 years ago
    I did report the issue to support .  I did provide the XML result of "creation" and "update".  I cannot provide an example, my application is a Delphi client running on my pc talking to AS/400 server.  The application won't start if it does not have the server partner on the appropriate level.



    I was provided a patch which showed improvement, but the files were still too big, and the was still too slow.



    I could try other patches if available and provide timing and size result using my scripts.



    Ref:

    RE: [Issue# M0092005] Web Submission - Auto-update frames during run
  • AlexeyK's avatar
    AlexeyK
    SmartBear Alumni (Retired)
    13 years ago

    Stephane,


    As far as I know, after applying the patch, the size of .xml files is increased only once (when you run the tests for the first time after installing the patch). This happens because the patch gathers more data than TestComplete does. The file size doesn't increase in subsequent runs. Do you still notice the increase after each run? If you do, tell me how much it is. Which TestComplete version do you use?


    As for the update speed, how often do you run tests in the Auto-update mode? Is it possible to turn off auto-update? Is the speed acceptable after you turn it off?


    You said you would like to have Visualizer images to find the cause of an error, if any. TestComplete captures images for test commands that simulate user messages and post event messages to the log. So, you can try using the Save last N events project property (double-click your project in the Project Explorer to open the project editor, then go to Properties -> Playback). This setting specifies the number of events to be saved in the log before an error message is posted. Assign some value, say 5 or 10, to the property. This number of images should be enough to understand what went wrong, and the images will not occupy much space on your hard drive...

  • slecault's avatar
    slecault
    Contributor
    13 years ago

    Here are some test results gathered using my scripts over my tested Delphi application.  The tested application has changed a little bit between orignal creation and today's update, but not enough to justify the changed sizes in XML files.


    I am using TestComplete 8.70.727.7, as for the patch... I am not sure, but the resulting xml are similar to a version including the patch.  I am not sure if the fix you ment is included in 8.70.


    For a script using screens with a lot of controls and properties (Add_PoidsTaille_Metric):


    Visualiser       Running         XML

    Mode            Time                size/capture

    ------------    ----------    ---------------

    On                    34 sec.       

    Off                    24 sec.

    Update/create    169 sec.    original XML goes from 564KB to 982KB


    For having a look at this kind of updates before, some controls seemed more than once in the XML.


    The same kind of update for a less intensive screen is more acceptable. (EnqProduitDIN_08):


    Visualiser       Running         XML

    Mode            Time                size/capture

    ------------    ----------    ---------------

    On                    47 sec.       

    Off                    20 sec.

    Update/create    60 sec.    original XML goes from 109KB to 196KB


    The majority of my script go trough the main screen with lots of controls, so the update speed for me is not good.


    The speed is acceptable when I am not using Update mode.  These scripts will run a few times a week, as for the updates, it would probably be every month or so.


    I will try the "save envents before error message posting".

  • AlexeyK's avatar
    AlexeyK
    SmartBear Alumni (Retired)
    13 years ago

    Stephane,


    Thanks a lot for gathering this performance statistics. It is expected that Visualuzer works slower in update mode, but I agree that in your first case, the time spent looks a bit strange. Most likely, this happens, because of the large number of controls on the tested form. I passed your information to developers. They will explore the situation and see what can be improved. We'll notify you, when we have some results.