Yocto 1.1 Overall Test Plan
Yocto 1.1 Overall Test Plan reversion history
| Version | Modifier | Comments |
| 0.3 | Jiajun Xu | Initial Version |
Yocto 1.1 Overall Test Plan
This overall test plan defines test scope, test strategy, test configurations as well as test execution cycle for Yocto v1.1 program.
Features to Be Tested
- Core OS: The core OS feature included Yocto kernel, distro components(like connman & zypper), file system, device drivers (e.g. Intel Graphics Driver).
- Poky build system: It includes basic poky build and other poky feature testing. Performance and different distribuitions support will be also tested.
- Yocto SDK: SDK testing only covers toolchain test.
- Installation & Software Upgrade: QA will check if image could be installed to target system and how software could be upgraded in an installed system.
- Power/Performance: QA will check the CPU power behavior by software level tool, such as powertop. Real Power consumption testing will be investigated. Performance results should be collected for analysis and tuning. Memory footprint under specific workload will be recorded.
What will not Be Tested in Yocto v1.1
Following feature categories won't be tested by QA team in Yocto v1.1:
- SDK plugin: QA will not cover SDK plugin and SDK tools testing.
- Documentation: QA will only verify the steps in Quick Start Guide. The accuracy (technical and language) of other documentations should be validated by developer.
- License file: license files and legal process is owned by Distro. team.
Test Environmental
Test Platform matrix
| Category | Qemu | Atom | Core i7 | Xeon | ARM HW | PPC HW | MIPS HW | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Platform | FishRiver Island2 | TunnelCreek | Blacksand | eMenlow | SandBridge | HuronRiver | JasperForest | Beagleboard | mpc8315e-rdb | routerstationpro | |||||
| Arch | x86_32 | x86_64 | arm | ppc | mips | x86_32 | x86_32 | x86_32 | x86_32 | x86_64 | x86_64 | x86_64 | arm | ppc | mips |
| Minimal image | yes | yes | yes | yes | yes | yes | yes | yes | |||||||
| Sato image | yes | yes | yes | yes | yes | yes | |||||||||
| Sato-SDK image | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | |
| LSB-SDK image | yes | yes | yes | yes | yes | yes | yes | ||||||||
Note:
- Fullpass testing defined in execution plan will be performed against sato and sato-sdk image.
- For minimal image, only booting case is checked
- For lsb-sdk image, only lsb and ltp test suite are performed. (For qemuarm and qemumips, lsb test suite will not be performed becasue it does not provide support for arm and mips. For JasperForest, fullpass testing will be performed against lsb-sdk image.)
- For FishRiver Island2 and HuronRiver, they will not be ready until August.
Test Strategy and Approach
QA will cover following tests for each target.
| Test Target | System & Core OS | SDK | Compliance | Stress | Power/Performance | Graphics | Mulitimedia |
| qemux86 | yes | yes | |||||
| qemux86-64 | yes | yes | |||||
| qemuarm | yes | yes | |||||
| qemumips | yes | yes | |||||
| qemuppc | yes | yes | |||||
| SugarBay | yes | yes* | yes | yes | yes | ||
| TunnelCreek | yes | yes* | yes | yes | yes | ||
| TunnelCreek noemgd | (basic functionality are tested) | ||||||
| FishRiver Island 2 | yes | yes* | yes | yes | yes | ||
| HuronRiver | yes | yes* | yes | yes | yes | ||
| Jasperforest | yes | yes | |||||
| Blacksand | yes | yes | yes | ||||
| eMenlow | yes | yes | yes | ||||
| Poky build feature | Functionality | Performance | Distribution Support |
| Poky | yes | yes | yes |
| Documentation Test | Quick Start Doc |
| Documentation | yes |
Test Levels
The Yocto 1.1 will be tested from the following different test execution levels.
Sanity Test
Sanity Test is a very brief and quick test. It is integrated with each build process (including incremental build) in autobuilder system. It checks image basic functionality, such as booting, network, zypper etc. Its results will be published in build web page and referred by the other testing. It is fully automation test and its execution time should be less than 10 minutes.
Test Frequency: Sanity test will be run on autobuilder system against daily build image.
Weekly Test
Weekly test is a test cycle against the weekly image released through distribution team. It will do new feature exploring, bug verification and regression testing. It includes more testing in component and system usage rather than Sanity Test. Weekly test will also manually check key components behavior, such like X window, connman, multimedia.
Test Frequency: Weekly Test is against weekly image and occurred each Monday if image is ready on autobuilder system. It will cost 2 days for one round weekly test.
Fullpass Test
In milestone test, test team will perform a full validation testing for candidate build, following test will be involved:
- Weekly Test - In fullpass test week, there will not be alone weekly test. Weekly test contents should be firstly executed for milestone build.
- Functional Test – which will follow the Feature List to test, cover Core OS & System usage, Multimedia
- Graphics Test - specific BSP(like CrownBay and Sugarbay) will need Graphics testing
- Multimedia Test - test audio/video playing has no problem on specific BSP.
- Stress Test – system should be alive and functional in 24 hours workload test.
- Power and Performance Test – which follow the power and performance test plan
- Compliance Test - system level test suites will be chosen, LTP, POSIX and LSB.
Test Frequency: Fullpass test will be performed against each RC build for milestone. It will cost a whole week for one round fullpass test.
Regression Test
Regression test is a set of tests to verify that change from the last build (code enhancements, bug fixes) doesn’t introduce new issues to the previous working code as well as new features work as expected. This cycle includes the tests for previous major bug fixes and areas of the code that might be affected by new implementation.
Test Frequency: Each 2 weeks, QA will go through bugzilla and add cases into Regression test. Regression test will be taken in Weekly testing and Fullpass testing.
Test Execution Cycle
| Build | Sanity Test | Weekly Test | Fullpass Test |
|---|---|---|---|
| Incremental Build | yes | ||
| Daily Full Build | yes | ||
| Weekly Build | yes | yes | |
| Milestone Build | yes | yes | yes |
Test Report
Test report should be posted on webpage and Yocto mailing list.
| Test Report | AutoBuilder Web | Yocto Mailing List |
|---|---|---|
| Incremental Build | yes | |
| Daily Full Build | yes | |
| Weekly Build | yes | |
| Milestone Build | yes |
Test report format : Pls. refer to Test Report Format
Test Automation
To reduce testing time, test automation will be adopted in the testing. Following test will be implemented as automation:
- Sanity Test
- Part of Weekly Test
- Stress Test
- Poky build Performance Test
Test Infrastructure
If QA has resource, test infrastructure will be investigated in Yocto v1.1. Automation test cases development should be test infrastructure independent.
Test Design
This is a overall test design for test components which will be covered QA testing. Detailed test cases design will be covered in Test Execution Plan.
System & Core OS
- Boot Test: Check if Yocto image is bootable with the bootloader.
- Installation/SW Update Test: Validate the Yocto image installation on hardware platform and software update functions from the end users' perspective. Using zypper/rpm for software update with hardisk installed image.
- Common system usage Test: shutdown/restart, suspend/resume, init 3/5 boot.
- Component Test (aka. Feature Test): Based on sato image features to test. For example:
- Perl
- Rootless X
- 3G
- ... etc
Poky Build System
- Functionality Test: Test Poky build feature on standard host configuration. For example:
- kernel interactive targets
- non-GPLv3 build
- sstate
- poky build in virtual machine
- ... etc
- Distribution support Test: Test Poky buld on latest Ubuntu, Fedora and Opensuse Hosts
- Performance Test: Check Poky build performance on standard host(Defined in perfromance test webpage)
SDK Test
- Toolchain test, including compiler, libraries, etc.
Stress Test
Stress testing refers to tests that determine the robustness of software by testing beyond the limits of normal operation. Stress tests commonly put a greater emphasis on robustness, availability, and error handling under a heavy load, than on what would be considered as correct behavior under normal circumstances.
- Test Method: 24 hours workload (Helltest + Crashme) test should pass.
Power/Performance Test
Power/Performance Test is to collect the power/performance data and status of Yocto image on defined BSP.
- Test Method: Power test will check if Yocto is power saving friendly, that CPU should support and enter different power saving stage. For performance test, memory footprint under specific workload will be collected.
Compliance Test
Compliance Test is targeted to validate system level health with different system test suite.
- LTP test suite
- POSIX test
- LSB test
