5. Website test in practice

ONLINE HELP
WINDEV, WEBDEV AND WINDEV MOBILE

Version:

Home | Sign in | English

Help / WEBDEV concepts / Part 6 - Testing a website

Overview
Testing a WEBDEV project
Testing the project from the editor
Testing the project from the WEBDEV administrator
Stress test/Regression test
Testing a remote WEBDEV website (in AWP or Session mode)
Testing a page
Testing the page from the editor
Stopping the page test
Tracing a project
Debugging principles
Debugger overview
Debugger features
Debugging without the debugger
Performance test
Overview
Starting the performance profiler
Reading the performance profiler results
Choosing a process to optimize
Regression tests
Overview
Automated tests
WDTestSite

WINDEV

WEBDEV

WINDEV Mobile

Others

5. Website test in practice

Table of contents

Overview

WEBDEV includes multiple methods for testing your sites:

test of the entire project,
test of a single page,
test of a single query,
test of a single report,
step-by-step project execution,
site performance test,
regression test/automated test,
load test.

The test of the entire project simulates the site startup. This makes it possible to test the entire site, even if its development is not complete yet. If a problem occurs, you can start the debugger to identify and fix the problem.

The test of a single page runs the current page only. This allows you to test the project on a given page, or to test a page once its development is complete. Like for the project test, you can start the debugger if a problem occurs.

The test of a single query runs the current query only. This allows you to check the operating mode of a query once it has been developed.

The test of a single report runs the current report only. This allows you to test a report once it has been developed. Like for the project test, you can start the debugger if a problem occurs.

A step-by-step project execution allows you to launch the debugger when starting the site. This solution allows you to closely monitor how the site runs.

A performance test allows you to check and optimize the execution time of your site.

A regression test (or automated test) is based on the execution of scripts. It checks that existing features are still supported when the site is run.

A load test establishes multiple simultaneous connections to a dynamic WEBDEV website.

In addition to these methods, WEBDEV also includes the "Code coverage" of the site, i.e., the measurement of how much code is executed when the site is tested. For more details, see Code coverage.

Testing a WEBDEV project

Testing the project from the editor

Running the test from the editor allows you to test:

the site features,
the use of the site with different browsers.

The test of a project can be run regardless of the current element in the editor.

Note: The project test browser can be selected:

in the WEBDEV options. On the "Home" tab, in the "Environment" group, expand "Options" and select "WEBDEV general options". The browser can be selected in the "Web" tab.
in the test mode options. On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Test browser".

Different types of tests

To test a static site from the editor:

On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project from the home page".
The editor is automatically minimized.
The browser specified in the WEBDEV options opens and shows the site home page.

To test a dynamic site (Session or AWP) from the editor, you can use one of the following methods:

On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project" (or press Ctrl + F9).
Click in the quick access buttons.

The editor is automatically minimized and the browser specified in the WEBDEV options opens and shows first page of the site.

To test a static + dynamic site (Session or AWP) from the editor:

to test the static part of the site: Follow the steps to test a static site.
to test the dynamic part of the site (Session or AWP): Follow the steps to test a dynamic.

Launch of a dynamic site (Session or AWP mode):

The following modules are automatically started when testing a dynamic WEBDEV website (Session or AWP mode):

The web server installed on the computer and configured for WEBDEV when installing WEBDEV.
If the web server is not started, the test cannot be run.
The WEBDEV administrator (WD300ADMIN.EXE).
The administrator allows you to manage connections to the web server and configure WEBDEV websites.
Note: You can test a project from the test page of the administrator ("Advanced" tab of WD300ADMIN, "Test page" button).
The WEBDEV engine (WD300AWP.EXE).
The WEBDEV engine allows you to manage user requests and returns the corresponding dynamic HTML page.
Note: The WEBDEV engine is started only if the project contains dynamic pages.
The Internet browser.
The Internet browser displays the HTML pages of the WEBDEV website.

Testing the project from the WEBDEV administrator

Running the test from the WEBDEV administrator (WD300Admin) allows you to test:

the features of the site.
the features specific to the Web (use of cookies, etc).

Note: The WEBDEV administrator can only be used to test dynamic sites (Session or AWP) or the dynamic part of static + dynamic sites.

Running the test from the WEBDEV administrator is equivalent to starting the site from a remote computer.

Before deploying a WEBDEV website, it is recommended to test the site at least once from the WEBDEV administrator.

To run the test from the WEBDEV administrator:

Start the WEBDEV administrator. Go to the "Tools" tab, "Web utilities" group, and select "WDAdmin".
In the "Advanced" tab of the WEBDEV administrator, click the "Test page" button.

