[#9560] JMeter GUI Test Plan (JMX) for Admin Authentication, AddInstructor, L…

[paramvir1994]

Part of #9560

The issue #9561 mentioned to use Jmeter GUI for creation of test plan. I planned to contribute on this issue and it covers the following:

1. Basic Test Plan for JMeter GUI (.jmx file) including User defined variables, HTTP Cookie Manager, Thread group and Summary Report.
2. Implemented the performance test scenarios for Admin Authentication, Adding Instructor, Loading the courses.
3. Used Regular Expression Extractor for fetching the CSRF-Token and using it for generating the cookie parameter for the future web requests.

Steps for execution:

1. Setup JMeter on your system.
2. Enable the cookies in Jmeter user.properties file in bin folder by adding "CookieManager.save.cookies=true" at the end of the file.
3. Run JMeter GUI and open the jmeter_testplan.jmx file.
4. Update the required parameters in the Test Plan User Defined Variables such as urlFrontend, urlBackend, portFrontend and portBackend based on your environment setup and save the test plan.
5. You can also configure the user workload in Thread Group based on the requirement. By default, the test runs with one user(thread).
6. To run the performance test, Jmeter GUI is not recommended as it has its own overhead. You should run the tests from the Console using the command "jmeter -n –t jmeter_testplan.jmx -l testresults.jtl".

Things to be worked upon:

1. More performance test scenarios are to be added based on the requirements.
2. Adding Instructor scenario request gives response code 403 due to invalid CSRF token. Need some guidance for this issue to be resolved. This forbidden request does not allow us to move to load courses scenario.

[amrut-prabhu]

Hi @paramvir1994 , welcome to TEAMMATES :) Thanks for taking the time to make this contribution!

In the future, it would be good if you could indicate your interest as a comment in the issue before implementing the fix, as stated in our contributor process guide 😅

Here are some things that you should take note if you are still interested in working on this (if not, you can look at first timer issues too:

1. For TEAMMATES, we have decided to use the JMeter Java API + TestNG instead of .jmx files. So, all our tests exclusively use Java.

   The documentation for our Load and Performance (L&P) tests is here (it's a bit hidden as it has not been flushed out yet).

2. The issue [#9560] Add a Jmeter test plan to show the performance testing process #9561 mentioned to use Jmeter GUI for creation of test plan.

   My bad for this 😅 . I hadn't updated the PR description (we had made a lot of changes to the process workflow over the course of the PR). Further evidence for why it's best to leave a comment on an issue before implementing a fix.

3. Though issue Add a Jmeter test plan to show the performance testing process #9560 is still open now, it is because we need to complete the To-do checkboxes (which are mainly cleaning up, refactoring and minor improvements). We are currently tackling the To-dos in issue Add L&P tests for backend endpoints #9646. We can add more endpoints there if you want to work on one that is not listed yet

   You can refer to PRs [#9560] Add a Jmeter test plan to show the performance testing process #9561 and Add L&P tests for backend endpoints #9646 to get an idea of how we are using JMeter in this project, and what is expected in a PR.

I haven't gotten a chance to look at your work in this PR yet, but I'll take a look at it soon.

Let me know if you want any further clarifications :)

Edit: I looked at the .jmx file; it isn't quite what we're looking for. The main reason being that values are hardcoded, and there is a lot of repeated work (which should be abstracted out).

[paramvir1994]

Hi @amrut-prabhu ,

Thank you for your valuable comment. :)

Actually, I wasn't expecting anyone else to be working on this issue. Also, I didn't see any comments from anyone else so I assumed I should pick up the issue directly. My bad about that.

To clarify, while I was continuing working on this, I saw your commit and then I realized the whole process has been changed. Earlier, Jmeter GUI test plan creation was supposed to be done when I just started working on it. Hence, I believe the work I did is invaluable for the project now.

Regarding the Jmeter test plan that I worked upon, I had hardcoded the values that are static such as URL webpage address(for example- /web/admin/home). All the dynamic values that can impact the whole script are abstracted out (for example- hostname, port number). Also, I implemented the capturing of CSRF token dynamically using Regular Expression Extractor.

Being a newbie in Jmeter, I was in learning mode and tried to implement it in an efficient way. Well, now the process is changed and I would love to further contribute using Jmeter API and TestNG.

If you have anything specific regarding the change in the Jmeter Script I provided, please let me know and I will update the script accordingly.

[amrut-prabhu]

@paramvir1994 Apologies for the delayed response.

I had hardcoded the values that are static such as URL webpage address(for example- /web/admin/home). All the dynamic values that can impact the whole script are abstracted out (for example- hostname, port number).

There are other dynamic values to be considered like logged in user, name of the course, feedback session etc. Take a look at the process followed in the 2 tests that we have right now- InstructorStudentEnrollmentLNPTest and StudentProfileLNPTest (keep an eye on #9652 too).
For student profile, for example, instead of having 1 user continuously making requests to the same API endpoint, we have multiple users simultaneously logged in who access the endpoint. This more closely matches real world behaviour. And, it will allow us to do spike testing in the near future.

Honestly, since you do not have much experience with JMeter, and since this L&P project is still in its infancy stage, I think that it would be best if you try working on some other issues first.

If you still want to work on this, you can take up one of the tasks in #9646 (let us know first!), but do note that these are more difficult than the ones that have been completed. Or you can propose some other endpoint that you want to work on (like retrieving sessions for the sessions page) and justify why you think it would be performance issue prone.