Manual - Test Plan Design for Release 4.4.0 #4451
Assignees
Comments
Mayons95
changed the title
Mayons95
changed the title
|
Updating Issue, adding #4508. |
|
Updating Issue, adding #4501 |
|
Updating Issue, adding #4503 |
|
We closed this issue because 4.4.0 RC1 is out, we are going to use this issue to perform the regression testing. |
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Introduction
In this issue, we will track all the efforts being made to test Wazuh release 4.4 on all the supported platforms. The test plan described here comprehends regression tests, so will only cover the specific changes made in this release. The complete tests suite will be run as part of our automated testing process.
Platforms:
Plan
#4428 Render nested field rows in the security alerts table
The goal of this PR is to filter correctly by searching by nested fields on the Security Events table, please look for the evidence attached on the linked PR.
Test - 1
Given the wazuh admin user is logged
When the user navigates to the Security Events Module
And there are Nested fields available
And the user add a filter by a nested field (eg: data.aws.requestParameters.rules)
Then the displayed data on the module should be filtered by the nested field previously selected.
Useful screenshots:
#4425 Fixed dashboard nested fields filtering
Test - 1
The goal of this PR is to filter correctly by searching by nested fields on the Security Events table, please look for the evidence attached on the linked PR.
Given the wazuh admin user is logged
When the user navigates to the Security Events Module
And there are Nested fields available
And the user add a filter by a nested field (eg: data.aws.requestParameters.rules)
Then the displayed data on the module should be filtered by the nested field previously selected.
Comments
How can I add mocked nested field to test this issue?
You should add mocked logs in:
var/ossec/logs/logs/alerts/alerts.json
var/ossec/logs/logs/alerts/alerts.log
Useful screenshots:
Test - 2
Given the wazuh admin user is logged
When the user navigates to the Security Events Module
And there are Nested fields available
And the user search a nested field using the search bar
And the user confirm the search
Then the displayed data on the module should be filtered by the nested field previously selected.
Useful screenshots:
#4376 Improve alerts summary performance
This PR changes the way the Alerts Summary tables are created in PDF reports to improve the dashboards loading time. Now the tables configuration is the PDF report folder segregated by modules and the request to obtain the data is made by the backend of the app instead of the frontend.
This avoids unnecessary loading times when the user does not use the reporting feature.
**Test -1 **
Given the wazuh admin user is logged
When the user navigates to the Security Events Module
Then the user generated a PDF report
And the PDF report is generated correctly.
Comments
As developers / QA the goal is to check if the request that performs the creation of the PDF report is executed when the user presses the "Generate Report" option and not when the user navigates to the module.
Useful video:
Screencast from 07-09-22 09:25:09.webm
#4363 Agents section performance
The goal of this test is to check that the loading of the different charts displayed on the agent page are loading independently from each other
**Test **
Given the wazuh admin user is logged
When the user navigates to the Agent page
Then the user verifies that the loading of the different charts are independent of each other
Comments
To check this easier you can use the google chrome developers tool, the network throttling tool, and select the slow 3G connection option.
Uselful videos:
Network setting:
Screencast from 07-09-22 14:10:29.webm
Test evidence:
https://user-images.githubusercontent.com/104914131/188913526-e9802383-4489-4ea2-96fa-be58a554b754.webm
#4174 Refactor ruleset management
Summary
All calls to action and navigation elements should be tested in Rules, Decoders, CDB Lists modules. When in doubt, compare the behavior of the feature with any 4.3.x Wazuh version
Tests -1
All table features
Pagination
Sorting
Row clicking
Links within the table rows
Search input
Custom action buttons (Manage rule files, Add new rule file, Refresh, Export formatted, etc.)
Manage rule / decoder files button should clear previous filters before switching the table
Custom rules / decoders filter button
Clicking a row in the rules or decoders tables should open a flyout with the details of the selected item.
In the details flyout information accordion, there are "links" that should close the flyout and filter the property in the background table.
Clicking a row in the table within the details flyout should replace the information in the flyout with the selected item.
Clicking the rule / decoder filename in the tables should load the file content view.
Clicking a rule.id in the Events table should load the rules view with an open flyout showing the selected rule information
image
Useful videos: Please check the related PR
#3905 Added agents windows events
Test -1
Preconditions: Have a Windows agent installed
Given the wazuh admin user is logged
When the user navigates to Agent/configuration/WindowsEvents
And the user navigates to the options displayed at the right
Then the user see the lof format window.
Uselful screenshot:
#4508 Changed terms of Office Max Rule Level - Office 365
The goal of this PR is to display correctly the Max Rule Level
Test - 1
Scenario: Open the main Office 365 dashboard
Given the wazuh admin user is logged
When the user navigates to Office 365 module
And the maximum alert level is defined
Then the Max Rule Level should show the correct value and match with the value shown in the Events by severity over time graphic
Comments
Useful screenshots:
#4516 Modify agent overview page
The goal of this PR is to check the resize of a particular agent page
Scenario: Open the summary page for an agent
Given a screen width higher than 1360px
Then the elements should be shown without overlapping or issues
Scenario: Open the summary page for an agent
Given a screen width lower than 1360px and higher than 768px
Then the elements should be shown without overlapping or issues
Scenario: Open the summary page for an agent
Given a screen width lower than 768px
Then the elements should be shown without overlapping or issues
Comments
Useful screenshots:
Screencast.from.21-09-22.15.26.21.webm
#4501 Centralize the plugin settings
The goal of this PR is to check the differents settings that can be updated.
Scenario: No existing configuration/The configuration file is generated with the expected settings.
Given The Wazuh admin user is logged
When the plugin platform starts
And there is no plugin configuration file in the expected path
Then the elements should be shown without overlapping or issues
Scenario: The configuration through Settings/Configuration section works
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user changes the value of any setting
And the user saves the changes
Then changes it's visible on the settings file.
Scenario: The user saves the configuration through Settings/Configuration
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user changes the value of any setting
And the user saves the changes
And the user refreshes the page
Then the user sees the changes applied previously.
Scenario: The action toast when saving the configuration can only show one each time - Toast displayed.
Given: The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And The user changes 2 or more settings that require the same type of action after updating.
And the user clicks on the save button
Then: It should only appear one toast confirming save successfully.
Scenario: Filter settings by category in Settings/Configuration
Given: The Wazuh admin user is logged
When the user navigates to Settings/Cofiguration
And the user selects one or more categories from select input on top of the page.
Then the settings of the selected category/ies should be displayed.
Scenario: User search a setting in Settings/Configuration
Given: The Wazuh admin user is logged
When the user navigates to Settings/Cofiguration
And the user introduces a query in the search bar.
Then the setting/s that match the query are displayed.
Scenario: Update one setting from Settings/Configuration
Given: The Wazuh admin user is logged
When the user changes a setting value
And the user clicks on the Save button
Then the setting should be updated in the configuration file and the frontend
Scenario: Update 2 or more settings from Settings/Configuration
Given: The Wazuh admin user is logged
When the user changes 2 or more setting values
And the user clicks on the Save button
Then the settings should be updated in the configuration file and the frontend
Scenario: Update one setting through API request PUT /utils/configuration (using some request tool: cURL, postman, etc...)
Given the user has access to Wazuh API
When the user does a request to update a setting
Then the setting should be updated in the configuration file
Scenario: Update 2 or more settings through API request PUT /utils/configuration
Given the user has access to Wazuh API
When the user does a request to update 2 or more settings
Then the settings should be updated in the configuration file.
Scenario: Plugin setting category description appears in the configuration file
Given an environment without a plugin configuration file
When the user starts the plugin platform
Then the default configuration file is generated
And each plugin category has the description on the configuration file
Scenario: Plugin setting category description appears in the Settings/Configuration
Given: The Wazuh admin user is logged
When the user navigates to Settings/Configuration page
Then each plugin category has the description
Comments**
Useful screenshots:
#4504 Upload file for customization.logo.*
Scenario: Select a file with the suggested extension for each customization.logo.* setting in Settings/Configuration - Drag & Drop
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user drag-and-drops a file in the file picker of Settings/Configuration
Then the file picker should suggest files with the supported extensions
Scenario: Select a file with the suggested extension for each customization.logo.* setting in Settings/Configuration - File Selection
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user selects a file in the file picker of Settings/Configuration
Then the file picker should suggest files with the supported extensions
Scenario: Upload the configuration for a customization.logo.* setting in Settings/Configuration
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user selects a valid file
And the user clicks on the Save button
And the user refreshes the page
Then the file should be saved in the expected path of the filesystem: WAZUH_PLUGIN_PATH/public/assets/custom/images whose filename is the setting key and the extension is the same as the uploaded file. (jpeg files will be saved as jpg)
And the image should be displayed on the UI depending on the setting customized
And the configuration file should be modified to include the setting and its value is a relative URL that should be exposed.
Scenario: Select a file that exceeds the size limit and displays a validation error in Settings/Configuration
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And selects a file that exceeds the size limit above 1MB.
Then a validation error should be displayed
Precondition: The setting is customized - There is an existing customization logo
Scenario: Delete the customization of each customization.logo.* setting in Settings/Configuration
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user clicks on the button to remove the file
And the user refreshes the page
Then the file should be removed from the file system: WAZUH_PLUGIN_PATH/public/assets/custom/images
And the UI should display the default image.
And the configuration file for the setting should be cleaned. This means that its value is an empty string ""
Scenario: Update the plugin configuration from Settings/Configuration by modifying multiple settings at the same time
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And modifies some setting that is not a customization.logo.*
And one of customization.logo.* setting
And the user clicks on the button to save
And the user refreshes the page
Then the file should be saved in the expected path of the filesystem: WAZUH_PLUGIN_PATH/public/assets/custom/images whose filename is the setting key and the extension is the same as the uploaded file. (jpeg files will be saved as jpg)
And the image should be displayed depending on the setting customized.
And the configuration file should be modified to include the setting and its value is a relative URL that should be exposed
And all the modified settings should be saved in the configuration file
Scenario: Update the plugin configuration from Settings/Configuration modifying multiple settings at the same time with 2 or more customization.logo.* settings
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user modifies some setting that is not a customization.logo.*
And the user modifies 2 or more of customization.logo.* settings
And the user clicks on the button to save
And the user refreshes the page
Then the files should be saved in the expected path of the filesystem: WAZUH_PLUGIN_PATH/public/assets/custom/images whose filename is the setting key
And the extension is the same as the uploaded file. (jpeg files will be saved as jpg)
And the images should be displayed depending on the setting customized.
And the configuration should be modified to include the settings and its value is a relative URL that should be exposed.
And all the modified settings should be saved in the configuration file
Scenario: Select a valid file for each customization.logo.* setting in Settings/Configuration with different aspect ratio - drag and drop a file
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user drag-and-drops a file
Then the file picker should suggest the supported file extensions
And renders properly the uploaded custom logo, without visual glitches or styling issues
Scenario: Select a valid file for each customization.logo.* setting in Settings/Configuration with different aspect ratio - file selction
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user selects a particular file
Then the file picker should suggest the supported file extensions
And renders properly the uploaded custom logo, without visual glitches or styling issues
#4505 Add header and footer report customization
Scenario: The customization.reports.* settings should appear in the default configuration file
Given The Wazuh admin user is logged
And there is no a plugin configuration file
When the user starts the plugin platform
Then the configuration file should be generated and includes the customization.reports.* settings
Scenario: The customization.reports.* settings should appear in the Settings/Configuration section
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
Then the customization.reports.* settings should be displayed
Scenario: Set the customization.reports.header with a valid value through Settings/Configuration.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user sets the customization.reports.header with a valid value (Maximum 4 lines)
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.footer with a valid value through Settings/Configuration.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And sets the customization.reports.header with a valid value. Maximum 2 lines.
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.header with a valid value through Settings/Configuration that includes multiple lines.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And sets the customization.reports.header with a valid value. Maximum 4 lines.
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
And the configuration file is valid and parseable.
Scenario: Set the customization.reports.footer with a valid value through Settings/Configuration that includes multiple lines.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And sets the customization.reports.header with a valid value. Maximum 2 lines.
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
And the configuration file is valid and parseable.
Scenario: Set the customization.reports.header with a invalid value through Settings/Configuration.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user sets the customization.reports.header with an invalid value. Maximum 4 lines.
Then a validation error is displayed.
Scenario: Set the customization.reports.footer with a invalid value through Settings/Configuration.
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user sets the customization.reports.header with an invalid value. Maximum 2 lines.
Then a validation error is displayed.
Scenario: Set the customization.reports.header with a valid value through an API request.
Given the user has access to Wazuh API
When the user does an API request to update the customization.reports.header setting with a valid value. Maximum 4 lines.
Then the endpoint replies with a successful response.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.footer with a valid value through an API request.
Given the user has access to Wazuh API
When the user does an API request to update the customization.reports.footer setting with a valid value. Maximum 2 lines.
Then the endpoint replies with a successful response.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.header with an invalid value through an API request.
Given the user has access to Wazuh API
When the user does an API request to update the customization.reports.header setting with an invalid value. Maximum 4 lines.
Then the endpoint replies with a bad request response.
Scenario: Set the customization.reports.footer with an invalid value through an API request.
Given the user has access to Wazuh API
When the user does an API request to update the customization.reports.header setting with an invalid value. Maximum 2 lines.
Then the endpoint replies with a bad request response.
Precondition: The customization.reports.header setting has a custom value.
Scenario: Generate a PDF with a custom report header.
Given the user has access to Wazuh API
When generates a PDF module report.
Then the custom text should appear in the header.
Precondition: The customization.reports.footer setting has a custom value.
Scenario: Generate a PDF with a custom report footer.
Given the user has access to Wazuh API
When generates a PDF module report.
Then the custom text should appear in the footer.
Precondition: The customization.reports.header setting has an empty custom value ""
Scenario: Generate a PDF with an empty custom report header.
Given the user has access to Wazuh API
When generates a PDF module report.
Then the default text should appear in the header.
Precondition: The customization.reports.footer setting has an empty custom value ""
Scenario: Generate a PDF with a custom report footer.
Given the user has access to Wazuh API
When generates a PDF module report.
Then the default text should appear in the footer.
In the associated PR there are some scripts to perform automatic settings.
#4503 Add validation to the plugin settings
Scenario: Set an invalid value for the setting in Settings/Configuration form
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user changes the input value to something invalid.
Then an error should appear below the input form.
And the setting should be red colored and highlighted as invalid.
And the bottom bar should display the count settings with invalid values.
And the save button should be disabled.
Scenario: Set 2 or more invalid values for the settings in Settings/Configuration form
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user changes the input value of 2 or more settings to invalid values. This depends on each setting validation.
Then an error should appear below the input form for each setting.
And the settings should be red colored and highlighted as invalid.
And the bottom bar should display the count settings with invalid values.
And the save button should be disabled.
Scenario: Set a valid value for the setting in Settings/Configuration form
Given The Wazuh admin user is logged
When the user navigates to Settings/Configuration
And the user changes the input value to a valid value. This depends on each setting validation.
Then it should not appear as a validation error below the input.
Scenario: Send invalid values to update the plugin configuration through the plugin API endpoint
Given the user has access to Wazuh API
When the user sent a request to PUT /utils/configuration with one or more settings, where at least one of them has an invalid value.
Then it should reply with a bad request displaying the validation error.
#4507 Add switch to toggle the use of custom branding
Scenario: Modify the value of customization.enabled setting through Settings/Configuration
Given The Wazuh admin user is logged
When the user modifies the custmization.enabled setting
And the user saves the configuration.
Then the configuration file should be updated and correctly displayed
Scenario: Modify the value of customization.enabled setting through an API request with a valid value.
Given the user has access to Wazuh API
When the user does an API request to update the setting customization.enabled with a valid value: true or false
Then the response should be successful
And the configuration file should be updated
Scenario: Modify the value of customization.enabled setting through an API request with an invalid value.
Given the user has access to Wazuh API
When the user does an API request to update the setting customization.enabled with an invalid value.
Then the response should be a bad request
Precondition: the customization.enabled setting value is true and the customization.* settings have custom values
Scenario: Customization is applied when the customization.enabled setting is enabled.
Given The Wazuh admin user is logged
When the user access to Wazuh App
Then the menu displays the custom image
And the plugin category displays the custom image
And the plugin health check displays the custom image
And the PDF report image displays the custom image
And the PDF header displays the custom text
And the PDF footer displays the custom text
Scenario: Customization is not applied when the customization.enabled setting is disabled.
Given the customization.enabled setting value is false and the customization.* settings have custom values
When the user goes to the plugin,
Then the menu displays the default image
And the plugin category displays the default image
And the plugin health check displays the default image
And the PDF report image displays the default image
And the PDF header displays the default text
And the PDF footer displays the default text
#4638 Wrong behavior from the Flyout component in Wazuh Dashboard
Scenario: Click on rule flyout
Given The Wazuh admin user is logged
When the user navigates to Management/Rules
And the user clicks on a rule
And the user clicks on the flyout
Then the flyout doest not disappear
Scenario: Click out rule flyout
Given The Wazuh admin user is logged
When the user navigates to Management/Rules
And the user clicks on a rule
And the user clicks outside the flyout
Then the flyout stops being displayed
#4204 Wrong behavior from the Flyout component in Wazuh Dashboard
Steps to test:
*Go to the Agents tab
*Click on the 'Deploy new agent' button
*Verify that they appear to select all these OS:
Red Hat Enterprise Linux
CentOS
Debian
Ubuntu
Windows
macOS
OpenSuse
Solaris
AIX
HP-UX
Amazon Linux
Fedora
Oracle Linux
SUSE
Raspbian OS
Steps to test:
*Go to the Agents tab
*Click on the 'Deploy new agent' button
*Check that the information shown matches this one:
For C7 we support ARMV7HL(ARMHF), AARCH64, I386, X86_64 and PPC64LE and the command is the same on all of them (The system and package manager is the same).
For D9+ we support the same architectures as C7 and the command is the same (The system and package manager is the same).
For OpenSuse we support the same architectures as the RPM package needs and builds and provides.
AL2,Fedora,OL, RHEL, SUSE.... all use RPM and use the same commands as C7.
For Raspbian OS we support the same as a Debian 9/10 fork.
Amazon Linux 1 is a fork (derivative) of CentOS 6.
Amazon Linux 2 is a fork of CentOS 7
Amazon Linux 2022 is something like RHEL 9
RedHat and Oracle linux are pretty much the same as CentOS
RedHat 6 is like CentOS 6
Oracle Linux 6 is the same as CentOS 6
Tasks
(all browsers are in their latest versions, with no plugins)
The text was updated successfully, but these errors were encountered: