Lx-Viewer logo
10:42, 18th August 2017

Testing

A major drive began before v1.0 for formal testing. Automated testing tools are under development and all aspects of the system are being documented. What follows is the current state of the documentation and testing effort.

Index

  1. Introduction
  2. Reporting simple compile errors
  3. Written specifications of the program
  4. Testing the user interface
  5. Testing the main program operation
  6. Distributions tested
  7. Code Auditing
  8. Automated testing
  9. Test files
  10. Program Documentation - Users
  11. Program Documentation - Developers
  12. Multilanguage testing
  13. References/further reading

Introduction

This page will document as much of the testing process as possible with an eye to aiding any volunteers who wish to help with testing the program. Software testing is important and anyone can help, so if you feel like you might like to take part with this side of the project, do contact one of the developers. The more people that help check the program, the better it will become.

Currently the formal testing program is in a developing state. Debugging is done by the developers with initial feedback on the programs operation by other group members (and end users once a file release has been made). Automated testing tools for the project are in a primative state at the moment but there have been discussions to aid this on the developers mailing list. The results of that will be conveyed on this page.

Bugs found are recorded on the Sourceforge tracker bugs page http://sourceforge.net/tracker/?group_id=30996&atid=401089, whereby the developers assign the bugs a priority level and record other information relevent to the problem and possible solution.

We encourage you to find DWG and DXF's that this program can't open but AutoCAD can. Send us the file with a bit of background description and we'll do something about it.

Reporting Compile/Make Errors

Errors in configuring can generally be caught with the following, which will send standard output and standard error to the same file:
./configure > configerrors.txt 2>&1

You can now copy the text in the file to the SourceForge bug page, or to the forum page for the project. Similarly with make:
make > makeerrors.txt 2>&1

Written Specifications of the Program

The following specifications should assist the testing of the program by providing a valid reference to the programs normal opperation. If you have any experience writing these kind of specifications please take a moment to look over them and let us know of any changes or additions you think should be made

Requirements Specification The requirements that the software is supposed to fullfill for the end user. Anyone should be able to check these details against the running program with ease

Functional Design Specification More technical descriptions of how the software should opperate and interact

Internal Design Specification Developers technical documents concerning the programs internal design.

Testing the User Interface

Using the Requirements and Functional Design specifications, check against the program you have recieved to ensure it operates as expected. Feel free to express your personal opinions on the programs aethetics, layout, usability and responsiveness.

Testing the Main Program Operation

You are much more likely to find a bug here if you have a wide selection of DWG files, eg ones made in product lines associated with AutoCAD (such as Autodesk Architectural Desktop), and yes we want you to try and find as many bugs as possible. Again, use the requirements and functional design specifications as a reference, report on an contradictions between the specifications and the program, or problems in program use, such as unopenable files or printing problems

Distributions Tested

DistributionVersionStatustested (date)VersionInstall instructionsRPM/DPM
Generic Installtesting0.98ayesSource
Mandrake9.1Definitive1.0yesno
Redhat8.0testing0.99eyesno

Code Auditing

It helps to have some Qt or C++ experience for these opperations. The basic methology is to find a cpp or header file and work through it asking yourself questions. eg Are all constant names in upper case? Do all but the most obvious declarations have comments?

ANSI validating

Automated Tools

Documented in full on the testing tools page. This includes the testing script and details on other programs that might aid the testing process.

Test Files

Free files to download from the internet. If you know of any more, let us know

Program Documentation - Users

Program Documentation - Developers

Multilanguage Testing

Is the translation to your language accurate? More importantly, is the translation up to date? The user guides are updated but the translations take longer, so errors may have crept in. Text expansion may also cause translations to overflow button areas, this needs to be checked for in all translations

References and Further Reading

Software Testing in the Real World - Improving the Process, Edward Kitt, 1995 ACM Press
Software Testing, Marc Roper, 1994 McGraw-Hill
The Handbook of MIS Application Software testing, Daniel J. Mosley, 1993 Prentice-Hall
Software Testing, Ron Patton, 2000 SAMS
Effective Computer User Documentation, James Crown, 1992 Thompson Publishing

Page last modified: 1 January 1970 00:00