Headless Browser Testing via Dashboard Mediator
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing headless browser technologies face limitations in securely handling sensitive data and dynamically requested inputs, such as CAPTCHA data and file uploads, which hinders their ability to test web applications effectively.
Innovation Solution
A method and system that utilize a dashboard server and runner servers to execute web application tests with headless browsers, where input requests including hints and session identifiers are sent to facilitate user input through a chat interface, allowing secure and complex data entry without direct API calls, enabling the execution of tests that require sensitive data and dynamic inputs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If headless browsers are used for web application testing, then automation capability and remote accessibility are improved, but the ability to securely handle sensitive data and dynamically requested inputs deteriorates
Solution Approach 1:
A dashboard server is introduced as an intermediary component between the headless browser and the web application. The dashboard server receives user input through a graphical interface, processes it securely, and transmits it to the headless browser via a secure channel. This mediator enables the headless browser to handle sensitive data without direct API exposure, resolving the security contradiction while maintaining automation capability.
2Ease of operation
If headless browsers are used for web application testing, then remote deployment and team collaboration are improved, but the ability to provide user input for sensitive data and dynamic content deteriorates
Solution Approach 1:
The dashboard server provides a universal interface that handles multiple types of user inputs (text, files, CAPTCHAs, etc.) through a single graphical interface. It can process various input types and transmit them to the headless browser as needed, making the system adaptable to different testing scenarios while maintaining remote accessibility.
3Device complexity
If direct API calls are used to pass data to headless browsers, then data transmission is simplified, but security risks and inability to handle sensitive data deteriorates
Solution Approach 1:
The dashboard server acts as a secure intermediary that receives data through a graphical interface and transmits it to the headless browser via an encrypted channel. This eliminates the need for direct API calls while maintaining simplicity in data transmission and significantly improving security by preventing direct exposure of the browser's API endpoints.
4Productivity
If headless browsers are used without graphical interface, then automation and efficiency are improved, but the ability to interact with CAPTCHA and file upload functionality deteriorates
Solution Approach 1:
The dashboard server serves as an intermediary that handles complex input tasks such as CAPTCHA solving and file uploads through its graphical interface. It processes these complex interactions and transmits the results to the headless browser, enabling the automated testing process to complete complex input tasks that would otherwise be impossible for headless browsers to handle directly.
Data Source
AI summary
Methods, non-transitory computer readable media, and runner servers are disclosed that execute a web application test with a headless browser activated in response to a request to schedule the test received from a dashboard server. The test includes test actions. An input request that includes a hint and a session identifier is sent to the dashboard server in response to a user input trigger associated with one of the test actions during the execution of the test. The associated one of the test actions is then executed with the headless browser using input data received from the dashboard server in response to the input request. During the execution of the web application test, web page(s) associated with the web application and analysis results are recorded. The recorded web page(s) and analysis results are then output to the dashboard server when the web application test is complete.