Gateway Verification and Validation Plan

Service/Component Description

See Gateway SRC

Deployment scenarios

Gateway can be installed on a separate machine or on the same machine where one or more back-end servers are installed.

Functionality tests

[TO BE DONE - Add remaining cases, the current list is incomplete only for the initial release in EMI-1. Note that most of those test cases are nearly implemented - only some details are missing.]

Resilience against invalid requests (implemented: gw_wrongHdr)
Gateway must deny requests with invalid SOAP formatting. Especially SOAP headers with invalid data must not be accepted. Correct but too big (to be kept in memory) headers must be denied too.

Dynamic site registration (implemented: gw_dynReg)
Test whether gateway allows for dynamic registration of new backend sites. The registration using HTTP POST method to the VSITE_REGISTRATION_REQUEST resource at the gateway should succeed if and only if the dynamic registration is enabled in configuration.

Forwarding of GET requests (NOT implemented)
Gateway must properly forward GET requests to the backend site. This must be tested with a simple backend service and HTTP client. The original request must be forwarded and response produced by the service returned to the client. The test is passed only if the response received by the client is unmodified.

Forwarding of POST/SOAP requests (NOT implemented)
Gateway must properly forward POST requests to the backend site. This must be tested with a simple backend HTTP service and HTTP client. The original SOAP request body must be forwarded and response produced by the service returned to the client. The test is passed only if:
  • the SOAP Body of the client request is unmodified at the backend server side.
  • all SOAP Headers of the client request are present and are unmodified at the backend server side (but new headers may be present too).
  • the response received by the client the same as what the backend server produced.

Security of dynamic site registration (NOT implemented)
Verify that the dynamic registration filters configured with registration.deny and registration.allow work correctly:
  • host matching allow rule should be accepted when there is no deny rule
  • host matching deny rule should be denied even if are entered in accept rule

Authentication (NOT implemented)
Test whether gateway properly extracts client's identity from SSL and inserts it as an SAML assertion in SOAP header.

Integration tests

[TO BE DONE]

Performance tests

  1. Test performance of request processing by invoking 10000 operations with do-nothing implementations of the back-end service. PASS criteria: at least 1000 exchanges per second on a commodity hardware. [implemented]
  2. Measure data transfer speed by streaming 100MB of data through gateway back and forth. TBD: define pass criteria [NOT implemented]

Scalability tests

  1. Test gateway by 100 of concurrent clients that should submit 1000 requests each to do-nothing service behind the gateway. Note that for this test maximum number of concurrent connections per service should be increased to 100 (or different services should be used). TBD: define pass criteria [NOT implemented]
  2. Invoke in parallel 10 instances of the transfer speed performance test and measure decreasing of the added transfer speed. TBD: define pass criteria [NOT implemented]

Standard Compliance/Conformance tests

N/A

Regression tests and unit tests

Unit tests coverage must be included in the test report. All bugs reported should have an automated regression test attached if it is possible. Otherwise manual bug checking procedure should be added to this section. Note that this applies to bugs reported from the 1.11.2010.

Regression tests to be performed manually:

  • N/A

Deployment scenarios

GATEWAY is deployed as an administrative domain-central service which might serve one or more domain's servers. This paragraph It's quite similar for all components.

According to a definition of "Smoke Testing":

Smoke Testing: A quick-and-dirty test that the major functions of a piece of software works.

Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

Smoke Testing Steps:

Software components that have been translated into code are integrated into a "build". A build includes all data files, libraries, reusable modules and engineering components required to implement one or more product functions. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover "show stopper" errors that have the highest likelihood of throwing the software project behind schedule. The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.

We have planned, following our experience on UNICORE, the steps needed to verify software base installation and base functionality aspects. UNICORE server self-installing jar file version requires not too much work to let the installation works, in this way we can perform a very elementary test without too much effort, obviously only a few properties in UNICORE configuration files can be set.

first of all we have to test the packages that will be built and delivered within and for EMI, i.e. the .deb or .rpm packages. So the current server bundle (which is outside EMI and released separately from EMI) is not relevant here.

In general I'd try to define a deployment testing procedure in multiple stages.

All should works with the default configuration, which will have to be designed in order that this kind of testing is possible, this should work out of the box... i.e. directly after running the installation procedure (yum install...) with no changes to the config files necessary.

Some question/answer to define steps:

1) Which threads should be started at the end of the procedure? gateway

2) How many hosts I have to use? one vm host is enough.

3) Where? on UNICORE Juelich testbed

4) Which platform? For now UNICORE components are built on SLC5-EPEL and tested on OpenSUSE

5) db entries? we can test it trying to add some entry into the xuudb using the admin.sh script

6) user to start the service is unicore

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2011-02-23 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback