Jump to content

Automated text environment


Recommended Posts

Hi,

we are currently defining our test systems for an embedded system with CPU, PCB,.... We want to control the embedded CPU with a serial bus and at the same time control and measure with our lab equipment.

We have been looking into LabView which seems to be perfectly suitable for small tests. Now we are defining automated test case which all follow the same approach.

- Setup the test scenario.

- Performance some test with the embedded system

- Compare results against a golden reference or a specification.

The problem we face right now, is that we do not see a good possibility to implement something like this in Labview effectively. Drawing a test spec graphically is not in favour of your test guys.

Is there a way to mix text-based and graphical programming in LabView, so that we can write the actual test in a programming language and use VIs to do the work?

Are the good alternatives we have not considered yet?

Thanks in advanced for the your advice

Peter

Link to comment

Drawing a test spec graphically is not in favour of your test guys.

Hi,

I am not sure I understand your problem here, to us a test specification is a formally control document written by a design engineers telling the test software team what we need to test on a unit or device. The test specification defines expected results & limits, maybe also defining specific test conditions, it is often reviewed and signed of by various teams in the organisation.

We then have to abstract that test specification into a form that is usable by an automated test system, this is true whether the automated system is written in LabVIEW (graphical), Visual Basic or Python (text based) form. We use a number of text files to define test limits & test configurations. These configuration files are linked in some way back to the original test specification for audit & QA purposes. The test software then reads these limit & configuration files when it runs to carry out the tests.

The better you do your abstraction the easier it will be to deal with changes to you original test specification. So for example if a test limit changes or maybe a set up condition like the power of an input signal changes you only need to change the limits or configuration text files and not your actual code.

- Setup the test scenario.

- Performance some test with the embedded system

- Compare results against a golden reference or a specification.

When you move from the stage of running a few simple stand alone tests or checks on units under test to try an do fully automated testing against test specifications you need to look at the concept of a Test Executive this software layer will carry out the function you were talking about. Again this software layer is really needed indifferent of the programming language you are using.

As has already been said you could look at TestStand write your own or several NI Allience Members supply Test Executive Type Systems.

cheers

Dannyt

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.