Programming Portal

Programming and Data Types in C programming

2009-07-28T12:36:00.004+05:30

In C programming we have different kinds of data types in C language and this is in continuation with previous discussion.

Integers signed and unsigned:

Sample code for syntax for unsigned inter is :

nsigned int num_students ;

With this declaration, the range of permissible integer values (for a 16-bit OS) will shift from the range -32768 to +32767 to the range 0 to 65535. Thus, declaring an integer as unsigned almost doubles the size of the largest possible value that it can otherwise take.

It happens because on declaring the integer as unsigned, the left-most bit is now free and is not used to store the sign of the number.

Unsigned integer still occupies two bytes.

It can be declared as : unsigned int i ; unsigned i ;

There also exists a short unsigned int and a long unsigned int. By default a short int is a signed short int and a long int is a signed long int in C programming.

Chars, signed and unsigned

Signed and unsigned chars, both occupying one byte each, but having different ranges. Consider the statement

char ch = 'A' ;

Here what gets stored in ch is the binary equivalent of the ASCII value of ‘A’ (i.e. binary of 65). And if 65’s binary can be stored, then -54’s binary can also be stored (in a signed char).

A signed char is same as an ordinary char and has a range from -128 to +127; whereas, an unsigned char has a range from 0 to 255.

Floats and Doubles

A float occupies four bytes in memory and can range from -3.4e38 to +3.4e38. If this is insufficient then C offers a double data type that occupies 8 bytes in memory and has a range from -1.7e308 to +1.7e308.

A variable of type double can be declared as,

double a, population ;

If the situation demands usage of real numbers that lie even beyond the range offered by double data type, then there exists a long double that can range from -1.7e4932 to +1.7e4932.

A long double occupies 10 bytes in memory in c programming and it is used rarely.

Learn about ABAP programming with finance sample reports for SAP here.

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAP
ALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code
ABAP complete course
ABAP Dictionary
SAP Scripts
Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface

You may be also interested in the following SAP Finance reports.

SAP Finance General Ledger report account balance
Finance general ledger line items SAP ABAP report
General ledger report SAP FINACNE
SAP FICO customer open items report
Customer balance in local currency for SAP FICO
Vendor open items report
SAP Finance abap report for Vendor balance in local currency
Customer relationship management introduction
Enterprise resource planning introduction

Programming and Data Types

2009-07-26T20:23:00.003+05:30

Primary data types of programming could be of three varieties—char, int, and float. We can derive many data types from these three types.

A char could be an unsigned char or a signed char. Or an int could be a short int or a long int.

Integers, long and short We had seen earlier that the range of an Integer constant depends upon the compiler.

For a 16-bit compiler like Turbo C or Turbo C++ the range is –32768 to 32767.
For a 32-bit compiler the range would be –2147483648 to +2147483647.

16-bit compiler means that when it compiles a C program it generates machine language code that is targeted towards working on a 16-bit microprocessor like Intel 8086/8088.

A 32-bit compiler like VC++ generates machine language code that is targeted towards a 32-bit microprocessor like Intel Pentium.
A program compiled using Turbo C would not work on 32-bit processor. It would run successfully but at that time the 32-bit processor would work as if it were a 16-bit processor.

This happens because a 32-bit processor provides support for programs compiled using 16-bit compilers. If this backward compatibility support is not provided the 16-bit program would not run on it.

Out of the two or four bytes used to store an integer, the highest bit (16th/32nd bit) is used to store the sign of the integer. This bit is 1 if the number is negative, and 0 if the number is positive.

C offers a variation of the integer data type that provides what are called short and long integer values.

Short and long integers would usually occupy two and four bytes respectively. Each compiler can decide appropriate sizes depending on the operating system and hardware for which it is being written, subject to the following rules:

shorts are at least 2 bytes big
longs are at least 4 bytes big
shorts are never bigger than ints
ints are never bigger than longs

long variables which hold long integers are declared using the keyword long.

Long integers cause the program to run a bit slower, but the range of values that we can use is expanded tremendously. The value of a long integer typically can vary from -2147483648 to +2147483647.

Integers that need less space in memory and thus help speed up program execution.

Short integer variables are declared as,

short int j ;
short int height ;

C allows the abbreviation of short int to short and of long int to long. So the declarations made above can be written as,

long i ;
long abc ;
short j ;
short height ;

OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

Thank you for visiting Programing and Testing. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can mail me at d_vsuresh[at the rate of ]yahoo[dot]co[in] for specific feed backs and suggestions.

Programming C Functions Coding

2009-05-03T11:52:00.003+05:30

Programming with C language and using Functions is done in our previous discussions. Now we are going to deal with advanced concepts of using functions in c programming.

Function Declaration and Prototypes :

Any C function by default returns an int value. Whenever a call is made to a function, the compiler assumes that this function would return a value of the type int. If a function should return a value other than an int, then it is necessary to explicitly mention so in the calling function as well as in the called function.

The following program segment illustrates how to make square( ) capable of returning a float value.

main( )
{
float square ( float ) ;
float a, b ;
printf ( "\nEnter any number " ) ;
scanf ( "%f", &a ) ;
b = square ( a ) ;
printf ( "\nSquare of %f is %f", a, b ) ;
}
float square ( float x )
{
float y ;
y = x * x ;
return ( y ) ;
}

And here is the output

Enter any number 1.5 Square of 1.5 is 2.250000
Enter any number 2.5 Square of 2.5 is 6.250000

The function square( ) must be declared in main( ) as float square ( float ) ;

This statement is often called the prototype declaration of the square( ) function. What it means is square( ) is a function that receives a float and returns a float.

Call by Value and Call by Reference

Whenever a function is called and passed something to it we have always passed the ‘values’ of variables to the called function. Such function calls are called ‘calls by value’. On calling a function we are passing values of variables to it.

Call by reference is done with pointers in C programming.

Pointer Notation Consider the declaration, int i = 3 ;

This declaration tells the C compiler to

1. Reserve space in memory to hold the integer value.
2.Associate the name i with this memory location.
3. Store the value 3 at this location.

The computer has selected memory location 65524 as the place to store the value 3. The location number 65524 is not a number to be relied upon, because some other time the computer may choose a different location for storing the value 3. The important point is, i’s address in memory is a number.

TO print this address number

main( )
{
int i = 3 ;
printf ( "\nAddress of i = %u", &i ) ;
printf ( "\nValue of i = %d", i ) ;
}

The output of the above program would be: Address of i = 65524 Value of i = 3

‘&’ used in this statement is C’s ‘address of’ operator. The expression &i returns the address of the variable i, which in this case happens to be 65524. Since 65524 represents an address, there is no question of a sign being associated with it.

Hence it is printed out using %u, which is a format specifier for printing an unsigned integer.

OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

Programming Functions in C part two

2009-04-13T22:22:00.002+05:30

Previously we had discussed regarding the usage functions in C programming and this is a continuation for it.

Use of Functions in C programming

Writing functions avoids rewriting the same code over and over.

Explanation : Suppose we have a section of code in your program that calculates area of a triangle. If later in the program we want to calculate the area of a different triangle, we nee d not write the entire code once again and we would prefer to jump to a ‘section of code’ that calculates area and then jump back to the place from where you left off. This section of code is nothing but a function.

