Hi,
I had a little chat with sven about automated testing. Let's say you'd upgrade raspbian and want to know whether your rev pi environment is still fully functional.
Today we at erminas already have a test program that would test if inputs and outputs work as desired. We use a an environment where DIO Inputs are wired to the outputs (of another PI) and vice versa. This way we can simulate machine signals.
The thing sven and I thought about is his python lib. Of course unit testing is valuable. We could create inputs, outputs, counters, virtual devices by software. The important question is, whether virtual testing is sufficient. Does it work with mocks or we should also test the hardware.
For the DIO we could wire inputs to outputs for testing. Of course the range of modules is quite huge. I guess Kunbus already has something for this. So what can users do to automatically test their environments?
Automated Testing
- Boris Crismancich
- KUNBUS
- Posts: 23
- Joined: 21 Apr 2017, 12:04
Kind regards / Herzliche Grüße / Cordiali saluti
Boris Crismancich
Boris Crismancich
We at KUNBUS cal this "regression testing" and of course we are developing and doing such tests for each firmware of the devices.
We do not believe in sufficient reliability of pure software simulations. But this may be because we are dealing with embedded systems where software is very close to hardware. So how are we testing?
We do have large wooden boards with special hardware equipment and wiring on which we alslo mount the device under test. very often we are using our own products as trest equipment. Just as Boris said with the DO using a DI to read back the outputs, we are using a second AIO to feed back analog signals. For the gateways we are using either master devices (PLCs) or if possible emulating master functions on ehternet or RS485 based field busses with a Windows PC.
The complete test is controlled by a Windows PC and a modular, partly data driven software. Many of our regression tests are running several hours to test as many as possible constallations of parameters (user inputs, signals).
These tests are highly specific for each device and the realted firmware and thus it would not help much to post detailed plans (this is also part of KUNBUS ip so I could not if I wanted to).
Hope this helps for your decisions.
We do not believe in sufficient reliability of pure software simulations. But this may be because we are dealing with embedded systems where software is very close to hardware. So how are we testing?
We do have large wooden boards with special hardware equipment and wiring on which we alslo mount the device under test. very often we are using our own products as trest equipment. Just as Boris said with the DO using a DI to read back the outputs, we are using a second AIO to feed back analog signals. For the gateways we are using either master devices (PLCs) or if possible emulating master functions on ehternet or RS485 based field busses with a Windows PC.
The complete test is controlled by a Windows PC and a modular, partly data driven software. Many of our regression tests are running several hours to test as many as possible constallations of parameters (user inputs, signals).
These tests are highly specific for each device and the realted firmware and thus it would not help much to post detailed plans (this is also part of KUNBUS ip so I could not if I wanted to).
Hope this helps for your decisions.
Unser RevPi Motto: Don't just claim it - make it!