ABAP object

[Former Member]

Hi Experts,

Whether all the ABAP developed objects are tested by ABAPers in Testing server?

If so, how will they proceed?

Is there any tool for the same?

<b>Point will be rewarded for useful answers.</b>

Thanks,

kavitha.

[Former Member]

Hi

First Do the Extended program check and the Code Inspector in Se38 itself

Then do the SQL trace and Runtime analysis if you feel that the performance is not upto mark

Then prepare a unit testing document with some sample test cases and document it

What should be the input and what should be the expected output from that program

for each program you have to do like this as a ABAPer

Regards

Anji

[Former Member]

hi,

As per my knowledge, on Testing server Abaper has no need to test the program, he is responsible to do unit testing on Developement server.

The tools used to test the programs are CATT and ECATT

regards,

pavan

[Former Member]

Hi

AFTER YOU DEVELOP THE OBJECT YOU CAN CHECK WITH THE TEST DATA IN DEVELOPMENT CLIENT

IF YOU WANT TO CHECK PERFORMANCE WISE YOU CAN GO FOR CODE INSPECTOR OR ECP CHECK

THE TESTING WILL BE DONE BY SOME FUNCTIONAL CUNSULTANT IN THE TESTING SERVER

WE DON'T NEED TO CHECK IN QUALITY SERVER

JUST WE CAN CHECK THE PROGRAM BY USEING TEHSE TOOLS

Run time analysis transaction SE30

SQL Trace transaction ST05

Extended Program Check (SLIN)

Code Inspector ( SCI)

Run time analysis transaction SE30 :This transaction gives all the analysis of an ABAP program with respect to the database and the non-database processing. 

SQL Trace transaction ST05: The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.

The trace list contains different SQL statements simultaneously related to the one SELECT statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated component of the R/3 Application Server - maps every Open SQL statement to one or a series of physical database calls and brings it to execution. This mapping, crucial to R/3s performance, depends on the particular call and database system. For example, the SELECT-ENDSELECT loop on a particular database table of the ABAP program would be mapped to a sequence PREPARE-OPEN-FETCH of physical calls in an Oracle environment.

The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP statement. This is because in an R/3 system, a client is a self-contained unit with separate master records and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open SQL statement automatically executes within the correct client environment. For this reason, a condition with the actual client code is added to every WHERE clause if a client field is a component of the searched table.

To see a statement's execution plan, just position the cursor on the PREPARE statement and choose Explain SQL. A detailed explanation of the execution plan depends on the database system in use.

Extended Program Check

This can be called in through transaction SE38 or through transaction SLIN. This indicates possible problems that may cause performance problems.

Code Inspector (SCI)

You can call the Code Inspector from the ABAP Editor (SE38), the Function Builder (SE37), the Class Builder (SE24), or as a separate transaction (SCI).

The Code Inspector indicates possible problems. However, note that, especially with performance issues: There is no rule without exception. If a program passes an inspection, it does not necessarily mean that this program will have no performance problems.

[matt]

You want to check that all developments have been tested in your test system, if I understand correctly.

You need the ABAP Coverage Analyser for this. It can be used for precisely this purpose.

<a href="http://help.sap.com/saphelp_nw04/helpdata/en/c7/af9a79061a11d4b3d4080009b43351/frameset.htm">Link</a>

matt

[Former Member]

Hi Kavitha,

I am working in SAP. Every report will be tested before it goes to end production(In SAP terminology we call them it as production box). If u want to test ur report u check.The procedure is

After ur report is developed in SE38 Transaction.

Goto UTILITIES(present in menu bar)-->MORE UTILITIES---->RUN TIME ANALYSIS.

select the PROGRAM RADIO BUTTON

program : mention ur report name there

ex: program : zreport.

AND click the EXECUTE BUTTON AND once again click the execute button u will see ur report output. and comes back and click the ANALYZE BUTTON and it will display the graph..

IF IT IS RED : POOR PROGRAMING

IF IT IS GREEN : BETTER PERFORMANCE

it will show

abap: this is ur program performance

database : In ur program u can access data from database .it shows that performnace.if it is red u can change ur select statemets in the program.

SOLUTION: WE READ SOME MATERIAL ON PERFORAMANCE TUNNIG.

I WILL SEND SOME POINTS:THAT IMPROVE UR PROGRAM PERFORMANCE.

STEPS:

1. Avoid using SELECT...ENDSELECT... construct and use SELECT ... INTO TABLE.

2. Use WHERE clause in your SELECT statement to restrict the volume of data retrieved.

3. Design your Query to Use as much index fields as possible from left to right in your WHERE statement

4. Use FOR ALL ENTRIES in your SELECT statement to retrieve the matching records at one shot.

5. Avoid using nested SELECT statement, SELECT within LOOPs.

6. Avoid using INTO CORRESPONDING FIELDS OF TABLE. Instead use INTO TABLE.

7. Avoid using SELECT * and Select only the required fields from the table.

8. Avoid nested loops when working with large internal tables.

9. Use assign instead of into in LOOPs for table types with large work areas

10. When in doubt call transaction SE30 and use the examples and check your code

11. Whenever using READ TABLE use BINARY SEARCH addition to speed up the search. Be sure to sort the internal table before binary search. This is a general thumb rule but typically if you are sure that the data in internal table is less than 200 entries you need not do SORT and use BINARY SEARCH since this is an overhead in performance.

12. Use "CHECK" instead of IF/ENDIF whenever possible.

13. Use "CASE" instead of IF/ENDIF whenever possible.

14. Use "MOVE" with individual variable/field moves instead of "MOVE-CORRESPONDING", creates more coding but is more effcient.

[Former Member]

Hi Kavitha,

If u r satisfy with my answer PLZ give me REWARD POINTS..

Regards,

kiran kumar.G

[Clemenss]

... different scenarios are possible. This is an IT management decision

Regards,

Clemens

<b>DON'T REWARD PEOPLE ASKING FOR POINTS.</b>