Versions Compared

Old Version 6

changes.mady.by.user Martin Ritchie

Saved on

compared with

New Version Current

changes.mady.by.user Martin Ritchie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

This section enumerates the various operational tests described in the Test Plan identified from the Functional Specification. This text should form the basis of the Technial Documenation Technical Documentation for the specified test class.

...

Description: On startup the broker reports the broker version number and svn build revision. This information is retrieved from the resouce resource 'qpidversion.properties' which is located via the classloader.
Input: The 'qpidversion.properties' file located on the classpath.
Output:

...

  1. The BRK ID is correct
  2. This occurs before any BRK-1002 listenting listening messages are reported.
testBrokerStartupListeningTCPDefault

...

testBrokerStartupReady

Description:
The final messasge message the broker will print when it has performed all initialisation and listener startups will be to log the BRK-1004 Ready message
Input:
No input, all succesful successful broker startups will show BRK-1004 messages.
Output:

...

No Format
MNG-1001 : Startup
MNG-1002 : Starting : <service> : Listening on port <Port>
MNG-1003 : ShutingShutting down : <service> : port <Port>
MNG-1004 : Ready
MNG-1005 : Stopped
MNG-1006 : Using SSL Keystore : <path>

...

Description:
Using the startup configuration validate that the managment management startup messasge message is logged correctly.
Input:
Standard configuration with management enabled
Output:

...

No Format
<date> MESSAGE MNG-1002 : Starting : RMI RegistgryRegistry : Listening on port 8999

Constraints:
The RMI ConnectorServer and Registry log messages do not have a prescribed order
Validation Steps:

...

  1. The MNG ID is correct
  2. The specified port is as specified on the commandlinecommand line.
testManagementStartupRMIConnectorServer

...

  1. The MNG ID is correct
  2. There has been a MNG-1001 message
  3. There has been at least one MNG-1002 Listenting Listening message
  4. No further MNG messages are produced as part of the startup process, i.e. before broker use.

...

No Format
<date> MNG-1003 : Shutting down : RMI RegistgryRegistry : Listening on port 8999

Validation Steps:

...

  1. The VHT ID is correct
  2. A VHT-1001 is printed for each virtualhost defined in the configration configuration file.
  3. This must be the first message for the specified virtualhost.

...

Description:
During shutdown the MessageStore will also cleanly close. When this has completed a MST-1003 closed message will be logged. No further messages from this MessageStore will be logged after this message
Input:
Default configuratinoconfiguration
Output:

No Format
<date> MST-1003 : Closed

...

Description:
A persistent queue must be persisted so that on recovery it can be restored independantly independently of any messages that may be stored on it. This test verifies that the MessageStore will log that it has recovered 0 messages for persistent queues that do not have any messages.
Input:

...

Description:
After the queue has been recovered the store will log that recovery has been completed. The MessageStore mustn ot must not report further status about the recovery of this queue after this message. In addition every MST-1004 queue recovery start message must be matched with a MST-1006 recovery complete.
Input:
Default persistent configuration
Output:

...

  1. The MST ID is correct
  2. This must occur after the queue recovery start MST-1004 has been logged.
  3. The queue.name is non-empty
  4. The queue.name corrolates correlates with a previous recovery start

...

Description:
Once all persistent queues have been recovered and the MessageStore has completed all recovery it must logged that the recovery process has completed.
Input:
Default persistent configuraionconfiguration
Output:

No Format
<date> MST-1006 : Recovery Complete

...

  1. Running Broker
  2. Connected Client
    Output:
    No Format
    <date> CON-1002 : Close
    Validation Steps:
  3. The CON ID is correct
  4. This must be the last CON message for the Connection
  5. It must be preceeded preceded by a CON-1001 for this Connection

...

testConnectionCloseViaManagement

...

Channel

The Channel test suite validates that the follow log messages as specified in the Functional Specification.

Description:
When a connected client has its connection closed via the Management Console this will be logged as a CON-1002 message.
Input:

  1. Running Broker
  2. Connected Client
  3. Connection is closed via Management Console
    Output:
    No Format
    
<date> CON-1002 : Close
    Validation Steps:
  4. The CON ID is correct
  5. This must be the last CON message for the Connection
  6. It must be preceded by a CON-1001 for this Connection

Channel

The Channel test suite validates that the follow log messages as specified in the Functional Specification.

This suite of tests This suite of tests validate that the Channel messages occur correctly and according to the following format:

...

Description:
When a new Channel (JMS Session) is created this will be logged as a CHN-1001 Create message. The messagse messages will contain the prefetch details about this new Channel.
Input:

...

Description:
The Java Broker implements consumer flow control for all ack modes except No-Ack. When the client fills the prefetch. As soon as the client starts to consume the messages (and ack them) the broker will resume the flow issuing a CHN-1002 Flow Started messasge message to the log
Input:

  1. Running broker
  2. Message Producer to put more data on the queue than the client's prefetch
  3. Client that ensures that its prefetch becomes full
  4. The client then consumes from the prefetch to remove the flow status.
    Output:
    No Format
    <date> CHN-1002 : Flow Started
    Validation Steps:
  5. The MST ID is correct

...

  1. Running broker
  2. Persistent Queue is created from a client
    Output:
    No Format
    <date> QUE-1001 : Create : Persistent Owner:<name>
    Validation Steps:
  3. The QUE ID is correct
  4. The Peristent Persistent tag is present in the message
  5. The Owner is as expected

...

  1. Running broker
  2. AutoDelete Persistent Queue is created from a client
    Output:
    No Format
    <date> QUE-1001 : Create : AutoDelete Persistent Owner:<name>
    Validation Steps:
  3. The QUE ID is correct
  4. The Peristent Persistent tag is present in the message
  5. The Owner is as expected
  6. The AutoDelete tag is present in the message

...

  1. Running broker
  2. Persistent Queue is created from a client with a priority level
    Output:
    No Format
    <date> QUE-1001 : Create : Persistent Priority:<levels> Owner:<name>
    Validation Steps:
  3. The QUE ID is correct
  4. The Peristent Persistent tag is present in the message
  5. The Owner is as expected
  6. The Priority level is correctly set

...

  1. Running broker
  2. An AutoDelete Persistent Queue is created from a client with priority
    Output:
    No Format
    <date> QUE-1001 : Create : AutoDelete Persistent Priority:<levels> Owner:<name>
    Validation Steps:
  3. The QUE ID is correct
  4. The Peristent Persistent tag is present in the message
  5. The Owner is as expected
  6. The AutoDelete tag is present in the message
  7. The Priority level is correctly set

...

  1. Running broker
  2. An autodelete Transient Queue is created from a client with a priority level
    Output:
    No Format
    <date> QUE-1001 : Create : AutoDelete Transient Priority:<levels> Owner:<name>
    Validation Steps:
  3. The QUE ID is correct
  4. The Transient tag is present in the message
  5. The Owner is as expected
  6. The AutoDelete tag is present in the message
  7. The Priority level is correctly set

...

testQueueDelete

...

testCreateQueueTransientViaManagementConsole

...

Description:
An explict QueueDelete request must result in Queue creation is possible from the Management Console. When a queue is created in this way then a QUE-1002 Deleted message being logged. One way the queue can be deleted is via na explict AMQP QueueDelete method1001 create message is expected to be logged.
Input:

  1. Running Broker
  2. Queue created on the broker with no subscribers
  3. broker
  4. Connected Management Console
  5. Queue Created via Management ConsoleClient requests the queue be deleted via a QueueDelete
    Output:
    No Format
    <date> QUE-10021001 : Deleted
Create : Transient Owner:<name>
    Validation Steps:
  6. The QUE ID is correct

...

testQueueAutoDelete

...

  1. The correct tags are present in the message based on the create options

...

testQueueDelete

...

Description:
When a Client requests a temporary queue then this is represented in the Java Broker as an autodelete exclusive queue. When the client disconnects the queue will automatically deleted. This can be seen as An explict QueueDelete request must result in a QUE-1002 Deleted message will be loggedbeing logged. This can be done via an explict AMQP QueueDelete method.
Input:

  1. Running Broker
  2. Queue created on the broker with no subscribers
  3. Client creates a temporary queue then disconnectsrequests the queue be deleted via a QueueDelete
    Output:
    No Format
    <date> QUE-1002 : Deleted
    Validation Steps:
  4. The QUE ID is correct

...

testQueueAutoDelete

...

Exchange

The Exchange test suite validates that the follow log messages as specified in the Functional Specification.

This suite of tests validate that the Exchange messages occur correctly and according to the following format:

...

Description:
When a Client requests a temporary queue then this is represented in the Java Broker as an autodelete exclusive queue. When the client disconnects the queue will automatically deleted. This can be seen as a QUE-1002 Deleted message will be logged.
Input:

  1. Running Broker
  2. Client creates a temporary queue then disconnects
    Output:
    No Format
    
<date> QUE-1002 : Deleted

...

  1.  Validation Steps:
  2. The QUE ID is correct
...
testQueueDeleteViaManagementConsole
...
testExchangeCreateDurable
...
Description:
 The ManagementConsole can be used to delete a queue. When a durable exchange is created an EXH-1001 message is logged with the Durable tag. This will be the first message from this exchange.this is done a QUE-1002 Deleted message must be logged.
 Input: 
  1. Running Broker
  2. Queue created on the broker with no subscribers
  3. Management Console connected
  4. Queue is deleted via Management ConsoleClient requests a durable exchange be created.
     Output: 
     No Format
    <date> EXHQUE-10011002 : Create : Durable Type:<value> Name:<value>Deleted

     Validation Steps:
  5. The EXH QUE ID is correct
Exchange
The 
...
Exchange test suite validates that the follow log messages as specified in the Functional Specification.
This suite of tests validate that the Exchange messages occur correctly and according to the following format:
 No Format

EXH-1001 : Create : [Durable] Type:<value> Name:<value>
EXH-1002 : Deleted

...
testExchangeCreateDurable
...
Description:
 When a durable 
...
testExchangeCreate
...
Description:
 When an exchange is created an EXH-1001 message is logged with the Durable tag. This will be the first message from this exchange.
 Input: 
  1. Running broker
  2. Client requests an a durable exchange be created.
     Output: 
     No Format
    <date> EXH-1001 : Create : Durable Type:<value> Name:<value>

     Validation Steps:
  3. The EXH ID is correct
...
testExchangeDelete
...
  1. The Durable tag is present in the message
...
testExchangeCreate
...
Description:
 An Exchange can be deleted through an AMQP ExchangeDelete method. When this is successful When an exchange is created an EXH-1002 Delete 1001 message will be is logged. This will be the last first message from this exchange.
 Input: 
  1. Running broker
  2. A new Exchange has been created
  3. Client requests that the new Client requests an exchange be deletedcreated.
     Output: 
     No Format
    <date> EXH-1002 : Deleted1001 : Create : Type:<value> Name:<value>

     Validation Steps:
  4. The EXH ID is correct
  5. There is a corresponding EXH-1001 Create message logged.
Binding
...
testExchangeDelete
...
Description:
 An Exchange can be deleted through an AMQP ExchangeDelete method. When this is successful an EXH-1002 Delete message will be logged. This will be the last message from this exchange.
 Input: 
  1. Running broker
  2. A new Exchange has been created
  3. Client requests that the new exchange be deleted.
     Output: 
     No Format
    
<date> EXH-1002 : Deleted

     Validation Steps:
  4. The EXH ID is correct
  5. There is a corresponding EXH-1001 Create message logged.
