From 88b3d3e095cbe1deca714d003fbf249d6427b057 Mon Sep 17 00:00:00 2001
From: Armin Luntzer <armin.luntzer@univie.ac.at>
Date: Tue, 23 May 2017 16:06:49 +0200
Subject: [PATCH] latex glossary: fixup so unused acronyms are not
unconditionally added to the list
---
Documentation/OS/README | 3 +-
Documentation/OS/shared/glossary.tex | 25 +++-
Documentation/OS/testplan/testplan.tex | 151 +++++++++++++++++++++----
3 files changed, 150 insertions(+), 29 deletions(-)
diff --git a/Documentation/OS/README b/Documentation/OS/README
index cec21ee..bcc3538 100644
--- a/Documentation/OS/README
+++ b/Documentation/OS/README
@@ -11,7 +11,8 @@ makeglossaries <file>
biber <file>
-then recompile
+and repeat this at least twice, or until all references
+have been resolved
Usermanual
diff --git a/Documentation/OS/shared/glossary.tex b/Documentation/OS/shared/glossary.tex
index ea7320e..dab220d 100644
--- a/Documentation/OS/shared/glossary.tex
+++ b/Documentation/OS/shared/glossary.tex
@@ -4,12 +4,21 @@
\setlength{\glsdescwidth}{0.8\textwidth}
\renewcommand{\glsnamefont}[1]{\textbf{#1}}
-\DeclareDocumentCommand{\newdualentry}{ O{} O{} m m m m } {
- \newglossaryentry{gls-#3}{name={#5},text={#5\glsadd{#3}},
- description={#6},#1, nonumberlist
- }
- \makeglossaries
- \newacronym[see={[ Glossary:]{gls-#3}},#2]{#3}{#4}{#5\glsadd{gls-#3}}
+% label, acronym, name, description
+\DeclareDocumentCommand{\newdualentry}{ m m m m } {
+ \newglossaryentry{gls-#1}{
+ name={#3 (\gls{#1})},
+ description={#4}, nonumberlist
+ }
+ \newglossaryentry{#1}{
+ type=\acronymtype,
+ name={#2},
+ first={#3 (#2)},
+ firstplural={#3s (#2s)},
+ see={[Glossary:]{\gls{gls-#1}}},
+ description=\glslink{gls-#1}{#3},
+ nonumberlist
+ }%
}
%%% \gls{ABBREV} to point at Acronym/Abbreviation index
%%% \gls{gls-ABBREV} to point to glossary
@@ -284,3 +293,7 @@
nonumberlist
}
+
+% do not remove
+\glsresetall
+\makeglossaries
diff --git a/Documentation/OS/testplan/testplan.tex b/Documentation/OS/testplan/testplan.tex
index 581b1d5..d787f63 100644
--- a/Documentation/OS/testplan/testplan.tex
+++ b/Documentation/OS/testplan/testplan.tex
@@ -17,6 +17,7 @@
\input{../shared/template/univie.tex}
\input{../shared/template/titlepage.tex}
+\input{../shared/template/traceability.tex}
\input{../shared/glossary.tex}
\usepackage{vhistory}
@@ -134,12 +135,20 @@ form of software programs that control the execution of a test, check the
correctnes of the results and generate a summary report.
+
\section{Items Under Test}
Components and software modules of the operating system are tested on an
unit-level where applicable. System level tests are tailored to the
various configuration options avaiable. and shall be accompanied by
-configuration files so the proper build may generated.
+configuration files so the proper build may generated.\\
+\\
+
+\requirement{IUT-0001} {Hardware constraints}{%
+The test plan specified by the present requirements shall apply to all parts %
+of LeanOS.
+}{}
+
\section{Operational Constraints}
@@ -149,8 +158,13 @@ performed. Unit-level test of platform-independent components may be executed
on any compatible hardware. Platform-dependent tests may require specific
hardware models (e.g. the \gls{SSDP} for testing of the \gls{NoC}) or just any
compatible processor model (e.g. \gls{LEON3} for testing the operation of the
-\gls{MMU}).
+\gls{MMU}).\\
+\\
+\requirement{OPC-0001} {Hardware constraints}{%
+The execution of the tests defined in this document shall comply with all %
+the operational constraints applicable to the hardware used in the tests.%
+}{}
@@ -184,19 +198,74 @@ test verifies the behaviour of a number of interacting components. \\
Unit and integration tests are white-box type test that executes a component
with a series of input conditions and verify the output or action for the
expected response. These type of test are typically independent from the
-hardware platform.
+hardware platform.\\
+\\
+
+\requirement{UIT-0001} {Unit/Integ. Tests}{%
+Unit and Integration Tests shall be defined and executed for LeanOS components.
+}{Tests can make use of the modified \emph{kselftest} framework provided %
+in the LeanOS source tree.
+}%
+
+\requirement{UIT-0002} {Test Suite}{%
+A unit and integration test suite shall be provided as a set of applications.
+}{}%
+
+\requirement{UIT-0003} {Automatic Test Execution}{%
+A single mechanism shall be provided that automatically runs all unit and %
+integration tests in sequence.%
+}{The \emph{kselftest} framework in the LeanOS source tree provides a %
+\emph{Makefile} setup that can be used for this purpose.}%
+
+\requirement{UIT-0004} {Test Results}{%
+The test suite shall generate feedback a human-readable report describing the %
+outcome of each unit and integration test.%
+}{}
+
+\requirement{UIT-0005} {Automatic Testing}{%
+A feedback mechanism shall be provided that allows an external automated %
+testing mechanism to execute and detect the results of unit and integration %
+tests.%
+}{This is very useful for automated bisection of code versions, e.g. by %
+using the \emph{git bisect run \ldots} functionality.}%
\section {Hardware-Software Tests}
These tests differ from unit and integration tests in that a particular hardware
platform is required for testing. All system-level integration tests fall in
-this category.
+this category.\\
+\\
+
+\requirement{HST-0001} {Hardware Tests}{%
+Hardware-software tests shall be defined and executed for LeanOS components %
+with the objective of verifying the behaviour of components which directly %
+interact with the relevant target hardware.%
+}{}
+
+\requirement{HST-0002} {Test Suite}{%
+A hardware-softwaree test suite shall be provided as a set of applications.
+}{}
+
+\requirement{HST-0003} {Test Results}{%
+The hardware-software tests shall generate feedback as a human-readable %
+report describing the outcome of test.%
+}{}
+
+
+\requirement{HST-0004} {Automatic Testing}{%
+A feedback mechanism shall be provided that allows an external automated %
+testing mechanism to execute and detect the results of hardware-software tests.%
+}{This is very useful for automated bisection of code versions, e.g. by %
+using the \emph{git bisect run \ldots} functionality.}%
+
+
+
\chapter{Test Environments}
-Test beds for running LeanOS tests are:
+Test beds in which LeanOS tests are performed:
\begin{itemize}
\item general-purpose platform for regular unit and integration tests
@@ -204,37 +273,53 @@ Test beds for running LeanOS tests are:
\item \gls{SSDP} and/or \gls{MPPB} for system-level hardware-software tests
\end{itemize}
+\noindent
+The test environments required for each category of test are described in the
+following sections.
+\newpage
\section{Unit and Integration Test Environment}
+\begin{figure}[]
+\begin{center}
+ \includegraphics[width=0.5\columnwidth]{images/unittest}
+ \caption{Unit and integration test environment. Stubs and Mockups %
+ are stand-ins for external dependencies with defined behaviour. %
+ A set of input data is fed into the item under test as specified %
+ in the test procedure.}
+ \label{fig:unittest}
+\end{center}
+\end{figure}
+
The test environment for unit and integration tests are shown in
-\fig{fig:unittest}.
+\fig{fig:unittest}.\\
+\noindent
The item under test is either one or a set of components of LeanOS. If needed,
stub and mockup functions, which simulate the expected behaviour of external
dependcies, are defined to create a representative environment in which the item
-under test is running.
+under test is running.\\
+\noindent
Tests are controlled by a test sequence, which generates inputs for the item
-under test and collects and evaluates the generated output.
+under test and collects and evaluates the generated output.\\
+\\
-
-\begin{figure}[h]
-\begin{center}
- \includegraphics[width=0.5\columnwidth]{images/unittest}
- \caption{Unit and integration test environment. Stubs and Mockups%
- are stand-ins for external dependencies with defined behaviour.%
- A set of input data is fed into the item under test as specified
- in the test procedure.}
- \label{fig:unittest}
-\end{center}
-\end{figure}
+\requirement{UITE-0001} {Unit Test Environment}{%
+Unit and integration tests shall be performed in an environment as defined in %
+\fig{fig:unittest}. %
+}{}%
\section{Hardware-Software Test Environment}
-The hardware-software test environment is described on a per-test basis.
+The hardware-software test environments are detailed on a per-test basis.\\
+\\
+\requirement{HSTE-0001} {HW/SW Test Environment}{%
+The required hardware-software test environment shall be defined in the %
+specification of each individual test.%
+}{}%
\chapter{Test Coverage}
@@ -246,10 +331,32 @@ previously.
Source code coverage must be achived in unit and integration tests.
A component is considered covered if full statement, decision and condition
-coverage is achieved.
+coverage is achieved. \\
+\noindent
If full coverage cannot be achieved, for example due to operational constraints,
-deviations are acceptable provided that they are justified.
+deviations are acceptable provided that they are justified.\\
+\\
+
+\requirement{SCC-0001} {Statement Coverage}{%
+Unit and integration tests shall offer full statement coverage for LeanOS code.%
+}{}%
+
+\requirement{SCC-0002} {Decision Coverage}{%
+Unit and integration tests shall offer full decision coverage for LeanOS code.%
+}{}%
+
+\requirement{SCC-0003} {Condition Coverage}{%
+Unit and integration tests shall offer full condition coverage for LeanOS code.%
+}{}%
+
+\requirement{SCC-0004} {Reduced Coverage}{%
+If the coverage specififed in the previous requirements cannot be achieved %
+due to operational contraints, justifications for deviations shall be provided %
+for each of the individual conditions where the degree of coverage is below %
+the specified goal. %
+}{}%
+
\section{Hardware Functions}
--
GitLab