7. előadás: web tesztelés

Web Testing Automation Overview

Introduction to Web Testing

• The session begins with a welcome and an introduction to the topic of web testing, transitioning from unit tests to broader web application testing.

• Previous seminars focused on unit tests, emphasizing their importance in local development and how they are written using specific standards and technologies.

• Unit tests are essential as they test the smallest components of applications; however, they do not guarantee that these components will work together in a complete application.

Moving Beyond Unit Tests

• Integration tests are necessary for validating larger parts of an application, although the technology used remains similar to that of unit tests.

• When integrating classes tested separately, the same testing code can be applied to ensure proper interaction between them.

• The discussion highlights that backend testing technology is sufficient for granular testing but must evolve when moving beyond backend concerns.

Challenges in Web Application Testing

• As developers move away from backend testing, they encounter various challenges related to different platforms and devices (e.g., mobile apps).

• Testing requires communication with browsers or dedicated devices; this includes ensuring functionality post-rendering in browsers.

• Different devices (like smartwatches or TVs) require tailored solutions for effective software testing during deployment phases.

Focus on Automated Web Testing

• Today's focus is on automating web testing processes, discussing tools and historical context behind web testing evolution.

• A brief overview of browser functionalities: browsers render HTML/CSS and execute scripts while displaying content based on compatibility with various systems.

Historical Context of Web Testing

• In earlier days, significant discrepancies existed between how different browsers rendered websites; this gap has narrowed but still presents challenges today.

• By the late 1990s, it became clear that software could not be released without some form of user interaction or manual testing alongside automated frameworks.

• Early automation tools were external solutions since integrated automated tooling within browsers was not available at that time.

Peripherals Simulation in Automation

Overview of Peripheral Simulation

• The discussion revolves around the development of scripts and applications that simulate user interactions with a computer, primarily focusing on mouse and keyboard actions.

• These simulations were often implemented using scripting languages like VBScript, allowing users to control the mouse and automate repetitive tasks.

Tools and Applications

• Examples of tools mentioned include AutoHotkey and Internet Explorer's scripting capabilities, which were not originally designed for automation but adapted for such purposes.

• The concept was to create macros that could automate tedious workflows, such as sending emails through web clients requiring numerous clicks.

Automation Challenges

• Users faced challenges when automating processes in applications like banking software, where multiple checkboxes needed interaction; scripts were developed to streamline these tasks.

• Testing involved running automated scripts that would load web pages, execute actions, take screenshots, and compare results to expected outcomes.

Limitations of Early Automation

• A significant limitation was the ad-hoc nature of these setups; any minor change in UI or application design could break existing scripts.

• The fragility of this approach meant that if any pixel-based navigation changed due to UI updates or resolution changes, it rendered tests ineffective.

Sensitivity and Dependency Issues

• The reliance on pixel-perfect navigation made testing extremely sensitive; even small design changes could lead to failures in automated tests.

Web Testing Challenges and Evolution

Operating System Dependencies in Web Testing

• The effectiveness of web testing is highly dependent on the operating system being used, as different systems (Windows, Mac, Linux) require distinct approaches for peripheral interactions like mouse and keyboard inputs.

• Writing code that functions across various platforms is challenging due to differing permissions and operational requirements; thus, a single codebase may not suffice.

• Users often encounter warnings when accessing web applications that are optimized for specific browsers (e.g., Chrome, Firefox), indicating potential compatibility issues with their current browser.

• To ensure functionality across multiple browsers in the 90s, extensive testing was necessary on each platform (Linux, Mac, Windows), complicating the development process significantly.

• The lack of scalability in tests was a major drawback; running multiple tests simultaneously was hindered by hardware limitations and peripheral constraints.

Limitations of Early Web Testing

• Browser memory consumption posed challenges during testing; even high-spec machines struggled to handle multiple tabs effectively due to resource demands from browsers like Edge or Chrome.

• Conducting parallel tests on a single machine was impractical because only one mouse and keyboard could be used at a time, limiting simultaneous interactions with multiple web pages.

• In smaller development companies during the 90s, automation tools were rarely utilized due to budget constraints; manual testing dominated the landscape despite its inefficiencies.

• Manual testing often resulted in numerous bug reports as testers navigated through applications individually without automated support.

Transition to Automated Testing Tools

• By the mid-2000s (around 2000–2008), advancements led to tools that allowed users to record their actions on websites for later playback—significantly easing the testing process.

• These new tools enabled testers to automate repetitive tasks by recording user interactions rather than writing scripts manually—a significant improvement over previous methods.

• The introduction of Selenium marked a pivotal moment in web testing; it allowed users to capture workflows easily and replay them without extensive programming knowledge.

• Selenium's ability to simplify complex test scenarios made it an essential tool within modern infrastructure for automated web application testing.

• Despite its advantages, early versions of Selenium faced limitations in interacting dynamically with browsers—issues arose when waiting for browser responses after actions were performed.

Conclusion: Progression Towards Effective Automation

Web Testing Evolution and Selenium WebDriver

Challenges in Early Web Testing

• The initial web testing process involved clicking links and waiting for a response, typically expecting results within five seconds. If the test failed to complete in that time, it was considered unsuccessful without options for further attempts.

• A significant drawback was the difficulty in maintaining the generated code snippets that indicated where to click on the webpage, complicating automated testing efforts.

• This period coincided with the rise of dynamic web applications, which complicated testing as data was no longer static but fetched from servers or databases.

Impact of Dynamic Web Applications

• Dynamic web applications relied heavily on JavaScript for content generation, making traditional testing methods less effective due to constantly changing data.

• Test cases shifted from simple link navigation checks (e.g., verifying 404 errors) to more complex scenarios involving dynamic content filtering based on user interactions.

• As web applications became more dynamic, automated testing needed to evolve significantly to handle these new situations effectively.

Introduction of Selenium WebDriver

• In 2009, Selenium WebDriver was introduced as a solution to enhance web application testing capabilities by allowing interaction with browsers similarly to how users would engage with them.

• The introduction of the JSON Wire Protocol aimed at standardizing communication between tests and browsers, facilitating better integration across different platforms and operating systems.

Architecture of Selenium Testing Infrastructure

• The architecture included unit tests that interacted with browsers through a mini-web server designed to send HTTP requests and receive responses from the browser.

• To achieve platform independence, a custom server layer was created so that Selenium scripts could communicate seamlessly regardless of operating system or browser type.

Standardization and Flexibility

• When sending requests (e.g., navigating to a webpage), these were processed through a standardized protocol using JSON format for communication between scripts and browsers.

• Browser developers provided automation APIs enabling external manipulation; while not standardized initially, they allowed Selenium's framework to interact effectively with various browsers by utilizing specific drivers (e.g., ChromeDriver).

Understanding the Jason Wire Protocol

Overview of Script Development

• The speaker discusses their ability to write scripts in various programming languages, including Java, C#, and C++, for testing purposes.

• They explain the process of initiating an automated testing session by sending a POST request to obtain a session ID.

Session Management and Navigation

• The speaker describes how they send requests within a session to navigate to different pages on a website.

• A specific request is made to interact with an element on the page, detailing how JSON bodies are used to describe actions.

Element Interaction via WebDriver

• Upon navigating to a webpage, the WebDriver retrieves the HTML content, allowing for element searches using XPath (XP).

• The WebDriver processes the HTML DOM and identifies elements like buttons or text boxes, returning objects that represent these elements.

Object Handling and Event Execution

• When requesting an element (e.g., submit button), it returns an object type that includes methods for interaction.

• Executing a click event involves sending HTTP requests through the wire protocol, which may inject JavaScript into the webpage for action execution.

Evolution of Selenium Infrastructure

• The discussion transitions into how this protocol has streamlined operations over time while remaining open-source.

• Selenium's infrastructure included three main components; however, some have become deprecated over time.

Selenium IDE: Features and Functionality

Recording and Playback Capabilities

• Selenium IDE was introduced as a browser extension supporting record-and-replay functionality for test automation.

Test Creation Assistance

• It facilitated effective test creation by gathering necessary data even if users started with simple recording tasks.

User Interface Testing Organization

• Users could organize recorded processes into test suites designed specifically for UI testing scenarios.

Result Tracking and Debugging Features

• The interface provided visual feedback on test success or failure using color-coded indicators (green/red).

Live Interaction with Websites

Selenium Framework Overview

Introduction to Selenium and Project Setup

• The speaker discusses the initial setup of a project using Selenium, highlighting the process of clicking on links to automate downloads.

