Folge uns auf:

Startseite » Mitmachen » Testen

Testen

Inhalt

Inkscape testen

Inkscape ist ein junges Projekt und der Fokus liegt noch auf der Entwicklung neuer Features. Trotzdem freut es uns, dass die Stabilität von Inkscape mit jeder neuen Version weiter zugenommen hat.

Der Löwenanteil am 'Testen' ist ganz einfach, Inkcape für die ganz normale Arbeit einzusetzen -- was bestätigt, dass Inkscape bereits so ausgereift ist, dabei die neuen Features zu benutzen und sicherzustellen, dass die Anwendung das tut, was man von ihr erwartet.

Schreibe einen Fehlerbericht wenn Du irgendetwas findest, das sich nicht so verhält wie es eigentlich sollte. Ein Fehlerbericht sollte zumindest eine Schritt-für-Schritt-Beschreibung enthalten, die beschreibt, wie der Bug ausgelöst werden kann und/oder eine Testdatei, die den Bug demonstriert (je kleiner/mehr auf den Bug konzentriert, desto besser).

? Weiteres...

Benutzer

Alle Möglichkeiten stehen Dir offen. Wir freuen uns sehr über Fehlerberichte und Vorschläge für neue Funktionen (in Form eines Fehlerberichts). Oft ist es nötig, diese Berichte weiter zu analysieren, umzuformulieren und noch weitere Aktionen durchzuführen. Jeder kann so etwas machen.

Noch besser wäre es, wenn Du Verbesserungen für die Teile des Programmes, die von Deinen Erwartungen abweichen, einreichen könntest - das ist für uns auch eine Bestätigung, dass das Projekt sich weiterentwickelt. Bedenke, dass bei einer instabilen Version - die Du entweder selbst gemacht hast (siehe CompilingInkscape), oder die Du als Snapshot der Entwicklerversion heruntergeladen hast, ausgiebiges und ernsthaftes Testen erforderlich ist. Wir würden auch gerne erfahren, wo wir im Vergleich zu ähnlichen Anwendungen stehen. Wenn Du merkst, dass Du interessante Ideen für Unzulänglichkeiten in Inkscape oder Pläne für Verbesserungen hast, dann nimm Kontakt zur Tester-Gruppe von Inkscape auf.

Wir brauchen weiterhin Helfer, die die Dokumentation, die Online-Hilfe, Tutorials und Screenshots erstellen und aktuell halten. Fehler in diesen Bereichen zu finden und zu melden ist ebenfalls eine wichtige Art des Testens - wir möchten nicht, dass eine Version mit veralteter Dokumentation veröffentlicht wird.

Inkscape-Tester

Im Laufe der Zeit hat sich eine Gruppe von Inkscape-Testern entwickelt, die auch ihre eigene Mailingliste hat - und von der wir hoffen, dass sie die gesamte Arbeit rund um Usability und Softwareergonomie anführt. Diese Gruppe sollte der erste Anlaufpunkt für folgende Teilgebiete sein:

