Yocto 1.1 Overall Test Plan: Difference between revisions

Latest revision as of 14:13, 7 July 2011

Yocto 1.1 Overall Test Plan reversion history

Version	Modifier	Comments
0.3	Jiajun Xu	Initial Version
0.4	Jiajun Xu	Update with internal review comments from Julie, Saul and Yi Zhao

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).
Core build system: It includes basic core build test and other build feature test. Performance and different distribuitions support will be also tested.
Yocto ADT: ADT testing only covers toolchain test.
Hob: Functionality of all components are validated if work correct.
Power/Performance: QA will check the CPU power behavior by software level tool, such as powertop. Real Power consumption with idle is collected.

What will not Be Tested in Yocto v1.1

Following feature categories won't be tested by QA team in Yocto v1.1:

Eclipse plugin: QA will not cover ADT plugin and ADT tools testing. -- (ADT team will cover them)
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 Environment

Test Platform matrix

Following matrix is the target Test Plantforms for Yocto 1.1, with the target images will be validated in QA test.

Category	Qemu					Atom				Core i7		Xeon	ARM HW		PPC HW	MIPS HW
Platform						FishRiver Island2	TunnelCreek	Blacksand	eMenlow	SandBridge	HuronRiver	JasperForest	Beagleboard	Pandaboard	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	arm	ppc	mips
Minimal image	yes	yes	yes	yes	yes								yes	yes	yes	yes
Sato image	yes	yes	yes	yes	yes
Sato-SDK image	yes	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, HuronRiver and Pandaboard, they will not be ready until August.

Test Strategy and Approach

QA will cover following tests for each target in each round fullpass testing.

Test Target	System & Core OS	ADT	Compliance	Stress	Power/Performance	Graphics	Mulitimedia
qemux86	yes	yes
qemux86-64	yes	yes
qemuarm	yes	yes	yes
qemumips	yes	yes	yes
qemuppc	yes	yes	yes
SugarBay	yes		yes		yes	yes	yes
TunnelCreek	yes				yes	yes	yes
TunnelCreek noemgd	(basic functionality are tested)
FishRiver Island 2	yes				yes	yes	yes
HuronRiver	yes				yes	yes	yes
Jasperforest	yes			yes**
Blacksand	yes		yes			yes	yes
eMenlow	yes					yes	yes
Beagleboard	yes		yes*
mpc8315e-rdb	yes		yes
routerstation	yes		yes*
Pandaboard	yes					yes	yes

Note:

Compliance Test on Beagleboard and routerstation will only cover LTP and POSXI Test, since LSB test suite does not support ARM and MIPS.
Jasperforest is picked up for stress test, because it is powerful with 12 CPUs and 2GB memory. Moreover, it is a server, which needs more stress tests. The other test boards, like blacksand and eMenlow do not have powerful CPUs, that's why we do not use them for stress test.

Core build feature	Functionality	Performance	Distribution Support
Core build	yes	yes	yes
Hob	yes	n/a	n/a

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 : TBD

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
Core 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(Covered in Weekly Test)

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 install/removal 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

(Basic functionality for tested features will be exercised as well as new functionality added in each release.)

Core Build System(Covered in Fullpass Test)

Functionality Test: Test Core build feature on standard host configuration. For example:
- kernel interactive targets
- non-GPLv3 build
- sstate
- core build in virtual machine
- ... etc
Distribution support Test: Test Core buld on latest Ubuntu, Fedora and Opensuse Hosts
Hob Test: Main UI and component functionality are validated (Some cases defined in weekly and some in fulpass)
Performance Test: Check Core build performance on standard host(Defined in perfromance test webpage)

ADT Test(Covered in Weekly Test)

Toolchain test, including compiler, libraries, etc.

