6.

0 System Testing:-
Testing is a crucial phase in the software development life cycle, ensuring
the quality, reliability, and effectiveness of the attack detection system. Given the
complex interplay of Genetic Algorithms, Machine Learning, Deep Learning, and
network infrastructure components. Testing is a cornerstone of any robust software
development lifecycle, especially for critical security systems. This chapter outlines the
rigorous testing methodologies applied to validate the DoS and Probe attack detection
system, ensuring its functionality, performance, and reliability across various operational
scenarios and integrations. It ensures the system's reliability, efficiency, and accuracy in
identifying malicious activities. For systems leveraging advanced machine learning and
genetic algorithms within a Software-Defined Networking environment, testing must be
comprehensive, covering various layers and functionalities. This chapter outlines the key
testing phases to validate the system's performance and robustness The Testing chapter
rigorously validates the effectiveness of the proposed system for detecting DoS and Probe
attacks. It outlines the test environment, typically a simulated network or controlled
setting, using benchmark datasets. Testing encompasses Unit Testing for individual
modules, Integration Testing to ensure seamless component interaction, and
comprehensive System Testing of the entire intrusion detection framework. Functional
Testing specifically verifies the system's ability to accurately identify various attack
types, including DoS and Probe, leveraging the optimized features selected by GAs.
Performance is rigorously evaluated using standard metrics such as Accuracy, Precision,
Recall, and F1-score, derived from confusion matrix parameters True Positives, False
Positives, True Negatives, and False Negatives. The primary objective is to achieve a
high Detection Rate (DR) and a low False Alarm Rate (FAR), demonstrating the
robustness and reliability of the GA-enhanced detection model against contemporary
network threats.

6.1 Test Environments:-

The document indicates that studies used various datasets for evaluating AI models.
Common datasets mentioned or inferred include:
 UNSW-NB 15
 Ransomware samples from Android applications
 Bot-IoT dataset from Cyber Range Lab
 CICIDS2017
 KDDCUP99, ISCX, NSL-KDD (though these are noted as outdated)
 IoT application dataset
 Modbus Network Traffic
 ICS datasets
  IoT network-traffic (Simulation)DBN
 UGR16
The review suggests a need for updated datasets from real-world, real-time IoT systems
for better evaluation.

6.6 Results:-
The results section summarizes the findings from the reviewed studies
regarding the performance of various AI models in detecting cybersecurity attacks.
 Overall Performance: AI models have produced satisfactory results in detecting
IoT cybersecurity threats.
 Commonly Used Methods: Support Vector Machines (SVM) and Random Forest
(RF) are among the most used methods, largely due to their high accuracy
detection and efficient memory usage.
 Other High-Performing Methods: Extreme Gradient Boosting (XGBoost),
Neural Networks (NN), and Recurrent Neural Networks (RNN) also demonstrate
good performance.
 Performance Metrics: AI models are evaluated using metrics such as accuracy
(ACC), precision (PRE), recall (REC), and f-measure (F1).
 DoS Attack Detection: AI detection models using CNN, RNN, and SVM have
been proposed to detect DoS attacks in IoT Botnets datasets.
 Probe Attack Detection: An IDS model based on Genetic Algorithm (GA) and
Deep Belief Network (DBN) has been proposed to achieve a high detection rate
for probe attacks.
 Limitations: Despite successes, limitations include long training times and high
computational complexity, and the use of outdated datasets
 Accuracy Scores: Both initial and final accuracy scores are presented for all
algorithms (K-Nearest Neighbours, Decision Tree, Support Vector Machine,
Logistic Regression, Random Forest, Naïve Bayes). The final accuracy score is
higher after optimization or refinement.
 Final Accuracy Scores (from Table 2):
 K-Nearest Neighbours: 99.89  Logistic Regression: 99.88
 Decision Tree: 99.88  Random Forest: 99.92
 Support Vector Machine: 99.91  Naïve Bayes: 99.78
  Comparison of Accuracy Scores: A graphical comparison of the final accuracy
scores shows that Random Forest achieved the highest accuracy among the
tested algorithms, followed closely by Support Vector Machine.
 Confusion Matrices: Confusion matrices are provided for each algorithm,
illustrating the True Positives, True Negatives, False Positives, and False
Negatives.
 Precision, Recall, F1-Score: These metrics are calculated for each algorithm.
o Precision, Recall, F1-Score for Random Forest (as an example from
Table 3, assuming it's the best):
 Precision: 0.9992
 Recall: 0.9992
 F1-Score: 0.9992
 ROC Curves: Receiver Operating Characteristic (ROC) curves are plotted for
each algorithm, along with a comparative ROC curve, demonstrating their
performance in distinguishing between normal and anomalous connections.
The results indicate that Random Forest provided the highest accuracy, making it a
strong candidate for robust cyber-attack prediction within the framework of data science
techniques.
Chapter 6: Testing
This chapter serves to thoroughly validate the developed system, ensuring it meets the
specified requirements and performs robustly. It moves from individual component
verification to comprehensive system validation.

6.1 Introduction to Testing:-

 Purpose of Testing: Briefly explain why testing is vital for your project.
Emphasize early bug detection, improved code quality, and reduced costs in the
long run.
 Testing Levels: Introduce the different levels of testing that will be performed
(Unit, Integration, System, Acceptance) and how they contribute to the overall
quality assurance.
 Testing Methodologies: Mention the primary testing methodologies you'll
employ (e.g., White-box testing, Black-box testing) and their relevance to your
project. For a genetic algorithm, white-box testing of the algorithm's internal logic
is paramount, while black-box testing will validate its output (attack detection).
The testing was conducted using the NSL-KDD dataset, a widely recognized
benchmark dataset for network intrusion detection. This dataset contains both normal
network traffic and various types of attacks, including DoS and Probe attacks. The dataset
was split into training and testing sets to ensure an unbiased evaluation of the models'
performance on unseen data. The implementation environment was Python, implying that
testing was conducted within a Python-based development setup.

6.2 Unit Testing of Modules

Unit testing is the first and most granular level of Software testing. It focuses
on individual components or "units" of your software in isolation to ensure each part
functions correctly according to its design specifications. For a project involving GA for
attack detection, this section is particularly important due to the algorithmic complexity
and the need for precision in each component.
Why Unit Test for DoS/Probe Attack Detection using GA?
 Our Project involves a Genetic Algorithm (GA) for detecting multiple types of
DoS and Probe attacks in networks. This means you have to use several distinct
components on various levels like, data pre-processing, feature extraction, the GA itself
(encoding, fitness function, selection, crossover, mutation), and the
classification/detection module. Each of these components can and should be a functional
part or an activities of unit tested.
Here's a detailed explanation of why unit testing is crucial for our project:

Early Bug Detection:- It catch defects at earliest stage, reducing cost and effort of fixing
them later. Complex systems AI, ML, DL where errors can cascade, early detection is
paramount. Test-Driven Development (TDD) is a powerful method for early bug
detection. By writing tests before you write the code for your GA components or data
processing, you define the expected behaviour upfront, which are drives cleaner more
correct implementations.

Data Pre-processing Bugs: Imagine a bug in your data normalization function incorrect
scaling, updating, measuring, handling of missing of entered data values. If undetected,
this bug would silently propagate through your feature extraction, GA, and classification,
leading to a poorly performing or completely broken attack detection system. A unit test
for your normalize_data() function asserting that normalized values fall within a specific
range, or that NaNs are handled as expected) would catch this immediately.

Feature Extraction Errors: If your feature extraction logic for network traffic
calculating packet size entropy, connection duration contains an error, the GA will be
optimizing based on flawed input, leading to suboptimal or incorrect attack signatures.
Unit tests for each feature calculation calculate_entropy (packet_stream) should return a
predictable value for a known stream are vital.

GA Component Failures: A bug in your GA's selection mechanism,

tournament_selection not picking the best individuals), crossover two_point_crossover
producing invalid chromosomes, or mutation bit_flip_mutation not actually flipping bits
would prevent the GA from converging or finding effective attack signatures. Unit tests
can verify the correctness of these operations with small, controlled inputs.

Benefits and Advantages of Unit Testing:-

 Detecting problems early in the development cycle—unit testing helps in identifying
bugs and issues at an early stage of the software development cycle. This early detection
is crucial as it allows for issues to be addressed before they escalate into more complex
problems in later stages of development.
 Reducing costs—by catching bugs early, unit testing can significantly reduce the cost of
bug fixes. It is generally more expensive to fix bugs in later stages of development or
after the software has been deployed.
 Promoting test-driven development—unit testing is a core component of TDD, where
tests are written before the actual code. This approach ensures that the codebase is
designed to pass the tests, leading to better structured, more reliable, and easier to
maintain code.
 Enabling more frequent releases—with a comprehensive suite of unit tests, developers
