Kernel Development QA: Difference between revisions

From Yocto Project
Jump to navigationJump to search
 
(34 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Kernel Development QA]]
This article is the test plan for kernel development features in Yocto Project.
This article is the test plan for Kernel Development.


= About Kernel Development =
==About Kernel Development==
Extensible SDK makes it easy to add new applications and libraries to an image, edit the source for an existing component, test the changes on the target hardware, and also allow you to integrate into the rest of [http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#build-system-term OpenEmbedded build system.]
In order to Setting up the extensible SDK please go to [http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-setting-up-to-use-the-extensible-sdk Setting Up to Use the Extensible SDK.]


= Objectives =
Describes common tasks you can perform on Yocto Project using kernel tools, and shows you how to use the metadata required to work with the kernel.
Verify all Kernel Development components to be fully functional.
For more information you can review the [http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html Kernel Development manual].
Components to be verified:


* linux-yocto-custom
==Objectives==
* local source
Verify all kernel development components are fully functional.
* local source with parallel meta
* local source with recipe-space meta
* External Source
* defconfig
* defconfig + fragments
* linux-yocto meta data + local fragments
* building external modules (hello-mod)


= Team members =
==Team members==
==QA Team involved in Kernel Development testing==
QA team members involved in Kernel Development testing:


[mailto:jair.de.jesus.gonzalez.plascencia@intel.com Jair Gonzalez]


[mailto:francisco.j.pedraza.gonzalez@intel.com Francisco Pedraza ]
==Scope==


= Scope =
===Types of Tests===
* linux-yocto-custom
* local source.
* local source with parallel meta.
* local source with recipe-space meta.
* External Source
* defconfig
* defconfig + fragments
* linux-yocto meta data + local fragments.
* building external modules (hello-mod).


* Manual tests on different platforms
* No automated tests at the moment


===Features Tested===
: 1. linux-yocto-custom
:: 1.1 local source
:: 1.2 local source with parallel meta
:: 1.3 local source with recipe-space meta
: 2. External Source
: 3. defconfig
: 4. defconfig + fragments
: 5. linux-yocto meta data + local fragments (WIP)
: 6. building external modules (hello-mod)


The complete set of test cases are documented on the [[Kernel Development Test Cases]] wiki. They are also listed on the master Kernel test plan in Testopia, that can be reached following this [https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=7435 link].


= Test Strategy =
==Test Strategy==
There are several test approaches for Kernel Development, such as:
There are several test approaches for kernel development, such as:
Perform test cases agreed upon the development during periodic Manual (full pass) according to the Schedule.
* Perform test cases agreed upon development during periodic full pass test cycles, according to the schedule.
Write new test cases based on developer request or new features as required.
* Write new test cases based on developer requests or new features added, as required.
Maintain current test cases and update them accordingly the new changes.
* Maintain current test cases and update them according to changes.
Perform exploratory testing on existing functionalities.
* Perform exploratory testing on existing functionalities.


===Test automation===
Tests will be gradually automated, after determining the feasibility to do so following discussions with the development team.


== Test automation ==
===Sanity testing===
Not required until now.
== Test Approach ==
 
=== Sanity testing ===
* Not covered at this moment
* Not covered at this moment
* TBD following DEV discussions
* TBD following discussions with the development team


=== Performance and Stress ===
===Test Process===
* Usability


===Regression===
: 1. Follow the steps as indicated on the [[Kernel Development Test Cases]] wiki.
* Regression testing will be covered on Automation execution.
: 2. Verify that all test cases pass. If not, raise bugs properly.
: 3. Update results to corresponding Testopia test run.


== Maintaining the test cases ==
===Submitting Bugs===
== Submitting Bugs ==
Being part of the Yocto Project, Kernel Development follows the same Yocto Project guidelines and principles. The guidelines can be found at https://wiki.yoctoproject.org/wiki/Community_Guidelines.  
Being part of the Yocto Project, Kernel Development follows the same Yocto Project guidelines and principles. The guidelines can be found at https://wiki.yoctoproject.org/wiki/Community_Guidelines.  
Kernel Development bugs are no different and are tracked into Bugzilla, the official Yocto Project bug tracker. Learn more about [https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking our process for reporting bugs].
Kernel Development bugs are no different than other Yocto Project bugs and are tracked into Bugzilla, the official Yocto Project bug tracker. Learn more about [https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking our process for reporting bugs].
 
=Requirements=
 
This set of requirements is listed in a two column format, Bugzilla entries vs. requirement description in the form of a user story.


<p>As a Developer I want to be able to apply single patch to Linux Kernel Source.  - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1614 Test Case 1614]</p>
==Requirements==
Use cases are documented in the corresponding section for each test case on [[Kernel Development Test Cases]] wiki.


<p>As a Developer I want to to be able to work with your own sources.  - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1615 Test Case 1615]</p>
===HW Requirements===
 
