(→MeeGo SDK Test Plan (Content not ready)) |
(→What will not Be Tested) |
||
| Line 92: | Line 92: | ||
== What will not Be Tested == | == What will not Be Tested == | ||
Following feature category won't be covered in MeeGo SDK testing. | Following feature category won't be covered in MeeGo SDK testing. | ||
| - | * Only | + | * Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it. |
* Not test for SDK package or image building, only check the built out package or images. | * Not test for SDK package or image building, only check the built out package or images. | ||
* Not cover Meego compliance test, but only check key package versions which should align with Meego release. | * Not cover Meego compliance test, but only check key package versions which should align with Meego release. | ||
* ARM support are not tracked in this document yet, which should be owned by Nokia. | * ARM support are not tracked in this document yet, which should be owned by Nokia. | ||
| - | |||
== Test Strategy and Approach == | == Test Strategy and Approach == | ||
Contents |
This is overall test plan for MeeGo SDK(Software Development Kit) of MeeGo open source project, which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK. It will be the joint effort from Nokia, Intel and MeeGo community.
Overall the MeeGo Core Testing will cover below host, target and testpoints:
| Tools | Priority |
|---|---|
| Emulator: Qemu | P1 |
| Simulator: Xephyr + chroot | P2 |
| Host\Target | Netbook | Handset | Tablet |
|---|---|---|---|
| Fedora13 | P1 | P1 | P1 |
| Fedora12 | P2 | P2 | P2 |
| Ubuntu10.04 | P1 | P1 | P1 |
| Ubuntu9.10 | P2 | P2 | P2 |
| OpenSuse 11.2 | TBD | TBD | TBD |
| OpenSuse 11.3 | TBD | TBD | TBD |
| WindowsXP | P1 | P1 | P1 |
| Win 7 | TBD | TBD | TBD |
| Meego Netbook | TBD | TBD | TBD |
| Mac OS | TBD | TBD | TBD |
|
Check Point | Priority | |
| SDK installer works | P1 | |
| SDK images compliance with Meego images | P1 | |
| Boot SDK images with Qemu | P1 | |
| Boot SDK images with Xephyr | P2 | |
| Basic function check for SDK image | need more detail checklist here | P1 |
| Qt Creator | P1 | |
| MADDE | P1 | |
| sysroots | P1 | |
| toolchains | P1 | |
App development
|
|
|
| Documents & Toturials | need detail checklist here | P1 |
| Additional tools | TBD | |
| Memory/performance/power check | TBD | |
Following feature category won't be covered in MeeGo SDK testing.
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target. The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.
It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.
The regression test will be taken in following test cycle:
Refer to MeeGo bugzilla guide
| Category | Peripherals |
|---|---|
| USB devices | keyboard, mouse, USB storage device , ... |
The networking arrangements needed to conduct the testing: