What am I working on?
Getting machine information is vital before the actual testing commences. This includes retrieving the Release and Version of the OS, the Architecture of OS, Kernel version, Processor type, Machine Name, etc. To fetch all this information, command uname is used with appropriate switches. Although the basic switches like m: Machine Hardware, n: Nodename, r: Release level remains the same, different OS have some more switches in addition. Listing 3 will explain the output of uname along with some switches.
Listing 3: uname output
$ uname
SunOS
$ uname -m
sun4u
$ uname n
sol-qa-test-01
Reference to Man pages will give more specific information on uname.
The Environment variables
To get the information about the System and Environment variables, command env is used. This command returns the PATH variable, Home Directory, PWD (Present Working Directory), Time Zone, User, Group ID, Hostname, SHELL variable etc. Listing 4 gives the output of env command.Listing 4: env output
$ env
HOME=/usr/dennis
PATH=/bin:/sbin:/usr/bin
SHELL=/bin/bash
PWD=/usr/dennis/cfiles
TERM=ansi
TZ=
USER=dennis
GROUP=testing
HOSTNAME=sol-qa-test-01
In addition to the command env, command set can also be used. This command set meant for Bash Shell returns more information than the env command like HISTFILESIZE, PS1, Shell Level, information about the Bash Shell and also the user defined variables used within that shell. The set o displays all option set for bash.
To add a PATH variable into an existing one, i.e. to append a PATH to existing one, the correct method is:
E.g.: to add the path of JDK which is installed at /usr/java/jdk to the path variable à
$ set PATH=$PATH:/usr/java/jdk
$ export PATH
Note: After setting a PATH, it needs to be exported only on SH, KSH and BASH. No need of exporting on a CSH or TCSH. export is another command, which makes environment of parent process available to the child processes.
The which command takes input from the PATH variable to display the information. Which gives the path where the specified executable or a binary resides if and only if the executable or binary is present on any of the path defined in the PATH variable.
See the following example where the output is the path of the desired binary.
$ which javac
/usr/java/jdk
If the above entry were not added in the PATH variable, then the output would be:
$ which javac
/usr/bin/which: no javac in /bin:/sbin:/usr/bin
These commands make the job of the tester or to say any user very easy and simple. While testing any application, one should keep these in mind and make proper use of them to see if the application satisfies the basic UNIX needs.
Let us now explore UNIX features one-by-one in detail. To begin with The Shell.
{mospagebreak title=The Shell}
The Shell
Shell is nothing but another UNIX command, which interprets user requests. Shell is a program that starts once the User logs in and terminates when User logs out. Machines do not understand the translation of commands into actions. An interpreter is required for this process to be performed. In UNIX, the Shell does these jobs.
- Takes a command from the User;
- Deciphers it into smaller pieces;
- Communicates with the Kernel by exchanging information;
- Sees that the command is executed.
Windows Users will understand Shell just like the Command.com, but as mentioned earlier, Shell provides a strong programming capability.
Whenever any command is issued to the Shell, Shell first locates the command program from the PATH variable and then executes it. In UNIX, all commands are in the form of small programs which are located in a specific location, usually the /bin directory.
If the command program does not exist in the PATH variable location, use of full pathname is required.
E.g.: a user defined command movedir is to be executed, give the full path name as:
$ /usr/dennis/movedir
The 3 modes:
Shell denotes its presence by the prompt $ - or any other prompt set by the PS1 command. When there is no input from User, Shell is said to be in sleeping mode.
After a command has been issued, Shell looks in at the command line to find special characters are included if any.
The command is passed over to the Kernel for execution. The Shell then waits for the completion of execution of this command. The Shell then waits for an input from the User.
Once User starts typing at the prompt, Shell wakes up.
These are the 3 modes sleeping, waiting and waking that the Shell would always be in.
Shell Features:
Quoting: Three types of quotes are available.
Single-quotes:
It echoes whatever is included within the quotes. No variable substitution is done within a
single quoted command.
Listing 5: echo command with single quotes
$ echo Value is $1000
Value is $1000
Double-quotes:
It echoes whatever is included within the quotes but with variable substitution.
Listing 6: echo command with double quotes
$ echo Value is $1000
Value is 000
Note: here $1 is considered to be a variable since variables are declared using the $ keyword and hence the variable substitution is done which is nothing since $1 belongs to a set of parameters called positional parameters.
Back-quotes: ` `
It is used for command substitution.
Listing 7: back quotes
$ list=`ls`
$ echo $list
file1 file2 file3
Above set of commands declares a variable named list. What the `ls` does is it executes the command ls and assigns the output to the variable list. The second command line simply echoes the contents of variable list, which now contains the output from the ls command.
{mospagebreak title=Command combination}
Command combination:
Executing commands one-by-one can be time consuming and tedious at times. Shell offers a beautiful and very helpful feature where in commands can be executed in one line itself. This can be achieved using a semicolon between the commands. This is the delimiter used to separate the list of commands. Lisitng 8 shows how the delimiter is used.
Lisitng 8: delimiter usage$ pwd ; ls ; uname -n
/usr/dennis/cfiles
file1 file2 file3
aix-qa-test-01
Above command will first display the present working directory, then list the directory contents form the present working directory and then display the machine name all in one shot.
In a nutshell, the sequence of command execution is:
- Shell breaks the command into words using spaces and tabs as delimiters unless the delimiters are quoted.
- If any Shell variables are defined, these are evaluated.
- Command substitution then takes place
- The redirection of the files for input or output is done (more emphasize on this in later articles)
- Shell then scans the command lines for wild-characters like the *, ?, . and replaces these wildcards with alphabetically sorted list that matches the pattern. (more emphasize on this in later articles)
- The full command is then sent to kernel for processing and after the processing is done, the resulted output is either displayed on the screen or redirected.
More on Shell:Testing needs to be performed on atleast the major Shells, since these shells behave differently. The major shells include SH (bourne Shell), Bash (Bourne Again Shell), Ksh (Korn Shell) and Csh (C Shell) although there are many more like the A Shell, Z Shell, TC Shell and so on.
Apart from those mentioned in the earlier paragraphs, shells have some differences like:
- Full signal trap handling is not available on CSH, but it is available on all other shells.
- Job Control is not a feature of SH, but it is of all other shells.
- Process substitution is only available on the BASH.
- Co-Processes can only be formed with KSH.
To identify which is the current shell one is working on, echo $SHELL displays the required information. Listiu
$ echo $SHELL
/bin/bash
Shell too possesses some characteristics of the OOP like Inheritance.
- One Shell can generate many sub-shells.
- These sub-shells inherit the characteristics from parent Shell.
- They use the current directory of the parent Shell for processing jobs.
- Sub-Shells also inherit the environment variables defined in the parent Shell.
- However, the local variables that are declared in the parent Shell remain private to the parent Shell and cannot be used in any of the sub-shells. This is an important factor while writing any shell scripts. If any sub-shell is opened in the script, make sure that the variables those have been declared in the parent shell are not used in the sub-shell.
- The sub-shells also inherit the signal handling mechanism of the parent shell.
- However, the signals that are trapped in parent shell are not trapped in the sub-shell.
We will take a closer look at Signals and Signal Trapping in the subsequent articles.
{mospagebreak title=Conclusion}
Conclusion
The testing process does not change as per the OS. The key to it is that a few precautions need to be taken when working on different OS and different SHELLS. From the testing point of view, each of the above mentioned paragraphs should be considered. Testcases should be designed in such a way that these precautionary measures are included as a part of the test case design. To give an example, remove the path from PATH variable and test if the application uses a default path and still continues successfully. Test to see if the applications give correct results on all shells. Few defects are observed when the quoting has been done. For e.g., a single quote has been used instead of a double quotes which gives totally different results.In the next articles, we will take a closer look on Processes and Jobs, File System, File Permissions, Filters, Shell Programming.
References
Author
Abhijit Potdar has a master's degree in computer management and is a 'Certified Software Tester (CSTE)'. He is having extensive experience in software testing. Specifically in Unix environment as well as in Test Automation apart from Database Testing. He can be reached at (abhijit.potdar AT gmail)
Home | Content | Resources | Contact | 
Before beginning with any kind of testing, one should consider few aspects like the architecture of the application, size of the application, who the end-user would be, time and budget allotted for testing, and most importantly the Operating System.