Toaster testing plan: Difference between revisions
From Yocto Project
Jump to navigationJump to search
No edit summary |
|||
Line 15: | Line 15: | ||
==== Functionality tests ==== | ==== Functionality tests ==== | ||
* [[REST_API_Contracts | REST API]] verification – create Django tests to detect API calls returning no data; | * [[REST_API_Contracts | REST API]] verification – create Django tests to detect API calls returning no data; | ||
* Calculation of the data collection rate - the ratio | * Calculation of the data collection rate - the ratio between the number of the variables having null values and the total number of variables collected; | ||
* Verify that all links in the simple UI are available; | * 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 through the simple UI; |
Revision as of 13:48, 22 October 2013
Introduction
This article is the test plan for Toaster.
Objectives
The test process focuses on:
- validating the data collected from the build process;
- verifying the correct functioning of the Toaster GUI; TBD
Test Areas
Toaster consists of two big components, as follows:
Backend
Functionality tests
- REST API verification – create Django tests to detect API calls returning no data;
- Calculation of the data collection rate - the ratio between the number of the variables having null values and the total number of variables collected;
- Verify that all links in the simple UI are available;
- Verify the quality of the data collected through the simple UI;
Usability tests
- Verify the easy usage of Toaster (easy to install and start/stop the toaster server)
Frontend
Functionality tests
- Manual testing in the first stage;
- Automate testing using 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
Test execution cycle | ||||
#Weekly Test | #Full Pass Test | #Release Test | ||
Build type | Weekly | Yes | Yes | |
Release | Yes | Yes | Yes | |
#Test Areas | #Backend | Yes | Yes | Yes |
#Frontend | Yes | Yes | Yes | |
Target machine | qemuarm | Yes | Yes | |
qemumips | Yes | |||
qemuppc | Yes | |||
qemux86 | Yes | Yes | Yes | |
qemux86-64 | Yes | |||
Target image | core-image-minimal | Yes | 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
- Scope
- Images built as candidates for milestone or final release;
- Passed #Weekly Test
- Objective
- Ensure functionality of Toaster component.
Release Test
- Scope
- Release candidates that pass #Full Pass Test
- Objective
- All scheduled features are covered, or rescheduled;
- All relevant bugs are fixed and verified.