can make changes to the code with more confidence. This reduces the risks associated
with new releases, thereby allowing for more frequent updates and improvements to the
software.
 Enabling code refactoring—unit tests provide a safety net that allows developers to
refactor code with confidence. Knowing that changes can be quickly tested to ensure they
don’t break existing functionality encourages improving and optimizing the code without
fear of introducing bugs.
 Detecting changes that break a design contract—unit tests can help in identifying
changes in the code that may violate the intended design or contract of a system. This
ensures that individual components of the software work as expected and in harmony
with each other.
 Reducing uncertainty—with a robust unit testing process, developers gain confidence in
the quality and functionality of their code. This reduces uncertainty and guesswork,
especially when making changes or adding new features.
Documenting system behaviour—unit tests can serve as a form of documentation for
the system. By reading the tests, other developers can understand what a particular piece
of code is supposed to do, which is especially useful for on boarding new team members
or for reference in future development.

Improved Code Quality:- Ensures each module is well-designed, self-contained, and

performs its intended function accurately.
Modularity:- It inherently encourages breaking down your attack detection system into
smaller, manageable units. For instance, instead of one monolithic function for "GA-
based detection," you'd have separate units for:
 initialize_population()
 calculate_fitness(individual, network_data)
 select_parents(population, fitness_scores)
 perform_crossover(parent1, parent2)
 apply_mutation(individual)
 classify_traffic(signature, traffic_features)
Each of these units can be tested independently, ensuring it does "one thing and does it
well" (Single Responsibility Principle). This makes the code easier to understand, debug,
and maintain.
Accuracy: Unit tests provide concrete examples of how each function should behave. For
example, a unit test for your calculate_fitness function would take a specific GA
individual (representing a potential attack signature) and a small, known set of network
traffic data (including DoS/Probe examples) and assert that the fitness score calculated is
within an expected range or matches a precise value.

Latest Techniques/Methods: Adhering to the "Arrange-Act-Assert" (AAA) pattern for

writing tests, where you first set up the test environment (Arrange), then execute the code
under test (Act), and finally verify the outcome (Assert). This structure promotes clear
and readable tests.

Facilitates Refactoring:- Provides a safety net, allowing developers to refactor code

confidently, knowing that existing functionality is preserved.
GA Optimization: As you experiment with different GA parameters, encoding schemes,
or fitness functions to improve attack detection accuracy, you will frequently refactor
your GA-related code. Without unit tests, such changes are risky, as they might
inadvertently introduce regressions breaking previously working functionality.
Algorithm Swaps: You might decide to try different machine learning classifiers in your
detection module switching from a simple thresholding mechanism to an SVM or a small
neural network trained on GA-generated features. A robust suite of unit tests for the
input/output of your classification module ensures that the new algorithm integrates
correctly and produces expected outputs for various traffic scenarios normal, DoS, Probe.
Data Structure Changes: If you optimize your data structures for storing network traffic
or GA individuals, unit tests will immediately flag any broken dependencies, giving you
confidence that your refactoring hasn't disrupted core logic.
Latest Techniques/Methods: Continuous Integration CI pipelines, where unit tests are
automatically run every time code is committed, are essential for leveraging this benefit.
If a refactoring breaks a test, the CI pipeline will fail, alerting developers immediately.

Aids Documentation:- Unit tests serve as living documentation, illustrating how each
component is supposed to be used and what its expected behaviour is. In understanding
GA logic Unit tests for your crossover function test_two_point_
crossover_produces_valid_off spring immediately clarifies the intended behaviour and
expected outputs for various parent inputs. It is often more up-to-date and practical than
separate written documentation. Attack Signature Representation can show specific valid
and invalid chromosome structures and how interpreted by the calculate_fitness function.
Input/Output Contracts It inputs a function expects and outputs it produce. A test for your
preprocess_network_log function show what format the raw log be in and processed,
feature-extracted output look like. Techniques/Methods: Well-named tests using clear,
descriptive names (e.g., test_fitness_function_for_known_dos_pattern) greatly enhance
their documentation value.

Promotes Modularity:- Encourages the development of loosely coupled, highly cohesive

