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.
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.
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
- Shell Programming
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.
$ cat /etc/passwd
- 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.
- 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.
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.
root tty01 May 15 15:30
dennis tty02 May 16 20:00
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)
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.
$ uname SunOS $ uname -m sun4u $ uname n sol-qa-test-01
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.
$ which javac
$ which javac
/usr/bin/which: no javac in /bin:/sbin:/usr/bin
- Takes a command from the User;
- Deciphers it into smaller pieces;
- Communicates with the Kernel by exchanging information;
- Sees that the command is executed.
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.
Quoting: Three types of quotes are available.
single quoted command.
Listing 5: echo command with single quotes$ echo Value is $1000
Value is $1000
Listing 6: echo command with double quotes
$ echo Value is $1000
Value is 000
It is used for command substitution.
$ echo $list
file1 file2 file3
Lisitng 8: delimiter usage
$ pwd ; ls ; uname -n
file1 file2 file3
- 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:
- 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
- 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.
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.
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)