Akzeptanztests werden in Scrum-Projekten durchgeführt, um umgesetzte Anforderungen iterativ und inkrementell gegen die Erwartungen des Product Owners zu prüfen. Dazu müssen Testartefakte kontinuierlich spezifiziert, gewartet und ausgeführt werden. Im Projektverlauf werden die Durchführung und Wartung des Testprozesses zunehmend zu zeit- und ressourcenkritischen Aufgaben, die mit einer manuellen Testdurchführung nicht mehr zu bewerkstelligen sind. Es wird ein ausgereifter Testautomatisierungsansatz benötigt. In dieser Arbeit wurde ein Testverfahren entworfen, welches die Vorteile des Model-Based Testing (MBT) mit anderen Test-First-Ansätzen, wie dem Behavior-Driven Development und Acceptance Test-Driven Development kombiniert, um die automatisierte Durchführung von Akzeptanztests im Scrum-Vorgehen zu integrieren. Dafür wurde untersucht, wie Anforderungen in Form von User Storys für die Testmodellentwicklung formalisiert werden können, wie die Rückverfolgbarkeit vom Testfall zur Anforderung und zurück gewährleistet werden kann und wie abstrakte Testfälle für die automatische Testdurchführung konkretisiert werden können. Zudem wurden ein Automatisierungs- und Durchführungsansatz für die Nutzung von GraphWalker mit Selenium als Adapterschicht zur Graphical User Interface (GUI)-Testautomatisierung sowie Möglichkeiten der Nutzung von Zustandsmodellen zur Modellierung fachlich oder logisch unerwünschter Pfade dargelegt. Das Testverfahren wurde prototypisch bei einem Fallbeispiel implementiert, um konkrete Anwendungsfälle umzusetzen und Rückschlüsse aus der praktischen Anwendung ziehen zu können. Die Ergebnisse der Arbeit zeigen, dass sich das konzipierte Testverfahren für die Automatisierung von Akzeptanztests eignet und das Vorgehen sowohl von Forschenden als auch Praktizierenden zur Implementierung eines MBT-Verfahrens verwendet werden kann.

The automatic creation of test cases has been a well-researched area in recent years. Indeed, the industry’s testing procedure still uses the traditional way of manual practices. However, investigations are continued to deliver new methods, but research results have not been fully adopted. In this paper, the investigated method applies the model-based testing (MBT) method to evaluate the ability to automate the creation of hardware-in-the-loop (HIL) test cases, where generated tests are created using MBT tools. The tools’ properties were compared to each other through a literature study, with the result of selecting tools to be used in a case study, and the tools selected were GraphWalker and MoMuT. The generated test cases perform similarly to their manual counterparts regarding how the test cases achieved full requirements coverage. When comparing the effort needed for applying the methods, a comparable effort is required for creating the first iteration, while with every subsequent update, MBT will require less effort compared to the manual process. Both methods achieve 100% requirements coverage, and since manual testing is created and executed by humans, some requirements are favoured over others due to company demands, while MBT tests will be generated randomly.In addition, a comparison between the used tools showcased the differences in the models’ design and their test case generation. The comparison showed that GraphWalker has a more straightforward design method and is better suited for smaller systems, while’s MoMuT can handle more complex systems but has a more involved design method.The results of the thesis showed that using MBT tools proved helpful as it covers the system requirements, can be executed in HIL and helps discover faults within the requirements and HIL system. These facts satisfy the companies’ demands. This thesis shows a promising improvement in automating the test process within the vehicular domain.

With modern computer systems becoming more and more complicated, theimportance of rigorous testing to ensure the quality of the product increases.This, however, means that the cost to perform tests also increases. In orderto address this problem, a lot of research has been conducted during thelast years to find a more automated way of testing software systems. Inthis thesis, different algorithms to automatically explore and test a systemhave been implemented and evaluated. In addition to this, a second setof algorithms have been implemented with the objective to isolate whichinteractions with the system were responsible for a failure. These algorithmswere also evaluated and compared against each other. In the first evaluationtwo explorers, which I called DeBruijn and LStarExplorer, were consideredsuperior to the other. The first used a DeBruijn sequence to brute forcea solution while the second used the L*-algorithm to build an FSM overthe system under test. This FSM could then be used to provide a moreaccurate description for when the failure occurred. The result from thesecond evaluation were two reducers which both tried to recreate a failureby first applying interactions performed just before the failure occurred. Ifthis was not successful, they tried interactions further and further away, untilthe failure was triggered. In addition to this, the thesis contains descriptionsabout the framework used to run the different strategies. / D ̊a v ̊ara moderna datasystem blir allt mer komplicerade,  ̈okar detta st ̈andigtbehovet av rigor ̈osa tester f ̈or att s ̈akerst ̈alla kvaliteten p ̊a den slutgiltiga pro-dukten. Det h ̈ar inneb ̈ar dock att kostnaden f ̈or att utf ̈ora testerna ocks ̊ao  ̈ kar. F ̈or att f ̈ors ̈oka hitta en l ̈osning p ̊a det h ̈ar problemet har forsknin-gen under senare tid arbetat med att ta fram automatiserade metoder atttesta mjukvarusystem. I den h ̈ar uppsatsen har olika algoritmer, f ̈or attutforska och testa ett system, implementerats och utv ̈arderats. D ̈arut ̈overhar ocks ̊a en grupp algoritmer implementerats som ska kunna isolera vilkainteraktioner med ett system som f ̊ar det att fallera.  ̈aven dessa algoritmerhar utv ̈arderats och testats mot varandra. Resultatet fr ̊an det f ̈orsta ex-perimentet var tv ̊a explorers, h ̈ar kallade DeBruijn och LStarExplorer, somvisade sig vara b ̈attre  ̈an de andra. Den f ̈orsta av dessa anv ̈ande en DeBruijn-sekvens f ̈or att hitta felen, medan den andra anv ̈ande en L*-algoritm f ̈or attbygga upp en FSM  ̈over systemet. Den h ̈ar FSM:en kunde sedan anv ̈andasf ̈or att mer precist beskriva n ̈ar felet uppstod. Resultatet fr ̊an det andraexperimentet var tv ̊a reducers, vilka b ̊ada f ̈ors ̈okte  ̊aterskapa fel genom attf ̈orst applicera interaktioner som ursprungligen utf ̈ordes percis innan feletuppstod. Om felet inte kunde  ̊aterskapas p ̊a detta s ̈att, fortsatte de medatt applicera interaktioner l ̈angre bort tills felet kunde  ̊aterskapas. Ut ̈overdetta inneh ̊aller uppsatsen ocks ̊a beskrivningar av ramverken som anv ̈andsf ̈or att k ̈ora de olika strategierna.

Under två decennier har utvecklare inom mjukvarutestning utvecklat testtekniken Modell-baseradtestning. Tekniken bygger på att man genererar testfall från en modell (tex i UML), istället föratt manuallet skriva testfall. Detta kan göra testprocessen mer effektiv, vilket leder till att merarbeten kan göras på kortare tid. Det kan också ses som en ekonomiskt fördel för företag därtestning är huvudområdet. Modell-baserad testning har goda omdömen och teorin för teknikenär väl dokumenterad i artiklar, arbeten samt böcker. Mycket tyder på att tekniken rent teoretisktär användbar i praktiken dessutom finns det väldigt lite kritik mot tekniken. Men trots alltdetta har Modell-baserad testning inte blomstrat inom IT-industrin.Syftet med detta arbete är att ta reda på vad anledningarna skulle kunna vara till att MBT intelyckats bättre inom industrin. I arbetet används tre olika MBT-verktyg för att testa och sedanjämföra om resultatet i praktiken blir som teorin beskriver tekniken. Studiens resultat pekar påatt tekniken fortfarande är omogen och många brister kring Modell-baserad testning stöts på. / For two decades, software testing developers have developed the Model-based testing technique.The technology is based on generating test cases from a model (e.g. in UML) instead of manuallywriting test cases. This can make the test process more efficient, which leads to more workcan be done in less time. It can also be seen as an economic benefit for companies where testingis the main area. Model-based testing has good reviews and the theory of the technique is welldocumented in articles, works and books. There are many indications that the technology istheoretically useful in practice, with a very few criticisms of the technology. Despite all this,Model-based testing has not expanded in the IT industry.The purpose of this study is to find out what the reasons could be to the fact that MBTdid not succeed better in the industry. In this thesis, three different MBT tools are used totest and then compare whether the result in practice becomes as the theory describes the technique.The result of the study indicates the opposite direction and many shortcomings regardingModel-based testing come across.

For many companies today, it is highly valuable to collect and analyse data in order to support decision making and functions of various sorts. However, this kind of data-driven approach is seldomly applied to software testing and there is often a lack of verification that the testing performed is relevant to how the system under test is used. Therefore, the aim of this thesis is to investigate the possibility of introducing a data-driven approach to test automation by extracting user behaviour data and curating it to form input for testing. A prestudy was initially conducted in order to collect and assess different data sources for augmenting the testing. After suitable data sources were identified, the required data, including data about user activity in the system, was extracted. This data was then processed and three prototypes where built on top of this data. The first prototype augments the model-based testing by automatically creating models of the most common user behaviour by utilising data mining algorithms. The second prototype tests the most frequent occurring client actions. The last prototype visualises which features of the system are not covered by automated regression testing. The data extracted and analysed in this thesis facilitates the understanding of the behaviour of the users in the system under test. The three prototypes implemented with this data as their foundation can be used to assist other testing methods by visualising test coverage and executing regression tests.