Yocto Project - User contributions [en]

Watch Yocto Bugs

2010-12-21T13:21:29Z

YongkangYou:

Yocto bugzilla adds a lot of fake users for each product and classification as components' default CC user. If developer/tester want to get some components intime bug update, (s)he can '''Watch''' related fake user.

* How to '''Watch'''?
# Login Yocto bugzilla.
# Click user '''Preferences'''
# Select '''Email Preferences'''
# Find fake user email address and '''Add users to my watch list'''

* Fake user email address and Classification/Product list
{| border="1"
|Classification || Product || Fake user
|-
|Yocto Projects || || yp.watcher@fake.user
|-
| || Cross-prelink || yp.cp.watcher@fake.user
|-
| || Swabber ||yp.swabber.watcher@fake.user
|-
| || Pseudo || yp.pseudo.watcher@fake.user
|-
| || Eclipse Plugin || yp.ep.watcher@fake.user
|-
| || Anjuta Plugin || yp.ap.watcher@fake.user
|-
| || Kernel || yp.kernel.watcher@fake.user
|-
| || Test Suite || yp.test.watcher@fake.user
|-
| || BSPs || yp.bsp.watcher@fake.user
|-
| || SDK tools || yp.sdk.watcher@fake.user
|-
|Infrastructure || || Infras.watcher@fake.user
|-
| || Autobuilder ||infras.ab.watcher@fake.user
|-
| || Website ||infras.web.watcher@fake.user
|-
| || Bugzilla || infras.bug.watcher@fake.user
|-
|Poky || || poky.watcher@fake.user
|-
| || Build System || poky.bs.watcher@fake.user
|-
| || Documentation || poky.doc.watcher@fake.user
|-
| || ADT || poky.adt.watcher@fake.user
|-
| || Security || N/A
|-
| Yocto Metadata Layers || || meta.watcher@fake.user
|-
| || Meta Recipes || meta.mr.watcher@fake.user
|-
| || Layers || meta.layer.watcher@fake.user
|}

Watch Yocto Bugs

2010-12-21T13:19:29Z

YongkangYou:

Yocto bugzilla adds a lot of fake users for each product and classification as components' default CC user. If developer/tester want to get some components intime bug update, (s)he can '''Watch''' related fake user.

* How to '''Watch'''?
# Login Yocto bugzilla.
# Click user '''Preferences'''
# Select '''Email Preferences'''
# Find fake user email address and '''Add users to my watch list'''

* Fake user email address and Classification/Product list
{| border="1"
|Classification || Product || Fake user
|-
|Yocto Projects || || yp.watcher@fake.user
|-
| || Cross-prelink || yp.cp.watcher@fake.user
|-
| || Swabber ||yp.swabber.watcher@fake.user
| || Pseudo || yp.pseudo.watcher@fake.user
| || Eclipse Plugin || yp.ep.watcher@fake.user
| || Anjuta Plugin || yp.ap.watcher@fake.user
| || Kernel || yp.kernel.watcher@fake.user
| || Test Suite || yp.test.watcher@fake.user
| || BSPs || yp.bsp.watcher@fake.user
| || SDK tools || yp.sdk.watcher@fake.user
|Infrastructure || || Infras.watcher@fake.user
| || Autobuilder ||infras.ab.watcher@fake.user
| || Website ||infras.web.watcher@fake.user
| || Bugzilla || infras.bug.watcher@fake.user
|Poky || || poky.watcher@fake.user
| || Build System || poky.bs.watcher@fake.user
| || Documentation || poky.doc.watcher@fake.user
| || ADT || poky.adt.watcher@fake.user
| || Security || N/A
| Yocto Metadata Layers || || meta.watcher@fake.user
| || Meta Recipes || meta.mr.watcher@fake.user
| || Layers || meta.layer.watcher@fake.user
|}

Watch Yocto Bugs

2010-12-21T13:09:23Z

YongkangYou: Created page with 'Yocto bugzilla adds a lot of fake users for each product and classification as components' default CC user. If developer/tester want to get some components intime bug update, (s)…'

QA

2010-12-21T12:06:19Z

YongkangYou:

See the http://yoctoproject.org/projects/testing-qa-and-autobuilder page on the website for more information on this project.

* Yocto 0.9
** Yocto 0.9 [[Overall Test Plan]]
** Yocto 0.9 [[Milestone Test Report]]
* Yocto 1.0
**[[Yocto 1.0 Overall Test Plan]]
** Yocto 1.0 Milestone Test Report [[1.0 Milestone Test Report]]
* [[Enabling Automation Test in Poky]]
* [[LTP result]]
* [[Posix result]]
* [[LSB result]]
* How to [[Watch Yocto Bugs]]

Yocto 1.0 Overall Test Plan

2010-11-23T06:50:31Z

YongkangYou:

== Yocto 1.0 Overall Test Plan ==
This overall test plan defines test scope, test strategy, test configurations as well as test execution cycle for Yocto v1.0 program.

=== Features to Be Tested ===
* Core OS: The core OS feature included Yocto kernel, distro components testing, fast boot, file system, device drivers (e.g. Intel Graphics Driver).
* Poky build system: It includes bitbake test and poky build feature testing.
* Yocto SDK: SDK testing covers SDK plugin, toolchain and SDK tools testing.
* 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.
* 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 v1.0 ===
Following feature categories won't be tested by QA team in Yocto v1.0:
* 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 ====

{|border="1" cellpadding="5"
! Category !! colspan="5"| Qemu !! colspan="4" | Atom !! colspan="2" | Core i7 !! colspan="2" | Xeon !! ARM HW !! PPC HW !! MIPS HW
|-
! Platform
|   ||   ||   ||   ||   || netbook || e-Menlow || Blacksand || TunnelCreek || colspan="2" | SandBridge || colspan="2" | JasperForest || Beagleboard || mpc8315e-rdb || routerstationpro
|-
! Arch
| x86_32 || x86_64 || arm || ppc || mips || x86_32 || x86_32 || 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 ||  
|-
! SDK image
| yes || yes || yes || yes || yes || yes ||   || yes || yes ||   ||   ||   ||   || yes || yes || yes
|-
! LSB image
| yes || yes || yes || yes || yes ||   ||   ||   ||   ||   || yes || yes || yes ||   || yes ||  
|}

=== Test Levels ===
The Yocto 1.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 ===
{|border="1" solid
! 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.

{|border="1" solid
! 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 ===
If QA has resource, test infrastructure will be investigated in Yocto v1.0. Automation test cases development should be test infrastructure independent.

=== Test Design ===

==== Core OS ====
* Boot Test: Check if Yocto image is bootable with the bootloader.
* Poky Feature: Poky runtime functionality. For example:
** Image Creator
** KVM enabled with qemu
** ... etc
* Component Test (aka. Feature Test): Based on minimal and sato image features to test. For example:
** Perl
** Rootless X
** Qemu mem/disk size customizable
** ... etc
* Compliance Test
** LTP test suite
** POSIX test
** LSB test
* Developer unit test suite

==== Poky Build System ====
* Bitbake Test: Basic bitbake functionality test, with automation test script for shell, python, variable testing in bitbake.
* Build Test: Poky build feature and real build on different OSD hosts. For example:
** multi-threaded parsing
** kernel interactive targets
** checksum, sstate
** poky tree build on Ubuntu, Fedora, Opensuse, etc
** Other cases, like building in virtual machine, etc

==== SDK Test ====
* SDK plugin functional test. It is based on SDK HLD definition.
* Toolchain test, including compiler, libraries, etc.
* SDK tools test, like oprofileUI, powertop, sdk generator etc.

==== Installation/SW Update ====
* Test Method:
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.

==== 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/Performance ====
* 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, industry standard benchmark will be executed. The performance results should be collected and published for analysis and tuning.

Yocto 1.0 Overall Test Plan

2010-11-23T02:31:30Z

YongkangYou: Created page with '== Yocto 1.0 Overall Test Plan == This overall test plan defines test scope, test strategy, test configurations as well as test execution cycle for Yocto v1.0 program. === Featu…'

== Yocto 1.0 Overall Test Plan ==
This overall test plan defines test scope, test strategy, test configurations as well as test execution cycle for Yocto v1.0 program.

=== Features to Be Tested ===
* Core OS: The core OS feature included Yocto kernel, distro components testing, fast boot, file system, device drivers (e.g. Intel Graphics Driver).
* Poky build system: It includes bitbake test and poky build feature testing.
* Yocto SDK: SDK testing covers SDK plugin, toolchain and SDK tools testing.
* 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.
* 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 v1.0 ===
Following feature categories won't be tested by QA team in Yocto v1.0:
* 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 ====

{|border="1" cellpadding="5"
! Category !! colspan="5"| Qemu !! colspan="4" | Atom !! colspan="2" | Core i7 !! colspan="2" | Xeon !! ARM HW !! PPC HW !! MIPS HW
|-
! Platform
|   ||   ||   ||   ||   || netbook || e-Menlow || Blacksand || TunnelCreek || colspan="2" | SandBridge || colspan="2" | JasperForest || Beagleboard || mpc8315e-rdb || routerstationpro
|-
! Arch
| x86_32 || x86_64 || arm || ppc || mips || x86_32 || x86_32 || 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 ||  
|-
! SDK image
| yes || 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 1.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 ===
{|border="1" solid
! 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.

{|border="1" solid
! 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 ===
If QA has resource, test infrastructure will be investigated in Yocto v1.0. Automation test cases development should be test infrastructure independent.

=== Test Design ===

==== Core OS ====
* Boot Test: Check if Yocto image is bootable with the bootloader.
* Poky Feature: Poky runtime functionality. For example:
** Image Creator
** KVM enabled with qemu
** ... etc
* Component Test (aka. Feature Test): Based on minimal and sato image features to test. For example:
** Perl
** Rootless X
** Qemu mem/disk size customizable
** ... etc
* Compliance Test
** LTP test suite
** POSIX test
** LSB test
* Developer unit test suite

==== Poky Build System ====
* Bitbake Test: Basic bitbake functionality test, with automation test script for shell, python, variable testing in bitbake.
* Build Test: Poky build feature and real build on different OSD hosts. For example:
** multi-threaded parsing
** kernel interactive targets
** checksum, sstate
** poky tree build on Ubuntu, Fedora, Opensuse, etc
** Other cases, like building in virtual machine, etc

==== SDK Test ====
* SDK plugin functional test. It is based on SDK HLD definition.
* Toolchain test, including compiler, libraries, etc.
* SDK tools test, like oprofileUI, powertop, sdk generator etc.

==== Installation/SW Update ====
* Test Method:
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.

==== 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/Performance ====
* 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, industry standard benchmark will be executed. The performance results should be collected and published for analysis and tuning.

QA

2010-11-23T02:17:26Z

YongkangYou: