|
|
|
|
|
- Overview
- Performing a dynamic audit from the development environment
- Starting a dynamic audit during the project test
- Starting a dynamic audit during the automated tests
- Performing a dynamic audit in the deployed application
- Overview
- Starting a dynamic audit through programming
- Starting a dynamic audit by using the ".WX" file
- Starting a dynamic audit in an application currently run
- Examining a dynamic audit
- Opening the status report of dynamic audit
- Window for analyzing a dynamic audit
- Types of events collected by the dynamic audit
The dynamic audit of an application analyzes its runtime performance. A dynamic audit can be performed in a test environment or on a live application. The audit detects problems such as: - Excessive memory consumption.
- Slowness of algorithms used.
- Errors "hidden" at runtime.
- ...
A dynamic audit can be performed: Performing a dynamic audit from the development environment The dynamic audit can be started: Starting a dynamic audit during the project test 1. Automatic dynamic audit During each window or project GO, a dynamic audit is performed in background task, without slowing down the execution. When the test is ended, the number of problems that occurred is displayed in the "Dynamic audit" widget of Project dashboard. To see the detailed status report, simply click the widget.To disable this automatic dynamic audit: - Click the widget arrow.
- Uncheck "Dynamic audit enabled".
In this case, no audit will be performed during a test via a simple GO: the dynamic audit will have to be explicitly started during the project test. 2. Dynamic audit explicitly started To explicitly start a dynamic audit during the project test: - Open the project to analyze.
- Use one of the following methods:
- On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project while the audit is enabled".
Not available. - In the project dashboard, expand the arrow of the "Dynamic audit" widget and select "In-depth project test (Go)".
- In the quick access icons, expand the "GO" icon and select the "Debug project while the audit is enabled" option.
Not available.
- The project starts.
- Handle the project in order to use the features that must be audited.
- Close the application.
- The editor opens the dynamic audit report window.
Starting a dynamic audit during the automated tests To start a dynamic audit during the automated tests: - Open the project to analyze.
- On the "Automated tests" tab, in the "Tests" group, expand "Run all" and select "Enable the dynamic audit during the automated tests".
The dynamic audit will be performed when an automated test is run. The report window of the dynamic audit is displayed at the end of test. The status report of dynamic audit is also displayed in the "Debugger trace" pane. Performing a dynamic audit in the deployed application Overview The dynamic audit can be started: - through programming.
- via the WX file.
- via a key combination.
Starting a dynamic audit through programming To programmatically start a dynamic audit, simply call dbgEnableAudit. The audit generates a ".waudit" file. This file must be loaded in the development environment in order to analyze the result. Remark: To analyze the result of application audit, the project of this application must be opened in WINDEV, WINDEV Mobile or WEBDEV. Examining a dynamic audit Opening the status report of dynamic audit The status report of the dynamic audit is a file whose extension is ".waudit". To open this file, you can: - Open the file in the editor directly: on the "Home" tab, in the "General" group, click "Open" and select the audit file.
- Use the "Dynamic audit" widget of the project dashboard: click the widget arrow and select "Open an audit". Then, select the audit file.
Window for analyzing a dynamic audit When loading a dynamic audit, the following window is displayed: - 1: Name of the audit file currently analyzed.
- 2: Period of time during which the audit was performed.
- 3: Selecting the period of time to view. If the audit spans over a long period of time, you can read a specific part of it using a range slider. The range slider covers the entire duration of the audit. The active section of the control (modifiable with the arrow keys) is displayed below. This area can be clicked and it automatically selects the event closest to the moment that was clicked (in the list of events).
- 4: Display mode of audit events. The audit events can be displayed in in a chronological order in the list of events or they can be grouped by family of events
- 5: Filtering button used to choose the types of events that will be displayed.
- 6: List of events displaying all the elements collected by the audit. On each table row:
- a "..." button is used to access the event details.
- if the event is linked to a particular code row, the "Code" button allows you to open the code editor directly at the corresponding location.
- the "-" button is used to disable the error. CAUTION: The error will no longer be displayed if it is disabled. It cannot be re-enabled.
Types of events collected by the dynamic audit The different types of events collected by the dynamic audit are: - The exceptions: an exception is a fatal error of the application (unless it is intercepted in a WHEN EXCEPTION block). An exception can be voluntarily generated by ExceptionThrow.
All the exceptions are reported by the dynamic audit (exceptions processed through programming or exceptions that have stopped the application). In most cases, an exception is the result of a programming error. - The errors: an error can be triggered by a WLanguage function to signal the failure of an operation (for example, fDelete returns an error if the deletion of the requested file failed). The errors can also be triggered by the developer via ErrorThrow.
In most cases, an error is caused by an invalid action of the application user or by a failure in the application environment. - The runtime warnings: these warnings are reported by some WLanguage functions to signal a potential problematic behavior but that causes no error. For example, if the WLanguage detects a performance problem in the code of the application.
Examples of runtime warning: - Using zipExtractFile in a loop to extract an important number of files from a Zip or 7z archive is not very efficient. We recommend that you use zipExtractFileList.
- Possible improvements on Chart controls: activation of anti-aliasing, use of labels inside pie sections, ...
- Access to controls not recommended from the secondary threads.
- Low client-to-server send rate. This warning indicates a network performance problem. It appears when opening a connection to a server in HFSQL Client/Server mode if:
- latency is higher than 50 milliseconds,
- a small network frame takes a long time to go back and forth between the client and the server (more than one second for 256 kB).
- Assertions: the runtime audit reports all the calls to dbgAssert in which the condition turned out to be False.
- The debugging events: these events are triggered by the call to the debugging functions (dbgSaveMemoryDump for example).
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|