SAP电子商务系统动态端到端测试实践：Robot框架应用

Robot框架

测试自动化

需积分: 9 65 浏览量更新于2024-07-20 收藏 1.65MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"这篇论文详细探讨了动态端到端测试技术在SAP电子商务系统中的应用，作者Petri Niemelä通过Robot测试自动化框架提供了一个实际案例。动态功能性端到端测试是确保软件开发项目质量的关键环节，尤其在信息技术日益重要的今天，商业运营和人们的生活质量越来越依赖于信息系统。企业会将业务流程映射到IT系统中，这些流程可能涉及多个组织单元，每个单元可能有自己的独立IT模块，并通过接口进行数据交换。因此，对整个跨系统的业务流程进行端到端测试以确保其正确运行至关重要。随着软件复杂性的增加，自动化测试工具如Robot Framework变得尤为关键。Robot Framework是一个通用的自动化框架，适用于各种不同的测试需求，包括功能测试、回归测试和端到端测试。它采用关键字驱动的测试方法，使得测试用例的编写更加直观和易于理解，这对于SAP这样的复杂系统尤其有用，因为它们通常需要大量的集成测试和系统测试。论文中，Niemelä展示了如何使用Robot Framework构建测试套件来模拟真实的用户交互，验证从一个模块到另一个模块的数据流，以及检查整个SAP电子商务流程的功能完整性。这涉及到对系统接口的测试，确保数据在不同模块间正确传输，同时还要验证业务逻辑是否按照预期执行。此外，该论文还可能涵盖了自动化测试策略的制定，包括测试环境的配置、测试数据的准备、测试脚本的编写和维护，以及如何利用Robot Framework的报告和日志功能来分析测试结果。通过这种自动化测试，可以大大提高测试效率，减少手动测试带来的错误和遗漏，同时缩短测试周期，使得软件发布更快速、更可靠。最后，Niemelä可能还讨论了在实际项目中遇到的挑战，如如何处理测试中的异常情况、如何维护和更新测试套件以适应系统的变化，以及如何在持续集成环境中集成测试自动化。这些实践经验对于其他寻求实施测试自动化的团队来说具有很高的参考价值。这篇论文为SAP系统和其他类似复杂系统的测试自动化提供了宝贵的经验和指导，强调了动态功能性端到端测试的重要性，并展示了Robot Framework在实现这一目标上的有效性和实用性。"

资源详情

资源推荐

2.2.2. Test types

Test types are a group of test activities which aim to check the system under test in

respect of one or multiple quality characteristics, which were presented in Table 1.

Test type can also aim to test a subset of a quality characteristic. For example, in

performance testing the tester could perform load testing, where the system is put

under heavy load and expected to still perform the tasks that were specified, or stress

testing to check how the system behaves under extreme conditions. [5, p.50] [7,

p.133-134]

The scope of the thesis is to implement a testing tool which specifically

concentrates on testing the functionality of the system under test with a combination

of end-to-end regression testing. There is plenty of literature in testing books

regarding test types. Therefore, only end-to-end testing and regression testing are

introduced in this section.

End-to-end testing

End-to-end testing is used to test the flow of an application by performing complete

processes from the start to finish. The purpose is to ensure that the overall process

flows as expected. This is achieved by checking that the system components

integrate correctly and verifying that the right information is passed between the

components. [3]

Companies’ functional units can grow big, covering complex business processes,

and disperse to a wide are geographically. To efficiently run such a business, the IT

systems needs to support the business processes. Performing end-to-end business

process testing is needed to verify a correct flow of information in complex IT

systems. Organizing and coordinating such a task in multiple different business units

can prove challenging.

Regression testing

Regression testing is retesting of software [10, p.176]. Regression tests are run

because when programmers make changes to the system, they may break parts of the

program that used to work [11]. The goal is to ensure that the new version of the

software still possesses the capabilities of the old version and that no new errors have

been introduced due to the changes [10, p.176].

With the increasingly popular agile software development methods, where

software deliveries are done rapidly in an iterative manner, the role of regression

testing is emphasized [12]. Because regression tests need to be run multiple times, it

is a good idea to automate them [11, p.143]. In many cases, the cost of automating

regression tests return the investment when compared to time consuming manual

testing.

2.3. Automated software testing

Kenneth White [13] defines automated software testing as follows: “Automated

Software Testing is using one program to ‘drive’ another. It does this either by

mimicking a human user through the User Interface (UI) or by interacting directly

with the source code via an Application Programming Interface (API).” Such a driver

program is called automation tool, or test library. Software test automation runs test

cases, performs actions with the system under test, validates the outputs of the

system and logs the results [14]. This is all done without human intervention. Before

a testing tool can do the testing, it needs to be specifically instructed what exactly

needs to be done. This is done manually with test scripts [13]. The implementation

techniques for automated test scripts can be roughly divided into two methods; using

capture-playback tools or manual programming [14].

This section aims to shortly introduce the different approaches for automated

software testing. Manual test script programming opens up more powerful options

than capture-playback tools, and a special introduction is given on data-driven test

automation and keyword-driven test automation approaches. The concept of test

automation framework is also introduced.

2.3.1. Capture-playback tools

Capture-playback tools do basically what the name implies. The user starts to record

a session with the tool, and the tool captures every keystroke, mouse movement and

click that the user performs during the session. Once finished, the tool stores all the

actions performed into a test script. The generated test script can be played back to

automatically test the application later when necessary. [4] [13]

Creating test scripts with capture-playback tools can be fast and requires only

little, if any, technical skills from the tester, but they often result in test script

maintenance issues. To perform a small change into the test script, or if the

application’s user interface changes even slightly, it is often required to fully re-

record the test script from the beginning. Test automation scripts in general always

require maintenance, but with capture-playback tools, the needed maintenance

usually overwhelms the gained benefits in the long run. Test data is also hard coded

into the test script, and provides no means for test data variability. [13] [15, p.50-57]

2.3.2. Manual programming

A more flexible technique for implementing test automation is manual programming

of the test scripts for the automation tool. At a low level, it is comparable to software

development where programming or scripting language is used [16, p.65]. With good

software development practices utilized, the maintainability of the automated tests

increase, reducing the work effort needed after initial implementation.

Maintainability of automated tests is one key factor for achieving a positive return on

investment for repetitive testing tasks when compared to traditional manual testing.

Utilizing manual test script programming and levels of abstraction, a more

sophisticated approach to test automation can be achieved.

2.3.3. Data-driven test automation

Data-driven test automation can be described as taking a step further from basic

manual test script programming. The principle in data-driven testing is to

differentiate the actual test data from the test scripts [13] [15] [17]. This is done by

creating the test script manually, then replacing the used inputs and expected outputs

with variables. The values for the variables are stored in external data files. The test

data is iterated for the test script until the test script has been run for each test data

provided. The test data can contain a large number of different data combinations,

increasing the test coverage in a way that would not be feasible with manual testing.

[15] [17]

Example of data-driven test automation can be seen in Figure 2. Figure illustrates

how, for example, a division operation of a calculator could be tested. The test data

can be provided in a tabular format using a spreadsheet program. The test script

contains a user function which reads the input data and expected output data for the

test execution. After executing the actions and performing validations, test data from

the next row is read and the same sequential test steps are repeated with the new test

data.

Figure 2. Principle of data-driven test automation.

Data-driven testing enables flexible test case creation. Because the test data is

differentiated from the test script and automation tool, creating test cases does not

necessarily need any technical knowledge from the tester if the scripts are already

created. Maintenance work for the automated tests decrease, because if the

functionality changes in the system under test, the maintenance is needed for the test

script and not the numerous test cases using the test script. [15]

While data-driven testing has testing scenarios where it thrives, for example

performing testing on the syntax of data fields, it does have its limitations. If the

testing scenarios provided by the test scripts prove insufficient, it always requires a

technical person with programming skills or automation tool specific scripting skills

to create new test scripts [15]. Additionally, as John Kent points out, most regression

and system tests are not about repetitively inputting data into the user interface, but

rather trying to fully execute business functionality in a realistic way [17]. Data-

driven test automation is not an optimal platform for such a purpose.

剩余73页未读，继续阅读

doudouice

粉丝: 0
资源: 3

SAP电子商务系统动态端到端测试实践：Robot框架应用

谷歌的端到端测试方法：隔离式服务器

SAP肉类行业端到端整体解决方案概述

大数据端到端分析技术在运营商家宽业务中的应用研究.docx

微服务架构下的测试之道 什么是微服务 微服务下如何进行测试 微服务下的单元测试 集成测试 端到端测试 独特的见解

PROFINET端到端性能测试文档

微服务架构下的测试之道 什么是微服务 微服务下如何进行测试 微服务下的单元测试 集成测试 端到端测试

PROFINET端到端性能测试

软件测试方法和技术自动

软件测试先分大类再分小类

pytorch实现端到端分类任务：1000个样本，每个样本序列都有2000个数，标签序列是2000个0-4的数,五分类问题，TCN模型搭建

SpringBoot系统测试方法

如何改进自动化测试质量

列举5个软件测试的发展趋势

python 自动化测试

ui、接口、端到端自动化测试

seafile项目怎么测试

pip install tensorflow 清华_基于tensorflow 实现端到端的OCR：二代身份证号识别

Android测试方法有哪些

判断对错 物联网端到端系统体系中，一般分为终端、网络、平台、应用等四层吗

tensorflow实现端到端分类任务：1000个样本，每个样本序列都有2000个数，标签序列是2000个0-4的数,五分类问题，TCN模型搭建

最新资源

微服务架构下的测试之道什么是微服务微服务下如何进行测试微服务下的单元测试集成测试端到端测试独特的见解

微服务架构下的测试之道什么是微服务微服务下如何进行测试微服务下的单元测试集成测试端到端测试

判断对错物联网端到端系统体系中，一般分为终端、网络、平台、应用等四层吗