Software Teting Structural

Structural system testing is designed to verify that the developed system and programs work. The objective is to ensure that the product designed is structurally sound and will function correctly. It attempts to determine that the technology has been used properly and that when all the component parts are assembled they function as a cohesive unit.

The structural system testing techniques provide the facility for determining that the implemented configuration and its interrelationship of parts functions so that they can perform the intended tasks. The techniques are not designed to ensure that the application system is functionally correct, but rather, that it is structurally sound.

Click here to see different kinds of structural testing.

Stress Testing Techniques:

Stress testing is designed to determine if the system can function when subject to large volumes of work i.e., larger than would be normally expected. The areas that are stressed include input transactions, internal tables, disk space, output, communications, computer capacity, and interaction with people. If the application functions adequately under test, it can be assumed that it will function properly with normal volumes of work.

Objectives of stress testing :

The objective of stress testing is to simulate a production environment for the purpose of determining that:

1 • Normal or above-normal volumes of transactions can be processed through the transaction within the expected time frame.

2 • The application system is structurally able to process large volumes of data.

3 • System capacity, including communication lines, has sufficient resources available to meet expected turnaround times.

4 • People can perform their assigned tasks and maintain the desired turnaround time.

How to use this :

Stress testing should simulate as closely as possible the production environment. Online systems should be stress tested by having people enter transactions at a normal or above normal pace.


Batch systems can be stress tested with large input batches. Error conditions should be included in tested transactions. Transactions for use in stress testing can be obtained from one of the following three sources:

1. • Test data generators
2. • Test transactions created by the test group
3. • Transactions previously processed in the production environment

In stress testing, the system should be run as it would in the production environment. Operators should use standard documentation, and the people entering transactions or working with the system should be the clerical personnel that will work with the system after it goes into production. Online systems should be tested for an extended period of time, and batch systems tested using more than one batch of transactions.

Stress testing should be used when there is uncertainty regarding the amount of work the application system can handle without failing. Stress testing attempts to break the system by overloading it with a large volume of transactions. Stress testing is most common with online applications because it is difficult to simulate heavy volume transactions using the other testing techniques.

The disadvantage of stress testing is the amount of time it takes to prepare for the test, plus the amount of resources consumed during the actual execution of the test. These costs need to be weighed against the risk of not identifying volume-related failures until the application is placed into an operational mode.(126)

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Softeare Testing V Model 11 steps

This post is in continuation with Software Testing V model.

Step 1: Assess Development Plan and Status

This first step is a prerequisite to building the Verification, Validation, and Testing (VV&T) Plan used to evaluate the implemented software solution. During this step, testers challenge the completeness and correctness of the development plan. Based on the extensiveness and completeness of the Project Plan the testers can estimate the amount of resources they will need to test the implemented software solution.

Step 2: Develop the Test Plan

Forming the plan for testing will follow the same pattern as any software planning process. The structure of all plans should be the same, but the content will vary based on the degree of risk the testers perceive as associated with the software being developed.

Step 3: Test Software Requirements

Incomplete, inaccurate, or inconsistent requirements lead to most software failures. The inability to get requirements right during the requirements gathering phase can also increase the cost of implementation significantly. Testers, through verification, must determine that the requirements are accurate, complete, and they do not conflict with one another.

Step 4: Test Software Design

This step tests both external and internal design primarily through verification techniques. The testers are concerned that the design will achieve the objectives of the requirements, as well as the design being effective and efficient on the designated hardware.

Step 5: Program (Build) Phase Testing

The method chosen to build the software from the internal design document will determine the type and extensiveness of tests needed. As the construction becomes more automated, less testing will be required during this phase. However, if software is constructed using the waterfall process, it is subject to error and should be verified. Experience has shown that it is significantly cheaper to identify defects during the construction phase, than through dynamic testing during the test execution step.

Step 6: Execute and Record Results

