Monthly Archives: April 2013

How to find MySQL Connection String

I have had this issue while working with various clients. How do you find the mysql connection string? This tutorial should help you.

How to make a MySQL connection:

I always write a separate file with the database connection information in it and put it in a secure location somewhere in the filesystem then include it in any file that needs to access that database. Here is how to write that include file which you just have to include in any PHP file directly before you make a database query:

 

<?php
//connect to database:
$url = "localhost";
$user = "kohlspaypal";
$pass  = "Paypalkohls1!";
$con = mysql_connect($url,$user,$pass);
mysql_select_db('kohlspaypal') or die('Could not select kohlspaypal database error was: '.mysql_error());
?>

The actual MySQL connection string is the line that reads:

$con = mysql_connect($url,$user,$pass);

However, the entire file is used to make the connection to the database. It is often the connection URL that people have issues finding when working with a server or database they are unfamiliar with, so that's what this tutorial will cover other than showing you the connection file itself as I have done above.

Using LocalHost as the URL for a MySQL Connection

Most of the time you can get away with simply using "LocalHost" as the value of the $url variable in the above script to make a connection to the database, but many servers, such as hosted Godaddy servers, for example, do not work with LocalHost as the URL, so here is an easy way to find the correct URL to use.

Finding the MySQL Connection URL:

  1. Log into your PHPMyAdmin installation. On servers where LocalHost won't work for the URL in the connection string, this usually involves logging into Cpanel or other control panel for your hosting account and then logging into PHPMyAdmin through there.
  2. Then click on the database you want to access within PHPMyAdmin. You will see something like what is in the following screenshot at the top of your page:

mysql

Notice at the top where it says "Server:" followed by an IP address or URL. That is what you should try next as your URL for the connection string, the $url variable in my example script above. If that doesn't work, contact your hosting provider and ask them for the Mysql Connection URL and they should be able to provide it for you. Good Luck on your next MySQL project!

Check out these great MySQL books to learn more about MySQL databases:

Setting up a Simple PayPal Shopping Cart

Here is how to set up a simple paypal shopping cart without any extra charges or additional shopping cart software to install.

  1. Log in to your PayPal account.
  2. in the right column, click on "My Business Setup".
  3. Under the first category called "Set up my payment solution", click the first "Start Now" button.
  4. Then, click the first option which reads "Create payment buttons for your website".
  5. On the next page, click on the blue "Create a Button" button in the middle of the page.
  6. On the next page, under step one, select "shopping cart" from the "Choose a button type" dropdown.
  7. You can enter an item number if you want to help keep track of your various items, but it's not required. The next required field is "Item Name", so enter a name that describes your item there.
  8. Next, enter the price of the item in the "Price" field.
  9. The rest of the fields on this page are not required, so unless you have special needs to track inventory or for IPN puposes, click the "Create Button" button at the bottom and retrieve your button code. If you have special needs, fill in those fields before pressing the "Create Button" button.

After that, you can simply skip to the website tab and copy and paste the button code into your webpage for a single simple shopping cart button. Then repeat this process for every item you are selling with your shopping cart and you will have a working PayPal shopping cart.

More advanced options and IPN, Instant Payment Notification:

Okay, if you didn't learn what you wanted to learn above, here is where I get into more advanced material about customizing shopping carts. Mainly I want to discuss the sending and returning of special variables to track items and customer information to process orders through IPN or the Instant Payment Notification feature.

In 2013 PayPal rolled out a new documentation site to assist developers with more advanced shopping cart and button creation. You can find this documentation at: developer.paypal.com.

 

Setting up PayPal IPN

I had a hard time finding updated information from 2013 on how to set IPN or Instant Payment Notification settings in PayPal. All the info on the web was outdated and didn't apply to PayPal's new website layout. So if you are looking to activate IPN for your PayPal account, here is how to do it as of May 2013 forward:

  1. Login to your PayPal account.
  2. Go to the "merchant services" tab.
  3. Click on "process orders" in the right column of the resulting page.
  4. Look for the "Instant Payment Notification" heading under "Receiving orders" and click on "learn more".
  5. Then, towards the bottom left of that page, click the button that reads "Choose IPN Settings".
  6. On the next page, fill in the Notification URL with the URL of your IPN receiving data script, then check the "Receive IPN Messages (enabled)" radio button. Finally, click "save" to save your settings.

That's it, now you are ready to receive Instant Payment Notifications for your custom IPN script you have or will write. I do a lot of PayPal automation work,  if you need a custom IPN listener written that will enable auto-order fulfillment, get in touch with me, I write custom IPN listeners for as low as $100 that will make it so you have to do nothing when an order is made through your website or through eBay. If you have a product that you sell that is something that can be sent electronically, like eBooks, coupons or other info that can be sent through email, then this could be a huge time saver for you! Email me at linian11@yahoo.com to find out more.

Set Root Password for MySQL on Centos Server

When you first set up a new webserver on Linux machines, you should always set the root password for MySQL. In fact when launching MySQL for the first time you should get a message that reads:

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h ip-68-178-128-186.ip.secureserver.net password 'new-password'

Alternatively you can run:
/usr/bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd /usr/mysql-test ; perl mysql-test-run.pl

Domain Name and Nameserver Tools

This is a simple list of links I put together for anyone needing help with domain name monitoring and nameserver set up. They are meant to give you information regarding your domain name, IP address and nameservers.

DnsStuff.com

DnsStuff.com - This site is one I use regularly to make sure my domain name is pointed right and to test nameservers for that domain or nameservers that I have built.

DomainTools.com

DomainTools.com is a great place for gathering WhoIs info for your domain and if you look around a bit they have other useful domain name tools and info.

DnsCheck.pingdom.com

DnsCheck.pingdom.com has a useful tool for running all sorts of DNS tests on a domain name.

Pingability.com

Pingability.com - is a great tool for checking to see if your domain is pointed to the proper server. Looking up your IP address and getting nameserver information for the domain name and/or IP address. IT lists MX records, A records, nameserver IPs and other host file data and zone information that is useful.

FYI - If you need custom domain name tools or SEO tools, I specialize in developing such tools for the internet. Web-based domain name, SEO, Calculators and business development tools are my no. one specialty. If you need any such custom tools contact Ian at linian11@yahoo.com and we can work something out and get a free estimate on the spot.

 

 

 

 

 

Find Linux Version From Command Line Promp

I spent a good half hour trying to find out how to get the Linux Distro information from the command prompt, so figured I'd make a note if it for everyone else. There are a few different commands that will get you information about the version of Linux you are using and similar information. Here they are:

Using the uname command

The uname command is very helpful, so I am listing it first. The trick is understanding the parameters, so I will list them here as well. To use the uname command to get basic info call it from the command prompt using the "a" parameter like this:

uname -a

the above will return something similar to the screenshot below:

uname

uname parameters:

a - exmaple from above (uname -a) provides basic information which as you can see above tells us it is a linux server with the node name which looks like an IP address. It also tells us its a 64 bit system and it us a GNU/Linus os.

i - prints the name of the hardware implemtation, which in my case returned: x86_64

m - prints name of machine hardware name which when I did returned same as above x86_64

n - prints the note name like: ip-10-194-242-132

o - gets the OS name such as GNU/Linux

p - if for processor type which again returned x86_64

r - prints OS release. I did it on an Amazon cloud server, so it returned: 3.2.37-2.47.amzn1.x86_64

s - returns the name of the OS which in my case returned "Linux".

v - prints version information

S,X - both parameters I read about, but niether were supported when I tried them on my Linux Amazon AMI. Both returned "Invalid Option", so you may want to see if they work for you. They are both captialized parameters.

If you didn't get the information you need from the uname command keep reading.

The /etc/*-release Command

This command will get you basid OS level information. When I invoked the command on an Amazon Linux cloud server, I got:

Amazon Linux AMI release 2012.09

Just type:

cat /etc/*-release

The proc/version command

To invoke this command, which provides more useful information regarding your system, type:

cat proc/version

from the command prompt. The below image shows the results I got from the proc/version command:

proc

So you can see this command returns some useful data such as the red hat distro in my case telling me I basically have a Centos system I was able to determine from the red hat version no.

See if you have a Red Hat Distro

You can do this by invoking the following at the command prompt:

cat /etc/redhad-release

If it doesn't throw an error and shows relative information, then you have a Red Hat distro. Simple as that.

Check if you have a Debian or Ubuntu Distro

Use:

cat /etc/issue

It will return relative info if you do. When I did this, it didn't specifically say, but only returned info that it was an Amazon Linux AMI, so I had to use that to Google for more information.

 

How to Build A Common Mult-Part Web Page in PHP

In this beginner's level PHP tutorial I will show you one of my favorite methods for Building a website from scratch using PHP with HTML5, CSS and maybe a little JavaScript. If you can master at least PHP, HTML and CSS, you can become a well-paid website developer in no time at all! I did about ten years ago and have been doing it full time ever since, so it's something to think about if you like web design and are looking to start a carrier. PHP is the most commonly used website coding language used for dynamic websites. All PHP site contain HTML with a few exceptions of course, but using HTML5 and PHP is what I recommend definitely if you want to make a living or even just develop your own site.

Advantages of using PHP for Website Development

Why use PHP? That's an easy question for me to answer. I use PHP because it is easy to learn, well documented, well known and a vastly sought after skill. PHP developers get paid. It's that simple. THe main reason though is it makes life easier for you, the developer. A prime example is how I will demonstrate how I use PHP to include content into a basic HTML page template.

A Basic Webpage Layout

This is the basic layout I use on 90% of the websites I build when the decision is up to me. You should plan out your site pages first. For example, write out a simple list of pages you want like this:

  • Home
  • About
  • Contact
  • services

Those are some of the common pages I like to include in the top nav of my website and are often close to the exact framework I use for building a website. Other pages I include in the footer in a sitemap.

Basic Features for a Website

Always plan the basic features your site will include. For example you might have an image slider on some pages. In my example, I am keeping it simple and only including the following necessary features that are common and could be used for almost anyone's website:

  • Drop-Down Navigation Menus -  the top navigation bar will allow for drop down menus, but they don't have to be on every tab, for example in this example I only use drop down menus on the about and services pages. When you hover over either of those links in the top navigation bar, a drop-down list of pages within those sections will appear. An example would be under services, links for Website Development, SEO, Server Administration and Logo Design could be used. Customize these to fit your needs of course.
  • Simple PHP caching system. This is not a traditional cache, but a cache none-the-less because we are essentially loading the index.php page with the header, top navigation menu and footer once and only changing the content of the page dynamically with PHP which speeds up page load times greatly, especially if you have a lot of images in your header, navigation bar and footer designs.

Make a Simple PHP Webpage Template

The first step to developing a website after you have drawn up some specs is to code your first page. I call it a bare-bones page. This is a page you can use to start off all the other pages in your website with so keep a copy of it without content and add content as needed to a copy of the template whenever you add a new page to the website. The basic parts to a well formatted PHP webpage are as follows:

  • Index.php - serves as the landing page as well as a page template in this infrastructure.
  • header.php - contains the website header including the site's logo and top navigation menu often along with whatever else you want at the top of yourpage such as login, logout and sign-up links for example. I include my header.php file in index.php.
  • topnav.php - I like to keep my top navigation menu in a separate file which i include in the header.php file usually.
  • content.php - will be the main content for the page. You will have several of these with different file names such as home, about, contact, etc., one for each page of your site. The content pages should contain only content that is different for each page. the other files in this infrastructure are all reused for every page of the website in most cases, but the content files are where you go to make general content edits without having to worry about common areas of the website pages that don't generally change much such as the header, top navigation bar and footer as in this example layout.
  • footer.php - is your common page footer used on every page in yoru website. If you surf the web and loo at a few different sites, a lot of them all have the exact same header and footer, so why have a different block of code to edit for each pages footer when you can edit one page and it will change the footer for every page in the site. That's the advantage of using PHP includes.

Developing Your First Page

The first page I always develop for any website is just a bare-bones page without content or with dome placeholder text and/or images for content. The first file you want to write is index.php. Here is a common method I use very often"

Coding index.php

<?php
//any PHP code that doesn't display anything to the page can be included above the opening HTML tags below, but do not put anything in this top PHP section that writes content to the page. This area is for preparing page content, not showing it.
//############ prepare content for different pages: ###############
//set tab class before including the header:
//set tab defaults:
$homeclass='';
$aboutclass='';
$contactclass='';
$serviceclass='';
//dynamically include main content according to URL's pg variable:
$pg = $_GET['pg'];//pg request from URL
//set default main content  pg content in case nothing is requested in URL:
$pginc = 'home.php';//default landing page if no other page requested
if($pg==""){$pg="home";}

//set up your navigation bar to dynamically highlight the pg your are on
//if page is in the home tab:
if($pg=='home'){$pginc = $pg.'.php';$homeclass='current';}
//if page is in the about tab:
if($pg=='about'){$pginc = $pg.'.php';$aboutclass='current';}
if($pg=='about_me'){$pginc = $pg.'.php';$aboutclass='current';}
if($pg=='about_company'){$pginc = $pg.'.php';$aboutclass='current';}
if($pg=='about_history'){$pginc = $pg.'.php';$aboutclass='current';}
//if page is in the My contact tab:
if($pg=='contact'){$pginc = $pg.'.php';$contactclass='current';}

//if page is in the contact tab:
if($pg=='contact'){$pginc = $pg.'.php';$contactclass='current';}

//if page is in the services tab:
if($pg=='services'){$pginc = $pg.'.php';$serviceclass='current';}
if($pg=='PHP'){$pginc = $pg.'.php';$serviceclass='current';}
if($pg=='webdevelopment'){$pginc = $pg.'.php';$serviceclass='current';}
if($pg=='serveradmin'){$pginc = $pg.'.php';$serviceclass='current';}

//set default tab to home so home page is highlited in nav when landing on site:
if($pg==''){$home='current';}
//now after this is where you start writing to page close PHP and open HTML tags
?>

<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Jafty.com Example Website</title>
<link href="css/global_styles.css" rel="stylesheet" type="text/css" />
<?php
//dynamically include extra style sheets & files for content area:
if($pg=='home') {
echo "<link href='css/home_style.css' rel='stylesheet' type='text/css' />";
 //you can also include other page specific PHP files here
}//end if parkingcrew page, add home CSS style sheet.

//contineue to include special style sheets for any other pages if needed:
if($pg=='about'){
echo "<link href='css/about_style.css' rel='stylesheet' type='text/css' />";
}//end if about page, add about CSS style sheet.
?>
</head>

<body>
<div id="wrap"><!--wrap (100% wide)-->

<?php
include 'includes/header.php'; //includes header file w/tabs.
?>

<div id="content"><!--content area is common standard of 960px wide-->
<!--#################### Start Main Content #######################-->
<?php include "includes/$pginc"; ?>
<!--################### End of Main Content #######################-->
</div><!--end content div-->

<?php include 'includes/footer.php'; ?>
</div><!--end wrap (100% wide)-->

</body>

</html>

The above code creates your page template. this file can be modified once you get all your pages in place and it is the framework for all of your content pages. All before the doctype declaration is PHP code that doesn't display anything to the page so it is okay there. Basically the first block of PHP code before the doctype declaration is to set up your tabs and page variables for use inside the head tag and after the opening Body tag.

After the HTML body tag, we use more dynamic PHP code to include the proper header for the website then show the content according to what page is called in the pg PHP GET variable visible in the browser's URL. In this example, I have named my main pages home, about, contact and services. Then the pages in the drop-downs for the about and services links have pages as well which are called about_me, about_company, about_history, PHP, and so on. Just be sure to name your PHP files according to these names and everything will work perfectly. For example, the about_me page needs to be named about_me.php and all the content pages go inside the includes folder so your site directory tree will look like the example in the next section.

Towards the bottom of the pg we include the footer file with PHP too so we have one footer file for the entire site, making changes easy.

Site Directory Tree

Here is what should be in the root folder for your website:

  • index.php (only file in the root directory for simplicity)
  • css - folder that holds all CSS style sheets for the site
  • images - for all your site's images
  • includes - folder for all your content pages as well as the header and footer files.

Create your header.php:

for this example site, every page will have the same header and it is coded like this:

    <div id="header"><!--header div 100% for dynamic width by 132px high-->
    <div id="headercontent">
    <img id="logo" src="images/logo.png" alt="Jafty.com" />
    
    <div id ="logininfo"><strong>Welcome to Jafty Interactive Web Development!</strong><br />

   Email Ian L. For a web development quote - <a href="mail:linian11@yahoo.com">linian11@yahoo.com</a>
   
    <p><strong>Jafty Coding Blog:</strong><br /><a href="http://jafty.com/blog">find code examples, tutorials and more web development info</a></p>
    </div>
    </div><!--end header content div 960px wide -->
    </div><!--end header div 100% wide by 132px high-->

    <div id="headspace"></div>
    
    <div id="topnav">
    <div id="topnavcontent">
    <div id ="utility"><ul id="utility_menu">
    
  <li><a href="index.php?pg=services">Services</a>

    <ul class ="end">

      <li><a href="index.php?pg=PHP">PHP</a></li>

      <li><a href="index.php?pg=web_development">Website Development</a></li>

      <li><a href="index.php?pg=server_admin">Servier Administration</a></li>

    </ul>

  </li>

  <li><a href="index.php?pg=contact">Contact</a>

  </li>

  <li><a href="index.php?pg=about">About <span style="color:#FFFFFF">&nbsp;&nbsp;|</span></a>

    <ul class ="end">

      <li><a href="index.php?pg=about_me">About Me</a></li>
      
      <li><a href="index.php?pg=about_company">About Jafty</a></li>

      <li><a href="index.php?pg=about_history">About History</a></li>

    </ul>

  </li>

  <li><a href="index.php?pg=dom_stats">Home <span style="color:#FFFFFF">&nbsp;&nbsp;|</span></a>
  </li>

</ul></div>
    </div><!--end topnav content div-->
    </div><!--end topnav div-->

Create a common footer.php File:

This is a very simple footer example, but also very functional. Modify as needed then save the following code in your includes directory for your website:

<div id="footer">
<br />
Terms of Service | FAQs | Contact Us<br />
Phone: 234.567.8900 - FAX: 234.567.8901<br />
&copy;2013-2025 YourSite.com Designed by Jafty.com
</div><!--end footer div (80px by 100px wide)-->

 

Set up your global.css File:

Global.css is s file that will get called in index.php and contains site-wide stiles for the header, footer and common attributes of pages maybe. I also make separate style sheets for pages that have special content, but that's up to you. At the least, you need the global.css file though for your pages to work, so here is the contents of that:

html,body{
padding:0;
margin:0;
}

#wrap{
width: 100%;
height: 2252px;
margin: 0 auto;
background-color:#FFFFFF;
background-image: url('../images/0100.png');
font-family:arial;
font-size:14px;
}

#header{
margin-top:0px;
width: 100%;
height: 160px;
background-color: #FF0000;
font-weight:bold;
}

#headercontent{
margin-top:0px;
width: 960px;
height: 160px;
background-color: #FF0000;
font-weight:bold;
margin:0 auto;
}

#logo{
margin-left:6px;
margin-top:8px;
float:left;
}

#logininfo {font-size: 10px;margin-top:20px; margin-right:0px; float:right; text-align: right; color: #FFFFFF; padding: .5em;}
#logininfo STRONG {font-size: 12px;}
#logininfo a{color: #FFFFFF; text-decoration: underline;}
#logininfo a:hover{color:#FFFFFF; text-decoration: none;}

#headspace{
width: 100%;
height: 2px;
background-color: #FFFFFF;
}

#topnav{
position:relative;
width: 100%;
height: 40px;
background-color: #F88017;/*#FE9A2E;*/
}

