In this paper we develop a general framework to reason about testing. The difficulty of testing is assessed in terms of the amount of tests that must be applied to determine whether the system is correct or not. Based on this criterion, five testability classes are presented and related. We also explore conditions that enable and disable finite testability, and their relation to testing hypotheses is studied. We measure how far incomplete test suites are from being complete, which allows us to compare and select better incomplete test suites. The complexity of finding that measure, as well as the complexity of finding minimum complete test suites, is identified. Furthermore, we address the reduction of testing problems to each other, that is, we study how the problem of finding test suites to test systems of some kind can be reduced to the problem of finding test suites for another kind of systems. This enables to export testing methods. In order to illustrate how general notions are applied to specific cases, many typical examples from the formal testing techniques domain are presented.

A new model based testing theory built on simulation semantics is presented. At the core of this theory there is an input-output conformance simulation relation (iocos). As a branching semantics iocos can naturally distinguish the context of local choices. We show iocos to be a finer relation than the classic ioco conformance relation. It turns out that iocos is a transitive relation and therefore it can be used both as a conformance relation and a refinement preorder. An alternative characterisation of iocos is provided in terms of testing semantics. Finally we present an algorithm that produces a test suite for any specification. The resulting test suite is sound and exhaustive for the given specification with respect to iocos.

Nowadays, cloud‐native software architectures have a significant relevance due to the speed and agility they provide. These properties lead relevant organizations in different industries, like video streaming (Netflix), car‐sharing (Uber, Cabify), banking (BBVA, HSBC), and governmental agencies (NASA, FBI, CERN, ESA) to heavily rely on cloud‐native software to run their business‐critical applications. Additionally, including fault injection actions in the production infrastructure allows companies to have consistent environments, to improve applications dependability against unexpected failures, to provide better user experience, and to improve the overall system quality. Thus, cloud computing technologies allow development teams to rapidly create complex systems and to continuously deploy them, at a global scale. This work describes Pystol, a novel fault injection platform—represented as a Software Product Line—to analyze the effects caused by a wide spectrum of adverse conditions. Pystol is designed to be executed on top of cloud‐native environments, either in private or public clouds. The proposed architecture shows a way for representing feature models based on Unified Model Language (in short, UML) component diagrams. Furthermore, we present a thorough empirical study carried out in real‐world environments, providing promising results.

Data privacy is one of the biggest challenges facing system architects at the system design stage. Especially when certain laws, such as the General Data Protection Regulation (GDPR), have to be complied with by cloud environments. In this article, we want to help cloud providers comply with the GDPR by proposing a GDPR-compliant cloud architecture. To do this, we use model-driven engineering techniques to design cloud architecture and analyze cloud interactions. In particular, we develop a complete framework, called MDCT, which includes a Unified Modeling Language profile that allows us to define specific cloud scenarios and profile validation to ensure that certain required properties are met. The validation process is implemented through the Object Constraint Language (OCL) rules, which allow us to describe the constraints in these models. To comply with many GDPR articles, the proposed cloud architecture considers data privacy and data tracking, enabling safe and secure data management and tracking in the context of the cloud. For this purpose, sticky policies associated with the data are incorporated to define permission for third parties to access the data and track instances of data access. As a result, a cloud architecture designed with MDCT contains a set of OCL rules to validate it as a GDPR-compliant cloud architecture. Our tool models key GDPR points such as user consent/withdrawal, the purpose of access, and data transparency and auditing, and considers data privacy and data tracking with the help of sticky policies.