DownloadGlusterFS QA
From GlusterDocumentation
This information is out of date
and does not contain information related to the current version of Gluster
Documentation Home
Overview
This document seeks to describe the Quality Assurance processes to be followed at GlusterFS. This document and the processes described herein are set to evolve as the QA process evolves. This document covers the test phases, the build delivery cycle and the tools we will be using.
Test phases
This covers the different test phases that the GlusterFS test cycle will go through. This classification is to provide a distinction on the type of testing that will be performed on our product. Each of the test phases are set to evolve as they are put into practice.
Unit test
Unit testing is the preliminary stage of testing that each GlusterFS module (eg. the translators, glusterfsd) will go through. The Unit Tests for each module are designed by the QA team and the developer owning that module, and the test will be automated by the developer. This is the initial test that each Glusterfs module will go through before entering the QA cycle.
Sanity test
Unit testing is the preliminary stage of testing that each GlusterFS module (eg. the translators, glusterfsd) will go through. The Unit Tests for each module are designed by the QA team and the developer owning that module, and the test will be automated by the developer. This is the initial test that each Glusterfs module will go through before entering the QA cycle.
Quality check cycle
This is the the entry point into the QA team. The quality check consists of various test phases on the functionality and performance of the software. All releases to QA will go through the quality check cycle. The subphases are:
Packaging
This phase checks the packaging of glusterfs into .rpm or .deb packages. The packaging will be performed by the QA team, while the specfiles are written by the developers.
Functionality
This will check the functionality of the code. This involves testing of the installations of GlusterFS, including the various options. It also involves testing various attributes of the product, and various combinations of Specfiles. The specfiles used for testing shall ensure a 100% coverage of translators and will be a set of specfiles designed for the most commonly used configurations among our users.
Posix compliance
This phase checks the conformance of the product to posix standards for filesystems. The methodology for the same will be designed by us.
posix-locks
This tool (http://nfsv4.bullopensource.org/tools/tests/locktest.php) is useful in testing the posix-locks xlator. Example usage:
$ cd /mnt/glusterfs # /mnt/glusterfs is a glusterfs mount, with
# posix-locks loaded on the server side
$ gcc -o locktests locktests.c
$ touch test # file on which tests will happen
$ ./locktests -f test -n 4
Performance testing
The performance of the filesystem in terms of the speed of file I/O operations will be tested in this phase.
The above test sub-phases can be run in parallel. Packaging and Posix compliance are not time intensive tests, wheras Functionality and Performance testing can involve a fair amount of time. Any build that enters QA must pass the Quality check phase before it becomes a candidate for reliability testing. A majority of the testing in QA will involve this quality check cycle.
Stress testing
This test cycle will involve checking for race conditions. The stress test cycles are run parallel to the other cycles, and check how the product runs under boundary conditions.
Reliability testing
Reliability testing involves testing the product for stability and consistent performance over time. In our situation, it would locate failure points in components like buffers and counters. The process would involve testing the product over extended periods of time (over weeks) at slightly above average loads. Both the functionality and performance of the product are monitored over this period. Only builds that have passed the quality check phase are eligible for reliability test. The most stable builds to exit Quality check phase will be subjected to the reliability test, and in all ideal conditions, only the builds that pass reliability testing will be released to the customers. We plan to run two or three concurrent reliability tests, with a phase difference of the times the builds were released from the Quality check phase.
Field defect test cycle
Any defects that are returned to us will be put through a field defect test cycle. The defect will be reproduced by the QA team and the developer owning that module. After the defect has been fixed by the developer, it undergoes a test to ensure the defect is fixed, and it is passed through the unit and sanity test before integration into the build.
This information is out of date
and does not contain information related to the current version of Gluster
Documentation Home
