Is there a framework to simulate a deterministically pseudorandom series of clicks imposed upon a Qt application - in order to try to trigger any memory leaks, threading errors etc - typical monkey-testing?
Some exotic, monkey use for QTestLib?
Yes, you can use the useful unit test module. Look in particular at the class QTestEventList. Just provide the QWidget you want to test, or the QMainWindow or whatever subclass you want and add the list of events you want to generate. If you want to generate a sequence of points so that you can reproduce in case of failure, use qsrand() and qrand().
The Squish automated GUI testing framework can be used to do monkey clicking in your application. There are a couple of nice things about using Squish for this purpose:
Squish runs on Windows, Mac, Linux and Android
It logs whatever random steps it happens to perform as a script that can be re-run (monkey testing docs)
It has an option to take a screenshot on application crash (screenshot on failure settings docs)
Disadvantages: Squish is not free. Setting up Squish to run your application can be super-irritating, especially if your application requires specific build characteristics of Qt or Python.
Related
I am attempting to use QTCreator's Memcheck tool to analyze the memory of a QT project, which is a dynamic library. It uses a QT Gui (QMainWindow) to allow the user to select a file, which is then processed, and then eventually returns to the mainwindow.
However, I cannot seem to use Memcheck properly.
When I select "Memcheck" and hit run, it instantly goes to "Analyzing memory" without ever letting the Gui pop up.
This is problematic. How can I get memcheck to work with this program?
I had two main issues:
1: Valgrind does not seem to play nice with QT Gui applications. It generates logs that are thousands of entries long for all the work QT is doing before it even gets to my application.
I had to make a separate, small non-GUI C++ program that would drive instead of the GUI application.
2: When trying to run from the command line, I needed to set an environment variable by using export. This needs to be the same as LD_LIBRARY_PATHS in QT Creator.
So I ran:
export LD_LIBRARY_PATH=X where X was the exact value I copied from LD_LIBRARY_PATHS in the variable from the QT Project.
Note: Running from the command line may have not be neccesary now that it isn't a GUI Application, memcheck might have passed just fine. Haven't tested since.
I have a window based application (c++) with list of log files;
number of logs would vary.
When each of the listed log file(each has different name) is double clicked a window pops up.The success criteria here is the successful opening of window on double click - this is to verified for each log file
How can I automate this process?
I would look into a program like Winium. It is a Selenium-based tool for testing windows apps. For further info, check this out: https://github.com/2gis/Winium
An alternative could be an Robotic Process Automation tool (RPA) like UIPath. It is not a testing tool per se, but it can be used as such and get your job done. There is a free community version available. Here's a link: https://www.uipath.com/
I have a project uses Qt GUI which works on raspberry-pi2; however I don't want users to interact with the operating system. I just want that the only application appears on the screen (from boot to shutdown) to be is my application. Actually the retropie project has done what I actually want. So I want to prepare an minimal SD Card image like that. Is there any tool or way to do that?
You can use openembedded http://www.openembedded.org/wiki/Main_Page for this.
Creat file that describe packages for your image, at your case base system + qt,
plus create description of package of your program, that include .service file for run you program at start with systemd. The command MACHINE=raspberry-something bitbake your-image
I'd just use the init scripts to run your application as soon as possible and make it handle all user inputs (keyboard and mouse) properly, without giving any way to the user to close it.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
Each time I run a test using TestDriven, it creates another "rocket" icon on my system tray. I have to manually do right-click Quit to get rid of them. How can I avoid this?
Check for any open file handles you may be creating in your tests. Depending on the size of your test suite that may be too time consuming and tedious. There's an option to turn off caching the test process between test runs in the options for TestDriven.Net. This seems to be designed for instances like what you're seeing. From their documentation:
Cache test process between test runs
By default the external test process will be cached when the ‘Run Test(s)’ command is used. This process appears in the tool tray as a rocket icon which can be used to kill the process. This is fine unless one of your tests starts leaking leaking native resources (such as leaving open a file handle). The best solution is to fix the resource leak, but you now have to option to work around the issue by killing the test process at the end of each test run. This can be useful if the resource leak is in a 3rd party DLL which can’t be easily be changed.
From here: http://weblogs.asp.net/nunitaddin/archive/2008/12/03/testdriven-net-options-pane.aspx
I realize you asked this a year ago, so you may have already figured out a way to fix the problem. In that case, I would ask that you let us know what you did.