Test Case: test_NoBackLogBuf_01
Description:
Synopsis:
Test correct handling when Back-Log Buffering is disabled.
Description:
The purpose of this test is to check the proper functioning when
Back-Log Buffering is disabled and an error qualifying for Back-Log
Buffering occurs, in this case DB com. problem (NGAMS_ER_DB_COM).
Expected Result:
The DAPI encounters a (simulated) problem with the DB communication
and raises an exception. NG/AMS should recognize this, and should
not Back-Log Buffer the file. The Staging Files should be deleted.
Staging Area, Back-Log Buffer and Bad Files Area should not contain
any files.
Test Steps:
- Start server with test configuration, which specifies a DAPI that
raises an exception which normally would qualify for Back-Log
Buffering. Janitor Thread Suspension Time = very long + Back-Log
Buffering disabled.
- Archive file.
- Check response that the file could not be archived due to the
problem.
- Check that the Staging Areas, Back-Log Buffer and Bad Files Area
contains no files.
Remarks:
...
Test Case: test_NoDapi_01
Description:
Synopsis:
No DAPI installed to handled request/Archive Push/wait=1.
Description:
If the specified DAPI cannot be loaded during the Archive Request
handling it is not possible to handle the Archive Request and
the server must bail out.
Expected Result:
The Archive Request handling should be interrupted and an error
reply sent back to the client since wait=1. The files in connection
with the request should be removed from the Staging Area.
Test Steps:
- Start server with configuration specifying a non-existing DAPI
to handle FITS files.
- Archive FITS file (wait=1).
- Check error reply from server.
- Check that Staging Area is cleaned up.
- Check that no files were archived.
- Check that no files moved to Bad Files Area.
Remarks:
...
Test Case: test_NormalArchivePushReq_1
Description:
Synopsis:
Test handling of normal Archive Push Request/check that Disk
Change Notification Message is sent out.
Description:
This Test Case exercises the Archive Push Request. It is checked
that a disk change is done as expected and that an Email Notification
Message is sent out in this connection.
The contents of the DB should be updated (ngas_files, ngas_disks)
and the NgasDiskInfo file on the completed disk as well.
Expected Result:
After the first Archive Request, the first Target Disk Set should
be marked as completed and an Email Notification sent out
indicating this (Email Disk Change Notification).
The information about the Main and Rep. Files should be indicated
in the DB. The entry for that disk in ngas_disks should be updated.
The NgasDiskInfo file on the Target Disk Set, which is now completed,
should be updated with the newest information and marked as completed.
Test Steps:
- Start server setting Email Notification up to work on local host
and sending the emails to the user running the test + set the
amount of required, free space so high that an immediate Disk
Change will take place.
- Archive a file.
- Receive the Email Notification + check the contents of this.
- Dump the info for the Main and Rep. Disks and check these.
- Dump the info for the Main and Rep. Files and check these.
- Load the NgasDiskInfo files on the Target Disk Set disks and
check the contents of these.
Remarks:
Consider to re-implement this Text Case, using the simulated disks in
the form of file systems in files.
Test Case: test_NormalArchivePushReq_2
Description:
Synopsis:
Test handling of normal Archive Push Request/check that Disk Space
Notification Message is sent out.
Description:
Before a disks get classified as completed, a Disk Space Notification
Message can be sent out to prepare the operators that soon a Disk
Set will be full. This test checks if this message is sent out as
expected.
Expected Result:
After having issued an Archive Push Request the disk should
reach the thresshold value for sending out the Disk Space Notification
Email.
Test Steps:
- Start server with cfg. specifying test user at localhost as
receiver for the Disk Space Notification Messages + set the threshold
for sending out Disk Space Notification Messages so high, that this
will happen immediately.
- Archive a file (Archive Push).
- Receive the Notification Message and check the contents.
Remarks:
Consider to re-implement this Text Case, using the simulated disks in
the form of file systems in files.
Test Case: test_NormalArchivePushReq_4
Description:
Synopsis:
Test handling of normal Archive Push Request/no_versioning=1.
Description:
It is possible to indicate to the NG/AMS Server in connection with an
Archive Request, that no new version number should be allocated
(if this is supported by the DAPI). If this is the case a file
archived with the same File ID as a previous file archived will
overwrite this, at least the DB entry, possibly also the file on disk
if NGAS is still writing to the same disk.
Expected Result:
After archiving the file the 2nd time, the first entry should be
overwritten.
Test Steps:
- Start server.
- Issue Archive Push Request/no_versioning=1.
- Re-issue the same Archive Push Request/no_versioning=1.
- Check that the File Info is the same for the 2nd Archive Request
as for the first.
Remarks:
...
Test Suite: ngamsArchiveStressTest
Description:
Synopsis:
Archive Stress Tests.
Description:
Various Test Cases which exercise an intensive archive activity.
Due to time constraints, the tests do not stress the system as much
as desirable. Could be enhanced in the near future if more performant
HW is used.
Missing Test Cases:
...
Test Case: test_StressTest_1
Description:
Synopsis:
Archive a small file 20 times, sequentially
Description:
The Test Case execises the situation where a (small) FITS file is
archived sequentially for a certain number of times.
Expected Result:
All N Archive Requests should be handled successfully.
Test Steps:
- Start server.
- Issue a small FITS file N times, check that a response is returned
indicating a successfull execution.
Remarks:
To make this test useful, it would be better to archive a much
higher quantity of files to test also the stability of handling
1000s requests over a long period of time.
Test Case: test_StressTest_2
Description:
Synopsis:
Archive small file 20 times/10 threads simultaneously/same File ID.
Description:
The purpose of this test is to test the capability of the server
to handle simultaneously incoming Archive Requests.
The ARCFILE keyword is not incremented, which means that the resulting
File ID (using the FITS DAPI), is constant.
Expected Result:
The 20 * 10 Archive Requests going on in parallel should handled
without problems. Since the resulting File ID is constant, and a new
File Version thus allocated at each Archive Request, there should be
200 new files archived with the same File ID but different File
Version and registered in the NGAS DB.
Test Steps:
- Start server.
- Schedule 10 threads to archive a small FITS file in parallel.
- Wait until all 10 threads have finsished archiving with a max.
timeout of 100s.
- In each thread: Check that the file was successfully archived.
Remarks:
This Test Case revealed a problem in the NG/AMS Server, whereby
if several Archive Requests of a file with the same File ID, may
lead to a blocking situation (DFS02065):
- The Sybase interface throws an exception because it is tried to
insert a duplicate row in ngas_files.
- The thread tries to reconnect.
- After reconnecting to the DB, it seems that repeating the
query blocks.
=> Find out where the blocking origins from.
=> Should be possible to distinguish between DB com. errors and
semantical errors. Only in the former case a reconnection should
be attempted.
Test Case: test_StressTest_3
Description:
Synopsis:
Archive small file 20 times/10 threads simultaneously/different File ID
Description:
The purpose of this test is to test the capability of the server
to handle simultaneously incoming Archive Requests.
The ARCFILE keyword is incremented, which means that the resulting
File ID (using the FITS DAPI), is different at each Archive Request.
Expected Result:
The 20 * 10 Archive Requests going on in parallel should handled
without problems. Since the resulting File ID is constant, and a new
File Version thus allocated at each Archive Request, there should be
200 new files with different File Ids archived and registered in the
NGAS DB.
Test Steps:
- Start server.
- Schedule 10 threads to archive a small FITS file in parallel.
- Wait until all 10 threads have finsished archiving with a max.
timeout of 100s.
- In each thread: - Increment the value of ARCFILE to obtain a
new File ID for each file.
- Check that the file was successfully archived.
Remarks:
...
Test Suite: ngamsAuthorizationTest
Description:
Synopsis:
Test the Authorization Service implemented by NG/AMS.
Description:
The NG/AMS Server implements the basic HTTP authorization. In this
Test Suite the proper functioning of this feature is exercised. This
both with authorization enabled and disabled and valid/non-valid
authorization code.
Missing Test Cases:
- IMPL!: Test internal authorization when:
- Cloning files between two nodes.
- Retrieving files between two nodes.
- Other combinations of retrieve requests.
- Other commands where a node may act as proxy.
Test Case: test_AuthReq_1
Description:
Synopsis:
Successful HTTP auth.
Description:
Test that a request is accepted when Authorization is
enabled and the proper Authorization Code is given with the query.
Expected Result:
The request is submitted with a valid HTTP auth. code. The NG/AMS
Server thus accepts and executes the request.
Test Steps:
- Start server with HTTP auth. enabled + a number of users defined.
- Issue STATUS Command with a valid auth. code.
- Check that the command is successfully executed.
Remarks:
...
Test Case: test_NoAuth_1
Description:
Synopsis:
Issue a request with Authorization disabled.
Description:
When HTTP Authorization is disabled requests can be submitted
without issuing the authorization code.
This Test Case exercises this case.
Expected Result:
The STATUS Command issued without authorization, should be accepted and
executed by the NG/AMS Server.
Test Steps:
- Start standard server with HTTP auth. disabled.
- Issue STATUS Command.
- Check that the command was successfully executed.
Remarks:
...
Test Case: test_UnAuthReq_1
Description:
Synopsis:
Request rejected when HTTP Auth. enabled and no Auth. Code issued
Description:
This Test Cases exercises the case where HTTP Authorization is
enabled in the NG/AMS Server, but where no HTTP Authorization code
is issued with a request.
Expected Result:
The NG/AMS Server will return a 'failed authorization response'
(challenging the client), which in this case means that the request
is rejected.
Test Steps:
- Start server with HTTP auth. enabled + a number of users defined.
- Issue a STATUS Command without the HTTP auth. code.
- Check that an NGAMS_ER_UNAUTH_REQ error code is returned.
Remarks:
Should also check if the HTTP response code is correct.
Test Case: test_UnAuthReq_2
Description:
Synopsis:
HTTP auth. enabled, illegal HTTP auth. code issued.
Description:
The purpose of this test is to check that the NG/AMS Server
rejects a request if HTTP auth. is enabled and in invalid HTTP
auth. code is submitted with the request.
Expected Result:
The server should detect the invalid HTTP auth. code and reject the
request.
Test Steps:
- Start server with HTTP auth. enabled + a number of users defined.
- Issue STATUS Command with an invalid auth. code.
- Check that an NGAMS_ER_UNAUTH_REQ error code is returned.
Remarks:
Should also check if the HTTP response code is correct.
Test Suite: ngamsCClientTest
Description:
Synopsis:
Tests of NG/AMS CClient + NG/AMS C-API.
Description:
The purpose of this Test Suite is to exercise the NG/AMS C-Client
and thereby also the NG/AMS C-API.
The NG/AMS Archive Client is tested in a separate suite
(ngamsArchiveClientTest).
Missing Test Cases:
Test Suite should be reviewed and missing Test Cases added. Many Test Cases
exercizing different combination of command line options for the
NG/AMS C-Client are missing.
Note: Action Remedy Ticket DFS01570 suggests a simplification of the
command line interface of the NG/AMS C-Client and of the C-API.
If this is implemented, this Test Suite will be simpler, i.e.,
less Test Cases must be implemented.
Test Case: test_ArchiveCmd_1
Description:
Synopsis:
Issue ARCHIVE Command via C-Client/API.
Description:
The purpose of the test is to verify that the C-Client/API can
handle properly an ARCHIVE Command.
Expected Result:
The ARCHIVE Command + the data of the specified file should be
transferred to the server and the file archived successfully.
Test Steps:
- ...
Remarks:
IMPL: To be implemented.
Test Case: test_ArchiveCmd_Err_1
Description:
Synopsis:
Issue ARCHIVE Command/request times out.
Description:
The purpose of the test is to check that a request that times out
is handled properly by the C-Client/API and a proper error message
is produced.
Expected Result:
After the given timeout, the C-Client/API should generate a timeout
error message.
Test Steps:
- Start speciel instance of server where Archive Requests blocks.
- Issue Archive Request (small file) specifying a timeout of 10s.
- Capture the output from the ngamsCClient, filter this, and
check that the proper error message has been generated.
Remarks:
...
Test Case: test_ArchiveCmd_Err_2
Description:
Synopsis:
Issue ARCHIVE Command/server crashes (broken socket connection).
Description:
The purpose of the test is to verify the correct handling/behavior
of the C-Client/API in the case the socket connection to the server
breaks.
Expected Result:
During the request handling the socket connection is provoked to break
and the C-Client/API should detect this and shoudl produce the proper
error message.
Test Steps:
- Start special instance of the server which makes itself crash when
a request is received (to simulate a broken socket connection).
- Submit an ARCHIVE Command via the C-Client/API (small file).
- Check the result produced by the ngamsCClient on stdout that this
is as expected.
Remarks:
...
Test Case: test_ArchiveCmd_Err_3_1
Description:
Synopsis:
Handling of corrupted HTTP response.
Description:
The purpose of the test is test that a corrupted HTTP response is
properly handled by the C-Client/API.
The response is corrupted such that it only contains a '
'
({Slash r}{Slash n}).
Expected Result:
The corrupt HTTP response cannot be unpacked/interpreted as an
XML document. This should be detected by the C-API and a proper
error message returned.
Test Steps:
- Start special instance of the server class, which produces
an illegal response.
- Issue an ARCHIVE Command via the ngamsCClient.
- Check that the output produced on stdout refers to the appropriate
error message.
Remarks:
...
Test Case: test_ArchiveCmd_Err_3_2
Description:
Synopsis:
Issue ARCHIVE Command/server sends back an empty HTTP response (='').
Description:
The purpose of the test is test that a corrupted HTTP response is
properly handled by the C-Client/API.
The response is corrupted such that it does not have any contents.
Expected Result:
The C-API should detect the illegally formatted response and return
the correct error code.
Test Steps:
- Start special instance of the server that generates an empty
HTTP response.
- Issue an Archive Request.
- Check that the proper error message is produced by the ngamsCClient
Remarks:
...
Test Case: test_ArchiveCmd_Err_3_3
Description:
Synopsis:
Issue ARCHIVE Command/server sends back a nonsense HTTP response.
Description:
The purpose of the test is test that a corrupted HTTP response is
properly handled by the C-Client/API.
The response is corrupted such that it contains 'noise'.
Expected Result:
The C-API should detect the illegally formatted response and return
the correct error code.
Test Steps:
- Start special instance of the server that generates a non-sense
HTTP response.
- Issue an Archive Request via the ngamsCClient.
- Check that the proper error message is produced by the ngamsCClient
Remarks:
...
Test Case: test_ArchiveCmd_Err_4_1
Description:
Synopsis:
Correct HTTP response, but illegal NG/AMS XML status document.
Description:
The purpose of the test is to verify that the C-Client/API handles
correctly the situation where an incorrectly formatted XML status
response is contained in the response from the server and the
proper error code generated by the C-API.
Expected Result:
The C-API detects the wrongly formatted NG/AMS XML status document,
and produces the appropriate error code.
Test Steps:
- Start special instance of the server which generates an HTTP
response with a corrupt XML NG/AMS status document.
- Issue an Archive Request via the ngamsCClient.
- Compare the output from ngamsCClient to check that the invalid
response was correctly handled.
Remarks:
...
Test Case: test_ArchiveCmd_Err_5_1
Description:
Synopsis:
Issue ARCHIVE Command/socket breaks while writing data on it.
Description:
The purpose of the test is to verify that the C-API handles
properly the situation where the socket connection breaks while
data is being written on it (during an Archive Push Request).
Expected Result:
The C-API should detect that the write socket connection breaks, and
should produce the appropriate error message.
Test Steps:
- Start special instance of server which terminates itself while
the client writes the data to the server.
- Issue Archive Push Request with a big file to the server.
- Verify that the proper error response is produced by the C-API.
Remarks:
...
Test Case: test_CheckfileCmd_1
Description:
Synopsis:
Issue CHECKFILE Command.
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL: To be implemented.
Test Case: test_CloneCmd_1
Description:
Synopsis:
Issue CLONE Command to server.
Description:
The purpose of this test is to check the proper handling of the
CLONE Command through the C-Client/API.
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL: Not yet implemented.
Test Case: test_RemDiskCmd_1
Description:
Synopsis:
Issue REMDISK Command.
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL: To be implemented.
Test Case: test_RemFileCmd_1
Description:
Synopsis:
Issue REMFILE Command.
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL: To be implemented.
Test Case: test_RetrieveCmd_1
Description:
Synopsis:
Issue RETRIEVE Command.
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL: To be implemented.
Test Case: test_RetrieveCmd_Err_1_1
Description:
Synopsis:
Issue RETRIEVE Command/request times out.
Description:
The purpose of the test is to verify that the situation where a
Retrieve Request times out is correctly handled by the C-API.
Expected Result:
After the specified timeout is reached, the appropriate error code
is returned to the client.
Test Steps:
- Start special instance of the server, which blocks on a Retrieve
Request (no response send).
- Issue a Retrieve Request via the ngamsCClient with timeout 10s.
- Verify that after 10s the correct error code is returned by the
C-API (printed by ngamsCClient on stdout).
Remarks:
...
Test Case: test_RetrieveCmd_Err_1_2
Description:
Synopsis:
Issue RETRIEVE Command/server dies during initial handling.
Description:
Check that the situation where the server dies during the initial
handling of a Retrieve Request is correctly handled by the C-API.
Expected Result:
The C-API should detect that the server died (=broken socket
connection) and should produce the appropriate error code, which is
printed on stdout by the ngamsCClient.
Test Steps:
- Start a special instance of the server, which kills itself
when receiving a RETRIEVE Command.
- Archive a file.
- Issue a RETRIEVE Command to retrieve the archived file.
- Verify that the proper output is produced by ngamsCClient indicating
the problem.
Remarks:
...
Test Case: test_RetrieveCmd_Err_1_3
Description:
Synopsis:
Issue RETRIEVE Command/server dies (connection broken)
while the server is sending the data across.
Description:
The purpose of the test is to verify that the C-Client/API handle
properly the situation where the socket connection where the server
is writing data to the client breaks.
Expected Result:
The C-API should detect the problem, and that the file has been
received incomplete and should return the proper error code, which
is written by ngamsCClient on stdout.
Test Steps:
- Start special instance of the server class, which terminates itself
while returned requested data.
- Archive a file.
- Retrieve the file.
- Check that the proper error response is created on stdout by
ngamsCClient.
Remarks:
...
Test Case: test_StatusCmd_1
Description:
Synopsis:
Issue STATUS Command/basic (no parameters).
Description:
Issue a STATUS Command via the C-Client (on the shell).
Expected Result:
The STATUS Command should be accepted and executed by the C-Client
and the server.
Test Steps:
- Start standard server.
- Execute the ngamsCClient tool on the shell.
- Capture the output from the ngamsCClient and compare this with the
expected output.
Remarks:
...
Test Case: test_StatusCmd_2
Description:
Synopsis:
Issue STATUS Command/proxy mode (host_id).
Description:
The purpose of this Test Case is to check that the ngamsCClient
accepts the -hostId command line parameter and transfers this
properly to the server. This is used for the proxy mode.
Expected Result:
The STATUS Command should be issued to the server, which will act
as proxy and forward the request to the specified target node.
Test Steps:
- Start two servers.
- Issue STATUS Command to one of them specifying the other as target.
- Check that the command is successfully handled on the given target
node.
Remarks:
The check to see if the command is actually executed on the specified
target node is not yet fully implemented.
Test Case: test_StatusCmd_3
Description:
Synopsis:
Issue STATUS Command/file_id.
Description:
Test that the C-Client/API can handle STATUS Command with -fileId.
Expected Result:
The command should be properly sent to the server, which should
query the info about the file and send this back where it is
handled appropriately.
Test Steps:
- Start two servers.
- Archive file into one server.
- Submit STATUS + File ID to the other server.
- Verify that the requested info is returned.
Remarks:
...
Test Case: test_StatusCmd_4
Description:
Synopsis:
Issue STATUS Command/file_id,file_version.
Description:
Same as test_StatusCmd_3 but also File Version is specified.
Expected Result:
The request info for the specified file should be returned.
Test Steps:
See test_StatusCmd_3.
Remarks:
...
Test Case: test_StatusCmd_5
Description:
Synopsis:
Issue STATUS Command/disk_id.
Description:
Test that the C-Client/API can handle STATUS Command with -diskId.
Expected Result:
The STATUS Command requesting for info about a specified disk,
should be properly transferred via the C-Client/API and executed
on the server.
Test Steps:
- Start server.
- Issue STATUS Command requesting for info about a certain disk.
- Compare the returned XML disk info with a reference file.
Remarks:
...
Test Suite: ngamsCheckFileCmdTest
Description:
Synopsis:
CHECKFILE Command.
Description:
This Test Suites exercises the CHECKFILE Command. It verifies the
nominal behavior and the behavior under abnormal conditions.
Missing Test Cases:
- Check proxy mode + CHECKFILE Command (i.e., file stored on another
node than the contacted one).
- Various combinations of disk_id/file_id/file_version (legal/illegal).
Test Case: test_ErrHandling_1
Description:
Synopsis:
Check error handling in connection with CHECKFILE Command.
Description:
The purpose of the Test Case is to check the correct behavior/handling
of the NG/AMS Server when it comes to handle the following cases:
- Disk not existing.
- File not existing.
- File Version not existing.
Expected Result:
The NG/AMS Server should detect the invalid parameters and should
return a proper error code.
Test Steps:
- Start normal NG/AMS Server.
- Archive file.
- Issue CHECKFILE Command with a non-existing Disk ID + check that
a proper error response is returned.
- Issue CHECKFILE Command with a non-existing File ID + check that
a proper error response is returned.
- Issue CHECKFILE Command with a non-existing File Version + check
that a proper error response is returned.
Remarks:
...
Test Case: test_NormalExec_1
Description:
Synopsis:
Normal execution of CHECKFILE Command.
Description:
The purpose of this Text Case is to test the normal/standard
execution of the CHECKFILE Command.
Expected Result:
The CHECKFILE Command should be accepted and executed successfully
by the server on an existing file.
Test Steps:
- Start NG/AMS Server.
- Archive a file successfully.
- Check the file specifying Disk ID/File Id/File Version.
- Check the the result returned by the NG/AMS Server is as expected.
Remarks:
...
Test Suite: ngamsCloneCmdTest
Description:
Synopsis:
Test Suite testing the CLONE Command.
Description:
...
Missing Test Cases:
- check disk switch.
- Clone Reporting/failed/successfull clonings.
- Parallel handling of CLONE Commands.
- Clone specifying:
- Illegal file_id.
- Illegal file_id/file_version.
- Illegal file_id/file_version/disk_id.
- Illegal disk_id.
- Illegal target_disk_id.
- target_disk_id is Replication Disk.
- Disk ID of src disk = target_disk_id.
- Disk ID, via File ID of src disk = target_disk_id.
- Failed cloning, no free disks.
- Check that cloning recovers from broken DB connection.
- Check that cloning recovers from empty SQL query results.
- If a file is cloned twice, it ends up on two Main Disks.
- Estimation of required disk space is correct.
- Rejection of CLONE Command when the required disk space is not enough.
Test Case: test_CloneCmd_1
Description:
Synopsis:
Normal execution of CLONE Command/clone one file/wait=0.
Description:
Test normal execution of the CLONE Command whereby wait=0.
Expected Result:
An immediate response should be returned indicating that the
CLONE Command has been accepted for execution. The Clone Status
Report should be send out indicating that the file was cloned.
Test Steps:
- Start 1 NG/AMS Server.
- Archive file 2 times.
- Clone one file specifying disk_id, file_id and file_version + wait=0.
- Check that the immediate response is correctly returned.
- Wait for the execution of the CLONE Command to finish.
- Check that the Request Info in the NG/AMS Server indicates that the
Clone Request finished.
- Check that the cloned file has arrived on the Target Disk.
- Check that the DB info has been updated as it should.
Remarks:
IMPL: Re-implement using _execCloneTest().
Test Case: test_CloneCmd_2
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id (wait=0).
Description:
Clone an entire disk and check that the Clone Request was successfully
handled.
Expected Result:
The 10 files on the disk specified to be cloned should be cloned
onto the selected Target Disk.
Test Steps:
- Start normal NG/AMS Server.
- Archive small FITS file 10 times.
- Flush email queue.
- Issue Clone Request.
- Wait for Clone Request to terminate.
- Check that the Clone Status Report indicates that the files were
cloned as expected.
Remarks:
IMPL: Re-implement using _execCloneTest().
Test Case: test_ErrExec_1
Description:
Synopsis:
Error executing CLONE Command: file_id + file_version +
target_disk_id => 2 files -> but only 1 disk.
Description:
The purpose of the test is to exercise the case where there is
insufficient space to carry out a Clone Request since the cloning
requires two Disk Sets.
Expected Result:
The contacted NG/AMS Server should detect the problem as should
reject the CLONE Command with an appropriate error message.
Test Steps:
- Start two servers (simulated cluster).
- Archive 5 files onto sub-node (NMU).
- Clone a given file specifying Target Disk on NMU.
- Check that the Clone Command is rejected.
Remarks:
IMPL: Verify that this Test Case is correct.
Test Case: test_NormalExec_1
Description:
Synopsis:
Normal execution of CLONE Command specifying file_id.
Description:
The Test Case exercises the Clone Command whereby a successfull
Clone Request is executed, specifying the file_id of a file to clone.
The cloning takes place within the scope of one NG/AMS Server
(simulating one node).
Expected Result:
The file should be cloned onto a Main Disk, which does not already
host that file.
Test Steps:
- Start instance of NG/AMS Server.
- Archive a file 5 times.
- Flush the email queue for the test user.
- Clone it via its File ID, specify the test user as recepient of
the Clone Status Report.
- Check that the response returned is as expected.
- Check that a proper Clone Status Report was sent out as a
Notification Email.
Remarks:
...
Test Case: test_NormalExec_10
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id, file_id,
file_version and target_disk_id (Proxy Mode cloning).
Description:
Expected Result:
Same as test_NormalExec_7 but specifying also file_id, file_version
and target_disk_id.
Test Steps:
Same as test_NormalExec_7 cloning only one file.
Remarks:
Should also check that cloned file has arrived on the Target Disk
and is registered in the NGAS DB.
Test Case: test_NormalExec_2
Description:
Synopsis:
Normal execution of CLONE Command specifying file_id/file_version.
Description:
Check normal execution of the Clone Command specifying file_id and
file_version.
Expected Result:
The selected file should be cloned onto a Main Disk not already
hosting that file.
Test Steps:
Same as test_NormalExec_1 with the exception that file_version is
also given.
Remarks:
...
Test Case: test_NormalExec_3
Description:
Synopsis:
Normal execution of CLONE Command, specifying disk_id, file_id and
file_version.
Description:
Check normal execution of the Clone Command specifying disk_id,
file_id and file_version.
Expected Result:
Same as test_NormalExec_1.
Test Steps:
Same as test_NormalExec_1 with the exception that disk_id and
file_version also are given.
Remarks:
...
Test Case: test_NormalExec_4
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id.
Description:
The Test Case tests the CLONE Command when specifying a valid
disk_id of a disk to be cloned.
Expected Result:
Same as test_NormalExec_1.
Test Steps:
Same as test_NormalExec_1 but specifying disk_id.
Remarks:
...
Test Case: test_NormalExec_5
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id, file_id,
file_version and target_disk_id.
Description:
Exercise a normal execution of the CLONE Command speciyfing a valid
combination of disk_id, file_id, file_version and target_disk_id.
Expected Result:
Same as test_NormalExec_1 but the file should end up on the specified
Target Disk.
Test Steps:
Same as test_NormalExec_1 but specifying a valid combination of
disk_id, file_id, file_version and target_disk_id.
Remarks:
...
Test Case: test_NormalExec_6
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id and
target_disk_id.
Description:
Test Case to exercise proper handling of the CLONE Command when
specifying a valid combination of disk_id and target_disk_id.
Expected Result:
The contents of the specified Source Disk should be cloned onto the
specified Target Disk.
Test Steps:
Same as test_NormalExec_1 but specifying a disk_id and target_disk_id.
Remarks:
...
Test Case: test_NormalExec_7
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id whereby Source
Disk not in Target Node (Proxy Mode cloning).
Description:
The purpose of the Test Case is to check the proper execution of the
CLONE Command when th contacted node has to clone a disk registered
within the context of another NG/AMS Server (Proxy Mode).
Expected Result:
The files contained on the specified disk located in another NGAS
Node, should be cloned onto a disk in the contacted node and stored
on a Main Disk not already containing the files.
Test Steps:
- Start two instances of the NG/AMS Server on the test node.
- Archive a file 5 times onto one of the NGAS Systems.
- Flush email queue no the node.
- Clone the disk onto the other NGAS System, by specifying the
disk hosting the files in the other NGAS System (wait=1).
- Check that the response from the NG/AMS Server is as expected.
- Check that the Clone Status Report (sent via Email Notification)
is as expected.
Remarks:
Should also check that the files have been cloned (check copies on
Target Disk + info in NGAS DB).
Test Case: test_NormalExec_8
Description:
Synopsis:
Normal execution of CLONE Command specifying file_id and file_version
(Proxy Mode cloning).
Description:
Same as test_NormalExec_7 but where file_id and file_version are
specified.
Expected Result:
The given file should be cloned onto the Target NGAS System.
Test Steps:
Same as test_NormalExec_7 but where file_id/file_version are specified
rather than disk_id.
Remarks:
Should test that the file has arrived on the Target Disk and that the
info is properly updated in the DB.
Test Case: test_NormalExec_9
Description:
Synopsis:
Normal execution of CLONE Command specifying disk_id, file_id and
file_version (Proxy Mode cloning).
Description:
Same as test_NormalExec_7 but specifying also file_id and file_version.
Expected Result:
Same as test_NormalExec_7 cloning only one file.
Test Steps:
Same as test_NormalExec_7.
Remarks:
Should also check that cloned file has arrived on the Target Disk
and is registered in the NGAS DB.
Test Suite: ngamsConfigCmdTest
Description:
Synopsis:
Test Suite testing the CONFIG Command.
Description:
The purpose of this Test Suite is to test the handling of the CONFIG
Command in the NG/AMS Server.
Missing Test Cases:
- Test proxy mode for CONFIG Command.
- Many Test Cases are missing. A review of the Test Suite and of the
CONFIG Command should be carried out and the necessary Test Cases added.
Test Case: test_ChangeLocLogLev_1
Description:
Synopsis:
Change the Local (Log File) Log Level Online.
Description:
The purpose of this Test Case is to test that the Local Log Level
can be changed while the NG/AMS Server is Online.
Expected Result:
The Log Level should be increased and more logs produced in the Local
Log File.
Test Steps:
- Start normal NG/AMS Server (Log Level=3).
- Send a CONFIG Command to the server changing the Log Level to 4.
- Check the response to the CONFIG Command is correct.
Remarks:
IMPL: Check in Log File that low level logs are produced.
Test Suite: ngamsConfigHandlingTest
Description:
Synopsis:
Handling of the configuration file.
Description:
The purpose of this Test Suite is to test the handling of the NG/AMS
Configuration. The test focuse on the handling of the configuration in the
NGAS DB and the loading into and loading from of this.
Missing Test Cases:
- Should make more tests to check if the server reacts correctly on
different parameter values.
- Should be analyzed and more Test Cases added to cover better this
feature.
Test Case: test_Load_1
Description:
Synopsis:
Test Purpose: Load configuration into DB.
Description:
The purpose of this Test Case is to test that the NG/AMS Configuration
can be loaded properly from an XML configuration document into the
NGAS DB.
Expected Result:
The XML based NG/AMS Configuration should be loaded into the NGAS DB.
Test Steps:
- Load configuration into instance of ngamsConfig and write it to
the NGAS DB.
- Load the previously loaded configuration from the DB into an object
and dump this into an NG/AMS XML Configuration.
- Verify that the contents is as expected after loading into the DB
and dumping from the DB into an ASCII format in the NGAS XML
Dictionary format.
Remarks:
...
Test Case: test_ServerLoad_1
Description:
Synopsis:
Test that the NG/AMS Server is loading configuration from DB and
initializing as expected.
Description:
Test that the NG/AMS Server can load the configuration properly from
the DB and initialize accordingly.
Expected Result:
The server should load the DB parameters according the specified
NGAS Configuration ID specified and should start up properly.
Test Steps:
- Load the configuration into the DB.
- Start an NG/AMS Server specifying an XML document which only
defines the DB connection + giving the reference to the DB Cfg. ID.
- Verify that the NG/AMS Server starts up properly.
Remarks:
...
Test Case: test_ServerLoad_2
Description:
Synopsis:
Test that the NG/AMS Server is loading configuration from DB and
initializing as expected.
Description:
The purpose of this Test Case is to verify that the NG/AMS Server
can be initialized properly by loading the configuration from the
NGAS DB. The parameter disabling handling of Archive Requests is
set to 0. It is checked that the server after initialization,
rejects Archive Requests.
Expected Result:
The NG/AMS Server should initialize and select disabling of handling
of Archive Requests. Submitting Archive Requests to the server
should result in a rejection of the request.
Test Steps:
- Create an NG/AMS XML Configuration where handling of Archive Requests
is disabled.
- Load this into the DB.
- Start instance of the NG/AMS Server specifying to use the previously
loaded configuration.
- Issue an Archive Request and verify that it is rejected.
Remarks:
...
Test Case: test_ServerLoad_3
Description:
Synopsis:
Test loading of specific configuration from DB.
Description:
Test that the NG/AMS Server is loading configuration from DB and
initializing as expected without mixing up parameters from other
configurations in the DB.
Expected Result:
The NG/AMS Server should load only parameters for the specified
configuration Group ID and ignore other parameters in the DB.
Test Steps:
- Prepare two XML configurations and load them in the DB. Difference
is that all attribute values of the second are set to value=0, which
means that the server could not operate if mixing up parameters from
the two.
- Start server.
- Archive file and check that the file was successfully archived.
Remarks:
...
Test Suite: ngamsDataCheckingThreadTest
Description:
Synopsis:
Data Consistency Checking Thread.
Description:
This Test Suite exercises the Data Consistency Checking facility.
It is verified that the various checks are properly functioning, and that
the DCC Thread is robust towards various errors that might occur.
Missing Test Cases:
This Test Suite is very basic. A thorough review should be done and the
missing Test Cases added.
In particular Test Cases for detecting the various points checked should
be added.
Test Case: test_DataCheckThread_1
Description:
Synopsis:
Basic functioning of Data Checking Feature.
Description:
Test Test the basic functioning of the Data Check Thread. The
Data Check Thread is started and it is checked that it performs
a cycle whereby all files are checked, and a Data Check Entry is
logged into the NG/AMS Local Log File.
Expected Result:
After a given period of time, the DCC Thread should have completed
one check cycle and have detected possible problems. In this case
there are no inconsistencies found.
Test Steps:
- Start standard NG/AMS Server configured to carry out DCC
continuesly.
- Archive a small file 3 times.
- Wait until the DCC has finished one cycle (NGAMS_INFO_DATA_CHK_STAT
log written in the log file).
- Check that the report is OK/that all files were checked.
Remarks:
...
Test Suite: ngamsDbSnapShotTest
Description:
Synopsis:
Test DB Snapshot Feature.
Description:
The purpose of the Test Suite is to test the DB Snapshot Feature, which
purpose it is to synchronize the various, remotely located NGAS DBs.
In particular the following Use Cases are considered:
=========================================================================
| DB | Snapshot | Disk | Reaction |
-------------------------------------------------------------------------
| + | + | + | No changes. |
-------------------------------------------------------------------------
| + | - | + | Snapshot updated. |
-------------------------------------------------------------------------
| + | + | - | 'Lost File' - Email Notification. |
-------------------------------------------------------------------------
| - | + | + | DB updated according to DB Snapshot. |
-------------------------------------------------------------------------
| - | - | + | TBI. |
-------------------------------------------------------------------------
| - | - | - | Irrelevant. |
=========================================================================
Missing Test Cases:
Should be reviewed carefully and the possibly, missing Test Cases added.
- Creation of DB Snapshot at server start-up, files on the disk.
Test Case: test_DbSnapshot_1
Description:
Synopsis:
Creation of DB Snapshot at server start-up.
Description:
Test that DB Snapshot is created when a disk is initialized. This both
for an empty DB and a DB with files registered where files are located
on the disk.
Expected Result:
When the server goes Online and the Janitor Thread is launched the
first time, it should detect that there is no DB Snapshot on the
disk and therefore created it. In this case it will be empty as
there are no files on the disk.
Test Steps:
- Prepare an instance of the NG/AMS Server and wait till the
Janitor Thread has executed once.
- Check that the DB Snapshot file for the disk in Slot 1 has been
created.
Remarks:
...
Test Case: test_DbSnapshot_2
Description:
Synopsis:
Test that DB Snapshot is updated when files are archived.
Description:
The purpose of this test is to verify that the DB Snapshot is updated
'real-time' when files are archived onto a disk.
Expected Result:
After having archived 3 files, the Janitor Thread should be
triggered to update the DB Snapshot.
Test Steps:
- Prepare instance of NG/AMS Server.
- Archive a small FITS file 3 times.
- Wait till the Temporary File Snapshots have been handled by
the Janitor Thread.
- Check that the DB Snapshot has been updated accordingly.
Remarks:
...
Test Case: test_DbSnapshot_3
Description:
Synopsis:
Test that DB Snapshot is updated correctly when files are removed.
Description:
The purpose of this test is to verify that the DB Snapshot is updated
'real-time' when files are removed from a disk.
Expected Result:
After having executed the REMDFILE command on one of the files stored
on the disk, the DB Snapshot should be updated by the Janitor Thread.
Test Steps:
- Prepare instance of NG/AMS Server.
- Archive a small FITS file 3 times.
- Issue a REMFILE Command to remove one of the files.
- Wait till the Temporary File Snapshots have been handled by
the Janitor Thread.
- Check that the DB Snapshot has been updated accordingly.
Remarks:
...
Test Case: test_DbSnapshot_4
Description:
Synopsis:
DB Snapshot is updated correctly when a disk is removed (REMDISK'ed).
Description:
The purpose of this test is to verify that the DB Snapshot of a disk
is correctly updated when the files contained and registered on the
disks are removed via a REMDISK Command.
Expected Result:
A while after executing the REMDISK Command, the corresponding entries
should disappear from the DB Snapshot of the REMDISK'ed disk.
Test Steps:
- Start a server.
- Archive a small FITS file 3 times.
- Clone the disk.
- Remove the resulting, cloned disk.
- Check that within a short time-out, all entries from the DB
Snapshot disappears.
Remarks:
...
Test Case: test_DbSnapshot_5
Description:
Synopsis:
Test that DB Snapshot is updated correctly when files are cloned.
Description:
The purpose of the test is to verify that the DB Snapshot on a disk,
is updated (on-the-fly) when files are being cloned onto it.
Expected Result:
A short time after the files have been cloned onto a given disk,
the information about the files should appear in the DB Snapshot
of the disk.
Test Steps:
- Start server.
- Archive a small test FITS file 3 times.
- Clone the Main Disk hosting the 3 files archived.
- Check that the DB Snapshot of the Target Disk has been updated with
the information about the files cloned.
Remarks:
...
Test Case: test_DbSnapshot_6
Description:
Synopsis:
Test that DB Snapshot is updated correctly when file are registered.
Description:
The purpose of the test is to verify that the DB Snapshot of a disk
on which files are being registered, is properly updated according
to the files registered.
Expected Result:
After a short while, the information for the files registered should
appear in the DB Snapshot of the disk.
Test Steps:
- Start server.
- Copy over a small test FITS file in 3 copies.
- Send a REGISTER Command to register the files copied over
(specifying root directory of the files).
- Check that the DB Snapshot is updated within a given period of time.
Remarks:
...
Test Case: test_DbSnapshot_7
Description:
Synopsis:
Test that DB is updated correctly according to DB Snapshot.
Description:
The purpose of the test is to verify that the DB is updated according
to the information in the DB Snapshot. This goes both for adding
missing entries and removing entries no longer stored on the disk and
registered in the DB Snapshot.
Expected Result:
After bringing the NG/AMS Server Online, the Janitor Thread should
update the DB according to the DB Snapshot.
Test Steps:
- Start an NG/AMS Server.
- Archive a file 3 times.
- Bring the server Offline.
- Delete the info for the previously archived from the NGAS DB.
- Bring the server Online.
- Verify that the entries in the DB Snapshot now appear in the
NAGS DB.
Remarks:
IMPL!: Last step of verifying that the file info is actually updated
in the DB, is not yet implemented.
Test Case: test_DbSnapshot_8
Description:
Synopsis:
Test that lost files are properly detected and reported.
Description:
The purpose of the test is to verify that files registered in the
NGAS DB and in the DB Snapshot, but not available on the disk, are
registered as 'Lost Files'.
Expected Result:
After going Online the Janitor Thread should detect that there are
files that are not found on the disk as expected. An Email Notification
Message should be sent to the subscribers of Data Error Messages
informing about this.
Test Steps:
- Start NG/AMS Server specifying the test user as receiver of
Data Error Notification Messages.
- Archive a small FITS test file 5 times.
- Bring the server Offline.
- Remove 3 of the archived files.
- Bring server Online.
- Check that after a while an Email Notification Message is sent out
to indicate the problem encountered.
Remarks:
IMPL!: Not yet implemented!
Test Case: test_DbSnapshot_9
Description:
Synopsis:
Test if file on disk, DB and DB Snapshot up to date,
that the are no changes.
Description:
The purpose of the test is to verify that if the NGAS DB, the DB
Snapshot and content of disk is found to be identical, no changes
are made to the DB Snapshot/NGAS DB.
Expected Result:
...
Test Steps:
- ...
Remarks:
IMPL!: Not yet implemented!
Test Suite: ngamsDiscardCmdTest
Description:
Synopsis:
Test the DISCARD Command.
Description:
The purpose of the Test Suite is to test the DISCARD Command.
Missing Test Cases:
IMPL: Should be reviewed and missing Test Cases added. In particular the
abnormal functioning and misusage should be better tested.
- IMPL!: Try to DISCARD file/path stored on another node.
- IMPL!: Try to remove read-only file.
- IMPL!: Remove file available in 3 copies (execute=0,1/FileID/Path).
- IMPL!: Issue command specifying no parameters.
- IMPL!: File specified with path, file registered in NGAS DB
(execute=0/1).
Test Case: test_IllegalPars_1
Description:
Synopsis:
Missing parameters 1) Disk ID, 2) File ID, 3) File Version missing.
Description:
The purpose of the test is to verify the error handling when an
illegal combination of parameters is submitted to the NG/AMS Server
with the DISCARD Command.
It is only allowed to execute the DISCARD Command referring to
Disk ID/File ID/File Version if all three parameters are specified.
Expected Result:
When submitting the DISCARD Command with either of the 3 parameters
missing, the command should be rejected and an Error Response returned
indicating the problem.
Test Steps:
- Start NG/AMS Server.
- Submit DISCARD Command with File ID/File Version.
- Check that the request is rejected, indicating that the Disk ID is
missing.
- Submit DISCARD Command with Disk ID/File Version.
- Check that the request is rejected, indicating that the File ID
is missing.
- Submit DISCARD Command with Disk ID/File ID.
- Check that the request is rejected, indicating that the File Version
is missing.
Remarks:
...
Test Case: test_NonExistingFile_1
Description:
Synopsis:
File not existing +/-execute/Disk ID/File ID/ File Version.
Description:
The purpose of the test is to verify the behavior of the DISCARD
Command, when it is tried to DISCARD a file, which is not available
on the contacted NGAS Node. This is both tried for execute=0 and
execute=1.
The file is referred to by its File ID.
Expected Result:
The NG/AMS Server should detect that the specified file is not
found on the contacted NGAS Node and should generate an error message
indicating this.
Test Steps:
- Start NG/AMS Server.
- Submit DISCARD Command, specifying a non-existing file/execute=0.
- Check that the error message from the NG/AMS Server is as expected.
- Submit DISCARD Command, specifying a non-existing file/execute=1.
- Check that the error message from the NG/AMS Server is as expected.
Remarks:
...
Test Case: test_NonExistingFile_2
Description:
Synopsis:
File not existing referred to by path, +/- execute.
Description:
The purpose of the test is to verify the behavior of the DISCARD
Command when it is tried to DISCARD a file referred to by it path
name.
Expected Result:
The NG/AMS Server should detect that the file referred to by a path
name is not available on the contacted NGAS Node and should send back
an Error Response. This goes both when execute=0 and execute=1.
Test Steps:
- Start NG/AMS Server.
- Submit a DISCARD Command, specifying a non-existing file path
(execute=0).
- Check that the command is rejected by NG/AMS.
- Submit a DISCARD Command, specifying a non-existing file path
(execute=0).
- Check that the command is rejected by NG/AMS.
Remarks:
...
Test Case: test_NormalExec_1
Description:
Synopsis:
File existing execute=0,1/Disk ID/File ID/File Version.
Description:
The purpose of the test is to verify that the normal functioning
of the DISCARD Command when it is tried to DISCARD a file referred to
by its corresponding Disk ID, File ID and File Version.
Expected Result:
The server should find the file, and should return a positive response
when issuing the DISCARD Command with execute=0. Subsequently, when
submitting the command with execute=1, the file should disappear
from the NGAS DB and from the disk.
Test Steps:
- Start NG/AMS Server.
- Archive a file.
- Issue a DISCARD Command specifying the Disk ID/File ID/File Version
of the file/execute=0.
- Check that the response from the NG/AMS Server reports that only
one copy is available of the file.
- Issue a DISCARD Command specifying the Disk ID/File ID/File Version
of the file/execute=1.
- Check that the response from the NG/AMS Server reports that the file
was DISCARDED.
Remarks:
...
Test Case: test_NormalExec_2
Description:
Synopsis:
File existing, remove via path, +/-execute.
Description:
The purpose of the test is to verify the normal functioning of the
DISCARD Command when DISCARD'ing files referred to by their path.
It is tried both to execute the command with execute=0 and execute=1.
The file is not registered in the NGAS DB.
This simulates the situation where spurious files are removed from the
NGAS system only referred to by their path.
Expected Result:
When the DISCARD Command is issued, execute=0, the NG/AMS Server should
find the file and return a response indicating that the file is only
available in 1 copy. When submitting the DISCARD Command with
execute=1, the file should disappear from the disk.
Test Steps:
- Start NG/AMS Server.
- Copy a test file onto a disk of the NGAS System.
- Issue a DISCARD Command specifying the copied file (execute=0).
- Check that the response indicates that the DISCARD Request is
granted.
- Reissue the DISCARD Command specifying the copied file (execute=1).
- Check that the response indicates that the file has been removed.
- Check that the file has disappeared from the disk.
Remarks:
IMPL!: Implement check to verify that file has been removed from the
disk.
Test Case: test_ProxyExec_1
Description:
Synopsis:
File existing (disk_id/file_id/file_version)/Proxy Mode.
Description:
The purpose of the test is to verify the proper handling of the
DISCARD Command when the file specified to the DISCARDed is located
on another NGAS Node, such that the contacted NGAS Node acts as proxy.
The DISCARD Command should be forwarded to the appropriate node and
executed accordingly.
It is tried both with execute=0 and execute=1. The file is referred
to by its Disk ID/File Id/File Version.
Expected Result:
When the DISCARD Command is submitted, the contacted NG/AMS Server
should figure out that the file is stored on another NGAS Node, and
should forward the request to the node, which hosts the file.
When issuing the command with execute=0 the response from the
sub-node should indicate that the file can be DISCARDED. When executing
with execute=1, the file should disappear from the NGAS DB and from the
disk on the sub-node.
Test Steps:
- Prepare simulated cluster with two nodes.
- Archive file onto one of the nodes.
- Issue a DISCARD Command, specifying the file archived to the node
not hosting the file archived.
- Verify that the command is forwarded to the node hosting the file
and executed there (request granted).
- Submit the DISCARD Command with execute=1 to the node not hosting
the file archived, and verify that it is forwarded and executed on
the node hosting the file.
- Verify that the file info for the file is no longer in the DB and
on the disk.
Remarks:
IMPL!: Verify that the file info in DB + file on disk are removed
on the sub-node.
TBD: Proxy Mode should only be valid if enabled in the NG/AMS Cfg.
Test Case: test_ProxyExec_2
Description:
Synopsis:
File existing (path), file on another host +/-execute,
explicit proxy-mode (Host ID given for sub-node).
Description:
The purpose of the test is to verify that a DISCARD Command is
forwarded to a sub-node, if a file to be DISCARDED is referred to by
its path and the Host ID hosting the file is given.
It is tested both with execte=0 and execute=1.
Expected Result:
When submitting the DISCARD Command with execute=0 the contacted
node should forward the request to the specified sub-node where the
request is checked and a positive response (granting to DISCARD the
file) is returned to the client.
Afterwards, when re-submitting the command with execute=1, the file
should disappear from the NGAS DB and from the disk of the sub-node.
Test Steps:
- Prepare simulated cluster with two node.
- Copy file onto a disk of the simulated sub-node.
- Issue DISCARD Command to simulated Master Node.
- Check the the request is forwarded to the sub-node and executed
successfully there (execute=0).
- Check the the request is forwarded to the sub-node and executed
successfully there (execute=1).
- Check that the file has been removed from the disk.
Remarks:
IMPL!: Check that the file has actually been removed.
TBD: Proxy Mode should only be applied if so configured.
Test Case: test_ProxyExec_3
Description:
Synopsis:
File not existing (path), file on another host +/-execute,
explicit proxy-mode (Host ID given for sub-node).
Description:
The purpose of the test is to verify that if a file is specified
by its path, giving a sub-node reference and where the file does
not exist, the DISCARD Command is rejected and an appropriate
error response generated on the sub-node and send back to the
client via the contacted node acting as proxy.
Expected Result:
When submitting the DISCARD Command specifying the path of a file
and the target node, the contacted node should act as proxy and
should forward the request to the specified target node. NG/AMS on
this node, should check that the file can be removed, and should
send back an error response, indicating that the file cannot be
discarded because it is not available.
The same should happen when re-issuing the DISCARD Command with
execute=1.
Test Steps:
- Start simulated cluster with two units.
- Submit a DISCARD Command specifying the sub-node and a file path
not existing on the target node/execure=0.
- Check that the error response contains a message indicating that
the file cannot be removed.
- Submit a DISCARD Command specifying the sub-node and a file path
not existing on the target node/execure=1.
- Check that the error response contains a message indicating that
the file cannot be removed.
Remarks:
...
Test Suite: ngamsEmailNotificationTest
Description:
Synopsis:
Test Suite for the Email Notification Feature.
Description:
The purpose of this Test Suite is to exercise the Email Notification
Service. It should be found out if all cases where Email Notification
Messages can be send out, are working properly.
Also the control flags in the configuration should be tested.
In particular it should also be verified that the Email Retention Service
works.
Missing Test Cases:
IMPL!: Review all Test Cases in other Test Suite exercizing the Email
Notification Service, and add the missing ones.
IMPL!: Test Email Notification Retention (max. number of emails for
emitting obtained, time-out for emitting obtained).
Test Case: test_1
Description:
Synopsis:
...
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
...
Test Suite: ngamsExitCmdTest
Description:
Synopsis:
Test Suite for the EXIT Command.
Description:
The purpose of this Test Suite is to exercise the EXIT Command.
Both the normal case where exit is granted should be tested, as well
as when exit is not allowed (if the server is in Online State).
Missing Test Cases:
...
Test Case: test_ExitCmd_1
Description:
Synopsis:
Normal execution EXIT Command/Offline.
Description:
Test that the server terminates if the EXIT Command is submitted
while the server is in Offline State.
Expected Result:
The server in Offline State, should accept the EXIT Command and
perform a clean shut down.
Test Steps:
- Start server (Auto Online = 0).
- Submit EXIT Command.
- Check that the response is as expected.
- Check that the server is no longer running.
Remarks:
IMPL!: Test that the server is no longer running.
Test Case: test_ExitCmd_2
Description:
Synopsis:
Server in Online State -> EXIT Command rejected.
Description:
Test that the EXIT Command is rejected when submitted when the
server is in Online State.
Expected Result:
The server should generate an Error Response indicating that the
command cannot be handled when the server is in Online State.
Test Steps:
- Start server (Auto Online = 1).
- Issue EXIT Command.
- Check that the request is rejected.
- Check that the server is still running.
Remarks:
IMPL!: Check that the server is still running after the EXIT Command.
Test Suite: ngamsHelpCmdTest
Description:
Synopsis:
Test Suite of the HELP Command.
Description:
The purpose of the Test Suite is to exercise the HELP Command.
Missing Test Cases:
NOTE: The HELP Command is not yet implemented. When implemented this
Test Suite should be reviewed and the missing Test Cases added.
Test Case: test_NoPars_1
Description:
Synopsis:
Issue HELP Command with no parameters/Offline State.
Description:
Check that the response to the HELP Command is as expected (taking
into account that the HELP Command is not yet implemented).
Expected Result:
The server should send back an Error Response indicating that the
HELP Command is not yet implemented.
Test Steps:
- Start server.
- Issue HELP Command.
- Check that output is as expected (=command rejected).
Remarks:
This Test Case should be modified when the HELP Command has been
implemented.
Test Case: test_NoPars_2
Description:
Synopsis:
Issue HELP Command with no parameters/Online State.
Description:
Check that the response to the HELP Command is as expected (taking
into account that the HELP Command is not yet implemented).
Expected Result:
The server should send back an Error Response indicating that the
HELP Command is not yet implemented.
Test Steps:
- Start server.
- Issue HELP Command.
- Check that output is as expected (command rejected).
Remarks:
This Test Case should be modified when the HELP Command has been
implemented.
Test Suite: ngamsIdleSuspensionTest
Description:
Synopsis:
Test Suite for the Idle Suspension Feature.
Description:
The purpose of the Test Suite is to test the Idle Suspension/Wake-Up
Feature. As it is not possible to suspend the test node, a special
Suspension and Wake-Up Plug-in have been provided which simulate that
the server is suspended without actually suspending it.
Missing Test Cases:
- IMPL!: CLONE (from suspended sub-node).
- IMPL!: Check that node is not suspending itself when:
- DCC is on-going.
- Request is being handled.
- Subscription data being delivered
- IMPL!: Check that a node suspends itself if configured so, within
the specified period of time.
- IMPL!: Check that sub-nodes are woken up at:
- CONFIG?&host_id
- STATUS: Check if more relevant cases.
(All tests with HTTP Authentication).
- IMPL: RETRIEVE?disk_id&file_id&file_version.
- IMPL: CHECKDISK (file on suspended sub-node).
- IMPL: Check that node is not suspending itself when subscription data
being delivered
Test Case: test_SuspendNode_1
Description:
Synopsis:
Test that a node suspends itself within the specified period of time.
Description:
The purpose of the test is to verify that the NG/AMS Server suspends
itself when Idle Suspension is enabled within the specified period
of time.
Expected Result:
After starting the server, it should suspend itself after the given
period of time.
Test Steps:
- Start server with a configuration file specifying idle suspension
after 10s.
- Wait till the server indicates in the DB that it is suspended
with a time-out of 20s.
- Afterwards, mark the suspended node to unsuspended to be able to
shut down cleanly.
Remarks:
...
Test Case: test_WakeUpCheckfile_1
Description:
Synopsis:
Check that CHECKFILE?file_id&file_version correctly handled
when the referenced file is stored on a suspended node.
Description:
The purpose of the test is to verify that a CHECKFILE Command is
properly handled by a Master node acting as a proxy and interacting
with a suspended sub-node.
Expected Result:
The contacted Master Node should identify that the sub-node hosting
the specified file is suspended, and should wake it up before
forwarding the request. Subsequently it should forward the request to
the sub-node and send back the result to the client.
Test Steps:
- Start simulated cluster with a sub-node suspending itself after a
short while.
- Archive 2 FITS file 2 times each.
- Wait till the sub-node suspends itself.
- Send a CHECKFILE Command to the Master node specifying to check
one of the previously archived files.
- Check response from the sub-node.
- Check from the log entries in the Master Node that the CHECKFILE
Command has been successfully executed.
- Check from the log entries on the sub-node that the CHECKFILE
Command has been successfully executed.
Remarks:
...
Test Case: test_WakeUpDataCheck_1
Description:
Synopsis:
Check that a suspended sub-node is woken up when DCC is due and that
the DCC is executed as expected after the node has been woken up.
Description:
Before suspending itself, a sub-node should request to be woken up
when the time for executing the next DCC is due.
The purpose of the test is to verify that a sub-node suspending itself
requests to be woken up at the specified point in time, and that the
contacted Master Node wakes up a suspended sub-node as expected.
Expected Result:
The contacted Master Node should identify that the sub-node is
suspended and that it has requested to be woken up by the Master Node
at a given point in time. The Master Node should wake up the node at
the requested point in time and the sub-node should carry out the DCC.
Test Steps:
- Prepare simulated cluster with a sub-node suspending itself after a
short while and having DCC enabled with a high frequency.
- Archive two files onto the sub-node.
- Wait till the sub-node has suspended itself.
- Wait till the sub-node has been woken up.
- Check that entries in the log file on the Master Node indicate
that it has woken up the suspended sub-node.
- Check that entries in the log file on the sub-node indicate that it
has been woken up.
- Wait until the DCC has been executed and check that the result is
as expected (the DCC summary log appears in the log file on the
sub-node).
Remarks:
...
Test Case: test_WakeUpRetrieve_1
Description:
Synopsis:
Check that RETRIEVE?file_id and RETRIEVE?file_id&file_version are
correctly handled when the file specified is stored on suspended node.
Description:
The test verifies that a suspended sub-node is woken up when a
RETRIEVE Request is send to the Master Node and the file properly
retrieved and send back to the client via the Master Node acting
as proxy.
Expected Result:
The Master Node server should identify the target node as suspended
and should wake it up before requesting the data. Subsequently the
data should be send back to the client by the Master Node acting
as proxy.
Test Steps:
- Start simulated cluster with a sub-node suspending itself after
a short while.
- Archive a small FITS file 3 times onto the sub-node.
- Wait till the sub-node has suspended itself.
- Submit a REQUEST?file_id to the Master Node.
- Check that the response is as expected.
- Check that the file has arrived on disk.
Remarks:
IMPL!: Check that the file has arrived on disk as expected.
Test Case: test_WakeUpRetrieve_2
Description:
Synopsis:
Check that RETRIEVE?ng_log&host_id is correctly handled
when the file specified is stored on a suspended node.
Description:
The purpose of the test is to verify that a suspended sub-node is
woken up by a Master Node if a RETRIEVE?ng_log&host_id Request is
sent to the Master Node specifying the suspended sub-node as target
node.
Expected Result:
The Master Node should identify the target sub-node as suspended and
should wake it up before forwarding the Retrieve Request. Subsequently
the Master should send back the requested data to the client.
Test Steps:
- Start simulated cluster with a sub-node suspending itself after
a short while.
- Wait till the sub-node has suspended itself.
- Send a RETRIEVE?ng_log&host_id Command to the Master Node specifying
the sub-node as target.
- Check that the response returned from the suspended node via the
Master Node is as expected.
Remarks:
IMPL!: Check that the requested file has arrived on the destination.
Test Case: test_WakeUpRetrieve_3
Description:
Synopsis:
Check that RETRIEVE?cfg&host_id is correctly handled when the file
specified is stored on a suspended node.
Description:
Check that a suspended sub-node is woken up if the NG/AMS Configuration
used on that node is requested via a Master Node acting as proxy.
Expected Result:
The Master Node should identify the sub-node as suspended and should
wake up the suspended sub-node before forwarding the RETRIEVE Command.
Test Steps:
- Start simulated cluster with a sub-node suspending itself after a
short while.
- Wait till the sub-node has suspended itself.
- Send Retrieve Request requesting the configuration from the
suspended sub-node.
- Check that the cfg. file has been properly retrieved.
Remarks:
...
Test Case: test_WakeUpRetrieve_4
Description:
Synopsis:
Check that RETRIEVE?internal&host_id is correctly handled
when the file specified is stored on a suspended node.
Description:
Verify that an 'internal file' hosted on a suspended sub-node is
correctly retrieved by a Master Node acting as proxy.
Expected Result:
Teh contacted Master Node should identify that the requested target
node is suspended and should wake it up before forwarding the
request. Subsequently it should send back the requested file.
Test Steps:
- Start simluated cluster with a sub-node suspending itself after a
short while.
- Wait till the sub-node has suspended itself.
- Send the Retrieve Request requesting a file on the suspended
sub-node.
- Check that the file has been properly returned via the log file
on the Master Node.
- Check that the file has been properly retrieved via the log file
on the sub-node.
Remarks:
...
Test Case: test_WakeUpStatus_1
Description:
Synopsis:
Test that suspended server is woken up when
STATUS?host_id= specifying that node is sent.
Description:
If a STATUS Command is send to a node requesting status from another
node (Proxy Mode), and the target is suspended, the contacted node
must wake up the suspended target node. The purpose of this test
is to verify this use case.
Expected Result:
The contacted node should identify the target node as suspended,
and should wake it up prior to forwarding the STATUS Command acting
as proxy.
Test Steps:
- Start simulated cluster specifying that one node can suspend itself.
- Wait till sub-node has suspended itself.
- Send STATUS Command to suspended node to check that it is suspended.
- Send STATUS Command to the simulated master requesting status from
the suspended sub-node.
- Check the response to the STATUS Command.
- Cross check that the suspended node is now woken up by sending
a STATUS Command directly to the sub-node.
Remarks:
...
Test Case: test_WakeUpStatus_2
Description:
Synopsis:
Test that suspended server is woken up when STATUS?file_access is
issued, specifying a file on a suspended sub-node.
Description:
The purpose of the test is to verify that a suspended sub-node is
woken up by a master node acting as proxy if a STATUS?file_id is
send pointing to a file on the suspended sub-node.
Expected Result:
The suspended sub-node should be woken up by the master node which
after the suspended sub-node has come Online should forward the
request which is executed on the sub-node and the result send back to
the client through the master node.
Test Steps:
- Prepare simulated cluster with unit, which suspends itself.
- Archive 3 files onto sub-node.
- Wait till sub-node has suspended itself.
- Send a STATUS?file_id request to the Master Node specifying one
of the files previously archived.
- Check the result returned from the sub-node via the Master Node.
Remarks:
...
Test Suite: ngamsInitCmdTest
Description:
Synopsis:
Test Suite for the INIT Command.
Description:
The purpose of the Test Suite is to exercise the INIT Command.
Missing Test Cases:
IMPL: Missing Test Cases for abnormal conditions.
IMPL: Test normal case when loading cfg. from the DB.
Test Case: test_handleCmdInit_1
Description:
Synopsis:
Normal execution of INIT Command/cfg. in file.
Description:
The purpose of the Test Case is to verify that the server
re-initializes and reloads the associated cfg. file when the INIT
Command is received.
Expected Result:
When the INIT Command is received by a server in Online State, the
server should reload the configuration and go into Online State.
Test Steps:
- Start server.
- Issue an INIT Command.
- Check that response from the server is as expected.
Remarks:
IMPL: Should change some parameters to verify that the cfg. file is
actually re-loaded.
Test Suite: ngamsJanitorThreadTest
Description:
Synopsis:
Test Suite NG/AMS Janitor Thread.
Description:
The purpose of the Test Suite is to verify that the Janitor Thread
carries out all the tasks assigned to it as expected. This, both under
normal conditions and under abnormal conditions.
Missing Test Cases:
- IMPL!: Test detection of Lost Files.
- IMPL!: Also ticket DFS01880.
- IMPL!: Test all actions/tasks carried out by the Janitor Thread (not
handling of DB Snapshot - TBD).
Test Case: test_1
Description:
Synopsis:
...
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
...
Test Suite: ngamsLabelCmdTest
Description:
Synopsis:
Test Suite for the LABEL Command.
Description:
The purpose of the Test Suite is to exercise the LABEL Command in the
various ways this is used. This goes for:
- Printing of labels for a disk referred to by host_id/slot_id.
- Printing of labels for a disk referred to by its Disk ID.
- Renaming a disk referring to the disk by its Disk ID.
Both normal and abnormal conditions are exercised.
Missing Test Cases:
IMPL!: Test LABEL?disk_id.
IMPL!: Test re-label feature.
IMPL: Test illegal combinations of parameters.
IMPL: Review Test Suite and add relevant Test Cases.
Test Case: test_LabelCmd_1
Description:
Synopsis:
Test basic handling of the LABEL Command.
Description:
The purpose of the Test Case is to verify the normal execution of the
LABEL Command when specifying to print out a label for a disk referring
to theof the disk.
Expected Result:
The contacted server should find the information for the
Test Steps:
- Start server.
- Submit LABEL Command specifying the host_id/slot_id of the disk.
- Verify the response from the LABEL Command.
- Verify the printer file generated by the LABEL Printer Plug-in.
Remarks:
...
Test Suite: ngamsOfflineCmdTest
Description:
Synopsis:
Test Suite for the OFFLINE Command.
Description:
The purpose of the Test Suite is to exercise the OFFLINE Command.
Both normal case and abnormal cases should be tested. Latter includes:
- Sending OFFLINE when server is busy.
- Sending OFFLINE when server is busy and force specified.
Missing Test Cases:
IMPL: Should be reviewed and the missing Test Cases added.
Test Case: test_StdOffline_1
Description:
Synopsis:
test standard execution of OFFLINE Command.
Description:
The purpose of the Test Case is to specify the normal execution of the
OFFLINE Command when the server is Online/Idle and the command is
accepted as expected and the server brought to Offline State.
Expected Result:
The server in Online State should accept the OFFLINE Command and should
go Offline.
Test Steps:
- Start server (Auto Online=1).
- Submit OFFLINE Command.
- Check the response from the server.
Remarks:
IMPL: Check that the server is in Offline State.
Test Suite: ngamsOnlineCmdTest
Description:
Synopsis:
Test Suite for the ONLINE Command.
Description:
...
Missing Test Cases:
IMPL!: This whole Test Suite should be reviewed and the missing Test Cases
added.
IMPL!: Re-registration DB -> NgasDiskInfo (no NgasDiskInfo).
IMPL!: Re-registration DB -> NgasDiskInfo (DB info newer).
IMPL!: Re-registration NgasDiskInfo -> DB (no DB info).
IMPL!: Re-registration NgasDiskInfo -> DB (NgasDiskInfo info newer).
- Make dummy Online Plug-In, which returns no physical disks, and check
the SW behaves as expected (goes online, reports that there are no disks,
...).
- Check that if there are no Disk Sets available and Archiving is disabled,
no problems are reported.
- Following Test Cases +/- completed disks:
- M Slot: M Disk + R Slot: M Disk
- M Slot: R Disk + R Slot: R Disk
- R Slot: M Disk + R Slot: M Disk
- more combinations illegal/legal ones ...
Test Case: test_OnlineCmd_1
Description:
Synopsis:
Test basic handling of Online Command.
Description:
The purpose of the test is to verify that the server goes Online
initializing with the specified cfg. file when the ONLINE Command is
issued.
Expected Result:
After being started up and in Offline/Idle State and receiving the
ONLINE Command, the server should re-load the cfg. and should bring
the system to Online State according to the cfg. file.
Test Steps:
- Start server (Auto Online=0).
- Send ONLINE Command.
- Check that the response from the server is as expected.
Remarks:
IMPL: Check that the server is Online (DB + STATUS Command).
Test Suite: ngamsPClientTest
Description:
Synopsis:
Test Suite for NG/AMS Python Client.
Description:
The purpose of the Test Suite is to exercise the various features provided
by the NG/AMS Python Client.
Missing Test Cases:
IMPL: This whole Test Suite should be reviewed and the missing Test Cases
added/unnecessary Test Cases removed.
Test Case: test_Archive_1
Description:
Synopsis:
Send Archive Push Request via P-Client.
Description:
Check the handling of Archive Push Requests through the NG/AMS
P-Client. No mime-type is submitted with the request.
Expected Result:
The ngamsPClient should accept the command and submit the Archive
Push Request to the remote NG/AMS Server.
Test Steps:
- Start server.
- Issue Archive Push Request (no mime-type).
- Wait for handling to finish.
- Check reply from server.
Remarks:
It is not checked if the file has been properly cloned. The ARCHIVE
Command is tested in the Test Suite ngamsArchiveCmdTest.py.
Test Case: test_Archive_2
Description:
Synopsis:
Send Archive Pull Request via P-Client
Description:
The purpose of the test is to test the handling of Archive Push
Requests via the NG/AMS P-Client.
Expected Result:
The P-Client should submit the Archive Pull Request to the
server, which should archive the file successfully.
Test Steps:
- Start server.
- Launch Archive Pull Request via the NG/AMS P-Client.
- Check the response from the server.
Remarks:
It is not checked if the file has been properly cloned. The ARCHIVE
Command is tested in the Test Suite ngamsArchiveCmdTest.py.
Test Case: test_Clone_1
Description:
Synopsis:
Send CLONE Command via P-Client.
Description:
Check the handling of CLONE Commands via the P-Client.
Expected Result:
The CLONE Command should be send to the server and should be
executed there as expected. Wait=1.
Test Steps:
- Start server.
- Archive a file.
- Submit a CLONE Command to clone the disk hosting the archived file
(wait=1).
- Check the response from the server.
Remarks:
It is not checked if the files have been cloned as such. The CLONE
Command is tested in the Test Suite ngamsCloneCmdTest.py.
Test Case: test_Clone_2
Description:
Synopsis:
Send CLONE Command via P-Client.
Description:
Submit a CLONE Command via the P-Client. Disk ID, File ID and File
Version given. Do not wait for termination (wait=0).
Expected Result:
The CLONE Command should be send to the server and accepted.
Test Steps:
- Start server.
- Archive a FITS file.
- Submit a CLONE Command to clone the disk hosting the archived file.
- Check the reply from the server indicates that the Clone Request
was accepted for execution.
Remarks:
It is not checked if the files have been cloned as such. The CLONE
Command is tested in the Test Suite ngamsCloneCmdTest.py.
Test Case: test_Clone_3
Description:
Synopsis:
Send CLONE Command via P-Client.
Description:
Test the CLONE Command. Disk ID, File ID and File Version given.
Wait for termination.
Expected Result:
The CLONE Command should be send to the server and accepted there.
Disk ID, File ID and File Version given. Wait for termination (wait=1).
Test Steps:
- Start server.
- Achive FITS file.
- Clone file specifying Disk ID, File ID and File Version + wait=1.
- Check response from server that the command was executed.
Remarks:
It is not checked if the files have been cloned as such. The CLONE
Command is tested in the Test Suite ngamsCloneCmdTest.py.
Test Case: test_CorrectUsageBuf_1
Description:
Synopsis:
Test Online help feature of NG/AMS P-Client.
Description:
Check that the man-page of the P-Client is displayed on stdout when
the tool is invoked without command line parameters.
Expected Result:
When the tool it invoked on the shell without parameters it should
print out the online help opn stdout.
Test Steps:
- Invoke P-Client on the shell + capture output from stdout.
- Filter output + check that output is as expected.
Remarks:
...
Test Case: test_Init_1
Description:
Synopsis:
Test that the INIT command is correctly handled via the NG/AMS
Python API.
Description:
Test that the INIT Command can be submitted via the P-Client.
Expected Result:
The INTI Command should be send to the server, which should accept
it and re-initialize.
Test Steps:
- Start server.
- Submit INIT Command.
- Check output from server that the command was successfully executed.
Remarks:
...
Test Case: test_Label_1
Description:
Synopsis:
Send LABEL Command via P-Client.
Description:
Test that it is possible to send LABEL Command via the P-Client.
Expected Result:
The LABEL Command should be send to the server and a label produced.
Test Steps:
- Start server.
- Submit LABEL Command specifying Slot ID/Host ID.
- Check response from the server.
Remarks:
...
Test Case: test_Online_1
Description:
Synopsis:
Handling of ONLINE Command via P-Client.
Description:
The purpose of the test is to test the handling of ONLINE Commands
via the P-Client.
Expected Result:
The ONLINE Command should be send to the server by the P-Client.
The server should fo Online.
Test Steps:
- Start server (Auto Online=0).
- Check on response from server that command was successfully handled.
Remarks:
...
Test Case: test_Register_1
Description:
Synopsis:
Send REGISTER Command via P-Client (wait=0).
Description:
Test that the REGISTER command is correctly handled via the NG/AMS
Python API.
Parameter wait specified = 0 (= there is not waited till command
execution has finished).
Expected Result:
The REGISTER Command should be send to the server, which should
start registering the files found under the given path. A response
should be returned before the actual execution of the REGISTER
Command is initiated.
Test Steps:
- Start server.
- Copy file onto one the NGAS Disks.
- Send REGISTER Command via the P-Client to initiate the REGISTER
Command (wait=0).
- Check response from the server.
Remarks:
...
Test Case: test_Register_2
Description:
Synopsis:
Send REGISTER Command via P-Client (wait=1).
Description:
Test that the REGISTER command is correctly handled via the NG/AMS
Python API.
Parameter wait specified = 1 (= there waited till command execution
has finished).
Expected Result:
The REGISTER Command should be send to the server, which should
start registering the files found under the given path. A response
should be returned when the execution finishes.
Test Steps:
- Start server.
- Copy file onto one the NGAS Disks.
- Send REGISTER Command via the P-Client to initiate the REGISTER
Command (wait=1).
- Check response from the server.
Remarks:
...
Test Case: test_RemDisk_1
Description:
Synopsis:
Handling of REMDISK Command via P-Client (execute=1).
Description:
Test that the REMDISK command is correctly handled via the NG/AMS
Python API.
Expected Result:
The REMDISK Command should be send to the server and executed
accordingly.
Test Steps:
- Start server.
- Submit REMDISK Command to remove one of the registered disks
(execute=1).
- Check response from the server.
Remarks:
...
Test Case: test_RemFile_1
Description:
Synopsis:
Send REMFILE Command via P-Client.
Description:
Test correct handling of the REMFILE command via the P-Client.
Expected Result:
The REMFILE Command should be send to the server, which should
execute it accordingly.
Test Steps:
- Start server.
- Archive a FITS file.
- Clone disk hosting the file.
- Issue REMFILE Command via the P-Client specifying to remove the
first copy of the file.
- Check the response from the server.
Remarks:
...
Test Case: test_Retrieve2File_1
Description:
Synopsis:
Handling of RETRIEVE Command via P-Client.
Description:
Test correct handling of the RETRIEVE command from the NG/AMS
Python API (no processing).
Expected Result:
The RETRIEVE Command should be send to the server requesting for
an archive file, which subsequently should be send back to the client
and stored on the local disk.
Test Steps:
- Start server.
- Archive a file.
- Retrieve the archived file into a local file.
- Check the response from the server.
- Check that the requested file has been successfully stored on the
local disk.
Remarks:
...
Test Suite: ngamsRegisterCmdTest
Description:
Synopsis:
Test Suite for REGISTER Command.
Description:
Test Suite that exercises the REGISTER Command in various usages.
Missing Test Cases:
- IMPL:
- wait=0/1
- Register file already registered.
- Register illegal file.
- Non-existing file/path.
- File/path not on NGAS Disk.
- Unknown mime-type.
Test Case: test_RegisterCmd_1
Description:
Synopsis:
REGISTER Command/register single file compl. path.
Description:
Test handling of the REGISTER Command under normal circumstances.
Expected Result:
The REGISTER Command should be accepted by the server and should
be executed successfully.
Test Steps:
- Start server.
- Copy file onto NGAS Disk.
- Submit REGISTER Command requesting to register the file copied over
(wait=1).
- Check response from the server that the request was successfully
executed.
- Check the DB info for the registered file.
Remarks:
...
Test Suite: ngamsRemDiskCmdTest
Description:
Synopsis:
Test handling of REMDISK Command.
Description:
The purpose of the Test Suite is to exercise the REMDISK Command under
normal and abnormal conditions. It is crucial to verify that it is not
possible to remove disks containing files available in less than 3
copies in the archive.
Missing Test Cases:
Test Suite should be reviewed and missing Test Cases added. In particular
Test Cases exercising abnormal cases should be added.
IMPL: - File info can be deleted, file on disk not.
- REMDISK issued to remove disk located in another node.
Test Case: test_RemDiskCmd_1
Description:
Synopsis:
Normal execution.
Description:
Test the normal execution of the REMDISK Command, where a disk,
containing files with at least 3 independent copies is request
REMDISK'ed.
Expected Result:
When executing the REMDISK Command on the cloned disk with execute=0,
the server should accept the command and report this to the client.
When re-issuing the REMDISK Command on the cloned disk with execute=1,
the server should accept the command, execute the REMDISK procedure on
the disk and report this to the client.
Test Steps:
- Start server.
- Archive a file.
- Clone the disk hosting the archived file.
- Issue REMDISK Command to remove the cloned disk (execute=0).
- Check response from the server.
- Issue REMDISK Command to remove the cloned disk (execute=1).
- Check response from the server.
Remarks:
IMPL!: It is not checked that the contents on the disk and the info
in the DB in ngas_files and ngas_disks is properly updated.
Test Case: test_RemDiskCmd_2
Description:
Synopsis:
Missing file copies, REMDISK Command rejected.
Description:
If there are not enough copies of files stored on a disk requested
to be REMDISK'ed, the server should reject the request indicating
the problem in the response.
If an Email Notification List has been specified, the files in
question, should be reported via email.
Expected Result:
The REMDISK Command should be rejected by the server, which should
detect that there are files on the disk requested to be REMDISK'ed,
which are not available in the system in 3 independent copies.
Test Steps:
- Start server.
- Archive file.
- Submit REMDISK to remove Main Disk hosting the archived file
(execute=0).
- Check on the response that the command is rejected by the server.
- Submit REMDISK to remove Main Disk hosting the archived file
(execute=1).
- Check on the response that the command is rejected by the server.
Remarks:
...
Test Suite: ngamsRemFileCmdTest
Description:
Synopsis:
Handling of REMFILE Command.
Description:
The purpose of the Test Suite is to exercise the REMFILE Command under
normal and abnormal conditions. In particular it is verified that it is
not possible to REMFILE files, which are available in less than 3 copies
in the archive.
Missing Test Cases:
IMPL!: The Test Suite should be reviewed and important, missing Test Cases
added. In particular, Test Cases for abnormal behavior should be
added.
IMPL!: - REMFILE submitted specifying file stored on another node.
- DB info can be removed, file info not.
Test Case: test_RemFileCmd_1
Description:
Synopsis:
Test normal execution of the REMFILE Command.
Description:
Test the normal execution of the REMFILE Command, whereby a file is
requested to the REMFILE'd which is available in at least 3 copies.
Expected Result:
The server should identify that the file requested to be removed is
available in at least 3 copies and should accept the request.
Test Steps:
- Start server.
- Archive file.
- Clone Main Disk hosting archived file.
- Submit REMFILE Command requesting to remove cloned file (execute=0).
- Check on response from server that the request has been accepted.
- Submit REMFILE Command requesting to remove cloned file (execute=1).
- Check on response from server that the request has been accepted.
Remarks:
IMPL!: It is not checked that the info for the file is actually
removed from the DB and from the disk.
Test Case: test_RemFileCmd_2
Description:
Synopsis:
Missing file copies, REMFILE Command rejected.
Description:
The purpose of the Test Case is to verify that the REMFILE Command
is rejected when it is attempted to remove files available in less
than 3 copies in the archive. This both when specifying execute=0 and
execute=1.
Expected Result:
The server should detect that the file requested to be REMFILE'd is
not available on the system in at least 3 independent copies.
Test Steps:
- Start server.
- Archive file.
- Submit REMFILE Command to remove copy of file on Main Disk
(execute=0).
- Check on response from the server that the request was rejected.
- Submit REMFILE Command to remove copy of file on Main Disk
(execute=1).
- Check on response from the server that the request was rejected.
Remarks:
IMPL!: It is not check if an Email Notification is sent out listing
files, which could not be removed because they were available
in less than 3 copies.
Test Suite: ngamsRetrieveCmdTest
Description:
Synopsis:
Exercise the RETRIEVE Command.
Description:
The purpose of the Test Suite is to exercise the RETRIEVE Command under
normal and abnormal conditions.
The nominal case, where a file is retrieved from a node where it is
residing is tested, but also the proxy mode where a node is acting as
proxy and retrieving the file from another node is tested. Also the
HTTP re-direction mode for retrieving is tested.
Missing Test Cases:
- Review this entire Test Suite and add important, missing Test Cases.
-IMPL:
- Test RETRIEVE?internal=&host_id=
- Test RETRIEVE?internal=
- TEST RETRIEVAL OF T-FITS FILES VIA A PROXY!
- Test HTTP redirection.
- Test RETRIEVE + processing via DPPI.
- Test RETRIEVE from MNU/HTTP redirection.
- Test authorization.
- Test that the scheme for determining the best suitable file is
working (create dummy entries in ngas_files for files e.g. on
other domains etc.).
Test Case: test_RetrieveCmd_1
Description:
Synopsis:
Retrieve file from server hosting the file.
Description:
The purpose of the test is to test the case where it is attempted
to retrieve an archived file directly from the unit hosting the file.
Expected Result:
The server should locate the file and send it back to the requestor.
Test Steps:
- Start server.
- Archive FITS file.
- Retrieve the file and store it in a local file.
- Check reply from the server indiates that the request was handled
successfully.
- Check that the file on disk has been successfully retrieved.
Remarks:
...
Test Case: test_RetrieveCmd_2
Description:
Synopsis:
Attempt to retrieve non-existing file (wrong version).
Description:
Test the case where it is attempted to retrieve a non-exiting file.
An appropriate error response should be generated.
Expected Result:
The server should identify that the file is not found in the NGAS
Archive and should return a response indicating this.
Test Steps:
- Start server.
- Archive FITS file.
- Retrieve file with same File ID as archived file but with another
version than the one allocated to the file.
- Check the error response from the server.
Remarks:
...
Test Case: test_RetrieveCmd_3
Description:
Synopsis:
Retrieve file from NGAS Cluster sub-node.
Description:
Test that a file stored on a sub-node is located and returned to the
requestor by the contacted server acting as proxy is Proxy Mode is
eneabled.
Expected Result:
The contacted server should locate the file, forward the request to
the node hosting the file, and should send back the file to the
requestor.
Test Steps:
- Start simulated cluster with master and sub-node.
- Archive file onto sub-node.
- Submit Retrieve Request to Master Node to retrieved the archived
file.
- Check the response from the Master Node.
- Check that the file has been retrieved as expected.
Remarks:
...
Test Case: test_RetrieveCmd_4
Description:
Synopsis:
Retrieve Log File from NMU/Sub-Node.
Description:
Retrieve the log file from the master node. Retrieve the log file via
a master node acting as proxy for a sub-node.
Expected Result:
The log file from the Master Node should be returned when no host_id
is given. When specifying a host_id, the contacted server should
identify that the requested log file is located on another node and
should forward the request to the node in question. The contacted node
should send back the file to the requestor.
Test Steps:
- Prepare simulated cluster.
- Retrieve NG/AMS Log File from master node.
- Check that the correct log file has been returned.
- Retrieve NG/AMS Log File from sub-node via master node.
- Check that the correct log file has been returned.
Remarks:
...
Test Case: test_RetrieveCmd_5
Description:
Synopsis:
Retrieve Cfg. File from NMU/Sub-Node.
Description:
Test that the NG/ASM Configuration can be returned from a master
node and a sub-node via a master acting as proxy.
Expected Result:
When no host_id is specified, the cfg. from the contacted node should
be returned. When a host_id is specified, the cfg. from the specified
node should be returned via the contacted node acting as master.
Test Steps:
- Prepare simulated cluster.
- Request cfg. from master.
- Check that correct cfg. has been returned.
- Request cfg. from sub-node via the master.
- Check that correct cfg. has been returned.
Remarks:
...
Test Case: test_RetrieveCmd_6
Description:
Synopsis:
Retrieve Internal File from NMU/Sub-Node.
Description:
With the RETRIEVE?internal Retrieve Request, it is possible to retrieve
files not being archived files and readable for the user running NGAS.
This test exercises this feature.
Expected Result:
The specified internal file should be located by the server and send
back to the requestor. The internal file is first retrieved from the
master node, then from a sub-node via the master acting as proxy.
Test Steps:
- Prepare simulated cluster with master and sub-node.
- Send RETRIEVE Command to retrieve /etc/hosts from the master.
- Check that the proper file has been retrieved.
- Send RETRIEVE Command to retrieve /etc/hosts from the sub-node
via the master, acting as proxy.
- Check that the proper file has been retrieved.
Remarks:
...
Test Suite: ngamsServerTest
Description:
Synopsis:
Test Suite of NG/AMS Server.
Description:
The purpose of this Test Suite is to exercise specific features of the
NG/AMS Server not exercised while testing other features (commands etc).
Missing Test Cases:
IMPL: Analyze if this Test Suite is relevant.
IMPL: Test HTTP authorization
IMPL: Test loading of NG/AMS Configuration from DB (different combinations
of parameters).
IMPL: Test of handling of Request DB/Info.
Test Case: test_1
Description:
Synopsis:
...
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
...
Test Suite: ngamsStatusCmdTest
Description:
Synopsis:
Test execution of the STATUS Command.
Description:
The purpose of this Test Suite is to exercise the STATUS Command
under normal and abnormal condition.
Both the simple execution on the contacted node, and the Proxy Mode
are tested.
Missing Test Cases:
- IMPL: Review this Test Suite and add missing, important Test Cases.
- IMPL!: Test STATUS?request_id!!!!
- IMPL!: Test STATUS?disk_id
- IMPL!: Test all cases for usage of STATUS with proxy host.
- IMPL!: STATUS?file_access: File not found on disk.
Test Case: test_StatusCmd_1
Description:
Synopsis:
Test normal execution of STATUS Command/local.
Description:
Test the execution of the STATUS Command when no parameters are
specified. This just makes the server return the basic status about
the operational environment.
Expected Result:
The server should return a reponse to the STATUS Command, indicating
the status of the system.
Test Steps:
- Start server.
- Submit STATUS Command.
- Check that the response to the STATUS Command contains the info
as expected.
Remarks:
...
Test Case: test_StatusCmd_2
Description:
Synopsis:
Test normal execution of STATUS Command/Proxy.
Description:
If another node is specified than the contacted node, when submitting
the STATUS Command, the contacted node should act as proxy and should
forward the request to the specified sub-node.
Expected Result:
The response from the specified sub-node should be returned to the
client.
Test Steps:
- Start simulated cluster.
- Submit STATUS Command referring to sub-node in cluster.
- Check that the response returned indicates that the request was
forwarded to the sub-node.
Remarks:
...
Test Case: test_StatusCmd_3
Description:
Synopsis:
Test normal execution of STATUS Command/File Access/Proxy.
Description:
It is possible to query the information about the accessibility of
a file given by its File ID and/or corresponding Disk ID and/or
File Version. Also Proxy Mode is supported for this feature. This is
exercised in this Test Suite.
Expected Result:
The information about the file, located on a sub-node should be
retrieved by the contacted node acting as proxy.
Test Steps:
- Start simluated cluster.
- Archive file onto sub-node.
- Submit STATUS?file_access&file_version Command specifying file,
previously archived.
- Check that the contacted node located the file and forwarded the
request to the sub-node and that the appropriate reponse was
returned.
Remarks:
...
Test Suite: ngamsSubscriptionTest
Description:
Synopsis:
Test the Subscription Service.
Description:
NG/AMS offers a Data Subscription Service
Missing Test Cases:
IMPL: Review Test Suite and define Test Cases.
IMPL: Test UNSUBSCRIBE Command.
Test Case: test_1
Description:
Synopsis:
...
Description:
...
Expected Result:
...
Test Steps:
- ...
Remarks:
...