Binding
The Binding test suite validates that the follow log The Binding test suite validates that the follow log messages as specified in the Functional Specification.
...
Description:
 The binding of a Queue and an Exchange is done via a Binding. When this Binding is created a BND-1001 Create messasge message will be logged.
 Input: 
  1. Running Broker
  2. New Client requests that a Queue is bound to a new exchange.
     Output: 
     No Format
    <date> BND-1001 : Create 

     Validation Steps:
  3. The BND ID is correct
  4. This will be the first message for the given binding
...
  1. Running Broker
  2. Java Client consumes from a topic with a JMS selector.
     Output: 
     No Format
    <date> BND-1001 : Create : Arguments : <key=value>

     Validation Steps:
  3. The BND ID is correct
  4. The JMS Selector argument is present in the message
  5. This will be the first message for the given binding
...
testBindingDelete
...
testBindingCreateViaManagementConsole
...
Description:
 Bindings can be deleted so that a queue can be rebound with a different set of values.
 Input:  The binding of a Queue and an Exchange is done via a Binding. When this Binding is created via the Management Console a BND-1001 Create message will be logged. 
 Input: 
  1. Running Broker
  2. Connected Management Console
  3. Use Management Console to perform binding
  4. Running Broker
  5. AMQP UnBind Request is made
     Output: 
     No Format
    <date> BND-10021001 : Create Deleted

     Validation Steps:
  6. The BND ID is correctThere must have been a BND-1001 Create message first.
  7. This will be the last first message for the given binding
...
testBindingDelete
...
Subscription
The Subscription test suite validates that the follow log messages as specified in the Functional Specification.
...
Description:
 Bindings can be deleted so that a queue can be rebound with a different set of values.
 Input: 
  1. Running Broker
  2. AMQP UnBind Request is made
     Output: 
     No Format
    

...
  1. <date> BND-1002 : 
...
  1. Deleted

...
testSubscriptionCreate
...
  1.  Validation Steps:
  2. The BND ID is correct
  3. There must have been a BND-1001 Create message first.
  4. This will be the last message for the given binding
...
testBindingDeleteViaManagementConsole
...
Description:
 Bindings can be deleted so that a queue can be rebound with a different set of values. This can be performed via the Management ConsoleDescription:
 When a Subscription is created it will be logged. This test validates that Subscribing to a transient queue is correctly logged.
 Input: 
  1. Running Broker
  2. Management Console connected
  3. Management Console is used to perform unbindCreate a new Subscription to a transient queue/topic.
     Output: 
     No Format
    <date> SUBBND-10011002 : CreateDeleted

     Validation Steps:
  4. The SUB BND ID is correct
...
testSubscriptionCreateDurable
...
Description:
 The creation of a Durable Subscription, such as a JMS DurableTopicSubscriber will result in an extra Durable tag being included in the Create log message
 Input: 
...
  1. There must have been a BND-1001 Create message first.
  2. This will be the last message for the given binding
Subscription
The Subscription test suite validates that the follow log messages as specified in the Functional Specification.
This suite of tests validate that the Subscription messages occur correctly and according to the following format
...
:
 No Format


...
SUB-1001 : Create : [Durable
...
] [Arguments : <key=value>]
SUB-1002 : Close

...
testSubscriptionCreate
...
Description:
 When a Subscription is created it will be logged. This test validates that Subscribing to a transient queue is correctly logged
...
testSubscriptionCreateWithArguments
...
Description:
 The creation of a Subscriber with a JMS Selector will result in the Argument field being populated. These argument key/value pairs are then shown in the log message.
 Input: 
  1. Running Broker
  2. Subscriber created with a JMS SelectorCreate a new Subscription to a transient queue/topic.
     Output: 
     No Format
    <date> SUB-1001 : Create : Arguments : <key=value>

     Validation Steps:
    

     Validation Steps:
  3. The The SUB ID is correct
  4. Argument tag is present in the message
