unit testing and integration testing

[Former Member]

hello 2 all,

what is the diff bet unit and integration testing? in sap what is unit teesting consists of and integration testing consists of what?

is this the work of test engineers r whose work is this?

take care

love ur parents

[Former Member]

Dear Sameer,

there are 6 types of testings:

1. Unit Testing

2. System Testing

3. System Integration security Testing

4. Performance Testing

5. User Acceptance testing

6. Regression Testing

Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we do have 1-create order, then 2-delivery, then 3-transfer order, then 4-PGI and then 5-Invoice. So we will be testing 1,2,3,4 and 5 seperately alone one by one using test cases and test data. We will not be looking and checking/testing any integration between order and delivery; delivery and TO; TO and PGI and then invoice.

Whrereas System testing you will be testing the full cycle with it's integration, and you will be testing using test cases which give a full cyclic test from order to invoice.

Security testing you will be testing different roles and functionalities and will check and signoff.

Performance testing is refered to as how much time / second will take to perform some actions, like e.g. PGI. If BPP defination says 5 seconds for PGI then it should be 5 and not 6 second. Usually it is done using software.

Regression testing is reffered to a test which verfies that some new configuration doesnot adversly impact existing functionality. This will be done on each phase of testing.

User Acceptance Testing: Refers to Customer testing. The UAT will be performed through the execution of predefined business scenarios, which combine various business processes. The user test model is comprised of a sub-set of system integration test cases.

We use different software during testing. Most commonly use are

Test Director: which is used to record requirement, preparing test plan and then recording the progress. We will be incorporating defects that are coming during these testings using different test cases.

Mercury Load Runner: is used for performance testing. This is an automatic tool.

Hope this helps you.

Do award points if you found them useful.

Regards,

Rakesh

[Former Member]

Hi Sameer,

This is my First rep to this group as i have joined last night. And I thank Mr.Ramu for his light about SDN.

U must have understood what is UNIT TESTING as other folks given many replies,

<b>My views on integration testing according to <b>AcceleratedSAP</b>.</b>

In ASAP, a test plan that combines the defined resources, time frames, scope and procedures for performing integration testing.

It can be The testing a chain of business processes that flow together and cross functional boundaries.

Integration testing also involves outputs, interfaces, procedures, organizational design, and security profiles and focuses on likely business events and high-impact exceptions.

The Business Process Master List contains the following testing spreadsheets:

For "Integration test 1"(end-to-end scenarios), the testing scenarios focus on business cases that are within the R/3 environment, such as cross-functional or organizational boundaries, and R/3 authorizations.

For "Integration test 2", the testing scenarios also focus on the integration to external components, connecting many business cases to form a complete business cycle. The main focus is on testing R/3 with all interfaces, reports, all forms of output, EDI, ALE, and converted master data.

for practice u may test credit management scenario:

If you are using both the Accounts Receivable (FI-AR) component to manage your accounting and the Sales and Distribution (SD) component for sales processing, you can also use Credit Management to issue credit limits for your customers. You can make settings in Customizing to decide the scope of the check and at what stage in the process (for example, order entry, delivery or goods issue) a credit limit should take place. General information functions are also available for use with credit checks.

<b>Hope MY VIEWS will help you Out.

AZHAR S</b>

[Former Member]

Hi Sameer,

<b>Unit Testing</b> means testing Your Object as a unit, with out considering any dependencis of other objects;

Testing the object for the functionality and testing with some test cases , testing the output based on the various inputs.

<b>Integration Testing:</b> testing the object w.r.t to other modules also;

if the data into your object is related to other modules, if the change in business scenario in one module is going to effect in other modules, so the integration between the functionality of all objects will be checked.

After the required Configurations and Customizations are done, the testing is done by the functional consultants to see if it is in line with the business requirement. Found good, the end users also test it in the test server. Then they are moved to the production system.

Please reward if useful.

Thanks & Regards

Sadhu Kishore

[Former Member]

Unit Testing

A unit test is a procedure used to validate that a particular module of source code is working properly from each modification to the next. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. Ideally, each test case is

separate from the others; constructs such as mock objects can assist in separating unit tests. This type of testing is mostly done by the developers and not by end-users.

Integration testing

Integration testing can proceed in a number of different ways, which can be broadly characterized as top down or bottom up. In top down integration testing the high level control routines are tested first, possibly with the middle level control structures present only as stubs. Subprogram stubs were presented in Section 2 as incomplete subprograms which are only present to allow the higher level control routines to be tested. Thus a menu driven program may have the major menu options initially only present as stubs, which merely announce that they have been successfully called, in order to allow the high level menu driver to be tested.

Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control

throughout the application. In practice a combination of the two techniques would be used. At the initial stages all the modules might be only partly functional, possibly being implemented only to deal with non-erroneous data. These would be tested in breadth-first manner, but over a period of time each would be

replaced with successive refinements which were closer to the full functionality. This allows depth-first testing of a module to be performed simultaneously with breadth-first testing of all the modules.The other major category of integration testing is bottom up integration testing where an individual module is

tested from a test harness. Once a set of individual modules have been tested they are then combined into a collection of modules, known as builds, which are then tested by a second test harness. This process can continue until the build consists of the entire application.

In practice a combination of top-down and bottom-up testing would be used. In a large software project being developed by a number of sub-teams, or a smaller project where different modules were being built by individuals. The sub-teams or individuals would conduct bottom-up testing of the modules which they were

constructing before releasing them to an integration team which would assemble them together for top-down testing.

[Former Member]

Hi Sameer,

Unit Testing

A unit test is a procedure used to validate that a particular module of source code is working properly from each modification to the next. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. Ideally, each test case is

separate from the others; constructs such as mock objects can assist in separating unit tests. This type of testing is mostly done by the developers and not by end-users.

Integration testing

Integration testing can proceed in a number of different ways, which can be broadly characterized as top down or bottom up. In top down integration testing the high level control routines are tested first, possibly with the middle level control structures present only as stubs. Subprogram stubs were presented in Section 2 as incomplete subprograms which are only present to allow the higher level control routines to be tested. Thus a menu driven program may have the major menu options initially only present as stubs, which merely announce that they have been successfully called, in order to allow the high level menu driver to be tested.

Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control

throughout the application. In practice a combination of the two techniques would be used. At the initial stages all the modules might be only partly functional, possibly being implemented only to deal with non-erroneous data. These would be tested in breadth-first manner, but over a period of time each would be

replaced with successive refinements which were closer to the full functionality. This allows depth-first testing of a module to be performed simultaneously with breadth-first testing of all the modules.The other major category of integration testing is bottom up integration testing where an individual module is

tested from a test harness. Once a set of individual modules have been tested they are then combined into a collection of modules, known as builds, which are then tested by a second test harness. This process can continue until the build consists of the entire application.

In practice a combination of top-down and bottom-up testing would be used. In a large software project being developed by a number of sub-teams, or a smaller project where different modules were being built by individuals. The sub-teams or individuals would conduct bottom-up testing of the modules which they were

constructing before releasing them to an integration team which would assemble them together for top-down testing.

I think this will help.

Thanks ,

Saptarshi

[Former Member]

Hi,

Unit testing is refer to the module which are going to implement. SD, MM, FICO etc. there will be test script based on that testing will be performed.

Integration testing will be cross the modules. MM-SD-FICO for example. Integration testing is also called SIT ( System integration testing

Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we do have 1-create order, then 2-delivery, then 3-transfer order, then 4-PGI and then 5-Invoice. So we will be testing 1,2,3,4 and 5 seperately alone one by one using test cases and test data. We will not be looking and checking/testing any integration between order and delivery; delivery and TO; TO and PGI and then invoice.

Whrereas System testing you will be testing the full cycle with it's integration, and you will be testing using test cases which give a full cyclic test from order to invoice.

With regards

Rajesh

[Former Member]

Hi Sameer,

Usually the development is done in a development environment for ex DV...here once the ABAP development is done the functional does the unit testing to make sure the functionalities are in place. Once this is doen the change is moved to IT/UT sytems...here again the functional does the testing (integration testing) This system will be usually a refreshed quite frquently and have a very close resemblence to Production PD server.

Once the functional says the Integration testing is ok then usually User does a UAT (user acceptance testing) and once that is thru then the changes are moved to production.

hope this gives an answer to ur querry.

reward points if it helps

regards

biju