I am first time using gatling and I am stack with such task
I need to provide working code of the following scenarios: dont know how to describe logging in/out
Basic flow: user1 is login in > continue to landing page > navigating through pages
Flow2 : user2 which is already logged in is downloading some pages
Flow 3: user1 and user2 are logging in and out for about 500 time each during 10 minutes.
You can use "Scenarios" and "Chain" them.
Each flow you are mentioning will become a scenario.
To give you a hint:
Start with defining User Requests: for e.x.: Login, Logout, Go To Landing Page, Navigate Some Pages, Download Something etc.
val loginRequest = exec(http("Login").get(...))
Then define Scenario like:
val basicFlow = scenario("My basic flow").exec(loginRequest).exec(browseRequest).exec(logout)
val flow2 = scenario("My 2nd Flow").exec(loginRequest).exec(browseRequest).exec(downloadRequest).exec(logout)
Then you can chain your scenarios in Simulation/setUp like:
setUp(basicFlow(injectAtOnce(1)), flow2(rampUsers(20) over (3 minutes))
You can then improve the load (setUp method), loop your requests etc.
The Gatling Documentation is a good place to start. The following pages will help elaborate more on what I explained briefly above:
More about Scenarios and Control flows like repeat etc.
Simulation and Load setup
If all this seems overwhelming, I would suggest start your record your individual scenarios and then refactor the generated code.
Once you are familiar with the concepts, you can try their helpful Cheatsheet
Edit#1
Gatling has restructured their documentation, updated the links. Please note that the code is as of Gatling 2.0.3, current version is 2.3, so it might not work out of the box, but the concept remains the same.
Related
I'm new to Gherking and trying to write my first scenarios as best as I can, but I regularly find myself in situations where I'm really tempted to add an "Else" to my scenario. "Given, When, Then" becomes "Given, When, Then, Else". I know that the "Else" keyword is not defined and so not implemented in Gherkin tools but it doesn't care to me because I don't use these tools.
Do you think it is correct to write this :
Example :
Scenario : Application starts
Given I start the application
When I already have an open session
Then I see the home screen
Else I see the login screen
Or is it better to write two different scenarios :
Scenario : Application started by authenticated user
Given I have an open session
When I start the application
Then I see the home screen
Scenario : Application started by unauthenticated user
Given I don't have an open session
When I start the application
Then I see the login screen
In short no, but here are options to handle multiple variants of a scenario:
If it was only tailing elements of the scenario steps that differed you could of moved early steps in to a common 'Background' section, making repeated differing scenarios shorter and clearer.
But from your example it is all steps differing slightly so you can:-
accept the repitition of multiple scenarios
Or
parametise the differences and use data tables in the 'given' and 'then' sections to give before and after values.
Or (my prefernece)
Use the 'scenario outline' syntax that uses an examples table to provide sets of data fixtures with their expected results. These replace in the scenario steps as runtime. The scenario is then 'played out' once for each row in the examples table.
So:
Scenario : Application started by authenticated user
Given I have an open session
When I start the application
Then I see the home screen
Scenario : Application started by unauthenticated user
Given I don't have an open session
When I start the application
Then I see the login screen
Becomes:
Scenario Outline: Application Start and login
Given Application started by <AuthenticationStatus> user
And I have <SessionState> session
When I start the application
Then I see the <FirstScreen> screen
Examples:
|AuthenticationStatus |SessionState |FirstScreen|
|Authenticated |open |home |
|Un-Authenticated |not open |login |
IMHO for 2 scenarios it might not be worth the loss of readabiltiy but for more than that I think it's definitely worth it.
Let's say I use Background feature which has the below steps:
Background: My pre-requisites
Given Step one
When Step Two
Then Step Three
....
Then Step Fifteen
So basically my Background has 15 common steps that is required for a set of scenario to run.
My question is : Is it possible to use the Background title My pre-requisites in other feature files, instead of writing down all the 15 steps as Background? Or is there any other way to handle this more gracefully.
You can create a before hook to code the background logic and reuse it across any feature file. Even tag the hook so u can filter out scenarios where u do not want the before hook to run.
Alongside the existing answer, you could also write a new step that compresses the functionality of the 15 steps into one or two steps that express what you are setting up.
The questions revolving around it are these:
Does the business need to know how the user will interact with the site to get to the point where you are ready to begin the test?
Can you bypass how the user will interact with the site to get there without information surrounding the test getting lost in translation between the dev team and the business?
For the former, I would go with a Background. The latter, I would go with a Hook.
For example:
I need to register a user in order to log in as them in my test. The Givens will start at me logging in, so I'll register the user through an API in a Hook.
I need to register a user in order to test the functionality of a new user on exiting the form, and various items surrounding registration, so I'll register the user, starting with some Background steps.
This is my first more "complex" SpecFlow scenario written in Gherkin. Please provide me any feedback about it's quality:
Scenario: CompanyUpload
Given admin (user) log in to admin-site
When user enters Uploading page
And user downloads Company Upload template
And template is updated by script
And user opens Company upload form
And user fills it with proper data
And user submit filled form
Then new job should be added to the queue (visible in table form)
And job status should be "In Queue" for not longer than 10 minutes
And job status should be updated to "Processing" and shouldn't take more than 4 minutes
And final job status should be "Succeeded"
This scenario is already coded with Selenium Webdriver actions. Now, I would like to cover it with SpecFlow to create acceptance tests library.
Features should focus on behavior not on implementation. So putting incidental detail in your features is not a good idea. In your example I'd say that your when steps are somewhat fragmented. Instead using 6 when steps to describe how the user uploads something, use one or two to describe what the user does. For instance.
When user uploads document using company upload template
Something like this describes the necessary detail but not more than that.
Using Chimp.js, Cucumberjs and WebdriverIO, I'm trying to run login step definitions in a browser instance, before other step definitions that depend on a user to be logged in. And possibly without adding them into the Background over and over again for each feature file.
Is this possible? I'm quite new to Wedbdriver.io and Cucumber and any advice would be a great help. Please let me know if more info is needed.
Personally I don't think this is a good idea. To log someone in you have to specify 'who' the user is. Later when your application becomes more complex you might have interactions between different users. Hiding any of this from the scenario is not good.
What you can do is combine user specification and login in single steps e.g.
Given I am logged in as an admin
Given Fred is logged in as a sales executive
etc.
If you are clever about how you implement these steps you can keep things fairly dry by extracting helper methods from the step definitions and using global variables to store people e.g.
Given 'I am logged in as an admin' do
#i = create_user role: admin
login as: admin, user: #i
and reuse these methods in other login steps.
If you organise your features well, you can background alot of these calls e.g.
Feature: Basic admin ops
Background:
Given I am logged in as an admin
Scenario: I can foo
When I foo
Scenario: I can bar
When I bar
Some final thoughts ...
Each scenario is there to drive a particular piece of development. Compared to the work of doing the development writing "Given I am logged in" is trivial.
When something goes wrong knowing that you were supposed to be logged in is an essential piece of information.
I'm a newbie to jMeter, so please bear with me.
I've been assigned the task of testing how an e-commerce website responds under load. I've managed to set up basic tests in jMeter that basically just repeatedly visit the home page, but I'd like to simulate something a bit more realistic:
User arrives on home page
User goes to catalogue page
User views product
User adds product to cart
User returns to catalogue, selects another product, adds to cart
User removes first product from cart
User proceeds to checkout
User completes checkout process.
I'm having trouble finding adequate documentation to explain how to do this. I figured out that I need a cookie manager in my test so that the user session will be maintained, but I haven't figured out how to get the user to traverse the site in a realistic use pattern (such as the one described above). Can anyone help out with this, give me some pointers as where to look for good examples, etc?
This should be no problem, record or manually create the necessary steps as HTTP Samplers, then add them into a Runtime Controller for example to execute them iteratively.
The individual steps will be executed in the order they are in the tree and, in case Cookies are used to handle session state, you might need to add the Cookie Manager to the top of the tree which will handle cookie headers for each user.
Add some timers to simulate user's think time and scale up by increasing the number of virtual users in the thread group.
Use some listener like the Aggregate Report to view the response times for every step.
Try to read http://jmeter.apache.org/usermanual/index.html at first.
Also you'll encounter the problem that Jmeter can't process dynamic pages:
http://wiki.apache.org/jmeter/JMeterFAQ#Does_JMeter_process_dynamic_pages_.28e.g._Javascript_and_applets.29
Does JMeter process dynamic pages (e.g. Javascript and applets)?
No. JMeter does not process Javascript or applets embedded in HTML pages.
JMeter can download the relevant resources (some embedded resources are downloaded automatically if the correct options are set), but it does not process the HTML and execute any Javascript functions.
If the page uses Javascript to build up a URL or submit a form, you can use the Proxy Recording facility to create the necessary sampler. If this is not possible, then manual inspection of the code may be needed to determine what the Javascript is doing.