Testing environment

EBSCONET: mock environment if it is actually possible to use this environment for testing. Otherwise, tests will be conducted using a FOLIO environment only.

FOLIO: Performance testing environment

Testing type

Required testing type


Load testing	Load testing measures system performance as the workload increases. That workload could mean concurrent users or transactions. The system is monitored to measure response time and system staying power as workload increases. The workload falls within the parameters of normal working conditions.
Stress testing	Unlike load testing, stress testing — also known as fatigue testing — is meant to measure system performance outside of the parameters of normal working conditions. The software is given more users or transactions that can be handled. The goal of stress testing is to measure the software stability. At what point does software fail, and how does the software recover from failure?
Spike testing	Spike testing is a type of stress testing that evaluates software performance when workloads are substantially increased quickly and repeatedly. The workload is beyond normal expectations for short amounts of time.
Endurance testing	Endurance testing — also known as soak testing — is an evaluation of how software performs with a normal workload over an extended amount of time. The goal of endurance testing is to check for system problems such as memory leaks. (A memory leak occurs when a system fails to release discarded memory. The memory leak can impair system performance or cause it to fail.)
Scalability testing	Scalability testing is used to determine if software is effectively handling increasing workloads. This can be determined by gradually adding to the user load or data volume while monitoring system performance. Also, the workload may stay at the same level while resources such as CPUs and memory are changed.
Volume testing	Volume testing determines how efficiently software performs with large projected amounts of data. It is also known as flood testing because the test floods the system with data.

"Normal" condition parameters:

Number of concurrent users: 2
Number of order lines being renewed 1000
Number of orders being renewed 804
4 of these orders have 50 POLs each - 800 orders with 1 POL each

"Extreme" condition parameters:

Number of concurrent users: 10
Number of order lines being renewed 5000
Number of orders being renewed 4804
4 of these orders have 50 POLs each - 4800 orders with 1 POL each

Dataset:

1 organization with Vendor = true
1 fiscal year, 1 Ledger, 1 Fund, 1 budget - each order line can reference this budget with 1 fund distribution.
Fill all possible integration fields for the majority of test orders
Some order lines with multiple locations
Some order lines with format = P/E Mix (Two units prices and two quantities on FOLIO side)
100 orders Where the EBSCONET file contains a type of non-renewal (These orders should be updated to canceled on FOLIO side) These orders would be closed as canceled.
Create a test data set of EBSCONET order line update requests - Each requests needs to include a valid POL number from the created data set.

Test approach:

Not using actual EBSCONET environment for testing.
Create a test data set of 2000 order lines
Order need to be in the Open status in FOLIO before the test begins
Send EBSCONET GET request
Send EBSCONET PUT requests to FOLIO env via edge-orders

Results of testing:

Opportunities for improvement:

Browser not supported