Yocto 1.1 Overall Test Plan

From Yocto Project
Jump to navigationJump to search

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