...
testSubscriptionCreateDurableWithArguments
...
testSubscriptionCreateDurable
...
Description:
 The final combiniation of SUB-1001 Create messages involves the creation of a Durable Subscription that also contains a set of Arguments, such as those provided via a JMS Selector.a JMS DurableTopicSubscriber will result in an extra Durable tag being included in the Create log message
 Input: 
  1. Running Broker
  2. Creation of a JMS DurableTopicSubiberJava Client creates a Durable Subscription with Selector
     Output: 
     No Format
    <date> SUB-1001 : Create : Durable Arguments : <key=value>

     Validation Steps:
  3. The SUB ID is correct
  4. The Durable tag Durable is present in the message
...
testSubscriptionCreateWithArguments
...
...
testSubscriptionCreateQueueBrowser
...
Description:
 The creation of a QueueBrowser will provides a number arguments and so should form part of the SUB-1001 Create Description:
 The creation of a Subscriber with a JMS Selector will result in the Argument field being populated. These argument key/value pairs are then shown in the log message.
 Input: 
  1. Running Broker
  2. Subscriber created with a JMS Selector.Java Client creates a QueueBroweser
     Output: 
     No Format
    <date> SUB-1001 : Create : Arguments : <key=value>

     Validation Steps:
  3. The SUB ID is correct
  4. The Arguments are Argument tag is present in the message
  5. Arguments keys include AutoClose and Browser.
...
testSubscriptionClose
...
testSubscriptionCreateDurableWithArguments
...
Description:
 When a Subscription is closed it will log this so that it can be corrolated with the Create The final combination of SUB-1001 Create messages involves the creation of a Durable Subscription that also contains a set of Arguments, such as those provided via a JMS Selector.
 Input: 
  1. Running Broker
  2. Java Client with a subscription.creates a Durable Subscription with SelectorThe subscription is then closed.
     Output: 
     No Format
    <date> SUB-10021001 : Create : Durable Arguments : Close<key=value>

     Validation Steps:
  3. The SUB ID is correct
  4. There must be a SUB-1001 Create message prceeding this message
  5. This must be the last message from the given Subscription
Performance Test Cases
  1. The tag Durable is present in the message
  2. The Arguments are present in the message
...
testSubscriptionCreateQueueBrowser
...
Description:
 The creation of a QueueBrowser will provides a number arguments and so should form part of the SUB-1001 Create message. 
 Input: 
  1. Running Broker
  2. Java Client creates a QueueBroweser
     Output: 
     No Format
    
<date> SUB-1001 : Create : Arguments : <key=value>

     Validation Steps:
  3. The SUB ID is correct
  4. The Arguments are present in the message
  5. Arguments keys include AutoClose and Browser.
...
testSubscriptionClose
...
Description:
 When a Subscription is closed it will log this so that it can be correlated with the Create.
 Input: 
  1. Running Broker
  2. Client with a subscription.
  3. The subscription is then closed.
     Output: 
     No Format
    
<date> SUB-1002 : Close

     Validation Steps:
  4. The SUB ID is correct
  5. There must be a SUB-1001 Create message preceding this message
  6. This must be the last message from the given Subscription
Performance Test Case
In addition to the performance test suite an additional performance test needs to be written that can be run with this new logging enabled and disabled so that an attempt at quantifying any impact can be made.
Test Structure
The test should perform the following actions:
  1. Connect a client
  2. Create a channel/JMS Session
  3. Create an exchange
  4. Create a queue
  5. Bind the exchange and queue
  6. Create a subscriber on the queue
  7. Close the Subscriber
  8. Close the Session
  9. Close the Connection
This will ensure that we hit as many of the new logging routines as possible.
 If this test should also be run prior to any code changes so that our current performance can be recorded.
Risks
Testing of this nature is dependant on a lot of items that are out of the tests control such as:
  1. CPU scheduling
  2. CPU performance
  3. Load
  4. GC
As a result the test cannot be guaranteed to produce the same results each time. To mitigate this risk running the test in a loop an reporting an average value of 10-20 runs should provide a more stable response.
 Leaving the broker startup/shutdown out of the test loop will help improve the tests performance and repeatability.TBC