To stop the test, go to the WEBDEV administrator (click 2025 in the taskbar) and click "Disconnect" ("Connections" tab).

Note: You can test the project from the WEBDEV administrator, as if you were in the editor.

Start the WEBDEV administrator. Go to the "Tools" tab, "Web utilities" group, and select "WDAdmin".
On the "Connection" tab, select the site and click the "Test" button.

Stress test/Regression test

WDTestSite is used to perform stress tests. It opens multiple simultaneous connections to a dynamic WEBDEV site (Session or AWP).

Each connection performs a set of actions in the WEBDEV website (preset scenario).

For more details on WDTestSite, see WDTestSite.

Testing a remote WEBDEV website (in AWP or Session mode)

WEBDEV offers several methods to test and debug a site on the development computer. However, in some cases, you may have to debug the site directly in a production environment.

For example, you might need to debug a website running on a web server in Taiwan from your office in Paris. You can start debugging remotely in the same configuration as a real user.

Two options are available:

Starting and debugging the site on a remote application server.
Debugging a site running on a remote application server.

For these two options, a specific configuration of the remote computer is required.

Testing a page

Testing the page from the editor

To test a page from the editor:

Open the page to be tested.
Click in the quick access buttons of the WEBDEV menu. You can also press F9.
The editor is automatically minimized and the page is executed.

During the test, all the page features can be run. You will be able to open other pages, for example.

Stopping the page test

There are multiple methods to stop the test:

1st method:
Close the page being tested. WEBDEV displays the editor open when the test was started.
2nd method:
- Go back to the editor via the taskbar or press Alt + Tab.
- Stop the test. WEBDEV displays the editor open when the test was started.

Tracing a project

Debugging principles

Debugging an application consists in:

checking the operating mode of a process,
understanding the operating mode of an existing program,
checking the values of variables,
checking the operating mode of special cases in an application or website.

The debugger allows you to perform these operations.

Note: WEBDEV also includes several trace tools (trace window, message box, etc.). For more details, see "Debugging without the debugger".

Debugger overview

The debugger monitors WLanguage programs so they can be improved.

The executed source code appears on the screen. The processes run are sorted in hierarchical order in the "Debugger" pane.

The value of the variables is displayed:

individually in the on-hover tooltip of each variable.
in the "Debugger" pane.

Debugger features

The debugger allows you to:

view the call stack,
view the content of variables or expressions,
execute the code step by step with the possibility to skip code blocks,
use conditional breakpoints,
modify the code while continuing the execution,
...

Debugging without the debugger

In some cases, running a program with or without debugger may be different.

The debugger sets pauses in the execution of the processes, during which Windows performs multiple tasks.

Therefore, the debugger cannot be used in a procedure called by a timer or in the code of a scrollbar.

Note: For more details on the limitations of the debugger, see the online help.

To debug these programs, you may want to watch for changes of a value, see how different procedures are called, etc.

This information can be:

displayed on the screen.
stored in a trace file.

Caution: If this information is displayed on screen, it should only be shown during tests.

Displaying information

Two tools can be used to display information:

message boxes: WLanguage Info function.
Caution: Messages boxes are displayed modally.
trace window: WLanguage Trace function.
The trace window appears in the upper-left corner of the screen, without interrupting the program.

Displaying the debug information

Displaying the debug information on the screen is useful in test mode only.

Therefore, you should avoid displaying any unnecessary elements before publishing the site.

To avoid displaying unnecessary elements, it is recommended to set how the debug information is displayed via a global procedure.

For example:

PROCEDURE MyTrace(StringToTrace)
IF InTestMode() THEN
Trace(StringToTrace)
END

In this code, depending on the result of InTestMode, the trace window appears during the application test only.

This procedure prevents trace windows from being displayed on end-user computers, even if they are called in the code.

The call to this trace procedure is identical to the use of Trace:

MyTrace("Customer: " + ...
Customer.CustomerNum)

Creating a trace file

During long processes (batch processing, etc.), to check the operating mode of the program, you must keep a physical trace of the processes run (a text file, for example).

The following procedure allows you to define how the trace will be displayed:

on the screen (/DEBUG parameter in command line).

in a text file (default mode).

PROCEDURE MyTrace(StringToTrace)
FilePath is int
FilePath = fDataDirUser() + ...
	ProjectInfo(piProjectName) + ".txt"
FileNum is int
DebugMode is boolean = False
IF Position(CommandLine(), "/DEBUG") > 0 THEN
	DebugMode = True
