Performance Engineers go through a set of manual tasks time and again. Be it for creating data for the load test, triggering of the test in a particular sequence / at a particular time or post processing of data collected after the test.
The general rule of thumb is – anything that takes more than 10 minutes and has to be done more than two times a week has to be automated. That is a minimum of 1040 minutes saved per year – 2 working days / year per person.
To achieve automation, although the world has come to Python & Scala for sophisticated solutions, quick and dirty Shell Scripts will never go out of style. I would not go for sophisticated / complex solutions, if the same can be attained in less than 20-lines of a quick Shell Script.
With that being said, this series of writings on Shell Scripts are basically my notes from different sources which I have collected over the period of time.
In this Part-1, let’s look at some basics Shell Scripts.
Note: This is not Shell Scripting-101. You might need to know real basics like giving permissions to shell script, how to run shell scripts etc.
User input and Validation
Lets say we are writing a shell script to create test data for Performance load testing. We don’t want to hard-code the environment details in to the script. We want to pass it as input-parameter.
- $1 – represents the first input variable passed along with the script at trigger.
- script run as ./scriptname.sh <envname> . Example: ./loadGeneration.sh staging
- Output: This test will run on staging setup.
#!/bin/bash
environment=$1
echo "This test will run on $environment setup."
- If user doesn’t enter environment name with the above script, you would want to stop him and notify him to do so.
- if statement below will make sure that the user enters the environment name.
- also pay attention to the “exit” in the if loop.
#!/bin/bash
environment=$1
if [[ "$environment" == "" ]]
then
echo "Please enter the environment name"
exit
fi
echo "This test will run on $environment setup."- The above example doesn’t scale if there are many input variables. If along with environment name, if you had to pass user count, test time etc, there will have to be an if condition for every input value check.
- Below is a better solution to tackle the same.
#!/bin/bash
environment=${1?Please enter the environment name.}
userCount=${2?Please enter the user load value.}
testTime=${3?Please enter Test Duration.}
echo "This test will run on $environment setup, with a user load of $userCount and for a duration of $testTime minutes."
- Above script can be made further more usable like :
#!/bin/bash
usage="Run the script as - ./loadGeneration.sh <envName> <userLoad> <testDurationInMins>"
environment=${1?$usage}
userCount=${2?$usage}
testTime=${3?$usage}
echo "This test will run on $environment setup, with a user load of $userCount and for a duration of $testTime minutes."
- We can also have the default values for arguments, like below.
- Pay attention the variable – testTime
- In the below case even if the third values is not passed while execution, it takes a default value of 60. Example: ./loadGeneration.sh staging 100
#!/bin/bash
usage="Run the script as - ./loadGeneration.sh <envName> <userLoad> <testDurationInMins>"
environment=${1?$usage}
userCount=${2?$usage}
testTime=${3:-60}
echo "This test will run on $environment setup, with a user load of $userCount and for a duration of $testTime minutes."- To output all the input variable sent to the script use – $@
- To output the number of variable to a script (count) use – $#
- To output the return code use – $?
#!/bin/bash
usage="Run the script as - ./loadGeneration.sh <envName> <userLoad> <testDurationInMins>"
environment=${1?$usage}
userCount=${2?$usage}
testTime=${3:-60}
#this outputs all the input parameters
echo $@
#this output the number of input parameters (count)
echo $#
#to get the return code of a section.
echo $?Side notes :
- Do not leave any space across the = sign while assigning the variables.
Next :
- In the Part-2 , we will look in to if-statements, loops and arrays!
Engineering Blog 