Hi Group Have few newbie questions on building effective load testing plan. I am working on building a load test plan for a server that backs mobile clients over REST APIs. We currently have one mobile client in production & we are launching a new redesigned client which is backed by different set of APIs. Goal of load testing is to assess whether production servers can take load generated by new clients. For some time there will be both new & old types of clients that will hit production servers.
I am reading users from csv file & in addition using the thread counts to generate load. I have created a basic test plan that contains all the APIs. The APIs can be broadly grouped into the following groups G1 - A set of APIs the old mobile app will call everytime it foregrounds. Though how many times this will happen is not known, the set of APIs that will get called is known. G2 - Old Client : Set of APIs old mobile app will call based on user action. This again depends on user action. Similar ly G3, G4 for new clients G3 - New Client: A set of APIs the new mobile app will call everytime it foregrounds. Though how many times this will happen is not known, the set of APIs that will get called is known. G4 - New Client : Set of APIs new mobile app will call based on user action. This again depends on user action. When I build the load test plan, should the different api calls be grouped per use case, or should they just be at some hypothetical high numbers? Should I even be paying attention to the fact that they are called by clients for different reasons? Example G1: A, B, C, P G2: P,Q,A,B G3: A,B,X,Y,Z G4: A,B.X >From here it is clear that A,B are called most frequently : 4 times more than Y,Z. How should this be reflected in test plan? Have 4 times number of samplers for A,B as compared to samplers for Y,Z? Can someone clarify how the ideal or at least acceptable test plan look like? Can someone share sample test plans that will answer my questions? I can explain further if something is not clear. Thank you for reading this far, appreciate your time! Shilpa