This involves the testing of code in a dynamic state. The approach, methods, and tools specified in the test plan will be used to validate that the executable code in fact meets the stated software requirements, and the structural specifications of the design.

Step 7: Acceptance Test

Acceptance testing enables users to evaluate the applicability and usability of the software in performing their day-to-day job functions. This tests what the user believes the software should perform, as opposed to what the documented requirements state the software should perform.

Step 8: Report Test Results

Test reporting is a continuous process. It may be both oral and written. It is important that defects and concerns be reported to the appropriate parties as early as possible, so that corrections can be made at the lowest possible cost.

Step 9: The Software Installation

Once the test team has confirmed that the software is ready for production use, the ability to execute that software in a production environment should be tested. This tests the interface to operating software, related software, and operating procedures.

Step 10: Test Software Changes

While this is shown as Step 10, in the context of performing maintenance after the software is implemented, the concept is also applicable to changes throughout the implementation process. Whenever requirements change, the test plan must change, and the impact of that change on software systems must be tested and evaluated.

Step 11: Evaluate Test Effectiveness

Testing improvement can best be achieved by evaluating the effectiveness of testing at the end of each software test assignment. While this assessment is primarily performed by the testers, it should involve the developers, users of the software, and quality assurance professionals if the function exists in the IT organization.

Related Posts

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software V Model Testing

Life cycle testing involves continuous testing of the system during the developmental process. At predetermined points, the results of the development process are inspected to determine the correctness of the implementation. These inspections identify defects at the earliest possible point.

Life cycle testing cannot occur until a formalized Systems Development Life Cycle (SDLC) has been incorporated. Life cycle testing is dependent upon the completion of predetermined deliverables at specified points in the developmental life cycle.

If information services personnel have the discretion to determine the order in which deliverables are developed, the life cycle test process becomes ineffective. This is due to variability in the process, which normally increases cost.

The life cycle testing concept can best be accomplished by the formation of a test team. The team is comprised of members of the project who may be both implementing and testing the system. When members of the team are testing the system, they must use a formal testing methodology to clearly distinguish the implementation mode from the test mode. They also must follow a structured methodology when approaching testing the same as when approaching system development.

Without a specific structured test methodology, the test team concept is ineffective because team members would follow the same methodology for testing as they used for developing the system. Experience shows people are blind to their own mistakes, so the effectiveness of the test team is dependent upon developing the system under one methodology and testing it under another.

The life cycle testing concept is illustrated in Figure below. This illustration shows that when the project starts both the system development process and system test process begins. The team that is developing the system begins the systems development process and the team that is conducting the system test begins planning the system test process. Both teams start at the same point using the same information.

The systems development team has the responsibility to define and document the requirements for developmental purposes. The test team will likewise use those same requirements, but for the purpose of testing the system. At appropriate points during the developmental process, the test team will test the developmental process in an attempt to uncover defects. The test team should use the structured testing techniques outlined in this book as a basis of evaluating the system development process deliverables.
During the system test process, an appropriate set of test transactions should be developed to be completed at the same time as the completion of the application system. When the application meets the acceptance criteria, it can be integrated into the operating environment.

During this process, the systems development team and the systems test team work closely together to ensure that the application is properly integrated into the production environment.

At that point, the teams again split to ensure the correctness of changes made during the maintenance phase. The maintenance team will make whatever changes and enhancements are necessary to the application system, and the test team will continue the test process to ensure that those enhancements are properly implemented and integrated into the production environment.

In the V-testing concept, project’s Do and Check procedures slowly converge from start to finish which indicates that as the Do team attempts to implement a solution, the Check team concurrently develops a process to minimize or eliminate the risk. If the two groups work closely together, the high level of risk at a project’s inception will decrease to an acceptable level by the project’s conclusion.(119)

Related Posts

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing Static and Dynamic

Static testing is performed using the software documentation. The code is not executing during static testing. Dynamic testing requires the code to be in an executable state to perform the tests.

Most verification techniques are static tests.

1 • Feasibility Reviews – Tests for this structural element would verify the logic flow of a unit of software.

2 • Requirements Reviews – These reviews verify software relationships; for example, in any particular system, the structural limits of how much load (e.g., transactions or number of concurrent users) a system can handle.

Most validation tests are dynamic tests. Examples of this are:

1 • Unit Testing : These tests verify that the system functions properly; for example, pressing a function key to complete an action.

2 • Integrated Testing : The system runs tasks that involve more than one application or database to verify that it performed the tasks accurately.

3 • System Testing : The tests simulate operation of the entire system and verify that it ran correctly.

4 • User Acceptance : This real-world test means the most to your business, and unfortunately, there’s no way to conduct it in isolation. Once your organization’s staff, customers, or vendors begin to interact with your system, they’ll verify that it functions properly for you.

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing Functional and Structural

Functional testing is sometimes called black-box testing because no knowledge of the internal logic of the system is used to develop test cases. For example, if a certain function key should produce a specific result when pressed, a functional test validates this expectation by pressing the function key and observing the result. When conducting functional tests, you’ll use validation techniques
almost exclusively.

Conversely, structural testing is sometimes called white-box testing because knowledge of the internal logic of the system is used to develop hypothetical test cases. Structural tests use verification predominantly. If a software development team creates a block of code that will allow a system to process information in a certain way, a test team would verify this structurally by reading the code, and given the system’s structure, see if the code would work reasonably. If they felt it could, they would plug the code into the system and run an application to structurally validate the code.

Each method has its pros and cons:

Functional Testing Advantages

1• Simulates actual system usage.
2• Makes no system structure assumptions

Functional Testing Disadvantages

1• Potential of missing logical errors in software
2• Possibility of redundant testing

Structural Testing Advantages

1• You can test the software’s structure logic
2• You test code that you wouldn’t use if you performed only functional testing

Structural Testing Disadvantages

1• Does not ensure that you’ve met user requirements
2• Its tests may not mimic real-world situations

A functional test case might be taken from the documentation description of how to perform a certain function, such as accepting bar code input. A structural test case might be taken from a technical documentation manual. To effectively test systems, you need to use both methods.

Related Posts
CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing - verification and Validation of a process

Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review or non-executable methods. Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated.

Verification requires several types of reviews, including requirements reviews, design reviews, code walk through's, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects.

Examples of system verifications :
The fallowing table illustrates the examples of verifications.

Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car). Examples of validation are shown in Table below.

Determining when to perform verification and validation relates to the development, acquisition, and maintenance of software. For software testing, this relationship is especially critical because:

1 • The corrections will probably be made using the same process for developing the software. If the software was developed internally using a waterfall methodology, that methodology will probably be followed in making the corrections; on the other hand, if the software was purchased or contracted, the supplier will likely make the correction. You’ll need to prepare tests for either eventuality.

2 • Testers can probably use the same test plans and test data prepared for testing the original software. If testers prepared effective test plans and created extensive test data, those plans and test data can probably be used in the testing effort, thereby reducing the time and cost of testing. (116.2)

Related Posts
CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Break Statement in C Programming

When break is encountered inside any loop, control automatically passes to the first statement after the loop. A break is usually associated with an if.

Example: Write a program to determine whether a number is prime or not. A prime number is one, which is divisible only by 1 or itself.

All we have to do to test whether a number is prime or not, is to divide it successively by all numbers from 2 to one less than itself. If remainder of any of these divisions is zero, the number is not a prime. If no division yields a zero then the number is a prime number.

Following program implements this logic.

