3,160 research outputs found
Extending Peass to Detect Performance Changes of Apache Tomcat
New application versions may contain source code changes that decrease the application’s performance. To ensure sufficient performance, it is necessary to identify these code changes. Peass is a performance analysis tool using performance measurements of unit tests to achieve that goal for Java applications. However, it can only be utilized for Java applications that are built using the tools Apache Maven or Gradle. This thesis provides a plugin for Peass that enables it to analyze applications built with Apache Ant.
Peass utilizes the frameworks Kieker and KoPeMe to record the execution traces and measure the response times of unit tests. This results in the following tasks for the Peass-Ant plugin: (1) Add Kieker and KoPeMe as dependencies and (2) Execute transformed unit tests. For the first task, our plugin programmatically resolves the transitive dependencies of Kieker and KoPeMe and modifies the XML buildfiles of the application under test. For the second task, the plugin orchestrates the process that surrounds test execution—implementing performance optimizations for the analysis of applications with large codebases—and executes specific Ant commands that prepare and start test execution. To make our plugin work, we additionally improved Peass and Kieker. Therefore, we implemented three enhancements and identified twelve bugs.
We evaluated the Peass-Ant plugin by conducting a case study on 200 commits of the open-source project Apache Tomcat. We detected 14 commits with 57 unit tests that contain performance changes. Our subsequent root cause analysis identified nine source code changes that we assigned to three clusters of source code changes known to cause performance changes.:1. Introduction
1.1. Motivation
1.2. Objectives
1.3. Organization
2. Foundations
2.1. Performance Measurement in Java
2.2. Peass
2.3. Apache Ant
2.4. Apache Tomcat
3. Architecture of the Plugin
3.1. Requirements
3.2. Component Structure
3.3. Integrated Class Structure of Peass and the Plugin
3.4. Build Modification Tasks for Tomcat
4. Implementation
4.1. Changes in Peass
4.2. Changes in Kieker and Kieker-Source-Instrumentation
4.3. Buildfile Modification of the Plugin
4.4. Test Execution of the Plugin
5. Evaluative Case Study
5.1. Setup of the Case Study
5.2. Results of the Case Study
5.3. Performance Optimizations for Ant Applications
6. Related Work
6.1. Performance Analysis Tools
6.2. Test Selection and Test Prioritization Tools
6.3. Empirical Studies on Performance Bugs and Regressions
7. Conclusion and Future Work
7.1. Conclusion
7.2. Future WorkNeue Versionen einer Applikation können Quelltextänderungen enthalten, die die Performance der Applikation verschlechtern. Um eine ausreichende Performance sicherzustellen, ist es notwendig, diese Quelltextänderungen zu identifizieren. Peass ist ein Performance-Analyse-Tool, das die Performance von Unit-Tests misst, um dieses Ziel für Java-Applikationen zu erreichen. Allerdings kann es nur für Java-Applikationen verwendet werden, die eines der Build-Tools Apache Maven oder Gradle nutzen. In dieser Arbeit wird ein Plugin für Peass entwickelt, das es ermöglicht, mit Peass Applikationen zu analysieren, die das Build-Tool Apache Ant nutzen.
Peass verwendet die Frameworks Kieker und KoPeMe, um Ausführungs-Traces von Unit-Tests aufzuzeichnen und Antwortzeiten von Unit-Tests zu messen. Daraus resultieren folgende Aufgaben für das Peass-Ant-Plugin: (1) Kieker und KoPeMe als Abhängigkeiten hinzufügen und (2) Transformierte Unit-Tests ausführen. Für die erste Aufgabe löst das Plugin programmbasiert die transitiven Abhängigkeiten von Kieker und KoPeMe auf und modifiziert die XML-Build-Dateien der zu testenden Applikation. Für die zweite Aufgabe steuert das Plugin den Prozess, der die Testausführung umgibt, und führt spezielle Ant-Kommandos aus, die die Testausführung vorbereiten und starten. Dabei implementiert es Performanceoptimierungen, um auch Applikationen mit einer großen Codebasis analysieren zu können. Um die Lauffähigkeit des Plugins sicherzustellen, wurden zusätzlich Verbesserungen an Peass und Kieker vorgenommen. Dabei wurden drei Erweiterungen implementiert und zwölf Bugs identifiziert.
Um das Peass-Ant-Plugin zu bewerten, wurde eine Fallstudie mit 200 Commits des Open-Source-Projekts Apache Tomcat durchgeführt. Dabei wurden 14 Commits mit 57 Unit-Tests erkannt, die Performanceänderungen enthalten. Unsere anschließende Ursachenanalyse identifizierte neun verursachende Quelltextänderungen. Diese wurden drei Clustern von Quelltextänderungen zugeordnet, von denen bekannt ist, dass sie eine Veränderung der Performance verursachen.:1. Introduction
1.1. Motivation
1.2. Objectives
1.3. Organization
2. Foundations
2.1. Performance Measurement in Java
2.2. Peass
2.3. Apache Ant
2.4. Apache Tomcat
3. Architecture of the Plugin
3.1. Requirements
3.2. Component Structure
3.3. Integrated Class Structure of Peass and the Plugin
3.4. Build Modification Tasks for Tomcat
4. Implementation
4.1. Changes in Peass
4.2. Changes in Kieker and Kieker-Source-Instrumentation
4.3. Buildfile Modification of the Plugin
4.4. Test Execution of the Plugin
5. Evaluative Case Study
5.1. Setup of the Case Study
5.2. Results of the Case Study
5.3. Performance Optimizations for Ant Applications
6. Related Work
6.1. Performance Analysis Tools
6.2. Test Selection and Test Prioritization Tools
6.3. Empirical Studies on Performance Bugs and Regressions
7. Conclusion and Future Work
7.1. Conclusion
7.2. Future Wor
Optimization of Implementation of Crane Certification in Contruction Service Companies
Purpose: This study aims to analyze the effect of accelerating the implementation of work and the costs needed for the job of occupational safety and health certification in the Construction services company in East Java province.
Design/methodology/approach: This study used a survey method carried out on 20 crane units in 4 construction service companies by analyzing data using Critical Path Method (CPM), resulting in an acceleration of inspection and testing of crane up to 37% with cost efficiency of 36 %.
Findings: The results of this study are expected to provide an overview of Crane's reliability as early as possible to users to anticipate operational failures through regular maintenance and repairs.
Research limitations/implications: This study can also determine the timing of inspection and testing in the context of implementing the Crane Occupational Safety and Health certification so that the use of resources can be optimized.
Practical implications: With the implementation of inspection and testing, certification can be fulfilled before the certification period ends.
Originality/value: This paper is original
Paper type: Research pape
Recommended from our members
Making Software More Reliable by Uncovering Hidden Dependencies
As software grows in size and complexity, it also becomes more interdependent. Multiple internal components often share state and data. Whether these dependencies are intentional or not, we have found that their mismanagement often poses several challenges to testing. This thesis seeks to make it easier to create reliable software by making testing more efficient and more effective through explicit knowledge of these hidden dependencies.
The first problem that this thesis addresses, reducing testing time, directly impacts the day-to-day work of every software developer. The frequency with which code can be built (compiled, tested, and package) directly impacts the productivity of developers: longer build times mean a longer wait before determining if a change to the application being build was successful. We have discovered that in the case of some languages, such as Java, the vast majority of build time is spent running tests. Therefore, it's incredibly important to focus on approaches to accelerating testing, while simultaneously making sure that we do not inadvertently cause tests to erratically fail (i.e. become flaky).
Typical techniques for accelerating tests (like running only a subset of them, or running them in parallel) often can't be applied soundly, since there may be hidden dependencies between tests. While we might think that each test should be independent (i.e. that a test's outcome isn't influenced by the execution of another test), we and others have found many examples in real software projects where tests truly have these dependencies: some tests require others to run first, or else their outcome will change. Previous work has shown that these dependencies are often complicated, unintentional, and hidden from developers. We have built several systems, VMVM and ElectricTest, that detect different sorts of dependencies between tests and use that information to soundly reduce testing time by several orders of magnitude.
In our first approach, Unit Test Virtualization, we reduce the overhead of isolating each unit test with a lightweight, virtualization-like container, preventing these dependencies from manifesting. Our realization of Unit Test Virtualization for Java, VMVM eliminates the need to run each test in its own process, reducing test suite execution time by an average of 62% in our evaluation (compared to execution time when running each test in its own process).
However, not all test suites isolate their tests: in some, dependencies are allowed to occur between tests. In these cases, common test acceleration techniques such as test selection or test parallelization are unsound in the absence of dependency information. When dependencies go unnoticed, tests can unexpectedly fail when executed out of order, causing unreliable builds. Our second approach, ElectricTest, soundly identifies data dependencies between test cases, allowing for sound test acceleration.
To enable more broad use of general dependency information for testing and other analyses, we created Phosphor, the first and only portable and performant dynamic taint tracking system for the JVM. Dynamic taint tracking is a form of data flow analysis that applies labels to variables, and tracks all other variables derived from those tagged variables, propagating those tags. Taint tracking has many applications to software engineering and software testing, and in addition to our own work, researchers across the world are using Phosphor to build their own systems. Towards making testing more effective, we also created Pebbles, which makes it easy for developers to specify data-related test oracles on mobile devices by thinking in terms of high level objects such as emails, notes or pictures
Early aspects: aspect-oriented requirements engineering and architecture design
This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications
Flaky Test Sanitisation via On-the-Fly Assumption Inference for Tests with Network Dependencies
Flaky tests cause significant problems as they can interrupt automated build
processes that rely on all tests succeeding and undermine the trustworthiness
of tests. Numerous causes of test flakiness have been identified, and program
analyses exist to detect such tests. Typically, these methods produce advice to
developers on how to refactor tests in order to make test outcomes
deterministic. We argue that one source of flakiness is the lack of assumptions
that precisely describe under which circumstances a test is meaningful. We
devise a sanitisation technique that can isolate f laky tests quickly by
inferring such assumptions on-the-fly, allowing automated builds to proceed as
flaky tests are ignored. We demonstrate this approach for Java and Groovy
programs by implementing it as extensions for three popular testing frameworks
(JUnit4, JUnit5 and Spock) that can transparently inject the inferred
assumptions. If JUnit5 is used, those extensions can be deployed without
refactoring project source code. We demonstrate and evaluate the utility of our
approach using a set of six popular real-world programs, addressing known test
flakiness issues in these programs caused by dependencies of tests on network
availability. We find that our method effectively sanitises failures induced by
network connectivity problems with high precision and recall.Comment: to appear at IEEE International Working Conference on Source Code
Analysis and Manipulation (SCAM
RETORCH: Resource-Aware End-to-End Test Orchestration
12th International Conference, QUATIC 2019, Ciudad Real, Spain, September 11–13, 2019Continuous integration practices introduce incremental changes in the code to both improve the quality and add new functionality. These changes can introduce faults that can be timely detected through continuous testing by automating the test cases and re-executing them at each code change. However, re-executing all test cases at each change may not be always feasible, especially for those test cases that make heavy use of resources thoroughly like End-to-End test cases that need a complex test infrastructure. This paper is focused on optimizing the usage of the resources employed during End-to-End testing (e.g., storage, memory, web servers or tables of a database, among others) through a resource-aware test orchestration technique in the context of continuous integration in the cloud. In order to optimize both the cost/usage of resources and the execution time, the approach proposes to (i) identify the resources required by the End-to-End test cases, (ii) group together those tests that need the same resources, (iii) deploy the tests in both dependency isolated and elastic environments, and (iv) schedule their parallel execution in several machine
- …