Siehe auch TestingFramework. (Note: Bryce? Jon? shouldn't the whole of that page be merged here? Or is it better to have this info in two pieces. IMHO wiki pages should not be made too long)

Rendering-Tests

Des weiteren gibt es für Inkscape Rendering-Tests, für deren Erstellung, Durchführung und Auswertung man nicht unbedingt ein Entwickler sein muss. Die Tests kann man im SVN (siehe unten) finden. Weiter unten findest Du auch Informationen darüber, wie Du diese Tests durchführen und auch selbst erstellen kannst.

See this list for up-to-date results.

Running rendering tests

Apart from running low-level unit tests Inkscape can also be tested on a higher level (also see SVG Test Suite Compliance. Currently (2008-7-26) there is a rendering test tool (along with a few test cases) in SVN ([1]) which can be used to partially automate rendering tests.

To run the rendering tests:

Note that by default only a binary comparison between the output and reference files is used, perceptualdiff (or any other comparison tool that returns zero on success and 1 on failure) can be used to aid comparison of images (see the available options of runtests.py). Note that perceptualdiff (1.0.2) had some problems with transparency, these might be solved by now, and if not, there is a patch in its patch tracker.

To select a subset of tests to perform, specify one or more patterns (with Unix-style wildcards) on the command line. Each pattern is interpreted as specifying a prefix. For example, 'runtest.py bugs' will match any tests whose path relative to the directory with test cases starts with 'bugs' (for example: 'bugsy.svg' or 'bugs/bugXYZ.svg').

The most common test results are:

runtests.py puts the output files in a subdirectory 'output' (at the same level as the 'testcases' and 'references' directories).

Creating rendering tests

Just put an SVG file in the 'testcases' directory (subdirectories can be used for organizing the tests).

To add a pass/fail reference, just put it in the corresponding location under references/pass or references/fail. References are matched by prefix, so any reference that has the original name (without its extension) as a prefix is seen as a reference for that file.

Fail references are used to distinguish between a result that is known wrong and a result that is just (perhaps only slightly) different from the correct rendering. If you are unable to create a pass reference you can even give just a fail reference.

It is also possible to create an SVG file that should produce the exact same output as a test case but uses simpler (or just different) methods. This practice is suggested in the SVG Conformance Test Plan. For example, if the test case file is called 'testcases/basic/foo.svg' you could create a "patch" file called 'testcases/basic/foo-patch.svg'. runtests.py would then use Inkscape to create a pass reference file from that (as 'references/pass/basic/foo-patch.svg') and use it as one of the references. (Note that this reference should in general not be committed to SVN.)

Developers

Build report

There is an 'inkscape build report; which is sent regularly to the inkscape-tester list (and periodically to the developer list, when new problems are seen) that gives a count of warnings spotted in the code.

Running unit tests

There are now some unit tests which should be performed before checking in. These may take some time to complete, and so this cannot be made a requirement for each build (Test Driven Development), nonetheless everyone is on their honour not to 'break the build' by committing code that does not pass these tests. You can execute them by:

Cxxtests will generate two (more or less equivalent) result files, an XML file and a text file with the extension 'log'. On Linux, those files are located in (buildpath)/src.

Creating unit tests

Inkscape uses the CxxTest framework. To enhance, modify or extend existing unit tests, just edit the existing test file (....-test.h).

The easiest way to create a new test in a directory which already has some unit tests is to simply copy one of the existing test files, strip it (remove anything specific and rename the class, constructors, etc.) and add some test methods. Take the time to look at the different ASSERT statements CxxTest supports, the TSM_ variants can be especially useful for example when you want to test a lot of different cases. Important: to make everything build correctly you have to do the following:

# Do like this:
CXXTEST_TESTSUITES += \
    $(srcdir)/dir/first-test.h \
    $(srcdir)/dir/second-test.h

For creating a unit test in a directory which does not have any unit tests yet:

Running tests unattended

For unit tests this is no problem, just set up something that runs cxxtests and you can use one of the log files it creates to see how it went.

To be able to run the rendering tests unattended on Windows you have to compile Inkscape as a commandline executable to prevent any CRT runtime error dialog boxes (or something similar) from popping up. On Linux and other Unices, this problem doesn't exist.

The teststatus.json file that is generated by runtests.py contains all the test results (in JSON format). Note that if you only run a subset of the tests this file retains all the information on tests that do not fall into that subset. It also retains old test results. The result codes in this file can be interpreted as in runtests.py (for example, 0, 1 and 2 stand for pass, fail and new, respectively).

Analyzing test coverage

To see how well the (unit) tests cover certain parts of the code, or to compare the coverage of rendering tests vs. unit tests, gcov can be used. See Profiling for more information on how to use gcov and coverage.py (a tool to get some grip on the massive amounts of data gcov can generate).