mabl's coverage feature allows you to browse your app's page coverage to more easily identify gaps and quickly find which test run on each page. On this page, you'll find a list of all the pages that mabl has explored in your app via the default link crawler in the last two weeks, filtered automatically by application. You can specify if you only want to view data as new as one day or as old as the last four weeks.
For each page in coverage table, you'll be able to view the most recent screenshot from the link crawler as well as the specific URL host and URL path in the first three columns, respectively. You're also able to filter by the specific host and path, in addition to selecting the age range of data you'd like to view. You'll need to run your link crawler regularly to take advantage of this feature. If the link crawler is not run regularly, the calculations may not accurately reflect the coverage of your application.
Frequency of coverage page updates
All measures are updated at least once a day
The above metrics only present the executed page coverage from the past two weeks (by default). Unique steps or tests that are recorded on a specific page but are never executed, due to an upstream test failure or conditional logic, are not included in these totals.
In addition to the above, mabl provides multiple measures to understand your level of existing coverage for a page:
The metric captures the number of unique tests that have visited that particular page in the timeframe defined above, regardless of whether or not they interact with elements on the page. If the number is 0, this means that no tests visit this page other than the link crawler. Click anywhere in the row to view the specific test that run on this page, or easily add your own if none exist.
Note: if a test is part of two plans and runs against that page twice, only the first unique run will be reflected here.
This metric captures the number of distinct interaction steps from tests that visit this and are executed on the page in the selected time frame. Steps are distinguished by the element they interact with and what action they perform.
Note: because assertions, wait steps, echo steps, etc. do not interact with the elements on the page, they are not included in this total.
This metric captures the number of distinct assertion steps from tests that visit this and are executed on this page in the selected time frame.
This metric measures the overall complexity of the DOM itself as measured by mabl when crawling the page or during a regular test run. The higher the number, the more interactive elements the page contains such as buttons, links, and fields.
The metric captures the number of pages that link directly to this path as detected by the mabl link crawler. The deeper a specific page is within your app, the lower this value will likely be. If you have not run your link crawler recently, this section may appear empty.
This metric captures the number of clicks necessary to access the specific path (starting at 0) as recorded by the link crawler. For example, your app homepage will have a depth of 0 while your login page will likely have a depth of 1. If you have not run your link crawler recently, this section may appear empty.
This metric captures the averaged daily number of unique users that visit the specific page using data captured from Segment data in your own application.
By integrating with Segment, mabl uses your real user data, via the
Track methods, to securely build a model of the pages in your app and determine the number of unique users interacting with each page. mabl does not process personally identifiable information (PII) as part of our Segment integration.
Page coverage is reported in terms of common pages of your application. We use a technique called "URL-clustering" to group dynamic URLs of pages, giving you more accurate and readable coverage data on how mabl is testing your apps.
Many web applications have dynamic URLs that include random IDs and other large groups of distinct URLs that describe very similar pages. This means that one web application could have thousands of distinct URLs, yet there might only be very small differences in content displayed for each URL. mabl analyzes the distinct URLs within a given workspace and combines URLs that appear to be variations of the same type of page.
Take a look at the following example mabl URLs. Every mabl user will have seen a URL of this form since one exists for every workspace.
app.mabl.com/workspaces/83hd632h9a-w/insights app.mabl.com/workspaces/uvg9eh2n56-w/insights dev.mabl.com/workspaces/qn243lf97h-w/insights qa.mabl.com/workspaces/bv82bfnv75-w/insights preview-env-445.mabl.com/workspaces/cd64lhaj32-w/insights
The URLs in this group all display different insights, but they share the same page template. mabl will cluster URLs like the ones above into one group to represent one page of an application. A cluster will be in the following form, even across different domains with the same path:
The distinct URL variations that are grouped together will be represented with a wildcard [ * ] in the locations where the variations occurred. Here is another more generic example:
/store/women/pants/pants-variation-1 /store/women/pants/pants-variation-2 ... /store/women/pants/pants-variation-2048
The above URLs would be combined into the following cluster:
URLs that are very unique will be contained in their own clusters. For example, with the mabl application, the login page will be its own cluster since there is only one and the page is the same for all users.
Coverage metrics and charts have a clearer display of how well your test suite tests your application, especially for customers with the segment integration and many dynamic urls. mabl gets the total pages count and the covered pages count from the number of common pages instead of the distinct URLs. This will be reflected in the charts on the Coverage page, in the table on the Coverage page, and the Page Coverage item on the Dashboard.
With fewer total pages, you can now more easily scroll through the table on the Coverage page to identify pages within your application that need more journeys.
How often are the URL clusters calculated?
The URL clusters are updated at the same frequency as the Coverage page metrics
By default, the results on the coverage page will be sorted by complexity in descending order. Once you've integrated with Segment, click the "Daily Users" twice to sort your coverage by the average number of daily users in descending order. Once the data has loaded, view the "Tests," "Steps," and "Assertions" column to easily identify pages lacking comprehensive coverage, as shown in the box below.
Where to find the "Daily Users" column, as well as two pages that are lacking coverage.
By default, mabl won't aggregate coverage data across environments (e.g app.myapp.com & dev.myapp.com). Type the URL host of the specific environment you'd like to view and wait for the table to populate with your data. Then, click on "Tests," "Steps," or "Assertions" to view the tests which have the most of each respective coverage type. This is also a great way to identify which pages may be visited by many tests but are lacking in steps that interact with or assertions that verify the page itself.
Where to find the "URL host" field. As we can see, this environment doesn't have much coverage at all.
To do so, you'll need to sort your coverage by "Linked To" in descending order. You'll view all of your pages ordered by the number of times the page was linked to by other parts of your app discovered by the link crawler. This helps you identify which pages are most frequently linked to and where they may lack coverage, as well as the number of users that are visiting the page on average.
The location of the "Linked To" tab within the coverage page.
The pages used to determine your page coverage are found through test executions, link crawlers, and segment integrations. While these sources provide a general snapshot of your applications, these pages might not all be relevant to your team. You can exclude pages from your coverage report by defining url paths that you do not want to see.
The coverage exclusion modal that is used to edit the list of paths.
The list of paths to exclude from your coverage report can be edited by clicking on the "exclusions" button in the top right corner of the Coverage page. Paths to ignore can be entered in the modal, and the changes can take up to 12 hours to appear.
Exclusions are applied across all hosts
Exclusions can also contain wildcards to match anything in one directory
Does not exclude:
Exclusions are also inclusive of subdirectories
Does not exclude:
Updated 2 months ago