Testing 08/02/2022

HTML mode vs URL mode

  1. Context Dependency: HTML mode performs context-based recording whereas URL mode is free from context i.e. contextless recording. Since the resources are separated by individual request in URL mode, so there is no context dependency between them.
  2. Resources: In HTML mode, the page resources like image, .css etc. are recorded in a single request whereas individual requests are created for each resource in URL mode.
  3. User Action: In HTML mode, each user action belongs to one request whereas in URL mode, multiple requests associated with one user action depends on the number of resources available on the page.
  4. Script Size: The size of the HTML mode script is comparatively smaller than the size of the URL mode script. The reason is in URL mode script each resource has a separate request.
  5. Correlation Effort: HTML mode script requires less effort than URL mode script to correlate the dynamic value.
  6. Resource Download during replay: Resources are downloaded during replay in HTML mode. But in URL mode individual request triggers for each resource hence resource downloading is not required.
  7. Execution Speed: HTML mode script is slower than URL mode script due to parsing of code.
  8. Script Maintenance: The maintenance of the script is less in HTML mode. On the other hand, the URL mode script requires more maintenance and re-work due to changes in the application.
  9. Explicit support: HTML mode supports explicit URL whereas URL mode does not support explicit HTML.
  10. Used for: HTML mode is used for browser-based application whereas URL mode is used for non-browser (thick-client) application.
  11. Functions: In HTML mode, web_submit_form is used whereas in URL mode, web_submit_data, web_image etc. are used.

 

Difference between web_submit_form and web_submit_data in LoadRunner?

WEB_SUBMIT_FORM():

The web_submit_form function is an action function that submits a form. The
web_submit_form function may be executed only in the context of a previous
operation.

web_submit_form is recorded only when VuGen is in HTML-based recording mode
(see VuGen's Recording Options).

WEB_SUBMIT_DATA():

The web_submit_data function is a action function that performs an
"unconditional" or "contextless" form submission. It allows you to generate
GET and POST requests as made by the HTML forms. You don't need to have a
form context to execute this request.

web_submit_data is recorded only when VuGen is in either URL-based recording
mode, or in HTML-based recording mode with "A script containing explicit
URLs only" option checked (see VuGen's Recording Options).

Actually both comes under HTML based recording modes only

1) where is in web_submit_form it identifies post as a
perticuler part of the webpage
And it doesn't include the server generated data like
session ID. It includes only user i/p's that he entered
while filling the foem.

2) Where is in web_submit_data it identifies the post as
the whole web and sends the reqest .
And it includes userinputs as well as server generated
data .
And functions will be same in both and bit more functions
will come in web submit form like
a) web link and b)web submit form .



HTTP response status codes


200 OK

The request succeeded. The result meaning of "success" depends on the HTTP method:

  • GET: The resource has been fetched and transmitted in the message body.
  • HEAD: The representation headers are included in the response without any message body.
  • PUT or POST: The resource describing the result of the action is transmitted in the message body.
  • TRACE: The message body contains the request message as received by the server.
201 Created

The request succeeded, and a new resource was created as a result. This is typically the response sent after POST requests, or some PUT requests.

202 Accepted

The request has been received but not yet acted upon. It is noncommittal, since there is no way in HTTP to later send an asynchronous response indicating the outcome of the request. It is intended for cases where another process or server handles the request, or for batch processing.

203 Non-Authoritative Information

This response code means the returned metadata is not exactly the same as is available from the origin server, but is collected from a local or a third-party copy. This is mostly used for mirrors or backups of another resource. Except for that specific case, the 200 OK response is preferred to this status.

204 No Content

There is no content to send for this request, but the headers may be useful. The user agent may update its cached headers for this resource with the new ones.

205 Reset Content

Tells the user agent to reset the document which sent this request.

Redirection messages

300 Multiple Choice

The request has more than one possible response. The user agent or user should choose one of them. (There is no standardized way of choosing one of the responses, but HTML links to the possibilities are recommended so the user can pick.)

301 Moved Permanently

The URL of the requested resource has been changed permanently. The new URL is given in the response.

302 Found

This response code means that the URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.

303 See Other

The server sent this response to direct the client to get the requested resource at another URI with a GET request.

304 Not Modified

This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.


Client error responses


400 Bad Request

The server could not understand the request due to invalid syntax.

401 Unauthorized

Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.

402 Payment Required 

This response code is reserved for future use. The initial aim for creating this code was using it for digital payment systems, however this status code is used very rarely and no standard convention exists.

403 Forbidden

The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401 Unauthorized, the client's identity is known to the server.

404 Not Found

The server can not find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 Forbidden to hide the existence of a resource from an unauthorized client. This response code is probably the most well known due to its frequent occurrence on the web.

405 Method Not Allowed

The request method is known by the server but is not supported by the target resource. For example, an API may not allow calling DELETE to remove a resource.


Server error responses

500 Internal Server Error

The server has encountered a situation it does not know how to handle.

501 Not Implemented

The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD.

502 Bad Gateway

This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.

503 Service Unavailable

The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.

504 Gateway Timeout

This error response is given when the server is acting as a gateway and cannot get a response in time.


VUGen:-

just go to runtime setting -> run logic 

in this we would get number of iterations  and iteration means kitna time pura process ko repeat karvana haa



Pracing :- Time diffrence between itterations

1)as soon as possible

2) particular fixed time between two itteration

3)start new itteration means 

let's take usertake 20s time then 60s-20s = 40s 

after 40sec another itteration will start

Think time :- time taken by the user to fill the form 








































 

Comments

Popular posts from this blog

Git and Github

bubble short Q1

Java Program to Check Whether the String Consists of Special Characters