-
Notifications
You must be signed in to change notification settings - Fork 0
Zhou et al.
Classification of faults into their into Root Causes (Internal, Interaction, and Environment,) and Influence (Functional, and Non-Functional).
The classification of Zhou et al. can be found in X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding, “Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study,” IEEE Transactions on Software Engineering, vol. 47, no. 2, pp. 243–260, Feb. 2021, conference Name: IEEE Transactions on Software Engineering. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/8580420
| Functional | Non-Functional | |
|---|---|---|
| Internal | F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F14, F17, F18, F19, F20, F21, F22, F23, F25, F27 | |
| Interaction | F13, F24 | F12, F15, F26, F16 |
| Environment |
We classified most faults in the TrainTicket system as functional-internal. These faults manifest within a single microservice and directly affect its correct behavior. For instance, F5 involves incorrect null-checks on methods returning an Optional type. This incorrect check leads to unexpected behavior (e.g., the service returns an unsuccessful response when it should be successful), so the fault is functional. Moreover, as the failure underlying this fault can be replicated by executing the service in isolation, F5 has an internal root cause.
Some incorrect results are produced not due to a bug within a single service but due to improper coordination between services. For example, F24 consistently produces status 405 (Method Not Allowed), as the coordination between the ts rebook-service and the ts-order-service is incorrectly configured to target the HTTP method POST for an endpoint in the ts-order-service that should actually be a DELETE. The fault is functional (it always results in the wrong outcome) but also rooted to interaction, as it involves incorrect coordination of multiple services.
Most non-functional-interaction faults incorrectly allow protected endpoints to be accessed without requiring authorization. These faults could be considered as functional faults since the expected status 401 (Unauthorized) or 403 (Forbidden) is never triggered. However, given that these faults are security related, which is considered as a non-functional requirement, and because the service logic itself is correctly implemented without the context of authorization, they are most accurately classified as non-functional faults. Furthermore, as these faults manifest when other services invoke the fault-containing services, their root cause is interaction-related.
Apart from authorization issues, F16 is a timeout-related fault that also falls under non-functional-interaction-faults. While it could be argued that F16 is a functional fault as it generates an error where a successful response is expected, the core functionality of either service is correctly implemented and yields a correct response when given enough time to complete its execution. Consequently, F16 is most accurately described as non-functional. Finally, as the fault could either be resolved by increasing the specified timeout value in the controller classes or by increasing the performance of its dependent services, F16 is deemed an interaction fault.
- Home
- Test Suite Creation
- Fault Identification
- Fault Classification
- Commit History Analysis
- Dependency of Test Cases and Detected Faults
- Adjustments to the Original Source Code