How to Test, Manage, and Configure Web Applications Run by Linux OS:
Let’s find out how to manage the fastest growing operating system today in the field of web applications testing. The following is applicable if your application is running on servers operated by any of Unix-like distribution.
This tutorial will be useful for any novice Linux user during his or her education. Especially, the majority of frequently asked questions we have to solve during our Linux study are described below.
What you will learn in this Tutorial:
We are going to run through a few essential topics which any QA Engineer will probably face during managing and testing web applications run by Linux OS:
Recommended read => UNIX basics for software testers.
Few regards to the history. It was a hard work by real Linux followers to bring *nix OS merits to bear on IT Community in past. Thanks to them, this operating system is in full swing now.
The global statistic mentions the majority of a supercomputer and highly-loaded application servers are operated by Linux. Linux servers tend to be the most stable and productive environments designed to be shared by a large number of users (e.g. social networks).
Let us get it started from few comparisons:
What You Will Learn:
This is only a part of all advantages we could list here. Let’s keep on moving.
Firstly, we’d like to list some hints which could help to avoid its specific singularities.
Tips & Tricks of penguin taming: web application testing
Let us start from some essential but simple points here:
Meanwhile, I’d like to draw your attention to few details about path types as well as name length limitations in the *nix OS.
First of all, let’s specify common terms.
An absolute path means the location of a file or directory from the root directory (top level): e.g. /var/log/protocol/log.
Relative path means path related to the current directory (pwd). For example, you are located in /var/log and you want to go to the following directory /var/log/protocol/log/. You can use a relative path here, so just apply cd protocol/log/.
And finally, there are following limitations applied to folder and file names in *nix (these limitations should also be checked during the test of your web application):
– 256 characters for a name;
– 1024 characters for an absolute path.
Basically, it’s prohibited (or impossible due to unknown or hidden password according to security policy) to log in as the root user (technically, the top level user, Administrator). But at the same time, the majority of daily routine administrative tasks require administrator permissions: web app starts/stop, database restarting/cleaning, new build deployments and so on.
The actual workaround here is to use the sudo command (requires a password as well): superuser does. So, use sudo followed by the required command to perform activities with so-called superuser permissions: sudo apt-get install shell utilities.
The administration of the Linux host (where your web application runs) requires frequent job and process managing activities.
We have listed a few must-knows below:
I’d like to finish this Intro with the following instructions how to install new software in Linux at this point is exceptionally challenging and called-for among former Windows users. The most common methods are below:
Firstly, any Linux user should be aware of such thing as for software repositories. Repository is storage for packages (both source and binary) accessible via Internet to install any required software on your computer.
You can easily select which to use or even create your own one: the list of connected repositories is stored here by default (examples for the most popular utilities):
– YUM: in files repo in the directory /etc/yum.repos.d/;
– APT: in file /etc/apt/sources.list and in the files in the directory /etc/apt/source.list.d/.
Further, coming to the technical side of testing itself, you can find a basic set of instruments for testing Linux applications you will definitely face while testing them. But most of these solutions are applicable to the majority of Unix-based systems and they are console based that is easier to automate, in fact.
On Linux, all programs can be divided into the following groups:
a) Core (Kernel)
This includes the core itself, the kernel modules and userspace level for kernel control (meaning the / proc and / sys interfaces). Since the kernel itself is written in C and ASM, then for testing you’d basically better to use C. Usually, these are small test kernel modules, checking some functions or module with different parameters + script.
As practice shows it’s better not to use one module checking the whole “feature”, but many modules checking each of the functions separately. You should also not forget to check all possible functions return codes.
b) User applications (userspace level)
Any application running on that OS. Of course, if such application is written in Java, you’ll need to own Java, at least in order to make sure that the program is working.
c) Core + User applications
Most likely this kind of application you will interact the most. This scheme encompasses the core driver provides low-level communication with any device and the user program.
Linux is really convenient for programming and testing. Almost all the tools present in any distributive or can be downloaded as they are distributed free.
Let’s try to describe all the necessary tools for testing Linux applications:
#1) GCC – Gnu C compiler
Basic C, C++ compiler for Linux. If you need to test the compiler, the gcc site having special tests. Compiling with the -g option will make debugging with gdb.
The BASH shell is also included in each distribution. It is in fact very useful for writing scripts.
Also present in each distributive. Rather simple but very handy syntax TCL.
– expect-perl ? expect-python (pyexpect) – libraries expect for scripting languages perl and python.
#4) gdb – Gnu Debuger
This is standard C / C + + debugger having a lot of opportunities. If you have never used it, I advise you to get acquainted with it. Use kgdb for a kernel.
#5) ltt – Linux Trace Toolkit
If your Linux core supports LTT, you can view the active processes/system calls in the current process.
#6) import? gimp – can be used for taking screenshots of testing graphics applications.
A program for manual testing. If you want to automate the console, it is better to use the expect (or in conjunction with the “cat” and “echo”, or just open / dev / ttySx as file – sometimes the second option does not fit).
#8) ltp – Linux Test Suite Page [ltp.sf.net]
Very useful collection of tests. Includes tests of file systems, system calls, and more.
#9) Some more common tools:
netperf – utility to verify the network performance.
ircp, irdump, openobex – Utilities for infrared checking.
telnet, ssh – remote shell. If you frequently enter the same command, you can use expect in any distributive.
That’s it for now. Today we learned a bunch of entirely important topics that cover FAQs, Linux singularities, process management, specific limitations and some more points that could be vital for QA services in the sphere of web application testing.
We have tried to list useful examples as well as to demonstrate the ways new software could be installed. Starting from this article you could keep on investigating the most stable, efficient, safe and legal operating system ever. We hope you’ve realized it makes sense!
About the Author: This is a guest post by Alexander Panchenko, who works as Head of Complex Web QA Department for A1QA. He is having good experience of working on various projects like backup and recovery applications, projects with complex business logic e.g. corporate portals based on Share Point, Banking systems, and Government portals. Now he is leading several teams of 7+ people and managing a division of 30+ engineers on board.
Good luck in testing, managing and configuring applications that installed on servers operated by Linux OS!
Need help in testing applications on Linux or any UNIX based systems? Just put your queries in below comments and we will try to resolve it.