modules, which are easier to maintain and extend. Decoupling Components is a
component in isolation, it often requires "mocking" or "stubbing" its dependencies. Test
your calculate_fitness function, you wouldn't want it to rely on a live network traffic feed.
Instead, you'd provide mock network data. This forces you to design your components to
be less dependent on each other, leading to a more modular and robust architecture.
o Easier Experimentation: If your attack detection system is highly
modular, you can easily swap out different GA operators or even entirely
different optimization algorithms (e.g., Particle Swarm Optimization
instead of GA) without affecting other parts of the system, provided they
adhere to the same interfaces.
o Scalability: Modular code is inherently more scalable, as individual
components can be developed, tested, and potentially deployed
independently.
 Latest Techniques/Methods: Using mocking libraries (e.g., [Link] in
Python, Mockito in Java) helps enforce and test for loose coupling.
Isolation of Faults:-
Brief: When a test fails, it points directly to the problematic unit, simplifying debugging.
 Exact Details & Relevance to Your Project:
o Pinpointing Errors: Instead of debugging a large, integrated system
where an attack detection failure could be due to issues in data collection,
preprocessing, feature engineering, GA convergence, or classification, a
failing unit test immediately tells you which specific component is at fault.
If test_mutation_rate_is_applied_correctly fails, you know exactly where
to look.
o Reduced Debugging Time: For complex GA-based systems, where the
"black box" nature of evolutionary algorithms can make debugging
challenging, unit tests are a lifesaver. They narrow down the search space
for bugs significantly.
 o Faster Iteration: Quick identification and fixing of bugs enable a faster
development cycle for your attack detection system.
 Latest Techniques/Methods: Clear error messages from your testing framework
(e.g., Python's pytest, unittest) guide you directly to the source of the problem.

6.2.1 Definition and Importance of Unit Testing

 What is a Unit? Clearly define what constitutes a "unit" in your project's context.
For "Detection of Attacks (DoS, Probe) using Genetic Algorithms," units could
include:
o Functions for data pre-processing (normalization, feature extraction).
o Individual components of the Genetic Algorithm (GA) itself:
 Initialization of population.
 Fitness function calculation.
 Selection mechanism (e.g., roulette wheel, tournament selection).
 Crossover operations.
 Mutation operations.
o Modules for attack classification based on GA output.
o Modules for generating and managing network traffic data (for
simulation).
o Modules for parsing and interpreting network logs (if used).
 Why Unit Test?
o Early Bug Detection: Catch defects at the earliest stage, reducing the cost
and effort of fixing them later.
o Improved Code Quality: Ensures each module is well-designed, self-
contained, and performs its intended function accurately.
o Facilitates Refactoring: Provides a safety net, allowing developers to
refactor code confidently, knowing that existing functionality is preserved.
o Aids Documentation: Unit tests serve as living documentation,
illustrating how each component is supposed to be used and what its
expected behaviour is.
 o Promotes Modularity: Encourages the development of loosely coupled,
highly cohesive modules, which are easier to maintain and extend.
o Isolation of Faults: When a test fails, it points directly to the problematic
unit, simplifying debugging.

6.2.2 Unit Testing Strategy and Methodology for Genetic Algorithms

Given the nature of Genetic Algorithms, unit testing presents unique challenges due to
their inherent randomness and iterative nature. Your strategy should address this:

 White-Box Testing Focus: While black-box principles apply, unit testing of a

GA heavily relies on white-box techniques to verify the internal logic of each GA
component.
 Deterministic vs. Non-Deterministic Components:
o Deterministic Components: For parts of your code that are deterministic
(e.g., data pre-processing, feature extraction, initial population generation
if using a fixed seed), traditional unit testing with fixed inputs and
expected outputs is straightforward.
o Non-Deterministic Components (GA Core): This is where it gets tricky.

 Seed Control: To make GA components testable, provide a mechanism to

set a fixed random seed for testing purposes. This ensures reproducibility
of "random" operations (e.g., initial population generation, mutation
points, and crossover points).
 Test Small, Isolated Logic: Break down complex GA operations into
smaller, testable functions. For example:
 Test the logic for a single crossover operation with specific parent
chromosomes.
 Test the logic for a single mutation operation on a given chromosome.
 Test the selection function with a known population and their fitness
scores.
 Statistical Validation (for aggregate behaviour): While
individual random events aren't predictable, the distribution of
outcomes over many runs can be. For example, test that:
 The mutation rate is applied approximately as expected
over a large number of mutations.
 The selection mechanism, over many trials, favours
individuals with higher fitness.
 Mocking Dependencies: If GA components rely on external
services (e.g., a network traffic simulator or a database for attack
patterns), use mocking to simulate their behaviour and isolate the
unit under test.
 Test-Driven Development (TDD) (Optional but Recommended): Explain if
TDD was employed, where tests are written before the code, guiding the
development process and ensuring testability from the start.

6.2.3 Unit Test Cases for "Detection of Attacks (DoS, Probe) using Genetic
Algorithms".
Provide concrete examples of unit test cases for various modules.
Example Modules and Test Cases:
2. Data Preprocessing Module:
o Function: normalize_features(data_point)
  Test Case 1: Input: data_point = [10, 100, 1000], Expected Output:
Normalized values (e.g., using Min-Max scaling, output [0.0, 0.1,
1.0] if min=0, max=1000).
 Test Case 2: Input: data_point with missing values (if applicable),
Expected Output: Error handling or appropriate imputation.
o Function: extract_features(raw_packet_data)
 Test Case 1: Input: Sample raw packet data (e.g., source IP, destination
IP, packet size, protocol), Expected Output: A dictionary or array of
extracted features relevant for attack detection.
3. Genetic Algorithm Core Components:
o Initialization Module:
 Function: initialize_population(population_size,
chromosome_length, feature_ranges, seed)
 Test Case 1: Input: population_size = 5, chromosome_length = 10,
specific feature_ranges, seed = 123. Expected Output: A list of 5
chromosomes, each of length 10, with values within the specified ranges.
(Verify for deterministic output with fixed seed).
 Test Case 2: Input: population_size = 1, chromosome_length = 1,
empty feature_ranges. Expected Output: Appropriate error or empty
chromosome.
o Fitness Function Module:
 Function: calculate_fitness(chromosome,
training_data_attacks, training_data_normal)
 Test Case 1: Input: A chromosome representing a rule,
training_data_attacks (known DoS/Probe samples),
training_data_normal (known normal samples). Expected Output: A
numerical fitness score.
 Test Case 2: Input: A chromosome that perfectly classifies all attacks and
no normal traffic. Expected Output: The highest possible fitness score.
 Test Case 3: Input: A chromosome that misclassifies everything. Expected
Output: The lowest possible fitness score.
 Test Case 4: Test with edge cases, e.g., an empty
training_data_attacks or training_data_normal (if allowed).
o Selection Module:
 Function: select_parents(population, fitness_scores,
num_parents_to_select, seed)
 Test Case 1: Input: population (with known chromosomes),
fitness_scores (pre-defined), num_parents_to_select = 2, seed =
456. Expected Output: Two parent chromosomes selected based on the
selection mechanism (e.g., if using roulette wheel, verify the probabilities
and for the specific seed, the expected parents).
 Test Case 2: Input: num_parents_to_select greater than
population_size. Expected Output: Error or handling.
o Crossover Module:
 Function: crossover(parent1, parent2, crossover_rate, seed)
 Test Case 1: Input: parent1, parent2, crossover_rate = 1.0 (always
cross over), seed = 789. Expected Output: Two offspring chromosomes
generated according to the crossover logic (e.g., single-point, two-point).
Verify the exchanged segments.
 Test Case 2: Input: crossover_rate = 0.0 (no crossover). Expected
Output: Offspring identical to parents.
o Mutation Module:
  Function: mutate(chromosome, mutation_rate, feature_ranges,
seed)
 Test Case 1: Input: chromosome, mutation_rate = 1.0 (every gene
mutates), feature_ranges, seed = 101. Expected Output: A mutated
chromosome where all genes have changed their values (within range).
 Test Case 2: Input: mutation_rate = 0.0 (no mutation). Expected
Output: Original chromosome returned unchanged.
 Test Case 3: Test mutation for specific gene positions and ensure values
stay within feature_ranges.
4. Attack Classification Module:
o Function: classify_traffic(traffic_data, best_chromosome_rules)
 Test Case 1: Input: traffic_data (features of a known DoS attack),
best_chromosome_rules (rules evolved by GA). Expected Output: True
(detected as DoS).
 Test Case 2: Input: traffic_data (features of known normal traffic),
best_chromosome_rules. Expected Output: False (not detected as attack).
 Test Case 3: Input: traffic_data (features of a known Probe attack),
best_chromosome_rules. Expected Output: True (detected as Probe).
 Test Case 4: Test with edge cases like empty traffic_data or invalid
best_chromosome_rules.
5. Reporting/Logging Module:
o Function: log_detection_event(attack_type, timestamp,
source_ip, destination_ip)
 Test Case 1: Input: Valid attack details. Expected Output: Verify that the
log file contains the correct entry in the expected format. (This might
involve checking file contents or mocking the logging library).
6.2.4 Tools and Frameworks for Unit Testing
 Mention the programming language and the specific unit testing framework used
(e.g., Python's unittest or pytest, Java's JUnit, C#'s NUnit).
 Discuss any libraries or tools that aid in mocking or asserting statistical properties.

6.2.5 Challenges and Best Practices for Unit Testing GAs

 Randomness Management: Reiterate the importance of controlling randomness

through seeding for reproducibility.
 Oracle Problem: For complex, non-deterministic outputs, defining a "correct"
output (test oracle) can be hard. Emphasize testing smaller, deterministic sub-
components and statistically validating the behavior of non-deterministic ones.
 Test Coverage: Discuss the importance of achieving high unit test coverage (e.g.,
statement coverage, branch coverage) to ensure all lines of code and decision
paths are exercised.
 Maintainability: Stress the importance of writing clear, concise, and
maintainable unit tests.

6.1 Test Environments

The testing was conducted using the NSL-KDD dataset, a widely recognized benchmark
dataset for network intrusion detection. This dataset contains both normal network traffic
and various types of attacks, including DoS and Probe attacks. The dataset was split into
training and testing sets [Image 14] to ensure an unbiased evaluation of the models'
performance on unseen data. The implementation environment was Python, implying that
testing was conducted within a Python-based development setup.
6.2 Unit Testing of Modules
While not explicitly detailed, unit testing would involve verifying the correctness of
individual code components:
 Data Preprocessing Functions: Ensuring that label encoding (Image 11) and
standard scaling (Image 12) correctly transform data.
 Feature Selection Logic: Validating that the feature selection process (e.g., based
on correlation, Image 13) accurately identifies and subsets features.
 Algorithm Implementations: Testing that each machine learning algorithm (RF,
DT, NB, KNN, XGBoost, LSTM, LR, SVM) is correctly instantiated and capable
of learning from small, controlled datasets.
6.3 Integration Testing of Modules
Integration testing would focus on verifying the seamless flow and interaction between
different modules:
 Data Pipeline: Ensuring that data flows correctly from preprocessing to feature
selection and then to model training without errors.
 Model Training and Prediction Flow: Confirming that the selected features are
correctly fed to the models for training, and that trained models can generate
predictions accurately on new data.
6.4 System Testing
System testing evaluates the complete, integrated cyber attack diagnosis system to ensure
it meets all specified requirements. This involves:
 End-to-End Prediction: Running the entire system from data input to attack
diagnosis output, verifying that it functions as a cohesive unit.
 Performance Evaluation: Assessing the system's overall accuracy, speed, and
resource utilization when diagnosing attacks from the test dataset.
6.5 Functional Testing
Functional testing focuses on verifying that the system's specific features and functions
operate as defined. For this project, key functional tests include:
 Attack Type Diagnosis: Testing the system's ability to correctly classify different
types of attacks, with a focus on DoS and Probe attacks. This involves feeding
labeled test data and checking if the predicted labels match the true labels.
 Accuracy Verification: Confirming that the reported accuracy for each model
(Table 3, Image 33) is consistent and accurately reflects its diagnostic
performance.
 Confusion Matrix Analysis: Interpreting the confusion matrix (Image 34) to
understand specific misclassifications (e.g., how often a DoS attack is
misclassified as a Probe attack, or vice-versa) and the rates of false positives and
false negatives.
6.6 Results
The testing results are presented through classification reports and accuracy comparisons:
 Classification Reports: Detailed reports for each model (Images 24-32) showing
precision, recall, f1-score, and support for each attack class (e.g., DoS, Probe,
Normal). These metrics provide a comprehensive view of how well each model
performs in identifying true positives and avoiding false positives/negatives for
specific attack types.
 Accuracy Comparison: A bar chart visually compares the "Accuracy of all the
Models" [Image 33]. This provides a quick overview of which model achieved the
highest overall diagnostic accuracy.
 Confusion Matrix: A confusion matrix [Image 34] offers a granular view of
classification performance, showing the number of true positive, true negative,
false positive, and false negative predictions. This is particularly useful for
understanding misclassifications between attack types like DoS and Probe.