• Emphasizes that this automation allows users to create basic tests manually, which can then be utilized for further development.

• Mentions collaboration features that enable team-based work within the framework.

WebDriver Functionality

• The speaker explains the primary function of WebDrivers in Selenium, which is to facilitate communication between code and web browsers.

• Highlights that this interaction is crucial for executing automated tests effectively.

Introduction of Selenium Grid

• Introduces Selenium Grid as a significant component of the infrastructure, allowing parallel test execution across different operating systems and browser versions.

• Discusses how Selenium Grid addresses challenges in web testing by enabling tests to run simultaneously on multiple machines with various configurations.

Evolution and Standardization (2018)

• Notes a pivotal moment in 2018 when WebDriver was standardized due to its widespread adoption in the industry.

• Describes how standardization improved browser support and integration capabilities within WebDriver.

Enhancements in V3C WebDriver

• The V3C WebDriver introduced better stability and API clarity compared to previous versions.

• Explains that while it still operates primarily as a one-way communication tool from client to browser, it marked significant progress in functionality.

Future Developments: WebDriver BID (2025)

• Anticipates future enhancements with the introduction of WebDriver BID, which aims for two-way communication between clients and browsers.

Webdriver Development and Browser Automation

Overview of Webdriver Development

• The discussion begins with a reference to the development line of the webdriver, indicating that there are additional considerations beyond its basic functionality.

• Each browser has its own developer inspect view, which allows developers to interact with their respective APIs. However, these developer tools are not integrated into the testing process for Selenium-based tests.

Testing Methodologies

• Selenium operates on open standards and is designed for cross-platform and cross-browser compatibility, albeit with some overhead due to web server interactions.

• An alternative approach emerged around 2017 focused on automation rather than just testing, particularly in web scraping scenarios.

Headless Browsers

• The introduction of headless browser technology addresses scalability issues associated with traditional browsers that require significant memory and graphical interfaces.

• Headless browsers function without a graphical user interface (GUI), making them efficient in terms of memory usage while allowing automated processes to run in containerized environments.

Advantages of Headless Browsers

• Two key benefits of using headless browsers include reduced memory consumption and the ability to operate within containerized setups without requiring a UI.

• Technologies like Chrome, Firefox, and Safari can be initiated within Docker containers for automated tasks without needing a visible browser interface.

Comparison Between Selenium and Alternative Technologies

• There are technologies developed alongside Selenium that allow direct communication with browsers. These include Playwright and Puppeteer, which utilize protocols specific to each browser.

• While these alternatives do not replace Selenium, they offer parallel solutions for interacting directly with headless browsers through established protocols like Chrome DevTools.

Protocol Standards

• Both Selenium's standard WebDriver protocol and custom protocols from other technologies aim for similar functionalities but differ in speed due to architectural differences involving web servers.

• The discussion highlights how different browsers may have unique requirements; for instance, Chrome's protocol may not work seamlessly with Safari or Firefox.

Future Implications

• As these technologies evolve towards running graphical tests without human intervention or visible frontends, it opens up new possibilities for automated testing frameworks.

Webdriver and Browser Support

Client-Server Architecture

• The architecture discussed is a client-driver-server model, where the WebDriver communicates with a web server.

• Supported browsers include Chromium, Firefox, and WebKit; however, the WebDriver supports all modern browsers due to its open standard nature.

Headless Mode Functionality

• Headless mode allows running tests in environments like containers or for scraping purposes. Playwright fully supports this feature.

• During test writing, non-headless mode is often used initially to visually confirm that tests run correctly before switching to headless mode for efficiency.

Session Management and Navigation

• The architecture includes session management where a session ID is obtained after sending a request to the session endpoint.

• Browsers have built-in support for WebDriver properties, allowing seamless interaction when writing tests that communicate with the browser.

Mobile Testing Limitations

Challenges with Mobile Support

• The WebDriver does not function on mobile devices as effectively as on desktops due to architectural constraints.

• For mobile application testing, an alternative framework called Appium is suggested for handling mobile-specific requirements.

Webdriver Workflow Overview

Requesting Sessions and Navigating URLs

• To initiate interactions with the browser, a session must be created first by requesting the session endpoint which returns a session ID.

• Navigation commands allow moving forward or backward in browsing history or directly accessing specific URLs using the obtained session ID.

Element Interaction Capabilities

