Getting Started Guide to Unix Based Testing

May 17, 2005February 4, 2010 Abhijit Potdar 10471 Views 8 Comments Articles, Quality Articles, software quality

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.

In this article, I will be covering the basics of UNIX, some basic commands of UNIX that will help beginners getting familiar with UNIX and some advanced commands too.

For more advanced concepts, check out part 2 of this article: Getting Started Guide to Unix Based Testing: Part 2

Getting Started Guide to Unix Based Testing

First, let us see what UNIX is and what the various flavors of UNIX are?

What is Unix?

The history of UNIX starts back in 1969, when Ken Thompson, Dennis Ritchie and others started working at Bell Labs what was to become UNIX .Originally written in assembler, UNIX was re-written in C in 1973. Here are some features of UNIX:

Unix is divided into two constituents:
- Kernel: Communicates with the hardware of a machine directly.
- Shell: Interprets the commands given by the user so that the kernel can read, understand and execute the command.

Unix is comprised of number of small commands, which performs one simple job only. These commands can be grouped together to achieve a complex task.
Unix provides a very strong pattern matching capability with the use of metacharacters.
Unix is highly programmable since it was designed keeping a programmer in mind. Shell programming can achieve what many development languages like C++ are capable of doing.
Unix is a Multi-Tasking, Multi-User Operating System.
Unix provides vary high level of Security and Networking support.
And most importantly, UNIX is an Open System.

All these features make UNIX a very powerful Operating System.

One more advantage in UNIX is that a job can be run in the background in the same shell whereas in windows this is not possible. So one can write a piece of shell-script and keep running the same in the background that would work just like a service on windows.

UNIX Flavors and Versions

UNIX has changed a lot since it was first developed in 1969. Many new features have been added to make it more efficient and robust. Many vendors and many flavors of Unix are available today. Linux, Solaris, AIX, HP-UX and Tru64 are some of the popular ones.

The major difference between these flavors is their vendor. IBM has its own hardware and they created AIX that would work well on their hardware. Similarly, HP invented HP-UX. Solaris works on SPARC based architecture. In all these flavors, the kernel is the same although the file system may vary. Above all, Linux itself comes from different vendors like RedHat, Mandrake, Novell (Suse) etc.

There are few basic differences between these flavors like the default shell on Red Hat Linux is Bash whereas on Solaris it is Csh. They handle metachars differently.

The file format on Linux is ELF (Executable & Linking Format) while on AIX and Solaris it is COFF (Common Object File Format).

When we say UNIX Flavors, it means that these OS follow some rules in order to qualify as a UNIX OS. All that an OS needs to qualify, as a UNIX OS is that it should be a POSIX (Portable Operating System Interface) compliant. POSIX is a set of rules or policies defined just like ISO (International Organization of Standards) or CMM (Capability Maturity Model), so that these flavors have the basic, important and frequently required features available all the time.

Let us now see what all commands are useful in order to test applications on a UNIX machine.

Beginning with the Testing

The testing begins with connection to a remote UNIX box. This connection can be established via various methods like WRQ Reflection, Putty, Citrix, Telnet, etc. But there are some important and key things, which requires consideration when testing on Unix. One has to keep in mind the following things:

The Shell
Processes and Jobs
File System
File Permissions
Filters
Shell Programming

In this article, I will explain few basic commands very useful in UNIX environment and will be focusing on the topic: The Shell.

Logging with Local User v/s NIS User

We will first take a closer look on the login process and then proceed with the above-mentioned topics.

To establish a connection, a user can log in if he/she is a NIS (Network Information Service) user OR if the user is added in the /etc/passwd file on the UNIX box.

The /etc/passwd file contains the Name, Password, UserID, Home directory and default shell defined for the local user in a specified format.

Listing 1 The /etc/passwd file

$ cat /etc/passwd

root:x:0:0:Super-User:/:/bin/sh

dennis: qcz0IWuPIQxiM:504:10::/usr/dennis:/bin/bash

This file is : delimited with each line beginning with the local user name – dennis.
x for user root denotes that the password has been encrypted and stored in the /etc/shadow file, while for dennis the qcz0IWuPIQxiM denotes that password is encrypted in the /etc/passwd file itself and not in /etc/shadow file.
504 is the User ID for dennis
10 is the principal group ID for dennis
Next field is blank for dennis while it is Super-User for root. This is the general information about the user.
/usr/dennis is the Home Directory of the user dennis and,
/bin/bash is the default Shell defined for dennis.

When a NIS user logs in to the machine the environment is a bit different than that of a Local user:

Default shell would be the default shell configured for that particular box, which may vary from machine to machine
The home directory would be the home directory configured in the NIS database.
If this specific directory that is configured in the NIS database is not mounted, the default directory after logging in would be the root directory.

Once the user is logged into the system, all thats needed is the use of commands to control the application.

Who is using my machine?

If the machine is used by more than one user at any given time, a good practice is use of the commands who (lists the users that are currently logged into the machine) and last (lists the users that were previously logged into the machine). These commands help to avoid unnecessary conflicts between simultaneous users. Listing 2 will explain the output of these commands.

Listing 2: who output

$ who

root      tty01       May 15 15:30

dennis    tty02       May 16 20:00

Here, 1st column displays the name of user logged in; 2nd display the device names of respective terminals; 3rd displays Date and Time of logging in.

$ last

dennis    tty01        dennis-w2k-01   Sun May 16 20:00   still logged in

dennis    pts/2        dennis-w2k-01   Thu May 12 22:46 - 00:46  (02:00)

1st column displays user name, 2nd the terminal name, 3rd is the remote machine through which these users were logged in, 4th is date of logging in, still logged on denotes the user is currently working on the machine while (02:00) denotes the duration for which the user was logged into the machine.

If a NIS user logs into the machine and the configured home directory is not mounted, the /tmp or /var directory can be used to store the data. These directories are supposed to be on every UNIX machine as per the file system of UNIX OS.

The df k command lists the mounted directories as well as the free space on each mounted directory. To mount a remote directory, use the command mount and to unmount a directory use unmount. Make sure that one is logged in as a root or other user with Admin rights.

One good feature of UNIX is that to log in as a different user, one does not need to logout and then re-login as another user (as in Windows). To login as another user, simply type in the command su – . This will open another shell and one can start working as if he were the new user. The su without any user name logs in as the root.

The command pwd is used frequently to display the present working directory. Since its difficult to view a graphical structure of the file system, this command is useful to understand which part of the file tree one is working currently.

E.g.: $ pwd

/usr/dennis/cfiles

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.

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.

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.

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

AuthorAbhijitPotdar 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)

8 thoughts on “Getting Started Guide to Unix Based Testing”

gagan
November 14, 2012 at 8:35 pm

thanks it is a good article!
Log in to Reply
Karthik Reddy
August 9, 2011 at 2:08 pm

Hi Sir,I am want to know about Unix Testing .In Real Time what we are going to do.What is the Best book For Unix.
Log in to Reply
Nitin Fedora
June 30, 2011 at 5:21 am

Hi sir, I have experience in Unix/Linux environment testing for data security. I have worked on Shell, different Linux flavors, SAN, NAS and Samba servers and worked on performance testing as well using some tools like iozone, fsstress and fdtree etc. Now, I would like to change my company. I just want to know that which are the companies that work on linux testing environment that I should apply? Is the dada centre job or Network administrator job will suit my current profile? I am little confused. Please suggest.

Thanks a lot.
Regards
Nitin
Log in to Reply
Bobby
April 24, 2011 at 3:52 am

than q for u cooperation…with us..
Log in to Reply
Shivamtyagi 89
February 11, 2011 at 6:14 am

dear sir
I am new user to use unix so please kindly request help me and guide for
use to unix command
Log in to Reply
Jai Sjp123
November 30, 2010 at 9:40 am

Hi,
I am new to the Unix Testing, the process is passing the unix shell script and get the data from one database and load that data file into another database, how do i test this process.

Kindly suggest me…..
Log in to Reply
Venu kumar
June 21, 2010 at 7:10 pm

Hi abhijit,

its really intresting,but i am new to the unix and shell scripting,can you kindly explain what are the major topics that a software tester should be thorough.give some real time examples how a software tester tests the application in unix.

venu
Log in to Reply