Whether you are a new employee in a company or new to the team, the processes and procedures followed in a company are always new and tough initially. The ease of adherence to any process or guideline is not easy when you start with it though it becomes a routine part of the life after a period of practice. But this initial period is the most difficult part of being a starter and learning to cope up with it is an integral part of improving your productivity and efficiency.
What are processes?
Processes are standard guidelines or workflows that are defined for the execution of certain functionality or for addressing certain issues. Every team or organization comprises of processes that will help them provide services and solutions of high quality and standards.
What is a Process Walkthrough?
Process Walkthrough is the activity by which a member of a team or an organization is provided knowledge on the processes and regulations crucial to the working of the team or organization. This helps in easy identification of the workflow and processes involved in the organization for the starter. Normally leads and managers of a team or project have a prior prepared plan for starters who join the team about the processes and procedures available.
Why is it necessary to understand the processes of an organization?
A process defines the way an organization works towards achieving its goals and visions. When proper adherence to the process is not done, it leads to loopholes and reduction in quality. This will not only bring down the level of customer satisfaction but will also de-motivate the employee and will further degrade his work. This is the main reason which calls for high importance to understand the processes of a company and to follow them as per guidelines.
Knowledge about processes is also important so as to support the project or the product development at times of crisis. For example, in the absence of a key resource, the need to fix a production bug will not be possible unless the other team member understands the procedures from the process documentation. These reasons state the necessity for starters to understand the processes and guidelines of their team or organization.
How to get acquainted with the processes
Understanding and getting acquainted with a process is a series of 5 steps that needs to be done with utmost care so as to make sure that there are no hiccups with the process implementation in future.
Step 1:Start with taking out time to understand the goals and visions of your organization. Most of the time, the processes revolve around the organizational views and goals. Hence understanding these would help in easy understanding of the process.
Step 2:Talk to senior members or leaders who are well aware of the process and try to get an idea around the process implementation. A short background and reasoning about the process will be of use when you learn about the process.
Step 3:Acquire documents and business case studies that relate to the process so as to learn the details completely. Learning processes through available case studies and recorded interviews will help in knowing the exact reason for which it was made.
Step 4:Analyze related data and measures that add value to your understanding of the process. Such kind of data can be extracted from previous implementation experiences of the process. In cases where the process has not been used yet, you can check out for sample data that was created during the process formulation.
Step 5:Analysis of data on the key measures will also help you to assess the stability and capability of the process. The assessed stability and process capability can be used to figure out any exceptional causes or situations that have been designed for the process.
Process understanding will no longer be a tough job as you have understood the need for a process walk through and the ways in which it can be done even if you are a starter.
This article start with brief introduction to Performance Testing
PERFORMANCE TESTING
Performance Testing is the process by which software is tested and tuned with the intent of realizing the required performance.
Test the behavior of an application with different Vusers load on the server.
Objective
The primary objective of the performance test is to identifying the “bottlenecks” of an application.
The top-down, meaning the transaction time take to submit a request and having it responded on the user's machine. This is a business perspective where they just want to know how the application is responding. The user do not want to know how many Hits/sec or Throughput but just want to know how much time was taken for a transaction (therefore the terminology of "transcation" must be aligned with you and the user).
The bottom-up, is a techincal perspective as you had pointed out such as the ASP.NET transactions or the database transactions (or commits). This is usually a persepctive from a technical manager so they can configure the system accordingly (or whatever they are going to do their system).
Hopefully the above is helpful in understandin your users/clients a little bit more before giving them a satisfying answer.
Bottleneck
It’s a breakpoint where the performance of an application is down or it’s a point where the environment fails to respond the users request.
Load Testing versus Performance Testing
My Simplified Definitions
Performance Testing = how fast is the system?
Load Testing = how much volume can the system process?
Performance testing seems to me to be much more broad than load testing. Consider:
A web developer can test the speed at which a page renders in a browser, and that is testing performance. Yet, that test would have nothing to do with load.
I might analyze the efficiency at which my database processes a single specific SQL query, and the resulting speed of delivery of the records can be the slowest component of the whole page building process. Measuring that speed is about performance, but only one transaction is involved (small load).
Load testing is usually focused on metrics like requests per second and concurrent users (the cause); whereas performance testing is more concerned with response times (the effect).
Testing for performance, part 1: Assess the problem space
Imagine you're a competent programmer who has worked with a number of different clients in many different technologies and who has just been assigned to your first project as a performance tester. To complicate matters, the technology involved happens to be fairly complicated and unfamiliar to you; this is not a project similar to one in your portfolio.
Testing for performance, part 2: Build out the test assets
Stage the environments, identify data, building out the scripts and calibrate your tests
As we look at the various environments, tools, data and scripts we use to build our tests, we will try to tie those artifacts back to the work that we did in the first article when we assessed the problem space. Often, as we build out the test assets, our understanding of the problem space changes, becoming more (or sometimes less) detailed, and often we are required to reconsider some of the decisions we made before we got down into the details.
Testing for performance, part 3: Provide information
In this article we look at some of the last heuristics: execute, analyse, and report:
Execute: Continually validate the tests and environment, running new tests and archiving all of the data associated with test execution
Analyze: Look at test results and collected data to determine requirement compliance, track trends, detect bottlenecks, or evaluate the effectiveness of tuning efforts
Report: Provide clear and intuitive reports for the intended audience so that critical performance issues get resolved
Performance Testing some other way to explain:
Think of performance testing as another tool in your testing arsenal - something you will do when you need to. It explores several system qualities, that can be simplified to:
Speed - does the system respond quickly enough
Capacity - is the infrastructure sized adequately
Scalability - can the system grow to handle future volumes
Stability - does the system behave correctly under load
Simple & Effective Performance Tips
Your end users complain that your Web pages load slowly and they don't intend to wait! So you need to dust off your system topology diagram and understand which servers user traffic travels. Then you need to determine if CPUs are busy on these systems, if they are busy (i.e., above 85%), you need to track down which process is using the CPU cycles; if CPU seems fine (i.e., under 85%), then ask yourself if memory is running out? If your system is memory-bound, you could be paging to disks - disk I/O is a performance killer. If memory is the issue, find out which process(es) are hogging memory - and they could be abusing memory too (e.g., memory leak, or loading large Word files into memory for processing); if your systems have pletty of free memory, then you need to check if your disk I/O is high. If disk I/O is high, you need to find out which process or thread is writing to and reading from the disk! Finally, if all the above checked out fine, ask yourself, if network bandwidth is maxed out: traffic is so high that responses from your Web site simply cannot push through the thin network "pipe". But ask yourself, is your application supposed to push that much data?
Web Performance Bottlenecks
Identify common website performance bottlenecks:
Source (what component they occur on)
Symptom (how you know there’s a problem)
Causes (what creates the problem)
Measurements (how to nail it)
Cures (how to make it go away)
Web Performance Tuning
There are several good posts about why people should tune their apps. Lots of other good places to find info on HOW to tune. Web performance tuning does a great job of using case studies and research by the big companies to prove the correlation between web performance and profit. It's obvious - slow pages make users go away; thus, revenue is lost.
Top Ten Web Performance Tuning Tips by Patrick Killelea, author of Web Performance Tuning is a good read for ideas. Patrick rightly points out that too many times performance testing is overlooked.
Java Performance Tuning Tips has a large number of tips categorized by topics such as JDBC, JMS, EJB, Application Servers, J2EE, J2ME, etc.
Apache Performance Tuning has suggestions on improving performance of the web server. It provides advice on run-time configuration issues, avoidance of swapping, and compile-time configuration issues.
LOADRUNNER
Load and performance testing enable web developers to know how their applications respond under heavy volumes of HTTP traffic. Load Runner is a load testing tool that puts massive cloud resources in the hands of web developers. Create your own test plans, and generate up to 50,000 concurrent users in realistic scenarios. Virtual users can login to your application using your own test users or purchase products with your test credit cards. Use random linking to get broad coverage of traffic patterns.
Why should you automate performance testing, What are the LoadRunner components, LoadRunner Terminology and Load Testing Process.
Why should you automate performance testing?
A well-constructed performance test answers questions such as:
·Does the application respond quickly enough for the intended users?
·Will the application handle the expected user load and beyond?
·Will the application handle the number of transactions required by the business?
·Is the application stable under expected and unexpected user loads?
By answering these questions, automated performance testing quantifies the impact of a change in business terms. This in turn makes clear the risks of deployment. An effective automated performance testing process helps you to make more informed release decisions, and prevents system downtime and availability problems.
What are the LoadRunner components?
LoadRunner contains the following components:
·The Virtual User Generator captures end-user business processes and creates an automated performance testing script, also known as a virtual user script.
·The Controller organizes, drives, manages, and monitors the load test.
·The Load Generators create the load by running virtual users.
·The Analysis helps you view, dissect, and compare the performance results.
·The Launcher provides a single point of access for all of the LoadRunner components.
LoadRunner Terminology
A scenario is a file that defines the events that occur during each testing session, based on performance requirements.
In the scenario, LoadRunner replaces human users with virtual users or Vusers. Vusers emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of Vusers. The actions that a Vuser performs during the scenario are described in a Vuser script. To measure the performance of the server, you define transactions. A transaction represents end-user business processes that you are interested in measuring.
Load Testing Process
Load testing typically consists of five phases: planning, script creation, scenario definition, scenario execution, and results analysis.
Plan Load Test: Define your performance testing requirements, for example, number of concurrent users, typical business processes and required response times.
Create Vuser Scripts: Capture the end-user activities into automated scripts.
Scenario Creation: Use the LoadRunner Controller to set up the load test environment.
Scenario Execution: Drive, manage, and monitor the load test from the LoadRunner Controller.
Analyze the Results: Use LoadRunner Analysis to create graphs and reports, and evaluate the performance.
The LoadRunner Solution
Overcomes resource limitations by creating Vusers. There is no limitation on the number of Vusers created ( except if you do not have the license)
Vusers are run on fewer machines than required for manual testing. One Load Generated is good enough to create 1000 Vusers.
It provides controller to manage Vusers during the test.
Allows repeatable tests with scripted actions.
Provides meaningful results.
Conclusion:
Load Runner has good reporting features with which the user can easily analyze the performance test results.
HP-LoadRunner Components
1)VuGen (Virtual User Generator)
2)LoadRunner Controller
3)LoadRunner Analysis
VuGen:
Example: VuGen code view
Developing Vuser Scripts
Walkthrough the scenario to be scripted.
Record the scenario.
Edit or enhance the scripts.
Configure the runtime settings.
Run the vuser script.
Re-enhance and re-run till working properly.
Incorporate the script into LR scenario.
Scripting
Mainly ‘C’ programming language based.
Able to incorporate C looping structure (for, if, while…)
Can also use Java, JavaScript, VB, VBScript
Scripting Enhancements
Transactions
Parameterization
Rendezvous Point
Think Time
Defining User Behavior
Recoding Options
Recording
Browser
Recording proxy
Advanced correlation
Runtime Settings
General
Network
Browser
Internet Protocol
Protocol Advisor
a.Ajax (Click & Script)
b.Web Services
c.Web (HTTP/HTML)
Record into Action
a. Vuser_init
b. Action
c. Vuser_end
Recording Options
Script
Recording Modes
HTML Recording Mode Script
URL Recording Mode Script
Differences between HTML and URL Recording Mode Scripts
1.
HTML-It generates the web vuser functions for every user action
URL- It generates the separate web url functions for each object on the web
2.
HTML- It captures a one web function for each user html request.
URL- It captures a one web for each non html resources (jpg,gif,css,js) on the web page.
HTML- For all the non html resources it captures in EXTRARES
URL- For all the non html resources it captures in separate WEB_URL functions
Advantages in HTML Script
It takes less time to user access as it has less no. of code.
Disadvantagein HTML Script
It may not download the entire source of the web page.
Advantage in URL Script
It downloads the complete source of the web page
Disadvantage in URL Script
It takes more time to execute the user actions.
FUNCTIONS
HTML Functions
Web_url()
Web_submit_data()
Web_submit_form
Web_link()
Web_image()
URL Functions
Web_url()
Web_submit_data()
Web_concurrent_start()
Web_concurrent_end()
PARAMETERIZATION
To pass the different set of user inputs instead of hard coded values in the script.
Point to note that parameterization may result in data dependency which the tester should be aware of and handle it appropriately. Every load test should at least require parameterization. Parameterization includes passing different types of data into the application to emulate the real world users performing/entering different values.
What do clients want to achieve from parameterization?
1. To test different data
2. Just to load/emulate the data
Parameterization requires identifying with the clients which areas required data input. This will be useful when discussing in the Application Design. From there, they can prepare the data from the database
which is a more efficient method.
Preparing the data
Usually after walking through the application, I will request the client to prepare the date via the database and export it out as an excel file. This will reduce the time in preparing lengthy excel or notepad files. From there, you can manipulate the data easily in either Excel or OpenOffice.org. After I’ve amended the files properly, I will save it as a .dat file and placed it in a shared folder for my scripts to access.
Once converted into .dat file, ensure that they have been delimited properly with the commas. Take note that Vugen allows different delimiters in the Parameter List.
The usual items to parameterize are username, password, dates, etc but not limited to the mentioned. However, there are also hidden values that are stored in web pages (e.g. in the form of AJAX) or HTML codes (e.g. hard-coded hidden input) which are captured by Vugen. As such, I will point it out to the clients and request them to prepare the data for me.
Having said that, it’s best to define what is correlation and parameterization or you may end up spending effort in the wrong track.
Placement of the Parameter file
When you created a parameter for each script, by default, it’s stored in the root of the script folder. That is, if you save the script as test_script.usr in C:\, the parameter file will be saved in C:\test_script. For every script that has a parameter, it will be saved in its individual script folder. This way is good for a single script but when multiple scripts using the same parameter file is involved in the load test, it will be advisable to centralize the parameter file.
What I do when I’ve prepared the data files is that I will place them in a central repository (folder) where all my scripts will access. This is tidier and provides a way of ensuring consistency of the parameter used for all scripts.
Why parameterize different data?
Why is there different effect on different data? A simple example is uploading of different sizes of files. If parameter A is uploading 2MB of file while parameter B is uploading 4MB of file, it will definitely generate a higher throughput on the latter parameter. This may be a concern of the client.
Another example is querying different items in a database. Parameter A may query and return a smaller result while parameter B returns a bigger result causing a higher throughput.
Not the Obvious Data Dependency
Point to note that parameterization may result in data dependency which the tester should be aware of and handle it appropriately.
Examples are username and password submission: A username login will require a valid password. This may seemed obvious for this situation. However, as pointed earlier about the hidden input, you will have to be cautious on it. As Vugen records whatever is been transmitted to the server, the hidden input are recorded as well. Therefore, you will need to check back with the application developers to find out more about the hidden values associated with each parameter value. If possible, request them to provide a list of the values in Excel file format for you to manipulate.
Which Settings are correct?
Parameterization settings vary depending on your applications. You may like to sequential it or randomize it. Ensure the settings are correct. Usually I defined them as unique.
Testing the data
There is various ways to test if the parameters are correct. You can perform the following:
1. Replay the script in Vugen with one iteration
2. Replay the script in Vugen with three iterations.
3. Replay the script in Controller with one Vuser.
4. Replay the script in Controller with three Vusers.
These will be sufficient to test out the validity of the parameters used. You can also defined at which point the parameter values are been used by defining the starting row to retrieve data.
CORRELATION FUNCTION
It captures the server generated values which are matching between the given left and right boundaries.
Parameter name: It captures the values in an array which are matching between the given length left and right boundaries.
LB: It’s a left boundary of correlated value.
RB: It’s a right boundary of correlated value.
ORD: It contains ordinal value. It defines a position are the occurrence of correlated value between the given boundaries.
Example:
ord =1:It captures the first position value between the given boundaries.
ord = 2: It captures the second position value between the given boundaries.
ord = all: It captures the all position value between the given the left and right boundaries.
Random behaviors:
Use the below types of randomization functions to select random values from server generate list.
Use the below function to select any one of the random value from available array list.
lr_paramarr_random(“links”);
Note: Links is parameter name defined by user in correlation
Example:
Assume that the array length is 20 then we can select a random value between 1 to 20.
Use the below functions to select the last array value always.
i=lr_paramarr_len(“links”);
Note: To calculate the length of the array (last value of the array)
lr_paramarr_idx(“links”,i);
Use the below function to select a random value with in the range (between the given range);
i=atoi(lr_eval_string(“{rparam}”);
lr_paramarr_idx(“links”,i);
Note: rparam is a random parameter type.
Use the below functions to select a sequential array for each iteration.
i=atoi(lr_eval_string(“iteration_number”);
lr_paramarr_idx(“links”,i);
For all the kind of requirements we can generate a random number using rand()
Example:
To generate random values
1. Range between 1 to 10
i=rand() % 10+1
2. Range between 2 to 6
i=rand() % 4+2
i=atoi(lr_eval_string(“{links_count}”));
Dynamic boundaries:
When ever we observe the dynamic value in the boundary use the below two approaches
Text flag:
Use the text flag to handle the dynamic boundaries
A.Digits or numerics: when you observe the dynamic boundary values are digits or numerics replace with “ # “(ash) in each digit place and use the boundary arguments like LB/DIG or RB/DIG
B.Alfa numerics : when you observe the dynamic boundary values are alphanumeric replace with“ ^ “ and use the boundary arguments like LB/ALNUM or RB/ALNUM
Save length & Save off set
To handle the dynamic boundaries use the below two arguments in a correlation function
a.Savelen: Define the fixed length of the correlated value to save into the parameter name.
b.Saveoffset: Define the fixed length of characters which are dynamically changing in the left boundary.
Example:
input type =”hidden” name=”SKU0” value=”16544094” ID=”
Web_reg_save_param(“Oname”,
”LB= input type =\”hidden\” name=\”SKU”,
“RB=\””,
“ORD=all”,
“SaveLen=8”,
“Saveoffset=10”,
LAST);
Savelen=8: Its correlated value length (Value)
Saveoffset=10: It’s a dynamic character length in the boundary.
Note:
1. In the above example I observed the dynamic boundary as 0” value=” (with 10 character length)
2. To use savelen or saveoffset always correlated value length and dynamic boundary length should be constant.
NOTFOUND:
Use notfound argument to return the execution status
NOTFOUND = warning:
When ever the correlation function is unable to capture the value the data from the server source it makes it as a warning instead of error and proceed with the next step execution.
Note: By default this argument as NOTFOUND = error
