EDIFACT order export performance testing
- Dennis Bridges
Testing environment
FOLIO: Performance testing environment
Limited to single node of mod-data-export-spring
Environment resources should be equivalent to a production 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 export jobs: 10
- Number of order lines being exported: 10,000
- Number of orders: 8,000
- POL limit 50
- Export job schedule frequency: Monthly (If hourly export drop a 0 from the amount of orders and order lines)
Real world conditions:
There will be variation in the numb er of Jobs an institution will have. Some institution could have 10 or 15 concurrent exports and some institution could have only 1 or 3. It is not dependent on size it depends when they have scheduled the exports. If they schedule everything on the same day and time or they stagger them.
The number of orders will also vary. Some vendors the library will only order a few things from per month and some they may order most things at specific times each year. Meaning there might be 10 orders per exports and then one day there will be 2000 because they send 2 big orders.
Dataset:
- Orders must contain all possible data points for EDI export
- Some order lines with multiple locations
- Some order lines with format = P/E Mix (Two units prices and two quantities on FOLIO side)
- At least 1 organization with 2 export configurations
- At least one organization using default export flag rather than an account number
- Different exports should export to both FTP and SFTP locations
Test approach:
- Create organizations and integrations
- Load orders data set
- Open FOLIO orders
- Observe export activity