Auflistung nach:
Auflistung Softwaretechnik-Trends 37(1) - 2017 nach Erscheinungsdatum
1 - 10 von 12
Treffer pro Seite
Sortieroptionen
- Zeitschriftenartikel10 Steps to ISO26262-compliant Model-based Software Development(Softwaretechnik-Trends Band 37, Heft 1, 2017) Lackner, H.
- ZeitschriftenartikelMobile App Testing – Nutzerfeedback automatisiert miteinbeziehen(Softwaretechnik-Trends Band 37, Heft 1, 2017) Elberzhager, Frank; Holl, Konstantin; Scherr, Simon AndréUm eine innovative mobile App schnell auf den Markt zu bringen, nehmen Anbieter in Kauf, sie mit eingeschränkter Qualität bzw. Funktionalität als sogenanntes Minimum Viable Product (MVP) zu entwickeln. Die Gratwanderung besteht darin, sich trotz Zeit- und Kostendruck auf die richtigen Features und Qualitäten zu konzentrieren. Andernfalls werden mobile Apps trotz innovativer Idee auf dem Markt nicht akzeptiert. Um den MVP-Ansatz zu optimieren, sollen Nutzerrückmeldungen früh und schnell berücksichtigt sowie auf typische Mängelaspekte fokussiert werden. In diesem Artikel soll ein Framework vorgestellt werden, welches textuelle Nutzerrückmeldungen sowie das Nutzerverhalten bei Verwendung der App erfasst und dieses auswertet. Die automatisch ausgewerteten Rückmeldungen liefern Informationen hinsichtlich der Verwendung und des Zustands der App sowie explizite Probleme und Featurewünsche der Nutzer. In der Weiterentwicklung der mobilen Apps stellen die Rückmeldungen entscheidende Hinweise für Personen in der Qualitätssicherung und der Entwicklung dar. Dies führt zu höherer Qualität und somit frühzeitig zur Optimierung mobiler Apps.
- ZeitschriftenartikelISTQB und die Standards - Freund oder Feind?(Softwaretechnik-Trends Band 37, Heft 1, 2017) Hamburg, Matthias; Dussa-Zieger, KlaudiaDas 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.
- ZeitschriftenartikelTestautomatisierung - Lessons learned(Softwaretechnik-Trends Band 37, Heft 1, 2017) Schönknecht, Andreas
- ZeitschriftenartikelSoftwaretechnik-Trends Band 37, Heft 1(Softwaretechnik-Trends Band 37, Heft 1, 2017) GI-FB Softwaretechnik
- ZeitschriftenartikelBericht: 40. Treffen der GI-Fachgruppe Test, Analyse & Verifikation von Software (TAV 40)(Softwaretechnik-Trends Band 37, Heft 1, 2017) Pietschker, Andreij
- ZeitschriftenartikelSoftware Testdokumentation nach den IEEE und ISO Standards(Softwaretechnik-Trends Band 37, Heft 1, 2017) Sneed, Harry; Seidl, RichardTest 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].
- ZeitschriftenartikelAutomatisiertes Testen von verteilten Systemen über Petrinetze(Softwaretechnik-Trends Band 37, Heft 1, 2017) Ruß, Tim; Magnus, Stephan; Krause, JanDieser 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.
- ZeitschriftenartikelGleitender Übergang vom manuellen zum automatisierten Test eingebetteter Software(Softwaretechnik-Trends Band 37, Heft 1, 2017) Sadeghipour, SadeghAngesichts 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.
- ZeitschriftenartikelTesten und Docker anhand eines Beispiels aus der Praxis(Softwaretechnik-Trends Band 37, Heft 1, 2017) Sokenou, Dehla