<p>As a Developer I want to be able to  generate and change  configuration files (defconfig).  - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1612 Test Case 1612]</p>
 
<p>As a Developer I want to be able to generate and change  configuration files (defconfig + fragments).  - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1613 Test Case 1613]</p>
 
 
The complete test cases are not completed due current design.
 
==HW Requirements==
* Any machine able to build Yocto Project.
* Any machine able to build Yocto Project.


==Software Requirements==
===Software Requirements===
* Poky.
* Poky
* GNU/Linux environment
* GNU/Linux environment


==Environment Requirements==
===Environment Requirements===
**YP 2.3 Release:
*YP 2.3 Release:
**Ubuntu-14.04
*Ubuntu-14.04
**Ubuntu-14.10
*Ubuntu-14.10
**Ubuntu-15.04
*Ubuntu-15.04
**Fedora-21
*Fedora-21
**CentOS-6.*
*CentOS-6.*
**CentOS-7.*
*CentOS-7.*
**Debian-7.*
*Debian-7.*
**Debian-8.*
*Debian-8.*
**openSUSE-project-13.2
*openSUSE-project-13.2
 
=Features=
<b> Features to be Tested </b>
 
<b><p>1. linux-yocto-custom.</p></b>
<p>1.1 local source. </p>
<p>1.2 local source with parallel meta</p>
<p>1.3 local source with recipe-space meta</p>
 


<b><p>2. External Source.</p></b>
==Schedule==
 
<b><p>3.Defconfig.</p></b>
<b><p>4.Defconfig + Fragments.</p></b>
<b><p>5.linux-yocto meta data + local fragments.</p></b>
<b><p>6.building external modules (hello-mod).</p></b>
 
 
 
= Schedule =
Every cycle depending on Milestone and release candidate
Every cycle depending on Milestone and release candidate


==Test execution Cycle==
===Test execution Cycle===
{| class="wikitable"
{| class="wikitable"
! Build
! Build
Line 133: Line 94:
|-
|-
| Weekly Build
| Weekly Build
| In progress
| TBD
| Y
| TBD
|-
|-
| Milestone Build
| Milestone Build
| Y
| TBD
| Y
| Y
|}
|}


=Dependencies=
==Dependencies==
*YP Dependencies
*YP Dependencies
** poky
** poky
** meta-kerneltest recipe
** meta-kerneltest layer
 
 
=Risk Assumptions=
* The complete features will not be tested now, the design of the test cases is under construction.
 
=Tools=
<p> TBD </p>
 
= Release Criteria/ Exit Criteria =
 
 
 
 
<!--
THIS IS THE OLD TESTING PLAN
 
= Test Areas =
eSDK consists of two big components, as follows:
 
== Backend ==
 
==== Functionality tests ====
*  [[REST_API_Contracts | REST API]]  verification – create Django tests to detect API calls returning incomplete (fields having null values) or wrong data for a certain set of entries from each table - our goal is to have 90% data collected. The tests can be found [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=andreeap/eSDK-tests&id=7cfd179be5db2a5530d60093fd09d0240138c2fa here];
*  Calculation of the data collection rate - the ratio between the number of the variables having null values ​​and the total number of variables collected (the data collection rate does not include wrong values); Run: ./fail_rate.py path_to_eSDK.sqlite_file. Output: table_name field_name value_that_never_changes and for each table a percentage: (the number of occurences of all the fields that never change their values)/(total number of entries for that table);
*  Verify that all links in the simple UI are available;
*  Verify the quality of the data collected through the simple UI;
*  Verify the quality of the data collected by verifying most of the values from the database by connecting directly to the database - our immediate goal is to have 90% correct data collected;
 
