170 likes | 343 Views
Functional Testing. Montpellier October 2006 perfSONAR Meeting Michalis Michael (Cynet). Functional Testing . Service Oriented Testing Black Box Testing Behavioural Testing Automated Testing. Functional Testing is necessary to:. Make sure that the service actually works
E N D
Functional Testing Montpellier October 2006 perfSONAR Meeting Michalis Michael (Cynet)
Functional Testing • Service Oriented Testing • Black Box Testing • Behavioural Testing • Automated Testing
Functional Testing is necessary to: Make sure that the service actually works This is accomplished by a wide range of tests If the tests are successful the service is functioning inside the specified parameters
Functional Testing process • A wide range of requests is fed to the service • Requests that are well formatted containing valid information • Requests that are malformed • Requests containing invalid or non sufficient information • Responses are collected and checked for validity • Responses information are cross-checked with information inside the service database
Process Create Requests Feed requests into Service Log responses Check for validity/Correlate responses against actual DB data Test Passed Test Failed
LS Functional Tests • Focus on checking LS response to : • Well formatted requests containing valid information • Requests that are not well formatted with or with out valid information • Requests that do not contain enough information • Requests with excess information also maybe fed • Suggestions: • Check LSCleanup (will do if time is enough) • Check the RRD MA against the LS
A LSRegisterRequest example • The request is missing the Data element . The LS should return an error response
LS Functional Test – Parts needed • A request building script-class. • A script-class that feeds the requests to the LS and stores the responses from the LS. (Requests are send via the SOAPClient class that is already available in the release) • A script-class that processes the responses (parser) and correlates the results with the actual data stored in the database (eXist). Here is decided whether the test has succeeded or failed.
What has been done so far • A document was send to the perf-dev mailing list, listing the tests that are going to be done, in order to get feedback from the developers • Started working on the request generating class. Class for the LSRegisterRequest has been developed
TO DO • Finish the developing of the classes for generating requests for the other types of requests • Make sure that the communication with the LS via the SOAPClient class is working • Last ( but trickier ) the development of the script-class for parsing and checking the responses from the LS
Help Needed • More like RFC documentation ( An accurate and detailed documentation is needed for the tester to understand the way a service works and responds). • Maybe some information on how independent components of the services work, like the databases i.e. • Suggestions for enriching and improving the scheduled tests.
An example – RRD MA • Metadata Key Request <?xml version='1.0'encoding='UTF-8'?> <nmwg:message type="MetadataKeyRequest" id="mdrq1" … <nmwg:parameters id="msgparam1"> <nmwg:parameter name="authToken">PIONIER-Public</nmwg:parameter> <nmwg:parameter name="timeValue">1127250495</nmwg:parameter> <nmwg:parameter name="timeType">unix</nmwg:parameter> </nmwg:parameters> <nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nmwgt:interface> <nmwgt:ifAddress type="ipv4">212.191.224.106</nmwgt:ifAddress> <nmwgt:ifName>ge-2/1/0.102</mwgt:ifName> <nmwgt:direction>out</nmwgt:direction> </nmwgt:interface> </netutil:subject> <nmwg:eventType>utilization</nmwg:eventType> </nmwg:metadata> <nmwg:data id="1"metadataIdRef="meta1"/> </nmwg:message> Test categories • Message Format • Message Values • Combination Both correct and incorrect messages are fed
An example – RRD MA • Tested messages • MetaData Key Request • SetupData Request • StoreRequest • All examples found in • http://wiki.perfsonar.net/jra1-wiki/index.php/Schemata_and_Instances • Helped produce a number of tests • Interaction with the LS will also be tested.
Current Status RRDMA Tests status • Infrastructure complete • The main script - Coordinator Executes • The creator script • Creates the requests in xmlfiles • Notes the validity of the requests • The request script • Actually used the SoapClient Class • Feeds the xml requests to the service and outputs the responses to xml files • The parser script • Checks the validity of the responses • Double-checks the responses with the actual data in the database
Current Status 2 • Creator Script The creator script is almost done. Actually different creator scripts were created for different message types. Minor changes are to be made when everything is completed • Request Script Done • Parser Script Work in progress. So far 2 test types are recognised. Work is needed also on the double-checking mechanism.
Current Status 3 RRDMA service has changed since perfSONAR 1.0. Major changes: • 1.0 Uses Error Messages • 1.0 will use Error Codes An RRDMA 1.1 server should be able to interact natively with a 1.0 client The functional testing team will check 1.1 version against 1.1 and 1.0 tailored tests.
Q & A • Questions • Comments