Shulou(Shulou.com)06/01 Report--

This article is about how to analyze SAP Cloud for Sales automation, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Today, based on the current situation of C4S products and their own technical background, I would like to talk briefly about automation, which is a touching topic that people both love and hate.

I believe that every member of any software development team will have enthusiastic expectations when they hear the word "automation". For the boss, the word means lower costs and higher ROI (Return On Investment, return on investment); from the development engineer's point of view, automation helps to detect the impact of code changes on original functionality earlier; test engineers are of course fully supportive of automation because it saves worry and effort; and product managers naturally do not refuse automation because it leads to more efficient delivery and faster iterations.

However, there is no shortage of failed automation teams around us. In 2013, in my previous company, I was involved in the development of a core system project, which took a year and a half from requirements to full launch, and the development of core functions took more than half a year. In the face of such huge business testing costs and strong requirements, PMO (Project Manage Office) started automated testing requirements at the beginning of project development. However, in the case of unstable business functions, product requirements, development and testing basically belong to the rush state, compared with manual regression, the benefits brought by automation are basically minimal. Therefore, choosing the appropriate timing and strategy of automation is one of the important factors for the success of automation.

As we all know, many SAP products are developed using self-developed ABAP. When I joined SAP, I learned that these products running on ABAP Netweaver have complete automated testing. For the ABAP background function code, the developers mainly write complete and high coverage unit tests for the core functions, and then use the transaction code SUT to schedule the background jobs to be executed periodically. If a fault is found during the automation test execution, the relevant personnel will be notified by email automatically.

Foreground UI code, whether native Fiori applications or CRM Web Client UI-like Fiori applications with a layer of skin, can automate UI testing through Selenium.

Of course, SAP Chengdu Research Institute is also developing many cloud products based on micro-service architecture, mainly using Java programming, so it is easier to implement automated testing. There are a large number of mature and popular automated test suites available in the Spring framework.

From the perspective of iterative release, the release cycle of C4S products is once a quarter, and there are three cycles in each quarter: the first two cycles mainly complete the development of new functions, and the third cycle requires team members to complete new functional tests and return to the original functions of the system. At the same time, there are five patches released each quarter, each of which needs to complete regression testing of the original business. Sandwiched between product new feature testing and regression testing is the endless workload and the need for high-efficiency and high-quality testing.

My strategy for automation for the features that my team is responsible for is: interface + UI automation coverage. You might ask, as the front end of a request, why do automated tests need interface coverage when UI tests can be covered? Is there any duplication of workload? From a functional point of view, there is some repetition. However, from the point of view of revenue, the benefit of investing in the automated testing of the interface far exceeds the cost.

1. For any system, the stability of the interface plays an important role in the whole system. Compared with the post-E2E (end-to-end) testing, interface testing can reduce the impact of changes on the entire application and downstream business callers from the basic layer.

two。 At the same time, the testing of the interface can also provide basic data for the implementation of UI automation.

In order to complete the testing of a scenario, UI automation usually has a lot of dependence on pre-business data. How to generate the test data needed for UI automation? Some colleagues suggested that the data could be created by hand in advance. If the data of automated testing has to be maintained manually, in my opinion, it doesn't matter if this automation is not needed. Usually, after the completion of the interface test, the interface that has been tested will be encapsulated into a tool class for subsequent engineering calls of UI automation, which not only reduces the data dependence of UI automation, but also puts forward higher requirements for the pass rate of interface test. Therefore, the general interface project must be 100% passed in order to complete the function of triggering subsequent UI automation to perform functional tests.

3. Lay a solid foundation for performance testing preparation.

Usually, before preparing the performance test, the response time of the interface test will become an important basis for feedback on the performance of the interface. When we work out the SLA (Service-Level Agreement) of interface performance, the basic data source is interface testing. However, many Internet companies pay more attention to the response time of the interface than the end-to-end response time, because the interface is lower-level. Especially for the multi-layer interface dependent system, the on-line boost test before 618 and double 11 every year, the interface full-link test must be the top priority.

The interface testing framework I recommend for C4S is Spring + Maven + Testng, the language is Java, and the object being tested is HTTP API provided by the C4S oData service. Spring framework is mainly responsible for object injection through annotations, Maven is responsible for engineering structure and Jar package management, and Testng is responsible for specific testing work. For friends who are not familiar with Java, they can do the job well with the help of existing tools such as Postman.

1. Engineering structure and description

The interface body project takes the Maven specification project as the template, and all the codes and related resource files are placed in the src/test directory. The project module is mainly divided into four parts: test code, enumerated objects, tool classes and related resource files.

Test code: this is the main directory where the test code is stored. Usually, according to the difference of the business, we write the test case of each interface according to the business test and parameter test.

The so-called business test refers to the part of the test case that involves business rules. For example, there is a channel field in an interface. Definition of business rules: when channel is all, data for omni-channel use is created; when channel is a specific value, the created data can only be applied to specific scenarios. There are 2 cases of business testing:

O Channel = all

O Channel = specific data

Parameter test: the main test is whether the interface parameter field is required. For example, there is a channel in an interface that is a required field and must be a string of the specified enumeration type. When the incoming interface is null or blank or a non-enumerated value, the framework returns a parameter error of HTTP 400and prompts an error message. At this point, there are 3 parameter test cases:

O Channel = null

O Channel = "" (blank)

O Channel = "XXXX" (XXXX is non-enumerated)

Enumerated objects: this section lists the fixed parameters that are often used in the business by enumerating to facilitate the use of the whole project. See the classes in the httpEnum folder in the following figure.

Tool class: includes basic tool class and business tool class. Business tool class encapsulates specific interfaces to facilitate downstream interface calls.

Resource files: including Spring-related configurations, properties files and data source files in parameter testing.

two。 Case writing

Here is an example of automated testing that implements the SocialMediaActivity interface of oData.

Let's borrow the picture drawn by teacher Li Xiaogang, a master of appearance, to get a general idea of the role of SociaMediaActivity in the C4S Wechat integration architecture:

As shown in the figure above, C4S facilitates Agent calls by exposing the SocialMediaActivity interface.

In the scenarios related to the integration of C4S and Social Media, users can bind a specific BusinessPartner (hereinafter referred to as BP) by following the official account of Wechat, so as to directly interact with the staff in the C4C service module through the Wechat Channel defined by users in the system. Activity is an activity for a specified BP, such as creating a ticket, giving likes, replying, etc. Therefore, the complete business process is as follows:

Get system token

Get associated BP information

Create ticket information

Comment / like / reply operation

Data cleaning

BeforeClass: performs the preparation for getting the token.

BeforeMethod: create / get associated BP information.

Test: test case for a specific business. The department checks the level and operation of Activity, so there are two test methods.

AfterMethod: clean up the created Activity. It should be noted here that in order to avoid the impact of background error data on the normal use of the application, incremental data needs to be cleared for each execution to keep the environment clean and tidy.

AfterClass: cleans up the created BP information.

3. CI (Continuous Integration, continuous integration)

Based on the integration of the Maven project, Jenkins is used for the example in this example, while the project project needs to use surefire-plugin (a Maven plug-in to execute test cases) to configure the relevant test case scope.

Configure the testng.xml file in pom.xml:

Example of testng.xml file content:

Once again, the benefits of using Maven can be used with a simple configuration:

Add the testng report plugin presentation to Jenkins, and then build.

Although I am better at using the Java-based Selenium UI automation framework and understand the great help to UI automation after interface testing, because C4S uses the existing molding product SAHI in both India and the United States, I will only introduce the application of SAHI in C4S here.

SAHI is a business-based automated testing tool for Web applications owned by Tyto Software, which accesses elements in Web pages by injecting JavaScript. Compared with automated testing tools such as Selenium, SAHI has certain advantages in dynamic ID element search and implicit page waiting processing. Interested colleagues can go to the official website to try.

1. Engineering structure and description

Take the Social case as an example:

* * DD_CSV: * * the data source of the case run

* * Function_Library: * * this directory stores encapsulated basic common functions, such as login, logout, work center access, form access, etc. A more detailed encapsulation is to abstract page elements under IDS in Library to facilitate unified management, as shown below:

SCRIPTS: a specific UI test case.

SUITE: the scope of the test case run.

two。 Case writing

Here is an example of the SingleTab function in the RUI project.

MultiTab and SingleTab function means that in C4S products, when the user opens one or more work views in full-screen mode, the system will display multiple work views in the workspace in the form of Tab; but when the user changes the browser size to a certain size, only the active Tab will be displayed in the workspace.

When MultiTab is displayed, it can be divided into active and inactive Tab, and at the same time, it is necessary to adapt to the mouse operation switching of multiple Tab and the switching through the function menu. As shown in the following figure:

SingleTab display: only the currently active Tab is displayed, which is different from MultiTab in data and form. At the same time, it should be adapted to Tab switching through the function menu.

At the same time, this feature requires the test system to work well under different themes and font sizes. Therefore, the flow of the test case is as follows (see the code comments section):

(1) reset related features: browser size, theme, font size, view type, page default filter

(2) access specific working views and display specific data to verify the display of active / inactive MultiTab in full-screen mode and the correctness of data on Tab

(3) reduce the size of the browser:

Verify the correctness of the data on Tab

Modify the system theme to verify the display of the SingleTab

Modify the font size to verify the SingleTab display

3. CI integration

Based on the powerful plug-in function of Jenkins, C4S completes CI scheduling and operation through the integration of Jenkins and GTP (internal defect management platform).

The CI integration of UI automation greatly improves the efficiency of regression testing of C4S products. In the version released in August this year, for example, there are now nearly 7000 test cases of manual regression. As mentioned earlier, the continuous regression testing of many test cases in each iteration is a time-consuming and labor-consuming project. And this is only for cases where regression testing is performed.

From the number of manual regression test cases, it is not difficult to see the importance of fast feedback system functional status mechanism in the continuous delivery chain. After the full coverage testing of the interface, the demand for the main process of UI automatic coverage regression testing is becoming stronger and stronger.

In C4S, we automate UI with the help of Jenkins parallel testing and notify the test results by email. At the same time of saving the manual return cost, the product management team can quickly and comprehensively understand the operation of the system functions in a short time, and give team members confidence in quality. At the same time, when there is module failure or even system downtime, the establishment of this fast feedback chain buys time for developers to fix the problem as soon as possible and reduces the time cost of subsequent repair.

As far as the current test coverage requirements are concerned, interface coverage and end-to-end UI coverage from inside to outside not only satisfy the stability and reliability of the underlying layer, but also ensure the availability of front-end functions. For SAP quality engineers, the work content is far from testing work, from the improvement of team members' quality awareness to unit test coverage and inspection; from testing work to team quality feedback, SAP quality engineers need to think hard in their daily work. Starting from the interests of the team, considering the value and significance of each quality activity is not only a test of the overall view for quality engineers, but also a balance between quality and efficiency.

The above is how to analyze SAP Cloud for Sales automation. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.