Using functions it becomes easier to write programs and keep track of what they are doing. If the operation of a program can be divided into separate activities, and each activity placed in a different function, then each could be written and checked more or less independently. Separating the code into modular functions also makes the program easier to design and understand.

We have to break a program into small units and write functions for each of isolated sub divisions. We can even write functions that are called only once and these functions perform some logically isolated task.

How to Pass Values between Functions ?

The mechanism used to convey information to the function is the ‘argument’. We use the arguments in the printf( ) and scanf( ) functions; the format string and the list of variables used inside the parentheses in these functions are arguments. The arguments are sometimes also called ‘parameters’.

Sending and receiving values between functions Example

Consider the following program where, in main( ) we receive the values of a, b and c through the keyboard and then output the sum of a, b and c.

The calculation of sum is done in a different function called calsum( ). If sum is to be calculated in calsum( ) and values of a, b and c are received in main( ), then we must pass on these values to calsum( ), and once calsum( ) calculates the sum we must return it from calsum( ) back to main( ).

main( )

{

int a, b, c, sum ;

printf ( "\nEnter any three numbers " ) ;

scanf ( "%d %d %d", &a, &b, &c ) ;

sum = calsum ( a, b, c ) ;

printf ( "\nSum = %d", sum ) ;

}

calsum ( x, y, z )

int x, y, z ;

{

int d ;

d = x + y + z ;

return ( d ) ;

}

And here is the output... Enter any three numbers 10 20 30 Sum = 60

Explanation

1.In this program, from the function main( ) the values of a, b and c are passed on to the function calsum( ), by making a call to the function calsum( ) and mentioning a, b and c in the parentheses: sum = calsum ( a, b, c ) ; In the calsum( ) function these values get collected in three variables x, y and z:

calsum ( x, y, z )

int x, y, z ;

2.The variables a, b and c are called ‘actual arguments’, whereas the variables x, y and z are called ‘formal arguments’. Any number of arguments can be passed to a function being called. The type, order and number of the actual and formal arguments must always be same.

3.The return statement serves two purposes:
1. On executing the return statement it immediately transfers the control back to the calling program.
2. It returns the value present in the parentheses after return, to th3e calling program.

4.There is no restriction on the number of return statements that may be present in a function. Also, the return statement need not always be present at the end of the called function.

5.Whenever the control returns from a function some value is definitely returned. If a meaningful value is returned then it should be accepted in the calling program by equating the called function to some variable.

6.If we want that a called function should not return any value, we must mention so by using the keyword void .