#topnavcontent{
position:relative;
width: 960px;
height: 40px;
background-color: #F88017;
margin:0 auto;
}

#utility {position:absolute; display: block; width: 100%;bottom:0; left: 0px; padding: 0; margin:0; color:#FFFFFF; overflow: visible;}

#utility_menu {position: absolute; display: block; bottom: 0px;    overflow: visible; padding: 0; margin: 0; list-style: none;}
#utility li {position: relative; display: block; float: right; overflow: visible; margin: 0;}
#utility a { background: transparent; color: #FFFFFF; display: block; border-left: 0px solid #FFFFFF; padding: .2em .5em;  text-decoration: none; font-weight: bold;}
#utility a em {font-size: 11px; font-style:normal; font-weight: normal; color: #6F6F6F;}
#utility a:hover { background: transparent; color: black;}
#utility a.current {color: yellow; background: transparent; border-left: 0px solid #FFFFFF;}
#utility a.current:hover {color: #000000; background: transparent;}

#utility  a.navfirst { background: transparent; color: #FFFFFF; display: block; border-left: 0px solid #999999; padding: .2em .5em; text-decoration: none; font-weight: bold;}

#utility a.current.navfirst {color: yellow; background: transparent; border-left: 0px solid #999999;}
#utility a.current.navfirst:hover {color: black; background: transparent; border-left: 0px solid #999999;}

#utility ul li ul {font-size:11px; position: absolute; display: none; top: 15px; margin-bottom: 0; margin-left: 0; margin-right: 0; padding-left: 0; margin-top: .6em; padding-top: 0; z-index:100;}
#utility ul li ul {
* top: 15px;
}
#utility ul li ul.end {right: -1em;}
#utility li > ul { top: auto; left: auto; } /* Opera fix */

#utility li:hover ul, #utility li.over ul  { display: block; z-index: 100; }
#utility li ul li { clear: left; position: relative; float: none;  z-index:100;}
#utility li ul li a {font-weight: normal; width: 15em; border: 1px solid #999; border-top: 0; background: #FFF url(../images/bck-tab-04.png) top repeat-x; color: #000;  z-index:100;}

#utility li ul li a:hover {background: #F3F6F9; color: #cc0000;  z-index:100;}

#content{
width: 950px;
height: 2000px;/*was 1748px;*/
margin:0 auto;
background-color: #efefef;
padding-top:15px;
padding-left:20px;
padding-right:20px;
/*box shaddow on right and left only by Ian L. of jafty.com
 box-shadow: h-shadow v-shadow blur spread color;
*/
    -moz-box-shadow:
        10px 0 10px -10px #333,
        -10px 0 10px -10px #333;
    -webkit-box-shadow:
        10px 0 10px -10px #333,
        -10px 0 10px -10px #333;
    box-shadow:
        10px 0 10px -10px #333,
        -10px 0 10px -10px #333;
/*prevents padding from changing page div's width:*/    
-webkit-box-sizing: border-box; /* Safari/Chrome, other WebKit */
-moz-box-sizing: border-box;    /* Firefox, other Gecko */
box-sizing: border-box;         /* Opera/IE 8+ */
}

hr {
border: none;
border-top: dashed 2px #FF0000;
color: #efefef;
background-color: #efefef;
margin-top:12px;
}

#footer{
width: 100%;
height: 80px;
background-color: #FF0000;
font-weight:bold;
text-align:center;
color:#FFFFFF;
}

/*link styles that you can take out if you don't need:*/
a:link{color: #1414bb; text-decoration: underline;}
a:visited{color: #1414bb; text-decoration: underline;}
a:hover{color:#000000; text-decoration: none;}
a:active{color: #1414bb; text-decoration: underline;}
/*end left over styles*/

Finally Add Content Pages

Now create your first contact page. All of the content pages can be created using the same basic method, so I will just create a simple home page example, so this will be the home.php file that gets saved in your includes directory for your site:

<h1>Home Page Content</h1>
<p>
This is the content that is in the home.php file which can be found in the includes directory. Locate the file to add content to the home page.
</p>

That's all I'll add for now because you will surely want to add your own content to your site, but put that as a placeholder for the home page and create a similar place holder for now for the other pages in the main nav and in the drop-down menus for the nav links if you have any. Create simple placeholders for now and save them in the includes directory. If you have followed along in this tutorial successfully, you should have a web page now that looks like this:

screenshot

 

Format a Phone Number with JavaScript During Input

How to format a ten digit phone number with JavaScript

Recently I had a project where a client wanted all the phone number fields in their forms to be formatted with only numbers and dashes using a standard ten digit phone number. Here is the solution I found that worked best:

The HTML

Phone Number: <input type="text" id="spouseph" name="spouseph" value="" onkeyup="phoneNo(event,this)" />

The JavaScript

//function formats phone numbers like 111-111-1111 during input:
function phoneNo(e,f){
var len = f.value.length;
var key = getKey(e);
if(key>47 && key<58 && len<13)
{
if( len==3 )f.value=f.value+'-'
else if(len==7 )f.value=f.value+'-'
else f.value=f.value;
//see if final number is correct:
var rex = /^[d -]+$/
if(f.value.search(rex)==-1){
alert("Error! Please enter your 10 digit phone number. Dashes will be inserted for you automatically. Only numbers are allowed.");
f.value=f.value.substring(0,len-1);
}

}
else{
f.value=f.value.substring(0,len-1);
}
}
//getKey function used in above phoneNo function
function getKey(e) {
var code;
if (!e) var e = window.event;
if (e.keyCode) code = e.keyCode;
else if (e.which) code = e.which;
return code
//    return String.fromCharCode(code);
}

The getKey function supports the phoneNo function which ensures that users only input numbers and dashes in the proper position. In fact, it inserts the dashes automatically and won't allow more than ten digits or 12 total characters including dashes. Hopefully some of you will find these simple JavaScript phone number validating functions as handy as I did.

NOTE: I found a but in this function with the shift key, it will allow some other characters, so I will work on a solution...

 

 

EmployWorkers.com Virtual Work

Need to hire the perfect coder, designer, developer or graphics specialist? EmployWorkers has all areas of Information technology covered and more.

Virtual employment agency

Where work that needs done, gets done.

Need to find work in the Information Technology field, EmployWorkers.com is for you! We employ all skilled workers in a vast array of areas including, but not limited to graphic design, logo design, Photoshop, web design, web development, application development, special needs coding, PHP, HTML, CSS, SEO, writing of all types, programming of all types and much more. If you need work, visit employworkers.com today and sign up for free. Finding work online has never been easier!

I, Ian L. of Jafty.com have created employworkers.com to fill a niche left open by the buyout of Vworker.com. They had a simpley to use website for posting jobs and finding work. I have expanded on the idea by making it even easier to sign up, post jobs and find work all for free. You never pay a cent, we collect a small percentage of the project price only in cases where a job was completed satisfactory and accepted by the employer. We have a zero risk policy where you don't pay anything until you are satisfied with our services. Money for projects is held in escrow so the worker knows he will be paid once he fulfils his contract with the employer, but employers can dispute at any time they feel there is a breech in the contract and get their escrowed funds returned to them hassle free. Most times you will find that satisfaction is standard however because employworkers.com uses a skilled pool of workers and expertly matches the most qualified workers with your project.

Go ahead and visit EmployWorkers.com today and give it a try whether you are an employer seeking assistance on a project or a worker looking for your next project, we have got you in mind!

System Testing

Understanding System Testing

In the world of software testing, system testing is the testing of a complete and fully integrated software product. System testing falls under the black box testing category of software testing. White box testing is the testing of the internal workings or code of a software application. In contrast, black box or system testing is the opposite. System testing involves the external workings of the software from the user’s perspective. White box testing requires extensive knowledge of the code and software design, but system testing requires no real knowledge of the software development process. It does require extensive knowledge of common black box testing procedures including knowing how to develop test cases and test suites. System testing should be done by people who are very thorough in nature. It is not meant to be done halfheartedly. Thoroughness is the key to good system testing practices.

What is involved in System Testing?

There are several components involved in system testing. Later in the tutorial we will discuss several types of system testing. Here we aim to show you the basic process. There is a test case example later in the tutorial that will help you understand the process. Here is what system testing involves:

  • Black box testing of the finished application before it goes to market.
  • Testing on fully integrated applications in order to test how components interact with one another and with the system as a whole.
  • Very thorough testing of every input in the application to check for required outputs.
  • Testing of the user’s experience with the application from start to finish.
  • Building detailed test cases and test suites that test each aspect of the application as seen from the outside without looking at the actual source code. This is where the name black box testing comes from (you cannot see the insides of a black box).

That is a very basic description of what is involved in system testing. Continue reading to learn more about each item mentioned above and quite a bit more about what system testing is and about what system testing is not.  Sometimes what it is not is just as important is what it is.

System Testing Versus Unit Testing

Let’s explore some of the similarities and differences between Unit Testing and System Testing. In general, unit testing is done during development of the software and system testing is done on the finished product. Also, unit testing is considered white box testing and system testing is black box testing. Those are the major fundamental differences. If we dig deeper we will discover many more differences and some similarities as well.

Differences Between Unit Testing and System Testing

Unit Testing

System Testing

  1. Usually done by the programmer who developed the application.
  2. Done by a testing agent with no prior knowledge of the application.
  1. Is done on small sections of code or individual functions and statements.

 

  1. Is done on the entire application after all its components have been integrated.

  1. Speed is an issue with unit testing because unit tests are commonly run dozens of times a day, sometimes hundreds.
  2. Speed is not as important in system testing because they are not run as many times in a day as unit testing.
  3. The code used to test in Unit testing can be very long, often longer than the actual code being tested
  4. In system testing the code used for testing is not as long as in unit testing and is smaller than the code being tested in most cases.

 

Similarities Between Unit Testing and System Testing

There are many similarities between unit testing and system testing. Although the similar items between the two are often performed in slightly different ways.

To illustrate a similarity of system and unit testing, we could use error testing as an example. In unit testing, additional code could be written to produce an error. We could then see how the application handles that error. If the tester is not happy with the way the error is handled, the source code can be altered to change it. On the other hand, in system testing, errors are thrown on purpose by entering invalid input. There is no code altering done during system testing. If an error is thrown while testing with a valid input, then the application is often returned to the developer to be repaired.

The major similarities of System Testing and Unit Testing are mostly in the general process. Both require a set of objects to be tested, a set of operators, an initial state and a goal state to complete the testing process. The path tested if often similar, but the methods and techniques vary greatly between the two testing types.

Test Cases and Test Suites

In order to test software applications, you must produce test cases. A test case is a set of variables or conditions used in determining whether an application is working properly or not. A group of test cases, known as a test suite, is needed to test any software application. To learn more about test cases for both unit testing and system testing, we have provided you with an example for each below.

Example Application

Below we use a tax calculator application as an example application to demonstrate testing cases for both unit and system testing. The application calculates the Earned Income Credit (EIC) of the user. For demonstration purposes, we will assume that the maximum amount a person can earn to be eligible for EIC is $10,000. Anyone making $10,000 or more will not receive any EIC. Anyone earning less than $10,000 will receive EIC. The relative inputs for the calculator would be the form fields you see in the image provided below:

Snap 2013-02-04 at 14.55.39 systst

Here is a screenshot of the EIC tax calculator that is used in the test cases explained below:

 

The EIC tax calculator in the above image is a web based application written in JavaScript. The process would be similar had it been written in a non-web based language such as C or C++.  We used the calculator in the above image to provide readers with a unit test case example. Below that, we will provide a system test case example.  We aim to demonstrate how each plays an important role in software testing.

Unit Test Case Example:

Testing done during the development of an application is Unit Testing and is done by the programmer on each section of code as it is written. To illustrate a unit test case example, we are going to take the first function of the tax calculator to demonstrate how a tester would perform unit testing on such a function. We will be testing the “contains” function that extends the array prototype in JavaScript. The “contains” function checks an array to see if it contains a specific value. PHP has a built in function for this called “in_array”. JavaScript does not, so we are going to add one to the array prototype. Here is the actual contains function:

Array.prototype.contains = function(obj) {

                var i = this.length;

                while(i--) {

                                if(this[i] === obj) {

                                                return true;

                                }

                }

                return false;

}

In unit testing, a programmer would test this function after adding it to be sure it works. While it’s a simple function, there are still different ways it could be tested.  A common unit testing method is to write another section of code to test it right after writing the function. Another slightly different method is to isolate the function to test it more thoroughly. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to test it by itself.  Below we will examine this method of isolating the code to be tested in detail. It is especially helpful if you aren’t sure you have written the function correctly. You may need to do a little trial and error testing to make it work as intended. Isolating the code helps you find errors. You will know that any errors are coming from the code in question and not some other block of code in the application.

To test the “contains” function, we first build a basic HTML template as its isolated testing environment. Then paste the function in between script tags and save the file as test.html or something similar. Here is what you should have in your new test file:

<script>

//begin contains function:

Array.prototype.contains = function(obj) {

                var i = this.length;

                while(i--) {

                                if(this[i] === obj) {

                                                return true;

                                }

                }

                return false;

}//end contains function.

//test contains function:

 

</script>

Notice how we put comments in the code to help understand what is going on (comments begin with //). Near the bottom of the code we left a space for testing the function. That is where we add our test code next.

In this case our function only requires one parameter, “obj”, which is an array object. Therefore we need an array for testing. The next step in writing our test case would be to create a JavaScript array object as demonstrated here:

// literal array of states that offer EIC

var stateEIC = ["DE", "DC", "IL", "IN", "IA", "KS", "LA", "ME", "MD", "MA", "MI", "MN", "NE", "NJ", "NM", "NY", "NC", "OK", "OR", "RI", "VT", "VA", "WI"];

We have built a literal array containing all states that offer EIC. We chose to use this as our test array because we will also need this array in our program later on. The application will calculate the eligibility for state level EIC by checking this array. If the state the user selected is in the “stateEIC” array, the user would get both state and federal EIC returns. If the user’s state isn’t in the array, they will only get federal EIC (if they meet other qualifying criteria). For this test case, we only need to test if the “contains” function works as required. We do so with a test function call. Next we set up our test inputs. We want one input that will test positive and one that will test negative so we can test all possible outcomes of the function. Set up your variables like this:

var state_1 = "OH";//has no state EIC

var state_2 = "NY";//has state EIC of 30% of fed EIC

 

We set the state_1 variable equal to the state of Ohio. Ohio has no state level EIC. We set the state_2 variable to the state of New York. New York does offer state level EIC. Now we have covered both possible cases for our “contains” function. When we test to see if OH is in the array, it should return false. When we test for NY it should return true. If it does not return the expected values, there is a bug and further trial and error programming is required. Here is what the two test cases should look like:

//TEST CASE 1 - state one test (OH Should return false):

if(stateEIC.contains(state_1)) {

alert(state_1+" has state level EIC");

}else{

alert(state_1+" Does Not have EIC");

}//end test case 1.

 

//TEST CASE 2 - state two test (NY Should return true):

if(stateEIC.contains(state_2)) {

alert(state_2+" has state level EIC");

}else{

alert(state_2+" Does Not have EIC");

}//end test case 2.

Again we clearly commented our code to identify “Test Case 1” and “Test Case 2” so we know what the expected outcome is going to be. If you have followed along in this tutorial, open your test HTML file in a web browser. You could also open the file named test.html [PROVIDE LINK TO DOWNLOAD test.html HERE] that goes with this tutorial. If the test code works you will see the following in your browser after opening the file:

 

Then click “OK” and you should see the following in your browser window next:

 

Above we have provided a very basic Unit Test Case example. Below we will provide a basic System Test Case example. Reading both will give you a pretty good idea of what is involved in each.

System Test Case Example

In system testing you are testing the application as a whole.  The “contains” function used in the unit test case example above would still be tested in system testing. It is just tested in a completely different manner. In system testing, the “contains” function is tested by waiting until the function is used in the finished program. Then the testing agent tests it by making sure it produces the expected output for various tested inputs.  Below we will outline how you would system test the application as a whole.

To begin system testing on our finished EIC calculator we would first plan out what inputs require testing. The inputs requiring testing include:

  • Marital status
  • Number of Children
  • State Input
  • Total Amount Earned
  • The Five inputs under Other Income
  • The Six check boxes

Ultimately in system testing we are testing the finished product to see if it works in accordance with the project requirements. For each of the inputs named above, we need to specify a minimum of two test cases as in the following written test case example:

Input

Test value

Dependencies

Expected  outcome

Notes

Marital Status Single Kids=1, state=NY, income=$9000, all checked Federal EIC = $805State EIC = $223 Passed
Marital Status Married Kids=1, state=NY, income=$9000, all checked Federal EIC = $905State EIC = $424 Passed
Kids 2 Marital=single, state=OH, income=$9000, all checked Federal  EIC= $1090State EIC = $560 Passed
Kids 3 Marital=single, state=OH, income=$9000, all checked Federal  EIC= $1490State EIC = $760 Passed
State OH Marital=married, Kids=1, income=$9000, all checked Federal  EIC= $1090State EIC = $0 Passed
State NJ Marital=married, Kids=1, income=$9000, all checked Federal  EIC= $7090State EIC = $560 passed
Income 9999 Marital=married, Kids=1, state=OH, , all checked Federal  EIC= $0State EIC = $0 Expected outcome was wrong check income variables
Income 10000 Marital=married, Kids=1, state=OH, , all checked Federal  EIC= $0State EIC = $0 passed

 

In the above table we have laid out some of the first of several test case scenarios necessary to complete system testing on the final software solution. If we were actually testing you would want to test every possible combination of input values. The above example is only a start.

In the first column we name the target input being testing. The inputs directly correspond with the form input fields as you can see in the image above. In the second column, we specify the test value to set the input to for this test case. In the third column we list what the other inputs must be set to in order to get the expected outcome according to the project requirements. In the fourth column we recorded the actual output the application produced when using the described inputs. In the last column we add our testing notes to record whether the test was a success or a failure and why. In system testing, the person doing the testing usually isn’t the one that fixes errors. That is why it’s necessary to record the outcome of each test. Any errors found are passed on to the developer so they can be fixed.

 

The Software Testing Hierarchy

As with almost any technical process, software testing has a prescribed order in which things should be done. The following is a list of software testing stages arranged in chronological order. These are the steps taken to fully test new software in preparation for marketing it:

  1. Unit testing – testing performed on each module or block of code during development. Unit testing is normally done by the programmer who writes the code.
  2. Integration testing – testing done before, during and after integration of a new module into the main software package. This involves testing of each individual code module. One piece of software can contain several modules which are often created by several different programmers. It is crucial to test each module’s effect on the entire program model.
  3. System testing – testing done by a professional testing agent on the completed software product before it is introduced to the market.
  4. Acceptance testing – beta testing of the product done by the actual end users.

What Types of System Testing Should Testers Use?

There are over twenty different types of system testing. The specific types used by a testing agent depend on several variables. Those variables include:

  • Who the testing agent works for – This is a major factor in determining the types of system testing a tester will use. Different methods are used by larger companies than are used by medium and smaller companies.
  • Time available for testing – Ultimately, all twenty some testing types could be used. Time is often what limits us to using only the types that are most relevant for each individual test case.
  • Resources available to the tester – Of course some testers will not have all types available to them. For example if you are a tester working for a large software development firm, you are likely to have expensive automated testing software not available to others.
  • Testing Agent’s Education – There is a certain learning curve for each type of software testing available. To use some of the software involved, a tester has to learn how to use it. To do manual testing, a tester needs to learn different techniques as well.
  • Testing Budget – Money becomes a factor for smaller companies and individual software developers. Often testers cannot afford some of the testing types used by larger companies.

Those are just a few examples of how different types of testing are selected by testers.  Ultimately a tester should add as many types to their test suite as possible. Below we have listed typical types of system testing a large software development company might use. We took these examples from a paper written for IBM. Here are the types of system testing IBM typically uses during system testing:

  1. Usability Testing – Usability testing is done to determine whether or not the software is going to be easy enough for the targeted user
  2. Stress Testing – Also known as load testing, stress testing is necessary to know that a software solution will perform under real life situations.
  3. Regression Testing – Regression testing involves testing done to make sure none of the changes made over the course of the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new software modules over time. Regression testing’s more complex techniques can even attempt to prevent future issues caused by the expansion of a software application down the road. It could be argued the regression testing could be part of integration testing. Realistically, it has its place in both.
  4. Recovery Testing – Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes.
  5. Serviceability Testing – This type of testing is simply to ensure that the application can be serviced as easily as possible.
  6. Migration Testing – Migration testing is done to ensure that the software can be moved from older system infrastructures to current system infrastructures without any issues.
  7. Functional Testing – Also known as functional completeness testing, functional testing involves trying to think of any possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it during functional testing.
  8. Hardware/Software Testing – IBM refers to Hardware/Software testing as “HW/SW Testing”. This is when the testing agent focusses their attention on the interactions between the hardware and software during system testing.

You may have noticed that there are only eight types of system testing above. Those are the ones large companies such as IBM are most likely to focus on during system testing procedures. If you are working for a small company or a private developer, the types you use will differ from those of a large company like IBM. There are always valuable lessons to take from a giant company like IBM who has essentially dominated the software market.

 

Automated Planning Systems (APS)

An Automated Planning System or APS is an automated system that plans test cases for software. The large number of test cases needed for some applications would be staggering without an APS. Planning techniques were taken from Artificial Intelligence specialists to develop APS systems that can develop a complete test suite in no time at all. These test suites are then used for testing applications such as the tax calculator above or a GUI. An APS is based on the following four parameters:

  1. Set of objects – first we must have a set of objects to test. The set of objects consist of the parts of the application being tested. An example from our tax calculator test case would be the marital status input. That would be one of the objects needing testing.
  2. Set of operators – An APS making test cases would figure out all the possible operations of the user interface (set of objects). It would then use those operations as the set of operators. The set of operators are used to plan a path from the initial state to the goal state explained below.
  3. Initial State – After the operators are determined, the systems default state is determined. This is known as the operator’s initial state.
  4.  Goal State – Finally, after the initial state is set, a goal state must be determined. The goal state is chosen that will best exercise the system.

A good example of an Automatic Planning System would be TestComplete, APS software from Smart Bear Software. There are many others available at a cost as well. Searching for Freeware APS software will produce some results but not as many as you would hope for. The quality and usability of Freeware APS systems vary from barely usable to satisfactory.

Practical System Testing

Automated System Testing is practical only if you can afford the tools and justify the costs. The truth of the matter is that most small to medium software developers do their own manual system testing. It can be stressful and time consuming at times, but you can get the job done by developing good test cases that you can perfect over time. Developers will often develop their own test suite if they do a lot of system testing. Remember the routines you use and perfect them. If you make your own test cases, you will find that many of them can be recycled and used on other applications in the future.

 

 

 

 

Understanding System Testing

In the world of software testing, system testing is the testing of a complete and fully integrated software product. System testing falls under the black box testing category of software testing. White box testing is the testing of the internal workings or code of a software application. In contrast, black box or system testing is the opposite. System testing involves the external workings of the software from the user’s perspective. White box testing requires extensive knowledge of the code and software design, but system testing requires no real knowledge of the software development process. It does require extensive knowledge of common black box testing procedures including knowing how to develop test cases and test suites. System testing should be done by people who are very thorough in nature. It is not meant to be done halfheartedly. Thoroughness is the key to good system testing practices.

What is involved in System Testing?

There are several components involved in system testing. Later in the tutorial we will discuss several types of system testing. Here we aim to show you the basic process. There is a test case example later in the tutorial that will help you understand the process. Here is what system testing involves:

·         Black box testing of the finished application before it goes to market.

·         Testing on fully integrated applications in order to test how components interact with one another and with the system as a whole.

·         Very thorough testing of every input in the application to check for required outputs.

·         Testing of the user’s experience with the application from start to finish.

·         Building detailed test cases and test suites that test each aspect of the application as seen from the outside without looking at the actual source code. This is where the name black box testing comes from (you cannot see the insides of a black box).

That is a very basic description of what is involved in system testing. Continue reading to learn more about each item mentioned above and quite a bit more about what system testing is and about what system testing is not.  Sometimes what it is not is just as important is what it is.

System Testing Versus Unit Testing

Let’s explore some of the similarities and differences between Unit Testing and System Testing. In general, unit testing is done during development of the software and system testing is done on the finished product. Also, unit testing is considered white box testing and system testing is black box testing. Those are the major fundamental differences. If we dig deeper we will discover many more differences and some similarities as well.

Differences Between Unit Testing and System Testing

Unit Testing

System Testing

1.       Usually done by the programmer who developed the application.

1.       Done by a testing agent with no prior knowledge of the application.

2.       Is done on small sections of code or individual functions and statements.

 

2.       Is done on the entire application after all its components have been integrated.

3.       Speed is an issue with unit testing because unit tests are commonly run dozens of times a day, sometimes hundreds.

3.       Speed is not as important in system testing because they are not run as many times in a day as unit testing.

4.       The code used to test in Unit testing can be very long, often longer than the actual code being tested

4.       In system testing the code used for testing is not as long as in unit testing and is smaller than the code being tested in most cases.

 

Similarities Between Unit Testing and System Testing

There are many similarities between unit testing and system testing. Although the similar items between the two are often performed in slightly different ways.

To illustrate a similarity of system and unit testing, we could use error testing as an example. In unit testing, additional code could be written to produce an error. We could then see how the application handles that error. If the tester is not happy with the way the error is handled, the source code can be altered to change it. On the other hand, in system testing, errors are thrown on purpose by entering invalid input. There is no code altering done during system testing. If an error is thrown while testing with a valid input, then the application is often returned to the developer to be repaired.

The major similarities of System Testing and Unit Testing are mostly in the general process. Both require a set of objects to be tested, a set of operators, an initial state and a goal state to complete the testing process. The path tested if often similar, but the methods and techniques vary greatly between the two testing types.

Test Cases and Test Suites

In order to test software applications, you must produce test cases. A test case is a set of variables or conditions used in determining whether an application is working properly or not. A group of test cases, known as a test suite, is needed to test any software application. To learn more about test cases for both unit testing and system testing, we have provided you with an example for each below.

Example Application

Below we use a tax calculator application as an example application to demonstrate testing cases for both unit and system testing. The application calculates the Earned Income Credit (EIC) of the user. For demonstration purposes, we will assume that the maximum amount a person can earn to be eligible for EIC is $10,000. Anyone making $10,000 or more will not receive any EIC. Anyone earning less than $10,000 will receive EIC. The relative inputs for the calculator would be the form fields you see in the image provided below:

Here is a screenshot of the EIC tax calculator that is used in the test cases explained below:

The EIC tax calculator in the above image is a web based application written in JavaScript. The process would be similar had it been written in a non-web based language such as C or C++.  We used the calculator in the above image to provide readers with a unit test case example. Below that, we will provide a system test case example.  We aim to demonstrate how each plays an important role in software testing.

Unit Test Case Example:

Testing done during the development of an application is Unit Testing and is done by the programmer on each section of code as it is written. To illustrate a unit test case example, we are going to take the first function of the tax calculator to demonstrate how a tester would perform unit testing on such a function. We will be testing the “contains” function that extends the array prototype in JavaScript. The “contains” function checks an array to see if it contains a specific value. PHP has a built in function for this called “in_array”. JavaScript does not, so we are going to add one to the array prototype. Here is the actual contains function:

Array.prototype.contains = function(obj) {

                var i = this.length;

                while(i--) {

                                if(this[i] === obj) {

                                                return true;

                                }

                }

                return false;

}

In unit testing, a programmer would test this function after adding it to be sure it works. While it’s a simple function, there are still different ways it could be tested.  A common unit testing method is to write another section of code to test it right after writing the function. Another slightly different method is to isolate the function to test it more thoroughly. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to test it by itself.  Below we will examine this method of isolating the code to be tested in detail. It is especially helpful if you aren’t sure you have written the function correctly. You may need to do a little trial and error testing to make it work as intended. Isolating the code helps you find errors. You will know that any errors are coming from the code in question and not some other block of code in the application.

To test the “contains” function, we first build a basic HTML template as its isolated testing environment. Then paste the function in between script tags and save the file as test.html or something similar. Here is what you should have in your new test file:

<script>

//begin contains function:

Array.prototype.contains = function(obj) {

                var i = this.length;

                while(i--) {

                                if(this[i] === obj) {

                                                return true;

                                }

                }

                return false;

}//end contains function.

//test contains function:

 

</script>

Notice how we put comments in the code to help understand what is going on (comments begin with //). Near the bottom of the code we left a space for testing the function. That is where we add our test code next.

In this case our function only requires one parameter, “obj”, which is an array object. Therefore we need an array for testing. The next step in writing our test case would be to create a JavaScript array object as demonstrated here:

// literal array of states that offer EIC

var stateEIC = ["DE", "DC", "IL", "IN", "IA", "KS", "LA", "ME", "MD", "MA", "MI", "MN", "NE", "NJ", "NM", "NY", "NC", "OK", "OR", "RI", "VT", "VA", "WI"];

We have built a literal array containing all states that offer EIC. We chose to use this as our test array because we will also need this array in our program later on. The application will calculate the eligibility for state level EIC by checking this array. If the state the user selected is in the “stateEIC” array, the user would get both state and federal EIC returns. If the user’s state isn’t in the array, they will only get federal EIC (if they meet other qualifying criteria). For this test case, we only need to test if the “contains” function works as required. We do so with a test function call. Next we set up our test inputs. We want one input that will test positive and one that will test negative so we can test all possible outcomes of the function. Set up your variables like this:

var state_1 = "OH";//has no state EIC

var state_2 = "NY";//has state EIC of 30% of fed EIC

 

We set the state_1 variable equal to the state of Ohio. Ohio has no state level EIC. We set the state_2 variable to the state of New York. New York does offer state level EIC. Now we have covered both possible cases for our “contains” function. When we test to see if OH is in the array, it should return false. When we test for NY it should return true. If it does not return the expected values, there is a bug and further trial and error programming is required. Here is what the two test cases should look like:

//TEST CASE 1 - state one test (OH Should return false):

if(stateEIC.contains(state_1)) {

alert(state_1+" has state level EIC");

}else{

alert(state_1+" Does Not have EIC");

}//end test case 1.

 

//TEST CASE 2 - state two test (NY Should return true):

if(stateEIC.contains(state_2)) {

alert(state_2+" has state level EIC");

}else{

alert(state_2+" Does Not have EIC");

}//end test case 2.

Again we clearly commented our code to identify “Test Case 1” and “Test Case 2” so we know what the expected outcome is going to be. If you have followed along in this tutorial, open your test HTML file in a web browser. You could also open the file named test.html [PROVIDE LINK TO DOWNLOAD test.html HERE] that goes with this tutorial. If the test code works you will see the following in your browser after opening the file:

oo

Then click “OK” and you should see the following in your browser window next:

pp

Above we have provided a very basic Unit Test Case example. Below we will provide a basic System Test Case example. Reading both will give you a pretty good idea of what is involved in each.

System Test Case Example

In system testing you are testing the application as a whole.  The “contains” function used in the unit test case example above would still be tested in system testing. It is just tested in a completely different manner. In system testing, the “contains” function is tested by waiting until the function is used in the finished program. Then the testing agent tests it by making sure it produces the expected output for various tested inputs.  Below we will outline how you would system test the application as a whole.

To begin system testing on our finished EIC calculator we would first plan out what inputs require testing. The inputs requiring testing include:

·         Marital status

·         Number of Children

·         State Input

·         Total Amount Earned

·         The Five inputs under Other Income

·         The Six check boxes

Ultimately in system testing we are testing the finished product to see if it works in accordance with the project requirements. For each of the inputs named above, we need to specify a minimum of two test cases as in the following written test case example:

Input

Test value

Dependencies

Expected  outcome

Notes

Marital Status

Single

Kids=1, state=NY, income=$9000, all checked

Federal EIC = $805

State EIC = $223

Passed

Marital Status

Married

Kids=1, state=NY, income=$9000, all checked

Federal EIC = $905

State EIC = $424

Passed

Kids

2

Marital=single, state=OH, income=$9000, all checked

Federal  EIC= $1090

State EIC = $560

Passed

Kids

3

Marital=single, state=OH, income=$9000, all checked

Federal  EIC= $1490

State EIC = $760

Passed

State

OH

Marital=married, Kids=1, income=$9000, all checked

Federal  EIC= $1090

State EIC = $0

Passed

State

NJ

Marital=married, Kids=1, income=$9000, all checked

Federal  EIC= $7090

State EIC = $560

passed

Income

9999

Marital=married, Kids=1, state=OH, , all checked

Federal  EIC= $0

State EIC = $0

Expected outcome was wrong check income variables

Income

10000

Marital=married, Kids=1, state=OH, , all checked

Federal  EIC= $0

State EIC = $0

passed

In the above table we have laid out some of the first of several test case scenarios necessary to complete system testing on the final software solution. If we were actually testing you would want to test every possible combination of input values. The above example is only a start.

In the first column we name the target input being testing. The inputs directly correspond with the form input fields as you can see in the image above. In the second column, we specify the test value to set the input to for this test case. In the third column we list what the other inputs must be set to in order to get the expected outcome according to the project requirements. In the fourth column we recorded the actual output the application produced when using the described inputs. In the last column we add our testing notes to record whether the test was a success or a failure and why. In system testing, the person doing the testing usually isn’t the one that fixes errors. That is why it’s necessary to record the outcome of each test. Any errors found are passed on to the developer so they can be fixed.

 

The Software Testing Hierarchy

As with almost any technical process, software testing has a prescribed order in which things should be done. The following is a list of software testing stages arranged in chronological order. These are the steps taken to fully test new software in preparation for marketing it:

1.       Unit testing – testing performed on each module or block of code during development. Unit testing is normally done by the programmer who writes the code.

2.       Integration testing – testing done before, during and after integration of a new module into the main software package. This involves testing of each individual code module. One piece of software can contain several modules which are often created by several different programmers. It is crucial to test each module’s effect on the entire program model.

3.       System testing – testing done by a professional testing agent on the completed software product before it is introduced to the market.

4.       Acceptance testing – beta testing of the product done by the actual end users.

 What Types of System Testing Should Testers Use?

There are over twenty different types of system testing. The specific types used by a testing agent depend on several variables. Those variables include:

·         Who the testing agent works for – This is a major factor in determining the types of system testing a tester will use. Different methods are used by larger companies than are used by medium and smaller companies.

·         Time available for testing – Ultimately, all twenty some testing types could be used. Time is often what limits us to using only the types that are most relevant for each individual test case.

·         Resources available to the tester – Of course some testers will not have all types available to them. For example if you are a tester working for a large software development firm, you are likely to have expensive automated testing software not available to others.

·         Testing Agent’s Education – There is a certain learning curve for each type of software testing available. To use some of the software involved, a tester has to learn how to use it. To do manual testing, a tester needs to learn different techniques as well.

·         Testing Budget – Money becomes a factor for smaller companies and individual software developers. Often testers cannot afford some of the testing types used by larger companies.

Those are just a few examples of how different types of testing are selected by testers.  Ultimately a tester should add as many types to their test suite as possible. Below we have listed typical types of system testing a large software development company might use. We took these examples from a paper written for IBM. Here are the types of system testing IBM typically uses during system testing:

1.       Usability Testing – Usability testing is done to determine whether or not the software is going to be easy enough for the targeted user

2.       Stress Testing – Also known as load testing, stress testing is necessary to know that a software solution will perform under real life situations.

3.       Regression Testing – Regression testing involves testing done to make sure none of the changes made over the course of the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new software modules over time. Regression testing’s more complex techniques can even attempt to prevent future issues caused by the expansion of a software application down the road. It could be argued the regression testing could be part of integration testing. Realistically, it has its place in both.

4.       Recovery Testing – Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes.

5.       Serviceability Testing – This type of testing is simply to ensure that the application can be serviced as easily as possible. 

6.       Migration Testing – Migration testing is done to ensure that the software can be moved from older system infrastructures to current system infrastructures without any issues.

7.       Functional Testing – Also known as functional completeness testing, functional testing involves trying to think of any possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it during functional testing.

8.       Hardware/Software Testing – IBM refers to Hardware/Software testing as “HW/SW Testing”. This is when the testing agent focusses their attention on the interactions between the hardware and software during system testing.

You may have noticed that there are only eight types of system testing above. Those are the ones large companies such as IBM are most likely to focus on during system testing procedures. If you are working for a small company or a private developer, the types you use will differ from those of a large company like IBM. There are always valuable lessons to take from a giant company like IBM who has essentially dominated the software market.

 

Automated Planning Systems (APS)

An Automated Planning System or APS is an automated system that plans test cases for software. The large number of test cases needed for some applications would be staggering without an APS. Planning techniques were taken from Artificial Intelligence specialists to develop APS systems that can develop a complete test suite in no time at all. These test suites are then used for testing applications such as the tax calculator above or a GUI. An APS is based on the following four parameters:

1.       Set of objects – first we must have a set of objects to test. The set of objects consist of the parts of the application being tested. An example from our tax calculator test case would be the marital status input. That would be one of the objects needing testing.

2.       Set of operators – An APS making test cases would figure out all the possible operations of the user interface (set of objects). It would then use those operations as the set of operators. The set of operators are used to plan a path from the initial state to the goal state explained below.

3.       Initial State – After the operators are determined, the systems default state is determined. This is known as the operator’s initial state.

4.        Goal State – Finally, after the initial state is set, a goal state must be determined. The goal state is chosen that will best exercise the system.

A good example of an Automatic Planning System would be TestComplete, APS software from Smart Bear Software. There are many others available at a cost as well. Searching for Freeware APS software will produce some results but not as many as you would hope for. The quality and usability of Freeware APS systems vary from barely usable to satisfactory.

Practical System Testing

Automated System Testing is practical only if you can afford the tools and justify the costs. The truth of the matter is that most small to medium software developers do their own manual system testing. It can be stressful and time consuming at times, but you can get the job done by developing good test cases that you can perfect over time. Developers will often develop their own test suite if they do a lot of system testing. Remember the routines you use and perfect them. If you make your own test cases, you will find that many of them can be recycled and used on other applications in the future.

 

Unit Testing

What is Unit Testing?

Unit testing of software applications is done during the development of an application. The object of unit testing is to isolate a section of code and verify its correctness. This is normally performed by the programmer on each section of code as it is written. Intimate knowledge of the source code is required. In “unit testing”, a unit is the smallest testable section of source code there is. When building an application a coder typically writes small sections of code for each process required to make the application work according to the specs.  The coder tests each section of code immediately after it’s written. This keeps the application running smooth at every stage of its development. Unit testing is performed throughout the development process in order to reduce the amount of testing needed later in the software development lifecycle.

Why do Exhaustive Unit Testing

Sometimes software developers attempt to save time and money by doing minimal unit testing. This is not possible because skimping on unit testing leads to higher costs during system testing, integration testing and even beta testing after the application is completed. Proper unit testing done during the development stage saves both time and money in the end.

Unit Test Case Example:

To illustrate a unit test case example, imagine we are coding a web application to register users to a website. The first actions of this application do nothing but ask the user their name and print it to the screen.  The HTML code would look like this:

What is your name? <input type=”text” id=”name” name=”name” />

<input type=”button” value=”Submit Name” onclick=”call_by_name()” />

 

In unit testing every small line of code that can be tested should be testing. Therefore, the coder would write the above two lines of code, save the file as an HTML file and open it in a web browser to make sure it works. If they spot an error, they fix it immediately before continuing. Then they would write the next logical step for the application which in this case would be the call_by_name JavaScript function.  If you look at the HTML code, call_by_name is called from the button element created in the second line of HTML code above. That function might look like this:

function call_by_name(){

var name = document.getElementById(‘name’).value;

alert(“Hello ”+name+” nice to meet you!!!”);

}//end call_by_name function.

 

In unit testing, a programmer would test this function after adding it. This simple function could easily be tested by saving the file, opening it and pressing the button on the webpage. If no errors occurred, they would see a popup greeting as in the below image. If an error was found they would fix it on the spot before continuing,

Building Test Cases

In the above simple examples we demonstrated a couple of the simplest test cases possible. All the coder had to do in order to test the code was to write it, save it and open it. Unit testing is not always such an easy process.  For example, what if you have to write a function that relies on other functions to operate? The code should still be tested. This is where more complex test cases and test suites come into play. In unit testing, a smaller scale software developer would probably be limited to manually testing software. To manually test a more complex function there are a couple options.

  • A developer could write another section of code in the application just to test the function. They would later comment out and finally remove the test code when the application is done.
  • They could also isolate the function to test it more thoroughly. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to test it by itself. This basically involves building a separate small application just for testing purposes. Isolating the code helps the programmer to know whether any errors are caused by the code in question or some other block of code in the application.

Sometimes a code might try the first method and graduate the second method if errors occur that require more extensive testing. Unit testing is necessary after each block of code is written because not doing so makes errors much harder to track. Imagine if you had several functions that depend on one another to operate. If there is an error and each function was not tested during development, the tester would have no way of knowing which section of code the error is in.

 

Mock Objects

Unit testing relies on mock objects being created to test sections of code that are not yet part of a complete application. Mock objects fill in for the missing parts of the program. For example, you might have a function that needs variables or objects that are not created yet. In unit testing, those will be accounted for in the form of mock objects created solely for the purpose of the unit testing done on that section of code.

Unit testing in Procedural Programming & Object Oriented Programming

Unit testing methods vary according the programming style being used. In our above example we used procedural programing (programming developed on the fly without using prewritten classes or objects). In procedural programming unit testing is done on very small sections of code as demonstrated in the above examples. Object Oriented Programming or OOP is programming using classes or object modules that are often prewritten and reused in other programs. Unit testing in OOP languages sometimes has to be done on larger sections of code particularly when reusing an existing class or object module. OOP is based on recycling code. Sometimes the classes used have already been tested. This means there may be fewer errors, but testing is still necessary after adding each class or code snippet to ensure seamless integration with other code and the system as a whole(as in integration testing).

Unit Testing Tools

There are several automated tools available to assist with unit testing. We will provide a few examples below:

  • Rational Software – Rational Software by IBM has a unit test feature known as “Rational Test Realtime”. The software contains a complete range of testing tools for much more than just unit testing. It is used for Ada, Java, C and C++. It creates unit tests by reverse engineering the software.  Operating systems it supports include Windows, Linux, Solaris, HP-UX and AIX. Go to http://www-01.ibm.com/software/rational/ to learn more.
  • JavaScript Assertion Unit– Also known as jsAsserUnit, this Freeware JavaScript unit testing tool can be used on any platform that supports JavaScript. It is available at http://jsassertunit.sourceforge.net/docs/index.html
  • CUT – CUT is a Freeware unit test tool for C, C++ and Objective C. It is great for embedded software testing frameworks and desktop applications on Linux and Windows operating systems. Learn more at sourceforge.net by going to http://sourceforge.net/projects/cut/.
  • Dotunit – Dotunit is a .net framework Freeware unit testing tool. Part of Junit on the Microsoft .net framework, Dotunit is used for automating unit testing on windows systems. This is another tool from sourceforge.net, so look for it at: http://dotunit.sourceforge.net/

Those are just a few of the available unit testing tools. There are lots more, especially for C languages and Java, but you are sure to find a unit testing tool for your programming needs regardless of the language you use.

Test Environments

Unit testing is often done on the local system. A closed local testing environment is needed that is not part of a network for safety reasons and to eliminate possible outside influences. This is particularly true in preliminary testing. After preliminary testing is done in an isolated local environment, more testing can be done in an open network environment such as on a local intranet or the World Wide Web.

Extreme Programming & Testing Frameworks

Unit testing in Extreme Programming, a programming philosophy that leaves no stone unturned, involves the extensive use of testing frameworks. A unit test framework is used in order to create automated unit tests. Unit testing frameworks are not unique to extreme programming, but they are essential to it. A unit testing framework is not just for testing either. They are often very powerful development tools as well. Below we look at some of what extreme programming brings to the world of unit testing:

  • Tests are written before the code
  • Rely heavily on testing frameworks
  • All classes in the applications are tested
  • Quick and easy integration is made possible

 

Testing frameworks were first developed by Kent Beck in 1994. Kent Beck wrote the first automated testing frameworks for Smalltalk. Smalltalk was an object-oriented language developed in the 1970s and made popular in the 1980s. Testing frameworks have since been ported over to dozens of different programming languages and frameworks. Kent Beck’s original testing framework was based on the same basic principles used today. He used an object-oriented approach to programming tests based on the following three main objects:

  • Test cases – Manage the execution of one test
  • Test suites – A group of test cases that all work together
  • Test results – A report of all the results from test cases and test suites. Statistical reports are made possible with test suites.

Summary

As you can see, there can be a lot involved in unit testing. It can be complex or rather simple depending on the application being tested and the testing strategies, tools and philosophies used. Unit testing is always necessary on some level. That is a certainty.

 

 

 

White Box Testing

White Box Testing

Introduction

White Box Testing is the testing of a software solution’s internal coding and infrastructure. It focuses primarily on strengthening security, the flow of inputs and outputs through the application, design and usability. White box testing is also known as clear, open, structural, and glass box testing. It is one of two parts of the “box testing” approach of software testing. Its counter-part, black box testing, involves testing from an external or end-user type perspective. On the other hand, White box testing is based on the inner workings of an application and revolves around internal testing. The term “white box” was used because of the see-through box concept. The clear box or white box name symbolizes the ability to see through the software’s outer shell (or “box”) into its inner workings. Likewise, the “black box” in “black box testing” symbolizes not being able to see the inner workings of the software so that only the end-user experience can be tested.

A person performing white box testing on an application will require access to its source code. There are several aspects of testing conducted during white box testing. We will cover the most relevant ones in this article. White box testing needs to be done by highly educated computer coding professionals because extensive coding knowledge is needed to perform this type of software testing.

What is Involved in White Box Testing

White box testing involves the testing of the software code for the following:

  • Internal security holes
  • Broken or poorly structured paths in the coding processes
  • The flow of specific inputs through the coding infrastructure
  • Expected output
  • The functionality of conditional loops
  • Testing of each statement, object and function on an individual basis

The testing can be done at system, integration and unit levels of software development. One of the basic goals of white box testing is to verify a working flow for an application. It involves testing a series of predefined inputs against expected or desired outputs so that when a specific input does not result in the expected output, you have encountered a bug.

Three Main Steps in White Box Testing

To give you a simplified explanation of white box testing, we have divided it into three basic steps. This is what testers do when testing an application using the white box testing technique:

  1. The first thing a tester will often do is learn and understand the source code of the application. Since white box testing involves the testing of the inner workings of an application, the tester must be very knowledgeable in the programming languages used in the applications they are testing. Also, the testing person must be highly aware of secure coding practices. Security is often one of the primary objectives of testing software. Ultimately the person performing white box testing on any software application should be a programmer in the coding language used and a security expert. The tester should be able to find security issues and prevent attacks from hackers and unknowing users who might inject malicious code into the application either knowingly or blindly. Security is always going to be a major issue in software development and testing.
  2. The second basic step to white box testing involves testing the application’s source code for proper flow and structure. There are a couple ways in which this can be done. One way is by writing more code to test the application’s source code. The tester will develop little tests for each process or series of processes in the application. That method requires that the tester must have intimate knowledge of the code and is often done by the developer. Other methods include manual testing, trial and error testing and the use of testing tools as we will explain further on in this article.
  3. Finally, the third major step involves knowing, understanding and using the various tools involved in white box testing. We will explain several different types of white box testing below. These are the types of things a qualified tester would need to know to perform their job properly.

The three above steps were written just to provide a very basic point of view regarding the white box testing procedure. The actual process can only be truly understood by learning each of the types and techniques involved. The list of prerequisites necessary to become a professional white box tester might seem staggering to some. More experienced software developers could pick up on the testing techniques fairly quickly because knowing the coding languages is a large percentage of the work.

Types of White Box Testing

White box testing encompasses several testing techniques used to evaluate the usability of an application, block of code or specific software package. There are several testing types involved in white-box testing. A few types, such as integration testing and functional testing are types of testing for both black-box and white-box testing. We have listed the ones that fall into both categories simultaneously at the top of the list below. Then we list types for white-box testing alone.

Integration Testing – Integration testing involves testing of code at each level of integration with a larger software component. For example, a programmer might write a new function to pull data from a database and display a table in your application. Unit testing is done on the code during development. Then, integration testing is done when melding the code with the larger software application to be sure it didn’t cause any unwanted behavior in your software. Integration tests are done in black box testing also.

 

 

Integration Testing – Black Box versus White Box Methods

Let’s imagine that a programmer has written a chat application. A month later he or she decided to add emoticons to it. This is a good example of a situation requiring integration testing. Both black box and white box testing would need to be done during integration testing. Below are examples of each as it would relate to the chat engine scenario where the programmer adds an emoticon module after the chat engine was completed.

White box integration test example – White box integration testing is normally done by the programmer or application developer. First, the programmer would test the chat application to be certain it works before doing the integration. Testing would be done using several of the testing types described in this article. Then the programmer would write the code to add the emoticons to the chat application. The programmer would then test the new emoticon module before integrating it with the chat application. Finally, the programmer adds the new emoticon module and tests the chat application with the emoticons added. The tests the programmer does during integration testing are similar to the tests done during development of any code. They may use automated tools to perform testing. They may also develop additional code to test the code they wrote in the first place. Whatever methods the programmer uses, they must test before, during and after integration.

Black box integration test example – Integration testing in the black box scenario is quite different. The testing is often done by a testing specialist rather than the programmer. The tester would first test the chat engine before the emoticon module was added. The tester would test the functionality of the application rather than the inner workings. He or she would only test what can be testing without altering code or getting involved in anything inside the program basically. Things they can test would include how the chat application performs from the user point of view and how fast do messages take to reach the other party. They would run similar tests before and after integration, but not during as in white box testing. Finally they could compare the before and after tests to determine the performance impact that adding emoticons had on the chat application.

Penetration Testing/Security Testing- Security testing is perhaps one of the most important and toughest of the testing types because the tester needs to act as an aggressor, attacking the code from several angles attempting to penetrate the database, cause malicious results or otherwise cause damage to the code or damage to the user’s computer using the code as a tool. This is commonly known as penetration testing. Testers try to hack the code before hackers get the chance. They code in preventative measures to the software’s more vulnerable areas making the code more secure from hackers and other known security threats. There are some tools available to assist coders and testers with penetration testing. One example of a penetration testing tool for web application developers is the Firefox web browser which has built in penetration testing tools. Other penetration testing tools include port scanners, vulnerability scanners and application scanners. Each tool has a specific goal. Port scanners will check network ports for possible weak points while application scanners will attempt a variety of known attacks of the software.

Penetration testing has several levels at which it can be performed. The levels relate directory to white box testing and black box testing. Different amounts of information are provided to the tester at each level of penetration testing. While there could be numerous levels of penetration testing, we choose to describe three here. The basic levels could be described using the following examples:

White box penetration testing – This is an example of a level of penetration testing where the tester is provided with the most information regarding the application being tested. For example, they would have full access to the application’s source code, detailed network information, IP addresses involved and all server information the application runs on. In White box penetration testing the tester is often the programmer and usually also has full disclosure regarding the application being tested.

Black box penetration testing – This is a level of penetration testing where the tester has only minimal access and information regarding the application being tested. Basically, this is when the tester is handed the application and told to perform testing with no prior knowledge of the application’s existence. He or she must determine ways to penetrate the application without prior knowledge of its infrastructure or functionalities.

Grey box penetration testing – Grey box penetration testing would be when a testing agent has limited prior knowledge of the application being tested. The exact level could be anywhere in between the black and white box penetration testing scenarios. The tester could know very little to almost everything. Grey box testing is when the tester has partial disclosure but not full disclosure as they would in the white box example.

 

Mutation Testing/Regression Testing – Mutation tests, also known as regression tests are run on code after changes or bug fixes are performed on the code. It is common to find new bugs or problems with an application after a bug has been fixed or other changes have been made to the code. Mutation testing is often used to discover the best coding techniques to use for expanding a software solution by the adding additional code to expand the applications functionalities for the end user. Like integration testing, Regression or Mutation testing can be done in both white box and black box testing.

Functional Testing – Also done in both white box and black box testing, functional testing involves the testing of coding processes while concentrating on the functionality of the application. The end-user experience should always be taken into consideration when testing any application. As part of functional testing procedures, a tester has to be sure that output is understood by both the program itself and the person using it.

Unit Testing – Unit testing is fittingly the first type of code we will discuss because it often the first type of testing done on an application. Unit testing is performed on each unit or block of code as it is developed. Without unit testing, further testing types would be much more difficult because there would be many more bugs found. When unit testing is performed, the majority of the software’s bugs can be caught in the development phase of the development process. Unit testing is essentially done by the programmer (whether they call it that or not) because, as a developer, you develop a few lines of code, a single function or an object and test it to make sure it works before continuing. That way you know your solution will work when it is pieced together one module at a time. If a software developer were to continue coding without doing unit testing along the way, problems would be much more difficult to trace. Tracing the source of a problem when it presents itself is much easier when you can rule out previously written sections of code because you have already tested them.

Testing for Memory Leaks – Memory leaks are leading causes of slower running applications. A testing agent who is experienced at detecting memory leaks is essential in cases where you have a slow running software application. Tools are available to assist testers with memory leak testing. Such A tool for testing C and C++ applications for memory leaks is called Valgrind.

Statement Coverage Testing – This type of testing is performed using methods that allow for every possible statement in the code to be tested at least once during the testing process.  There are several tools available to testers that will assist them with statement coverage testing. Certain tools will report the number of executable statements to help in the testing process. Testers also build custom applets to perform statement coverage testing in many cases. An example of a tool that handles statement coverage testing for C++ applications is Cantata++, a tool you can learn about at IPL.com.

Branch Coverage Testing – Finally we also have branch coverage testing which tests each possible path of a software application. All programs have more than one possible path. Even the simplest of programs must have at least two possible paths. Since computers are essentially a massive series of on-off switches, there must be at least one such switch triggered in even the crudest of application. Actually, if you were to look at the entire process involved, even the simplest applications have numerous switches. Most software applications have several possible paths with some having thousands or more. Each switch provides for a new possible path and some switches have more than one possible position. For example, the common switch statement in many programming languages can have almost limitless possible positions. Switch statements are also known as branch statements in many common programming languages such as C and C++. In branch coverage testing, code is written that will test each possible case at every possible switch often creating a massive number of possible paths through a software program, all of which must be tested. This is why testers have to write testing apps to perform these branch coverage tests, because without the assistance of a custom application to test each switch case, the tester would take much more time testing applications. There are also several tools available for performing branch testing on various coding languages. Tools such as TCAT and TCAT-PATH are available for C, C++ and Java.

Summary

As you can see by the numerous types of testing mentioned in this article, white box testing can be quite complex. The complexity involved has a lot to do with the application being tested. A small application that performs a single simple operation could be white box tested in minutes, while larger programming applications take days, weeks and even longer to fully test. Testing on some applications is a full time job for many testers.

If you have a fairly decent knowledge of programing languages, a computer engineering degree and some common sense, maybe you can become a software testing engineer, otherwise, it is probably wise to hire a professional to handle your white box testing for you because it can be quite complicated. It is probably most common to have the same programmer who wrote the application do the white box testing as well because they will have the familiarity required to perform the required software tests. White box testing should be done on a software application as it is being developed, after it is written and again after each modification.

We hope you have learned a good deal about white box testing in this article. Have fun with your next coding project or testing project and don’t forget all those ones and zeros! Each one is a switch that could potentially require white box testing.