main( )
{
int num, i ;
printf ( "Enter a number " ) ;
scanf ( "%d", &num ) ;
i = 2 ;
while ( i <= num - 1 ) { if ( num % i == 0 ) { printf ( "Not a prime number" ) ; break ; } i++ ; } if ( i == num ) printf ( "Prime number" ) ; } In this program the moment num % i turns out to be zero, (i.e. num is exactly divisible by i) the message “Not a prime number” is printed and the control breaks out of the while loop. There are two ways the control could have reached outside the while loop: 1 . It jumped out because the number proved to be not a prime. 2. The loop came to an end because the value of i became equal to num. When the loop terminates in the second case, it means that there was no number between 2 to num - 1 that could exactly divide num. That is, num is indeed a prime. If this is true, the program should print out the message “Prime number”. The keyword break, breaks the control only from the while in which it is placed. The following is the example to explain this point. main( ) { int i = 1 , j = 1 ; while ( i++ <= 100 ) { while ( j++ <= 200 ) { if ( j == 150 ) break ; else printf ( "%d %d\n", i, j ) ; } } } In this program when j equals 150, break takes the control outside the inner while only, since it is placed inside the inner while. The previous post of the blog deals with nested if statement of IF'S.

Learn complete course of C Programming here.

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions


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

Nested IF ELSES in C Programming

We can use to write an entire if-else construct within either the body of the if statement or the body of an else statement. This is called ‘nesting’of ifs.

Note that the second if-else construct is nested in the first else statement. If the condition in the first if statement is false, then the condition in the second if statement is checked. If it is false as well, then the final else statement is executed.

You can see in the program how each time a if-else construct is nested within another if-else construct, it is also indented to add clarity to the program. Inculcate this habit of indentation, otherwise you would end up writing programs which nobody (you included) can understand easily at a later date.

In the sample program an if-else occurs within the else block of the first if statement. Similarly, in some other program an if-else may occur in the if block as well. There is no limit on how deeply the ifs and the elses can be nested.

Here is the sample code to execute the nested if else statements.

main( )

{

int i ;

printf ( "Enter either 1 or 2 " ) ;

scanf ( "%d", &i ) ;

if ( i == 1 )

printf ( "You would go to heaven !" ) ;

else

{

if ( i == 2 )

printf ( "Hell was created with you in mind" ) ;

else

printf ( "How about mother earth !" ) ;

}

}

Related Posts :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

IF - ELSE Statements

The if statement by itself will execute a single statement, or a group of statements, when the expression following if evaluates to true. It does nothing when the expression evaluates to false.To execute one group of statements if the expression evaluates to true and another group of statements if the expression evaluates to false we use the else statement .

Example:

In a company an employee is paid as under:

salary and DA = 90% of basic salary. If his salary is either equal to or above Rs. 1500, then HRA = Rs. 500 and DA = 98% of basic salary. If the employee's salary is input through the keyboard write a program to find his gross salary.

main( )

{

float bs, gs, da, hra ;

printf ( "Enter basic salary " ) ;

scanf ( "%f", &bs ) ;

if ( bs <>

{

hra = bs * 10 / 100 ;

da = bs * 90 / 100 ;

}

else

{

hra = 500 ;

da = bs * 98 / 100 ;

}

gs = bs + hra + da ;

printf ( "gross salary = Rs. %f", gs ) ;

}

The flow of control is given as shown below.

Here are the few points to concentrate further.

1 . The group of statements after the if up to and not including the else is called an ‘if block’. Similarly, the statements after the else form the ‘else block’.

2 . Notice that the else is written exactly below the if. The statements in the if block and those in the else block have been indented to the right. This formatting convention is followed throughout the book to enable you to understand the working of the program better.

3 . Had there been only one statement to be executed in the if block and only one statement in the else block we could have dropped the pair of braces.

4 . As with the if statement, the default scope of else is also the statement immediately after the else. To override this default scope a pair of braces as shown in the above example must be used.
78.2

The previous post of the blog deals with Multiple Statements with in IF .

Related Post :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

Mulitple Statements with in IF

It may so happen that in a program we want more than one statement to be executed if the expression following if is satisfied. If such multiple statements are to be executed then they must be placed within a pair of braces as illustrated in the following example.
Example : The current year and the year in which the employee joined the organization are entered through the keyboard. If the number of years for which the employee has served the organization is greater than 3 then a bonus of Rs. 2500/- is given to the employee. If the years of service are not greater than 3, then the program should do nothing.

Here is the sample code :
main( )
{
int bonus, cy, yoj, yr_of_ser ;
printf ( "Enter current year and year of joining " ) ;
scanf ( "%d %d", &cy, &yoj ) ;
yr_of_ser = cy - yoj ;
if ( yr_of_ser > 3 )
{
bonus = 2500 ;
printf ( "Bonus = Rs. %d", bonus ) ;
}
}

Observe that here the two statements to be executed on satisfaction of the condition have been enclosed within a pair of braces.

If a pair of braces is not used then the C compiler assumes that the programmer wants only the immediately next statement after the if to be executed on satisfaction of the condition. In other words we can say that the default scope of the if statement is the immediately next statement after it.

Here is the flow chart of the sequence of above program.

The previous post of the blog deals with IF Statement in C programing.

Related Posts

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

If Statement in C Programming

C uses the keyword if to implement the decision control instruction. The general form of if statement looks like this:

if ( this condition is true )

execute this statement ;

The keyword if tells the compiler that what follows is a decision control instruction. The condition following the keyword if is always enclosed within a pair of parentheses. If the condition, whatever it is, is true, then the statement is executed. If the condition is not true then the statement is not executed; instead the program skips past it.

As a general rule, we express a condition using C’s ‘relational’ operators. The relational operators allow us to compare two values to see whether they are equal to each other, unequal, or whether one is greater than the other. Here’s how they look and how they are evaluated in C.

Sample program to execute C Program :

main( )
{
int num ;
printf ( "Enter a number less than 10 " ) ;
scanf ( "%d", &num ) ;
if ( num <= 10 ) printf ( "What an obedient servant you are !" ) ; } On execution of this program, if you type a number less than or equal to 10, you get a message on the screen through printf( ). If you type some other number the program doesn’t do anything. The following flowchart would help you understand the flow of control in the program. 70.1
The previous post of the blog deals with Operators in C Programming.

Related Posts :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

C Language Operators Associativity

When an expression contains two operators of equal priority the tie between them is settled using the associativity of the operators. Associativity can be of two types—Left to Right or Right to Left. Left to Right associativity means that the left operand must be unambiguous. It means it can not be involved in evaluation of any other sub-expression. Similarly, in case of Right to Left associativity the right operand must be unambiguous.

Let us understand this with an example.

EX 1 : Consider the expression a = 3 / 2 * 5 ;

Here there is a tie between operators of same priority, that is between / and *. This tie is settled using the associativity of / and *. But both enjoy Left to Right associativity. The following diagram shows for each operator which operand is unambiguous and which is not.


Since both / and * have L to R associativity and only / has unambiguous left operand (necessary condition for L to R associativity) it is performed earlier.

EX 2 : Consider one more expression a = b = 3 ;

Here both assignment operators have the same priority and same associativity (Right to Left). The following Figure shows for each operator which operand is unambiguous and which is not.


Since both = have R to L associativity and only the second = has unambiguous right operand (necessary condition for R to L associativity) the second = is performed earlier.

EX 3 : Consider yet another expression z = a * b + c / d ;

I request you to share this page on your favorite social book marking site with the below link.

Here * and / enjoys same priority and same associativity (Left to Right). The below Figure shows for each operator which operand is unambiguous and which is not.


Here since left operands for both operators are unambiguous Compiler is free to perform * or / operation as per its convenience since no matter which is performed earlier the result would be same.
54.1

The previous post of the blog deals with Priority of mathematical operators in C Programming.

Related Posts :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions