Hadoop

Posted by: Prince in Technology No Comments »

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.