END
IF DebugMode THEN
	Trace(StringToTrace)
ELSE
	FileNum = fOpen(FilePath, foCreateIfNotFound + ...
       	foWrite + foAdd)
	IF FileNum <> -1 THEN
		DateTimeTrace is DateTime
		DateTimeTrace = SysDateTime()
		DateTrace is Date
		DateTrace = DateTimeTrace.Date
		TimeTrace is Time 
		TimeTrace = DateTimeTrace.Time
		fWriteLine(FileNum, DateToString(DateTrace) + ...
			" - " + TimeToString(TimeTrace))
		fWriteLine(FileNum, StringToTrace)
		fWriteLine(FileNum, " ")
		fClose(FileNum)
	END
END

Remarks:

The trace file is created by default in the user data directory. The name of this file is the same as the project name. This file contains the information to trace during the program execution. The information is completed by the date and time of each "Trace". This allows you to detect a potential problem during the process.
Example of trace file content:
01/12/2015 - 10:53:25:20
Customer name: Martin

Performance test

Overview

The performance profiler allows you to check and optimize the execution time of your site.

The principle is straightforward:

The website test is run.
During the test, the performance profiler keeps track of all the actions performed and the corresponding processes run.

At the end of the test, the performance profiler displays:

the 10 most time-consuming operations.
all the actions performed in the tested site, sorted by duration (from the longest to the shortest action).

You can select a process to analyze its processing time and optimize it.

Starting the performance profiler

To start the performance profiler, go to the "Project" tab, "Audit and performance" group, expand "Analyze performance" and select "Analyze performance".

The project is automatically run in test mode. The process to optimize can be run in your site.

To go back to the editor, simply close your application or website.

The performance profiler displays the result of the analysis.

Note: Use the performance profiler to optimize your website (before publishing, for example).

Reading the performance profiler results

The performance profiler presents the result of the analysis in several tabs:

the "Summary" tab shows the ten longest processes.
the "Mapping" tab shows a graphical view of the main processes.
the "Details" tab shows all the processes run during the test of the application (from the slowest to the fastest).
the "Calls" tab shows the details of the operations performed in a process.

The following information is displayed for each process:


Function	Function, process or procedure run.
Total time	Function execution time.
Calls	Number of calls made to the function (procedure or process).
Time per call	Execution time of a call to the function (procedure or process).
Code %	Percentage of code run outside the call to a WLanguage function or outside the call to a custom function or procedure.
Parent	Process that called the function.

Remark: In the Details tab, "Execution completed" indicates the total time of the test run with the performance profiler.

Choosing a process to optimize

The processes to be optimized are chosen based on several criteria:

the process execution time. The longest processes must be optimized.
the percentage of time used by the function or procedure. The higher this percentage is, the greater the number of processes that can be optimized in the code.

Note: If the process corresponds to a WLanguage function, it will be quite difficult to optimize it.

Regression tests

Overview

There are several test options to guarantee the quality of your applications:

Project or page test (Go icon), which can be used to immediately test any changes made to your site.
WDTestSite, which can be used to run different tests on a WEBDEV website.

To automate these tests and improve your applications, you can also run automated unit tests. These tests allow you to easily check all the features available in your applications.

Automated tests

Each test contains a scenario that can be directly edited in the development environment. This scenario is written in WLanguage and can be modified at any time.

These tests can be run before each deployment to make sure your website works properly after the changes you made.

You can test the following elements:

sets of procedures
classes

Each test is associated with a WLanguage code: the test scenario. This scenario can be viewed in the code editor. The code of the tests can be modified.

The tests and the associated code are not provided to the end users. Therefore, the number of tests has no impact on the size of the site available to end users.

For more details, see Automated tests.

WDTestSite

WDTestSite is used to run different tests on a WEBDEV website.

WDTestSite can run the following tests:

Load test:
Load tests simulate the connection of several users to a WEBDEV website. All users perform a series of operations (scenario) at the same time.
Regression test:
Regression tests check how a WEBDEV website works between two updates. A scenario created with a previous version of the site must work correctly in the updated site.
Test of a site in multi-user mode:
The test of a site in multi-user mode checks whether concurrent accesses to the data files are handled properly. This test consists in simulating the simultaneous connection of several users to a WEBDEV website. All users perform a series of operations (scenario) at the same time.
Comparison of different servers:
WDTestSite compares the speed of different servers. Simply run the same scenario on different servers and compare the scenario execution time.
Optimization of processes developed in WLanguage:
WDTestSite compares the execution time of a scenario before and after the WLanguage code is optimized.