Skip to Content

PREREQUISITES

The looping capability are planned to be shipped with SAP Solution Manager 7.1 SP13

Alternatively you can implement following notes in advance:

  • 2088536 – Downport CBTA Default Components
  • 2088525 – IF and LOOP Default Components for CBTA
  • 2029868 – CBTA – Runtime Library – Fixes & improvements

USE-CASE FOR LOOP FUNCTIONALITY:

A test script may need to perform actions against an unknown number of entries in a table. The script may therefore need to:

  • Start at first row and check if there is an entry
  • If entry exists perform one or more actions on the current row
  • Continue with next row

REQUIRED DEFAULT COMPONENTS: DO, EXIT_DO, LOOP

Keyword: DO

It can be used to iterate over several steps. It defines where the loop starts.

  • It must be used together with the LOOP keyword which defines where the loop ends.
  • The EXIT_DO keyword must be used as well to determine when to stop the loop.

The CounterName parameter provides the name of the iteration counter. This counter is incremented automatically at runtime while iterating over the included steps. The actual value of the counter can be retrieve using the regular token syntax.

For instance, when CounterName is set to “COUNTER” its value can be reused in the subsequent steps using %COUNTER% (or $COUNTER$ for specific situations where the percent character is ambiguous).

If you plan to use nested loops please make sure to declare a different counter names.

Component Parameters

CounterName: Specifies the the name of the iteration counter.

Keyword: EXIT DO

It must be used within a loop that has been defined using the DO and the LOOP keywords. The EXIT_DO keyword interrupts the loop as soon as the condition is met.

A typical use case is to check the value of iteration counter that has been declared via the CounterName parameter of the DO keyword.

For instance, when CounterName is set to “COUNTER” its value can be checked using the %COUNTER% token.

Component Parameters

LeftOperand

  • Specifies the value of the left operand that is to be checked.

Operator

  • Specifies the boolean operator to use.

The operators supported are the ones below:

    • = for “Equal to”
    • < for “Less than”
    • > for “Greater than”
    • <= for “Less than or equal to”
    • >= for “Greater than or equal to”
    • <> for “Not equal to”
    • {contains} for “Contains”
    • {startsWith} for “Starts with”
    • {endsWith} for “Ends with”

An additional operator is supported when testing WEB applications (i.e.: applications running in the browser):

    • {matches} for checking whether the value matches a regular expression. The regular expressions are expressed using the .NET syntax.

RightOperand

  • Specifies the value of the right operand that is to be compared with the left operand.

Options

The options parameter lets you perform some adaptations or conversions of both the left and right operand before comparing them.

The supported options are:

  • /u (for uppercase) – Both values are converted to upper-case before being compared
  • /t (for trimmed) – Both values are trimmed before being compared
  • /i (integer) – Both values are converted to an integer before being compared
  • /f (float) – Both values are converted to a float (or double) before being compared
  • /b (bool) – Both values are converted to a Boolean before being compared

Keyword: LOOP

It defines the end of the loop and must be used together with the DO keyword which defines where the loop starts.

EXAMPLE – PROCESS LINE ITEMS IN SALES ORDER

The following scripts was created for transaction VA02 (Change Sales Order) to add shipping information for each line item of an existing sales order.

/wp-content/uploads/2014/12/script_597554.png

With DO Keyword the loop starts and the counter is set to ‘1’.

DO.png

To be able address the row number starting at ‘0’ we take the counter number minus ‘1’ using the CBTA_A_SETINEXECUTIONCTXT component.

SETINEXECONTEXT.png

Then the scripts reads the value of the first row in the first column to check if an entry exists.

GETCELLVALUE.png

If the value is empty we exit the loop with the EXIT_DO keyword.

EXIT_DO.png

Otherwise the scripts performs the required actions for the current row

  • Select row

SELECT_ROW.png

  • Menu Goto –> Item –> Shipping
  • Enter the required shipping information using the related screen component
  • Go back to main screen

With the LOOP keyword the script goes back to the DO keyword while increasing the counter and processing further line items of that sales order.

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. RĂ©mi GODARD

    Hello Reiner,

    We have been waiting for such components for months, this is really great news!

    I suppose the Runtime Library & Default Components doc will be updated in the near future.

    Thank you for having provided explanations for using DO, EXIT_DO and LOOP.

    Do you know if such documentation already exists somewhere for FOR, EXIT_FOR, NEXT?

    I have not been able to install the required notes yet, so I could not check their complexity. Maybe they are equivalent to the others and additional documentation not really urgent…

    Thank you again for this very important release.

    Rémi.

    (0) 
    1. Reiner Markheiser Post author

      Hi Rémi,

      unfortunatelly there is no official documentation available yet for the new capabilities. As the customers I work with also waited for the LOOP features I documented the related use case and wanted to share it for others via this blog.

      The description for each new default component you’ll find as usual in the TCE editor as soon you added it to your script. Maybe this helps already.

      Regards Reiner

      (0) 
      1. Peter O'Leary

        Hi Reiner

        I am interested in CBTA and how it handles background processing i.e. when you want to move towards fully automated scripting i.e. to run  unattended over night which includes and end to end process which may contain steps using batch jobs. If the jobs don’t produce a log or spool output  what are the options to confirm the script has produce the correct result, not just that it completed?

        Can CBTA interrogate spool output?

        Is there any chance we can arrange a call so we can discuss more on the direction of CBTA. Keen to know if their assessment criteria which determines what testing script are or are not candidates for automating.

        Cheers

        Peter

        (0) 
        1. Reiner Markheiser Post author

          Hi Peter,

          these are very good questions I also got from other customers which planned to start with Test Automation. Therefore I started to write a document that should provide some guidance for Regression Test that includes also some input for BPCA. Here the link to the draft version of the document:

          https://mdocs.sap.com/mcm/public/v1/open?shr=w9DGzubR4KM7__kQbFGx7EhpiCt1JXM707Uj7LjU5i8&amp;obj=tilKIOtjHg6J5Xw_2O33e8PdHqr3IcW4flVKn25W79Y

          I hope this answers some of you more generic questions on Test Automation.

          To answer your more specific question regarding CBTA:

          Basically CBTA is able to be executed unattended and it also can handle background jobs. Regarding options to confirm if the script has produced the correct result it is the same approach like for manual testing. Usually I need to ask an application expert, how a manual tester would evaluate if the result is correct or not. Then you typically use a checkpoint to verify if an actual value on the screen meets the expected one. For asynchronous activities like batch jobs it might be necessary to add wait commands or loops for checking the completeness of the job.

          CBTA can basically validate values as part of the spool output as long it is a structured list view. It might not work for all possible output formats.

          For further more individual support SAP has several service offerings in the area of Test Management and Test Automation with CBTA. Please get in touch with your local SAP contact.

          Kind Regards Reiner

          (0) 
          1. Peter O'Leary

            HI Reiner

            Can you please re-confirm that you can load test data into the test data container by excel spreadsheets? or any other suggestions on other technology that can be used so business Analyst can load data into the TDC in advance of testing cycles?

            My belief is you can have multiple test scripts sharing the same TDC…is this correct?

            Can you pass on parameters from  e.g batch to dialog processing….

            How do we test interfaces in CBTA e.g. we output or input file , how do we test the  correctness of the content of a file, a tricky one could be e.g. Process Orchestration messages.

            Really appreciate your help. I would be interested in getting you feedback on the Framework I am working on to carry out the initial assessment of existing scripts if they are candidates for CBTA.

            Many thanks

            Peter

            poleary@deloitte.co.nz

            (0) 
  2. Rutvik Upadhyay

    Hi Peter,


    > Yes you can load the test data into TDC by excel spread sheet. You have to define the parameters first and can export them as excel sheet.


    > You can also use the same TDC for multiple test scripts provided all the parameters by importing them from multiple scripts. Avoid any value to the parameter which is not intended to a particular script while creating a variant. 


    > we can pass the parameter values if they are captured by the scripts while recording or u add them manually (with the help of ‘object spy’). Then change the type to local  and refer that value from the following script.


    > You can test the interface or file monitoring by recording the procedure for appropriate tcodes, putting the check data condition if required through front end tool.


    Regards,

    Rutvik.


    (0) 
      1. Peter O'Leary

        A couple of other questions.

        I am working on a Framework to allow a process where we can make a well though out  decision tree on whether test scripts are candidates for automation (byin this case CBTA). Has anything been develop by SAP? I am happy to share what I have done to date.

        Interested in  your findings to date the percentage when automating existing scripts…that were actually candidates for automation? e.g. on average are 30% of existing scripts meet a criteria to be automated….or is it much higher

        I am interested gaining more material to myself to understanding the additional scripting needed after recording the script, to make it re-useable…examples of the level detail around checks etc passing values, between scripts….has anyone publish a guide with examples of scripting.

        if you are testing a business process, which may be covered by example 7 Test scripts and 2 in the middle are not necessary candidates to be automated by CBTA…how have you tackled  this when the idea is to run the scripts over night without manual intervention.

        (0) 
  3. Peter O'Leary

    Another quick thing there was a document published in 2011 SAP Solution Manager – How to Guide Test Automation……the problem is prior to CBTA. Is there  a more up to date version that does cover CBTA?

    (0) 
      1. Peter O'Leary

        Hi Reiner

        I sent to this email address  reiner.markheiser@sap.com an Excel Worksheet we are building to allow an assessment to be made on which “Test Scripts” make sense to automate i.e. the benefit from both a Business and Technical 

        The idea is to have the Test Analyst/Engineer to carry out a triage of the testing’s scripts before any work starts on recording them.

        I would really appreciate your feedback or your colleagues who may be interested in this.

        My email is poleary@deloitte.co.nz.

        Cheers

        Peter

        (0) 
  4. Harald Ahorner

    Hi Reiner,

    I composed yesterday a test script using the new  IF/ELSE/ENDIF CBTA component.

    We figured out, that the system gives you always a FAIL in the evaluation of the IF component, when the condition of the IF statement is evaluated with FALSE and a PASS, when it is true.

    Is there a way to avoid the FAIL behaviour. All what I want to achieve is to route the logic in different ways, depending of the IF condition, without influencing the outcome of the test. Is this maybe a paramenter in the option, which is documented? I was then able to achieve this with the SETCONDITION component.

    Many thanks for your clarifications,

    Cheers,

    Harald

    (0) 
    1. Reiner Markheiser Post author

      Hi Harald,

      can you double check in the execution report, if the IF component causes the fail of the script ? Maybe the fail is caused by another step in the script.

      I have used the IF component several times and never had this behaviour.

      Regards Reiner

      (0) 
      1. Harald Ahorner

        Hi Reiner,

        Thanks for your reply! We checked this now several times in different areas and it is all over the place the same result. Once the if condition is evaluated to FALSE, this gives you an overall FAIL in the test case, instead of just branching out to the ELSE part of the statement (what it does correctly, but as it is FAILED in the first place it is not very meaningful). I attach you some logs to show you the problem.

        Cheers,

        Harald

        IF FALSE CONDITON .jpg

        IF TRUE CONITION.jpg

        (0) 

Leave a Reply