void display( )
{
printf ( "\nHeads I win..." ) ;
printf ( "\nTails you lose" ) ;

7.A function can return only one value at a time.

OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

Software Testing Process Overview

2009-04-11T14:30:00.004+05:30

The testing and development processes are in a feedback loop. The testing process feeds identified failures back into the development process.

Failure reports provide a set of symptoms that a developer uses to identify the exact location of a fault or error. The development process feeds new and revised designs and implementations into the testing process.

Testing of development products will help identify defective test cases when testers determine that "failures" result from problems with test cases themselves or the drivers that execute them, and not the software under test.

The form and content of development products affect the testing process. When developers select methods and tools, they establish constraints on the testing process. The testing perspective must be considered, preferably by the presence of professional testers, when development methods and tools are selected.

The form and quality of a requirements specification also affects the process. Product requirements comprise the source of test cases in system and acceptance testing. System testers should participate in the gathering and validation of the requirements in order to have a sufficient understanding of them to assess risks and testability.

Three-step approach for each type of testing performed on a project.

Analysis:The product to be tested is examined to identify any special features that must receive particular attention and to determine the test cases that should be constructed. We will present a number of analysis techniques.
Construction: In this phase the artifacts that are needed for testing are created. The test cases identified during analysis are translated into programming languages and scripting languages, or they are entered in a tool-specific language.
Execution and Evaluation: This is the most visible and often the only recognized part of the test effort; however, it is also typically the quickest part of the test effort. The test cases that were identified during analysis and then constructed are executed. The results are examined to determine whether the software passed the test suite or failed it.

Test Cases and Test Suites

The basic component of testing is a test case. Test case is a pair (input, expected result), in which input is a description of an input to the software under test and expected result is a description of the output that the software should exhibit for the associated input.

Inputs and expected results are not necessarily simple data values, such as strings or integer values, but they can be complex.

Inputs often incorporate system state information as well as user commands and data values to be processed. Expected result includes not only perceivable things, such as printed reports, audible sounds, or changes in a display screen, but changes to the software system itself.

A test case execution is a running of the software that provides the inputs specified in the test case and observes the results and compares them to those specified by the test case. If the actual result varies from the expected result, then a failure has been detected and we say the software under test "fails the test case."

If the actual result is the expected result for a test case, then we say the software "passes the test case."

Test cases are organized into a test suite. Most test suites have some sort of organization based on the kinds of test cases. If software passes all the test cases in a test suite, then we say that the software "passes the test suite."

Software testing other interesting topics:

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

Programming Development Process Overview

2009-03-29T18:24:00.003+05:30

A process is a continuous series of activities that convey you to an end.Main activities in a software development process are

analysis— which focuses on understanding the problem and defining the requirements for the software portions of a system
design— which focuses on solving the problem in software
implementation— which focuses on translating the design into executable code
testing— which focuses on ensuring that inputs produce the desired results as specified by the requirements

Maintenance begins after deployment with a focus on bug repairs and enhancements. Maintenance usually involves further analysis, design, implementation, and testing. Among the testing activities during maintenance is regression testing, which ensures that successful test results after changes are the same as those before changes.

Under an incremental development process, a system is developed as a sequence of increments. An increment is a deliverable, including models, documentation, and code, which provides some of the functionality required for the system.

The products developed in one increment feed into the development of the next increment. Successive increments add (and sometimes change) system functionality. The final increment delivers a deployable system that meets all requirements. Increments can be developed in sequence or one or more can be developed concurrently.

To build each increment, developers analyze, design, code, and test as needed. They typically have to perform these activities repeatedly in building an increment because they find errors in previous work. As development progresses, they gain new insights into the problem and the solution. We prefer to acknowledge this iterative aspect of incremental development and make it part of the process.

In planning each increment, we include explicit steps for repeating various activities. Among these are steps for systematically reviewing current models, identifying errors based on experiences in later tasks, and modifying the models (or code) that have already been produced—not just those that will be produced in the future.

Object-oriented development is particularly well suited to evolutionary development because object-oriented analysis, design, and implementation entail the successive refinement of a single model. This is the case both within an increment and among increments.

In object-oriented analysis, we understand a problem by modeling it in terms of objects and classes of objects, their relationships and responsibilities. In object-oriented design, we solve the problem by manipulating those same objects and relationships identified in analysis and introducing solution-specific classes, objects, relationships, and responsibilities.

Implementation is straightforward from a well-specified set of design products. Thus, the entire development process involves a refinement of a model. Design products are primarily an extension of analysis products and implementation products are coded expressions of design products. The products of one increment are extended and refined in the next increment.

The incremental development of products requires the incremental testing of those products. Products can change from increment to increment in both planned and unplanned ways. Test suites must change in concert. Regression tests must be run between increments and within iterations to ensure that changes do not adversely affect correctly working code.

A process in which work on one increment overlaps work on another adds to the complexity of development and testing. Coordination is required to sequence the development of interacting increments so that objects that are associated with, but assigned to different increments, can be tested in a timely fashion.

Software testing other interesting topics:

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

Thank you for visiting Codes and Test. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can mail me at d_vsuresh[at the rate of ]yahoo[dot]co[in] for specific feed backs and suggestions.

Programming C Language Introduction

2009-03-28T22:19:00.002+05:30

C programming language is said to be a middle level language because it combines the best elements of high-level languages with the control and flexibility of assembly language .

As a middle-level language, C allows the manipulation of bits, bytes, and addresses the basic elements with which the computer functions and C code is also very portable.Portability means that it is easy to adapt software written for one type of computer or operating system to another type.

All high level programming languages support the concept of data types. A data type defines a set of values that a variable can store along with a set of operations that can be performed on that variable. Common data types are integer, character, and floating-point. Although C has several built in data types, it is not a strongly typed language, as are Pascal and Ada. C permits almost all type conversions.

C specifies almost no run time error checking. For example, no check is performed to ensure that array boundaries are not overrun. and these types of checks are the responsibility of the programmer.

C does not demand strict type compatibility between a parameter and an argument.C allows an argument to be of any type so long as it can be reasonably converted into the type of the parameter and C provides all of the automatic conversions to accomplish this.

C allows the direct manipulation of bits, bytes, words, and pointers. This makes it well suited for system-level programming, where these operations are common.

C has only a small number of keywords, which are the commands that make up the C language. For example, C89 defined 32 keywords, and C99 adds only 5 more. High-level languages typically have many more keywords.

C is a structured language. The distinguishing feature of a structured language is compartmentalization of code and data. This is the ability of a language to section off and hide from the rest of the program all information and instructions necessary to perform a specific task. One way that you achieve compartmentalization is by using subroutines that employ local (temporary) variables.

By using local variables, you can write subroutines so that the events that occur within them cause no side effects in other parts of the program. This capability makes it very easy for your C programs to share sections of code. If you develop compartmentalized functions, you need to know only what a function does, not how it does it.

Structured languages typically support several loop constructs, such as while, do-while, and for. In a structured language, the use of goto is either prohibited or discouraged and is not the common form of program control . A structured language allows you to place statements anywhere on a line and does not require a strict field concept.

In C, functions are the building blocks in which all program activity occurs. They allow you to define and code individually the separate tasks in a program, thus allowing your programs to be modular.

After you have created a function, you can rely on it to work properly in various situations without creating side effects in other parts of the program. Being able to create stand alone functions is extremely important in larger projects where one programmer's code must not accidentally affect another's.

Related posts

INTRODUCTION TO C PROGRAMMING

C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting Codes and Test. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can mail me at d_vsuresh[at the rate of ]yahoo[dot]co[in] for specific feed backs and suggestions.

SoftwareTesting Perspective

2009-03-19T20:21:00.004+05:30

The testing perspective is a way of looking at any development product and questioning its validity. The person examining work products from this perspective utilizes a thorough investigation of the software and all its representations to identify faults. The search for faults is guided by both systematic thinking and intuitive insights.

It is a perspective that makes reviews and inspections just as powerful a tool as execution-based testing. A review will almost never find something that is missing—that is, a review typically only seeks to validate what exists and does not systematically search to determine if all things that should be in the software actually are in it.

The testing perspective requires that a piece of software demonstrate that it not only performs according to its specification, but performs only to that specification. Thus, a product is tested to determine that it will do what it is supposed to do, and it is also tested to ensure that it does not do what it is not supposed to do.

Software testing is typically accomplished by a combination of inspections, reviews, and test executions. The purpose of these activities is to observe failures.

An inspection is an examination of software based on a checklist of typical problems. Most items on a checklist are based on programming language semantics and/or coding conventions—for example, ensuring that each program variable is initialized before its first use and that pointers or references have been set to reasonable values before they are used. Modern compilers for object-oriented programming languages can detect many of the problems called out on traditional inspection checklists.

A review is an examination of software with the purpose of finding errors and faults even before the software is executed. Reviews are made in the context of the system being developed and have a deeper interest in the software than do inspections.

A review delves into the meaning of each part of a program and whether it is appropriate for meeting some or all of the application's requirements. A review is intended to uncover errors such as missed or misunderstood requirements or faults in a program's logic. Some reviews examine programming details such as whether variable names are well chosen and whether algorithms are as efficient as they could be.

Test execution is testing software in the context of a running program. Through executing the software, a tester tries to determine whether it has the required behavior by giving the program some input and verifying that the resulting output is correct. Among the challenges to testers are identifying suitable inputs, determining correct outputs, and determining how to observe the outputs.

The testing perspective is

Skeptical: Wants proof of quality.
Objective: Makes no assumptions.
Thorough: Doesn't miss important areas.
Systematic: Searches are reproducible.

Team blog recent posts

Testing Spiral model SAP ABAP Business Objects
ABAP Syntax for New Line
Second law of thermodynamics (physics)

Function in C Programming

2009-03-17T08:36:00.002+05:30

A computer program (except for the simplest one) cannot handle all the tasks by itself. Instead, it requests other program like entities—called ‘functions’ in C—to get its tasks done.

A function is a self-contained block of statements that perform a coherent task of some kind.

Example

main( )

{

message( ) ;

printf ( "\nCry!" ) ;

}

message( )

{ printf ( "\nSmile" ) ;

}

And here’s the output...

Smile...

Cry

Here, main( ) itself is a function and through it we are calling the function message( ). Main( ) ‘calls’ the function message( ) and it mean that the control passes to the function message( ).

The activity of main( ) is temporarily suspended; it falls asleep while the message( ) function wakes up and goes to work. When the message( ) function runs out of statements to execute, the control returns to main( ), which comes to life again and begins executing its code at the exact point where it left off. Thus, main( ) becomes the ‘calling’ function, whereas message( ) becomes the ‘called’ function.

Important points about Function

Any C program contains at least one function.

If a program contains only one function, it must be main( ).

If a C program contains more than one function, then one (and only one) of these functions must be main( ), because program execution always begins with main( ).

There is no limit on the number of functions that might be present in a C program.

Each function in a program is called in the sequence specified by the function calls in main( ).

After each function has done its thing, control returns to main( ).

When main( ) runs out of function calls, the program ends. The program execution always begins with main( ). Except for this all C functions enjoy a state of perfect equality. No precedence, no priorities.

One function can call another function it has already called but has in the meantime left temporarily in order to call a third function which will sometime later call the function that has called it.

Other C programming Related topics are

Switch in C Programming
PROGRAMMING C VARIABLES
C PROGRAM INSTRUCTIONS
COMPILATION AND EXECUTION OF C PROGRAM
C PROGRAMMING RULES PART ONE
C PROGRAMMING RULES PART TWO
COMPILATION AND EXECUTION OF C PROGRAM
INSTRUCTIONS TO WRITE C PROGRAM

Team blog recent posts

Work Flow in SAP ABAP an introduction
ABAP Syntax for Move corresponding
Zeroth law of thermodynamics (physics)

Switch in C Programming

2009-03-16T11:03:00.003+05:30

The control statement that allows us to make a decision from the number of choices is called a switch, or more correctly a switch-case-default, since these three keywords go together to make up the control statement.

The syntax for this is

switch ( integer expression )
{
case constant 1 :
do this ;
case constant 2 :
do this ;
case constant 3 :
do this ;
default : do this ;
}

The integer expression following the keyword switch is any C expression that will yield an integer value. It could be an integer constant like 1, 2 or 3, or an expression that evaluates to an integer. The keyword case is followed by an integer or a character constant. Each constant in each case must be different from all the others. The “do this” lines in the above form of switch represent any valid C statement.

How it functions ?

First, the integer expression following the keyword switch is evaluated. The value it gives is then matched, one by one, against the constant values that follow the case statements. When a match is found, the program executes the statements following that case, and all subsequent case and default statements as well. If no match is found with any of the case statements, only the statements following the default are executed.

Example with only Switch

main( )
{
int i = 2 ;
switch ( i )
{
case 1 :
printf ( "I am in case 1 \n" ) ;
case 2 : printf ( "I am in case 2 \n" ) ;
case 3 : printf ( "I am in case 3 \n" ) ;
default : printf ( "I am in default \n" ) ;
}
}

The output of this program would be:

I am in case 2
I am in case 3
I am in default

The switch executes the case where a match is found and all the subsequent cases and the default as well.

If you want that only case 2 should get executed, it is upto you to get out of the switch then and there by using a break statement.There is no need for a break statement after the default, since the control comes out of the switch anyway.

Example with Break statement and Switch

main( )
{
int i = 2 ;
switch ( i )
{
case 1 : printf ( "I am in case 1 \n" ) ;
break ;
case 2 : printf ( "I am in case 2 \n" ) ;
break ;
case 3 : printf ( "I am in case 3 \n" ) ;
break ;
default : printf ( "I am in default \n" ) ;
}
}

The output of this program would be:

I am in case 2

Other C programming Related topics are

PROGRAMMING C VARIABLES
C PROGRAM INSTRUCTIONS
COMPILATION AND EXECUTION OF C PROGRAM
C PROGRAMMING RULES PART ONE
C PROGRAMMING RULES PART TWO
COMPILATION AND EXECUTION OF C PROGRAM
INSTRUCTIONS TO WRITE C PROGRAM

Team blog recent posts

Work Flow in SAP ABAP an introduction
ABAP Syntax for Move
Software testing spiral model
Heat and Convection (physics)

Software Testing Spiral Model

2009-03-11T21:37:00.003+05:30

The spiral model is based on the need to iterate. It contains as many iterations as are necessary to bring a product to fruition. Each iteration requires that the participants plan, define their life-cycle, prototype, analyze risks, write requirements, build models, detailed designs, code, unit, and system tests, and install.

Advantages :

It is flexible and allows for multiple iterations.
It employs prototyping extensively.
It allows for the coexistence of other models .
It makes risk evaluation explicit.
It acknowledges the need to validate requirements and design.
It was originally designed with a particular need to accommodate COTS, and is therefore more amenable to software reuse.

Disadvantages :

It is less easy to allocate phases to groups and responsibilities than other models.
It requires that staff are well-versed in software engineering.
It requires much team self-discipline in the capture of emerging requirements.
It does not acknowledge the need to have test input from the start of the project.
It allocates particular phases to requirements definition and high- and low-level design.
It doesn’t make the baselines explicit.
It doesn’t allow for process decomposition
Much prototype code may eventually be used in the final version.
It must be very tool-supported to work or it will either decay or become enmeshed in the
bureaucracy it was intended to minimize.

Implications :

• The status of emerging requirements must be constantly reviewed.
• The team is committed to validating both the requirements and the design.
• Any use of prototype code in the production version will require much more rigorous unit testing than is normal.

Software Testing Stage Gate Process Model

2009-03-10T23:16:00.003+05:30

Cooper’s stage gate model is a variant of the waterfall. It splits the life-cycle into six stages separated by “gates.” Each gate is a decision point. It differs from the waterfall in that the activities in each stage may be simultaneous.

The different stages of this model are explained below.

Discovery stage: a product manager thinks of a new idea for a product.
Idea screen: the idea is presented to potential stakeholders for their buy-in.

Scoping stage: the market for the product is assessed and key features are identified.
Second screen: the idea is re-presented to potential stakeholders for their buy-in, but with more-rigorous requirements and other information.

The business case stage: in which the product, market, organization, project management and environment, competitors, budget, RoI, and legal issues are defined.
Go to development is the moment at which the organization can commit to the large budget required for development.

The development stage includes requirements refining, design, code, and build. Its output is a product ready for beta testing.
Go to testing is the moment when the testing budget and the marketing and operational plans must be committed to. It is based on the continued existence of a market opportunity.

Testing is system and acceptance testing at internal and friendly customer sites. It generates a
product fit for launch.
Go to launch: is the moment when marketing and training plans become operative and we can launch the product.

Problems with this model are

1• Half the activities are oriented to the development of a business case. Since this is likely to occupy between 5–10% of the total manpower, more detail on the other 90–95% of the manpower’s activities would be useful.

2• No allowance has been made for the requirements changes.

3• Testing is relegated to the penultimate activity. The possibility that the requirements are deeply flawed will thus tend to be hidden. Similarly the testers will not learn how to use the product until too late causing considerable delay. The tests they prepare may thus need much rewriting.

4• That a decision can be taken on the marketability of a product which has yet to enter beta testing requires enormous faith in the ability of developers. The amount of iteration between the development and testing groups is not shown, and the delays can be considerable.

To overcome all these problems

1• Focus on the earliest access to the requirements as they are assembled.
2• Get early access to prototype versions so they can prepare tests.
3• Provide review and possibly modeling feedback to management such that inconsistent or missing requirements be identified asap.

Related :

Water fall model testing
Risk management in software testing
How do we test a software ?

Waterfall Model

2009-03-09T19:39:00.003+05:30

The waterfall model consists of 5 phases:

1. Requirements (in which the customer requirements are written).
2. Design (in which the high and low-level design documents are written).
3. Code (in which the code is written and (hopefully) unit tested).
4. System test (which is where we come in).
5. Installation and cut over.

Disadvantages of waterfall model

Bureaucrats believe such phases are finite and cannot be iterated upon.
It doesn’t allow for parallel activities such as prototyping or the development of user interface.
specifications or for safety-critical system issues such as the development of a safety case.
It makes no mention of contract preparation, project management, reviews, or audits.
It implies that system testing starts only when coding is finished.
It says nothing about software reuse.

Advantages of waterfall model

Each phase generates some baseline deliverable.
It is well-known.
It has been used for many years.
It is very adaptable.
Each process can be decomposed into others.
You can add any process you want.

Here

Each phase may have to be repeated (as requirements change, as prototypes evolve).
It needs to be seen in parallel with a number of other life-cycles with which it must stay synchronized.
It can be modified for prototypes and software reuse.
Testing input begins at least as early as requirements definition .
Any change to requirements, design, or code must be manually reflected through all levels of documentation to ensure all documents are consistent . then it is perfectly usable.(69.2)

Thank you for visiting Codes and Test. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can for any specific feed back .

Managing Risk in Software Project

2009-03-08T11:53:00.003+05:30

Plan how to manage the project’s risks: The Risk Management Plan documents how risks will be managed. It is a subset of the project plan and is written before the project begins.
Identify risks: One simple approach is to get representatives of all the affected groups in a room and have a workshop. Circulate a provisional list to excite attention. Get their ideas down onto large sheets of paper you can blu-tack to the walls. Circulate a revised list after the meeting.

Repeat the process half-way through the project, and identify how many have not occurred, and how many unforeseen ones had occurred.

Risk Alerts are the triggers used to identify when a risk is imminent. Typical test-related triggers are:

Reduction in the number of lines of code per bug found.
Finding an unacceptably-high number of priority-1 and -2 bugs in a build.
Finding an unacceptably-high number of bugs in a component.
Late arrival of signed-off specifications for use as a baseline.
Failure of performance tests to achieve targets.
Growing code complexity.
Growing code turmoil.

Monitoring such risks is easier when an alerting system is in place. The existence of a risk log allows the test team to identify priorities and provides a good basis for deciding the mix of tests to be planned.

Risks can be grouped by sources and by kinds and a risk kind is for example that something doesn’t work, that it works too late, too slowly, at the wrong time, or that it has unintended side-effects. These groups are sensitive to risk drivers in that a driver can change a whole group of risks.

The failure of the project to use an appropriate development method was having a knock-on effect throughout the whole of the project. It was a source of risks and a major driver. Here are some more are

Use of an inappropriate (unrelated to the risk) method or process.
Lack of customer involvement:Apart from the obvious need for a sufficient set of requirements
There is the need for feedback to users of (fragments of) the proposed solution.
Dissimilarity to previous projects: If “we’ve never done anything as (big/complex/different) as this before” is an issue, then beware.
Project complexity: This is relative to the experience of an organization. What might exhaust some organizations will be run-of-the-mill to others.
• Requirements volatility:If such changes aren’t allowed for, the project will soon deteriorate.(56)

Related :

How do we test a software ?

Thank you for visiting Codes and Test. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

How do we test a software ?

2009-03-05T20:53:00.002+05:30

The following are the different techniques of software testing on the open basis.

Functional (black-box) methods can be applied to any unit, build, or system, since they assume no knowledge of how either was constructed or what it contains. Such methods require a sufficient and unambiguous specification if they are to be effective. (Devising black-box tests for some code from its specification at the time the specification is written is a useful verification of the specification; if it can’t be done, the specification isn’t good enough.) This is what you will normally do for a system test.

Structural (white-box) methods can also be used on any unit or build, but are cheapest to devise when used on structured programs, e.g., well-written programs in a structured language. These are usually applied to unit tests.

Dynamic analysis techniques are derivative methods which assume that a particular technique such as condition tables, finite state machines, object-orientation, or functional programming, has been used to develop the software; we use knowledge of that technique to determine the test cases, so these have very special areas of application. These can be applied at both system test and unit test times. These are usually applied to unit tests.

Static analysis techniques can best be used before integration, and can also point to the need for more-rigorous unit testing. These require using tools to analyze the source code .These are usually applied to unit tests.

Symbolic evaluation carried out by an automated symbolic evaluation tool places no special requirement on the unit, except of course that it be in the language evaluated by the tool. This involves “dry-running” the code, and recording the output values of variables algebraically rather than using specific values for input variables . This is usually applied to unit tests.

Thank you for visiting Codes and Test. To get the updates as and when published, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

XML Logical Structure

2009-03-02T16:16:00.004+05:30

HTML uses its tags as if they were style switches. The start tag turns a feature on, such as underlining, and an end tag turns it off again. XML uses its start tags and end tags as containers.

The start tag, the content, and the end tag all form a single element. Elements are the building bricks out of which an XML document is assembled. Each XML document must have only one root element, and all the other elements must be perfectly nested inside that element. This means that if an element contains other elements, those elements must be completely enclosed within that element.

If we sketch out the structure of the elements in this XML document, you’ll obtain the kind of tree structure of elements shown in figure below.

As we can see from figure , the document has a sort of tree-like structure, with the root element (&lthome.page>) at the top of the tree (or the base, depending on how you look at it). All the elements that are inside this element are neatly contained within each other. An XML document must contain one and only one root element, and there must not be any elements that are either partially or completely outside, before or after, that element.

To make it easier to refer to the relationships between elements and to elements with respect to other elements, we could say that an element is the parent of the elements that it contains. The elements that are inside an element are called its children. Elements that share the same parent element are called siblings.

In the simple example shown in Figure , &lthome.page> is the parent of all the other elements, &lttext> is the parent of &ltpara>, &lttitle> is a child of &lthead>, and &lttitle> and &ltbanner> are siblings. Going down the element tree, each child element must be fully contained within its parent element. Sibling elements may not overlap.

The arrangement of the elements in an XML document is called the logical structure. As you will see next, an XML document also has a physical structure. In order to be usable the logical and physical structure of an XML document must be synchronous; they must be completely and properly nested inside each other.

XML Introduction

XML anatomy part two

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

XML Document Anatomy part two

2009-02-25T17:12:00.004+05:30

This post is in continuation with XML Document Anatomy part one and going through that post will give you more comfort in understanding the present topic.

The Root Element (Lines 2 through 23)

Each XML document must have only one root element, and all the other elements must be completely enclosed in that element. Line 2 identifies the start of the

&lthome.page>

element (the start tag), and line 23 identifies the end of the element (the end tag).

Note that unlike HTML, in which a

&ltP>

tag might often be used as a sort of formatting instruction to insert a blank line between paragraphs of text, in XML an element normally consists of three things: a start tag, content (either text or other elements), and an end tag.

An XML element doesn’t always have content. Empty elements, such as the IMG element in HTML that simply points to an external graphics file through its SRC attribute, obviously have no content. An empty element might have an end tag, but it can have a special form of start tag that allows an explicit end tag to be omitted.

the name you use in the element start tag must exactly match the name you use in the end tag. If you want to use an odd combination of cases to increase the legibility of long names .

XML is case sensitive, recognizing the difference between uppercase letters (A–Z) and lowercase letters (a–z). In applications that aren’t case sensitive, mixed-case characters are usually converted—folded into one case or the other. The ASCII character set usually folds to uppercase characters. Unicode usually folds to lowercase characters. XML has to account for this, and for the fact that it might have to deal with languages in which the case folding is uncertain. Therefore, XML defaults to lowercase (and the XML declaration also has to be in lowercase).

An Empty Element (Line 13)

Empty elements are a special case in XML. In SGML and HTML, it is obvious from the DTD’s definition of an empty element that it is empty and has no comment. XML, in keeping with its developers’ design goals, requires you to be much more explicit. Indeed, you might not use a DTD at all, so it could be hard to decide whether an element is or should be empty. Therefore, empty elements have to be very clearly identified as such. To do so, there is a special empty tag close delimiter, />, as in the following:

&ltempty_element/>

To maintain a certain degree of backward-compatibility with SGML (until such time as the SGML standard is updated to allow the use of empty-tag close delimiters), and to make the conversion of existing SGML and HTML code into XML a little easier (a process called normalization, which adds end tags to all elements and is supported by a lot of SGML tools), you can use an end tag instead of the special empty tag close delimiter. The element declaration

blockquote>
&ltgraphic source=”file.gif”/>

is therefore interchangeable with

&ltgraphic source=”file.gif”></graphic>

Attributes (Lines 7 and 22)

Element tags can include one or more optional or mandatory attributes that give further information about the elements they delimit.

Attributes can only be specified in the element start tag. The syntax for specifying an attribute is

<element.type.name attribute.name=”attribute.value”>

If elements were nouns, attributes would be adjectives. We could therefore say

&ltfruit taste=”sharp”>

or even

&ltproblem size=”huge” cause=”unknown” solution=”run.away”>

An attribute can only be specified in an element start tag.

In direct contrast to SGML and HTML, in which multiple declarations are considered to be fatal errors, XML deals with multiple declarations of attributes in a unique manner. If an element appears once with one set of attributes and then appears again with a different set of attributes, the two sets of attributes are merged. The first declaration of an attribute for a particular element is the only one that counts, and any other declarations are ignored. The XML processor might warn you about the appearance of multiple declarations, but it is not required to do so and processing can continue as normal.

XML Introduction

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

XML Document Anatomy

2009-02-23T16:28:00.003+05:30

XML’s rules for distinguishing between markup and content are :

1.The start of markup is identified by either the less-than symbol (<) or the ampersand character (&).

2. Three other characters are also treated as markup characters: the greater-than symbol (>), the apostrophe or single quote, (‘), and the (double) quotation mark (“).

3.If you want to use any of the preceding special characters as normal characters, you must “escape” them by using the general entities that represent them.

To escape a character means to conceal it from a subsequent software package or process. It is often used in computing terms to refer to prefixing certain characters in programming languages with a special character string to prevent them from being interpreted as special characters.

Originally the ESC (escape) character string was used to prefix commands sent to the printer itself to control such things as the font or page size and distinguish the command strings from printable characters.

4.Everything that is not markup is content (character data).

The following code shows the XML code for a Web home page. This is a very simple example, but it contains all the important parts that you will find in nearly all XML documents.


1:  <?xml version=”1.0”?>
2:   &lthome.page>
3:     &lthead>
4:       &lttitle>
5:         My Home Page
6:       </title>
7:       &ltbanner source=”topbanner.gif”/>
8:     </head>
9:     &ltbody>
10:       &ltmain.title>
11:         Welcome to My Home Page
12:      </main.title>
13:      &ltrule/>
14:      &lttext>
15:        &ltpara>
16:          Sorry, this home page is still
17:          under construction. Please come
18:          back soon!
19:        </para>
20:      </text>
21:    </body>
22:    &ltfooter source=”foot.gif”/>
23:  </home.page>

XML Introduction

2009-02-21T17:06:00.002+05:30

Problems with HTML :

1.HTML has syntactic checking and Validation constraints:

There are formal definitions of the structure of HTML documents. HTML is an SGML application and there is a document type definition (DTD) for every version of HTML. Web browsers are designed to accept almost anything that looks even slightly like HTML .The only tag that is compulsory in an HTML document is the TITLE tag; and this is one of the least common tags there is.

2. HTML content awareness problems:

Searching the Web is complicated by the fact that HTML doesn’t give you a way to describe the information content i.e the semantics of documents. In XML you can use any tags you like (such as &ltNAME> instead of &ltH3>), but using attributes in tags (such as &ltH3 CLASS=“name”>) can embed just as much semantic information as custom tags can.

Without any agreement on tag names, the value of custom tags becomes a bit doubtful. To worsen matters, the same tag name in one context can mean something completely different in another. Furthermore, there are the complications of foreign languages—seeing &ltinkoopprijs> isn’t going to help very much if you don’t know that it’s Dutch for “purchase price.”

HTML is not object-oriented:

Modern programmers have been making a long and difficult transition to object-oriented techniques. They want to leverage these skills and have such things as inheritance, and HTML has done very little to accommodate them.

HTML lacks a robust linking mechanism:

If you’ve spent a few hours on the Web, you’ve probably encountered at least one broken link. HTML’s links are one-to-one, with the linking hard coded in the source HTML files. If the location of one target file changes, a Webmaster may have to update dozens or even hundreds of other pages.

HTML is not reusable:

Depending on how well written they are, HTML pages and fragments of HTML code can be extremely difficult to reuse because they are so specifically tailored to their place in the web of associated pages.

The Standard Generalized Markup Language (SGML) from which XML is derived, is useful to make data storage independent of any one software package or software vendor. SGML is a meta language, or a language for describing markup languages. HTML is one such markup language and is therefore called an SGML application. In XML, these applications are often called markup languages—such as the hand-held device markup language (HDML) and the FAQ markup language (QML).

But SGML is just too expensive and complicated for Web use on a large scale. Using SGML requires too much of an investment in time, tools, and training.

XML uses the features of SGML that it needs and tries to incorporate the lessons learned from HTML.

Advantages of XML :

1.XML can be used with existing Web protocols and mechanisms and it does not impose any additional requirements. XML has been developed with the Web in mind—features of SGML that were too difficult to use on the Web were left out, and features that are needed for Web use either have been added or are inherited from applications that already work.

2.XML supports a wide variety of applications. It is difficult to support a lot of applications with just HTML; hence, the growth of scripting languages. HTML is simply too specific. XML adopts the generic nature of SGML, but adds flexibility to make it truly extensible.

3. It is easy to write programs that process XML documents. One of the major strengths of HTML is that it’s easy for even a non-programmer to throw together a few lines of scripting code that enable you to do basic processing . HTML even includes some features of its own that enable you to carry out some basic processing .

4.XML documents are reasonably clear to the any one.A valid XML document

Describes the structural rules that the markup attempts to follow
Lists any external resources (external entities) that are part of the document
Declares any internal resources (internal entities) that are used within the document
Lists the types of non-XML resources (notations) used and identifies any helper applications that might be needed
Lists any non-XML resources (binaries) that are used within the document and identifies any helper applications that might be needed

5.XML documents are easy to create. HTML is almost famous for its ease of use, and XML capitalizes on this strength.

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

Security Testing and Functional Testing

2009-02-13T12:13:00.004+05:30

It’s not the primary job of a tester to find all the bugs in a product. Unless you have an extremely small product that runs on a very limited system, you won’t be able to find all the bugs unless you don’t plan on releasing the product for a very long time.

The primary job of a tester is not to get all bugs fixed either. There are always bugs that will remain unfixed as a conscious decision. Testers also do not generally make decisions on which bugs get fixed and which ones are deferred to a later date, or even those that there are no plans to fix.

The primary job of a tester is also not to decide when to ship a product. Although you can relay the state of the product to the company, the decision to release the product is typically made by the company or a team within the product group.

Functional testing is testing that is performed on behalf of a legitimate user of the product who is attempting to use it in the way it was intended to be used and for its intended purpose. This is who the functional tester is really the advocate for.The majority of functional testing is done from the viewpoint of a customer.

Testing from only customer viewpoint will cause you to bypass a large percentage of security tests. Most security vulnerabilities, although they have a chance of being discovered by the intended customers, are unlikely to be exploited by them.

The customer may call technical support to report the bug or maybe just grumble about it to friends or acquaintances. It’s unlikely that many of the intended customers will even recognize that bug as more than a nuisance or sign of poor quality, let alone correctly see it as a security risk.

The attention of functional testing is much more focused on how to enable the customers to perform their tasks in the easiest and most convenient way possible while providing enough checks and safety measures so that they can’t cause inadvertent harm too easily. It’s a sort of
“protect them from themselves” mentality.

If any security testing is done,it tends to focus on things such as permissions and privileges but, again,only based around the assumption that the customer is using something like the login functionality as intended.

In essence, because you are performing tests on behalf of a customer,you are trusting that all people using the software you are testing are customers and not merely consumers.

Customers are the people or organizations that your software is intentionally written to solve a problem or problems for. They have been the main focus throughout the entire development cycle, from the gathering of requirements through the implementation, and that then provides the basis for functional testing.

Customers are the people or organizations that your software is intentionally written to solve a problem or problems for. They have been the main focus throughout the entire development cycle, from the gathering of requirements through the implementation, and that then provides the basis for functional testing.

Consumers, on the other hand, are those people or organizations that might use your software in a way it was or was not intended and who are not included in your customers. Sometimes your product’s consumer base grows because your product is able to perform some task as part of its normal repertoire, and that task is all that the consumer wishes to accomplish.

Sometimes it is because your product interfaces with some other software or hardware, and the consumer wants to use that ability to interface to their own advantage or because they think it may be exploitable.(3-46)

Related Posts

Walk throgh's and inspections in software testing
Parallel testing technique
Control software testing technique
Error handling testing
Manual support testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

Software Security Vocabulary

2009-02-09T21:33:00.006+05:30

Access Control List (ACL): A data structure or list that is maintained to track what users or groups have permissions to perform what actions.This is a Windows term.

Attack: A particular instance of an attempted introduction of one or more exploits to a system.

Attacker: Someone who is trying to bypass the security of one or more pieces of software to carry out his or her own agenda.

Back Door: A piece of malicious software that is installed and left running to provide a way for an attacker to regain system access at a later time.

Cracker: Someone who “cracks” through software security, particularly licensing and copy protection. It’s thought to have its roots in “safe cracker.” This term isn’t often used, in part because it’s more narrowly focused and in part because it’s just not as widely known, and the differentiation between a hacker and a cracker is not clear.

Cracking: The act of circumventing the copy protection, licensing, or registration functionality of software.

Daemon: A piece of software running in the background, usually as a process. Sometimes used interchangeably with “demon.”

Denial of Service (DoS): Where legitimate users are prevented from accessing services or resources they would normally be able to access.

Distributed Denial of Service (DDoS): Where legitimate users are prevented from accessing services or resources by a coordinated attack from multiple sources.

Escalation of Privilege: When attackers illegitimately gain more functionality or access than they are authorized to have.

Ethical Hacker: One that performs penetration tests. Sometimes ethical hackers are also called “white hats.”

Exploit: A code, technique, or program that takes advantage of a vulnerability to access an asset.

Firewall: An application or hardware appliance designed to diminish the chances of an attack by limiting specific types of information that can pass into or out of a system or network. It’s a piece of perimeter security.

Hacker: Someone who “hacks” together programs, i.e., writes them in a particularly haphazard or unorganized manner. This wasn’t originally a term that was specific to attackers, but in the last few years it has become an often-used synonym for attackers, especially in the press.

Hijacking: A situation when an attacker takes over control of one side of a two-sided conversation or connection.

Hub: A networking device that repeats the network packets on the physical network layer among many devices.

Information Disclosure: A situation when an attacker is able to access information he or she shouldn’t be able to.

Intrusion Detection System: An application that monitors a system or network and reports if it recognizes that the signs of an attack are present.

Leetspeek: The stereotypical sign of a script kiddie where text is written with numbers substituted for letters. The name comes from “elite.” For example, “leet” is often written as “1337” or “l33t.”

Media Access Control (MAC) Address: Also called the Physical Address, it is physically embedded in every network interface card (NIC) during the manufacturing process. MAC addresses are often treated as unique, although that is not actually guaranteed.

OSI Network Model/OSI Seven Layer Model: The Open Systems Interconnection Reference Model. This is commonly used to explain at what point certain processes are taking place and how information travels.

Personally Identifiable Information (PII): Information that is private to the user or machine. Disclosing PII is a violation of user privacy and can be a part of identity theft problems.

Phishing: Social engineering on a large scale, usually to obtain things like login information, credit card numbers, etc.

Protocal Stack: A system that implements protocol behavior based on a series of the OSI Network Model.

Reverse Engineering: The act of wholly or partially recreating the algorithms or designs used in software. This is usually done without sourcecode access.

Rootkit or Root Kit: A set of tools and scripts that an attacker installs after successfully compromising a system. These are designed to automate additional tasks including installing additional programs like key loggers, remote administration tools, packet sniffers, backdoors, etc. Kernel Rootkits are rootkits that hide themselves within the operating system’s kernel, making them a lot more difficult to detect.

Router:A hardware device that routes traffic between two networks. It can also disguise the traffic from the network behind it to make it appear as if all traffic comes from a single system.

Script kiddie: The somewhat derogatory term for an attacker who primarily downloads and uses exploit code designed and written by others. “Script kiddie” tends to be used to signify a Copy-cat type of attacker that is not particularly skilled or creative on his or her own. A script kiddie is also considered to be young, cocky, and brash.

Social Engineering: The process of tricking or convincing a user into volunteering information the hacker can later use. This is often focused on things that are either finance related or material for identity theft.

Spoofing: Impersonating someone or something else — such as another user or machine — in order to trick software security checks or users.

Switch: A hardware device similar to a hub but which knows the hardware (MAC) addresses of each machine connected to it. This is so it can transmit packets only to the individual machine it is addressed to.

Threat: A possible path to illegitimate access of an asset.

Trojan Horse: A piece of malicious software designed to deceive the victims by appearing to be a benign program that they may wish to use and thus are willing to download or install.

Virus: A piece of malicious software that is capable of spreading itself, typically as part of a piece of software or a file that is shared between users.

Vulnerability: A bug in the software that would allow an attacker to make use of a threat to illegitimately access an asset. All vulnerabilities are threats, but only unmitigated threats are vulnerabilities.

Zero-Day Exploit: A vulnerability that is exploited immediately after its discovery, often before the software company or the security community is aware of the vulnerability.

See proof techniques here

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

Proof Techniques in Testing and Stimulation

2009-02-02T20:39:00.003+05:30

There are two approaches to proof of correctness: formal proof and informal proof. A formal proof consists of developing a mathematical logic consisting of axioms and inference rules and defining a proof either to be a proof tree in the natural deduction style or to be a finite sequence of axioms and inference rules.

Informal proof techniques follow the logical reasoning behind the formal proof techniques but without the formal logical system.

Simulation is used in real-time systems development where the "real-world" interface is critical and integration with the system hardware is central to the total design. In many nonreal- time applications, simulation is a cost effective verification and test-data generation technique.

To use simulation as a verification tool several models must be developed. Verification is performed by determining if the model of the software behaves as expected on models of the computational and external environments using simulation. This technique also is a powerful way of deriving test data. Inputs are applied to the simulated model and the results recorded for later application to the actual code.

The data sets derived cause errors to be isolated and located as well as detected during the testing phase of the construction and integration stages.

To develop a model of the software for a particular stage in the development life cycle a formal representation compatible with the simulation system is developed. This consists of the formal requirement specification, the design specification, or separate model of the program behavior. If a different model is used, then the developer will need to demonstrate and verify that the model is a complete, consistent, and accurate representation of the software at the stage of development being verified.

The next steps are to develop a model of the computational environment in which the system will operate, a model of the hardware on which the system will be implemented, and a model of the external demands on the total system.

These models can be largely derived from the requirements, with statistical representations developed for the external demand and the environmental interactions. The software behavior is then simulated with these models to determine if it is satisfactory.

Simulating the system at the early development stages is the only means of determining the system behavior in response to the eventual implementation environment. At the construction stage, since the code is sometimes developed on a host machine quite different from the target machine, the code may be run on a simulation of the target machine under interpretive control.

Simulation also plays a useful role in determining the performance of algorithms. (148)

Related Posts

Walk throgh's and inspections in software testing
Parallel testing technique
Control software testing technique
Error handling testing
Manual support testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

Walk throughs,Inspections of software testing part two

2009-01-28T17:43:00.004+05:30

This post is continuation with previous post Walk tyhroughs,Inspections of software testing part one.

1.System Requirements Review

This review is an examination of the initial progress during the problem definition stage and of the convergence on a complete system configuration. Test planning and test documentation are begun at this review.

2 • System Design Review

This review occurs when the system definition has reached a point where major system modules can be identified and completely specified along with the corresponding test requirements. The requirements for each major subsystem are examined along with the preliminary test plans. Tools required for verification support are identified at this stage.

3• Preliminary Design Review

This review is a formal technical review of the basic design approach for each major subsystem or module. The revised requirements and preliminary design specifications for each major subsystem and all test plans, procedures and documentation are reviewed at this stage. Development and verification tools are further identified at this stage. Changes in requirements will lead to an examination of the test requirements to maintain consistency.

4• Final Design Review

This review occurs just prior to the beginning of the construction stage. The complete and detailed design specifications for each module and all draft test plans and documentation are examined. Again, consistency with previous stages is reviewed, with particular attention given to determining if test plans and documentation reflect changes in the design specifications at all levels.

5• Final Review

This review determines through testing that the final coded subsystem conforms to the final system specifications and requirements. It is essentially the subsystem acceptance test.

Rules should be followed for all reviews:

1. The product is reviewed, not the producer.
2. Defects and issues are identified, not corrected.
3. All members of the reviewing team are responsible for the results of the review.

Reviews are conducted to utilize the variety of perspectives and talents brought together in a team. The main goal is to identify defects within the stage or phase of the project where they originate, rather than in later test stages; this is referred to as “stage containment.”

As reviews are generally greater than 65 percent efficient in finding defects, and testing is often less than 30 percent efficient, the advantage is obvious. In addition, since defects identified in the
review process are found earlier in the life cycle, they are less expensive to correct.

Another advantage of holding reviews is not readily measurable. That is, reviews are an efficient method of educating a large number of people on a specific product/project in a relatively short period of time. Semiformal reviews are especially good for this, and indeed, are often held for just that purpose.

In addition to learning about a specific product/project, team members are exposed to a variety of approaches to technical issues, a cross-pollination effect. Finally, reviews provide training in and enforce the use of standards, as nonconformance to standards is considered a defect and reported as such.(147.2)

Related Posts

Parallel testing technique
Control software testing technique
Error handling testing
Manual support testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

Walkthroughs,Inspections of software testing

2009-01-25T12:17:00.004+05:30

Walkthroughs and inspections are formal manual techniques that are a natural evolution of desk checking. Both procedures require a team, usually directed by a moderator. The team includes the developer, but the remaining members and the moderator should not be directly involved in the development effort.

Both techniques are based on a reading of the product (e.g., requirements, specifications, or code) in a formal meeting environment with specific rules for evaluation. The difference between inspection and walkthrough lies in the conduct of the meeting. Both methods require preparation and study by the team members, and scheduling and coordination by the team moderator.

Inspection involves a step-by-step reading of the product, with each step checked against a predetermined list of criteria. These criteria include checks for historically common errors. Guidance for developing the test criteria can be found elsewhere. The developer is usually required to narrate the reading product. The developer finds many errors just by the simple act of reading aloud.

Walkthroughs differ from inspections in that the programmer does not narrate a reading of the product by the team, but provides test data and leads the team through a manual simulation of the system. The test data is walked through the system, with intermediate results kept on a blackboard or paper.

The test data should be kept simple given the constraints of human simulation. The purpose of the walkthrough is to encourage discussion, not just to complete the system simulation on the test data. Most errors are discovered through questioning the developer's decisions at various stages, rather than through the application of the test data.

At the problem definition stage, walkthrough and inspection can be used to determine if the requirements satisfy the testability and adequacy measures as applicable to this stage in the development. If formal requirements are developed, formal methods, such as correctness techniques, may be applied to ensure adherence with the quality factors.

Walkthroughs and inspections should again be performed at the preliminary and detailed design stages. Design walkthroughs and inspection will be performed for each module and module interface. Adequacy and testability of the module interfaces are very important. Any changes that result from these analyses will cause at least a partial repetition of the verification at both stages and between the stages. A reexamination of the problem definition and requirements may also be required.

Finally, the walkthrough and inspection procedures should be performed on the code produced during the construction stage. Each module should be analyzed separately and as integrated parts of the finished software. (146.2).

Related Posts

Parallel testing technique
Control software testing technique
Error handling testing
Manual support testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

White and Black box Testing Examples

2009-01-21T18:34:00.002+05:30

White-Box Testing

White-box testing assumes that the path of logic in a unit or program is known. White-box testing consists of testing paths, branch by branch, to produce predictable results. The following are white-box testing techniques:

• Statement Coverage : Execute all statements at least once.
• Decision Coverage : Execute each decision direction at least once.
• Condition Coverage : Execute each decision with all possible outcomes at least once.
• Decision/Condition Coverage :Execute all possible combination's of condition outcomes in each decision. Treat all iterations as two-way conditions exercising the loop zero times and one time.
• Multiple Condition Coverage : Invoke each point of entry at least once.

Black-Box Testing

Black-box testing focuses on testing the function of the program or application against its specification. Specifically, this technique determines whether combinations of inputs and operations produce expected results.

When creating black-box test cases, the input data used is critical. Three successful techniques for managing the amount of input data required include:

Equivalence Partitioning

An equivalence class is a subset of data that is representative of a larger class. Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class.

Boundary Analysis

A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function.

Error Guessing

Test cases can be developed based upon the intuition and experience of the tester.(142.3)

Related Posts

Parallel testing technique
Control software testing technique
Error handling testing
Manual support testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .