Microarchitecture’s optimizations have increased the performance but lowered the security. Speculative execution is one of the optimizations that was thought to be secure, but it is exploitable to leak information. The problem with these exploits is that there is no easy software defence and many exploits could be unexplored due to it being a fairly recent discovery. This thesis explores a way to find code that is vulnerable to this. The solution to the problem is to use the tool Side Channel Abstract Model Validator (SCAMV) which implements the method Model-Based Testing (MBT). We examine the core CVA6, which is a RISCV Central Processing Unit (CPU). Test cases are generated by program generators and interesting ones are selected by applying an observational model to them. The observational model abstracts side-channel leakage of the microarchitecture. The selected test cases are executed on the platform to validate the used observational models. The results of the test cases showed no indication of modifying the side channels under speculative execution. The results showed that SCAMV can examine timing-based channels. The conclusion is that our findings indicate that the CVA6 core is not vulnerable to speculative cache or timing-based side-channel attacks. / Optimeringar på mikroarkitektur nivåer har ökat prestandan men minskat säkerheten. Spekulativt utförande (speculative execution) är en av de optimeringar som har ansetts vara säkert, men det har visats att det kan utnyttjas för att läcka information. Problemet med dessa sårbarheter är att det inte finns något enkelt mjukvaruförsvar och att många sårbarheter fortfarande kan vara outforskade. Denna avhandling undersöker ett sätt att försöka hitta kod som är sårbar för detta. Lösningen på problemet är att använda verktyget SCAMV som använder sig av metoden Model-Baserad Testning. Vi undersöker CVA6, vilket är en RISCV CPU. Testfall genereras av programgeneratorer och intressanta testfall väljs genom att tillämpa en observationsmodell på dem. Observationsmodellen abstraherar sidokanalläckage i mikroarkitekturen. De valda testprogrammen verkställs på plattformen för att validera de använda observationsmodellerna. Resultatet från testfallen visade ingen indikation på att det går att modifiera sidokanalerna under spekulativt utförande. Resultatet visade att SCAMV kan undersöka tidsbaserade kanaler. Slutsatsen är att våra resultat indikerar att CVA6 inte är sårbar för spekulativa cache eller tidsbaserade sidokanalattacker.

There are some systems (or parts of systems) that are very critical and need especially good test suites to test them. For these critical systems, exhaustive testing may be a good way to test them. Thus, we have implemented two versions of bounded exhaustive search (BES) algorithms in a model-based testing tool called, Modbat. One of the BES versions (BESnL) visits each self-loop in the model only once. The other version (BESL) has no constraint or limitation on the number of time it visits each self-loop. We have then compared the two BES algorithms with each other and with an already implemented algorithm in Modbat called random search (RS). We have run the three mentioned algorithms (BESL, BESnL and RS) on five different models and compared their performance on these models in terms of time, coverage and finding faults. We have found that BESnL is faster than BESL and it can miss some faults that BESL can find. However, BESnL can find errors faster than BESL. BESL has sometimes better performance than BESnL in terms of branch coverage. In terms of other coverage criteria (like state coverage, transition coverage and instruction coverage), both BESL and BESnL has very similar performance. We have also found that running the RS algorithm is, in general, faster than both BES algorithms at generating tests (given the same total number of tests generated) if the model has a clear end state. RS may also be faster at finding faults than the BES algorithms. However, The BES algorithms and the RS algorithm have similar behaviours regarding coverage. Nevertheless, RS can sometimes reach higher coverage faster than the BES algorithms and with a smaller number of tests. / Det finns vissa system (eller delar av system) som är mycket essentiella och som behöver särskilt bra testsviter för att testa dem. För dessa essentiella system kan uttömmande tester vara ett bra sätt att testa dem. Således har vi implementerat två versioner av begränsad uttömmande sökning eller på engelska ”bounded exhuastive search” (BES) algoritmer i ett modellbaserat testverktyg kallat Modbat. En av BES-versionerna (BESnL) besöker varje självslinga i modellen bara en gång. Den andra versionen (BESL) har ingen begränsning av hur många gånger den besöker varje självslinga. Vi har sedan jämfört de två BES-algoritmerna med varandra och med en redan implementerad algoritm i Modbat som kallas slumpmässig sökning eller på engelska ”random search” (RS). Vi har kört de tre nämnda algoritmerna (BESL, BESnL och RS) på fem olika modeller och jämfört deras prestanda på dessa modeller när det gäller tid, täckning (coverage) och att hitta fel. Vi har funnit att BESnL är snabbare än BESL och det kan missa några fel som BESL kan hitta, men BESnL kan hitta fel snabbare än BESL. BESL har ibland bättre prestanda än BESnL när det gäller filialtäckning (branch-coverage). När det gäller andra täckningskriterier (som statlig täckning, övergångstäckning (tranintion-coverage) och instruktionstäckning) har både BESL och BESnL mycket liknande resultat. Vi har också funnit att körning av RS-algoritmen i allmänhet är snabbare än båda BES- algoritmerna vid generering av tester (givet samma totala antal genererade tester) om modellen har ett klart slutläge (end-state). RS kan också vara snabbare att hitta fel än BES-algoritmerna. BES-algoritmerna och RS-algoritmen har dock liknande beteenden när det gäller täckning. RS kan ibland nå högre täckning snabbare än BES-algoritmerna och med ett mindre antal tester.

Detta examensarbete har utförts på uppdrag av Stegia AB. Stegias linjärmotorerprovas i en testbänk innan motorerna skickas till den slutliga kunden. Idag finns ettbehov av en testbänk som skall samla in data från utförda tester, minska risken atttesterna utförs fel, samt att testbänken skall vara lättare att använda för produktionspersonalen.Idag innehåller linjärmotortestet många manuella arbetsmoment,vilket innebär en hög risk för felaktiga resultat utan möjlighet till spårbarhet i testresultatet.Målet med detta arbete är att förenkla det slutliga testet av linjärmotorerför produktionspersonal, samt att minska risken för felaktigt utförda tester genomtestautomatisering. Resultatet presenteras i form av en prototyp som har konstruerats,vars syfte är att förbättra test av linjärmotorerna genom att uppfylla målet atträtt utförda tester görs på motorerna. Resultatet säkerställs genom validering ochutvärdering och analys av den framtagna prototypen. / This diploma work has been carried out on behalf of Stegia AB. Stegia manufacturesand sells linear motors that are tested in a test bench before shipped to thecustomer. Today there is a need for a test bench that collects test results from theperformed tests. The company would like to lower the risk of falsely made tests,and to make the test bench easier for the production staff to use. At this moment,the test of the linear motors is made up of several manual tasks before the test iscompleted. This increases the risk of wrong results because of incorrectly madetests, with no traceability of the results. The goal with this diploma work is to lowerthe risk of incorrect test result by automating the testing process for the productionstaff. The result is presented as a prototype, that should increase the reliability ofthe test result of the motors. The result is then validated and analyzed in this report.

Modern-day vehicles consist of numerous electronic computing devices with accompanying software. Since vehicles are generally classified as safety-critical systems, rigorous testing strategies have to be deployed to ensure correct operation of the embedded software. Testing in an active sense is understood to be the main testing method for software in general. The main characteristic of active testing is that test cases have complete control over the system under test, warranting sequential execution of test cases. To complement active testing a method called passive testing is being researched, where the main benefit compared to active testing is that the evaluation of test cases becomes parallelizable. As passive testing opens up for concurrency, the issue of not recognizing faulty behavior arises. This could be the case when simultaneously testing functions which share an output, and the incorrect behavior of a function is being masked by the correct behavior of another function. To avoid vacuous test results, the evaluation of dependent test cases can be separated. Previous work describes the process of extracting dependencies between test cases from requirement specifications. However, this approach is not suitable when test cases are derived from various artifacts. In this thesis we present a syntax-based approach for dependency discovery between test cases. The approach was evaluated through a case study using integration test cases developed for active hardware-in-the-loop testing at Scania CV. Dependencies between 946 test cases have been extracted and the test cases were grouped into three categories, with 286 test cases being identified as independent. The approach shows some potential for evaluating test cases written for active testing, but the results indicate that using test cases written specifically for passive testing may yield better results. The approach also proved to be useful for finding bugs and deviations in scripts. Thus, the method has proven useful for discovering dependencies from syntax, but the results are strongly dependent on the complexity and commonality of the scripts. / Moderna fordon innehåller åtskilliga elektroniska kontrollenheter med medföljande programvara. Eftersom fordon ofta anses vara säkerhetskritiska system krävs robusta teststrategier av den inbyggda mjukvaran för att säkerställa korrekt drift. Aktiv testning är för nuvarande den vanligaste metoden för att testa mjukvara. Den huvudsakliga egenskapen för aktiv testning är att testfall har total kontroll över systemet som är satt under test, vilket medför sekventiell utvärdering av testfall. För att komplettera aktiv testning undersöks en metod som kallas passiv testning, där den största fördelen gentemot aktiv testning är att utvärderingen av testfall kan ske parallellt. Att utvärdera testfall samtidigt medför dock att felaktigt beteende i mjukvaran potentiellt kan maskeras. Detta kan ske då flera funktioner delar utsignaler, och en funktions felaktiga beteende maskeras av en annan funktions korrekta beteende. För att undvika tomma sanningar som testresultat, kan utvärderingen av testfall som har ett beroende mellan dem separeras. Föregående arbeten inom området beskriver processen för att extrahera beroenden mellan testfall från kravspecifikationer. Denna metod är dock inte lämplig när testfall är baserade på flera olika artefakter. I detta examensarbete presenterar vi en syntaxbaserad metod för att hitta beroenden mellan testfall. Metoden utvärderades genom en fallstudie på Scania CV, där aktiva integrationstestfall för hardware-in-the-loop användes för analys. Beroenden mellan 946 testfall kunde extraheras och testfallen grupperades i tre olika kategorier, där 286 klassificerades som oberoende. Metoden visar potential för att analysera testfall skrivna för aktiv testning, men resultaten indikerar att testfall skrivna specifikt för passiv testning kan generera ett bättre resultat. Ett oväntat men positivt utfall är att metoden i viss grad kan användas för att hitta buggar och avvikelser i skript. Således har metoden visats användbar för att hitta beroenden från syntax, men resultatet beror starkt på skriptens komplexitet och gemensamhet.

Denna rapport beskriver projektet Managing education research data. Utförandet av projektet är en del av kursen TDDD96 - Kandidatprojekt i programvaruutveckling våren 2024. Beställaren av systemet är Lucija Batinovic, doktorand på FUSA (IBL) vid Linköpings universitet. Rapporten behandlar frågeställningarna hur en applikation som tillämpar konceptet Community-augmented meta-analysis (CAMA) kan utvecklas för att maximera kundvärdet, vilka lärdomar som kan dokumenteras från programvaruprojektet som är intressanta till framtida projekt, vilket stöd man kan få genom att skapa och följa upp en systemanatomi samt hur en databas kan utformas för att optimera söktid. Målet med applikationen är att ge en samlad plattform för delning av data från öppen vetenskap kopplad till lärande, en plattform för så kallad Community-augmented meta-analysis. Slutsatsen blev att värde skapades för kunden genom att analysera kundens krav och genom projektgruppens tekniska erfarenheter fylla på med fler krav för att möta kundens verkliga behov. De överförbara lärdomar som kunde dokumenteras var bland annat de processrelaterade erfarenheterna från den agila arbetsmetoden. Systemanatomins betydelse visade sig vara att den medför en förståelse för hur systemet ska fungera samt tydliggör beroenden inomsystemet. Slutligen konstaterades att en metod för att optimera söktiden i en databas kan vara normalisering.

Denna studie undersöker hur AI-genererad kod för automatiserad testning av frontend kan kvalitetssäkras genom att utveckla ett ramverk med riktlinjer. Problematiken med kvalitet och trovärdighet i generativ AI-baserade lösningar belyses, där AI ofta producerar kod med varierande kvalitet och anpassning till den specifika kontexten. Genom en kombination av litteraturstudier och en intervju med expert inom området identifieras centrala kvalitetsaspekter såsom kodens läsbarhet, struktur, dokumentation, och underhållbarhet.  Studiens mål är att framställa ett ramverk som praktiskt kan tillämpas för att granska och säkerställa kvaliteten i AI-genererad kod för automatiserad testning av frontend. Ramverket bygger på en kvalitativ analys av både teoretisk och empirisk data och erbjuder vägledning för hur generativ AI kan användas effektivt inom systemutveckling. Det föreslagna ramverket förväntas underlätta testprocessen och minska kravet på manuell kodgranskning, samtidigt som det adresserar de unika utmaningar som generativ AI medför. Framtida forskning rekommenderas för att validera och vidareutveckla ramverket, med särskild tonvikt på praktisk tillämpning och anpassning till olika organisatoriska behov. / This study examines how AI-generated code for automated frontend testing can be quality assured by developing a framework with specific guidelines. The issue of quality and reliability in generative AI-based solutions is highlighted, as AI often produces code with varying quality and contextual accuracy. Through a combination of literature studies and an interview with an expert in the field, central quality aspects such as code readability, structure, documentation, and maintainability are identified.  The aim of the study is to create a framework that can be practically applied to review and ensure the quality of AI-generated code for automated frontend testing. The framework is based on a qualitative analysis of both theoretical and empirical data and provides guidance on how generative AI can be effectively used in system development. The proposed framework is expected to facilitate the testing process and reduce the need for manual code review while addressing the unique challenges posed by generative AI. Future research is recommended to validate and further develop the framework, with particular emphasis on practical application and adaptation to various organizational needs.

Model-Based Testing has shown tangible benefits in previous research exploring widespread domains. Clearing systems in financial markets however are large software systems in which these approaches rarely have been explored. This paper in particular explores the Model-Based Testing approach using Modbat, a specialized tool based on extended finite-state machines, as a complementary testing approach on software clearing systems at Nasdaq. In particular, the approach is applied to functionalities of the system to test both its ability to find bugs undiscovered by traditional methods, as well as to measure its effectiveness and efficiency in creating reliable coverage in short amounts of time. In this study, we show that the model-based Modbat approach can achieve high code coverage with relatively little effort. 77 % of the production coverage was achieved with very few Modbat test runs. Additionally, only ∼ 9-14 % of the same lines of code, and a fraction of the time were required to achieve these results. From this, we conclude that Model-Based Testing approaches such as Modbat allow for significantly more efficient testing in terms of coverage over time compared to manual approaches. / Modellbaserad testning har visat på konkreta fördelar i tidigare forskning som utforskat omfattande områden. Clearingsystem inom finansmarknader är dock stora programvarusystem där dessa metoder sällan har utforskats. Denna arbete utforskar specifikt modellbaserad testning med användning av Modbat, ett specialiserat verktyg baserat på utökade ändliga automater, som ett kompletterande testningsmetodik för programvarurensningssystem på Nasdaq. Särskilt tillämpas metoden på specifika funktioner i systemet för att testa både dess förmåga att hitta buggar som inte upptäckts av traditionella metoder och att mäta dess effektivitet att skapa pålitlig täckning av kod på kort tid. I denna studie visar jag att den modellbaserade Modbat-metoden kan uppnå hög kodtäckning med relativt lite ansträngning. 77 % av produktionskoden täcktes med mycket få Modbat-testkörningar. Dessutom krävdes endast cirka 9-14 % av samma LOC, och en bråkdel av tiden för att uppnå dessa resultat.

Testning är en nödvändig men kostsam del av mjukvaruutveckling. Test utförs på olika abstraktionsnivåer och kan vara manuella eller automatiserade. På lägsta abstraktionsnivå, enhetsnivå, är automatiserad testning vanligt och relativt okomplicerat, medan systemtester är svårare att automatisera. I synnerhet gäller detta tester på ett grafiskt användargränssnitt (GUI) som kräver speciella verktyg.   Triona vill undersöka möjligheterna att automatisera regressionstester från GUI:t av sin produkt C-Load, en molnbaserad webbtjänst för avtalsbaserad transportbokning.    Det primära syftet med denna fallstudie är att med en anpassad urvalsprocess utvärdera ett möjligt verktyg i förhållande till C-Load-förvaltningens förväntningar på automatiserad GUI testning (AGT) och att utifrån resultatet föreslå hur C-Loadförvaltningen kan gå vidare med val av verktyg för AGT. För att uppfylla syftet användes litteraturstudier, intervjuer och observationer av praktiska test.    Verktyg för GUI-testning kan delas in i tre huvudkategorier: skriptbaserade, modellbaserade och skriptlösa. Baserat på tidigare forskning drogs slutsatsen att ett skriptbaserat verktyg där koden i testskripten skrivs manuell bäst passar C-Loadförvaltningens krav och förutsättningar. Det mest använda verktyget av denna typ, Selenium WebDriver, utvärderades kvalitativt gentemot identifierade krav.    Av tidigare forskning framgår att vanliga utmaningar med skriptbaserade GUI-tester är att arbetsinsatsen för att skapa och underhålla testskript är stor och att testen kan vara opålitliga. Dessa problem framkom också i studiens intervjuer och observationer.   Slutsatsen är att det vore möjligt att automatisera regressionstester av C-Load med hjälp av Selenium Webdriver, och att det på sikt skulle kunna frigöra tid. Initialt krävs dock en omfattande insats för att implementera automatiserade tester i förvaltningen och Selenium Webdriver uppfyller bara delvis C-Load-förvaltningens förväntningar på AGT. C-Load-förvaltningen rekommenderas att utvärdera fler verktyg innan beslut fattas. I en kommande urvalsprocess bör Triona beakta hur väl olika verktyg fungerar i förhållande till moderna webbramverk. / Testing is a necessary but costly part of software development. Tests are performed at different abstraction levels and can be either manual or automated. On the lowest level of abstraction, where unit testing is performed, automated testing is commonplace and relatively uncomplicated, whereas system testing is more difficult to automate. This is especially true for GUI-testing, which requires special tools.      Triona wished to investigate possibilities to automate regression testing of the GUI for its C-load product, which is a Cloud-based web-service for contract-based transport booking.      The purpose of this case study was to evaluate one tool for automated GUI-testing (AGT) against the C-Load team’s expectations on AGT, and based on the result recommend Triona how to proceed in the process of implementing AGT. Literature studies, observations and interviews were conducted to fulfil the purpose.      GUI-testing tools can be classified into three categories: script-based, model-based and scriptless. One conclusion was that a script-based tool, where test scripts are manually coded would best suit Triona’s needs. The most used tool in that category, Selenium WebDriver, was tested and evaluated against requirements.       Prior research shows that common challenges encountered when using script-based GUItests are the workload required to create and maintain test scripts and that the tests can deliver inconsistent or “flaky” results. These challenges were confirmed during our analysis.       Our conclusion is that it is possible to automate C-Load regression tests with Selenium WebDriver, and that it would eventually free up time. However, a considerable effort is initially required to implement automated testing. Selenium Webdriver only partly fulfills the C-Load team’s expectations on AGT. Before a decision is taken, the C-Load team should evaluate more tools. When evaluating tools for AGT, Triona should take note that Selenium Webdriver can be deficient when it comes to testing applications based on modern web frameworks.

A risk is something that can happen and a problem is something that we know will happen or that has already happened. Security testing is used to evaluate a programs security using various methods and risk-based security testing is used to analyze, calculate and correct potential defects or problems in a system.Testing can be very costly and it is the most primary way of removing software defects. Many people focus their testing looking for correct behavior and not deviant behaviors in software, therefore security testing has not been as relevant in traditional testing. It is usually not possible to perform exhaustive testing on a system, instead you must selectively choose tests to conduct. How should the selection of tests be conducted? The study therefore intends to investigate how one can start working with risk-based security testing in development projects in order to prioritize and choose test cases and test methods. The study also aims to answer whether you can get any financial or practical benefits from working with risk-based security testing. To conduct the study a case study was used and to collect data, a document study was used to provide the opportunity to answer the questions. In order to analyze the collected data, a qualitative data analysis method has been used to explain and describe the content with a descriptive research approach. The results of the study provided an example of risk management with different steps one can take to start working on risk-based security testing in existing or new development projects. The study’s conclusion also shows that if you work with risk-based security testing there are practical benefits. For instance, higher quality of the system and economic benefits by finding defects or implementing countermeasures for possible risks at an early stage during the systems development. / En risk är någonting som kan hända och ett problem är någonting som vi vet kommer hända eller som redan har hänt. Säkerhetstest används för att med olika metoder värdera ett programs säkerhet och riskbaserad säkerhetstestning används för att analysera, kalkylera och åtgärda potentiella defekter eller problem i ett system. Testning kan vara väldigt kostnadskrävande och det är det mest primära sättet som används för att ta bort defekter i mjukvaror. Många fokuserar sin testning på att leta efter ett korrekt beteende och inte avvikande beteenden i programvara, därför har säkerhetstestning inte varit så aktuellt i traditionell testning. Det är oftast inte möjligt att utföra uttömmande testning på ett system utan man måste selektivt välja tester, men hur ska selektionen gå till?Studien ämnar därför att undersöka hur man kan börja arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt för att kunna prioritera och välja testfall och testmetoder. Studien ämnar också svara på om man kan få några ekonomiska eller praktiska fördelar av att arbeta med riskbaserad säkerhetstestning.För att genomföra studien gjordes en fallstudie och för att samla in data utfördes en dokumentstudie för att ge möjlighet att besvara frågeställningarna. För att analysera den insamlade data har en kvalitativ dataanalysmetod använts för att med en deskriptiv undersökningsansats kunna djupare förklara och beskriva innehållet. Resultaten från studien har medfört ett riskhanterings exempel med olika steg man kan ta för att börja arbeta med riskbaserad säkerhetstestning i befintliga eller nya utvecklingsprojekt. Studiens slutsats visar också att om man arbetar med riskbaserad säkerhetstestning så finns det praktiska fördelar. Exempelvis högre kvalitet på systemet och ekonomiska fördelar genom att man i ett tidigt skede under systemets utveckling hittar defekter eller implementerar motåtgärder för eventuella risker.

The purpose of this thesis is to examine the wrongfully convicted person’s possibilities for taking investigative measures in his or her own case, in order to apply for post-conviction relief according to 58:2 p.4 of the Swedish Code of Judicial Procedure (SCJP), with a particular focus on preservation of evidence and post-conviction DNA testing. Since the legal requirements for reconsidering the preliminary investigation according to 58:6a SCJP are set high, the convicted is, with very few exceptions, left alone to make his or her own attempt at reinvestigating the case, but without legal right to get access to all the evidential items in the case. This is a huge problem when the convicted would need to let such items get reanalyzed by forensic or scientific experts, in order to exculpate him- or herself, for instance by using the newest DNA technology, which was not available during the preliminary investigation. Hence, there is a great interest in preserving evidence, and in particular “traces” (spår), after the verdict has become legally binding. In this thesis, I argue that evidence, such as “traces”, should be preserved not only in the interest for clearing unsolved crimes in the future, but also for the possibility of a future petition of post-conviction relief - at least if the crime committed was a serious crime. According to my study, it is a common belief among the police, that preservation of evidence called “traces” is unregulated. I argue that The Archives Act, which regulates the general duty of state agencies to preserve official documents, is applicable also regarding these “traces”. Consequently, I propose that all of these types of evidence should be preserved by the agencies. Alternatively, the convicted should be notified by the appropriate agency that the evidence is going to be destroyed and grant him or her a right to request further preservation within a certain time. Moreover, I conclude that there should be a possibility for the convicted to require post-conviction DNA testing in Sweden as exemplified on the federal level in the US, as well as that the legal requirements for reconsidering the preliminary investigation in 58:6a SCJP should be more lenient. Another solution would be to make it possible for the court, according to 58:6b SCJP, to decide upon that the prosecutor should take investigative measures when it can be assumed that it would lead to the reconsideration of the preliminary investigation. If the proposed legislative changes are not taken, at least it should be possible for the prosecutor to take investigative measures, such as initiating the DNA testing, by using the opportunity to partwise reconsideration of the preliminary investigation. / Syftet med denna uppsats är att utreda den oskyldigt dömdes utredningsmöjligheter för att ansöka om resning enligt 58:2 p.4 Rättegångsbalken (RB), med särskilt fokus på bevarande av bevismaterial och begäran om DNA-testning efter lagakraftvunnen dom. Eftersom kravet på förundersökningens återupptagande enligt 58:6a RB ställs högt, är den dömde, med mycket få undantag, lämnad åt att själv vidta utredningsåtgärder, men utan laglig rätt att få tillgång till allt bevismaterial i fallet. Detta är ett stort problem då den dömde skulle behöva få till stånd nya forensiska eller kriminaltekniska analyser på materialet, i syfte att rentvå hen från skuld, genom att exempelvis använda den nyaste DNA-tekniken, som inte fanns tillgänglig vid den ursprungliga förundersökningen. Därför finns det ett starkt intresse av att bevismaterial, främst spår, bevaras efter domen har vunnit laga kraft.  I denna uppsats argumenterar jag för att bevismaterial, såsom spår, inte endast bör bevaras med hänsyn till intresset av att klara upp kalla fall, utan även beträffande möjligheten till framtida ansökan om resning - åtminstone om det brott som begicks var ett allvarligt sådant. Enligt min studie är det en vanlig uppfattning bland polisen att bevarandet av bevismaterial, såsom spår, är oreglerat. Jag argumenterar för att arkivlagen, som reglerar den allmänna skyldigheten för statliga myndigheter att bevara allmänna handlingar, även är tillämplig lag avseende spår. Följaktligen föreslår jag att myndigheter bör bevara alla dessa typer av material. Alternativt borde den dömde underrättas av lämplig myndighet att bevismaterialen ska hävas, och ge hen rätt att begära, inom viss tid, att bevismaterialen ska fortsätta att bevaras. Dessutom konstaterar jag att det bör införas en möjlighet för den dömde att begära ny DNA-testning efter lagakraftvunnen dom i Sverige, likt regleringen på federal nivå i USA, samt att kravet på förundersökningens återupptagande enligt 58:6a RB bör sänkas. En annan lösning skulle vara att göra det möjligt för domstolen i enlighet med 58:6b RB att förelägga åklagaren att vidta viss utredningsåtgärd när det kan antas leda till förundersökningens återupptagande. Om inte dessa förändringar sker bör åklagaren åtminstone ha möjlighet att vidta utredningsåtgärder, som att t.ex. initiera ny DNA-testning, genom att utnyttja möjligheten att delvis återuppta förundersökningen.