I have a test that comapres tables in 2 databases. There are over 500000 records in just one table. It would seem the Ranorex report becomes unstable (and very slow to load) over 10000 results. I have turned off screen capture as there is no UI element in the tests.
The issue I have this is only one table of many and it would seem Ranorex is seriously limited in how many results it can handle.
I would normally handle something like this with multiple PC's sadly that isn't an option. I am open to suggestions from anyone who has had to test a huge amount of data.
Large Test Unresponsive Report
Large Test Unresponsive Report
Ian Fraser
Re: Large Test Unresponsive Report
So the report itself is slow to load?
Have you tried renaming the report extension to .XML and loading it in a browser?
Have you tried renaming the report extension to .XML and loading it in a browser?
If this or any response has helped you, please reply to the thread stating that it worked so other people with a similar issue will know how you fixed your issue!
Ciege...
Ciege...
Re: Large Test Unresponsive Report
You could just write a .Net method in your test module that does all the compares in a single loop and just print one line to the report for the whole thing. Just have a try/catch that will throw the element(s) that failed.
You could create a List that holds each failure and then print the list if there is anything in it. (or just print a report line for each failure...)
Psuedo coded below...
Again, this is psuedo code, so you would need to figure out the exact logic you need.
You could create a List that holds each failure and then print the list if there is anything in it. (or just print a report line for each failure...)
Psuedo coded below...
Code: Select all
List<string> failures = new List<string>();
foreach (Row r in myTable.Rows) {
try {
<do comparison here>
if (<error condition>) throw new Exception();
} catch(Exception e) {
failures.Add(r.ID);
Report.Log(<FAILURE ON r.ID>);
}
}
if (failures.Size = 0) Report.Log(<SUCCESS>);
Shortcuts usually aren't...