1
votes

First let me preface this with 1) I'm not a developer by nature, and 2) I've only been using JMeter for less than 1 month.

I am performing basic CRUD testing of our APIs to/from our database. Due to a table constraint, each record in the table under test must have a unique typeId and groupId where the typeId/groupId combination is pre-defined elsewhere.

I need to perform the following upon a basic Create:

Path: /.../.../.../crud/QualificationExpression Method: POST

{
    "id": null,
    "displayName": "crudTest: ${__Random(1,10000000, randomNumber)}",
    "functionName": null,
    "displayableSourceExpression": "TRUE",
    "clobObjId": null,
    "typeId": xxx,
    "groupId": yyy,
    "typeCode": null
}

I'm trying to figure out what is the best way to do this:

  • CSV file
  • Array
  • Array List

Searching the forums and other online resources, when people use a CSV they're typically using it to store username|passwords for random logins. This results in them using Parameters instead of a Post Body.

The Array examples all seem to contain a single column array where they pull a random value from within the array. However, I have a pair: if typeId = x, then objectId must = y.

Then I see an Array List sample where I'm totally confused:

ArrayList listOfPairs = new ArrayList();
    ArrayList pair1 = new ArrayList();
       pair1.add(203);
       pair1.add(303);
       listOfPairs.add(pair1);
    ArrayList pair2 = new ArrayList();
       pair2.add(204);
       pair2.add(304);
       listOfPairs.add(pair2);
    ArrayList pair3 = new ArrayList();
       pair3.add(205);
       pair3.add(305);
       listOfPairs.add(pair3);

    for (int i = 0; i < listOfPairs.size(); i++) {
        ArrayList pair = (ArrayList)listOfPairs.get(i);
        System.out.println("pair:" + pair.get(0) + " " + pair.get(1));
    }

My desire would be to not have a CSV file and it would be best to have the test plan .jmx be stand-alone without relying on "payload" files being present.

I'm hoping those with more experience and knowledge could provide some guidance and insight.

2

2 Answers

2
votes

Go for Functions, from performance perspective it's better to use built-in components where possible.

If you:

  • need to have pre-defined (not random) typeId and groupId combination - you need to keep these pairs somewhere
  • don't want external files - you need to store these files in Test Plan itself, i.e. in User Defined Variables
  • need typeId and groupId pairs to be unique - the most obvious solution is using current virtual user number as prefix or postfix like:

    • in User Defined Variables:

      User Defined Variables

    • in Request Body use __threadNum() and __V() functions combination like:

      "typeId": "${__V(typeId_${__threadNum})}",
      "groupId": "${__V(groupId_${__threadNum})}",
      
  • plan to run test for several iterations - use __counter() function as an extra postfix

See How to Use JMeter Functions articles series for comprehensive information on above and other JMeter functions.

2
votes

Your requirement is almost like the one in this post.

When you send the same HTTP request again and again - just by changing different parameters, in your case type id and group id - definitely using CSV data set config is a very good choice or JDBC Request if it is in the DB. I do not understand why you do not like CSV file approach. If I were you, I would try to keep the data completely away from the test script. It would be very easy to maintain in future.

Lets say you are using arraylist (Why arraylist? You mean Map?)! Suddenly, If you need to run your test for a new set of 1000 type id and group ids, Will you be updating the script to add those id in the Array or Map? If you use CSV data set config, just change the file path to point to new CSV. That's it. You are good!

Do not add the complexity in the testplan by including beanshell/other samplers to create test data etc. Keep the testplan very simple. JMeter's work should be simple - send the request and get the response. It should not be spending time in creating test data.