Testing embedded software with Robot?
Caizu
Is it possible to use Robot Framework for embedded software anyhow? I
would be very interested in the detailed information if anyone knows
more about it.
I just noticed in the guide that "It can be used for testing
distributed, heterogeneous applications, where verification requires
touching several technologies and interfaces." but with my
understanding of the written text I would need an "iron wire example"
from this - maybe because English is not my mother tongue.
-Caizu-
Pekka Klärck
>
> Is it possible to use Robot Framework for embedded software anyhow? I
> would be very interested in the detailed information if anyone knows
> more about it.
It definitely is possible. If your embedded system can run Python you
might even be able to run RF on it directly, but in most cases it's
enough and easier to just test the system using it's external
interfaces. If you have existing tools that can interact with those
interfaces you should be able to control them somehow, but you may
also want to (or need to) create new libraries to interact with the
interfaces directly. For example I'm going to work next week with at
team building a modem, and I expect that we'll use Telnet library [1]
to control external simulators and also need to implement a new
library to interact with serial port using pySerial [2].
[1] http://code.google.com/p/robotframework/wiki/TelnetLibrary
[2] http://pyserial.sourceforge.net/
Giving any more detailed information is pretty much impossible without
knowing your system and its interfaces better.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Caizu
that I have to find out some more information in here.
-C-
On 23 syys, 11:50, Pekka Klärck <p...@iki.fi> wrote:
> 2009/9/23 Caizu <kaisa.mak...@gmail.com>:
Taylor, Martin
The basic approach is that you need to be able to communicate with your embedded system in some way. We have one way to communicate that allows us to send keystrokes to the calculator as if a user were pressing keys on the keypad. We then have other keywords that allow us to query the calculator state in order to verify the result of the keypresses. This is used for user scenario testing via the calculator UI. We have another way of communicating with the software on the embedded device that allows us to make XML-RPC API calls to various exposed APIs in the calculator software. We use this approach to test the math algorithms on the calculator and have >2M such test cases, all driven via Robot Framework.
If you can share anything about your particular embedded device and how you want to test it I'd be willing to continue this discussion with you.
Cheers,
Martin
Pekka Klärck
>
> At Texas Instruments we use Robot Framework and a number of proprietary keyword libraries that I've built to test the embedded software on TI Calculators. Unfortunately I cannot share much about this because this software is all proprietary.
>
> The basic approach is that you need to be able to communicate with your embedded system in some way. We have one way to communicate that allows us to send keystrokes to the calculator as if a user were pressing keys on the keypad. We then have other keywords that allow us to query the calculator state in order to verify the result of the keypresses. This is used for user scenario testing via the calculator UI.
This is exactly the technique I would have recommend to use in this
case. The same idea obviously works great also with mobile phones and
other similar devices.
> We have another way of communicating with the software on the embedded device that allows us to make XML-RPC API calls to various exposed APIs in the calculator software. We use this approach to test the math algorithms on the calculator and have >2M such test cases, all driven via Robot Framework.
This is a great idea too. Must be somewhat faster than running two
million tests through the UI.
This kind of a approach where the most important scenarios are tested
through the UI similarly as a user would do them and business logic
tests are run through some lower level interface is obviously not
limited to the embedded testing domain. It can be applied to web
testing, testing native desktop applications, etc. One variation of
the theme is executing tests through the lower level interface in
continuous integration and running the same tests through the slower
UI few times per day. With Robot Framework this is pretty easy to do
by using variables in library and/or resource imports and setting
correct variables from the command line.
Pekka Klärck
sent to the rf-users list and added it to Cc.]
2010/9/14 Eileen Wei <eileen...@gmail.com>:
> I found this discussion and this is something I am very interested
> too. I will be testing desktop applications that's designed in C++, I
> am wondering if anyone has any experience on exposing the C++
> interface to Python so Robot Framework can use it?
We have instructions, with an executable example, on how to use C from
Robot Framework test libraries [1]. The example uses Python's ctypes
module [2], and probably you can use it also to interact with C++ code
somehow. Please share your findings if you decide to try it!
[1] http://code.google.com/p/robotframework/wiki/HowToUseC
[2] http://docs.python.org/library/ctypes.html
Cheers,
.peke
> On Sep 23 2009, 7:40 am, Pekka Klärck <p...@iki.fi> wrote:
>> 2009/9/23 Taylor, Martin <cmtay...@ti.com>:
>>
>>
>>
>> > At Texas Instruments we use Robot Framework and a number of proprietary keyword libraries that I've built to test the embedded software on TI Calculators. Unfortunately I cannot share much about this because this software is all proprietary.
>>
>> > The basic approach is that you need to be able to communicate with your embedded system in some way. We have one way to communicate that allows us to send keystrokes to the calculator as if a user were pressing keys on the keypad. We then have other keywords that allow us to query the calculator state in order to verify the result of the keypresses. This is used for user scenario testing via the calculator UI.
>>
>> This is exactly the technique I would have recommend to use in this
>> case. The same idea obviously works great also with mobile phones and
>> other similar devices.
>>
>> > We have another way of communicating with the software on the embedded device that allows us to make XML-RPC API calls to various exposed APIs in the calculator software. We use this approach to test the math algorithms on the calculator and have >2M such test cases, all driven via Robot Framework.
>>
>> This is a great idea too. Must be somewhat faster than running two
>> million tests through the UI.
>>
>> This kind of a approach where the most important scenarios are tested
>> through the UI similarly as a user would do them and business logic
>> tests are run through some lower level interface is obviously not
>> limited to the embedded testing domain. It can be applied to web
>> testing, testing native desktop applications, etc. One variation of
>> the theme is executing tests through the lower level interface incontinuousintegrationand running the same tests through the slower
Eileen Wei
something.
Thanks,
Eileen
On Sep 15, 3:49 am, Pekka Klärck <p...@iki.fi> wrote:
> [This mail was sent to me only, but I suspect it was supposed to be
> sent to the rf-users list and added it to Cc.]
>
Grace Zhuang
在 2009年9月23日星期三 UTC+8下午4:50:06，Pekka Klärck写道：
Heiko Thiery
--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.
