Existing software product line (SPL) engineering testing approaches generally provide positive testing that validates the SPL’s functionality. Negative testing is commonly neglected. This research aims to unify behavioral and feature models of an SPL, enable testing before and after variability binding for domain-centric and product-centric testing, and combine positive and negative testing for a holistic testing view. This study suggests behavioral modeling with event sequence graphs (ESGs). This heterogeneous modeling strategy supports bottom-up domain testing and top-down product testing with the feature model. This new feature-oriented ESG test creation method generates shorter test sequences than the original ESG optimum test sequences. Statechart and original ESG test-generating methods are compared. Positive testing findings are similar. The Statechart technique generated 12 test cases with 59 events, whereas the ESG technique created six test cases with 60 events. The ESG technique generated 205 negative test cases with 858 events with the Test Suite Designer tool. However, the Conformiq Designer tool for the Statechart technique does not have a negative test case generation capability. It is shown that the proposed ESG-based holistic approach confirms not only the desirable (positive) properties but also the undesirable (negative) ones. As an additional research, the traditional ESG test-generating approach is compared to the new feature-oriented method on six SPLs of different sizes and features. Our case study results show that the traditional ESG test generation approach demonstrated higher positive test generation scores compare to the proposed feature-oriented test generation approach. However, our proposed feature-oriented test generation approach is capable of generating shorter test sequences, which could be beneficial for reducing the execution time of test cases compared to traditional ESG approach. Finally, our case study has also shown that regardless of the test generation approach, there has been found no significant difference between the Bottom-up and Top-down test strategies with respect to their positive test generation scores.

In dynamic and resource-constrained Tactical Edge Network (TEN) environments, where Denied, Disrupted, Intermittent, and Limited Impact (DDIL) conditions prevail, a tailored security approach is vital for real-time decision-making. In this paper, we propose adapting the Zero Trust (ZT) security paradigm to suit TEN settings, focusing on strict access controls, continuous entity verification, and unauthorized access mitigation. Our solution introduces a risk-based ZT scale approach, aligning security measures with scenario-associated risk levels while minimizing resource usage. We employ a Bayesian Network (BN) model to evaluate communication request risk, considering potential attacks. Our experiments confirm the effectiveness and adaptability of our approach in ensuring secure and efficient operations in these challenging environments.

Collaborative Drone systems (CDS) have the potential to benefit a variety of application areas such as agriculture, military operations, surveillance, and disaster response. At the same time, CDS can pose challenges due to their limited flight time impacted by battery capacities, and constrained edge computation capabilities on-board the drones. Furthermore, an understudied subject relates to when drones in a CDS trust each other to accomplish a task, resulting in new vulnerabilities that can be exploited via cyber attacks. In this paper, we propose a novel trust quantification methodology in a CDS with intelligence-driven edge routing, which can help detect malicious nodes in a CDS that compromise communication and disrupt the functionality of packet forwarding. Our approach for trust quantification is guided by a CDS vulnerability analysis that characterizes impact due to the presence of two malicious threat agents viz., flooder node and faker node. Detection of these threat agents in a CDS is aided by trust quantification in the form of trust scores obtained by using a Bayesian Network model that allows for decision-making on CDS nodes’ trust levels. We validate our trust quantification methodology in ns-3 based simulation experiments and show how we can categorize nodes based on different thresholds of trust scores with varying sensitivities, which helps in the detection of CDS threat agents.

Change impact analysis evaluates the changes that are made in the software and finds the ripple effects, in other words, finds the affected software components. Code changes and bug fixes can have a high impact on code quality by introducing new vulnerabilities or increasing their severity. A recent high-visibility example of this is the code changes in the log4j web software CVE-2021-45105 to fix known vulnerabilities by removing and adding method called change types. This bug fix process exposed further code security concerns. In this article, we analyze the most common set of bug fix change patterns to have a better understanding of the distribution of software changes and their impact on code quality. To achieve this, we implemented a tool that compares two versions of the code and extracts the changes that have been made. Then, we investigated how these changes are related to change impact analysis. In our case study, we identified the change types for bug-inducing and bug fix changes using the Quixbugs dataset. Furthermore, we used 13 of the projects and 621 bugs from Defects4J to identify the common change types in bug fixes. Then, to find the change types that cause an impact on the software, we performed an impact analysis on a subset of projects and bugs of Defects4J. The results have shown that, on average, 90% of the bug fix change types are adding a new method declaration and changing the method body. Then, we investigated if these changes cause an impact or a ripple effect in the software by performing a Markov chain-based change impact analysis. The results show that the bug fix changes had only impact rates within a range of 0.4–5%. Furthermore, we performed a statistical correlation analysis to find if any of the bug fixes have a significant correlation with the impact of change. The results have shown that there is a negative correlation between caused impact with the change types adding new method declaration and changing method body. On the other hand, we found that there is a positive correlation between caused impact and changing the field type.

Code changes are one of the essential processes of software evolution. These changes are performed to fix bugs, improve quality of software, and provide a better user experience. However, such changes made in code could lead to ripple effects that can cause unwanted behavior. To prevent such issues occurring after code changes, code change prediction, change impact analysis techniques are used. The proposed approach uses static call information, forward slicing, and method change information to build a Markov chain, which provides a prediction for code changes in the near future commits. For static call information, we utilized and compared call graph and effect graph. We performed an evaluation on five open-source projects from GitHub that varies between 5K-26K lines of code. To measure the effectiveness of our proposed approach, recall, precision, and f-measure metrics have been used on five open-source projects. The results show that the Markov chain that is based on call graph can have higher precision compared to effect graph. On the other hand, for small number of cases higher recall values are obtained with effect graph compared to call graph. With a Markov chain model based on call graph and effect graph, we can achieve recall values between 98%-100%.

The test case prioritization (TCP) problem is defined as determining an execution order of test cases so that important tests are executed early. Different metrics have been proposed to measure importance of test cases. While coverage and fault-detection based measures have benefits and have been used in a lot of studies, mutation kill-based measures have emerged in TCP recently, since they have benefits addressing issues with other approaches. Moreover, in the TCP problem, finding the optimal solution has a complexity of the factorial of the number of test cases, making meta-heuristic algorithms a highly suitable approach. In this study, we propose an end-to-end pipeline for TCP, Mutation Kill-based Evolutionary Algorithm (MuKEA-TCP), which allows users to have fast and efficient TCP results from existing source code, or directly from the mutant kill report of a system, without the need for any coverage information or real faults. An evolutionary algorithm utilizing Average Percentage Mutant Killed (APMK) as the objective function augmented with a local search procedure enhancing is used in MuKEA-TCP. We performed our case study on five open-source Java projects, in which we compared the APMK values of the final TCP results of some well-known greedy algorithms, and MuKEA-TCP using different initialization methods. Our results have shown that providing additional method as an initial input to the proposed augmented evolutionary algorithm has improved the results and outperformed other methods for our case study. Findings of this study have shown that using an evolutionary algorithm augmented with local search with mutation kill-based APMK as the objective function enhances the commonly used greedy prioritization methods, with a minor execution time trade-off.

Change impact analysis analyzes the changes that are made in the software and finds the ripple effects, in other words, finds the affected software components. In this study, we analyze the bug fix change patterns to have a better understanding of what types of changes are common in fixing bugs. To achieve this, we implemented a tool that compares two versions of codes and detects the changes that are made. Then, we investigated how these changes are related to change impact analysis. In our case study, we used 13 of the projects and 621 bugs from Defects4J to identify the common change types in bug fixed. Then, to find the change types related to cause an impact in the software, we performed an impact analysis on a subset of projects and bugs of Defects4J. The results have shown that, on average, 90% of the bug fix change types are adding a new method declaration and changing the method body. Then, we investigated if these changes cause an impact or a ripple effect in the software by performing a Markov chain-based change impact analysis. The results show that the bug fix changes had only impact rates within a range of 0.4%-5%. Furthermore, we performed a statistical correlation analysis to find if any of the bug fixes have a significant correlation on the impact of change. The results have shown that there is a negative correlation between caused impact with the change types adding new method declaration and changing method body. On the other hand, we found that there is a positive correlation between caused impact and changing the field type.

Change impact analysis plays an important role in identifying potential affected areas that are caused by changes that are made in a software. Most of the existing change impact analysis techniques are based on architectural design and change history. However, source code-based change impact analysis studies are very few and they have shown higher precision in their results. In this study, a static method-granularity level change impact analysis, that uses program slicing and Bayesian Network technique has been proposed. The technique proposes a directed graph model that also represents the call dependencies between methods. In this study, an open source Java project with 8999 to 9445 lines of code and from 505 to 528 methods have been analyzed through 32 commits it went. Recall and f-measure metrics have been used for evaluation of the precision of the proposed method, where each software commit has been analyzed separately.