Web Based Application Architecture & Objectives.

Web application is an application that is accessed by users over a network such as the Internet or an intranet. The term may also mean a computer software application that is coded in a browser-supported language (such as JavaScript, combined with a browser-rendered markup language like HTML) and reliant on a common web browser to render the application executable.

Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions.

 The application which runs based up on the web server is called web based application

Objectives:

1) Response time

2) Servers behavior

3) Network bandwidth

4) Vusers load

Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

Performance Goals & Objectives.

The primary objective of performance testing test is to measure the response time of each user action.

Speed – Determines whether the application responds quickly

Scalability – Determines maximum user load the software application can handle.

Stability – Determines if the application is stable under varying loads

Performance testing can serve different purposes.

 It can demonstrate that the system meets performance criteria.

 It can compare two systems to find which performs better.

     Or it can measure what parts of the system or workload causes the system to perform         badly.

Why do Performance testing?

Performance testing is done to provide stakeholders with information about their application regarding speed, stability and scalability. More importantly, performance testing uncovers what needs to be improved before the product goes to market. Without performance testing, software is likely to suffer from issues such as: running slow while several users use it simultaneously, inconsistencies across different operating systems and poor usability. Performance testing will determine whether or not their software meets speed, scalability and stability requirements under expected workloads. Applications sent to market with poor performance metrics due to nonexistent or poor performance testing are likely to gain a bad reputation and fail to meet expected sales goals. Also, mission critical applications like space launch programs or life saving medical equipments should be performance tested to ensure that they run for a long period of time without deviations

What is Performance testing?

In software engineering, performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.

Performance testing is a subset of performance engineering, an emerging computer science practice which strives to build performance into the implementation, design and architecture of a system

Software Development Life cycle

Performance Testing life cycle

Performance Questionnaires

The following are the basic set of requirements for performance testing of any application:

A. Application Questionnaire

1.      Description of the Application, various modules (if application is structured in a modular fashion), its functionalities, etc. The points to be covered are: -

• General Description, Functional flow of the application.
• System Architecture  (Communication flow)
• Interface Description (if the system architecture involves interfacing to other subsystems) 
1. Technical architecture of application under test with various technologies involved in the design of the application and other subsystems.

3.      Various protocols (ex: web, Siebel, oracle ..etc) supported (any specific proprietary protocols, if expected to be supported should be

4. If the application has been developed provide the URL of an environment close to the production environment on which tests could be performed.
5. Platforms/OS/Database supported/recommended for the product/application.
6. List of frequently used functionalities in the application/system/product.
7. List of business critical functionalities in the application/system/.
8. Workload Model for the application system

(This involves the description of the usage of various functionalities/modules of the application/system/product in the production or real environment. More particularly, the number of users using various functionalities or modules of the application/system in a day or over a period of time) what are the various profiles and their frequency of activities on the site? Also provide the peak load that can be expected from each user profile and the duration for which the peak load is to be maintained. 

9.      Whether the SLA’s have been defined? Please provide the SLA’s details

10.  What is the maximum concurrent users using the site? 

11.  What is the maximum load that you want to generate on the system? 

12.  If the application is already in production what is the user profile (Peak hour load, Normal hour load).

13. Are there any monitoring over firewalls and /or remote load generator builds
14. Please mention details of monitoring, e.g. oracle and web/app servers 
15. Any benchmark available for the performance of the application functions or subsystems 
16. Baseline details (Client expectations) 

B. Engagement Questionnaire:

 Tentative Start Date of the Project

A.    Planned Completion Date of the Project 

C. Tool Questionnaire:

A.    Does the client has licensed tool for performance testing, If yes please provide the details of the tool.

B.     If the Client has license for Load runner tool, are Load Generators placed at different regions?

(To simulate real time load)

C.     Does client has remote desktop software so that users can access the machines located at?

D. Resources Questionnaire: 

A.    Does the client will provide DBA support/Infra/Dev/Web admin during the execution of Load test?

B.     Number of Resources required at Onsite and Offshore.

D.    Define Pass / Fail Criteria (What is acceptable performance parameter)

F. Contacts for Issues and escalations:

     (Infra team, Database team, Dev team, Web admin team)

G. Comments (If Any)