-
Notifications
You must be signed in to change notification settings - Fork 0
Silva et al.
Taxonomy of faults in microservice systems and their association with non-functional attributes.
The taxonomy of Silva et al. can be found in: F. Silva, V. Lelli, I. Santos, and R. Andrade, “Towards a Fault Taxonomy for Microservices-Based Applications,” in Proceedings of the XXXVI Brazilian Symposium on Software Engineering, ser. SBES ’22. New York, NY, USA: Association for Computing Machinery, Oct. 2022, pp. 247–256. [Online]. Available: https://doi.org/10.1145/3555228.3555245
| Fault ID | Fault Description | Silva et al. Sub-Category | Fault | Characteristic |
|---|---|---|---|---|
| F1 | Wrong status codes in HTTP responses | Analysability | Maintainability | |
| F2 | Incorrect password-length validation | Confidentiality | Security | |
| F3 | Overwriting instead of combining results | Functional Completeness | Internal Fault | Implementation |
| F4 | Incorrect null-checks on collections |
Functional Completeness | Internal Fault | Implementation |
| F5 | Incorrect null-checks on Optional objects |
Functional Completeness | Internal Fault | Implementation |
| F6 | Incorrect handling of non-existent routes | Functional Completeness | Internal Fault | Implementation |
| F7 | Index conflict with ConsignPrice objects in database |
Integrity | Not Validating Input/Data | Security |
| F8 | Missing null-checks leading to an unhandled NullPointerException
|
Functional Completeness | Internal Fault | Implementation |
| F9 | Improper date handling in URL path variables | Functional Completeness | Internal Fault | Implementation |
| F10 | Misuse of java.util.Date constructor |
Functional Completeness | Internal Fault | Implementation |
| F11 | Inconsistent return types in fallback methods | Analysability | Maintainability | |
| F12 | Publicly accessible admin paths due to improper security configuration | Authenticity | Security | |
| F13 | Invalid endpoint call for empty path variables | Analysability | Invalid Request Data Fault | Maintainability |
| F14 | Incorrect usage of BigDecimal.add
|
Functional Completeness | Internal Fault | Implementation |
| F15 | Improper ordering of security matchers | Authenticity | Security | |
| F16 | Insufficient timeout settings | Temporal Behavior | Long Response Time | Service Discovery |
| F17 | Misconfigured initialization data | Integrity | Not Validating Input/Data | Security |
| F18 | Comparing travelDate to the wrong field |
Functional Completeness | Internal Fault | Implementation |
| F19 | Reversed logic for cookie validation | Functional Completeness | Internal Fault | Implementation |
| F20 | Missing isEmpty-check on response data |
Integrity | Not Validating Input/Data | Security |
| F21 | Potentially infinite loop in seat assignment | Functional Completeness | Internal Fault | Implementation |
| F22 | Incorrect status code for missing authorization | Analysability | Maintainability | |
| F23 | Wrong order of if-conditions |
Functional Completeness | Internal Fault | Implementation |
| F24 | Incorrect HTTP method in HTTP request | Analysability | Invalid Request Data Fault | Maintainability |
| F25 | Comparing enumeration constant to the wrong field | Functional Completeness | Internal Fault | Implementation |
| F26 | Security configuration mismatch | Authenticity | Security | |
| F27 | Missing check for UUID in path variable |
Integrity | Not Validating Input/Data | Security |
F1: Analysability & Maintainability → $${\color{magenta}Invalid \space Response \space Data \space Fault}$$
This fault involves returning an incorrect status code, where the service consistently returns status 1 even when the request fails. This fault resembles the "Invalid Request Data Fault" but instead of invalid request data, our fault has invalid response data. Therefore, we introduce a new category "Invalid Response Data Fault" to this subcategory.
F2: Confidentiality & Security → $${\color{magenta}Insufficient \space Credentials \space Accepted}$$
This fault allows users to create shorter passwords than intended and results in a Security Issue. However, it does not fully fit any of the existing fault types, which is why we add a new fault type here.
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, it is an internal fault within the ts-admin-travel-service.
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 "Internal Fault".
Similar to F4, this fault involves an incorrect null-check with an Optional return type. This is again in the internal implementation of a single service and, therefore, fits the "Internal Fault" within the taxonomy.
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 inside a single service and, therefore, was placed into "Internal Fault".
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 the "Data Storage" characteristic. However, all fault types under this characteristic are of the category of performance faults, which does not fit this fault example. As the underlying problem of this fault is that the database or the implementation does not validate the input and, therefore, stores multiple objects with the same index, it fits the Integrity → Not Validating Input/Data fault type.
This fault is again a fault within a single service → Internal Fault.
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 fault types for invalid or missing user input or request data. However, in this case, the request data is valid, but only the service can not correctly interpret or transform the data for its further processing. Therefore, it is an "Internal Fault" within this service.
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 internal service implementation, F10 was most accurately classified under Functional Completeness & Implementation → Internal Fault.
A mismatch between two different data types (HTTPEntity vs. ResponseEntity) in the response of a service is similar to fault F1. Therefore, F11 was classified under Analysability & Maintainability →
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, it was classified as a security fault. None of the existing fault types fits perfectly. The fault type "Missing authorization" is the closest fit but as the authorization is not completely missing but only faulty on our case, we introduce a new fault type here.
F13 involves empty strings being passed as variables in a path, which is invalid request data.
F14 ignores the return value of BigDecimal.add, leaving values unmodified. As this fault arises from an oversight in the internal service implementation, it was classified under "Internal Fault".
The incorrect order of antMatchers grants unauthorized access to protected endpoints. Similar to F12, this is a faulty authorization, so the new fault type "Faulty Authorization" fits best.
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 fault type "Long Response Type Fault".
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 fault type Not Validating Input/Data applies to this fault.
Using the wrong field within a condition leads to an incorrect comparison and unexpected internal service behavior.
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 a single service.
F20 involves accessing a list of stations without checking if the list is empty, which triggers an IndexOutOfBoundsException. As the service implementation fails to validate whether the list contains any values before attempting access, F20 was assigned to "Not Validating Input/Data".
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 internal implementation of the service, the fault was assigned to the "Internal Fault" type.
F22: Analysability & Maintainability → $${\color{magenta}Invalid \space Response \space Data \space Fault}$$
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, returning a wrong response code does not directly influence the security of a service or system. Instead, the service is returning invalid response data (similar to F1) and is therefore assigned the newly created "Invalid Response Data Fault" type.
F23 arises from the incorrect ordering of if-statements, which prevents more specific conditions from being executed. This was most accurately classified under the fault type of "Internal Fault".
F24 stems from using the incorrect HTTP method (POST instead of DELETE), which is related to the configuration of the HTTP request. Therefore, this fault is most accurately classified under "Invalid Request Data Fault".
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 service internal fault. Hence, F25 was assigned to the fault type "Internal Fault".
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 "Faulty Authorization".
F27 arises because the service implementation fails to check that a string is convertible to a UUID, which leads to a NumberFormatException. Similarly to F20, this is classified as "Not Validating Input/Data".
- Home
- Test Suite Creation
- Fault Identification
- Fault Classification
- Commit History Analysis
- Dependency of Test Cases and Detected Faults
- Adjustments to the Original Source Code