(Created page with "= testrunner-lite further development = == Discussion about architecture changes == === 8.12.2010 workshop in Tampere === testrunner-lite should provide features for OTS and M…") |
|||
| Line 4: | Line 4: | ||
=== 8.12.2010 workshop in Tampere === | === 8.12.2010 workshop in Tampere === | ||
| + | Participants: Sampo Saaristo, Timo Mäkimattila, Timo Härkönen, Kyösti Ranto, Sami Lahtinen. | ||
| - | testrunner-lite should provide features for OTS and MCTS testing. | + | testrunner-lite should provide new features for OTS and MCTS testing. |
| - | A | + | A feature request is created for making a library of testrunner-lite [http://bugs.meego.com/show_bug.cgi?id=11031 #11031], and another for python bindings [http://bugs.meego.com/show_bug.cgi?id=11025 #11025] |
| + | |||
| + | One of the architecture issues considering the whole testing toolchain is the role of testrunner-lite. There should be possibility to have a test plan that uses more than one DUT (device under testing) that sync events between each other. Currently testrunner-lite operates only one DUT. The question is should there be one testrunner-lite instace to each DUT, or should testrunner-lite handle multiple DUT's. A proof of concept for [[Quality/QA-tools/MCTS-Test-Automation-Design|MCTS]] testing is under development. The purpose is to modify testrunner-lite to handle two DUT's and synchronize the operations between DUT's with messaging API. | ||
| + | |||
| + | A feature to analyze measurement data is requested in FEA [http://bugs.meego.com/show_bug.cgi?id=11039 #11039]. Sampo provided an idea to add a plugin architecture that would provide an API for handling measurement data. Users could provide also their own plugins if they want to. (Sampo, please draw a picture here) | ||
| + | |||
| + | There was no conclusion about the final architecture, but we decided to take following steps: | ||
| + | |||
| + | * Start planning of testrunner-lite library API according to current features | ||
| + | * Continue planning of measurement API | ||
| + | * Wait for the results of MCTS proof of concept and alter our design according to the findings | ||
Participants: Sampo Saaristo, Timo Mäkimattila, Timo Härkönen, Kyösti Ranto, Sami Lahtinen.
testrunner-lite should provide new features for OTS and MCTS testing.
A feature request is created for making a library of testrunner-lite #11031, and another for python bindings #11025
One of the architecture issues considering the whole testing toolchain is the role of testrunner-lite. There should be possibility to have a test plan that uses more than one DUT (device under testing) that sync events between each other. Currently testrunner-lite operates only one DUT. The question is should there be one testrunner-lite instace to each DUT, or should testrunner-lite handle multiple DUT's. A proof of concept for MCTS testing is under development. The purpose is to modify testrunner-lite to handle two DUT's and synchronize the operations between DUT's with messaging API.
A feature to analyze measurement data is requested in FEA #11039. Sampo provided an idea to add a plugin architecture that would provide an API for handling measurement data. Users could provide also their own plugins if they want to. (Sampo, please draw a picture here)
There was no conclusion about the final architecture, but we decided to take following steps: