Comparative analysis of methods for testing web applications

The aim of the study was to conduct a comparative analysis of testing approaches for web applications in the two most popular architectures: monolithic and microservices. For the purpose of the study, the server-side of the application (backend) was implemented twice with identical functionalities for each of these architectures, allowing for a precise comparison of testing differences for the same program capabilities. The results revealed that the monolithic application was easier and faster to test. However, the microservices architecture requires more energy spent on testing, but allows better scalability and elasticity for independent teams to develop applications. Each of the examined architectures certainly has its own advantages and drawbacks. Furthermore, the conducted research indicates that unit tests require significantly less time to execute. However, when it comes to comprehensive code analysis, integration tests outperform unit tests by covering a substantial portion of the application's code with a single test. Nonetheless, the best comprehensive code analysis and protection against unwanted functional changes can be achieved by employing all known types of tests

Testing-based process for component substitutability

Software components have emerged to ease the assembly of software systems. However, updates of systems by substitution or upgrades of components demand careful management due to stability risks of deployed systems. Replacement components must be properly evaluated to identify if they provide the expected behaviour affected by substitution. To address this problem, this paper proposes a substitutability assessment process in which the regular compatibility analysis is complemented with the use of black-box testing criteria. The purpose is to observe the components' behaviour by analysing their internal functions of data transformation, which fulfils the observability testing metric. The approach is conceptually based on the technique Back-to-Back testing. When a component should be replaced, a specific Test Suite TS is built in order to represent its behavioural facets, viz. a Component Behaviour TS. This TS is later exercised on candidate upgrades or replacement components with the purpose of identifying the required compatibility. Automation of the process is supported through the testooj tool, which constrains the conditions and steps of the whole process in order to provide a rigorous and reliable approach.Fil: Flores, Andrés Pablo. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Patagonia Confluencia; ArgentinaFil: Polo, Macario. Universidad de Castilla-La Mancha; Españ

Komponentenbasierte Überwachung hybrider Systeme durch den Einsatz formaler Methoden

Die vorliegende Arbeit beschäftigt sich mit der Entwicklung eines neuen Verfahrens zum nahtlosen Komponentenentwurf und zur Systemüberwachung durch ein einheitliches Modell, das die Anforderungen der Entwicklung von komplexen dynamischen Systemen erfüllt und somit einen Beitrag zum Entwurf verlässlicher Systeme leistet. Hierfür wird die komponentenbasierte Design-Methodologie KobrA eingesetzt, weil diese eine schrittweise Komponentenzerlegung auf verschiedenen Abstraktionsebenen und Sichten durchführt. Sie beinhaltet sowohl „Top-down“-Elemente als auch „Bottom-up“-Ansätze, die für eine effiziente prototypische Systemrealisierung geeignet sind. Mit der Entwicklung eines formalen echtzeitfähigen Überwachungs- und Fehlererkennungsmechanismus wird die KobrA-Methode durch eine formale Modellierungssprache erweitert, welche sowohl für die Softwareentwickler als auch für die Ingenieure verständlich sein soll. Aus diesem Grund sollte diese Sprache eine eindeutige und streng definierte Semantik besitzen. Die einheitliche Beschreibung der Systemkomponenten sowie der Überwachungskomponenten durch denselben formalen Sprachmittel ermöglicht die systematische Einbettung der Überwachung über den gesamten Entwicklungsprozess und dessen Ausführung während des Betriebs. Petri-Netze gehören zur Graphentheorie und zählen seit mehreren Jahren zu den mächtigsten Spezifikationswerkzeugen in verschiedenen Gebieten. Sie erlauben die Beschreibung des Komponentenverhaltens durch ein Netzwerk, bestehend aus Knoten und aus Bedingungen für den Datenfluss zwischen diesen Knoten. Wesentliche Vorteile von Petri-Netzen sind zum einen ihre formale mathematische Formulierung, die auf einem soliden theoretischen Fundament beruht, sowie zum anderen die explizite Abbildung des Prozesszustandes über ein Markierungskonzept. Petri-Netze ermöglichen zusätzlich die Darstellung sequentieller, sich gegenseitig ausschließender sowie paralleler Aktivitäten, die Modellierung und Visualisierung von Systemverhalten sowie die Nebenläufigkeit und die Synchronisation von kooperativen Prozessen. In dieser Arbeit erfolgt die Verhaltensbeschreibung der Überwachungskomponenten durch eine neue Klasse von Petri-Netzen, so genannte „Modifizierte Partikel Petri-Netze“ (engl., Modified Particle Petri Nets „MPPN“). Diese Netzklasse beinhaltet hybride Petri-Netze für die Modellierung des hybriden Systemverhaltens und einen Partikelfilter als probabilistische Erweiterung, um die Überwachung als Tracking-Problem aufzufassen. Petri-Netze bieten eine vollständige und konsistente Beschreibung der Prozesse, die graphische Anschauung sowie Simulation und Animation als Testmöglichkeit bereits während der Entwurfsphase. Die Kombination aus KobrA-Beschreibungsformalismus und Petri-Netzen erlaubt eine anschauliche, modular und hierarchisch strukturierte Modellierung, direkt in einer formalen Sprache. Durch unterstützende Werkzeuge, die im Rahmen dieser Arbeit entwickelt sind, kann die Realisierung der Überwachungskomponente direkt aus der Spezifikation generiert werden. Hierfür wird das Petri-Netzmodell in ein textuelles kompaktes XML-Austauschformat (engl., „Extensible Markup Language“) transformiert, welche sich an dem PNML-Standard (engl., „Petri Net Markup Language“) orientiert. Diese generische Vorlage enthält das Komponentenverhalten und die für den Überwachungsprozess notwendigen Parameter. Der besondere Aspekt für den Einsatz derselben formalen Methode, nämlich die Petri-Netze, sowohl für die Spezifikation als auch für die Realisierung, beruht auf zwei Zielen. Das primäre Ziel ist, ein einheitliches verständliches Ausdrucksmittel für die Entwurfsphase eines Systems zu stellen, mit dem alle Aspekte des ausgewählten Abstraktionsniveaus unmissverständlich dargestellt werden können. Denn Spezifikationsdokumente in natürlichen Sprachen sind anfällig für Missverständnisse, während formale Spezifikationen auf mathematischen Beschreibungen und eindeutiger Semantik und Syntaxen basieren. Das sekundäre Ziel ist eine formale überprüfbare Spezifikation (mittels eines Simulationswerkzeuges) als solide Basis für die Realisierungsphase zu bilden. Denn eine automatisch verifikationsbasierte Systementwicklung stellt eine Möglichkeit zur Erhöhung der Systemverlässlichkeit dar. Die andere Möglichkeit basiert auf der Robustheit des Überwachungsverfahrens während der Betriebsphase

Component Integration through Built-In Contract Testing

This chapter describes a technology and methodology referred to as built-in contract testing that checks the pairwise interactions of components in component-based software construction at integration and deployment time. Such pairwise interactions are also referred to as contracts. Built-in contract testing is based on building test functionality into components, in particular tester components on the client side and testing interfaces on the server side of a pairwise contract. Since building test software into components has implications for the overall component-based development process, the technology is integrated with and made to supplement the entire development cycle starting from requirements specification activities and modeling. The chapter outlines typical specification concepts that are important for built-in contract testing, provides a guide on how to devise built-in contract testing artifacts on the basis of models, and discusses issued involved in using this approach with contemporary component technologies