Added documentation for manual test cases.

Change-Id: If2de720644eef3606009258da703bb6854c97bb0
This commit is contained in:
Vitalii Yerys 2016-09-12 18:05:01 +03:00
parent 8111dc0513
commit 3be96792f6
4 changed files with 274 additions and 1 deletions

View File

@ -222,4 +222,7 @@ An ordinary test cycle for each iteration consists of the following steps:
.. include:: test_suite_smoke_bvt.rst
.. include:: test_gcs_gui.rst
.. include:: test_suite_integration.rst
.. include:: test_suite_functional.rst
.. include:: test_suite_functional.rst
.. include:: test_suite_destructive.rst
.. include:: test_suite_gui_negative.rst
.. include:: test_suite_system.rst

View File

@ -0,0 +1,144 @@
===================
Destructive testing
===================
Verify master controller fail in HA cluster will not crash the system
----------------------------------------------------------------------
ID
##
gcs_controller_failover
Description
###########
Verify that after non-graceful shutoff of controller node, cluster stays
operational and after turning it back online, cluster is operational.
Complexity
##########
manual
Steps
#####
1. Create an environment with 3 controller nodes at least
2. Install and configure GCS plugin
3. Deploy cluster
4. Verify Cluster using OSTF
5. Verify GCS plugin
6. Power off main controller (non-gracefully)
7. Run OSTF
8. Verify GCS plugin
9. Power on controller which was powered off in step 6.
10. Run OSTF
11. Verify GCS plugin
Expected results
################
All steps except step 7 must be completed successfully, without any errors.
Step 7 one OSTF HA test will fail, because one of controllers is offline - this
is expected.
Verify compute node fail in Non-HA cluster will not crush the system
--------------------------------------------------------------------
ID
##
gcs_compute_failover
Description
###########
Verify that after non-graceful shutoff of compute node cluster stays
operational and after turning it back online, cluster is operational.
Complexity
##########
manual
Steps
#####
1. Create an environment with 1 controller, cinder and 2 compute nodes
2. Install and configure GCS plugin
3. Deploy cluster
4. Run OSTF
5. Verify GCS plugin
6. Power off one of the computes (non-gracefully)
7. Run OSTF
8. Verify GCS plugin
9. Power on compute which was powered off in step 6
10. Run OSTF
11. Verify GCS plugin
Expected results
################
All steps except step 7 must be completed successfully, without any errors.
Step 7 one OSTF test will fail, because one of nodes is offline - this is
expected.
Verification of Cinder node non-graceful shutoff in HA cluster
--------------------------------------------------------------
ID
##
gcs_cinder_failover
Description
###########
Verify that after non-graceful shutoff of cinder node cluster stays
operational and after turning it back online, cluster is operational.
Complexity
##########
manual
Steps
#####
1. Create an environment with 1 controller, compute and 2 cinder nodes
2. Install and configure GCS plugin
3. Deploy cluster
4. Run OSTF
5. Verify GCS plugin
6. Power off one of the cinder nodes (non-gracefully)
7. Run OSTF
8. Verify GCS plugin
9. Power on cinder node which was powered off in step 6
10. Run OSTF
11. Verify GCS plugin
Expected results
################
All steps except step 7 must be completed successfully, without any errors.
Step 7 one OSTF test will fail, because one of nodes is offline - this is
expected.

View File

@ -0,0 +1,82 @@
====================
GUI negative testing
====================
Check the plugin reaction on non-consistent data in plugin configuration fields
-------------------------------------------------------------------------------
ID
##
gcs_non_consistent_configuration
Description
###########
Verify that during plugin configuration, non-consistent input into plugin
configuration fields are handled properly.
Complexity
##########
manual
Steps
#####
1. Deploy fuel master node
2. Enable GCS plugin
3. Verify that multiple lines in plugin fields are handled correctly
4. Verify if special characters in url fields are handled properly
5. Verify 'Client E-mail' field with incorrect patterns for e-mail
Expected results
################
All incorrect inputs must be handled properly, and warning should be displayed.
Check the plugin reaction on invalid configuration, typos verification
----------------------------------------------------------------------
ID
##
gcs_invalid_configuration
Description
###########
Verify that during plugin configuration with invalid data, proper errors are
displayed after a attempt of deployment.
Complexity
##########
manual
Steps
#####
1. Create an environment with 1 controller, compute, cinder node
2. Enable GCS plugin
3. Configure plugin with invalid bucket location and try to create backup in new bucket
4. Verify that during deployment of changes proper error/warning is shown
5. Configure plugin with invalid private key
6. Verify that during deployment of changes proper error/warning is shown
Expected results
################
Steps 4, 6 will fail with proper error message.

View File

@ -0,0 +1,44 @@
==============
System testing
==============
Check data consistency of backed up volume
------------------------------------------
ID
##
gcs_data_consistency_verification
Description
###########
Verify that data writen into volume stays consistent after backup restoration.
Complexity
##########
manual
Steps
#####
1. Boot VM and attach volume to it
2. Write a test file onto volume and get it md5sum value
3. Backup volume
4. Destroy VM and volume
5. Boot VM and restore volume from a GCS
6. Attach restored volume to a VM
7. Verify file consistency by comparing md5sum value with value obtained in step 5
Expected results
################
All steps must be completed successfully, without any errors. Both md5sum
values obtained from step 2 and 7 must be the same.