• Interactions with elements can be performed once identified through element endpoints; actions include clicking buttons or retrieving text from elements.

• The protocol operates similarly to RESTful APIs, facilitating communication between scripts and browsers through defined requests.

Advanced Features of Webdriver

Handling Multiple Tabs and Cookies

Understanding Browser Interactions and Testing Tools

Information Retrieval from Browsers

• The discussion begins with the ability to retrieve information from within a browser, focusing on logs and network requests that can be extracted.

• It highlights how JavaScript can manipulate the Document Object Model (DOM), allowing for notifications when changes occur without user interaction.

• Notifications can be set up for DOM changes, such as displaying hidden text after a delay, enhancing interactivity in web applications.

Performance and Debugging Insights

• There is curiosity about future developments in coverage reports from tests, indicating a desire for improved testing frameworks that provide detailed insights.

• Current unit tests are being developed to generate coverage reports similar to those seen in seminars, specifically targeting JavaScript code execution.

Introduction to Testing Frameworks

• The speaker transitions to discussing various web pages and tools available for testing, particularly focusing on Chrome extensions.

• A comparison is made between Selenium and Katalon Recorder; while Selenium is no longer actively developed, Katalon offers robust features for automated testing.

Katalon Testing Framework Overview

• Katalon is introduced as a comprehensive test framework with pricing details; it offers both free and premium versions with significant costs associated with advanced features.

• The advantages of Katalon include its capability to perform mobile and API testing alongside web automation, although there may be better alternatives available.

Practical Demonstration of Test Creation

• The speaker demonstrates using the recorder extension in Chrome to create test cases dynamically by linking multiple tests together based on shared data inputs.

Overview of the Testing Process

Introduction to the Test Setup

• The speaker introduces a second half of a testing schedule, indicating that they will search for "lumándor" and view the timetable.

• They explain navigating to the UBB+ page, emphasizing the command and target structure necessary for web driver requests.

Web Driver Interaction

• The speaker discusses submitting an action on a search form without needing to click, as the system can handle it automatically.

• They highlight selecting specific links from a table based on text recognition, which is crucial for automated testing.

Document Inspection and Element Selection

• An XP expression is mentioned, focusing on finding normalized text within documents. This aids in identifying elements dynamically during tests.

• The process of extracting relevant content from tables is described, showcasing how elements are located through font tags in HTML.

Running Tests and Observations

• The speaker prepares to run a test case while discussing potential issues with browser automation.

• Upon executing the test, they observe successful interactions with web elements without manual input.

Enhancements and Future Steps

• Suggestions are made for refining tests by removing unnecessary clicks or actions that do not contribute to functionality.

• A more efficient version of generating tests is proposed, demonstrating improved interaction with web pages without direct clicks.

Logging and Execution Monitoring

• The importance of logging actions during tests is emphasized; this allows tracking progress and timing throughout execution.

• Discussion includes monitoring current positions within forms during execution to ensure accuracy in automated processes.

Exporting Test Cases

• The speaker mentions exporting recorded steps into various frameworks, highlighting flexibility in adapting tests across different environments.

Web Automation Overview

Introduction to Web Automation

• The session begins with a discussion on creating a class for web automation, specifically using a Firefox driver to navigate to Google and check for issues.

• The process involves directing the driver to an URL, locating an element by its ID (specifically "S"), clicking it, clearing its text, and inputting new data ("orar") before submitting.

Streamlining the Process

• The speaker emphasizes that once the element is found, it can be stored as an object. This allows for operations like clicking and sending keys in a more organized manner.

• The current setup enables testing of web applications using the same structure previously used for simple code tests. It highlights the importance of wire protocols and web drivers in executing these tests.

Comparison with Other Frameworks

• An alternative approach discussed is exporting tests to Robot Framework or Papetir. Papetir offers advantages over traditional web drivers due to its asynchronous communication capabilities.

• Unlike web drivers that require explicit waiting for events (like page loading), Papetir's design allows for faster integration into browsers through asynchronous behavior.

Efficiency Considerations

• The speaker notes that while both frameworks function similarly, their execution differs; synchronous execution in web drivers may lead to inefficiencies when running multiple tests.

• A brief mention of different programming languages supported by various frameworks (Java, Python, Node.js), indicating broad applicability across platforms.

Conclusion and Next Steps