-
Notifications
You must be signed in to change notification settings - Fork 0
Waseem et al.
Taxonomy of issues in microservice systems.
The taxonomy of Waseem et al. can be found in M. Waseem, P. Liang, M. Shahin, A. Ahmad, and A. R. Nassab, “On the Nature of Issues in Five Open Source Microservices Systems: An Empirical Study,” in Proceedings of the 25th International Conference on Evaluation and Assessment in Software Engineering, ser. EASE ’21. New York, NY, USA: Association for Computing Machinery, Jun. 2021, pp. 201–210. [Online]. Available: https://dl.acm.org/doi/10.1145/3463274.3463337
| Fault ID | Fault Description | Category | Sub-Category | Type of Issue |
|---|---|---|---|---|
| F1 | Wrong status codes in HTTP responses | Technical Debt | Code Debt | Inconsistent Code |
| F2 | Incorrect password-length validation | Technical Debt | Code Debt | |
| F3 | Overwriting instead of combining results | Technical Debt | Code Debt | |
| F4 | Incorrect null-checks on collections |
Technical Debt | Code Debt | |
| F5 | Incorrect null-checks on Optional objects |
Technical Debt | Code Debt | |
| F6 | Incorrect handling of non-existent routes | Technical Debt | Code Debt | |
| F7 | Index conflict with ConsignPrice objects in database |
Technical Debt | Code Debt | |
| F8 | Missing null-checks leading to an unhandled NullPointerException
|
Technical Debt | Code Debt | |
| F9 | Improper date handling in URL path variables | Technical Debt | Code Debt | |
| F10 | Misuse of java.util.Date constructor |
Technical Debt | Code Debt | |
| F11 | Inconsistent return types in fallback methods | Compilation Issue | Syntax Error | - |
| F12 | Publicly accessible admin paths due to improper security configuration | Security Issue | Authorization | Handling Authorization Header |
| F13 | Invalid endpoint call for empty path variables | Technical Debt | Code Debt | |
| F14 | Incorrect usage of BigDecimal.add
|
Technical Debt | Code Debt | |
| F15 | Improper ordering of security matchers | Security Issue | Authorization | Handling Authorization Header |
| F16 | Insufficient timeout settings | Exception Handling | Communication Exception | Timeout Error |
| F17 | Misconfigured initialization data | Technical Debt | Code Debt | |
| F18 | Comparing travelDate to the wrong field |
Technical Debt | Code Debt | |
| F19 | Reversed logic for cookie validation | Technical Debt | Code Debt | |
| F20 | Missing isEmpty-check on response data |
Technical Debt | Code Debt | |
| F21 | Potentially infinite loop in seat assignment | Technical Debt | Code Debt | |
| F22 | Incorrect status code for missing authorization | Technical Debt | Code Debt | Inconsistent Code |
| F23 | Wrong order of if-conditions |
Technical Debt | Code Debt | |
| F24 | Incorrect HTTP method in HTTP request | Service Execution | Service Communication | HTTP Connection |
| F25 | Comparing enumeration constant to the wrong field | Technical Debt | Code Debt | |
| F26 | Security configuration mismatch | Security Issue | Authorization | Handling Authorization Header |
| F27 | Missing check for UUID in path variable |
Technical Debt | Code Debt |
This fault involves returning an incorrect status code, where the service consistently returns status 1 even when the request fails. This fault closely resembles a classified issue from the replication package by Waseem et al. (issue 259), as both describe the problem of returning incorrect status codes. Consequently, we used the classification of issue 259, which was classified to Technical Debt → Code Debt → Code Smell, as a reference to classify F1. However, the issue type of Code Smell was not a suitable fit for F1 because code smells are typically not considered faults. Instead, since returning a status of 1 for both successful and unsuccessful responses is inconsistent with the beavior of other services (which return 1 for successful and 0 for unsuccessful responses), F1 was classified under Inconsistent Code.
This fault allows users to create shorter passwords than intended and might initially appear to be a Security Issue. However, the underlying cause lies in an incorrect sequence of operations: the password is encrypted before it is checked to ensure it meets the minimum length requirements. Since F2 relates to the incorrect logical order of statements in the source code, it was classified as Code Debt. As none of the existing issue types in this subcategory captured F2, Logic Sequence Error was introduced.
The service overwrites existing data instead of appending to it, resulting in the first service's result being lost. Since the ts-admin-travel-service communicates correctly with the ts-travel-service and ts-travel2-service, F3 could not fit under Service Execution and Communication Issue. As this fault stems from a logical flaw in the service implementation, F3 was placed in Code Debt within Techincal Debt. A new issue type, Data Overwrite Error, was introduced due to the lack of a matching pre-existing issue type.
F4 arises from a null-check with a respository method that never returns null. As this fault results from a logically flawed condition within the source code for this particular service, F4 fits most accurately under Code Debt within Technical Debt. However, as none of the issue types captured F4, Condition Logic Error was introduced to emphasize the incorrect condition in the implementation.
Similar to F4, this fault involves an incorrect null-check with an Optional return type. The underlying problem again lies in the condition logic, so it shares the same custom issue type of Condition Logic Error.
F6 involves a faulty null-check with an object configured to never be null. This fault mirrors F4 and F5 in that it involves a flawed condition logic and, therefore, was placed into Condition Logic Error.
F7 involves incorrectly saving multiple objects to the database with the same index value. Depending on the interpretation of the category, F7 could be related to a Database Issue, as the database is unable to return any entities when repository.findByIndex(0) is invoked. However, considering the existing subcategories within this category, Database Issue is more tailored to issues related to database connection, which is not the case in F7. F7 is more tied to the service implementation failing to verify that the indices of objects are not duplicated before saving them to the database. Therefore, this fault fits most accurately under Code Debt, and the custom issue type of Insufficient Value Validation was introduced, as no preexisting issue type was fitting.
This fault leads to a NullPointerException due to missing null-checks. The taxonomy includes a category specifically tailored to NullPointerException, so F8 could be classified as Exception Handling Issue → Others → NullPointerException. However, it could be argued that the fault stems not from the service failing to handle exceptions properly but rather from the missing check to prevent the exception in the first place. In that case, since null values are insufficiently checked, the fault is classified under the custom issue type Insufficient Value Validation within Technical Debt → Code Debt.
Without appropriate annotations or implementation for manual date transformation, the service fails to convert Date objects to a string in paths, making the URL containing dates dysfunctional. The taxonomy includes a category for broken URLs under Service Execution → Service Communication → Broken URLs, which could be considered a valid fit for F9. However, since the root cause lies in the implementation’s missing annotations or transformation mechanisms, F9 was most accurately classified under Code Debt within Technical Debt. In this case, we assigned the fault to the custom issue type Insufficient Value Validation, as no issue type was an appropriate fit, and since the date variable in the path is not verified to have the correct format.
The constructed date is 1900 years behind the intended time due to improper use of the Date constructor. Since this logically incorrect initialization is part of the service implementation, F10 was most accurately classified under Technical Debt → Code Debt. As the taxonomy did not offer a fitting issue type, the custom issue type of Initialization Error was introduced.
A mismatch between two different data types (HTTPEntity vs. ResponseEntity) leads to a compile-time error that prevents the service from starting. Therefore, F11 was classified under Compilation Issue → Syntax Error.
F12 involves improper handling of security measures, allowing protected endpoints to be accessed without authorization by appending a trailing slash to the URL. Since this fault is security-related, specifically involving authorization management, it was classified as Security Issue → Authorization → Handling Authorization Header.
F13 involves empty strings being passed as variables in a path, generating an invalid request URL. Like F9, F13 could be classified under Service Execution → Service Communication → Broken URLs, as the generated URL is non-functional. However, since the service implementation lacks preventive measures to avoid generating URLs with empty strings, F13 was classified under Technical Debt → Code Debt → Insufficient Value Validation.
F14 ignores the return value of BigDecimal.add, leaving values unmodified. As this fault arises from an oversight in the service implementation, it was classified under Technical Debt → Code Debt. A new issue type, Ignored Return Value, was introduced to address the taxonomy’s lack of fitting issue types for this particular fault.
The incorrect order of antMatchers grants unauthorized access to protected endpoints. Similar to F12, this is an authorization oversight, so the issue type of Handling Authorization Header captures the essence of the fault.
In F16, the service times out due to an insufficient timeout value being configured. As the service executes and returns its expected result when given enough time, the fault is solely related to the timeout and fits most accurately to the issue type Timeout Error within the Category Exception Handling. It is important to note that although Waseem et al. did not explicitly include the issue type Timeout Value in the original taxonomy, this issue type was used within their replication package to assign specific issues.
The service implementation fails to verify whether the string seatNumber is convertible to an integer before performing the conversion, causing a NumberFormatException. As with F7, the custom issue type Insufficient Value Validation applies to this fault.
Using the wrong field within a condition leads to an incorrect comparison and unexpected service behavior. Like F4, F5, and F6, the flawed condition logic is best classified under Condition Logic Error.
The logic for handling cookies is reversed, causing cookie values to be incorrectly assigned to null when a new value should have been generated. Like several prior faults, F19 stems from a logical error within an if-condition of the service. Therefore, the custom issue type Condition Logic Error under Technical Debt → Code Debt most accurately fits the described fault.
F20 involves accessing a list of stations without checking if the list is empty, which triggers an IndexOutOfBoundsException. While this fault could reasonably be classified under the Exception Handling category due to the unhandled exception, it could also be placed under Technical Fault → Code Debt, as the service implementation fails to verify whether the list contains any values before attempting access. As with several prior faults, F20 was assigned to the custom issue type Insufficient Value Validation.
In F21, a while-loop can run indefinitely if all possible seat values are already taken, and random generation yields no new seat. Due to the flawed implementation of the service, which leads to infinite loops that negatively impact its reliability, this fault was classified under Code Debt within Technical Debt. Since none of the existing issue types in this subcategory appropriately describe F21, the issue type Infinite Loop was introduced.
F22 involves incorrectly returning a status code of 403 (Forbidden) when it should be 401 (Unauthorized). Since both status codes are security-related responses, F22 could be classified as a Security Issue. However, depending on the interpretation of Inconsistent Code, it could also be argued that returning an incorrect status code is inconsistent with the established HTTP protocol standard. In this case, F22 was classified under Technical Debt → Code Debt → Inconsistent Code.
F23 arises from the incorrect ordering of if-statements, which prevents more specific conditions from being executed. Similar to F2, the incorrect logical order of statements was most accurately classified under the custom issue type of Logic Sequence Error.
F24 stems from using the incorrect HTTP method (POST instead of DELETE), which is related to the configuration of the HTTP connection. Therefore, this fault is most accurately classified under Service Execution → Service Communication → HTTP Connection.
Similar to F18, F25 arises from an incorrect comparison, where the service compares a SeatClass constant with the number of available seats instead of the ticket’s seatType, presenting a logical misalignment in a conditional statement. Hence, F25 was assigned to the issue type of Condition Logic Error.
An authorization rule is applied to an incorrect endpoint path, making the actual path accessible without restriction. Like F12 and F15, this fault is authorization-related and was most accurately classified as a Security Issue → Authorization → Handling Authorization Header.
F27 arises because the service implementation fails to check that a string is convertible to a UUID, which leads to a NumberFormatException. Although the taxonomy includes an issue type for Wrong use of Universally Unique Identifier (UUID) under Build Issue, the fault occurs at runtime rather than during the build process. Therefore, since the missing check for string validity is an implementation issue, F27 was classified under Technical Debt → Code Debt → Insufficient Value Verification.
- Home
- Test Suite Creation
- Fault Identification
- Fault Classification
- Commit History Analysis
- Dependency of Test Cases and Detected Faults
- Adjustments to the Original Source Code