process: verification guide for types and methods (#721)

close #497

Signed-off-by: Philipp Ahmann <[email protected]>
Co-authored-by: aschemmel-git <[email protected]>

Author: pahmann

docs/platform_management_plan/software_verification.rst

@@ -161,8 +161,8 @@ method is to be used as meta data (*TestType* and *DerivationTechnique*).
      - structural-statement-coverage
      - 1, -, -
      - QM & ASIL B
-   * - Structural Condition Coverage (Code coverage)
-     - structural-condition-coverage
+   * - Structural Branch Coverage (Code coverage)
+     - structural-branch-coverage
      - 1, -, -
      - QM & ASIL B
    * - Walkthrough
@@ -437,11 +437,26 @@ the software test strategy and corresponding processes.
 The main build environment of the project is based on `Bazel <https://bazel.build>`__. It it used to build software
 components, documentation, and automated tests.
 
-.. rubric:: GoogleTest
+.. rubric:: GoogleTest (gtest)
 
-The software components of the project written in C++ are tested with the help of
+The software components of the project written in C++ are unit tested with the help of
 `GoogleTest <https://google.github.io/googletest/>`__.
 
+.. rubric:: gcov/gcovr
+
+The structural coverage reached by unit testing in the project is evaluated by the gcov/gcovr tool chain
+`gcovr <https://github.com/gcovr/gcovr>`__ - gcov is part of the GNU compiler collection (gcc).
+
+Note that gcov/gcovr supports several coverage metrics:
+
+- "statement" - used in S-CORE for the structural-statement-coverage method
+- "decision" - used in S-CORE for the structural-branch-coverage method
+- "branch" - used in S-CORE to support manual analysis of the code coverage if the "decision"
+  coverage is reported as "cannot be determined" by the tooling. As the "branch" coverage on target
+  is determined by the tool as object code coverage and as the compiler adds object branches for
+  fast evaluation of complex conditions in decisions, this is more than required by the
+  structural-branch-coverage method.
+
 .. rubric:: Integration Testing Framework (ITF)
 
 The integration of software components can be verified with the help of the ITF. It allows the definition and execution

docs/process/process_areas/implementation/guidance/implementation_checklist.rst

@@ -53,10 +53,10 @@ Checklist
      -
    * - IMPL_01_02
      - Are the SOLID design principles applied?
-     - The Unit Design shall archieve the following principles:
-       Correct order of excecution of the functions,
+     - The Unit Design shall achieve the following principles:
+       Correct order of execution of the functions,
        consistency of the interfaces between the units,
-       correctness of data flow and data controll between the units,
+       correctness of data flow and data control between the units,
        simplicity, readability and comprehensibility, robustness,
        suitability for modifications, verifiability
      -

docs/process/process_areas/verification/guidance/index.rst

@@ -26,3 +26,4 @@ Guidance
    verification_templates
    verification_plan_template
    verification_report_template
+   verification_methods

docs/process/process_areas/verification/guidance/verification_guideline.rst

@@ -130,4 +130,7 @@ useful, this shall be planned and added to the project milestone plan.
 Verification types and methods
 ------------------------------
 
-Verification types and methods are described in the :need:`doc_concept__verification__process`.
+Verification types and methods are described in the :need:`gd_meth__verification__methods` and the
+derivation techniques in :need:`gd_meth__verification__derivation`. The detailed method guideline
+helps to get an understanding what the different methods and derivation techniques mean and how to
+create test cases using the same.