m |
|||
| Line 10: | Line 10: | ||
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] | 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 | + | 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) | 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) | ||
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: