Testing WSO2 User Engagement Server
Testing WSO2 User Engagement Server can be divided into a few major areas. Please find the high-level details that can be used when testing WSO2 User Engagement Server below.
Portal :-
Portal is the section where users can create and design dashboards.
Create a Dashboard:-
A user can create any number of dashboards. But they can view only one dashboard at a time.
1. Access the User Engagement Server portal (eg: https://ues.wso2.com/portal)
2. Login with valid credentials
3. Click on Add button
4. Provide Dashboard Name
5. Hit Next button
The user should be redirected to a page where they are asked select a layout for the dashboard.
6. Click Select button on desired dashboard layout
Now the user will be presented with a screen where the page structure is divided into the layout selected in step 6. On this screen, user can add gadgets to the dashboard.
A gadget is a single component that can be displayed on a dashboard. A gadget can contain various details such as stats, feeds, maps etc.
Adding a Gadget to a Dashboard:-
Once the user has created the dashboard, next step is to customize it by adding gadgets. These gadgets are displayed on the left-hand side of the edit-dashboard screen. Simply click on the plus sign on the left-hand side column. This should expand the gadgets section.
A gadget is added to a column displayed on the dashboard. A single column can have multiple gadgets. To add a gadget to the dashboard, simply drag and drop the gadget into a column.
Removing a Gadget from Dashboard:-
To remove a gadget from dashboard, simply click on the recycle bin icon on top right-hand side of the gadget in edit dashboard screen
Viewing Gadgets in maximized mode:-
The user can view a gadget on default mode, as well as maximized mode. To view a gadget on maximized mode, simply click on the maximize icon displayed on top of the top left.
Scrolling within Gadgets:-
When the content is too lengthy to be displayed within a gadget scrolling should be enabled. User should be able to scroll up/down within the gadget. Especially this functionality needs to be tested on mobile browsers.
Personalized Dashboards for Users:-
Dashboards are developed in a way that can be easily personalized at user profile level. These modifications can be extracted into different stages by user privileges.
Admin Users:-
Users with admin rights can create and modify dashboards. Once an admin user modifies a dashboard these changes are visible to all non-admin users. Meaning if an admin user adds a gadget to a particular dashboard, all the non-admin users looking at the dashboard will be able to see newly added gadget.
Non-Admin Users:-
Non-admin users also can personalize the dashboards. But the visibility of these changes are restricted to that particular user profile. For example, if a non-admin user adds a new gadget to a dashboard, other users should not see this change.
Handling Multiple Dashboards:-
In WSO2 User Engagement Server users can create multiple dashboards. It is important to verify that these dashboards’ contents remain independent from each others.
Even though a gadget can be used in any number of dashboards, when there are multiple dashboards, dashboard layout A should be independent from the dashboard layout B.
Concurrency Testing for WSO2 User Engagement Server:-
WSO2 User Engagement server provides users with multiple dashboards. It is vital to maintain a good concurrency level in order to serve users with satisfying experience.
Since WSO2 products are used in production servers as clusters it is recommended to test concurrency on top of a cluster set up. For the ease of understanding, I will use the following production set up to explain the load testing approach.
Preconditions:-
- There should be a dashboard created in portal
- Dashboard should consist of a number of gadgets
Scenario:-
1. A non-admin user logs into the system.
2. Accesses the dashboard.
3. Verifies that the gadgets are available on the dashboard.
4. Logs out of the system.
In order to test concurrency, we use Apache Jmeter. Tester should create a Jmeter script to simulate the above scenario. In our case tester needs to pay extra attention when creating the Jmeter script because SSO enabled SAML requests needs to be handled carefully within the Jmeter script HTTP Requests.
Concurrency Testing Approach:-
There are two main approaches we have used to test concurrency of WSO2 User Engagement Server cluster.
Method — 1: Gradually increase the load while the cluster is up and running. Then check at which point the server becomes unstable.
In this approach, just start the cluster and leave it for about 5–10 minutes to become stable as a best practice. Then start the Jmeter Script and monitor the logs for each node. Log files can be found at [$UES_HOME]/repository/logs/wso2carbon.log. Also, it is important that we monitor Jconsole while the tests are running. Please take a look at the stats displayed below in order to get an idea how the load tests are carried out. Pay attention to the pattern of how the thread count is incremented.
System Stability/ Thread Count:-
JConsole Output for a Single UES Node:-
Method — 2: In this method, we started the server, and randomly restarted each UES node by using a shell script while load tests are running. This approach is important to understand how the High Availability is being handled on cluster. Please find the example script below in order to restart the WSO2 product. This assumes that there is only one WSO2 product running on the server at a given time. You can change DOWNTIME and UPTIME variables and the location of the wso2server.sh file in $[UES_HOME]/bin folder.
#!/bin/bash
#finds wso2 product process and kills it and restarts the server
DOWNTIME=1m
UPTIME=2m
while [ true ]
do
kill -9 $(ps -C java -o pid | tr -dc ‘0–9’)
echo WSO2 server killed
sleep $DOWNTIME
cd /home/ubuntu/UES/wso2ues-2.0.0-m4/bin
sh wso2server.sh start
echo WSO2 server started in background
sleep $UPTIME
done