Some Linux or Unix command to help QA Activities
Posted by: Prince in QA/Testing, Solutions 1 Comment »Some Linux/Unix command to help QA Activities
—————————
Linux/Unix Commands
—————————
See IP Address: ifconfig
See directory :: ls, li, ls
Create directory:: mkdir NAME
go to directory:: cd NAME
go to root :: \
delete directory :: rm -rf NAME
delete force fully directory :: rm -rf NAME
move file :: mv logs/error_log logs/ error_log1
copy file :: cp -rf pdf/abc.pdf test/abc.pdf
copy file all files \cp -rf pdf/* test/
Find process:: ps -ef “processname”
Find Process :: ps -ef | grep java
Kill process:: kill -9 processid, killall procmail
Find and replace:: find . -name conf.xml
Grep Command:: grep “my name is prince” test/PrinceJain
Grep and count no of times: grep “my name is prince” test/PrinceJain | wc -l
set date:: date -s “2 OCT 2006 18:00:00″, date -s “Sun Nov 30 02:09:31 IST 2008″
run process in backend :: nohup php GetName.php &
start stop service::
service iptables stop
/etc/rc.d/init.d/iptables stop
/etc/rc.d/init.d/iptables start
/etc/init.d/mysql restart
/etc/init.d/mysql stop
/etc/init.d/mysql start
To do empty file:: >error_log , cat error_log
To change file/folder permission :: chmod -R 777 upload
To see tail for log file::tail -f FileName
To do file transfer from one machine to another (Unix/Linux)::
scp -r root@192.168.1.13:/home/prince/abc.txt jain/
scp –r prince/abc root@192.168.1.12:/home/prince/
To do file transfer from one machine to another (Linux to windows)::
(First install pscp in window machine)
pscp.exe -r root@192.168.1.13:/home/root/prince.png .
pscp.exe -r C:\ prince.png root@192.168.1.12:/home/prince/
To broadcast message ::
type “wall” , then whatever you want to say (multiple
lines are OK), followed by and then CTRL-D
—————————
CVS Commands
—————————
check out :: cvs co name
update :: cvs update name
diffrence :: cvs diff name
—————————
Vi editor Commands
—————————
open file–vi file name
save and close– :wq
quite without save– :q
save forcefull without save — :q!
find and replace –
:%s/localhost/192.168.1.13/
:%s/localhost/192.168.1.13/g
:%s/localhost/192.168.1.13/gc
nginx (pronounced as “engine X”) is a HTTP server and mail proxy server written by Igor Sysoev. nginx is a lightweight, high performance web server/reverse proxy and e-mail (IMAP/POP3) proxy, licensed under a BSD-like license. It runs on UNIX, GNU/Linux, BSD variants, Mac OS X, Solaris, and Microsoft Windows.
Nginx is one of a handful of servers written to address the C10K problem. Unlike traditional servers, Nginx doesn’t rely on threads to handle requests. Instead it uses a much more scalable event-driven (asynchronous) architecture. This architecture uses small, but most importantly, predictable amounts of memory under load.
Even if you don’t expect to handle thousands of simultaneous requests, you can still benefit from Nginx’s high-performance and small memory footprint. Nginx scales in all directions: from the smallest VPS all the way up to clusters of servers.
Basic HTTP features:
Handling of static files, index files and auto-indexing
Reverse proxy with caching
Load balancing
fault tolerance
SSL support
FastCGI support, with caching, although it doesn’t have CGI support.
Name- and IP-based virtual servers
FLV streaming
MP4 streaming, using the MP4 streaming module
Web page access authentication
gzip compression
Mail proxy features:
User redirection to IMAP/POP3 backend using an external HTTP authentication server;
User authentication using an external HTTP authentication server and connection redirection to internal SMTP backend;
Authentication methods:
POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
SSL support
STARTTLS and STLS support.
Suppored Operting Systems:
FreeBSD 3 — 7 / i386; FreeBSD 5 — 7 / amd64;
Linux 2.2 — 2.6 / i386; Linux 2.6 / amd64;
Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
MacOS X / ppc, i386;
Windows XP, Windows Server 2003.
Performance:
nginx has reverse proxy server feature
nginx has Load balancer feature
Other HTTP features:
name- and IP-based virtual servers;
keep-alive and pipelined connections support;
flexible configuration;
reconfiguration and online upgrade without interruption of the client processing;
access log formats, bufferred log writing, and quick log rotation;
4xx-5xx error codes redirection;
rewrite module;
access control based on client IP address and HTTP Basic authentication;
PUT, DELETE, MKCOL, COPY and MOVE methods;
FLV streaming;
speed limitation;
limitation of simultaneous connections or requests from one address.
Experimental features:
embedded perl.
Question: When Smoke & Sanity Testing is performed in the STLC? Which of them is performed earlier & the other later & why?
Ans: Sanity testing: It is just to test the basic functionalities of a software product and application. it is done by testers.
Sanity Testing is subset of regression testing and a group of test cases are executed that are related with the changes made to the application.
Smoke testing: it is a form of regression testing. When an application made some new changes to modules or added new modules to a application then a smoke test is performed that it is working fine or not. It can be done by both developers and testers but most of time dev team perform this.
In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.
A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide
There are no certain rules for this, the both ensure whatever we are releasing it should be defect free and tester should catch defect ASAP so we can reduce time and cost to deliver best product.
In Some organizations, Sanity Testing is done first and then Smoke testing because Sanity Testing is a sub set of major function testing to check build is stable or not and major function working fine or not and smoke testing is like cursor testing where user just touch every part of the application it can be called as ad-hoc.
But in some organizations, Smoke is done first and later the sanity, but again its depend on organization to organization
Software sanity tests are commonly conflated with smoke tests. A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive. If the smoke test fails, it is impossible to conduct a sanity test.
In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct. If the sanity test fails, it is not reasonable to attempt more rigorous testing.
Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests and unit tests on an automated build as part of their development process.
|
Quality Assurance |
Quality Control |
|
A planned and systematic set of activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified requirements. |
The process by which product quality is compared with applicable standards; and the action taken when nonconformance is detected. |
|
An activity that establishes and evaluates the processes to produce the products. |
An activity which verifies if the product meets pre-defined standards. |
|
Helps establish processes. |
Implements the process. |
|
Sets up measurements programs to evaluate processes. |
Verifies if specific attribute(s) are in a specific product or service |
|
Identifies weaknesses in processes and improves them. |
Identifies defects for the primary purpose of correcting defects. |
|
QA is the responsibility of the entire team. |
QC is the responsibility of the tester. |
|
Prevents the introduction of issues or defects |
Detects, reports and corrects defects |
|
QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process. |
QC evaluates if the application is working for the primary purpose of determining if there is a flaw / defect in the functionalities. |
|
QA improves the process that is applied to multiple products that will ever be produced by a process. |
QC improves the development of a specific product or service. |
|
QA personnel should not perform quality control unless doing it to validate quality control is working. |
QC personnel may perform quality assurance tasks if and when required. |