Stress Test(Covered in Fullpass 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(Covered in Fullpass 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(Covered in Fullpass Test)

Compliance Test is targeted to validate system level health with different system test suite.

LTP test suite
POSIX test
LSB test

@@ Line 5: / Line 5: @@
 |-
 | 0.3 || Jiajun Xu || Initial Version
+|-
+| 0.4 || Jiajun Xu || Update with internal review comments from Julie, Saul and Yi Zhao
 |}
@@ Line 13: / Line 15: @@
 === 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.
+* Core build system: It includes basic core build test and other build feature test. Performance and different distribuitions support will be also tested.
-* Yocto SDK: SDK testing only covers toolchain test.
+* Yocto ADT: ADT 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.
+* Hob: Functionality of all components are validated if work correct.
-* 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.
+* Power/Performance: QA will check the CPU power behavior by software level tool, such as '''powertop'''. Real Power consumption with idle is collected.
 === 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.
+* Eclipse plugin: QA will not cover ADT plugin and ADT tools testing. -- (ADT team will cover them)
 * 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 Environment ===
 ==== Test Platform matrix ====
+Following matrix is the target Test Plantforms for Yocto 1.1, with the target images will be validated in QA test.
 {|border="1" cellpadding="5"
-! Category !! colspan="5"| Qemu !! colspan="4" | Atom !! colspan="2" | Core i7 !! colspan="1" | Xeon !! ARM HW !! PPC HW !! MIPS HW
+! Category !! colspan="5"| Qemu !! colspan="4" | Atom !! colspan="2" | Core i7 !! colspan="1" | Xeon !! colspan="2" | ARM HW !! PPC HW !! MIPS HW
 |-
 ! Platform
-| &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || FishRiver Island2|| TunnelCreek || Blacksand || eMenlow || SandBridge || HuronRiver|| colspan="1" | JasperForest || Beagleboard || mpc8315e-rdb || routerstationpro
+| &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || FishRiver Island2|| TunnelCreek|| Blacksand || eMenlow || SandBridge || HuronRiver|| colspan="1" | JasperForest || Beagleboard || Pandaboard || 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
+| x86_32 || x86_64 || arm || ppc || mips || x86_32 || x86_32 || x86_32 || x86_32 || x86_64 || x86_64 || x86_64 || arm || arm || ppc || mips
 |-
 ! Minimal image
-| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || yes || yes || yes
+| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || yes || yes || yes || yes
 |-
 ! Sato image
-| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || yes || &nbsp; || &nbsp;
+| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp;
 |-
 ! Sato-SDK image
-| yes || yes || yes || yes || yes || yes || yes || yes || yes || yes || yes || &nbsp; || yes || yes || yes
+| yes || yes || yes || yes || yes || yes || yes || yes || yes || yes || yes || &nbsp; || yes || yes || yes || yes
 |-
 ! LSB-SDK image
-| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || yes  || &nbsp; || yes || &nbsp;
+| yes || yes || yes || yes || yes || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || &nbsp; || yes  || &nbsp; || &nbsp; || yes || &nbsp;
 |}
@@ Line 53: / Line 55: @@
 * 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, HuronRiver and Pandaboard, they will not be ready until August.
 === Test Strategy and Approach ===
+QA will cover following tests for each target in each round fullpass testing.
 {| border="1" {{table}}
 | align="center" style="background:#f0f0f0;"|'''Test Target'''
 | align="center" style="background:#f0f0f0;"|'''System & Core OS'''
-| align="center" style="background:#f0f0f0;"|'''SDK'''
+| align="center" style="background:#f0f0f0;"|'''ADT'''
 | align="center" style="background:#f0f0f0;"|'''Compliance'''
 | align="center" style="background:#f0f0f0;"|'''Stress'''
@@ Line 66: / Line 69: @@
 | align="center" style="background:#f0f0f0;"|'''Mulitimedia'''
 |-
-| '''qemux86'''||yes||yes|| || || || ||
+| '''qemux86'''||yes||yes|| &nbsp;||&nbsp; ||&nbsp; ||&nbsp; || &nbsp;
+|-
+| '''qemux86-64'''||yes||yes||&nbsp; ||&nbsp; ||&nbsp; ||&nbsp; ||&nbsp;
+|-
+| '''qemuarm'''||yes||yes||yes ||&nbsp;||&nbsp; ||&nbsp; || &nbsp;
+|-
+| '''qemumips'''||yes||yes||yes ||&nbsp; ||&nbsp; ||&nbsp; ||&nbsp;
+|-
+| '''qemuppc'''||yes||yes||yes ||&nbsp; ||&nbsp; ||&nbsp; || &nbsp;
+|-
+| '''SugarBay'''||yes||&nbsp;  || yes ||&nbsp; ||yes||yes||yes
+|-
+| '''TunnelCreek'''||yes||&nbsp;  || &nbsp; ||&nbsp; ||yes||yes||yes
+|-
+| '''TunnelCreek noemgd'''||(basic functionality are tested)||&nbsp;  ||&nbsp;  ||&nbsp;  ||&nbsp;  ||&nbsp;  ||&nbsp;
+|-
+| '''FishRiver Island 2'''||yes||&nbsp;  || &nbsp; ||&nbsp; ||yes||yes||yes
 |-
-| '''qemux86-64'''||yes||yes|| || || || ||
+| '''HuronRiver'''||yes||&nbsp;  ||&nbsp; ||&nbsp; ||yes||yes||yes
 |-
-| '''qemuarm'''||yes||yes|| || || || ||
+| '''Jasperforest'''||yes||&nbsp;  ||&nbsp;||yes**||&nbsp; ||&nbsp; ||&nbsp;
 |-
-| '''qemumips'''||yes||yes|| || || || ||
+| '''Blacksand'''||yes||&nbsp;  || yes ||&nbsp; ||&nbsp; ||yes||yes
 |-
-| '''qemuppc'''||yes||yes|| || || || ||
+| '''eMenlow'''||yes||&nbsp;  ||&nbsp; ||&nbsp; ||&nbsp; ||yes||yes
 |-
-| '''SugarBay'''||yes|| ||yes|| ||yes||yes||yes
+| '''Beagleboard'''||yes|| &nbsp;  || yes* ||&nbsp; ||&nbsp; || &nbsp; || &nbsp;
 |-
-| '''CrownBay'''||yes|| || || ||yes||yes||yes
+| '''mpc8315e-rdb'''||yes|| &nbsp;  || yes ||&nbsp; ||&nbsp; || &nbsp; || &nbsp;
 |-
-| '''CrownBay noemgd'''||  (Only boot&installation are tested)|| || || || || ||
+| '''routerstation'''||yes|| &nbsp;  || yes* ||&nbsp; ||&nbsp; || &nbsp; || &nbsp;
 |-
-| '''FishRiver Island 2'''||yes|| ||yes|| ||yes||yes||yes
+| '''Pandaboard'''||yes|| &nbsp;  || &nbsp; ||&nbsp; ||&nbsp; || yes || yes
+|-
+|
+|}
+Note:
+* Compliance Test on Beagleboard and routerstation will only cover LTP and POSXI Test, since LSB test suite does not support ARM and MIPS.
+* Jasperforest is picked up for stress test, because it is powerful with 12 CPUs and 2GB memory. Moreover, it is a server, which needs more stress tests. The other test boards, like blacksand and eMenlow do not have powerful CPUs, that's why we do not use them for stress test.
+{| border="1" {{table}}
+| align="center" style="background:#f0f0f0;"|'''Core build feature'''
+| align="center" style="background:#f0f0f0;"|'''Functionality'''
+| align="center" style="background:#f0f0f0;"|'''Performance'''
+| align="center" style="background:#f0f0f0;"|'''Distribution Support'''
 |-
-| '''HuronRiver'''||yes|| || || ||yes||yes||yes
+| '''Core build'''||yes||yes||yes
 |-
-| '''Jasperforest'''||yes|| ||yes||yes|| || ||
+| '''Hob'''||yes||n/a||n/a
 |-
-| '''Blacksand'''||yes|| || || || ||yes||yes
+|
+|}
+{| border="1" {{table}}
+| align="center" style="background:#f0f0f0;"|'''Documentation Test'''
+| align="center" style="background:#f0f0f0;"|'''Quick Start Doc'''
 |-
-| '''eMenlow'''||yes|| || || || ||yes||yes
+| '''Documentation'''||yes
 |-
 |
@@ Line 124: / Line 160: @@
 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:
+'''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.
-* Weekly testing
-* Fullpass testing
 === Test Execution Cycle ===
@@ Line 165: / Line 199: @@
 |}
-Test report format : Pls. refer to [[Test Report Format]]
+Test report format : TBD
 === Test Automation ===
@@ Line 172: / Line 206: @@
 * Part of Weekly Test
 * Stress Test
-* Poky build Performance Test
+* Core build Performance Test
 === Test Infrastructure ===
@@ Line 180: / Line 214: @@
 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 ====
+==== System & Core OS(Covered in Weekly Test) ====
 * 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.
+* Installation/SW Update Test: Validate the Yocto image installation on hardware platform and software install/removal 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:
@@ Line 189: / Line 223: @@
 ** 3G
 ** ... etc
+(Basic functionality for tested features will be exercised as well as new functionality added in each release.)
-==== Poky Build System ====
+==== Core Build System(Covered in Fullpass Test) ====
-* Functionality Test: Test Poky build feature on standard host configuration. For example:
+* Functionality Test: Test Core build feature on standard host configuration. For example:
 ** kernel interactive targets
 ** non-GPLv3 build
 ** sstate
-** poky build in virtual machine
+** core build in virtual machine
 ** ... etc
-* Distribution support Test: Test Poky buld on latest Ubuntu, Fedora and Opensuse Hosts
+* Distribution support Test: Test Core buld on latest Ubuntu, Fedora and Opensuse Hosts
-* Performance Test: Check Poky build performance on standard host(Defined in perfromance test webpage)
+* Hob Test: Main UI and component functionality are validated (Some cases defined in weekly and some in fulpass)
+* Performance Test: Check Core build performance on standard host(Defined in perfromance test webpage)
-==== SDK Test ====
+==== ADT Test(Covered in Weekly Test) ====
 * Toolchain test, including compiler, libraries, etc.
-==== Stress Test ====
+==== Stress Test(Covered in Fullpass 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(Covered in Fullpass 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(Covered in Fullpass Test) ====
 Compliance Test is targeted to validate system level health with different system test suite.
 * LTP test suite
 * POSIX test
 * LSB test

Yocto 1.1 Overall Test Plan: Difference between revisions

Latest revision as of 14:13, 7 July 2011

Contents