Amis25 practical example service virtualization api simulation

Paraso& Proprietary and Confiden1al 1

6/10/16

Practical example of Service Virtualization for API simulation

[email protected]

Paraso& Proprietary and Confiden1al 2 Paraso& Proprietary and Confiden1al 2

§  Paraso& is supplier automated tes1ng solu1ons §  Since 1984, Los Angeles (US) and Krakow (EU) §  Development Tes1ng PlaMorm §  Con1nuous Tes1ng PlaMorm

§  Solu1on Architect for Paraso& Nordics §  Since 1992 in Valida1on & Verifica1on (PhD) §  Since 1999 in SW Tes1ng §  Joined Paraso& 2004, focus Benelux and Scandinavia §  Research projects at University of Groningen

§  Joined work with: §  Faris Nizamic §  John van der Molen §  Bas Dijkstra

Introduction


We are living in a Distributed World

Mobile devices force the industry to re-think the user experience

APIs drive composite apps and interconnecting multiple dependencies

Cloud challenges ingrained concepts about software development


Bus

Bus

Cloud Resource

Partner

Partner

Bus

Bus

ERP

Modern IT systems are a collec1on of many components, o&en exposes as services

Testing in our Distributed World


Bus

Bus

Cloud Resource

Partner

Partner

Bus

Bus

ERP

For tes1ng this: We need this:



Service-‐oriented systems characteris1cs: §  Func1onality spread across the network §  Interdependent services with no single owner §  No full control over a (sub)system

Test automa1on -‐ sa1sfying maturity level §  Test tools capable suppor1ng automa1on process §  Test automa1on techniques available to test teams

YET, Agile so&ware development is being delayed due to of number of constraints imposed by SOA.

Bus

Bus

Cloud Resource

Partner Partner

Bus

Bus

ERP



Conducted a survey, asking so&ware developers, testers, and performance test engineers a series of ques1ons about their access to test environments.

The survey results show: §  Applica1ons rely on an average of 8 dependent services §  30% of 1me is spend on configura1on on test environment §  71% of developers/testers need to schedule test environment

access §  Average 1me block for access is 4 hours §  50% of the test plan is actually executed §  20% of the dependent services' func1onality is required for

dev / test tasks

Survey on Constraints in Testing


Constraints

Availability Schedule Data Other

limited access to a sub-‐system

no access to a sub-‐system

not sufficient dev/test environments

non-‐instant availability of a sub-‐system

unfinished subsystem not available data

not appropriate data

corrupted data

necessary test-‐data not in sub-‐systems

fees of invoking third-‐party system

limited usage permission of a sub-‐

system

Not allowed data corrup1on of a sub-‐

system

regulatory controls conflic1ng

delivery schedules of sub-‐systems

not appropriate delivery

coordina1on

Survey on Constraints in Testing


Other industries: Simulation


For Service Oriented Systems the use of Virtual Services is the current technique to obtain simulated environments.

Service virtualiza-on emulates the behavior of so5ware components to remove dependency constraints on development and tes-ng teams (Wikipedia).

Virtual Services can be modeled or generated from traffic coming to and from real services.

How to simulate environment in SOA


Service Virtualization: How does it work?

Monitor & Capture

Initiated from the system under test, the user has the ability to capture detail from a live monitor that analyzes system traffic, from analyzing transaction logs or by modeling virtual behavior within the Parasoft Virtualized interface.

Model & Deploy

After the virtualized artifact has been captured, users can now instruct the details of the virtualized asset behavior. This includes: performance, data sources and conditional response criteria. The virtualized asset is then provisioned for simplified uniform access across teams and business partners.

Provision & Consume

The virtualized asset can now be called for unit, functional and performance tests. The virtualized asset can be leveraged by any test suite – including Parasoft Test.


Studielink is the central hub for informa1on exchange between: §  University (around 70 in NL) §  DUO (government body for Ministry of Educa1on)

Hoger onderwijsinstellingen Hoger onderwijsinstellingen Hoger

onderwijsinstellingen Hoger onderwijsinstellingen

Case study: Studielink


§  Student uses it for to enroll to study at university §  Central portal for address muta1ons



§  Studielink connects the “student informa1on system” (SIS) of the university to the web-‐services of DUO

§  Data that is exchanged include: §  Personal data ( both GBA as well as non-‐GBA data ); §  Educa8on history §  Indica8on of the type tui8on §  Registra8on informa8on as well as study-‐results (exams)



§  Studielink offers universi1es and (SIS) suppliers a number of test-‐environments to perform the acceptance tes1ng

§  Due to budget and technical constraints, DUO has only one structural test-‐environment available

§  This connec1on to DUO is vital for Studielink and partners for a successful tes1ng of complete flows: §  Test scenarios have con1nuous exchange of messages within the chain

§  Custom made mock were regarded too expensive

The constraints


Introduced Service Virtualiza1on


Implemented Paraso& Virtualize on a cloud-‐based machine §  Used STunnel for SSL connec1on to the different SIS systems §  Implemented virtual assets for HOA and HOI services Phase 1 (pilot): §  Technical obstacles, in par1cular SSL connec1vity §  Simula1on of the primary data-‐flows

§  Including a-‐sync communica1on like address modifica1on

Phase 2: §  Extended of the number of different data-‐flows §  Implementa1on of storing persistent data (use of database)

§  Not providing the same registra1on number twice

Introduced Service Virtualiza1on


Results


Studielink can offer the partners on all test-‐environments a connec1ons with the web-‐services of DUO (real or simulated): §  Technical aspects of the connec1on (like the use of cer1ficates)

can be simulated successfully §  Contains over 4000 student records, including school history §  Available for three different test-‐environments §  Via SSL available over the Internet §  Used by all Dutch universi1es and polytechnics. §  Already “up and running” for more then 2 years §  More 3rd party services be “virtualized”

Results


Typical API: §  Message formats: SOAP, XML, JSON, EDI, Fixed Length, SWIFT §  Transport protocols: HTTP, JMS, MQ, FTP, AS2 Typical message flows: §  Synchronous communica1on §  Generated responses based on data-‐table look up (“SELECT”) §  State-‐based virtualiza1ons (“UPDATE”) §  A-‐synchronous communica1on (like provisioning) §  Batch processing (like payments) §  More ?!

Abstract away from case study


Typical Virtualiza1ons: §  Proxy / rou1ng services §  Virtual assets based on “real” traffic (record & playback) §  Virtual assets based on interface defini1on

Typical use cases and modeling: §  Regression tes1ng => Fixed responses §  Func1onal tes1ng => Data-‐driven responses §  Load & performance tes1ng => Performance profiles §  Resilience tes1ng => Data modifica1on §  Cer1fica1on processes => Data valida1on



Who creates the Virtual Assets: §  Consumer: Owner of the problem, limited domain knowledge §  Producer: Full domain knowledge, has it’s own problems Deployment models: §  Central server

§  Central maintained Virtual Assets (‘Waterfall’) §  De-‐central deployed Virtual Assets (‘Agile’)

§  De-‐central servers §  Own local servers (‘DevOps’) §  Cloud based implementa1on (“Con1nuous Delivery”)



Move to decentral cloud based set-‐up

Paraso& Environment Manager


Summary

Service Virtualiza1on solves constraints in tes1ng distributed systems: §  Availability §  Scheduling §  Data

Benefits depends of the situa1on: §  Speed up the overall tes1ng 1me §  Solve the test-‐data management problem §  Enabler of test-‐automa1on §  Cost reduc1on for staged environments Bus

Bus

Partner Partner

Bus

Bus

ERP


Summary

Enabler for Con1nuous Tes1ng and Delivery in distributed environments: §  Key for Agile methodologies, DevOps §  Integra1on with Jenkins etc. §  Docker & cloud deployment

Allows Environment Based Tes1ng: §  Not only the front door, also the back door §  Resilience, Security, Performance, Cer1fica1on


No guarantee… user error…


Further reading and information

Email: Rix.Groenboom@Paraso&.NL Mobile: +31-‐62-‐240-‐1968

Amis25 practical example service virtualization api simulation

Technology