数据库迁移性能测试测试策略

测试策略：

在环境1中进行测试，计算TPS和错误率

在环境2中进行测试，计算TPS和错误率

对比两次测试结果，确保使用最好的环境

Table of Contents

1. Introduction

2. Objective

3. In Scope

4. Architecture

5. Non-functional Requirement (NFR)

5.1 Load & Stress Test Volume for API

5.2 Endurance Test Volume for API

5.3 Stress Test Volume for Batch

6. Workload Model

6.1 Workload Model - Load Test

6.2 Workload Model - Stress Test

7. Performance Testing Approach

7.1 Load Test for API

7.2 Stress Test for API

7.3 Endurance Test for API

7.4 Stress Test for Batch

8. Performance Monitoring Approach

9. Performance Test Environment

10. Performance Tools Used

11. Performance Test Reporting

12. Key Performance Indicators (KPIs)

12.1 KPI for API Testing

12.2 KPI for Batch Testing

13. Support Required

14. Performance Test Timeline

15. Defect Management

16. Assumptions

1. 
   Introduction

This document outlines the approach for performance testing the WeLab Bank applications.

Performance assessment will be conducted for the bank applications in T24 core banking platform while the system is under load with mobile banking API requests triggered from frontend.

1. Objective

The primary goal of performance testing is to validate the successful migration of the T24 core banking system database migration from NuoDB to Postgres DB. This process aims to ensure that system performance remains stable and does not degrade as a result of the database transition.

The testing will focus on confirming that the system can effectively handle the anticipated load generated by mobile App APIs, ensuring that all API responses meet the defined Service Level Agreement(SLA)

Key areas of assessment will include:

• Mobile API Performance:

Evaluating the responsiveness and throughput of APIs triggered from mobile app under expected usage volumes

• T24 Component Monitoring

Conducting comprehensive application and system health assessment of the T24 core banking components to ensure optimal performance and reliability post-migration.

1. In Scope

The performance testing team would conduct following activities for the scope of performance testing.

Scope:

• Mobile API – 25? end-to-end business critical flows which comprises of 82 API requests.
• T24 Component – Monitor the application and system health of T24 core banking during performance test execution.

Activities:

• Requirement Gathering - Finalize NFR’s based on the analysis of the requirements.
• Performance Test Plan – Design performance test plan document based on the input received in requirement gathering phase. This document should be signed off by the approver or stakeholders.
• Performance Test Design – Create test scripts, enhance and validate for multiple data points.
• Test Infrastructure Validation – Validate the test tool infrastructure before test execution.

• Performance Test Execution – Run planned set of test execution as per the target volume of transactions.
• Performance Test Monitoring – Monitor the application and system health by Dynatrace, Active MQ, Rancher tools during test execution.
• Performance Test Reporting – Prepare Test reports containing observations, analysis and recommendations. Final copy of report should be signed-off by the approver for project closure.

1. Architecture

Below architecture diagram depicts the flow of request or calls for FPS Credit Transfer.

<check with latest diagram for FPS>

Below architecture diagram depicts the flow of request or calls for Loan On-boarding.

<check with latest diagram for Loan>

<Wealth?>

1. Non-functional Requirement (NFR)

The NFR analysis is one of the key area for successful accomplishment of performance testing, below table elaborates on the volumetric to be simulated during performance testing.

5.1 Load & Stress Test Volume for API

The Load test will be executed for 1 hour of steady state duration with 100 concurrent users in 1 minute of ramp-up time and the Stress test will be executed for 1 hour of steady state duration with 200 concurrent users in 2 minutes of ramp-up time.

Main App API Load & Stress Test Volume

S No.	Functionality		API Name	Load Test Volume	Stress Test Volume	Response Time SLA (in Sec)
				Transaction / Hour	Transaction / Hour
1	FPS Add Money	GET	/v1/payments/edda/banks/me	5500	10000	1
		POST	/v1/payments/direct-debit	5500	10000	1
2	FPS Send Money	GET	/v1/payments/limits	3600	5500	1.3
		POST	/v1/payments/limits	3600	5500	1.3
		GET	/v1/bank-accounts/core/spending-account	3600	5500	1.3
		POST	/v1/fps-registrations/enquiry	3600	5500	1.3
		POST	/v1/payments/check-account	3600	5500	1.3
		POST	/v1/accounts/me	3600	5500	1.3
		POST	/v1/payments/credit-transfer	3600	5500	1.3
3	Get Notifications	GET	/v1/message-center/notificationInfo	3800	7300	0.9
		PUT	/v1/message-center/notificationInfo	3800	7300	0.9
		GET	/v1/message-center/notifications	3800	7300	0.9
		GET	/v1/payments/edda/list-mandate-request-outward	3800	7300	0.9
		GET	/v1/payments/edda/pending-number	3800	7300	0.9
		GET	/v1/payments/edda/list-mandate	3800	7300	0.9
4	GoSave2	GET	/bulgarians-cf/bank-account/v1/get-bank-account	3500	7000	1.2
		POST	/bulgarians-cf/passenger/v1/check-passenger	3500	7000	1.2
		POST	/bulgarians-cf/passenger/v1/add-passenger	3500	7000	1.2
5	ApplePay_CardProvisioning	POST	/v1/ehi/service/getTransaction.asmx/	34000	65000	0.36
6	ApplePay_CardTransaction	POST	/v1/ehi/service/getTransaction.asmx/	50000	100000	0.7
7	CirrusATM_CardTransaction	POST	/v1/ehi/service/getTransaction.asmx/	1763	3500	3.2
8	Wealth_JumpingFlow	GET	/v1/wealth/translations?language=zh-hk	960	1500	0.3
		GET	/v1/wealth/white-list	960	1500	0.3
		GET	/v1/wealth/investment-account-status	960	1500	0.3
		GET	/v1/wealth/max-age	960	1500	0.3
		GET	/v1/wealth/max-horizon	960	1500	0.3
		GET	/v1/wealth/customer/personal-info	960	1500	0.3
		GET	/v1/wealth/investment-account-status	960	1500	0.3
		GET	/v1/wealth/investment-instruction-request-data	960	1500	0.3
		GET	/v1/wealth/questionnaires/crpq	960	1500	0.3
		GET	/v1/wealth/client-goals	960	1500	0.3
		GET	/v1/wealth/goal-categories-templates	960	1500	0.3
		GET	/v1/wealth/promotion/promotion-lists	960	1500	0.3
		GET	/v1/wealth/investment-account-status	960	1500	0.3
		GET	/v1/wealth/investment-account-status	960	1500	0.3
		GET	/v1/wealth/client-goals	960	1500	0.3
9	Wealth_GoalSetting	GET	/v1/wealth/customer/check-monthly-income	2800	5600	0.6
		GET	/v1/wealth/grid-finder-v2	2800	5600	0.6
		POST	/v1/wealth/client-goals	2800	5600	0.6
		GET	/v1/wealth/all-static-doc	2800	5600	0.6
		GET	/v1/wealth/normal-and-boost-portfolio	2800	5600	0.6
		GET	/v1/wealth/model-portfolio-details/${boostPortfolioCode}	2800	5600	0.6
		GET	/v1/wealth/last-model-portfolio-projection	2800	5600	0.6
		GET	/v1/wealth/model-portfolio-details/${portfolioCode}	2800	5600	0.6
		GET	/v1/wealth/fx/single-quote	2800	5600	0.6
		GET	/v1/wealth/settlement-date/${portfolioCode}	2800	5600	0.6
		GET	/v1/wealth/fx/single-quote	2800	5600	0.6
		GET	/v1/wealth/model-portfolio-details/${portfolioCode}/fee	2800	5600	0.6
		GET	/v1/wealth/subscription-date	2800	5600	0.6
		GET	/ v1/wealth/portfolio-docs/${portfolioCode}	2800	5600	0.6
10	Wealth_IAO	GET	/v1/wealth/questionnaires/crpq	1150	2300	0.7
		GET	/v1/wealth/questionnaires/non-crpq	1150	2300	0.7
		GET	/v1/wealth/static-doc/WEALTH_BROCHURE	1150	2300	0.7
		GET	/v1/wealth/investment-account-status	1150	2300	0.7
		GET	/v1/wealth/confirm-onboarding	1150	2300	0.7
		GET	/v1/wealth/static-doc/FATCA_PDF	1150	2300	0.7
		GET	/v1/wealth/customer/personal-info	1150	2300	0.7
		GET	/v1/wealth/onboarding-requests/dicts	1150	2300	0.7
		POST	/v1/wealth/investment-instruction	1150	2300	0.7
		GET	/v1/wealth/investment-account-status	1150	2300	0.7
		POST	/v1/wealth/documents/upload-v2	1150	2300	0.7
		POST	/v1/wealth/questionnaires/answers	1150	2300	0.7
11	Wealth_FX	GET	/v1/wealth/accounts-balance	400	800	3
		GET	/v1/wealth/fx/single-quote	400	800	3
		GET	/v1/wealth/accounts-balance/USD	400	800	3
		POST	/v1/wealth/fx/init-order	400	800	3
		GET	/v1/wealth/fx/single-quote	400	800	3
		GET	/v1/wealth/fx/orders	400	800	3
12	Wealth_GoalEdit	GET	/v1/wealth/grid-finder-v2	1050	2000	0.95
		POST	/v1/wealth/client-goals	1050	2000	0.95
		GET	/v1/wealth/client-goals/${clientGoalId}	1050	2000	0.95
		PUT	/v1/wealth/client-goals/${clientGoalId}/goal-name?goalName=JMeterTest	1050	2000	0.95
		POST	/v1/wealth/client-goals	1050	2000	0.95
		GET	/v1/wealth/all-static-doc	1050	2000	0.95
		GET	/v1/wealth/normal-and-boost-portfolio	1050	2000	0.95
		GET	/v1/wealth/model-portfolio-details/${portfolioCode}	1050	2000	0.95
		GET	/v1/wealth/model-portfolio-details/${boostPortfolioCode}	1050	2000	0.95
		DELETE	/v1/wealth/client-goals/${clientGoalId}	1050	2000	0.95
13	MSG-Registration	POST	/v1/onboarding-requests/rewards/register/me	9000	18000	1
		GET	/v1/onboarding-requests/rewards/register/me?eventName=easonTicket2022&customerId=${customer_idMSGReg}	9000	18000	1
14	MSG-Change Address	PUT	/v1/accounts/me/addresses	1300	2500	1.4
15	Add Money	GET	/v1/payments/edda/banks/me	900	1700	1.7
		POST	/v1/payments/direct-debit	900	1700	1.7
16	RTGS HKD	POST	/payment-crossborder-srv/v1/jobs/inward-mx-message	600	1200	1.1
		GET	/payment-crossborder-srv/v1/jobs/pending-payments?events=REDO_ACCT_VRF	600	1200	1.1
		POST	/payment-crossborder-srv/v1/jobs/account-verification	600	1200	1.1
17	RTGS USD	POST	/payment-crossborder-srv/v1/jobs/inward-mx-message	600	1200	1
		GET	/payment-crossborder-srv/v1/jobs/pending-payments?events=REDO_ACCT_VRF	600	1200	1
		POST	/payment-crossborder-srv/v1/jobs/account-verification	600	1200	1
18	Send Money	GET	/v1/bank-accounts/core/spending-account	900	1700	1.5
		POST	/v1/payments/credit-transfer	900	1700	1.5
19	RTGS offus Fund Out USD	GET	/onboarding-pro/jwt/${customer_idUSD}	450	900	1
		GET	/payment-mob/v1/payments/rtgs/bank-info	450	900	1
		GET	/payment-mob/v1/payments/rtgs/business-datetime	450	900	1
		GET	/payment-mob/v1/payments/swift/charge-info?channel=RTGS¤cy=USD	450	900	1
		GET	/payment-mob/v1/payments/currency-conversion?from=USD&to=HKD&amount=1.00	450	900	1
		POST	/payment-mob/v1/payments/rtgs-transfer	450	900	1
20	RTGS onus Fund Out + onus Fund In USD	GET	/onboarding-pro/jwt/${customer_idUSD}	450	900	4
		GET	/payment-mob/v1/payments/rtgs/bank-info	450	900	4
		GET	/payment-mob/v1/payments/rtgs/business-datetime	450	900	4
		GET	/payment-mob/v1/payments/swift/charge-info?channel=RTGS¤cy=USD	450	900	4
		GET	/payment-mob/v1/payments/currency-conversion?from=USD&to=HKD&amount=1.00	450	900	4
		POST	/payment-mob/v1/payments/rtgs-transfer	450	900	4
21	Global Remit In USD	POST	/payment-crossborder-srv/v1/jobs/inward-mx-message	900	1800	1
		GET	/payment-crossborder-srv/v1/jobs/pending-payments?events=REDO_ACCT_VRF	900	1800	1
		POST	/payment-crossborder-srv/v1/jobs/account-verification	900	1800	1
22	Global Remit Out USD	GET	/onboarding-pro/jwt/${customer_idUSD}	900	1800	1
		GET	/payment-mob/v1/payments/cross-border-transfer/country-list	1000	2000	1.1
		GET	/payment-mob/v1/payments/cross-border/payment-information?countryCode=US¤cy=USD	1000	2000	1.1
		GET	/payment-mob/v1/payments/cross-border-transfer/payee-list?countryCode=US	1000	2000	1.1
		GET	/payment-mob/v1/payments/cross-border-transfer/bic-matching?bic=BOFAUS3MXXX&countryCode=US	1000	2000	1.1
		GET	/payment-mob/v1/payments/swift/charge-info?channel=SWIFT¤cy=USD	1000	2000	1.1
		GET	/payment-mob/v1/payments/currency-conversion?from=USD&to=HKD&amount=10.00	1000	2000	1.1
		POST	/payment-mob/v1/payments/cross-border-transfer	1000	2000	1.1

Note:

• Stress test volume for MGM is 500 transaction per minute. Calculated it in TPH coming as 30,000 TPH. Considering load test volume 15,000 TPH (half of Stress test volume).
• Load and Stress test volumes for Apple Pay Card Provisioning are same (1,000 TPH). Including non-apple pay card transactions, the volume for Apple Pay Card Transactions in load test is 6,000 TPH and in stress test is 12,000 TPH.

5.2 Endurance Test Volume for API

Endurance test would be conducted with load test volume only with 100 concurrent users ramping up in 2 minutes and running for longer period (4 to 6 hours of test).

1. Workload Model

This section will detail on the workload pattern for each type of tests planned for execution.

S No.	Test Type	Concurrent Users	Ramp-up Period	Test Duration (Steady-state)	Ramp-down Period
1	Load Test – API	104	1 minutes	1 hour	1 minutes
2	Stress Test - API	208	2 minutes	1 hours	2 minutes

6.1 Workload Model - Load Test

S No.	Scenario Name	Concurrent Users	Target TPH
1	FPS Add Money	10	4800
2	FPS Send Money	10	3600
3	Get Notifications	6	3800
4	GoSave2	7	3500
5	ApplePay_CardProvisioning	5	28000
6	ApplePay_CardTransaction	5	5000
7	CirrusATM_CardTransaction	4	1700
8	Wealth_JumpingFlow	3	960
9	Wealth_GoalSetting	12	2800
10	Wealth_IAO	5	1100
11	Wealth_FX	5	400
12	Wealth_GoalEdit	8	1000
13	MSG-Registration	10	9000
14	MSG-Change Address	4	1300
15	USD phase 1	5	3000
16	USD phase 2	5	2800
Total		104

6.2 Workload Model - Stress Test

S No.	Scenario Name	Concurrent Users	Target TPH
1	FPS Add Money	20	9600
2	FPS Send Money	20	7200
3	Get Notifications	12	7600
4	GoSave2	14	7000
5	ApplePay_CardProvisioning	10	56000
6	ApplePay_CardTransaction	10	10000
7	CirrusATM_CardTransaction	8	3400
8	Wealth_JumpingFlow	6	1900
9	Wealth_GoalSetting	24	5600
10	Wealth_IAO	10	2200
11	Wealth_FX	10	800
12	Wealth_GoalEdit	16	2000
13	MSG-Registration	20	18000
14	MSG-Change Address	8	2600
15	USD phase 1	10	6000
16	USD phase 2	10	5600
Total		208

1. Performance Testing Approach

Performance testing approach pertaining to API’s is done by generating expected load at API gateway layer which in turn generates load to target T24 system through Active MQ layer.

Figure 1: Performance Testing Approach

While Mobile API load is triggered at front-end, and the back-end system is under load. Below monitoring activities would be performed runtime.

• Client-side statistic would be captured through LoadRunner tool.
• MQ health (like Queue depth) should be captured by Active MQ Console.
• Application and System health would be monitored by Dynatrace tool and Racher console.

7.1 Load Test for API

To evaluate application performance with peak user load and transaction volume.

• Concurrent Users: 104
• Ramp-up & Ramp-down period: 1 minutes
• Test Duration: 1 hour (steady state)

7.2 Stress Test for API

To measure capacity of the application to sustain the transactional load greater than peak projected loads.

• Concurrent Users: 208
• Ramp-up & Ramp-down period: 2 minutes

• Test Duration: 1 hour (steady state)

7.3 Endurance Test for API

To identify application performance bottlenecks and hardware infrastructure health issues during an extended duration of application usage with peak user and transactional load.  Key metrics, which are investigated, are Memory Usage Trends, Frequent Major Garbage Collections, CPU Spikes, etc.

• Concurrent Users: 500
• Ramp-up & Ramp-down period: 10 minutes

• Test Duration: 4 - 6 hours

7.4 Stress Test for Batch

Batch performance test would be triggered with help of batch engineer. The monitoring activity is conducted for validating the responsiveness and scalability of the batch system with peak volume of data. Typically, it covers the performance analysis of the COB batch jobs with peak business volume in T24 banking system.

1. Performance Monitoring Approach

The Performance test team engages in monitoring of the servers with help of,

• Dynatrace & Rancher tool – To collect the application and system health metrics.
• Support Team – To collect T24 statistics after batch jobs run.
• Active MQ Tool – To collect the MQ health statistics during test execution.
• DBA Team – To collect NuoDB performance report from Infrastructure team for batch processed records analysis.

1.  Performance Test Environment

Performance test environment specification is analyzed to derive the scaling factor with respect to production environment. Below table of data confirms that UAT environment hardware specification is very close to that of production environment but not exactly similar.

Note: It has been agreed that UAT environment will be matched in terms of hardware configurations with production before test execution starts.

S No.	Specifications	Production Environment	UAT or Staging Environment
1	Number of servers/nodes	Rancher: 3 masters 31 workers	Rancher: 3 masters 64 workers
2	Physical Memory Size (RAM) in GB	Rancher: 32GB * 19 64GB * 15	Rancher: 32GB * 12 64GB * 15
3	No. of CPU Cores	Rancher: 4 cores * 6 8 cores * 13 16 cores * 15	Rancher: 4 cores * 6 8 cores * 18 16 cores * 3
4	DB Type	Mssql / Postgres	Mssql / Postgres
5	Disk Capacity	Portworx Total Capacity: 24TiB EBS NuoDB (data disk): 3 * 1024GiB Active: 3 * 50GiB ECFPS: 2 * 100GiB ForgeRock: 6 * 100GiB EFS (mainly for airflow, backup and monitoring) Capacity: 8EiB (on demand)	Portworx Total Capacity: 24TiB EBS NuoDB: 3 * 1024GiB Active: 3 * 50GiB ECFPS: 2 * 100GiB ForgeRock: 6 * 100GiB EFS (mainly for airflow, backup and monitoring) Capacity: 8EiB (on demand)
6	DB Capacity	RDS (DB Engine|RDS Instance Type|Storage Size) ECFPS: SQL Server|db.m5.2xlarge|100GiB Payment: PostgreSQL|db.m5.xlarge|100GiB ForgeRock:PostgreSQL|db.m5.large|100GiB Loan: PostgreSQL|db.r5.large|100GiB KeyCloak: PostgreSQL|db.r5.large|100GiB	RDS (DB Engine|RDS Instance Type|Storage Size) ECFPS: SQL Server|db.m5.large|100GiB Payment: PostgreSQL|db.m5.large|100GiB ForgeRock:PostgreSQL|db.t3.small|50GiB Loan: PostgreSQL|db.t3.medium|50GiB KeyCloak: PostgreSQL|db.t3.small|50GiB

1. Performance Tools Used

Performance testing and monitoring tools that were used are mentioned below,

Levers	Tools Name
Performance Testing Tools	Jmeter
Performance Monitoring Tools	Dynatrace, Rancher, Active MQ Console
Client-side token generation	NodeJS

Load Generators Specification

• 2 VM machines would act as Load Generator & Controller machines

• 172.16.30.21

• Out of the 5 machines, one machine will act as Controller and installed with Micro Focus LoadRunner Controller (license key will reside on this machine) and rest of the virtual machines will act as Load Generators (LG) to simulate up to 250 virtual users per LG.
• All the machines should also have MS Office (Word, Access and Excel packages), Fiddler & Adobe Acrobat Reader installed

1. Performance Test Reporting

Results will be collated from all the test execution and an interim report will be shared in email content after each test execution. The following testing reports will be provided as part of this engagement:

Executive Test Summary report – This word document report will contain summary of all the planned test executions and key observations. This will be delivered as an engagement closure document with detailed analysis and recommendation.

1. Key Performance Indicators (KPIs)

Below mentioned key performance indicators will be captured from test execution logs.

12.1 KPI for API Testing

Below KPI’s will be captured while API performance testing is conducted.

• • API performance analysis from achieved throughput & response time.
  • Application health monitoring
• System resource utilization

1. Support Required

Below mentioned support is required for metric collection during or after the test execution.

Area	Support Required	Responsible Team / Person
T24	T24 statistics extract	T24 Team
Database	PostgresDB Performance Statistics	Infrastructure Team

1. Performance Test Timeline

Milestone	From	To	Remarks
Test Planning and Scripting preparation	6 Jan	28 Feb
Test Execution	10 Jan	8 Mar
Test reporting

1. Defect Management

Below relevant data will be captured during the performance testing for defect management process. The defect data related to performance testing will be published in the final Test Summary Report as evidence.

• Test Phase Detected In
• Defect ID
• Severity
• Priority
• Module
• Label
• Status
• Detected on
• Reported By
• Assigned To
• Summary
• Comment / Resolution Logs

1. Assumptions

Below are the assumptions made for performance testing.

No	Description
1	Performance testing environment is functionally stable and is in proportion to production (capacity, configurations and data)
2	Any other API’s not listed in the section 5.1, is treated as out of scope.
3	“Partial and Full withdrawal from POT”, “Card Transactions” functionalities have been taken out of scope and Loans submission and Loans Draw-down functionalities are included in scope. MGM & Apple Pay has been added newly in scope of performance testing
4	Simulating MQ API separately is  not required as Mobile API triggered from frontend mobile app will in turn trigger the MQ API to simulate the end to end performance.
5	Simulating extra calls/requests to T24 backend system is not required, the frontend Mobile API call will generate the load in “Frontend to T24 through MQ” flow.
6	Performance testing team is enabled with access to relevant testing tools and server access for monitoring the systems under test
7	Support from Development team, Middleware team, DBA is available when required
8	Performance monitoring tool (Dynatrace) is configured as required
9	WeLab & solution vendor stakeholders will be available during the engagement to provide necessary technical inputs/clarifications to Cognizant team-members
10	Credentials to log in to WeLab’s network should be available to all performance test team members
11	If security mechanisms like MFA/2FA, validations for OTP (one-time PIN) or Captcha are used in the application-instance deployed in the Performance Test (PT) environment, such mechanisms should be disabled in the application-instance, or a default OTP/PIN should be provided for all test user-IDs
12	Issues related to application, environment, etc., that hamper/halt performance assessment activities will be resolved by the relevant WeLab stakeholders at the earliest within a mutually agreed ETA to avoid impact to project schedule
13	WeLab will provide inputs to identify key real-time mobile-UI and API-based transactions, and batch processes, for consideration in PT scope. Performance SLAs for key business transactions will be provided by WeLab
14	Valid test-data like required number of test user account for scripting and test execution will be made available to the PT team by WeLab. The test user-IDs should have necessary roles to execute all in-scope functional steps and must have similar access rights to application functionalities to ensure that business-flows do not vary across user-IDs. “Test” bank accounts must be set up by WeLab with all data prerequisites (e.g., positive balance in account, etc.) for performance testing
15	Production-like DB volume will be made available by WeLab during PT executions for realistic scenario-simulation. It has been agreed that UAT environment will be matched in terms of hardware configurations with production before test execution starts.
16	A relevant WeLab team will monitor server performance metrics during performance tests & share logs with Cognizant after each test based on mutually agreed timelines
17	Both MGM and Apple Pay functionalities should be available in staging environment
18	The new scope (MGM & Apple pay) should not have additional development work involved in encryptions or tokenization during performance test script design.
19	Apple Pay Card Provisioning functionality triggers an SMS at the end with notification service, this is out of scope for performance testing
20	Card simulator/Interface configuration, transaction initiation should be done by WeLab.
21	The total number of users to be simulated should be less than 1000 concurrent users.
22	The test execution must be done in combined manner (including the complete scope) to assess the overall performance impact of the system under test.