Overall Test Plan

From Yocto Project
Revision as of 22:17, 22 October 2010 by Scottrif (talk | contribs) (Created page with 'Yocto 0.9 Overall Test Plan reversion history {|border="1" |Version|| Modifier || Comments |- | 0.3 || Yongkang You || Initial Version |- | 0.8 || Yongkang You || Update with…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Yocto 0.9 Overall Test Plan reversion history

Version Modifier Comments
0.3 Yongkang You Initial Version
0.8 Yongkang You Update with internal review comments.

Yocto 0.9 Overall Test Plan

This overall test plan defines test scope, test strategy, test configurations as well as test execution cycle for Yocto v.9 program.

Features to Be Tested

  • Core OS: The core OS feature included Yocto kernel, fast boot, file system, device drivers (e.g. Intel Graphics Driver).
  • Installation & Software Upgrade: QA will check if image could be installed to target system and how software could be upgraded in an installed system.
  • Yocto SDK: QA check standalone SDK and SDK plugin. SDK developer will write unit test cases to make sure of SDK plug-in functionality.
  • Power: QA will check the CPU power behavior by software level tool, such as powertop.
  • Performance: Performance results should be collected for analysis and tuning.
  • Disk footprint and memory footprint.
  • Different architecture and platform supporting: Yocto will support these architectures: x86_32, x86_64, ARM, PPC, MIPS. Testing will cover related platforms.

What will not Be Tested in Yocto v0.9

Following feature categories won't be tested by QA team in Yocto v0.9:

  • Documentation: QA will check the Documentation existence. Its accuracy (technical and language) should be validated by developer.
  • Real Power assumption testing should rely on the special power measurement device. It will not be tested in Yocto 0.9 release.
  • 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           netbook e-Menlow SandBridge        
Arch x86_32 x86_64 arm ppc mips x86_32 x86_32 x86_32 x86_64 x86_32 x86_64 arm ppc mips
Minimal image yes yes yes yes yes   yes         yes yes yes
Sato image yes yes yes yes yes     yes       yes yes yes
SDK image yes yes yes yes yes yes           yes yes yes
LSB image yes yes yes yes yes       yes yes yes yes yes yes


Test Levels

The Yocto 0.0 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 auto build system. It checks image basic functionality, such as booting, network, sdk compilation 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.

BAT Test

Basic Acceptance Test (BAT) is a fully automation test. It will be executed after full build check in auto build system. It checks more fields than Sanity Test, e.g. some system level test, such as LTP. Its execution time should be controlled within 2 hours.

BAT test depends on Sanity Test result. If Sanity Test is failed, BAT test will not be executed.

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 BAT Test. Weekly test will also manually check key components behavior, such like X window, web browser.

Weekly test depends on BAT test result. If BAT test evaluation fails, Weekly test will not be executed.

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.
  • Stress Test – system should be alive and functional in 72 hours workload test.
  • Power and Performance Test – which follow the power and performance test plan

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.

The regression test will be taken in following test cycle:

  • Weekly testing
  • Fullpass testing

Test Execution Cycle

Build Sanity Test BAT Test Weekly Test Fullpass Test
Incremental Build yes
Daily Full Build yes yes
Weekly Build yes yes yes
Milestone Build yes yes yes yes

Test Report

Test report should be posted and archived.

Test Report AutoBuilder Web Yocto Mailing List Wiki Archieve
Incremental Build yes
Daily Full Build yes
Weekly Build yes
Milestone Build yes yes

Test report format : TBD

Test Automation

To reduce testing time, test automation will be adopted in the testing. Following test will be implemented as automation:

  • Sanity Test
  • BAT Test
  • System Test (LTP, POSIX, LSB etc.)
  • Stress Test
  • Performance Test

Test Infrastructure

Test infrastructure will be considered in Yocto v0.9 . Automation test cases development should be test infrastructure independent.

Test Design

Core OS

  • Boot Test: Check if Yocto image is bootable with the bootloader.
  • Compliance Test
    • LTP test suite
    • POSIX test
    • LSB test
  • Component Test (aka. Feature Test): Based on minimal and sato image features to test, such as connman, web browser, X etc.
  • Developer unit test suite
  • Wind River Test Suite: any Wind River test suite for embedded Linux can be used in Yocto

Installation/SW Update

  • Test Method:

Validate the Yocto image installation on hardware platform and software update functions from the end users' perspective.

SDK Test

  • standalone SDK compilation test. The target application could be compiled success and executable in target platform.
  • SDK plugin functional test. It is based on SDK HLD definition.

Stress

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:

72 hours workload test should pass.

Power

  • Test Method:

Power test will check if Yocto is power saving friendly, that CPU should support and enter different power saving stage.

Performance

  • Test Method:

Industry standard benchmark will be executed. The performance results should be collected and published for analysis and tuning.

Reference Documentation