TestExecute crashes with no log produced

[chicks]

Again,  I have submitted a ticket on this but hope somebody else may have encountered this issue or have some advice and suggestions

.

The problem is that TestExecute starts running my script and then crashes at some point without producing any log.

This was originally happening every 10 days or so, but is now happening consistently on two different machines but not a third machine.    When it started happening consistently I was able to capture an error report, and SmartBear indicated that it was a problem with DDT.closedriver   I used a different excel driver and saw that test execution proceeded further before Test Execute crashed.  At that point,  I converted most of my code to use the different excel driver.  However,  the problem is still occurring.     

I am running test execute 11.3 using windows 7.   This is failing on two different machines one running 32 bit Excel and one running 64 bit Excel

Miscellaneous data:

0) 1 of 4 scripts in this project is running with no issues.  With 2 of them, I'm seeing this problem.  The third is ending early.

1) reinstalling excel on box  1 did not make any difference

2) reverting the spreadsheet (with subversion) to a version that worked earlier did not make any difference

3) I am seeing the problem on at least two different boxes , but apparently not a third

4) I am seeing the problem against multiple test environments,  i.e.  both our QA test environment and our Stagjng test environment

Any advice or questions very gratefully appreciated !

[tristaanogre]

That is VERY interesting. So it does seem like it was some sort of environmental factor playing into the problem that a re-fresh/reset of the VM image somehow corrected. Very odd.  Thanks for the update, @chicks. Here's hoping you get the rest of it sorted out.

[chicks]

I saw this again yesterday on my shiny new physical box with everything (memory, processor, etc.) maxed out.

Within a period of an hour "all" scripts started failing, with the same error  a test complete log was not being produced.

ERROR: 'TestCompleteLogs\index.htm' doesn't match anything: 'TestCompleteLogs' exists but not 'TestCompleteLogs\index.htm'

.  I investigated and determined that not all scripts were failing, but just the scripts attempting to access the QA.xlsx file.

However,  at the same time these scripts were failing on one box,  they were working on another box.  (using subversion to update the xlsx file before running the test) with the same QA.xlsx file

After some tinkering with the excel file,  the scripts magically started working when run against the QA.xlsx excel sheet.

My theory at this point is that due to some combination of the box environment and the excel spread sheet  the DDT Ace driver is hitting some kind of error which Test Execute does not handle properly (e.g. catching exception or whatever).  At that point,   TestExecute just gracelessly crashes.

[AlexKaras]

Hi Curt,

Have you reported this to Support (https://support.smartbear.com/message/?prod=TestComplete) referencing this thread?

There is a chance that they will provide you with some internal build of TestExecute with additional debug logging enabled or something like this that will make it possible for you to provide them with crush dump\log for further investigation...

[chicks]

Thanks Alex.  I have been working on this with smartbear support for several months and we have not determined any helpful information.   However,  I will add this latest information and your suggestion and see whether they have anything.

Regards,  Curt

[osaid_ahmad]

Hi,

I am not sure if it make sense to you but i had the same problem with TE and even with TC. Try clearing unnecessary logs, free up some memory, and most importantly reduce the no of tests that run in the suite.

I also raised the tickets sent dumps but unfortunately the problem was not solved. Only thing that helped is reducing the number of tests that run in one go. 

Regards

Osaid

[tristaanogre]

Question: Are you making sure that you call DDT.CloseDriver on your Excel driver before you create another instance? I know for CSV files there's a maximum number of connections that you can have open before DDT.CSVDriver starts returning errors about being unable to open another connection.

If you're consistently having problems with opening a LOT of Excel connections, that would be where I'd start checking... basically, a rule of thumb is that, for every DDT.ExcelDriver call, you should have a corresponding DDT.CloseDriver call to close the Driver object when you're done using it.  Something like:

function MyTestCase() {
    var xcelDriver;
    xcelDriver = DDT.ExcelDriver('C:\\MyDocs\\MyXcel.xlsx', 'TestSheet', true);
    
    //do some stuff

    DDT.CloseDriver(xcelDriver.Name);
}

[chicks]

Thanks Osaid.  One theory I had was that either my test suite or my spreadsheet had reached some kind of limit after 5 years.

I just counted for the first time,   and I have about 91 tabs in my spreadsheet.   At one point when TestExecute was crashing I rolled back the spreadsheet 6 months to see if that made any difference and it did not.  

With the latest set of crashes,  it was crashing instantly,  previously I could see that it would run for some period and then crash.

[chicks]

Hey Robert,

I noticed with the latest set of crashes that it was  failing instantly.  The first thing my scripts do is use the DDT driver to fetch some global information.  Prior to that TestExecute would crash after proceeding to the actual separate tests.  I conclude from that that the DDT (ACE) driver did not like the combination of spreadsheet / environment.  

Short Version:  It looks like it crashed on the initial opening of the ddt.exceldriver before I had any chances to close it or open more drivers....

Regards, , Curt

[tristaanogre]

Yeah... I think I'm with you on this that there is something environmental around the interface to Excel via the ACE driver... perhaps not necessarily a problem with TestComplete/TestExecute directly.

Have you tried moving the tests to a different machine with a fresh install of Excel?  Also, the machine in question, is it running the 64-bit version of Office/Excel?  Have you tried creating a "dummy" project to access a "dummy" excel file to see if the problem occurs there?

[tristaanogre]

Just as a note, it is for reasons like this that I built my framework (and have been convinced to maintain the structure by guys like @AlexKaras) around CSV files instead of Excel.  There is just something about depending upon files created within a very particular piece of software as driving the data for a test project... I like Excel, I use it... but it is limited in it's portability and you are not the first person to complain about the reliability and stability of it as a data storage for long term use.  Just my $0.02... and with conversion rates these days, that might not be worth a lot. 😉