Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Uma abordagem de teste estrutural de integração par-a-par para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir na interface entre os pares de unidades que se relacionam em um programa. Para programas OO este tipo de teste envolve testar a interação entre os pares de métodos. Já para programas OA, o teste estrutural de integração par-a-par envolve testar a interação entre os seguintes pares de unidades: método-método, método-adendo, adendo-método e adendo-adendo. Para efetuar o teste estrutural de integração par-a-par deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre a unidade chamadora e a unidade chamada. Para isso é definido o grafo Def-Uso Par-a-Par (PWDU) que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e da unidade chamada. Além disso, são propostos três critérios para derivar requisitos de teste para pares de unidades. Dentre eles, dois critérios são baseados em fluxo de controle: todos-nós-integrados e todas-arestas-integradas; e um critério é baseado em fluxo de dados: todos-usos-integrados. Uma ferramenta que apóia o teste estrutural de unidade de programas OO e OA escritos em Java e AspectJ, chamada JaBUTi/AJ, foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos de usos são discutidos para explicar a aplicação da abordagem / A pairwise integration structural testing approach for OO and AO programs implemented with Java and AspectJ is presented. The purpose of this approach is to find faults that may exist in the interface between the pairs of units that relate in a program. For OO programs this type of testing involves testing the interaction among pair of methods. For AO programs, the pairwise integration structural testing involves testing the interaction among the following pairs of units: method-method, method-advice, advice-method and advice-advice. To perform the pairwise integration structural testing, all the execution flow (control and data flow) that happens between the caller and the called unit must be considered. For this, it is defined the PairWise Def-Use graph (PWDU) that is an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller and called unit. Additionally, three new criteria to derive test requirements for pairs of units are proposed. Amongst them, two criteria are based on control flow: all-integrated-nodes and all-integrated-edges; and one criterion is based on data flow: all-integrated-uses. A tool that supports unit structural testing of OO and AO programs implemented with Java and AspectJ, called JaBUTi/AJ, was extended in order to support the proposed integration testing approach. Examples are discussed in order to explain the application of the approach

All developers understand the benefits of testing their code to ensure its functionality. Today’s market is moving further towards design principles where testing is a central or driving force during development. This puts a certain pressure on academia to supply these skills to their students.Recently the course II1302 Projects and project methods at the Royal Institute of Technology in Kista made a concerted effort to introduce the students of the course to these modern concepts. This thesis investigates how areas of testing can effectively be introduced to the students in the course, utilizing a tailored example that takes the area of testing into particular consideration and how to automate it via DevOps-tools provided by a cloud-based service. Further, it also makes an attempt to provide additional material to be used for teaching testing in conjunction with the example provided.The case study covers the development of an example application, meant to mirror a typical student project. It also covers how this was used for teaching the students about the testing areas considered. The covered testing areas include unit testing, integration testing and UI testing. With these given testing areas, the application and an associated learning module was developed for each area in question. Relevant standards, strategies and approaches was also identified for each of these areas.The thesis also presents important properties to take into consideration when developing similar examples in the future, based on the experiences obtained during the study. These include needs such as understandable by inexperienced students, applicability outside the course, adherence to established standards, tools that are simple to use and an architectural structure that allows for testing.Some improvements are also recommended: the students would benefit from learning software testing from an early stage of their studies. The content of the learning modules should also be brought to the students earlier in the course, so it can be applied in their projects at an early stage as well.Further research is also recommended to evaluate the suitability of using other cloud-based environments instead, and to evaluate the applicability of the learning modules for students of varying disabilities. / Alla utvecklare förstår fördelarna med att testa kod för att garantera dess funktionalitet. Dagens industri går i en riktning där testning spelar en central del av design under utveckling av mjukvara. Denna tendens lägger en viss press på högskolan att lära ut dessa erfarenheter till dess studenter.På senare tid har kursen II1302 Projekt och projektmetoder på Kungliga Tekniska Högskolan i Kista tagit en stor ansats för att introducera sina studenter inför dessa moderna koncept. Denna uppsats undersöker hur testningsområdet effektivt kan introduceras till studenterna inom denna kurs, genom att utnyttja ett egengjort exempel som har området i fokus, samt att automatisera detta via DevOps-verktyg tillhandahållna av molnbaserade tjänster. Dessutom görs även en ansats för att tilldela ytterligare material som kan användas för att lära ut testning av mjukvara i samband med det givna exemplet.Fallstudien omfattar utvecklingen av en exempelapplikation, som var avsedd att likna ett typiskt studentprojekt. Den täcker även hur denna användes för att lära ut de betraktade testningsområdena till studenterna. De täckta områdena av testning inkluderar enhetstestning, integrationstestning och testning av användargränssnitt. Med dessa givna testningsområden utvecklades både applikationen och dess associerade lärmoduler för vardera testningområde i fråga. Relevanta standarder, strategier och metoder var också identifierade för vardera av dessa områden.Denna uppsats presenterar även ett antal viktiga egenskaper att hålla i åtanke vid utveckling av liknande exempel i framtiden, baserat på erfarenheterna från studien. Detta inkluderar behov som tillgänglighet för mindre erfarna studenter, applicerbarhet utanför själva kursen, tillämpning av etablerade standarder, utnyttjande av lättanvända verktyg och en arkitektur som tillåter testning.Några förbättringar föreslås även: studenterna skulle gynnas av att lära sig om mjukvarutestning i ett tidigt skede av sina studier. Innehållet i lärmodulerna bör även presenteras för studenterna tidigare i kursen för att kunna appliceras i deras projekt.Ytterligare forskning rekommenderas även för att utvärdera andra lämpliga molnbaserade miljöer, samt för att utvärdera tillämpbarheten av lärmodulerna hos studenter med inlärningssvårigheter.

Electronic Control Unit (ECU) is a crucial component in today’s vehicle. In a complete vehicle, there are many ECUs installed. Each of these controls a single function of the vehicle. During the development cycle of an ECU, its functionality needs to be validated against the requirement specification. The Hardware-in-the-loop (HIL) method is commonly used to do this by testing the ECU in a virtual representation of its controlled system. One crucial part of the HIL testing method is an intermediary component that acts as a bridge between the simulation computer and the ECU under test. This component runs a parameterized real-time system that translates messages from the simulation computer to the ECU under test and vice versa. It has a strict real-time requirement for each of its tasks to complete.A logging and monitoring system is needed to ensure that the intermediary component is functioning correctly. This functionality is implemented in the form of low priority additional tasks that run concurrently with the high priority message translation tasks. The implementation of these tasks, alongside with a distributed system to support the logging and monitoring functionality, is presented in this thesis work.Several execution time measurements are carried out to get the information on how the parameters of a task affect its execution time. Then, the linear regression analysis is used to model the execution time estimation of the parameterized tasks. Finally, the time demand analysis is utilized to provide a guarantee that the system is schedulable. / Elektronisk styrenhet (ECU) är en viktig del i dagens fordon. I ett komplett fordon finns det många ECU installerade. Var och en av dessa kontrollerar en enda funktion hos fordonet. Under en utvecklingscykel för en ecu måste dess funktionalitet valideras mot kravspecifikationen. HIL-metoden (Hardware-in-the-loop) används vanligtvis för att göra detta genom att testa ECU i en virtuell representation av sitt styrda system. En viktig del av HIL-testmetoden är en mellanliggande komponent som fungerar som en bro mellan simuleringsdatorn och den ecu som testas. Denna komponent driver ett parametrerat realtidssystem som översätter meddelanden från simuleringsdatorn till ECU som testas och vice versa. Det har en strikt realtidskrav för att alla uppgifter ska kunna slutföras.Ett loggnings och övervakningssystem behövs för att den mellanliggande komponenten ska fungera korrekt. Denna funktionalitet är implementerad i form av extraordinära uppgifter med låg prioritet som körs samtidigt med de högsta prioritetsuppgifterna för översättningstjänster. Genomförandet av dessa uppgifter, tillsammans med ett distribuerat system för att stödja loggnings och övervakningsfunktionaliteten, presenteras i detta avhandlingararbete.Flera utförandetidsmätningar utförs för att få information om hur parametrarna för en uppgift påverkar dess körtid. Därefter används den linjära regressionsanalysen för att modellera exekveringstidestimeringen av de parametrerade uppgifterna. Slutligen används tidsanalysanalysen för att garantera att systemet är schemaläggbart.

This thesis examines integration testing of object-oriented software. The process of integrating and testing procedural programs is reviewed as foundation for testing object-oriented software. The complexity of object-oriented software is examined. The relationship of integration testing and the software development life cycle is presented. Scenarios are discussed which account for the introduction of defects into the software. The Unified Modeling Language (UML) is chosen for representing pre-implementation and post-implementation models of the software. A demonstration of the technique of using post-implementation models representing the logical and physical views as an aid in integration and system testing of the software is presented. The use of UML diagrams developed from the software is suggested as a technique for integration testing of object-oriented software. The need for automating the data collection and model building is recognized. The technique is integrated into the Revised Spiral Model for Object-Oriented Software Development developed by du Plessis and van der Walt. / Computing / D.Phil. (Computer Science)

This thesis examines integration testing of object-oriented software. The process of integrating and testing procedural programs is reviewed as foundation for testing object-oriented software. The complexity of object-oriented software is examined. The relationship of integration testing and the software development life cycle is presented. Scenarios are discussed which account for the introduction of defects into the software. The Unified Modeling Language (UML) is chosen for representing pre-implementation and post-implementation models of the software. A demonstration of the technique of using post-implementation models representing the logical and physical views as an aid in integration and system testing of the software is presented. The use of UML diagrams developed from the software is suggested as a technique for integration testing of object-oriented software. The need for automating the data collection and model building is recognized. The technique is integrated into the Revised Spiral Model for Object-Oriented Software Development developed by du Plessis and van der Walt. / Computing / D.Phil. (Computer Science)