Automated testing of a LabVIEW executable with a GUI

[jmorris]

Hello all you helpful forum-goers!

TL;DR: What system would you recommend for automating an extensive set of tests run on a LabVIEW executable with a complicated GUI?

My company has software product written in LabVIEW that is distributed as an executable.  It has an extensive set of tests that we run before a new release, but most of them are manual:

   Example 1: Use the program to load a test file, wait for the progress bar to finish, then make sure the correct data is displayed on the screen.

   Example 2: Make sure the user cannot press the OK button until they fill in this text field.

   Example 3: Make sure the program only allows numbers to be entered in this field.

   Example 4: After entering values, save the data into a file, and then make sure the file has the correct content (including the current date and time).

We would really, really like to automate this testing to save time and reduce human error.  I've heard I can use VI Server to trigger actions and read values of fields (I think even with a compiled executable, which is what I need), but it seems very likely that there is a better / faster way than building all the test scaffolding from scratch myself.

I've been look at the NI LabVIEW Unit Test Framework Toolkit, but the requirements are currently written in DOORS, not the NI Requirements Gateway, and furthermore the input vectors setup doesn't seem to be testing user interactions with the GUI.  In other words, it seems to be set up more for unit testing (thus the name) rather than the integration testing that we currently do of the finished product.

Products like TestComplete by SmartBear don't seem to list LabVIEW as one of the supported types of software that they can read and control.

I appreciate any suggestions or recommendations you have, especially if you've already solved this problem in one way or another yourself.  Thank you for your time!

[BertMcMahan · Accepted solution]

It's not a full system per se, but you can make your own. Take a look at this article:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000001DdiqSAC&l=en-US

You'll need to modify your running executable slightly but not too much. Then just use VI Server functions to remotely click the buttons or read properties. Use "Value (Signaling)" to imitate users pressing buttons or doing things. You can't do this with latched booleans though, which is unfortunate. You can get around this by changing their behavior from Latch when Released to Switch when Released, then setting their value back to False manually in the event handler case for that button.

[wiebe@CARYA]

How hard this is really depends on your program.

You can drop any compiled VI on a LabVIEW executable, and the executable will be run in the executable. This Vi can do VI server stuff. Alternatively, you can open an application reference to the executable, and use VI server to do things. Of course, diagrams and a lot of front panels will be removed... Both methods have to be actively prevented to disallow it, and some ini file settings are needed to enable a remote connection. Of course you can embed your own test framework stub yourself, a VI that for instance takes a TCP IP connection, and executes requests.

I have used a VI that I drop (so it's normally not included) and that VI listens to a named pipe. I have a .NET application that puts things on the named pipe, and my end user can use this with power shell to execute his tests.

So this won't allow you to test everything. Some things are hard. But opening a project might very likely result in a user event. You can trigger this event from your test platform... Testing if a button is enabled is pretty straightforward. However, pressing a latch button can be very difficult. You'd need a position and use Windows API to simulate a mouse click at that position. Getting the position can be hard if the button lives in a subpanel (or nested subpanels).

So if a lot of your application uses user events, you can automate a lot. If not you might need a bit of code to enable this, or it might simply be near impossible.

There are packages out there that use mouse clicks and vision\OCR, or so I've heard. Packages that use Window handlers won't work, as LabVIEW uses OpenGL\Mesa3D to draw controls and indicators.

[jmorris]

Hello wiebe@CARYA, when you say "executable will be run in the executable", can you link to any documentation that explains that or gives an example?  This page gives an example of using VI Server via TCP, but it would be better if there is a way to not build that into my application for security reasons.

Thank you for your help!

[wiebe@CARYA]

---

@jmorris wrote:

Hello wiebe@CARYA, when you say "executable will be run in the executable", can you link to any documentation that explains that or gives an example?  This page gives an example of using VI Server via TCP, but it would be better if there is a way to not build that into my application for security reasons.

Thank you for your help!

---

Sorry. If you drop a VI on an executable (in Explorer, a shortcut works too), the VI will be run in the executable.

Anything dropped on a LabVIEW executable will trigger the OS Document Open events, and if you can't do anything with those events, VIs are opened in the executable. The VI can be started, and it can use VI server and SubVIs to do all sorts of things.

This works for any application, if you drop a .txt file on notepad.exe or shortcut to it, notepad.exe will open the .txt file.

Make sure separate compiled code is off though, the executable cannot compile code, so the compiled code needs to be in the VI.

[jmorris]

Hi wiebe@CARYA, so in your example the executable would contain the VI server code to control the dropped VI, correct?  In that situation, how would the initial application or VI reference be opened, if not via TCP?  Do you have a code snippet you could post of the beginning of the controlling code (i.e. the executable in this example)?

I have gotten a system working by adding code to enable TCP VI server listening in my software under test (SUT), then just running separate test code to open an application reference to the SUT via the service name.  The only reason I'm asking for further clarification on the dropped executable scenario is to avoid having to build into my released product the enabling of the TCP VI server listening.

Thanks again for your help!

[Jaleel]

I am using LabVIEW 2023. Tried the same. I could access controls and set their properties. But this change  is not calling value signalling. Without value signaling support I think this is just fancy implementation. Anyone know/used (this one one with make changes UI). with value signalling ?