==== Usability tests ====
*  Verify the easy usage of eSDK ([https://wiki.yoctoproject.org/wiki/WebHob#Installation_and_Running easy to install and start/stop the eSDK server])
 
== Frontend ==
 
==== Functionality tests ====
*  Manual testing in the first stage;
*  Automate testing using  [http://www.seleniumhq.org/ Selenium], in the second stage;
 
==== Compatibility tests ====
*  Verify the behavior of the GUI on different browsers and operating systems; TBD
 
==== Usability tests ====
*  Verify if the GUI design is as described here: http://yoctoproject.org/webhob;
*  Friendly graphical user interface;
 
==== Performance tests ====
*  Stress testing (e.g. display appropriate error messages when the system is under stress);
 
= Test Cycle =
{|class="wikitable" style="text-align: center;"
| || || colspan="3" | Test execution cycle
|-
| || || [[#Weekly Test]] || [[#Full Pass Test]] || [[#Release Test]]
|-
| rowspan="2" | Build type || Weekly  || Yes || Yes ||
|-
| Release || Yes || Yes || Yes
|-
| rowspan="2" | [[#Test Areas]] || [[#Backend]] || Yes || Yes || Yes
|-
| [[#Frontend]]  || Yes || Yes || Yes
|-
| rowspan="5" | Target machine || qemuarm || || Yes || Yes
|-
| qemumips|| || || Yes
|-
| qemuppc|| || || Yes
|-
| qemux86|| Yes || Yes || Yes
|-
| qemux86-64  ||  ||  || Yes
|-
| rowspan="3" | Target image|| core-image-minimal|| Yes || ||
|-
| core-image-sato-sdk|| || Yes || Yes
|}
 
== Weekly Test ==
*; Scope:
** Images built weekly and released through the distribution team.
 
*; Objective:
** Functionality test on most areas with minimum sets of tests;
** Regression test with high probability to find bugs.


== Full Pass Test ==
==Risk Assumptions==
*; Scope:
* For each change in kernel version and kernel cache, the team needs to change many configuration files in order to achieve a correct execution.
** Images built as candidates for milestone or final release;
* Just like any software, the kernel is also susceptible to bugs.
** Passed [[#Weekly Test]]


*; Objective:
==Tools==
** Ensure functionality of eSDK component.
* bitbake
* yocto-layer
* bitbake-layers
* any available text editor


== Release Test ==
==Release Criteria/ Exit Criteria==
*; Scope:
* All test cases pass.
** Release candidates that pass [[#Full Pass Test]]
* No blocking issues are found.


*; Objective:
==References==
** All scheduled features are covered, or rescheduled;
* http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html
** All relevant bugs are fixed and verified.
* http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html
-->
Compendium of Yocto Project manuals, including the two above:
* https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html

Latest revision as of 21:35, 6 November 2017

This article is the test plan for kernel development features in Yocto Project.

About Kernel Development

Describes common tasks you can perform on Yocto Project using kernel tools, and shows you how to use the metadata required to work with the kernel. For more information you can review the Kernel Development manual.

Objectives

Verify all kernel development components are fully functional.

Team members

QA team members involved in Kernel Development testing: 

Jair Gonzalez

Scope

Types of Tests

  • Manual tests on different platforms
  • No automated tests at the moment

Features Tested

1. linux-yocto-custom
1.1 local source
1.2 local source with parallel meta
1.3 local source with recipe-space meta
2. External Source
3. defconfig
4. defconfig + fragments
5. linux-yocto meta data + local fragments (WIP)
6. building external modules (hello-mod)

The complete set of test cases are documented on the Kernel Development Test Cases wiki. They are also listed on the master Kernel test plan in Testopia, that can be reached following this link.

Test Strategy

There are several test approaches for kernel development, such as:

  • Perform test cases agreed upon development during periodic full pass test cycles, according to the schedule.
  • Write new test cases based on developer requests or new features added, as required.
  • Maintain current test cases and update them according to changes.
  • Perform exploratory testing on existing functionalities.

Test automation

Tests will be gradually automated, after determining the feasibility to do so following discussions with the development team.

Sanity testing

  • Not covered at this moment
  • TBD following discussions with the development team

Test Process

1. Follow the steps as indicated on the Kernel Development Test Cases wiki.
2. Verify that all test cases pass. If not, raise bugs properly.
3. Update results to corresponding Testopia test run.

Submitting Bugs

Being part of the Yocto Project, Kernel Development follows the same Yocto Project guidelines and principles. The guidelines can be found at https://wiki.yoctoproject.org/wiki/Community_Guidelines. Kernel Development bugs are no different than other Yocto Project bugs and are tracked into Bugzilla, the official Yocto Project bug tracker. Learn more about our process for reporting bugs.

Requirements

Use cases are documented in the corresponding section for each test case on Kernel Development Test Cases wiki.

HW Requirements

  • Any machine able to build Yocto Project.

Software Requirements

  • Poky
  • GNU/Linux environment

Environment Requirements

  • YP 2.3 Release:
  • Ubuntu-14.04
  • Ubuntu-14.10
  • Ubuntu-15.04
  • Fedora-21
  • CentOS-6.*
  • CentOS-7.*
  • Debian-7.*
  • Debian-8.*
  • openSUSE-project-13.2

Schedule

Every cycle depending on Milestone and release candidate

Test execution Cycle

Build Automated Test Manual Test
Daily Master NO NO
Weekly Build TBD TBD
Milestone Build TBD Y

Dependencies

  • YP Dependencies
    • poky
    • meta-kerneltest layer

Risk Assumptions

  • For each change in kernel version and kernel cache, the team needs to change many configuration files in order to achieve a correct execution.
  • Just like any software, the kernel is also susceptible to bugs.

Tools

  • bitbake
  • yocto-layer
  • bitbake-layers
  • any available text editor

Release Criteria/ Exit Criteria

  • All test cases pass.
  • No blocking issues are found.

References

Compendium of Yocto Project manuals, including the two above:

Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Kernel_Development_QA&oldid=32913"