<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
<channel>
<title>Softwaretechnik-Trends 37(1) - 2017</title>
<link>http://dl.gi.de/handle/20.500.12116/40584</link>
<description/>
<pubDate>Tue, 21 Jul 2026 14:24:42 GMT</pubDate>
<dc:date>2026-07-21T14:24:42Z</dc:date>
<item>
<title>Automatisiertes Testen von verteilten Systemen über Petrinetze</title>
<link>http://dl.gi.de/handle/20.500.12116/40596</link>
<description>Automatisiertes Testen von verteilten Systemen über Petrinetze
Ruß, Tim; Magnus, Stephan; Krause, Jan
Dieser Beitrag stellt eine Methode vor, um mittels modellbasierter Tests ein verteiltes System über seine Netzwerk-Kommunikation zu validieren. Diese wird kontextabhängig gegen ein Sollverhalten geprüft und ggf. manipuliert. Die Beschreibung des Sollverhaltens erfolgt hierbei durch eine sequenzbasierte Notation. Dadurch ist es einfach und intuitiv möglich, Testszenarien zu implementieren und automatisiert durchzuführen. Zur Laufzeit wird das Netzwerkverhalten über ein Petrinetz effizient validiert. Außerdem ist es möglich, ein entsprechendes Gerät in ein Netzwerk zu integrieren und den Datenverkehr auf vielfältige Weise zu manipulieren.
</description>
<pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/40596</guid>
<dc:date>2017-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>Software Testdokumentation nach den IEEE und ISO Standards</title>
<link>http://dl.gi.de/handle/20.500.12116/40595</link>
<description>Software Testdokumentation nach den IEEE und ISO Standards
Sneed, Harry; Seidl, Richard
Test documentation is needed not only to assess the extent and quality of a test but also to assess the productivity of testers and to tie the test to the software architecture. Decision makers and auditors need test documentation to decide whether to release a version or not. Maintainers need test documentation to see how changes can be tested. Testers need test documents to help them identify the causes of errors. Finally auditors require a documentation of the test to confirm that the product has been adequately tested. Test documents are prescribed by prevailing IEEE and ISO standards. Originally they were prepared by hand. Today they are most often generated automatically as a byproduct of the test automation. The demand for test documentation goes back to the early days of testing when the US military was testing the ballistic missile defense system. The tool RXVP – Research and Evaluation Package – instrumented the Fortran code to trace execution paths through the system and to measure the degree of test coverage. Branch coverage was considered at that time to be an important criteria for determining how well the software was tested [Miller, 1979]. It was also important to register the paths that were taken through the network of code modules in order to be able to reconstruct the tests. Shortly thereafter the IEEE published the Standard ANSI/IEEE-829 for Software Test Documentation. The first version appeared in 1983. It was later revised in 1998 [ANSI/IEEE, 1998]. It is interesting to note that this first general test standard was entitled test documentation and not just system testing. It emphasized what should come out of a system test – the results. Later in 1987 another corresponding standard for unit testing – ANSI/IEEE Std. 1008 – was published. That standard put much less emphasis on documentation, i.e. what should be delivered, and instead emphasized the process, i.e. how software units should be tested [ANSI/IEEE, 1993].
</description>
<pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/40595</guid>
<dc:date>2017-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>Gleitender Übergang vom manuellen zum automatisierten Test eingebetteter Software</title>
<link>http://dl.gi.de/handle/20.500.12116/40597</link>
<description>Gleitender Übergang vom manuellen zum automatisierten Test eingebetteter Software
Sadeghipour, Sadegh
Angesichts der zunehmenden Funktionsumfänge und wechselseitigen Abhängigkeiten eingebetteter Systeme wird deren Testprozess immer aufwendiger. Eine erste Voraussetzung zur Beherrschung der Komplexität des Testprozesses ist die Testautomatisierung. Die hohen Kosten und der Aufwand der Einführung und des Betriebs der Testautomatisierung sowie der Bruch zwischen dem manuellen und automatisierten Testprozess sind Aspekte, welche viele Unternehmen davon abhalten, ihren Testprozess zu automatisieren. Im vorliegenden Beitrag wird eine SoftwareArchitektur zur Automatisierung der Testausführung und -auswertung präsentiert, welche den genannten Nachteilen entgegenwirkt. Ferner wird ein Testframework vorgestellt, das die vorgeschlagene Architektur umsetzt.
</description>
<pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/40597</guid>
<dc:date>2017-01-01T00:00:00Z</dc:date>
</item>
<item>
<title>ISTQB und die Standards - Freund oder Feind?</title>
<link>http://dl.gi.de/handle/20.500.12116/40594</link>
<description>ISTQB und die Standards - Freund oder Feind?
Hamburg, Matthias; Dussa-Zieger, Klaudia
Das Qualifizierungsprogramm des International Software Testing Qualifications Board (ISTQB) wird von vielen als ein Standard angesehen. Manche sehen darin sogar eine Standard-Testmethode. Andererseits veröffentlichen IEEE, ISO und andere Normungsinstitute in letzter Zeit immer wieder neue Normen und Standards im Umfeld des Softwaretestens. Es stellt sich die Frage, woran sich Unternehmen in der Praxis halten sollten. In diesem Beitrag erläutern wir die Beziehung zwischen ISTQB und den relevanten SoftwaretestStandards. Wir argumentieren dafür, dass Unternehmen ihre eigene Testmethode an solchen Standards orientieren sollen, während sie ihren Mitarbeitern eine Grundausbildung nach ISTQB zukommen lassen.
</description>
<pubDate>Sun, 01 Jan 2017 00:00:00 GMT</pubDate>
<guid isPermaLink="false">http://dl.gi.de/handle/20.500.12116/40594</guid>
<dc:date>2017-01-01T00:00:00Z</dc:date>
</item>
</channel>
</rss>
