From fb3d3baaaf37b7c254c30e3b45fa831b570e0403 Mon Sep 17 00:00:00 2001 From: Attilio Stefano Funel Date: Mon, 11 May 2026 09:20:07 +0200 Subject: [PATCH 1/5] attifunel added requirement testing description --- .../guidance/verification_methods.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index 221ba97bac..e4173b7db1 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -172,10 +172,29 @@ Derivation Techniques Following derivation techniques are explained + * :ref:`Analysis of requirements ` * :ref:`Boundary Values ` * :ref:`Equivalence Classes ` * :ref:`Fuzzy Testing ` +.. _ver_req_anal: + +Requirements analysis +""""""""""""""""""""" + +Requirements analysis is a testing technique where tests are designed based on the +requirements assigned to the software element under test (component, module, unit etc.). +If available, the verification method defined for each requirement should be used as +the basis of the test cases design. + +Requirements should always be tested against their "nominal" behaviour: i.e. "if input +x = A, the output y of SW component X shall be equal to b". This leads to a test case +injection value x = A and verifying that output y = B. "Negative" testing technique should +be also considered: i.e. testing what happens when input x = B (if not already specified +in other requirements). Note that the latter derivation can be covered by other techniques +mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing and Fault +Injection. + .. _ver_boundary: Boundary Values From 9bb64b2f0f9c35a1c7857cf023a3268e47274663 Mon Sep 17 00:00:00 2001 From: Attilio Stefano Funel Date: Mon, 11 May 2026 09:22:00 +0200 Subject: [PATCH 2/5] attifunel improved clarification --- .../verification/guidance/verification_methods.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index e4173b7db1..5a9e245563 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -191,7 +191,9 @@ Requirements should always be tested against their "nominal" behaviour: i.e. "i x = A, the output y of SW component X shall be equal to b". This leads to a test case injection value x = A and verifying that output y = B. "Negative" testing technique should be also considered: i.e. testing what happens when input x = B (if not already specified -in other requirements). Note that the latter derivation can be covered by other techniques +in other requirements). + +Note that requirement-based testing derivation is typically covered by other techniques mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing and Fault Injection. From 0eeb805e5efe8b6d146dce7811c6d96efbd1ed5a Mon Sep 17 00:00:00 2001 From: Attilio Stefano Funel Date: Mon, 11 May 2026 09:22:49 +0200 Subject: [PATCH 3/5] attifunel added ref. to interface testing as well --- .../verification/guidance/verification_methods.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index 5a9e245563..b2eae741b1 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -194,8 +194,8 @@ be also considered: i.e. testing what happens when input x = B (if not already s in other requirements). Note that requirement-based testing derivation is typically covered by other techniques -mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing and Fault -Injection. +mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing, Interface +Testing and Fault Injection. .. _ver_boundary: From 859aef854dfd13adfe24a6fc12c9cd9f9113ef0d Mon Sep 17 00:00:00 2001 From: Attilio Stefano Funel Date: Mon, 11 May 2026 09:23:39 +0200 Subject: [PATCH 4/5] attifunel unified naming --- .../verification/guidance/verification_methods.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index b2eae741b1..54a65f148e 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -172,7 +172,7 @@ Derivation Techniques Following derivation techniques are explained - * :ref:`Analysis of requirements ` + * :ref:`Requirements analysis ` * :ref:`Boundary Values ` * :ref:`Equivalence Classes ` * :ref:`Fuzzy Testing ` @@ -193,7 +193,7 @@ injection value x = A and verifying that output y = B. "Negative" testing techni be also considered: i.e. testing what happens when input x = B (if not already specified in other requirements). -Note that requirement-based testing derivation is typically covered by other techniques +Note that requirement-based testing derivation is typically covered by other techniques mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing, Interface Testing and Fault Injection. From dc7dca5e2658cdfcb803e2af9778e432c823ef09 Mon Sep 17 00:00:00 2001 From: Attilio Stefano Funel Date: Thu, 14 May 2026 09:37:48 +0200 Subject: [PATCH 5/5] added some notes, typos, corrections, improvements etc. --- .../guidance/verification_methods.rst | 38 +++++++++++-------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index 54a65f148e..9312361128 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -76,8 +76,8 @@ interfaces (the points where different parts of the system connect and interact) correctly and reliably. This includes validating data formats, protocols, error handling, and overall communication integrity incl. the respective consumed and exchanged data. -It can be distinguished between internal and external interfaces. Internal interfaces are best covered -on unit level. External interfaces work best on component integration and feature level. +The method applies to both internal and external interfaces. Internal interfaces are best covered +on unit level. External interfaces are tested best on component integration and feature level. It is important that the interface tests include the testing of the actual intended functionality which the interface provides. The related requirements, architectural design, but also the descriptive @@ -113,14 +113,14 @@ Types of ``interface-test`` are: Stress the interfaces to see how they behave under heavy load (e.g., sending a large number of messages simultaneously). -- **Security Tests:** (Relevant for code interacting with security critical parts) +- **Security Tests:** (Relevant for code part of, or interacting with, security critical parts) Verify that the interfaces are protected against unauthorized access and data breaches. - **Timing and Performance Tests** (Relevant for realtime constraints) - Measure the latency and throughput of the interfaces. This is mainly on integration level and is - hard to have reasonable testing in the reference implementation + Measure the latency and throughput of the interfaces. This should be tested mainly on integration level. + Conversely, this method could be difficult to apply in the reference implementation .. _ver_structural: @@ -130,7 +130,7 @@ Structural Coverage Structural coverage is a white-box testing technique used to check if the testing is sufficient by analyzing if code constructs were called during testing. -In S-CORE we do both: +Metrics applied are: * **Statement Coverage:** Measures whether each executable source code statement has been executed. @@ -139,8 +139,8 @@ In S-CORE we do both: S-CORE evaluates this coverage using the compiler selected for the target reference platform. -If a sufficient structural coverage is not reached then additional test cases are added. -What is sufficient and how to determine the coverage is defined in the :need:`wp__verification_plan` of the project. +If a sufficient structural coverage is not reached then additional test cases shall be added. +The coverage targets and how to determine the coverage is defined in the :need:`wp__verification_plan` of the project. .. _ver_sta: @@ -182,18 +182,18 @@ Derivation Techniques Requirements analysis """"""""""""""""""""" -Requirements analysis is a testing technique where tests are designed based on the -requirements assigned to the software element under test (component, module, unit etc.). +Requirements analysis is a test derivation technique where tests are designed based on the +requirements assigned to the software element under test (unit, component, feature etc.). If available, the verification method defined for each requirement should be used as the basis of the test cases design. -Requirements should always be tested against their "nominal" behaviour: i.e. "if input -x = A, the output y of SW component X shall be equal to b". This leads to a test case +Requirements should always be tested against their "nominal" behaviour: i.e. "if input +x = A, the output y of SW component Z shall be equal to B". This leads to a test case injection value x = A and verifying that output y = B. "Negative" testing technique should -be also considered: i.e. testing what happens when input x = B (if not already specified +be also considered: i.e. testing what happens when input x = C (if not already specified in other requirements). -Note that requirement-based testing derivation is typically covered by other techniques +Note that requirement-based derived test case may also cover other techniques and derivation methods mentioned here, such as Boundary Values, Equivalence Classes, Fuzzy Testing, Interface Testing and Fault Injection. @@ -289,11 +289,15 @@ How to perform the analysis: input variables simultaneously. This is especially important if there are dependencies between the variables. +In case of non-trivial determination of test case inputs, a short explanation of the +process followed can be given in order to facilitate maintenance and test regression, +as well as during audits and assessments. + .. _ver_equivalence: Equivalence Classes """"""""""""""""""" -Equivalence Classes or also called Equivalence Partitioning (EP) is a software testing technique +Equivalence Classes, also called Equivalence Partitioning (EP), is a software testing technique that divides the input domain of a program into equivalence classes or partitions. The principle is that all values within a single partition are treated equivalently by the software. Therefore, only one test case from each partition is needed to achieve adequate test coverage. This reduces @@ -365,6 +369,10 @@ How to perform the analysis: Create test cases using the representative values from each equivalence class. Aim to cover all classes in your test suite. +In case of non-trivial determination of test case inputs, a short explanation of the +process followed can be given in order to facilitate maintenance and test regression, +as well as during audits and assessments. + .. _ver_fuzzy: Fuzzy Testing