Home

Verification of Low Level Software notes

Contents

1. Stephan Griinfelder Follow up review of the IOPS Software Calculate code metrics and decide on readiness for code inspection Re run the static code checker Re do the code review Inspect the fixes of the review item discrepancies Assess readiness for unit AA testing Stephan Gr nfelder AR gt k a d wem Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder typedef int voltage typedef int current typedef current leak_current current c voltage v leak_current lc int nonsense nonsense c v no strong types c lc works even in strong hierarchy c works when wanted Application of a code checker to the reviewed software Check if you find a bug you haven t found in the manual review Stephan Griinfelder Unit Testing Stephan Griinfelder Unit test case design Retrieve the design specification of the unit under test Derive black box test cases like for functional testing See unit 2 Enhance the tests with white box test cases to satisfy a required coverage criteria Test things that came up in the code review Stephan Griinfelder Decision Coverage Branch Coverage number of decision outcomes exercised Decis
2. 1 1 i max 1 ge state raw position 1 gt deb time 250 y Figure 2 Switch Postition Debouncing 5 1 4 Reliability and Accuracy R SRD RA 10 2 Missing Parameters In case the IOPS hasn t received a single valid message within 10 seconds after start up it shall reboot the processor Comment The reboot may be initiated by the software by neglecting to kick the watchdog R SRD RA 20 1 PP bus Error In case the software cannot interpret a PP bus command or encounters an invalid software state it shall initiate a reboot of the processor within one second Comment The software should be operable as much as possible there is no need to log the cause of the error or stay fail silent once the software is fully operational R SRD RA 30 1 Watchdog Kicking The software shall kick a watchdog at least once a second and at most 10000 times a second by setting bit 1 of the digital I O port for at least 50 clock cycles and by clearing the bit afterwards Comment the external watchdog will reset the MC4711 if it is not kicked for 1000ms A deadlock resolved by the watchdog shall not be visible to other devices on the PP bus Das wird ja wohl nicht erf llt Siehe FMEA FTA bei einem WD reset in operational h rt der IOPS auf seinen Zustand zu melden Eigentlich ist das ein Requirement und kein Kommentar Was im SRD 1 0 schon bem ngelt wurde hat der SRD Autor hier eine unsinnig umformliert 5 2 Software Budget R
3. Stephan Griinfelder 15 How does SW design influence testing Example 4 lacking cohesion gt stubbing hardly manageable Stephan Griinfelder 17 How does SW design influence testing Example 1 En ia a CS no problem Hierarchy of includes Stephan Griinfelder 14 How does SW design influence testing Example 3 Problem gt no loops Stephan Griinfelder 16 How about global variables target compiler Stephan Griinfelder Review of an Architectural Design Document Modularity No cycles in the module dependencies Cohesion Data Information hiding Can all requirements indeed be implemented in the design elements given in the traceability matrix Are requirements forgotten Style use the same language as the SRD Visualisation use standardised figures to capture your design UML HOOD Clarity and maintainability of the design Review of an ADD Stephan Griinfelder Stephan Griinfelder Review of the OPS ADD Consistency concern e Modularity e No cycles in the module dependencies Q How can you guarantee or at least IN os check consistency between the Data Information hiding Pe eee eee description in the design document and implemented in the design elements given in the traceability matrix Are the actual code requirements forgotten e Clarity and mainta
4. TheCompany Ltd Rosentalgasse 3 A 1140 Wien PLS Intelligent Oil Pressure Sensor Architectural Software Design Document 004599 Issue 1 0 Date 15 Sep 2003 Name Function Signature Date Prepared Stephan Gr nfelder SW Designer i cocnccnccncnncnncnncnncnnnnncnncnncnnnnnennnnns Geeeeeeeeeeeneeneenenes Checked Bernd Spiess Seeler le et Meike teeter deus ee ee Robert Stolz VeriiicallomEngineer ati Nee Helga Machart SW Quality Assurance asien lei Approved Norbert Wichtig Proiee Manage estrenos prensas Sieben TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 2 Document Distribution List Hansi Hinterseer Arnold Schwarzenegger Cindy Crawford Hubert von Goisern Change Log Change Description 1 0 15 Sep 2003 This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 3 Table of Contents I A ee See er Se ete 4 1 1 O A O Eee 4 1 2 Detinitions Acronyms Abbrevations anne ee A 4 gt Docume area einlesen 4 2 1 EREM 5 D2 Reference LOCUS nannten O A 5 SE A A E TA 5 4 System COM essen 5 Io OV SUC MN DES en nee alates cate eel ge Sa alesis alec cat aaa heel O 6 5 1 Desten Melodien ee e 6 Za TEE 6 Ep Component Descrip a a 7 6 1 PEDOUN Aunado did ersehen 7 O A RO 7 6 3 e 8 A Na a Nee N 9 T Fe siDility and Resource Estim les
5. European Space Agency Board for Software Standardisation and Control Guide to software verification and validation ESA PSS 05 10 Issue 1 February 1994 Gets into more detail than PSS 05 0 with respect to software verification European Space Agency Board for Software Standardisation and Control Guide to the software requirements definition phase ESA PSS 05 03 Issue 1 October 1991 Gets into more detail than PSS 05 0 with respect to requirements management and engineering Linda Rosenberg What is Software Quality Assurance STSC Crosstalk May 2002 STSC Crosstalk is a free web based publication for software quality in military applications IBM Rational Unified Process See http www rational com A set of document templates and tools that support the software life cycle together with a HTML based description of software project management issues and examples
6. e Operator promted for manual interaction by test script e An operator must interpret data generated in an otherwise automatic test Stephan Griinfelder Test Hooks e Generation of test data in the test object e Access to internal test data for authorised users Stephan Griinfelder Psychology A programmer should avoid attempting to test his or her own program Testing is a destructive process you try to break the software try to find weaknesses try to reveal bugs It is extremely difficult after a programmer has been constructive while designing and coding a program to suddenly change his or her perspective and attempt to form a completely destructive frame of mind toward the program Hence most programmers cannot effictively test their own software because they cannot bring themselves to form the mental attitutde of exposing errors Myers78 Stephan Griinfelder Write a System Test Plan Testing is a project Like in development projects the chance of success increases if you plan the work and keep working on the plan Define software release criteria Make release criteria SMART Specific for the project Measurable to evaluate the software against them Attainable Relevant steph aGKable Automation in IOPS Software System Testing In the lab you have e a PC based PP bus node with Windows API with interactive test software that produces log files with time stamps resultion 3 100s on a
7. user defined type u unsigned must be followded by another prefix word an unsigned 16 bit entitiy Tabelle 2 Vorsilben engl prefixes f r Variablen Um die Unterscheidung selbstdefinierter Typen von Funktionen und Variablen leichter zu machen formulieren wir folgende Regel 18 Schreibweise von Typennamen Ein Bezeichner eines benutzerdefinierten Typs muss mit einem gro en Anfangsbuchstaben beginnen mindestens einen Kleinbuchstaben enthalten und mit dem Pr fix T versehen werden Zum Beispiel TDatabaseRecord Die vorgestellten Regeln k nnen zur Falle werden wenn sie nicht konsequent angewandt werden wie folgendes Beispiel in C zeigt Team A stellt folgenden Parameter zur Verf gung int iParameter ist Zeiger hat aber kein p im Pr fix Ist die Variable auf die der Zeiger zeigt N ll s ist in Modus e den Normal Zustand gesetzt Team B verwendet diesen Parameter pr ft aber nicht seine Deklaration weil das Pr fix schon eine Integer Variable definiert iParameter 0 Annahme diese Anweisung setzt das Modul in den Normalzustand Tats chlich ist der Astana aber undefinvert 7 Woher kommst du Wer einmal in einem mehrere tausend Zeilen umfassenden Quellcode einen Fehler finden musste und nicht selbst Autor der Software war we wie schwierig es sein kann eine bestimmte Definition aufzufinden Warum dies von Bedeutung sein kann wurde m obigen
8. Code metrics for Unit Testing and Integration Testing Baseline Testing Tool based software metric calculation Software coding standards Code review checklists Code review Stephan Griinfelder Contents Unit 6 e Implementation of simplified unit tests moderated e A note on test metrics e Tools for automatic test case generation e Design and implementation of unit tests Stephan Griinfelder Contents Unit 8 Generating and using system test error statistics Running the designed system tests System Test Summary Report Extreme Programming Risk based testing Conclusion Feedback Stephan Griinfelder What is NOT taught here Formal specifications Static theorem proving Certification of safety critical software Verification of time domain issues in parallel systems Internet security testing Stephan Griinfelder Stephan Griinfelder Today s contents Today s contents Unit 1 Unit 1 continued Motivation e Case studies of requirements Self Assessment Test e Review of the Software Requirements Document 1 0 Definitions e Walkthrough Review Meeting V Model motivation of an early V amp V Special considerations for embedded systems Review techniques How to review a software requirements document Stephan Griinfelder Stephan Griinfelder Motivation Motivation Komplexere Software in Autos als Pannenursache Nummer eins Die immer komplexere Software in Autos ist Pannenursach
9. Sauber verkn pfte Quelldateien lassen sich leicht neu arrangieren und wiederverwenden Es ist daher ratsam immer alle notwendigen Deklarationen zu inkludieren sodass jede Datei ohne Vorbedingungen separat bersetzt werden kann Empfehlung 17 Reihenfolge und include Jede Quelldate sollte einzeln bersetzt werden k nnen Die Reihenfolge der include Anweisungen in einer Quelldatei sollte keine Rolle spielen Und wenn Sie die Verzeichnisstruktur ndern m ssen oder ein schlechtes Programm zum Configuration Management haben wird die Befolgung folgender Empfehlung viel Arger ersparen Empfehlung 18 Dateinamen Jeder Dateiname sollte 1m Projekt nur einmal vorkommen Auch in Details des Designs kann durch Beachtung von Regeln die Zusammenarbeit im Team vereinfacht werden C ist keine objektorientierte Sprache und Funktionen m ssen als Parameter ggf eine Referenz auf ein betroffenes Objekt und ein anwendbarer Parameter bergeben werden Beispielsweise bei vola SELPOrt int BoOrL ID rit IV Die hier gew hlte Reihenfolge der Parameter entspricht dem Prinzip zuerst das betroffene Objekt anzugeben dann die Parameter f r dieses Objekt Dies ist das meist verwendete Prinzip Wenn sich alle Mitglieder eines Teams daran halten dann gibt es keine Verwirrungen weil niemand auf die Idee kommt vold SetPort int 2Vaelue Int Portib zu definieren Also lohnt es sich hier eine Regel zu definieren Etwa indem die Reihenfolge der Para
10. achieve state based entry point coverage are based on the design they are usually just those which would form a normal black box test set particularly if an approach such as Binder s FREE is used This reduces the need to write additional test cases purely to achieve a defined coverage target Thread Based Context Coverage The concept of context coverage which underpins both inheritance context coverage and state based context coverage can also be used to assist with other coverage analysis problems For example when testing a multithreaded application traditional structural coverage metrics will aggregate the coverage achieved by all the threads into a single coverage value The context coverage approach can be applied here to maintain separate coverage information for each thread As with state based context coverage a user provided function is used automatically by Cantata to determine the current context 13 IPL Information Processing Ltd const echar cppca User Context funotrtond Const 4 state char butter 6 sprintf buffer Sx OS Threads GetCurrentThreadID return buffer The additional coverage information provided through context coverage can be used o ensure that each individual thread 1s thoroughly tested Moreover the raw coverage data which statements and decisions are executed in which threads can be used to analyse how the software under test actually behaves in the presence
11. batch Value 1 E Schreibe Jetzt den Wert ans Register WriteStack l und sichere ihn auf dem Stack x Die Wahl der Funktionsnamen ist mehr als nur schlecht Das Pr fix Get wird im allgemeinen verwendet wenn das Object der Operation dabei unver ndert bleibt Der Kommentar beschreibt aber eine Operation die das Objekt den Stack ver ndert Eine gl cklichere Wahl ist die Verwendung von Pop denn push und pop sind eingeb rgerte Begriffe f r die Verwendung eines Stacks Die Funktion GetLatchValue d rfte einen Wert berechnen der sp ter n ein Register geschrieben werden muss Also st die Bezeichnung irref hrend denn der Benutzer der Funktion erh lt nicht den Wert des Registers sondern einen Wert f r das Register Die Wahl des klein geschriebenen L als Variablenname ist gef hrlich In den letzten beiden Zeilen ist es schwierig zu sagen ob der zuvor gelesene Wert verwendet wird oder eine Eins Der Name LatchValue ist ein aktionsloses Hauptwort bezeichnet aber eine Aktion namlich das Beschreiben des Registers Die Wahl des Namens fur die letzte Funktion ist ebenfalls rref hrend es wird kein Stack geschrieben Das Argument der Funktion ist kein Stack sondern ein Element des Stacks WriteToStack ware da schon besser Und wirklich gut ist naturlich Push Eine korrigierte Version des obigen schlechten Beispiels k nnte wiefolgt aussehen iOldLatchValue Pop oder PopFromStack
12. function e The test tool is fully integrated with the In Circuit Emulator If more test cases are defined the size of e Very fancy tools can even automatically generate test cases on numerical boundaries Stephan Gr nfelder Stephan Gr nfelder IOPS unit testing Test the source file debounc c in an isolation testing approach 100 decision coverage is required Note that we have an OO design in plain C language CA gie Stephan Griinfelder Stephan Griinfelder IOPS unit testing the bugs Stephan Griinfelder Unit 7 Verification of Low Level Software Stephan Griinfelder IOPS unit testing continued Test the source file debounc c in an isolation testing approach 100 decision coverage Is required Note that we have an OO design in plain C language Af Stephan Gr nfelder New bugs and enhancements are submitted in the elementool account by the Fixed issues are closed in the elementool by QA Non fixed issues are re opened in the elementool account Team leaders assign priority to new Issues Issues priority is Q amp A checks fixed issues in the A Be emt R amp D fixes issues according to new release using the elementool priority Issues status changed report engine y 4 to Fixed in elementool account R amp D releases a new internal version with fixed bugs and new features updated in the elementool account Contents Unit 7 Design
13. m allgemeinen ein Designprogramm das automatisch Quellcode erzeugen kann Wenn S e ein neues CASE Tool benutzen m ssen S e unter Umst nden das m Codierungsstandard festgehaltene Layout gr ndlich berholen oder das Tool entsprechend anpassen Referenzen 1 Codierungsstandards in der Software Entwicklung f r Eingebettete Systeme 2 Ein guter Programmstil will standardisiert sein 3 LCLint User s Guide http lclint cs virginia edu Fehlervermeidung bei der Erstellung von C Programmen Die Programmiersprache C ist fur viele Anwendungen im Bereich Eingebettete Systeme nicht wegzudenken Fur eine Vielzahl von Prozessoren erlaubt sie nahezu alles zu implementieren was auch in Maschinensprache m glich ist Der Preis fur diese Flexibilit t ist das geringe Sicherheitsniveau beim Programmieren Der folgende Artikel beschreibt Regeln deren Befolgung dieses Niveau hebt ohne die Machtigkeit von C zu bescheiden Weiters erleichtern sie die Interaktion von Programmierern und sollten somit Teil eines Codierungsstandards sein In den fr hen Siebzigern arbeitete Dennis Ritchie in den heute zu Lucent geh renden Bell Laboratories an der Entwicklung des Betriebssystems UNIX Zu diesem Zweck ben tigte er eine Sprache die kompakten schnellen Code erzeugen lie und die Hardware effizient bedient Zu dieser Zeit wurden diese Kriterien nur von Assembler zuverl ssig erf llt Doch Assembler ist prozessorabh ngig und UNIX sollte auf einer Vielz
14. r ein Unterprogramm Ver ndern eines Objekts siehe Regel 9 Teil eines Namens f r ein Unterprogramm Abfragen eines Objekts das Objekt wird dabei n der Komponente des R ckgabewerts der Funktion ver ndert Siehe auch get Letzter Teil eines Namens f r eine Identifiziert den Typ Klasse einer Variable Struktur z B Nachricht eindeutig es kann aber mehrere Instanzen z B Nachrichten diesen Typs geben die ggf durch eine D unterschieden werden Tabelle 1 Erfassung und Definition von Fachbegriffen im Coding Standard Empfehlung 11 Worttypen in Bezeichnern f r Bool sche Unterprogramme Unterprogramme Prozeduren oder Funktionen deren R ckgabewert eine Bool sche Variable ist sollten mit Namen bezeichnet werden die eine Entscheidungsfrage darstellen und daher nur mit ja oder nein bzw true oder false zu beantworten sind Beispiel IsInterruptkEnabled Empfehlung 12 Worttypen in Bezeichnern f r Variablen Bezeichner Bool scher Variablen sollten Eigenschaften beschreiben z B bModeDirty Bezeichner aller anderen Variablentypen sollten Hauptworter sein z B iEventNumber Empfehlung 13 Buchstaben als Bezeichner Einzelne Buchstaben sollten nicht als Bezeichner fur Variablen oder Unterprogramme verwendet werden Ausnahmen sind Schleifenzahler und Indizes fur Felder arrays Das kleine L sollte nie als Bezeichner verwendet werden Es kann in seltenen Fallen vorteilhaft sein die letzte Empfehlung nicht zu b
15. 0 Page 7 All processor related functions are found in the System library which is a third party product and is used by all project specific objects The object Debounc implements a debouncer 1 e a state machine that debounces digital input As said only one instance is used by Main which implements the PP command interpreter and the glue logic for the other objects Finally messages h 1s a header file common to all PLS software projects It defines the messages sent over the PP bus 6 Component Description 6 1 Debounc 6 1 1 Type The files debounc c and debounc h implement a number of identical debouncing functions as abstract data types TDebouncer The maximum number of debouncers that can be handled must be defined with the macro MAX_DEBOUNCERS 6 1 2 Purpose This component implements the debouncing of the oil pressure switch position 1 e it is used to compute the debounced oil pressure switch state Furthermore it keeps the system time i e increments the global variable ulSystemTime at 1kHz with the help of the on chip timer 6 1 3 Function The function GetNewDebouncer returns a handle of type TDebouncer for a new debouncer and initialises the private variables and the on chip timer in case the function 1s called the first time The member functions Set PosTime and SetNegTime set the positive and negative debounce times of a debouncer and at the same time define the initial state of the debouncer The function D
16. 15 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 4 Resources 4 1 Roles Role Persons part full time Responsibilities Comments est Manager Assign names here in thisProvides management oversight column More than one rolesResponsibilities can be taken by one and the same person e provide technical direction e acquire appropriate resources e provide management reporting e conduct test reviews Identifies prioritizes and implements test cases e recover from errors e document change requests Ensures test environment and assets are managed and maintained Responsibilities e administer test management system e install and manage access to test systems Ensures test data database environment and assets are managed and maintained Database Administrator Database Manager Responsibilities e administer test data database Identifies and defines the operations attributes and associations of the test classes Responsibilities e identifies and defines the test classes e identifies and defines the test packages Designer Implementer Medcare hf CONFI DENTIAL Page 16 Implements and unit tests the test classes and test packages Responsibilities ecreates the test classes and packages implemented in the test model D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 4 2 System Which of our resources could
17. Beispiel bereits demonstriert Die Auffindbarkeit von Definitionen wird wesentlich verbessert wenn jedes global verwendete Programmelement als Teil des Bezeichners den Ort seiner Definition ang bt w e folgende Regel vorschreibt Regel 19 Definitionsort in Bezeichnern globaler Programmelemente Ein Bezeichner einer globalen Variable oder eines globalen Unterprogramms muss die Datei dentifizieren in der die Definition der Variablen des Unterprogramms erfolgt Diese Regel ist sehr allgemein gehalten und l sst viele Freiheiten Der Grund daf r ist die Vielfalt der Programmiersprachen und Programmierstile Nehmen wir das Beispiel reinen objektorientierten Designs Wenn die Programmiersprache Objektorientierung unterst tzt dann ist es blich jede global sichtbare Klasse in einer Datei gleichen Namens zu definieren In einem sauberen Design keine globalen Attribute und Variablen ist jede weiter Ma nahme zur Identifikation des Definitionsorts berfl ssig Programmieren Sie aber beispielsweise in C oder Assembler dann kann die Beachtung folgender Empfehlung viel rger sparen Empfehlung 20 Erfassen des Definitionsorts in nicht objektorientierten Sprachen Jedes gobal sichtbare Programmelement sollte den Namen der Date oder eine eindeutige Abk rzung des Dateinamens in der es definiert wird 1m Bezeichner f hren und diesen durch ein Unterstreichungszeichen vom Rest des Bezeichners trennen Unterstreichungszeichen sollten ausschlie lich
18. How Should We Test Polymorphism Traditional structural coverage metrics are inadequate as a measure of how well polymorphic code has been tested Consider the following fragment of code class Base p blre vold foo void bar Polymorphism is the ability to perform operations on an object without knowing exactly how the object will implement the operation In C polymorphism can be achieved at run time through the combination of several language features public class inheritance overriding virtual methods and using base class pointers or references to refer to derived class objects Polymorphism can also be achieved at compile time using templates IPL Information Processing Ltd 3 1 3 2 private virtual void helper bi class Derived public Base private virtual void helper I void test_driver Base base Derived derived base foo ii Test Casa Al derived bar E Test Case A2 In this example test case Al invokes Base foo on the base object which in turn calls virtual function helper on the base object invoking Base helper In test case A2 note that bar is not overridden in Derived so the inherited method Base bar 1s invoked on the derived object which in turn calls helper on the derived object invoking Derived helper Does the test_driver function fully exercise the Base class Does it fully exercise the Derived class Let s assume fo
19. Review of the IOPS firmware sources Review items main c debounc h debounc c dio h dio c Other files system h messages h se E Stephan Griinfelder intentionally no checklist Unit 5 Verification of Low Level Software Stephan Griinfelder IOPS code review meeting ergoe J Stephan Gr nfelder Static code checker demo program 2 2 Which code lines are return name obviously char MyName int i char name ll Joe Jakeson if i name 2 i fe AD A Stephan Griinfelder Contents Unit 5 Code review meeting software inspection Capabilities of static code checking tools Application of a code checker to the reviewed software Follow up review metric calculation and static check Unit test design Host target testing Getting started with Cantata and the TCD file format Stephan Griinfelder Static code checker demo program 1 2 include lt string h gt Which char MyName 01 char cUartData char OxFA 02 code lines main are S unsigned uiA unsigned cUartData obviously int i a 10 0 0 0 0 0 0 0 0 0 for i 0 i lt 10 i ali i for i 0 i lt 3 i char szString 10 ali cUartData strcpy szString MyName Stephan Gr nfelder Solution to the static code checker demo Stephan Gr nfelder Capabilities of static code checkers Intendation c
20. SRD SB 10 1 Maximum CPU Load The timing budget of the IOPS software shall load the CPU up to at most 80 R SRD SB 20 1 Idle Time If the MC4711 is not busy with processing it shall execute the idle command to save power and prolong the lifetime of the micro controller TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 10 Comment The idle command puts the MC4711 in a low power state The micro controller proceeds program execution after executing the idle command if and only if an unmasked interrupt has been served since the idle command R SRD SB 30 1 Memory Footprint The IOPS software shall consume at most 80 of the MC4711 on chip memory 5 3 Software Design R SRD SD 10 1 Software Codig Standard The IOPS software shall conform to the software coding standard of CS1 CS2 CS3 R SRD SD 20 1 Software Re use The IOPS software shall re use as much source code from the KJ project as possible R SRD SD 30 1 Programming Language The IOPS software shall be programmed in C whenever possible 6 Traceability This chapter captures the origin of the software requirements in tabular form minutes of the technical meeting ABB Thecompany 12 Apr 2003 G teborg one at MRD seciong MRD section4 ooo R SRD SD 20 Software Reuse decisition of the project management see TheCompany Mom 0009240 24 Mar 2003 R SRD SD 30 1 Programming Language for the MC4711 there is no other compiler available
21. Standard The IOPS software shall conform to the software coding standard of CS1 CS2 CS3 R SRD SD 20 1 Software Re use The IOPS software shall re use as much source code from the KJ project as possible R SRD SD 30 1 Programming Language The IOPS software shall be programmed in C whenever possible TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 10 6 Traceability This chapter captures the origin of the software requirements in tabular form ABB Thecompany 12 Apr 2003 G teborg ABB Thecompany 12 Apr 2003 G teborg arnold muskelkater at R SRD SD 20 Software Reuse decisition of the project management see TheCompany Mom 0009240 24 Mar 2003 R SRD SD 30 1 Programming Language for the MC4711 there is no other compiler available TheCompany Ltd Rosentalgasse 3 A 1140 Wien PLS Intelligent Oil Pressure Sensor software Requirements Document Document 004589 Issue 2 0 Date 12 Sep 2003 Name Function Signature Date Prepared Stephan Gr nfelder SW Designer i occcccnnccncnncnncnncnncnnnnncnnnnncnncnnnnnnnns deeeeeeeeaeeneeseegeees Checked Bernd Spiess Project nelle CC Robert Stolz VerifisatiomEngneer euere derer Helga Machart SW Quality Assurance saceiecclesexciacovateycdabauecctaseiuvbdacunesda dasdieceetexsdacedsted Approved Norbert Wichtig Project Manager A pieadiodesedateesduieaive TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 2 D
22. Vorschriften zeigen Empfehlung 10 Worttypen in Bezeichnern f r Unterprogramme Unterprogramme Prozeduren oder Funktionen im synchronen Programmfluss sollten Zeitw rter am Beginn des Bezeichners f hren z B StartTimer Eine Ausnahme bilden Bool sche Funktionen Asynchrone Routinen sollten im Bezeichner anf hren welches Ereignis sie bearbeiten z B TimerInterruptServiceRoutine Name oder Teil eines Namens fur eine Dieser Name wird ausschlie lich f r Variable Variablen verwendet deren Wert nicht von Interesse ist Teil eines Namens f r ein Unterprogramm Abfragen eines Objekts das Objekt selbst bleibt unver ndert Siehe auch take und Regel 9 Teil eines Namens f r eine Variable Die betroffene Variable ist ein Abk rzung f r identifier h ufig f r eindeutiger Schl ssel zur Nachrichten messages oder Prozesse Identifikation des Objekts zu dem tasks verwendet diese Variable geh rt Siehe auch key und type Teil eines Namens f r eine Variable Ein Schl ssel key identifiziert einen h ufig 1m Bereich relationale Datenbanken Eintrag in einer Datenbank oder verwendet einer anderen ein oder mehrdimensionalen Datenstruktur eindeutig Siehe auch JD Name oder Teil eines Namens fiir ein Entnehmen des obersten Elements Unterprogramm eines Stacks Name oder Teil eines Namens fur ein Einf gen eines Elements n eine Unterprogramm eindimensionale Datenstruktur meist Stack Teil eines Namens f
23. and faster 2 trying to be mean 3 Two seconds to be sure we cover all possible input values The counting of the number of clipped samples ensures that there is no algorithmic error suppressing Samples instead of clipping them Doing such pendantic tests by hand is dead boring and error prone 4 Do not forget to test a typical range as well 5 We are dealing with integers no tolerances or whatsoever apply 6 The location of the test script s executing the automatic test must be defined somewhere in the document at hand Test scripts can be C Programs bat files scripts from GUI testing recorders Matlab scripts or whatever But stick to one technique a comfortable test environment should allow to execute a bunch of tests by a single user interaction Note the test design omits out of range test cases In case there is the possibility to define an invalid input range i e from 1 to 1 in a GUI this must be tested 3 1 3 Business Cycle Testing Business Cycle Testing should emulate the activities performed on the Project over time A period should be identified such as one year and transactions and activities Medcare hf CONFI DENTIAL Page 8 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 that would occur during a year s period should be executed This includes all daily weekly and monthly cycles and events that are date sensitive such as ticklers The test design tem
24. and the last byte received R SRD PP 30 1 Reply Message Format The first data bytes of the reply message of the IOPS shall be the ID 23 The second byte shall be a copy of the first data byte of the command the IOPS is replying to R SRD PP 40 1 SetPosDebTime Command Upon receipt of the data bytes 2nd byte the IOPS software shall set the positive debounce time for the oil pressure switch to an appropriate offset POS where POS shall be interpreted as a signed two bit complement number and the programmable range shall be from 0 to 2 seconds TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 8 Comment the positive debounce time 1s the debounce time for the transition closed to opened switch R SRD PP 50 1 SetNegDebTime Command Upon receipt of the data bytes 2nd byle the IOPS software shall set the negative debounce time for the oil pressure switch to an appropriate offset NEG where NEG shall be interpreted as a signed two bit complement number and the programmable range shall be from 0 to 2 seconds Comment the negative debounce time is the debounce time for the transition opened to closed switch R SRD PP 60 1 SetRepIntv Command Upon receipt of the data bytes 1st byte 2nd byte the IOPS software shall report the debounced oil pressure switch state at intervals of min SEC 30 seconds as soon as it has been switched to operational mode by the message of R SRD PP 70 Eigentlic
25. be created and distributed 6 2 Test Logs Describe the format requirements or methods and or tools used to record and report on the test results 6 3 Defect Reports In this section identify the method and tools used to record track and report on test incidents and their status Medcare hf CONFI DENTIAL Page 19 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 7 References 7 1 Applicable Documents In case of a conflict between a document listed below and this document the listed document is applicable However such a conflict should be brought to the immediate attention of the project manager and document author Al Doc Number Project and Document title A2 7 2 Reference Documents In case of a conflict between a document listed below and this document this document is applicable However such a conflict should be brought to the immediate attention of the project manager and the author of the listed document R1 Doc Number Project and Document title R2 Rational GNOME RUP RationalUnifiedProcess index htm Medcare hf CONFIDENTIAL Page 20 Advanced Coverage Metrics for Object Oriented Software Executive Summary The use of structural coverage metrics to measure the thoroughness of a test set is a well understood technique However the application of the technique to object oriented software presents new challenges This paper presents object ori
26. bei der Erstellung von C Programmen Elektronik Heft 14 2002 S 66 71 DSTD The Company 003720 Design Standards for Embedded Systems Software 2 0 3 Definitions 3 1 Requirement Format and Numbering The requirements in this document are stated between a requirement number and a requirement delimiter The requirement number follows the subsequent syntax rule R SRD lt section gt lt number gt lt issue gt where lt section gt 1s an identifier for the chapter section or subsection to which the requirement belongs to lt number gt is an incremental number used within each instance of lt section gt lt issue gt is a number indicating in which issue of the specification the requirement was last changed Initially it 1s set to 1 The requirement delimiter is a parallelogram If a requirement is no longer valid it is replaced by the text deleted Requirement numbers may not be removed or reused The verb shall is used whenever the described practice is compulsory should is used for recommended practices Sentences without any of the two verbs within a formal requirement are explanations 3 2 Typographic Conventions Text in italic face represents a term that is defined or has has special meaning within this document An instance of such a term is not necessarily in italic face if the context will leave no doubt that the definition is applicable Bold face letters emphasise the textual content and impro
27. chstem Requirement R SRD SI 30 1 Debouncing Algorithm To compute the debounced oil pressure switch state the IOPS software shall use an algorithm that integrates over the raw sensor values If all raw values sampled within the debounce time correspond to a different state than the current debounced oil pressure switch state then the state must flip and it must take at least the same number of samples of opposite switch positions to flip the state again TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 9 Nicht wirklich gut erkl rt ein Beispiel oder eine Grafik w re nett Das must ist auch ein bisserl verwirrend Bei Revision besser weglassen 5 1 4 Reliability and Accuracy R SRD RA 10 1 Missing Parameters In case the IOPS is not programmed within 10 seconds after start up a re boot of the processor 1s necessary Was hei t programmed Das Start Command oder irgendein Kommando R SRD RA 20 1 PP bus Error In case the software cannot interpret a PP bus command or encounters an invalid software state it shall initiate a reboot of the processor within one second Comment The software should be operable as much as possible there is no need to log the cause of the error or stay fail silent once the software is fully operational Dieser Kommentar ist eine Hilfe damit man leichter erkennt was f r ein Bl dsinn hier gefordert ist Wenn die IOPS SW stirbt und der WD rebootet dann wartet der IOP
28. coverage the code must be fully exercised in each appropriate context Definition To take a specific example the inheritance context coverage variant of decision coverage for a routine in a particular context is simply the number of decision branches exercised in the context divided by the total number of decision branches in the routine The overall inheritance context decision coverage for the routine is then defined as the average of the inheritance context decision coverage in each context appropriate to the routine For a routine defined in a base class the appropriate contexts are the context which corresponds to the base class along with those corresponding to each derived class which inherits the routine unchanged Note that the routine need not more accurately can not be tested in the context of derived classes which provide an overriding definition of the routine Thus the overall inheritance context decision coverage for a routine 1s given by NumberOfContexts DecnBranchesExercisedInContext InheritanceContextDecnCoverage 71 100 S NumberOfDecnBranchesInRoutine x NumberOfContexts As with the standard coverage metrics system wide averages of inheritance context coverage across all routines in the system can also be defined An Example Using Decision Coverage Let s assume that functions foo and bar shared significant amounts of common code In an attempt to simplify the class the functions are
29. der Softwareentwicklung sein Ein Codierungsstandard ist aber ein Wegbereiter f r h here Qualit t bessere Wartbarkeit und schnellere Einarbeitungszeiten und kann somit Geld sparen sobald in einem Softwareprojekt mehr als eine Personen arbeitet Zusammenfassung Dieser Artikel informiert ber die Motivation der Einf hrung von Software Coding Standards und bietet einen umfassenden berblick ber die Themen die in einem derartigen Standard bedacht werden sollten Die Behandlung der Themen ist so weit gefasst dass sie f r alle relevanten Programmiersprachen im Bereich Eingebettete Systeme g ltig ist Referenzen 1 http msdn microsoft com library techart hunganotat htm Andrew Koenig C Traps and Pitfalls Addison Wesley 1988 http www andromeda com people ddyer topten html 4 Angelika Langer Stolpersteinen aus dem Weg gehen Elektronik 6 1998 Software wie PC lint oder lint Siehe zum Beispiel http www gimpel com Ein guter Programmstil will standardisiert sein Quellcode eines erfahrenen Programmierers unterscheidet sich meist schon im Erscheinungsbild von Quellcode der von einem Anf ngern erstellt wurde Profis halten sich konsequent an einen durchdachten Stil Wenn so ein Programmierstil in Form von Regeln und Empfehlungen dokumentiert ist dann k nnen sich Anf nger diesen leichter aneignen und selbst schneller Profis werden Ist die Einhaltung dieser Regeln f r alle Mitarbeiter eines Projekts verpflichtend
30. die Literale 1 2345E6 und1 2345e 06 Wenn wir Hexadezimalzahlen fur Zugriffe auf die Hardware verwenden ist es vorteilhaft die vorhandene Wortbreite in der Zahlendarstellung zu reflektieren Daher die folgende Empfehlung 7 Ziffernzahl fur Hexadezimalzahlen Die Anzahl der Stellen einer Hexadezimalzahl sollte die Anzahl der tatsachlich verwendeten Bits widerspiegeln Dazu Anwendungsbeispiele in C define BITMASK Ox00000FFO Maske ftir 32 bit Werte char cBlinkPattern OxOF 7 TED A00mSs Cine 200 ms us unsigned uiAdcZeroLevel 0xF000 i Wea oid Buseinterface 7 Irref hrend ist wenn f r eine 16 bit Gr e eine Hexadezimalzahl verwendet wird deren Stellenanzahl auf ein 32 bit Format schlieBen lasst Um derartigen Unfug zu verbieten konnen wir entweder die letzte Empfehlung in eine Regel umwandeln oder eine weitere entsprechene Regel formulieren die das explizit verbietet Beides wird uns nicht davor sch tzen dass Programmiersprachen prozessorabh ngige Komponenten besitzen k nnen und in C etwa der Typ int abgeleitet von der internen Verarbeitungsbreite des Prozessors z B 16 oder 32 bit breit sein kann Hier kann die projektiibergreifende Definition von Typen mit fester Stellenanzahl helfen Beispielsweise verwenden manche Entwicklungswerkzeuge den Typ INT32 fur ganzzahlige 32 bit Werte oder UINT16 als 16 bit Typ fur positive ganze Zahlen in Form eines Makros Fur jeden Compiler bzw Prozessor muss dann nur die ent
31. ee neu le ee bein Pole of Sen a EE DS Ao j Assemblerbeispiel Die Sprungmarke Diekunk von ast nicht ein gente fobs onus cese kunke en m Gegensatz zur ENEE Parameter x wird in Register r0 bergeben Weitere verwendete Register rl IE IA IE Ie al Deals a I Io SABA IS TAO ol sea EO compro Sei E ae ro EE if le jump DieFunktionLElO rl 220 fo KEE uekung eins Blocks area OMPI Fri le are storie Se lee ae Defoe sera ae Valine HOP weiterer Programmcode Label negative Einr ckung HOD weiterer Programmcode E O Son te Oya E if le jump DieFunktionLE100 kere Pie Wieden SI CIO ojo VI E MIS EE nop E EE code 3 DieFunkt ionLEl00 DieFunktionLElO as o aaron E E Listing 4 Beispiel zu Sprungmarken und Kommentierung von gro en Bl cken sowie zur Verwendung von Leerzeilen Regel 19 Beschreibungen von Funktionen und Unterprogrammen Funktionsbeschreibungen m ssen alle Parameter Fehlerf lle und den R ckgabewert der Funktion beschreiben Bei ambivalenter Interpretationsm glichkeit muss erw hnt werden ob ein Parameter als Eingabewert Ausgabewert oder fur beide Zwecke verwendet wird Funktionsbeschreibungen mussen dem in Listing 4 gezeigten Layout folgen Wenn Sie eine Bibliothek erstellen dann wird im Regelfall dem Benutzer der Bibliothek nur mehr eine Header Datei als einziger Teil des Quellcodes zuganglich gemacht Daher sollten Sie Funktionen auch dort beschreiben
32. in each possible state the behaviour of the class is state dependant State based context coverage is designed to measure how fully this behaviour has been tested Consider a typical class with state dependent behaviour a bounded stack A bounded stack can be in one of three possible states empty partially full or full The behaviour of the stack is qualitatively different in each state For example the pop Operation removes and returns the top element from the stack in states partially full or full but throws an exception and leaves the stack unmodified in state empty The class interface for the bounded stack class is shown below class BoundedStack pu ubliies BoundedStack size_t maxsize BoundedStack void pushin gt int pop struct underflow std exception struct overflow std exception Black Box Testing using Entry Point Coverage When testing a class the first step 1s to write test cases to exercise the public interface to the class int test driver BoundedStack stack 2 Stack pusn I stacki popis destructor called implicitly at end of block We can use entry point coverage to ensure that the test cases exercise each of the methods of the class The test cases above achieve 100 entry point coverage However it is clear that this test set does not fully exercise the BoundedStack class the stack never becomes full and an exception is
33. or implementation of testing List any constraints that may affect the design development or implementation of testing Acronyms ADC Analog Digital Converter HW Hardware IDE Integrated Development Environment I O input output LED Light Emitting Diode RTOS Real Time Operating System RUP Rational Unified Process SW Software TBC To Be Confirmed TBD To Be Defined UI User Interface XP Extreme Programming Medcare hf CONFI DENTI AL Page 3 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 2 Requirements for Test This chapter lists all applicable software requirements and identifies the test case verifying the correct implementation of the requirement in form of a tracablility matrix In case a requirement is not tested the right hand column of the following table states not tested In case more than one input document is at hand i e a system specification and a interface specification then create two tables The tables should preferably be extracted from tools such as DOORS Requesite Pro Note that this is a boring thing to do but the Matrix careful creation review and update is an essential part in the proof that really all requirements are implemented and tested The complementary part in this proof are the test procedures itself That is why the matrix and the test procedures reside in the same document An example matrix is given below R Cl 10 Device Init Sta
34. serve as targets of test Of what size are the test log files Is the test data amount a problem for our server hard disks Medcare hf CONFI DENTIAL Page 17 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 5 Project Milestones 5 1 Milestones Plan Feel free to identify milestones e g testing hardware that must be ready by a time test data that must be generated etc However at least think of the following milestones Milestone Task Effort planned Start Date planned End Date planned Plan Tests Design Tests Implement Tests Execute Tests Evaluate Tests Explain how these milestones are assessed 5 2 Progress Assessment How are the testing status and effort updates reported to the management Think of updating the table below at regular intervals Use the deviation of the two effort columns to revise your time plan and get a more realistic effort estimations For status assessments and reports to the management you might use a table that shows the test progress as follows lastest effort estimation aR pss MT 100 100 es 100 50 0 o running error lt free ST XX FTO1 3 person days 4 days 5 O oO O o 3 O O oO o o O Medcare hf CONFI DENTI AL Page 18 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 6 Deliverables 6 1 Test Model This section identifies the reports that will
35. so sprechen wir von einem Software Coding Standard Der folgende Artikel pr sentiert Regeln zur Verwendung von Zahlen und Namensgebung die auf eine Vielzahl von Programmiersprachen anwendbar sind Deren Beachtung erh ht die Lesbarkeit des Quellcodes die Zusammenarbeit im Projekt und die Wartung der Software wird damit vereinfacht Elementarteilchen des Quellcodes Bei der Erstellung der erw hnten Regeln m ssen wir dort beginnen wo das Leben eines Programms beginnt bei der Verwendung von Buchstaben Ziffern und der nat rlichen Sprache Keine Angst Esoterik hat hier nichts verloren Vielmehr definieren wir zun chst Bausteine die wir dann zu m chtigen Konstrukten zusammenf gen werden Die erste Frage die Sie sich stellen m ssen ist die welche nat rliche Sprache Sie zur Dokumentation verwenden In vielen Fallen wird dies Englisch sein folglich muss dann auch Ihr Coding Standard auf Englisch sein In unserem Artikel werden wir uns jedoch weiter an die deutsche Sprache halten Damit die Inhalte des Artikels besser n einen englisch verfassten Standard bernommen werden k nnen verwenden wir englischsprachige Bezeichner und formulieren daher unsere erste Regel 1 Dokumentationssprache Alle Software Dokumente und Programmkommentare mussen in deutscher Sprache geschrieben sein benutzerdefinierbare Bezeichner in Programmen mussen englisch sein Nahezu jeder Quereinsteiger stolpert ber verwendete projekt oder firmenspezifisch
36. system testing d gt Find weaknesses in previous testing steps Find weaknesses of the system test process if flaw was found after testing Assess readiness for delivery Test process must be improved Personnel must be trained Unabigousness of specifications should be checked Stephan Griinfelder Contents Unit 8 Generating and using system test error statistics Running the designed IOPS system tests System Test Summary Report Extreme Programming Risk based testing Conclusion Feedback Stephan Griinfelder Generating and using system test error statistics Why statistics on system testing Find weaknesses in previous testing steps Find weaknesses offie system test process if flaw Test process should be questioned Personnel must be trained More caution must be taken with certain software sima dH Efer Generating and using system test error statistics Why statistics on system testing Find weaknesses in previous testing steps Find weaknesses of the system test process if flaw was found after testing Assess readiness for delivery ea Stephan Gr nfelder release software now Running the designed OPS system tests Use either your personal systemt tests or the sample system test document and break the IOPS software PP bus simulator commands O open oil pressure switch c close oil pressure switch b sen
37. terminal window A digital I O card with C C and LabView drivers An IEEE bus PCI card with C C drivers A digital storage oscilloscope programmable via IEEE bus A function generator programmable via IEEE bus to what extent will you automate software system testing Stephan Griinfelder Economy 50 J09 014 Verification Effort Stephan Griinfelder 28 Write the IOPS System Test Plan Let s fill out the management sections of the Software Test Plan Template that MyConsultant wrote for the company Medcare Let s see of much use it is to IOPS Stephan Griinfelder Functional System Test Design Techniques Equivalence partitioning Boundary value analysis Traceability E mail by key customer nn R SRD AD 10 1 marketing a requirements document pg 4 ST XY FTO1 AD7768_checkintegrity ST XY FT03 functional system tests Stephan Griinfelder Equivalence Partitioning Partition the input output domain of a program into a finite number of equivalence classes such that one can reasonably assume that the test of a representative value of each class is equivalent to a test of any other value Examples e N e Triangle self assessment test of unit 1 AR Test a program that returns the absolute value of an integer e Test a program that adds two integer values Stephan Griinfelder Error Guessing Never just test the function of the requirements Think
38. test ID use LT as code that identifies Load Tests 3 1 7 Stress Testing Stress testing is a type of performance test implemented and executed to find errors due to low resources or competition for resources Low memory or disk space may reveal defects in the target of test that aren t apparent under normal conditions Other defects might result from competition for shared resources like database locks or network bandwidth Stress testing can also be used to identify the peak workload the target of test can handle For PC based software think of stressing the system by simultaneously e multiple users performing the same transactions against the same data or accounts e lowering RAM to least possible specified e filling up the harddisk e do the worst case transaction volume or mix For embedded software think of e a nearly full Flash Memory e interrupts coming at highest rates e excessive service request or data rates For stressing and load testing of network based applications a lot of tools exist For embedded systems it is recommended to regard memory tests i e stack size as special stress tests since memory could be regarded as a resource The following example is such a test taken from the Embla N S7000 CU DSP Software Test Plan Medcare hf CONFI DENTIAL Page 11 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 Identification ST CUDSP STO1 Check that the stack space reserved is su
39. the database applications and system to a desired known state The following types of conditions are to be included in the testing power interruption to the client power interruption to the server communication interruption via network servers interruption communication or power loss to controllers incomplete cycles data filter processes interrupted data synchronization processes interrupted invalid database pointer or keys invalid or corrupted data in database flash memory Tests created for Function and Business Cycle testing should be used to create a series of transactions Once the desired starting test point is reached the following actions should be performed or simulated individually Power interruption to the client power the CPU down Power interruption to the server simulate or initiate power down procedures for the server Interruption via network servers simulate or initiate communication loss with the network physically disconnect communication wires or power down network servers or routers Interruption communication or power loss to controllers simulate or physically eliminate communication with one or more controllers or devices Once the above conditions or simulated conditions are achieved additional transactions should be executed and upon reaching this second test point state recovery procedures should be invoked Medcare hf CONFI DENTIAL Page 13 D 0209 00 S
40. then the IOPS does not respond to any command to show it is broken In case of errors during the operation i e assertion failures the MC4711 reboots as shown in the state diagram of Figure 1 assertion failure A Program Operation A 4 ___ 4 automatic unless start command memcheck fails Figure 1 State transitions of the IOPS TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 7 4 3 Hardware The IOPS is based on the MC4711 Micro Controller which implements a fully operational PP bus controller Thus issues like bus arbitration address decoding and message checksums are fully transparent to the firmware The MC4711 is a 16 bit controller running at 10MHz with 16kB on board RAM and 16kB EEPROM It also contains a digital I O port One of its pins is connected to the mechanical switch one to an external watchdog and one to a light emitting diode HW 5 Specific Software Requirements This chapter contains the formal requirements on the IOPS software 5 1 Functional Requirements 5 1 1 Requirements on the Initialisation Process R SRD INIT 10 1 Self Test After a reset the IOPS software shall perform a selft test that checks the RAM and the processor core R SRD INIT 20 1 Self Test Fail Silence The IOPS software shall only reply to PP bus commands when the self test at start up passes 5 1 2 Requirements on the PP bus Communication Each PP bus message consists of 4 bytes The first byte is a
41. und sauberes Erscheinungsbild des Gesamtprojektes Das Auffinden von Referenzen mit Hilfe von Editorsuchfunktionen wird wesentlich erleichtert speziell bei der Wartung von Code dessen Autor man nicht selbst ist jo ers img e Mo cae nun und enana den Ineo elie lbs x Das gezeigte E a EE foe OHER OCHNTE CEA OUT secuela lies 1s EE AMB So SIA a ote ae eee es REI MA int iWert2 L iWert3 2 zero kee tPaar een 12 RES ze tPaar iY tPaar iX 19 ASS ren ae iWertl iWert2 iWert3 AS Sl LA int piWert2 amp iWertl EE iScheinbarZeigerVariable k evs siete eae Ee REG CIN 6 Viet letzte LW See Nemes Weis St Reel Tr ven lee y TSS eae Ca o ARES A ME A else Seller lo er EE IAE E tPaar OO Taler PAOLA Ine Wetton siert PMO a Aa 2 TE TOR ePaar y tPaar u Ek PS TOI ey iWertl iWert2 iWert3 Deore int piWert2 amp iWertl Fe OR iKeineZeigerVariable Se Gece ee alien OK way as Werne nern i OK inerto Were Wera tg or So Listing 1 Demonstration der Regeln 1 bis 7 Klammernsetzung Klammern sind wohl eine der meist verwendeten Elemente vieler Programmiersprachen In C und verwandten Sprachen definieren runde Klammern die Reihenfolge von Auswertungen in ar thmetischen Ausdr cken eckige Klammern enthalten Indizes f r Feldvariable geschwungene Klammern definieren Programmbl cke In C werden spitze Klammern nur vom Preprozessor verwendet in C werden dies
42. und vor allem auf die f r deren Verwendung relevanten Randbedingungen eingehen Interne Funktionen etwa Funktionen mit dem Attribut static in C oder private member functions in C m ssen dem Benutzer der Bibliothek nicht bekannt sein deren Beschreibung sollte daher nur in der Datei mit der Implementierung der Funktion stehen Daher lautet die n chste Empfehlung Empfehlung 20 Ort der Funktionsbeschreibung Beschreibungen von internen Funktionen sollten am Ort ihrer Definition an der Stelle der Implementierung zu finden sein Beschreibungen extern sichtbarer Funktionen die Bedeutung ihrer Parameter R ckgabewerte und Randbedingungen f r die Funktionsverwendung sollten am Ort der Funktionsdeklaration in einer Header Date1 zu finden sein Um das Layout von Quellcode qualitativ aufzuwerten bedarf es nicht nur einer guten Struktur zum Auffinden von Funktionen und Bl cken Uberlange Zeilen sind nicht nur bei machen Editoren b sartige Fallen sie zerst ren auch das Layout beim Drucken von Quellcode nachhaltig Daher ist es unabdingbar sich an eine maximale Zeilenbreite zu halten Die L nge dieser Zeilenbreite sollten Sie an den in Ihrer Firma eingesetzen Editor anpassen insbesondere an dessen Angebot an skalierbaren nicht proportionalen Schriftarten sowohl f r den Bildschirm als auch f r die Druckausgabe Editor und Programmausdruck m ssen einen nicht proportionalen Zeichensatz verwenden da alle Vorschriften zur horizontalen Ausricht
43. what error could be in the software Caution Think of errors in the test environment positive negative testing Stephan Griinfelder State transition testing Error guessing Black Box Stephan Griinfelder Boundary Value Analysis Experience shows that test cases that explore boundary conditions have a higher payoff than test cases that do not Boundary conditions are those situations directly on above and beneath the edges of input or output equivalence classes Extend the examples you did before gt e Triangle self assessment test of unit 1 Test a program that returns the absolute gt value of an integer oa d e Test a program that adds two integer values Stephan Griinfelder System Test Categories Function Testing Failover and Recovery Data Integrity Testing Testing Business Cycle Testing Configuration Testing Performance Profiling Installation Testing Storage Testing Documentation Testing Load Testing Stress Testing Volume Testing Security and Access Control Testing Stephan Griinfelder Function Test Design Guidelines Use the described black box techniques Make the tests hard to pass Do not test things which are not required a mistake that applies mainly to automated tests Make the tests orthogonal i e when you have to change one requirement a minimal set of tests must be changed Give clear orders in the textual description of the design use active voi
44. who numbers each RID uniquely and forwards it to the author for comment Authors add their responses on the RID form and then return the it to the secretary RIDs are categorised as major minor or editorial Stephan Griinfelder 41 Review techniques walkthrough meetings Review Meeting The author provides an overview of the review items A general discussion follows during which issues of the structure function and scope of the review items should be raised The author then steps through the review items Members raise issues about specific points as they are reached in the walkthrough As the walkthrough proceeds errors suggested changes and improvements are noted by the leader Stephan Griinfelder Review techniques software inspection Output e alist of the members e alist of changes and defects noted during the software inspection e alist of actions with persons responsible identified and expected dates for completion defined e recommendatio rough team on medy e defects and dispose of unresolved issues e g further meetings Stephan Griinfelder Review techniques technical teview Review Meeting Major RIDs are discussed followed by the minor and editorial RIDs The outcome of the discussion of any defects should be noted by the review leader in a review decision box on the RID form This may be one of CLOSE UPDATE ACTION or REJECT Stephan Griinfelder Review techniques technic
45. 1 Test Case 2 Stephan Gr nfelder McCabe s integration complexity Module design complexity denoted as iv by McCabe measures the individual effect of a module upon the program design The module design complexity is evaluated by marking the nodes of the control graph of the module that contain calls to external modules Then the graph is reduced according to the rules listed below 1 marked nodes cannot be removed unmarked nodes that contain no decisions are removed edges that return control to the start of a loop that only contains unmarked nodes are removed edges that branch from the start of a case statement to the end are removed if none of the other cases contain marked nodes Stephan Griinfelder Integration complexity Integration complexity 1 1 lt 5 Remove node 8 Stephan Gr nfelder McCabe s integration complexity The module design complexity is the cyclomatic complexity of the reduced graph In summary module design complexity ignores paths covered in module testing that do not result in calls to external modules The remaining paths are needed to test module interfaces Stephan Gr nfelder Integration complexity cp vpo bi a Ba a aen r Ze a Ma ei ai V el d e j yn bh E a is T i Ka Gd Ge A Ba K d A we he d F ze r ps d i g ge i d ri d f K L A ys L 1 A f Remove node 2 I Ramos rode d L Remo mo e
46. C pressure cut off switch should be named ACCtl_swtCutoff_C an instant shut off shall also be fulfilled when the cutoff switch label ACCD_stACCutoff is not set Stephan Griinfelder gt A Bad requirement 1 Ay R SRD Strt 10 2 Bit PWR of the Start Release Message limits the activaton time of the starter motor After ECU init this release bit is set The bit will be reset after the starter has been activated for a calibratable time and in case of ignition off After a recovery and in the initialisation the release bit has to be set Stephan Griinfelder Bad requirement 3 KA Af R SRD Dia 15 1 The diagnosis can be turned off in certain vehicle conditions message from the engine coordinator Stephan Gr nfelder Bad requirement 5 73 R SRD StrtCtl 35 1 For the engine start instead of the average engine speed StSysCtl_nEngStrtCtl_mp shall be used as shown in the figure below Be a eles C e Or o A q Fary O Stephan Griinfelder AN Bad requirement 6 CA gt A 3 5 Quantity Governing Exceptions IE Since the CCTL Governor works as a quantity Governor the torque coming as input to CCTL shall be converted into quantity Injection Mass In the same way the quantity needs to be conveted into torque to get an interface in the torque path The Chrysler 395 CCTL has fuel density value 1 and hence injection mass and quantity are same Hence PRP_NORM_CONV_ FAC s
47. Configuration Items Data List 2 1 Applicable Documents MRD TheCompany 004537 Little Stream Marketing Requirements Document V2 1 ICD ABB IA PL 1520 00 PowerPlan Bus Interface Control Document Release 1 0 HW TheCompany 004545 IOPS PCB Design 1 0 TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 5 MoM TheCompany 004596 Minutes of Meeting of the external PLS IOPS System Requirements Review Wr Neutstadt 8 Sep 2003 2 2 Reference Documents CS1 F Griesauer Guter Code braucht Ordnung Teil 1 Universelle Regeln zur Namensgebung und zu Zahlenformaten Elektronik Heft 18 2001 S 52 59 CS2 S Programmierer Guter Code braucht Ordnung Teil 2 Das Code Layout Elektronik Heft 8 2002 S 74 81 CS3 A Schlau Guter Code braucht Ordnung Teil 3 Fehlervermeidung bei der Erstellung von C Programmen Elektronik Heft 14 2002 S 66 71 DSTD The Comany 003720 Design Standards for Embedded Systems Software 2 0 3 Definitions 3 1 Requirement Format and Numbering The requirements in this document are stated between a requirement number and a requirement delimiter The requirement number follows the subsequent syntax rule R SRD lt section gt lt number gt lt issue gt where lt section gt is an identifier for the chapter section or subsection to which the requirement belongs to lt number gt is an incremental number used within each instance of lt section gt lt issue gt is a number indi
48. FI DENTIAL Page 1 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 Table of Contents 1 IR TUE ee ee O POE CRE o E E E E 3 1 1 POS E 3 1 2 A sea ange vances Eo E e A 3 1 3 RA 3 1 4 PCT OMY E 3 2 ROGUE ERIS for TES ceca 4 A o Po 5 3 1 A A 5 3 1 1 Data lite cares armenia dono ae re 5 3 1 2 FONCHON TESOURO nia 6 3 1 3 BUSINESSCHLIE Kg A oie lO a A 8 3 1 4 BE Tuten Ce MR due asian ee 9 3 1 5 Performance Profiling occocococnccocnococonnnccnnnconnnconnnnoronnonnnnnrrnnnrnnnnnonnnrrnsnereninrnnns 10 3 1 6 Loan Te N EE 11 3 1 7 SEO TO UNO EEN 11 3 1 8 VOLUME Terre ne en 12 3 1 9 Beie f ie NG A Pe oo o UE CO O E 12 3 1 10 Security and Access Control Testng 12 3 1 11 Failover and Recovery TesiNd running 13 SE lZz ee ie e lee Teil Gene ocios 14 311 E une E ie Te N EE 14 3 1 14 Software Build Consistency Check 15 3 2 RRE 15 ROSE AA e oO A AE E ee 16 4 1 FOSS EE 16 4 2 e e E e e POE o A 17 5 Project MIE e E 18 5 1 NE SEON ES Plain ves ia eae moaned ee ee eae ested 18 5 2 o CMV see eek 18 ESCA EE 19 6 1 Te el ias 19 6 2 EA 19 6 3 Be dh a 19 De EN een crag ote tenance A 20 7 1 APPIICADIE DOCUMENTS ee raid 20 7 2 Referenc DOCUMENTS EE 20 Medcare hf CONFI DENTI AL Page 2 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 1 1 1 2 1 3 1 4 Introduction This is a Software Test Plan Template based on the RUP template R2 for
49. Issue 1 0 same users In each case verify those additional functions or data are correctly available or denied Tests on the system level might require to change configurations in the operating system or network interface Therefore system level tests might have to be manual tests For the ID of Security and Access Control Test Descriptions use the acronym SA 3 1 11 Failover and Recovery Testing Failover and RecoveryTesting ensures that the target of test can successfully failover and recover from a variety of hardware software or network malfunctions with undue loss of data or data integrity Failover testing ensures that for those systems that must be kept running when a failover condition occurs the alternate or backup systems properly take over for the failed system without loss of data or transactions Recovery testing is an antagonistic test process in which the application or system Is exposed to extreme conditions or simulated conditions to cause a failure such as device Input Output 1 0 failures or invalid database pointers and keys Recovery processes are invoked and the application or system is monitored and inspected to verify proper application or system and data recovery has been achieved Use the following generic test description for ideas to create your own tests Identification ST Test Object Acronym FRO1 Test Objective Verify that recovery processes manual or automated properly restore
50. Listing 2 sehen kann ist die Struktur von zusammenhangenden i f else Folgen der Struktur einer switch Anweisung hnlich Doch w hrend sich die Bl cke der F lle 1 bis 4 in Listing 2 gegenseitig ausschlie en erlaubt die switch Anweisung durch das gezielte Weglassen der Instruktion break auch mehrere Optionen zu durchlaufen Diese Technik erlaubt die Erzeugung sehr effizienten Codes f hrt aber leicht zu Fehlinterpretationen Daher sollte man diesen Trick immer dokumentieren wie Listing 3 zeigt Im Sinne defensiver Programmierung sollte auch immer ein default Zweig vorhanden sein Regel 10 Struktur der switch Anweisung Eine swit ch Anweisung muss die in Listing 3 gezeigte Form haben Im speziellen muss das Auslassen der break Instruktion dokumentiert sein und ein de fault Zweig vorhanden sein Switch iExpression Case NO ON Code zu diesem Fall Neceser EE ee break Case OMAN ZT case OPTIONS case OPTION4 pio de a elena sli Mesa eii sy break Case OEI INS AS zus IS eo Vier oil elt ender momm cme ei een veal eer lamer alos la lo ken El ade ACHTUNG gt KEIN break case OPTION ee il all gan ze era ee o CiU break default FehlerReport __LINE _ break ME ao Listing 3 Gut gew hlte Struktur einer switch break Anweisung Die break Instruktion begegnet uns auch in Schleifen und erm glicht einen Abbruch der Schleife Speziell n verschachtelten Routinen sollte man be der Instruktion kommentiere
51. PROBLEM LOCATION 5 PROBLEM DESCRIPTION 6 RECOMMENDED SOLUTION 7 AUTHOR S RESPONSE 8 REVIEW DECISION CLOSE UPDATE ACTION REJ ECT underline choice Annotated References Standards online literature magazines and books Bach99 BeckO1 Fagan86 FDA02 Hal103 Myers78 Perry95 IESRA IEEE IPL99 PSS 05 0 James Bach Test Automation Snake Oil See http www jamesbach com reprinted from Windows Tech Journal 10 96 Funny to read article Teaches us that test automation is good but should be implemented with care Kent Beck Extreme Programming Explained Addison Wesley 2001 Kent Beck is one of the protagonists on the XP wave His book is easy to read and very American XP is cool funny and you ll make a lot of money M E Fagan Advances in Software Inspections IEEE Transactions on Software Engineering Vol SE 12 No 7 July 1986 You don t want to read that I haven t read it either U S Department Of Health and Human Services Food and Drug Administration CDRH General Principles of Software Validation Final Guidance for Industry and FDA Staff January 11 2002 published on the WWW Unless you want to submit a medical device to the US market there is no need to read that publication However it is really a good collection of advices Payson Hall Knowing the Odds A practical three step risk management process you can accomplish in one afternoon
52. S auf eine neue Parametrisierung anstatt entweder zu melden dass er neu parametrisiert werden muss oder die alten Parameterwerte neu zu verwenden R SRD RA 30 1 Watchdog Kicking The software shall kick a watchdog at least once a second and at most 10000 times a second by setting bit 1 of the digital I O port for at least 50 clock cycles and by clearing the bit afterwards Comment the external watchdog will reset the MC4711 if it is not kicked for 1000ms A deadlock resolved by the watchdog should in the best case not visible to other devices on the PP bus Das wird ja wohl nicht erf llt Sp testens ab der FMEA FTA wird das klar bei einem WD reset in operational h rt der IOPS auf seinen Zustand zu melden Eigentlich ist das ein Requirement und kein Kommentar 5 2 Software Budget R SRD SB 10 1 Maximum CPU Load The timing budget of the IOPS software shall load the CPU up to at most 80 R SRD SB 20 1 Idle Time If the MC4711 is not busy with processing it shall execute the idle command to save power and prolong the lifetime of the micro controller Comment The idle command puts the MC4711 in a low power state The micro controller proceeds program execution after executing the idle command if and only if an unmasked interrupt has been served since the idle command R SRD SB 30 1 Memory Footprint The IOPS software shall consume at most 80 of the MC4711 on chip memory 5 3 Software Design R SRD SD 10 1 Software Codig
53. STQE The Software Testing amp Quality Engineering Magazine Vol 5 issue 2 March April 2003 pp 34 40 After reading articles in this magazine you will wonder how it is possible to write so many lines about so obvious things Glenford Myers The Art of Software Testing John Wiley amp Sons 1978 A classic However even though software testing techniques change very slowly over time it clearly does not reflect the state of the art William Perry Effective Methods for Software Testing John Wiley amp Sons 1995 Don t read that Full of bla bla tables and metrics nobody ever uses ANSVIEEE Std 1028 1988 IEEE Standard for Software Reviews and Audits Better let it in the shelf unless you want to become an SQA or auditor IEEE Standard Glossary of Software Engineering Terminology 1990 Good but quite expensive However you will find cites in the WWW for many of the definitions of this standard Advanced Coverage Metrics for Object Oriented Software IPL Information Processing Ltd 1999 This is a white paper of a company selling unit test tools It is appended to the lecture notes European Space Agency Board for Software Standardisation and Control ESA software engineering standards ESA PSS 05 0 Issue 2 February 1991 PSS 05 10 PSS 05 03 Rosenb02 RUP A very good overview of a quite formal software lifecycle model Can be purchased from ESA Black copies of this standard can be found in the web
54. Software Test Plans It is however stricter than RUP and more detailed i e in RUP the test case description lacks detail Purpose This document describes the planned test activity of the Project Test Object Identify existing project information and the software components that should be tested e g refer to the requirements document Describe the basic testing strategies to be employed e g black box SW SW interface SW HW integration testing with oscilloscope Standard resources needed to perform these tests are defined in chapter 4 special test tools are identified in section 3 2 Background Enter a brief description of the target of test components application system etc and its goals Include information such as major functions and features its architecture and a brief history of the project This section should be not longer than three to five paragraphs Scope Describe the stages of testing covered in this document for example Linting Code Reviews Unit Integration or System Testing and the types of testing that will be addressed by this plan such as Function or Performance Provide a brief list of the target of test s features and functions that will or will not be tested List any assumptions made during the development of this document that may impact the design development or implementation of testing List any risks or contingencies that may affect the design development
55. Stream PLS a sensor network for medium sized water power plants As a Software Requirements Document SRD it is the baseline for the software development for the Intelligent Oil Pressure Sensor IOPS which reports the oil pressure state of a turbine on the PowerPlant bus 1 2 About this and Previous Issues Issue 1 0 of the document was prepared for the PLS IOPS System Requirements Review It is mainly based on the PLS Marketing Requirements Document MRD and on the PowerPlant bus Interface Control Document ICD Issue 2 0 is an update based on the review results MoM 1 3 Acronyms AD Applicable Document CPU Central Processing Unit IOPS Intelligent Oil Pressure Sensor LSB Least Significant Bit PCB Printed Circuit Board PLS Project Little Stream RD Reference Document RID Review Item Discrepancy SRD Software Requirements Document 2 Documents In the event of a conflict between this document and an Applicable Document AD the AD shall have the precedence In the event of a conflict between this document and a Reference Document RD this document shall have precedence Any such conflict should however be brought to the attention of TheCompany Ltd for resolution This document has been established based on the issues of ADs and RDs as given below Issue changes of ADs and RDs will lead to an update of this document only in case of impacts on its content The valid documentation status 1s reflected in the relevant
56. T approach further recommends that any methods which are inherited by a derived class and which interact with any re defined methods should be re tested in the context of the derived class The focus of this re testing is to exercise the interactions between the inherited methods and the re defined method s primarily the calls between the methods This recommendation could be interpreted as a coverage requirement of 100 call pair coverage of the inherited methods in the context of each derived class Strict Coverage In practice the integration test cases which exercise the interactions between methods are often spread throughout the complete test suite for the class Rather than separating the integration test cases out sometimes the easiest way to ensure that interactions are thoroughly re tested is to re run all of the base class test cases This conservative approach can be enforced through the application of a stricter coverage requirement namely that 100 decision coverage is achieved for each base class method in the context of every derived class by which it is inherited Achieving Inheritance Coverage Is Easy During unit testing the effort required to achieve inheritance context coverage is not significantly greater than that required to achieve coverage according to traditional metrics Typically no additional test cases are required Instead test cases already written to test the base class are used to re test the inherited
57. Teil von Datendeklarationen Ein un rer Operator der in der Bezeichnung einer Variablen vorkommen kann darf vom Variablenbezeichner nicht getrennt werden In vielen gangigen Codierungsstandards gibt es scharfere Vorschriften betreffend der Verwendung des Leerzeichens anstelle der beiden folgenden Regeln Oft wird beidseitig jedes binaren Operators wie z B amp amp ein Leerzeichen gefordert Die Motivation hinter der hier vorgestellten weniger strikten Handhabung ist die Moglichkeit Code Zeilen die bei Verwendung von aussagekraftigen Bezeichnern tendenziell eher zu lang geraten auf diesem Weg erforderlichenfalls zu k rzen Regel 6 Leerzeichen und bin re Bool sche Operatoren Binaren Bool schen Operatoren muss ein Leerzeichen direkt vorangehen und eines direkt folgen Regel 7 Leerzeichen und andere bin re Operatoren Die Leerzeichensetzung um bin re Operatoren darf visuell nicht den Vorrangregeln be der ar thmetischen Auswertung des Sprachkonstrukts widersprechen Ein Leerzeichen muss entweder auf beiden Seiten des Operators stehen oder auf keiner der beiden Seiten Beispiele zu den vorgestellten Regeln sind in Listing 1 angegeben Wie schon eingangs erw hnt wenden viele erfahrene Programmierer diese automatisch an ohne sich je Gedanken gemacht zu haben w e man diesen Stil formal erfassen k nnte Die Definition von Regeln und deren konsequente Anwendung innerhalb eines Projektteams sorgt nicht nur f r ein einheitliches
58. Verification of Low Level Software Lecture Notes Table of Contents Handout units top l IOPS Software Requirements Document 10 46 IOPS Software Requirements Document 20 56 IOPS Architectural Design Document 10 66 Traceability Matrix for IOPS System Tests oooooooooonocononanonoccccccnnononnnnnnnnnnnnnnnos 76 Medcare Software Testplan Template TH Advanced Coverage Metrics for Object Oriented Software occcccccnnnccnnooccnnnns 98 Artikelreihe ber Software Codierungs Standards cccccccccesssseeeeeeeeeeeees 112 Risk Based ESOO nein een 148 Review Item Discrepancy RID Form ooccnnnnnnncnncnnnnnnnnnnnnnonocccnnnnnnnnnnnnnanoconnnos 151 PATNI CALC CU CONC ee A AN 152 Copyright 2004 by Stephan Gr nfelder Copyright 2001 by WEKA Zeitschriftenverlag Copyright 1999 by IPL Information Processing Ltd Verification of Low Level Software Reviewing and Testing in the Software Life Cycle with an Emphasis on Embedded Systems Stephan Griinfelder Contents Unit 1 Motivation Self Assessment Test Definitions V Model motivation of an early V amp V Special considerations for embedded systems Review techniques How to review a software requirements document Stephan Griinfelder Contents Unit 2 Using UML to analyse requirements amp scenarios FMEA Fault Trees Review of the Software Requirements Document 2 0 Technical Review Meeting Test automation advantages drawbacks costs Writing a S
59. aber auch fatale Folgen haben wie ein Beispiel noch zeigen wird Das einfachste Unterscheidungsmerkmal ist die Gro Kleinschreibung Eine unn tige Fehlerquelle bei hardwarenaher Programmierung ist die Verwechslung von Variablen mit Unterprogrammen deren Einsprungadresse der Compiler oder Assembler als Variable interpretieren k nnte Wir formulieren daher folgende Regel 15 Schreibweise von Bezeichnern f r Unterprogramme Unterprogramme Prozeduren oder Funktionen m ssen mit einem Gro buchstaben beginnen und mindestens einen Kleinbuchstaben enthalten Wenn der zweite Buchstabe gro geschrieben wird darf der erste kein T sein um Verwechslungen mit einem Typenbezeichner auszuschlie en Empfehlung 16 Details zur Schreibweise von Bezeichnern f r Unterprogramme Unterprogramme Prozeduren oder Funktionen sollten Gro buchstaben nur verwenden um den Beginn von neuen Worten zu signalisieren wie zum Beispiel in ComputelnverseMatrix Schon ware es von einem Bezeichner einer Variablen gleich zu erfahren von welchem Typ die Variable ist Dies ist zumindest bei Standard Typen durch die Verwendung einer Vorsilbe Pr fix leicht m glich Erstmals wurde diese Idee in der sogenannten Ungarischen Notation standardisiert 1 Tabelle 2 gibt einige weit verbreitete Vorsilben an die mit den Vorsilben der Ungarischen Notation im brigen nicht mehr sehr viel zu tun haben Die Tabelle ist in Englisch verfasst weil dann die Bedeutung der Vors
60. ahl von Plattformen laufen Daher wurde C geschaffen eine strukturierte prozedurale prozessorunabh ngige Hochsprache die die Implementierung aller erdenklichen Tricks des einfachen Von Neumann Rechners zul sst Wenn man die Tricks allerdings nicht ganz beherrscht dann ist es in kaum einer anderen Sprache so leicht sich selbst Fallen zu stellen wie in C der heute wichtigsten h heren Programmiersprache m Bereich Eingebettete Systeme Die strukturierte Sprache C erlaubt nicht nur die Erzeugung von nahezu so effizientem Code wie Assembler sondern gestattet auch einen sagenhaft unleserlichen und unstrukturierten Programmstil Ein schlechter Programmstil verleitet zu Fehlinterpretationen bei der Wartung von Software erschwert Modultests und Portierung kostet ein Unternehmen daher Zeit und Geld Abhilfe schaffen sogenannte Codierungsstandards 1 2 3 Die folgenden Vorschriften k nnten Teil eines derartigen C Standards sein Vom Umgang mit dem Pre Processor und Dateien Ein m chtiges Werkzeug f r die bersetzung von C Code ist der Pre Processor dessen Arbeit schon beendet ist bevor der Compiler selbst startet Der sachgem e Umgang mit seinen Befehlen erleichtert die Portierung von Code Regel 1 Pfadangabe in Include Dateien Die Angabe eines Pfades im include statement muss relativ zum Projektverzeichis sein Absolute Pfadangaben sind nicht gestattet Regel 2 Allgemeine und projektspezifische Include Dateien Projektspezifische In
61. al teview Output The objective of an audit is to verify that e the list of the reviewers and meeting participants software products and processes comply with e atable of RIDs organised according to category with standards guidelines specifications and dispositions marked procedures e a list of actions with persons responsible identified The audit process is carried out by an audit AND expe ced pales compleHlomcenned team who interview the development team the meeting conclusi n examine review items report errors and recommend solutions Review techniques audit Stephan Griinfelder Stephan Griinfelder Advantages of Reviews Advantages of Reviews e Reviews improve the self awareness of e Reviews point out dead ends and lead out developers of them Reviews uncover not only weaknesses of product and processes but also of developers They promote a realistic self awareness and this means nearly always a more modest one Reviews level out the individual scales Discussion causes an increase of harmony in standards if the reviews are carried out in a team A new culture emerges egoless programming Stephan Griinfelder Problems with Reviews Reviews require effort The preparation and the meeting itself need time and qualified meeting participants e Reviews can threaten the individual A developer can easily be turned from author to an examined person prevention by the moderator If this effect is
62. and implementation of IOPS unit tests Bug tracking Generating and using unit test error statistics A note on OO Test metrics Unit test summary report System test readiness review Stephan Gr nfelder IOPS unit testing the bugs Stephan Griinfelder Bug tracking tools Reporting and assignment of priorities Routing of bugs Email notification WWW based tools What defects are currently open What are the defects am in charge of What entries did not change for more than a month What defects have been fixed A collection of tools can be found at http www sqatester com bugtracking Stephan Griinfelder Test assessment steps Perrys5 Establish assessment objectives Identify what to measure Assign measurement responsibilities Select approach to evaluation Identify needed facts Collect evaluation data Assess the effectiveness of testing Stephan Griinfelder OO test metrics Note that conventional coverage analysis does not show the full picture in OO programming Does testing base foo mean that derived foo works inheritance context decision coverage see IPL99 Stephan Griinfelder Contents of the test summary report Version of software under test test version Tester date Used test environment especially when testing an embedded system Summary of the test results itself e g ST FanCo Ft04 fails because at the moment there are no duty cycles sent via CAN T
63. ann dann etwa das Suchen von Funktionsaufrufen in umfangreichem C Code zum Alptraum werden Layout Vorschriften umfassen neben der Klammernsetzung meist Regeln zur Verwendung des Leerzeichens zum Einsatz von Leerzeilen und Blockstrukturen Vorschriften zur Einr ckung sowie zur vertikalen und horizontalen Ausrichtung von Text Kommentare Kommentare bereichern das Programm mit Zusatzinformation f r den Leser und sollen helfen die Interpretation des Codes zu erleichtern Es ist berfl ssig zu erw hnen dass falsche Kommentare noch schlechter sind als keine Kommentare Die Verst ndlichkeit von Kommentaren kann wohl schlecht standardisiert werden daher betreffen Regeln f r Kommentare meist was kommentiert werden muss und welche jeweiligen Vorlagen zu verwenden sind Etwa Vorlagen f r das Markieren von Unterprogrammen oder Sprungadressen Standards f r Kommentare sind also zu einem guten Teil Anweisungen an das Layout der Kommentare Oft sind die Erwahnung des Autors des Projekts Erstellungsdatum und derengleichen standardisiert und im Idealfall mit einem System zur Versionskontrolle abgestimmt Sprachunabh ngige Anforderungen an das Design H ufig findet man in Codierungsstandards auch Kapitel mit Anforderungen die das Softwaredesign betreffen und damit nicht mehr dem reinen Codieren zugeschrieben werden k nnen Diese sind n der Regel schwer von der gew hlten Programmiersprache zu trennen genau wie das Design selbst Viele Stand
64. ar ber viele Gedanken zu machen Software wird aber nicht nur von alten Profis geschrieben es lohnt sich daher zu definieren was einen guten Stil im Bereich des Code Layouts ausmacht Wir beginnen mit folgenden Festlegungen Regel 1 Delimitoren und Ausdr cke Delimitoren von Statements also der Strichpunkt in C oder Variablen der Beistrich in C d rfen n cht unmittelbar einem Leerzeichen folgen m ssen aber von einem Zeilenvorschub einem Leerzeichen oder weiteren Delimitoren gefolgt werden Regel 2 Trennzeichen in zusammengesetzten Datentypen Trennzeichen f r zusammengesetzte Datentypen also z B der Punkt beim Spezifizieren einer Komponente einer struct oder union in C d rfen weder direkt vor einem Leerzeichen stehen noch direkt von einem Leerzeichen gefolgt werden Regel 3 Leerzeichen und Zuweisungsoperator Der Zuweisungsoperator muss zwischen zwei Leerzeichen oder zwischen einem Leerzeichen und einem Zeilenvorschub stehen Regel 4 Leerzeichen und undre Operatoren Un re Operatoren wie z B in C der Adressoperator amp oder der Verweisoperator durfen von ihrem Operanden nicht durch ein Leerzeichen getrennt werden In C und C kann im Fall von Zeigervariablen der Stern Operator auch zu einem Teil einer Variablendeklaration werden Ahnliches gilt analog fiir Typenbezeichner in Ada und Pascal Um auch hier potenziellen Fehlern vorzubeugen erweitern wir Regel 4 folgenderma en Regel 5 Un re Operatoren als
65. ards verzichten daher auf starre Regeln und es wird mehr auf Ecksteine des sauberen Softwaredesigns hingewiesen Der Programmierer wird meist angehalten sich an Prinzipien wie Koh sion Modular t t Abstraktion und derengleichen zu halten F r h here Programmiersprachen also alles was ber Assembler hinausgeht werden n Standards gelegentlich Softwaremetriken definiert die eingehalten werden m ssen Derartige Metriken definieren etwa die maximale Gr e von Unterprogrammen die maximale Verschachtelungstiefe von Schleifen oder Verzweigungen pro Unterprogramm oder etwa einen Mindestprozentsatz an Kommentarzeilen Diese sogenannten statischen Softwaremetriken werden mit Hilfe von Hilfsprogrammen errechnet Die berpr fung ob die erstellte Software den Metriken gen gt ist dann entweder Teil einer Code Review oder ein Aspekt des Modultests Die Metriken werden statisch genannt weil zu ihrer Berechnung die Software nicht ausgef hrt werden muss sondern nur der syntaktisch richtige Code gen gt um sie zu berechnen Dynamische Softwaremetriken hingegen beschreiben die Effizienz von Tests und nicht die Software selbst Sprachabh ngige Anforderungen an das Design Wenn der Codierungsstandard eine konkrete Programmiersprache betrifft dann ist das Formulieren von Anforderungen an das Design schon wesentlich leichter Mehr als alle bisher vorgestellten Regeln sollen die sprachspezifischen Designvorschriften vermeiden n bekannte Fa
66. are zero Set temperature to 289K wait 1 second 3 Verify that VESERR is zero Set the vessel temperature to the maximum possible wait 1 second 4 Verify that bit OVRTMP of message VESERR is set but all other bits are zero Stephan Griinfelder Bad Function Test 2 Test Objective Verify that the speed fans are only switched on when the fan ratio FanCtl_rFanPwr is between a maximum Fan_rFanOn_C and minimum Fan_rFanOff_C Also verify if there is no drive away roar Fan_stDrvAway is zero it must be possible to set a limit Technique First of all the Fan_stDrvAway_mp has to be zero Only if this measurement point is set to zero the FanCtl_rFanPwr can be controlled by the hysteresis The engine speed has to be set to a high value i e 5000 rpm First set the Fan_rFanOff_C and the Fan_rFanOn_C to zero The speed fans have to start running immediately Stephan Griinfelder Unit 3 Verification of Low Level Software Stephan Griinfelder Discussion of the lOPS System Test Design Annotaded IOPS SW Test Plan pdf Stephan Griinfelder Organisational Approaches for Unit Testin Hierarchy of includes em Een Ern Iessen ME Stephan Griinfelder Contents e Discussion of the system test design e Organisational Approaches for Unit Testing e Integration Test Planning e What is good SW design how does it affect testing e Technical review of the Architectural Design Docume
67. ay 10 goto InDieSchleife for i 0 Horror 1 i lt 10 i Abbruchbedingung pfui printf sd p 1 piArray i 0 Schleifenz hler schlecht gew hlt InDieSchleife printf Schleife wird nie initialisiert n Horror wird nicht aufgerufen n i Stephan Gr nfelder Code review Optional excercise ZS Note the most important points you usually check in a code AN review apart from the ones se tackled in the software coding standard section before Stephan Griinfelder Code review checklists Make sure there are no implicit type casts a division by 0 cannot happen known compiler bugs have no effect the code is free from language specific pitfalls and errors made in the past many more points Checklists improve the quality of code reviews Stephan Griinfelder Software coding standards language pitfalls inf fast_division int i unsigned j return i gt gt j the return value might be different when using a different compiler Stephan Gr nfelder Code review checklists Make sure the software coding standard is followed there are no double negations debug code has been removed the data types match the required accuracy all variables are declareed within the correct scope array indexes are not wrong by one and can not exceed the range or be negative arithmetic overflows are handled Stephan Gr nfelder
68. cating in which issue of the specification the requirement was last changed Initially it is set to 1 The requirement delimiter is a parallelogram If a requirement is no longer valid it is replaced by the text deleted Requirement numbers may not be removed or reused The verb shall is used whenever the described practice is compulsory should is used for recommended practices Sentences without any of the two verbs within a formal requirement are explanations 3 2 Typographic Conventions Text in italic face represents a term that is defined or has has special meaning within this document An instance of such a term is not necessarily in italic face if the context will leave no doubt that the definition is applicable Bold face letters emphasise the textual content and improve readability Binary numbers are tagged with a subscript b like 0101 Hexadecimal numbers are tagged with a subscript h like 3FA9 Numbers without subscripts are to be interpreted as decimals TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 6 3 3 General Technical Terms and Phrases In the following table a definition of used technical terms and phrases 1s found kick a watchdog reset the watchdog timer 1 e reload it with a previously defined value mask an interrupt disable interrupt serving but latch the interrupt Table 1 Technical terms used in this document dis arm a watchdog wird ni
69. cd AAA AAA AAA AAA AAA III ATTA AAA TAT Stubs Section AAA AAA AA AAA AAA AAA ATTA ATTA ATTA SSSTUB range SSACTION 1 SSINPUTS _value 100 SSOUTPUTS R_ RANGE_OK AAA AAA AAA AAA I II I II I II TTT Stephan Gr nfelder Getting started with Cantata Complete maths tcd to reach 100 decision coverage Tests Completed At 08 25 33 Script Checks Checks Checks Stubs Paths Assertions Status Errors Passed Failed Warning Failed Failed Failed Stephan Gr nfelder Getting started with Cantata e Inspect the intrumented source file maths cti e Inspect the test code mathst c e Why does the source code use STATIC instead of static Stephan Griinfelder Unit 6 Verification of Low Level Software Stephan Griinfelder Complete maths tcd Tests Completed At 08 25 33 Test Script Checks Checks Checks Stubs Paths Assertions stat ARE b e 4 Errors Passed Failed Warning Failed Failed Failed Stephan Griinfelder Testing test metrics Invent a very simple function and test cases that achieve 100 Multiple Condition Coverage but nevertheless do not find the bug Stephan Griinfelder Contents Unit 6 Implementation of simplified unit tests moderated Le finish the maths tcd example from unit 5 A note on test metrics Tools for automatic test case generation Design and implementation of unit tests for the IOPS project Stephan Griinfelder Solut
70. ce Stephan Griinfelder Bad Function Test 1 Test objective Check the oil pressure warning lamp Technique Set the debounce times OPSCD_DebNeg_C and OPSCD_DebPos C to 1s Connect pin K14 with ground to simulate high oil pressure Wait one second Verify that OPSCD_Lamp_mp is one Disconnect K14 and ground to simulae low oil pressure Wait one second Verify that OPSCD_Lamp_mp is zero Stephan Griinfelder IOPS System Test Design Rean Reg Short Text Tested in SRA ET A zeit Test SP 0FS F TOE 7 STJO FT STAO FTE 5T 10865 FT02 ST 1OP5 FT R STAFF TOI ST IOPS FTOI STOFFT raar Tst 19F5 Fro2 e ST I0PS FTOt ST 10PS FTO4 ST 10FS FT03 ST MPS FTOS SHO FTS ST 10PS FTOS ST IOPS FTIG ST 10PS FTOF SI OFFTOES Stephan Gr nfelder Example Function Test R SRD XY 1 1 If the vessel temperature is higher than 300K the DSP software shall set the bit OVRTMP of the CAN bus message VESERR R SRD XY 2 1 If the vessel temperature is lower than 290K the DSP software shall clear the bit OVRTMP of the CAN bus message VESERR ST XY FT01 Set the system up such that VESERR is zero Set the vessel temperature to the minimum possible Wait 10 seconds 1 Verify that VESERR is zero Set temperature to 299K wait 10 seconds 2 Verify that VESERR is zero Set the vessel temperature to 301K wait 1 second Verify that bit OVRTMP of message VESERR is set but all other bits
71. chen Schon heute basierten 90 Prozent aller Innovationen im Auto auf Soft ware oder Elektronik In einem Oberklasse Wagen sind heute 70 oder 80 elektronische Steuerger te drin sagt Weinmann Dank Klimaanlagen Navigationssystemen und High Tech Stereoanlagen sind Autos f r die Fahrer angenehmer gewor den Antiblockiersysteme ABS Stabilisierungshilfen ESP Bremsassistenten und piepsende Einparkhilfen haben den Verkehr sicherer gemacht Ei ntersuchung des Stephan Gr nfelder on aus immer k rzeren Entwicklungszyklen und immer komplexeren IT Systemen verantwortlich Bislang wird untersch tzt dass der Entwicklungsprozess bei Software methodisch aufwendiger ist als in der Mechanik sagt er Wir sollten von den Ingenieuren lernen auch was Gr nd lichkeit angeht Er w nsche sich einheitliche Standards f r alle Hersteller Zulieferer und Programmierer Das w rde auch bei einer Panne der Werkstatt die Arbeit erleichtern Denn die ist nicht selten berfordert wegen der Vielzahl der Elektronikbauteile im Wagen Die Komplexi t t in der Automobil Industrie ist dramatisch hoch sagt Erich Nickel Direktor f r Automobil Software bei IBM In einem undurchschaubaren Systemverbund sei es extrem schwer festzustellen wo der Fehler liege Die Werkstatt tausche dann gerne mal die Steuerger te aus und schicke sie ein Doch der Hersteller kann am Einzelger t keinen Fehler entdecken Das ist ineffektiv und viel zu teue
72. clude Dateien m ssen im include statement zwischen Doppelhochkomma stehen Spitze Klammern s nd f r C Runtime Libraries und andere projekt bergreifende Dateien reserviert Regel 3 Header und Implementierung Der Name einer Header Date darf sich vom Namen der Implementierungsdate1 nur in der Datei Endung unterscheiden Die oben vorgestellten Vorschriften erlauben das einfache Wechseln des Projektverzeichnisses und erleichtern das Auffinden von Dateien und dazugehorigem Code Um C Code auch n C verwenden zu k nnen und wiederholtes Parsen von Code zu verhindern fomulieren wir Empfehlung 4 Kapselung von Header Dateien Die Deklarationen jeder Header Date sollten zwischen den in Listing gezeigten Pre Processor Anweisung stehen ifndef DATEINAME_H define DATEINAME_H parce E pls ps extern Cc ea Mae beginmenzscresDeklarationen der leader Deren So a Si A 1 CPU ADSP2181 typedef int TIntl6 telif CPU INTEL486 wpeder shore ne Dios else error Macro CPU has an unexpected value endif ifdef DEBUG undef ASSERT tderin o ASSER ach SSS ere Gay Bene pore lem ame Mako romeo net reko endif hier ende clits melee ome cles Meder enc ai Sy ifdef _ cplusplus endif endif DATEINAME_H Listing 1 Beispiel zur Empfehlung 4 und Regel 7 Der Funktionsumfang des Pre Processors reicht aber deutlich ber das Einf gen von Include Dateien hinaus Er gestattet nahezu unbegrenzte tex
73. csi ae ne u 10 S Traceability Main seele aeg 10 This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 4 1 Intoduction 1 1 Purpose This document describes the architectural design of the software for the Intelligent Oil Pressure Sensor IOPS The IOPS is a sensor for the Project Little Stream PLS a sensor network for medium sized water power plants The intended reader of the document is any manager software engineer and verification responsible in the PLS IOPS To fully understand the contents of this document the reader should be familiar with the software requirements SRD Note that the document describes the design of the IOPS software only The design of the overall system interactions between the subsystems within a PLS network is found in another document ICD Due to the limited size and complexity of the of IOPS requirements there exists no detailed design document 1 2 Definitions Acronyms Abbreviations The IOPS software design method is based on the Unified Modelling Language which is normally used for OO languages Hence it uses OO terminology and this terminology is used in this document as well However since C is not an OO language a matching for the OO terms is defined as follows e aclass is aC file plus correspondig header file which are used to implemen
74. ctions between Base bar and Base helper or the interactions between Base foo and Derived helper OIPL Information Processing Ltd 3 3 Obviously just because Base foo works with Base helper does not mean that it will automatically work when used with Derived helper Although Derived helper has the same interface as Base helper they have different implementations For our testing to be really thorough we should exercise both foo and bar for both the base class and the derived class as we would if they were explicitly overridden in the derived class Figure shows that the inherited methods are not fully covered by the original test cases The diagram includes the make believe versions of foo and bar shown enclosed in braces which represent their inheritance in Derived Base foo Exercised in A1 bar UNTESTED helper Exercised in A1 1 Derived foo UNTESTED bar A Exercised in A2 helper Exercised in A2 Figure 1 The inherited methods have not been fully exercised We Need Better Tests To achieve 100 coverage an enhanced test set 1s required void better_test_driver Base base Derived derived base fol base bar derived foo derived bar 4 4 The additional test cases help ensure that the interactions between the public methods and the private helper functions have been fully e
75. d next command from rx_bus txt Stephan Griinfelder Extreme Programming XP Extreme Programming Beck01 e introduces pair programming instead of code reviews implements tests before coding instead of writing SRDs the requirements are captured in test scenarios has many more iterations than other lifecycle models Stephan Griinfelder Risk based testing Idea e Assess likelihood of a flaw in program fragments the impact and visibility of the flaw e Distribute test effort dependent on a risk estimation based on the above factors Stephan Griinfelder System Test Summary u Report see unit 7 Stephan Gr nfelder XP the SQA and embedded systems e Pair programming harder to identify common errors and difficult to prove code review Implementing tests before coding might add costs when software design is infeasible because of hardware problems Many iterations and early software deliveries might be impossible in in projects with hardware software co design Stephan Griinfelder Risk likelihood assessment very small eltablished function fno optimization Scale Pize Complexity Number of Former Level of Optimization Defects Found Ear A ang Resources ier afty never changed Aa iy 6 fose 9 ke large f How could this be more precise Other factors experience of developers change frequency of requirements Visibility assessment Impact assessmen
76. definiert ist oder nicht Ein Tippfehler 1m Bezeichner des Markso wird nicht autmatisch erkannt Listing konnte in UNIX durch folgende Anweisung ubersetzt werden cc c dateiname c DDEBUG Genauso gut bersetzt aber die folgende Anweisung mit Tippfehler das Programm allerdings ohne Debug Eigenschaften cc c dateiname c D_DEBUG_ Verlangen w r nun in einer neuen Regel immer einen Makrowert so werden derartige Tippfehler abgefangen Beide zuvor gezeigten bersetzungsversuche w rden fehlschlagen Je nach Implementierung k nnte zum Beispiel die Anweisung ce c dateiname c DDEBUG 1 zum gew nschten Ergebnis f hren und es m sste in Listing der Wert des Makros DEBUG berpr ft werden anstelle der Tatsache der Definition Bei der Einf hrung einer solchen versch rften Makro Regel k nnte man Regel 6 n eine Empfehlung umwandeln Es ist weit verbreitete Praxis die Einr ckung von Zeilen von Pre Processor Anweisungen unbeeinflusst zu lassen wie in Listing 1 bei den Makros DEBUG und CPU gezeigt Gleichzeitig findet man aber eine Einr ckung der extern Deklaration in nahezu jeder Header Datei die das Makro cplusplus pr ft Dieses Thema k nnte Gegenstand einer weiteren Regel sein Fehlervermeidung bei der Steuerung des Programmflusses In einem vorangegangenen Artikel zum Thema Codelayout wurde gezeigt wie leicht man beim Lesen eines Programms in die Irre gef hrt werden kann wenn die horizontale Ausrichtung der Programmzeile
77. den Programmfluss ndern kann und einer offnenden Klammer muss ein Leerzeichen stehen Die bisher vorgestellten Regeln helfen einerseits Fehlinterpretationen von komplexen Ausdr cken zu vermeiden und andererseits durch die Festlegung der Verwendung des Leerzeichens d e Textsuche effizienter einzusetzen Horizontale Ausrichtung Die horizontale Ausrichtung Einr ckung von Programmbl cken ist unverzichtbarer Bestandteil guten Layouts in strukturierten Programmiersprachen und kann auch die Interpretation von Assemblerprogrammen deutlich vereinfachen Der Zweck der horizontalen Ausrichtung ist es die Begrenzungen von Programmbl cken zu verdeutlichen So l sst sich etwa leichter erkennen welche Instruktionen von einer Verzweigung betroffen sind bersprungen werden oder Teil einer Schleife s nd Die Beachtung der m folgenden aufgestellten Regeln vereinfacht das Erkennen dieser Blockstrukturen und erh ht damit die bersichtlichkeit des Quellcodes Regel 11 Einr ckung und Einr ckungsszeichen Programmbl cke m ssen durch Einr ckung erkennbar sein Diese horizontale Ausrichtung muss mit dem Leerzeichen erfolgen Die horizontale Ausrichtung von Programmcode mit dem Tabulatorzeichen kann zu unglaublichen Schwierigkeiten f hren wenn fallweise ein anderer Editor verwendet wird oder unter unterschiedlichen Betriebssystemen editiert wird es st gar n cht so selten das der Debugger auf einer anderen Plattform l uft Das gilt auch
78. der Review of IOPS SRD 2 0 using RID forms Stephan Gr nfelder System Test Automation Stephan Gr nfelder System Test Automation Stimulation of the inputs of the system Measurement of the outputs and comparison with expected outputs Creation of useful test logs Stephan Griinfelder Disadvantages of Test Automation Automating a test is 5 to 10 times the effort of manual testing An automated test only checks what it is programmed for and cannot detect obvious unplausibilities if it is not programmed to check for it Sometimes impossible Costs of the test equipment GUI Stephan Griinfelder Disadvantages of Manual Testing Boredom Prone to errors Lacking repetitiveness Sometimes impossible e g volume testing Stephan Griinfelder Advantages of Test Automation e Repeatability GUI example GUI problem e No forgetting of a step in a test case e Clear proof of an error in case it is intermittend e Cost benefits for repetitive tests e Programming is fun Stephan Gr nfelder Advantages of Manual Testing Since a manual testing is faster to implement than an automated test you can do more testing in the same time unless you need to repeat the testing a couple of times A human tester can find errors she wasn t even testing for Costs of test equipment are less Humans have no problems with GUI Stephan Gr nfelder Half Automatic Tests
79. diesem Zweck dienen Diese Empfehlung ruft zum sparsamen Gebrauch des Unterstreichungszeichens auf weil damit Namen k rzer werden viele Compiler unterst tzen Namensl ngen bis nur maximal 32 Zeichen Es fehlt allerdings der Hinweis ob die Kennung des Definitionsortes als Vor oder Nachsilbe erfolgen sollte Diese Festlegung kann in einer weiteren Empfehlung gemacht werden und ggf f r Typen und Unterprogramme verschieden sein Rein formal wird streng zwischen einer Deklaration und einer Definition unterschieden Der Begriff Definition in obigen Vorschriften ist nicht formal zu verstehen mit dem Ort der Definition ist die Stelle im Programm gemeint wo der Programmierer den Typ des gesuchten Elements erkennen kann und entsprechende Kommentare vorfindet Beispiele f r die Verwendung global sichtbarer Programmelemente in C Funktionen die in der Datei DataSink c implementiert sind ap bOpen datasink_1s_oximeter_chnannel_open pe SO RicheN Ay bOpen DataSink_IsOximeterChnlOpen ZS Viel besser SPEAKER MAKESOUND DIALTONE ein Makro aus Speaker h Das Designdokument identifiziert die Datei MsgIntf h als Definitionsort von Nachrichten die in zwei Systemen interpretiert werden m ssen Das gegenst ndliche Programm behandelt die Nachrichten im Modul MsgHnd c TAlertMessage_MsgIntf tMyAlarmMessage TStatusMessage_Msgintf tMyStatusMessage MsgHnd_Clear amp tMyStatusMessage Die verwe
80. dl loop rear edge Retire pode 7 dem Be Sah o 0344 Stephan Griinfelder Structured integration testing The integration complexity denoted as S by McCabe of an assembly of modules counts the number of paths through the control flow The design complexity S X vi The integration complexity of an assembly of N modules is given by the formula minimum number of S S N 1 l integration test cases of a project when integrating a new module execute the control flow of the reduced graph Stephan Griinfelder Review of the integration testing strategies unit 3 Buttom up unit testing as shown in unit 3 McCabe s structured integration testing Set break points at interfaces and inspect data and control flow Perform system tests with an instrumented code that reveals Call Pair Coverage Perform system tests and analyse the Call Pair Coverage manually Stephan Griinfelder Other software metrics Enhancements of cyclomatic complexity that regard the mentioned drawback Number of goto s Number of exit points of functions Lines of code Ratio comments statements Maximum nesting level Stephan Griinfelder Tool based metric calculation metric lt source file name without extension gt source files are ready for code gt f review results in lt src gt ctl Le A A Decide upon the metrics which ANS y Functions with v lt 10 no goto s single exit point pe
81. e Abk rzungen Die F hrung eines Abk rzungsverzeichnisses st daher unabdingbar Regel 2 Abk rzungen Alle verwendeten projektspezifischen Abk rzungen m ssen im Designdokument erkl rt werden Projekt bergreifende Abk rzungen werden im Anhang des Coding Standards definiert Alternative Formulierungen dieser Regel k nnen auf elektronische Abk rzungsverzeichnisse verweisen Ein solches Verzeichnis bietet sich insbesondere f r projekt bergreifende Kurzformen an Beispielsweise unter Verwendung der Kommandos man und what is in Unix Ebenso wichtig kann auch ein Querverweis auf eine weitere Erl uterung sein Folgendes Beispiel aus einem Abk rzungsverzeichnis ist nicht erfunden sondern stammt aus einem Dokument einer gro en deutschen Elektronikfirma Abk rzung DSS Bedeutung Datensammelschiene Dies zeigt dass ein schlecht gewahlter Begriff genauso nichtssagend sein kann wie seine Abk rzung Daher formulieren wir folgende Regel 3 Projekt Glossar Alle projektspezifischen Definitionen oder Abk rzungen m ssen n einem Glossar erkl rt werden Das Designdokument muss zumindest eine Referenz auf diesen Glossar enthalten Nun wenden wir uns den Zahlenformaten zu Die Verwendung von Oktalzahlen hat s ch nie wirklich durchgesetzt Einer der Gr nde ist dass sie zu leicht mit Dezimalzahlen verwechselt werden k nnen Daher folgende Empfehlung 4 Verwendung von Oktalzahlen Oktalzahlen sollten nicht verwendet werden Der Grund
82. e Nummer eins Fehler in der Elektronik seien inzwischen fiir 55 Prozent lt sf lle verantwortlich r umten Automo bilhersteller und Softwareexperten zu Beginn der Fachta gung Informatik 2003 am Dienstag in Frankfurt ein Hauptursache sei das mangelnde Zusammenspiel zwischen Systemen verschiedener Zulieferer Von 1998 bis 2001 sei die Zahl der Pannen die durch feh lerhafte Software verursacht wurden um 23 Prozent gestie Center Automotive Research in Gelsenkirchen zufolge hat sich die Zahl der Personenwagen in den vergangenen 30 Jahren mehr als verdoppelt die Zahl der Unfallopfer aber sank um 70 Prozent Dies ist zu einem Gutteil auf Systeme wie ABS oder ESP zur ckzuf hren glaubt die Gesellschaft f r Informatik und beruft sich dabei auf Zahlen des Statisti schen Bundesamtes und des ADAC Allerdings h ufen sich auch die Systempannen Prof Hein rich Mayr Pr sident der GI macht daf r eine fatale Koaliti gen Andere Ursachen h tten nur um 3 Prozent zugenom men Werde nicht schnellstens gegengesteuert k nnten softwarebedingte Pannen in zehn Jahren zwei Drittel aller Defekte ausmachen rechnet die Gesellschaft f r Informatik GI vor F r die Autoindustrie werde die Informatik immer wichti ger best tigt Ulrich Weinmann Gesch ftsf hrer der BWM Car IT GmbH Der Markt f r Automobilsoftware wird sich einer Studie der Unternehmensberatung Mercer zufolge bis 2010 auf 100 Milliarden Euro vervierfa
83. e Requirements Document 2 0 ICD ABB IA PL 1520 00 PowerPlan Bus Interface Control Document Release 1 0 2 2 Reference Documents UMLRT Bruce Powel Douglass Real Time UML Addison Wesley 1998 MC4711 Digital Devices The MC4711 Users Manal 2 edition June 2002 PMC Digital Devices A Programmer s Guide to the MC4711 1 edition October 2002 IKJADD TheCompany 004403 PLS KJ Software Architectural Design Document 3 0 3 System Overview The IOPS software is designed to be fail silent 1 e it rather shuts up before saying something wrong During start up a self test of the MC4711 is being performed If it fails the software runs an endless loop and waits until the watchdog resets the processor If the test passes the IOPS software enables the PP bus interrupts sends the PP bus message MSG_READY to inform the main control that it is ready for commands and starts responding to PP bus commands from the main control At the same time the on chip timer of the MC4711 is started The timer is used to generate interrupts at the rate of 1kHz Its interrupt service routine ISR increases the global milliseconds counter ulSystemTime by one This counter is a global variable for reasons of simplicity and is used to implement timeouts and the measurement of the report intervals of the debounced oil pressure switch State After the receipt of the command MSG_START the IOPS software must no longer listen to PP bus messages The IOPS softwar
84. e auch f r Templates verwendet Regel 8 Block Definitionen Klammern oder Schl sselworte zur Blockdefinition m ssen in einer separaten Zeile stehen und nach dem vorhergegangenen Ausdruck linksb ndig ausgerichtet sein Diese Regel bedeutet f r den C Programmuerer die Festlegung auf die erste der in Listing 2 gezeigten drei g ngigen Eimruckungs Strategien Die Wahl f llt auf diese Strategie da bei ihr am einfachsten Anfang und Ende eines Programmblocks zu erkennen sind F r runde und eckige Klammern definieren wir drei etwas komplexere Vorschriften Das Klammern Layout entstammt den Programmbeispielen in den UNIX man pages Die Anwendung dieser Vorschriften wird in Listing 3 illustriert Empfehlung 8 Klammernsetzung in Ausdr cken und Formeln Eine ffnende eckige oder runde Klammer muss einem Leerzeichen Zeilenvorschub einer anderen Klammer oder einem Funktions bzw Variablennamen folgen und darf nicht direkt von einem Leerzeichen gefolgt werden Eine schlie ende eckige oder runde Klammer darf n cht direkt hinter einem Leerzeichen stehen und muss direkt von einem Trennzeichen Delimitor oder einer weiteren Klammer gefolgt werden EE dar ANSE 6 US rare ed ae ce Sy Sie eee ga print codec tad Seendardszesindr wal claw ik WE ie ky eee SE ss korme se nem mageile gem iche 7 printe Hrer wet cos schwerer von Plecekbeginzsorort Wate cles la LO Ol SMS zusehen Sia 7 4 en eS BOM nEnmer EE Ee lc cs blo Degas pr
85. e disables PP bus interrupts and starts sending its report messages MSG_OILSWITCH 4 System Context Since the hardware takes care of PP bus arbitration address definition address decoding checksum calculation and rejection of messages with wrong checksums the logical view of the PP bus communication with the main control is a peer to peer communication for the IOPS software MC4711 The only other external interfaces of the IOPS software are the oil pressure switch and the external watchdog Both are connected to the digital I O port of the controller To access the digital I O port and the PP bus the MC4711 system C library is used It provides the blocking VO functions rx_bus and tx_bus to receive and send data via the PP bus and the functions memout and memin to access special purpose registers of the controller such as the interrupt configuration register and the digital I O port register This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 6 5 System Design 5 1 Design Method The used design method is the Unified Modelling Language for Real Time Systems UMLRT This method is an object oriented design method Since the IOPS software is written in C the object s attributes are static variables of the source file implementing the class There is only one instance of
86. each of the identified objects in the IOPS software which simplifies matters However the debouncing algorithm the class debounc was taken over from the earlier KJ project This class allows to have multiple instances To accomplish this the debouncing state machines are designed as abstract data type TDebouncer A valid instance of this abstract data type has to be passed to each member function when operating with the debounding algorithm see section 6 1 5 2 Decomposition Description The IOPS software encapsulates the digital I O port of the MC4711 in the object Dio It has a member function for each peripheral access possible via the port as seen in the decomposition diagram in Figure 1 This figure only shows a subset of private 1 e static data and functions which are identified by a minus as function prefix memin memout tx_bus rx_bus set_timer start_timer set_interrupt Dia ulSystemTime uiReportIntervalSeconds wDioShadow TimerISRO main Init GetNewDebouncer ProgrammingMode KickWd SetPosTime OperationalMode GetOilPressureS witch SetNegTime BusISRQ Debounce selftest Messages PP bus message definitions Figure 1 IOPS Software UML Class Diagramm This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1
87. ebounce takes as argument the raw digital sensor value and returns the debounced value The algorithm exaclty follows the diagram shown in figure 2 of the SRD with Ims The state of the debouncer s is captured in arrays which have the dimension MAX_DEBOUNCERS 6 1 4 Subordinates To set up the 1kHz timer interrupt the MC4711 system library is used 6 1 5 Dependencies Before any of the other member functions can be called a valid debouncer must be created by calling GetNewDebouncer 6 1 6 Interfaces The member functions only accept and return built in types 6 1 7 Resources Debounc needs the on board timer and defines an interrupt service routine for the cyclic timer expiration 6 2 Dio 6 2 1 Type The component Dio is a high level driver for all digital I O of the IOPS software This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 8 6 2 2 Purpose The idea of Dio is to ease the use of the digital I O port of the MC4711 Instead of accessing the pins of the port in the client routine the knowledge which pin is connected to which peripheral device 1s encapsulated in Dio c 6 2 3 Function The member function Init sets up the input output configuration of the port All other member functions are project specific getter and setter methods that access the pins of the port Wh
88. ed systems Testing must be planned carefully a sample test plan will be presented in unit 2 Testing an embedded system can be a challenging project that may exceed the cost of developing the system by far Stephan Griinfelder Review techniques walkthrough meetings Preparation A review leader nominates the team The moderator or author distributes the review items when the author decides that they are ready for walkthrough Members should examine the review items prior to the meeting Concerns should be noted so that they can be raised at the appropriate point in the walkthrough meeting Stephan Griinfelder Review techniques walkthrough meetings Output e alist of the members e alist of changes and defects noted during the walkthrough a list of actions with persons responsible identified and expected dates for completion defined recommendations made by the walkthrough team on how to remedy defects and dispose of unresolved issues e g further meetings Stephan Griinfelder Review techniques technical teview Preparation The leader creates the agenda and distributes it with the statements of objectives review items specifications plans standards and guidelines to the review team Members then examine the review items Each problem is recorded on the RID form A RID form should record only one problem or one group of related problems Members then pass their RIDs to a secretary
89. efolgen wenn ein bekannter Algorithmus implementiert wird und dort einzelne Buchstaben als Variablen oder Funktionsnamen verwendet werden Etwa wird bei der Definition der Faktoriellen fast immer n verwendet und das Blockieren und Freigeben von Semaphoren oft mit P und V bezeichnet Wenn ein Name gefunden worden ist dann sollte es keine Verwechslungsm glichkeiten mehr geben Wir fugen daher folgende Empfehlung hinzu Empfehlung 14 Eindeutigkeit von Namen Ein und derselbe Name sollte nicht f r verschiedene Objekte verwendet werden Ein Objekt sollte nur einen Namen haben Diese Empfehlung erscheint berfl ssig C erlaubt aber beispielsweise einer Variablen zwei oder mehr Namen zu geben In der nat rlichen Sprache werden oft dem selben Objekt verschiedene Namen gegeben in diesem Artikel etwa wurde bislang von Unterprogrammen Prozeduren und Funktionen gesprochen obwohl m bisherigen Kontext kein Unterschied auszumachen war Solche Begriffsvermischungen haben in Software n chts verloren Was bist du Die bislang vorgestellten Vorschriften legen keinen lexikalischen Unterschied zwischen Namen f r Variablen Konstanten Typen und Unterprogrammen fest Da deren Verwechslung bel hardwarenaher Programmierung und daher ggf schwacher automatischer Pr fung zu schwer erkennbaren Fehlern f hren kann ist die Festlegung von einfachen Unterscheidungsmerkmalen in Form von Regeln vorteilhaft Eine inkonsequente Anwendung dieser Regeln kann
90. eline Testing Tool based software metric calculation Software coding standards Code review checklists Code review Stephan Griinfelder Code metrics The testability of software is strongly related to its complexity Given that program statements are linked to each other by sequence selection i e branches or conditions and iteration i e loops McCabe defined a metric that gives a complexity of 1 for a simple sequence of statements with no branches Only one test is required to execute every statement in the sequence Each branch added to a module increases the complexity by one and requires an extra test to cover it Stephan Griinfelder Cyclomatic complexity Sequence lteration Stephan Griinfelder Cyclomatic complexity Inaccuracy of the cyclomatic complexity amp amp b gt 2 primei bese ni N Peer printer test n gt Stephan Griinfelder Stephan Griinfelder Cyclomatic complexity v 1 Total cyclomatic complexity The total cyclomatic complexity of a program can be obtained by summing the cyclomatic complexities of the constituent modules The full cyclomatic complexity formula given by McCabe IS v e n 2p where p is the number of modules Stephan Griinfelder Baseline testing method Complexity 7 6 2 3 Baseline path Switch decision 1 Switch decision 2 IF A THEN X 1 ELSEIF 8 THEN X 2 O ELSE X 3 ENDIF O O Q O O Test Case
91. en auch noch einige Schlupfl cher durch unser Regelwerk findet Beide in Listing 5 gezeigten Fallen haben mit dem Layout zu tun und verletzen keine der pr sentierten sprachunabh ngigen Regeln Um solch schlecht strukturierten C Code zu unterbinden m ssen w r ganz spezifische sprachabh ngige Regeln aufstellen In unserem n chsten und gleichzeitig letzten Artikel zum Thema Codierungsstandards werden wir genau das tun 1 Ur mans 1 Eon cos llos ue Se DE Ee ler ne 9 Vee ee EE SE DEE EE Eeer E else EE e o EE KEE E Listing 5 Sprachabh ngige Fallstricke bei der Ausrichtung von Code Neben der computerunterst tzten Versionskontrolle haben weitere Werkzeuge eine Schnittstelle zum Codierungsstandard Je spezifischer eine sprachabh ngige Regel des Standards ist desto leichter kann man sie automatisch berpr fen In der Tat erkennt ein gutes kommerzielles Lint Tool beide Fallen n Listing 5 und das gratis erh ltliche LCLint 3 erkennt immerhin die Endlosschleife LCLint erlaubt brigens auch in beschr nktem Rahmen eine designabhangige berpr fung des Quellcodes Das Programmdesign ist untrennbar mit der verwendeten Programmiersprache verkn pft Unser Folgeartikel wird Designrichtlinien f r die C Programmierung vorstellen die einfach in einen Codierungsstandard eingegliedert werden k nnen Die breiteste Schnittstelle zwischen einem Entwicklungswerkzeug und den Layout Vorschriften eines Codierungsstandards hat
92. en writing to the port register the MC4711 demands that the value last read from an input pin has to be written MC4711 This is accomplished in Dio by keeping a shadow register which is updated it in the getter functions and used in the setter functions 6 2 4 Subordinates To access the digital I O port the system library functions are used 6 2 5 Dependencies Init must be called before any other member function is called 6 2 6 Interfaces The member functions only accept and return built in types 6 2 7 Resources No other software component should access the digital I O port in parallel This could cause wrong values in the port shadow register 6 3 Messages 6 3 1 Type The component is a header file only 6 3 2 Purpose The idea of messages h is to share a file in all PLS software projects This file defines all PP bus messages in a central place 6 3 3 Function The file only contains defines but no enumerations This is to allow to include this file in Assembler programs as well 6 3 4 Subordinates No subordinates 6 3 5 Dependencies See above 6 3 6 Interfaces See above 6 3 7 Resources No resources are used This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 9 6 4 Main 6 4 1 Type Apart from main Main has no public member functions Hence it has
93. ented context coverage anew way to measure coverage for object oriented systems IPL is an independent software house founded in 1979 and based in Bath IPL has been accredited to ISO9001 since 1988 and TickIT accredited since 1991 IPL has developed and supplies the AdaTEST Cantata and Cantata software verification products AdaTEST Cantata and Cantata have been produced to these standards Copyright This document is the copyright of IPL Information Processing Ltd It may not be copied or distributed in any form in whole or in part without the prior written consent of IPL IPL Eveleigh House Grove Street Bath EEN B A 1 5 L R len UK Phone 44 0 1225 444856 Certificate Number FM1589 Fax 44 0 1225 444400 email ipl iplbath com Last Update 28 10 99 10 28 File Advanced Coverage Metrics doc Introduction The use of structural coverage metrics to measure the thoroughness of a test set is a well understood technique However the application of the technique to object oriented software presents new challenges Traditional structural coverage metrics such as statement coverage branch coverage and condition coverage measure how well the bodies of each method have been tested Unfortunately these traditional metrics do not take into account the object oriented features of the software under test In particular the use of polymorphism and the encapsulation of state dependent behaviour behind well defined clas
94. ermine the current state while gathering coverage data How Well Did We Do Using the test cases from better_test_driver to test the BoundedStack we find that we still haven t achieved 100 state based entry point coverage The destructor has not been exercised in the partially full or full states Although state based coverage does not apply to constructor functions 1t does apply to destructors Exercising destructors in all states helps ensure that all allocated resources are properly freed The following further enhanced test set does achieve 100 state based entry point coverage int even better test driver BoundedStack stack 2 stack push 3 push when empty Stack sous 1 push when partially full tE Ar israckspush Ee 7 push when full catch BoundedStack overflow expected to throw stack pop pop when full stack pop 0 pop when partially full try 4 stack pop J pop when empty catch BoundedStack sunderflow expected to throw BoundedStack stack2 3 stack2 push 6 IF stack2 18 partialliy etull BoundedStack stack3 1 IPL Information Processing Ltd 4 9 4 10 stack3 push 6 ih Stacks 28 7411 destructors called implicitly at end of block for Fi Stack empty Stack2 partially full and stacks Full Extra Effort Gives Extra Benefit State based context coverage is unusual because it requires the user to provide additi
95. ersetzt 1K KK KK IK KK KK KK IK I KK kK AA poea Ay IE oki wanes UCHR goto InDieSchleife POr lernen E EN Brenn piArray i 0 oS cnc ent Imler Schale che or wu nike InDieSchleife patas elsa esca Ee Eer Eo a e EE PELLE el EE cuece goto AndererProgrammpfad else AndererProgrammpfad Prien i Progremmprade ni Goo MitLeVonBlock ae EE eS Tano wie a ee Jeder Comprller verweigerte CENAS A A Sua as Dai Image MitteVonBlock SA EE Listing 6 Gute Gr nde goto aus Ihren Programmen zu verbannen und Beispiele f r undefinierte Ergebnisse RiskyCompany Inc Risk based Testing Donotusethiswithoutmodification 12 Work Instructions UK 12WA Exercise Work Instruction Risk based Testing Introduction The idea of a risk based test strategy is to distribute test effort dependent on risk estimation The available test capacity is distributed in a reasonable way More time 1s spent on testing more risky program parts less time 1s spent on testing less risky parts of the software Responsibilities The risk based test strategy has to be planned by the project software responsible or a person who is assigned by him For risk estimation all necessary stakeholders system developers software developers customers testers etc may be involved Work Instruction The software has to be split in a manageable number of units The units must be distinguishable by risk estimation A resonable
96. es e Hierarchies of types Stephan Gr nfelder int f int k int n if k gt 10 a 0 n return alk tnt g int p if p printf n printf sd p return p 2 Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder char buf 100 FILE f if name printf ok n f fopen name r fclose f char fread char size_t size_t FILE fread buf 100 2 f Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Griinfelder typedef unsigned short Att_Char typedef Att_Char Row 80 typedef Row Screen 25 typedef int Row_Ix typedef int Col_Ix define BLANK Att_Char 0x700 Screen scr Row_Ix row Col Ix gol int i 0 scr row col BLANK okay scr i col BLANK scr col row BLANK warning 2 wrngs 13 Capabilities of static code checkers Can static code checking programs replace a human review partner _ PA SA Can a human review partner make a static code checking program superfluous
97. esting needs to be planned Stephan Griinfelder Feed back session J What did you like F 7 9 What did you already know before We What did you miss What was too easy Y o 2 What was too hard to understand What was too boring Would you recommend the course Any general suggestions Stephan Griinfelder Contact Stephan Grunfelder Rosentalgasse 3 1 3 A 1140 Wien stephan gruenfelder gmx at Stephan Gr nfelder TheCompany Ltd Rosentalgasse 3 A 1140 Wien PLS Intelligent Oil Pressure Sensor Software Requirements Document Document 004589 Issue 1 0 Date 28 Aug 2003 Name Function Signature Date Prepared Stephan Gr nfelder SW Designer ccccnccncnncnncnncnncnncnncnncnncnncnnnnncnnnnns deeeeeeeeseeneeneenenes Checked Bernd Spiess PIOJECEENGINCE ee re se Robert Stolz VerifieationEngineer Seltener Seren Helga Machart SW Quality Assurance asien lei Approved Norbert Wichtig Proiee Manage estrenos prensas Sieben TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 2 Document Distribution List Hansi Hinterseer Arnold Schwarzenegger Cindy Crawford Hubert von Goisern Change Log Change Description 1 0 28 Aug 2003 TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 3 Table of Contents MS bor an rela ha ee ee ee see E er eT le 4 e Wee 4 132 ADOD eege 4 e AONMS see ea een aia 4 2 LEE 4 2 1 Appleable Doc
98. exikalische Standardisierung Lexikalische Regeln betreffen etwa die Verwendung von Abk rzungen in Variablennamen die Verwendung von Nummern und Zahlenformaten Gro und Kleinschreibung sowie reservierte Namen Viele Standards haben auch sehr detaillierte Vorschriften zur Benennung von Datentypen und Variablen Diese Vorschriften umfassen meist die Namensgebung selbst und eine formal spezifizierte Vorsilbe Pr fix bzw Nachsilbe Postfix Ein Beispiel hierf r ist die von Charles Simonyi erfundene oft zitierte und mutierte Ungarische Notation 1 Auch Dateinamen und platzierungen werden gelegentlich standardisiert CASE Tools machen derartige Regeln meist berfl ssig Jedoch st der Einsatz von derartigen Werkzeugen f r eingebettete Software oft nicht machbar oder in vielen F llen nicht rentabel Daher ist die Beachtung dieses Themas im Standard empfehlenswert Vorschriften an das Code Layout Nahezu alle gangigen Codierungsstandards weisen eine Fulle von Regeln auf die das Layout des Programms betreffen Einheitliche Programmstrukturen erh hen nicht nur die Lesbarkeit sondern auch die Wartbarkeit von Programmen Eingebettete Software wird selten mit m chtigen Entwicklungsumgebungen erzeugt die es erlauben sofort alle aufrufenden oder aufgerufenen Unterprogramme eines Programmblocks anzuzeigen Oft steht nur ein Compiler f r die Kommandozeile und e n einfacher Editor zur Verf gung Ohne genaue Vorschriften an die Klammernsetzung k
99. f r Produkte vom gleichen Hersteller ein mit dem Microsoft Visual C Editor erstelltes Programm kann in der Ansicht des Windows Notepads vollig unleserlich sein Gute Editoren erlauben trotzdem die Verwendung des Tabulators und bersetzen das Dr cken der Tabulatortaste in eine einstellbare Anzahl von Leerzeichen Regel 12 Einrtickungstiefe Die Einr ckungstiefe muss 3 Zeichen sein Warum gerade drei Viele Programmierer halten zwei Zeichen f r zu wenig und den von vielen Betriebssystemen verwendeten Standard von acht Zeichen bei weitem f r zu viel Drei oder vier Zeichen entsprechen der Standardeinstellung vieler Editorprogramme k nnen noch eindeutig als Einr ckung erkannt werden und verschwenden nicht unn tig Platz Regel 13 Globale und lokale Einr ckung Code in globalem Kontext z B die Definition global sichtbarer Funktionen darf nicht einger ckt sein G ltige Ausdr cke inmitten eines Blocks m ssen linksbundig zum vorhergehenden Ausdruck ausgerichtet werden Empfehlung 14 Einr ckung von Sprungmarken Eine Sprungmarke Label sollte eine einfache negative Einr ckung zum vorhergehenden Code aufweisen Empfehlung 15 Kommentar am Blockende Ist ein Programmblock l nger als 20 Zeilen so sollte am Blockende ein Kommentar den Grund der Blockdefinition erlautern Bei der Programmierung in Assembler lohnt es sich zum besseren Auffinden von Sprungmarken Regel 13 zu ndern und eine Mindesteinr ckung f r Instruktionen z
100. f r die Verwendung dieses Zahlenformats und dessen Unterst tzung von einigen aktuellen Programmiersprachen ist die einfache Umrechnung zwischen Oktal und Binarzahlen Den gleichen Vorteil haben die deutlich h ufiger verwendeten Hexadezimalzahlen Sie werden dann verwendet wenn das Bitmuster einer Zahl eine besondere Rolle spielt Empfehlung 5 Zahlenformat Das verwendete Zahlenformat sollte dem Umfeld der Verwendung der Zahl angepasst sein Binarzahlen oder Hexadezimalzahlen sollten nur dann verwendet werden wenn auf Hardware R cksicht genommen werden muss andernfalls sind Dezimalzahlen zu verwenden Regel 6 Buchstaben und Vorzeichen in Zahlenformaten Buchstaben in Hexadezimalzahlen m ssen Gro buchstaben sein Der Exponent ber Exponentialdarstellungen muss von der Mantisse durch ein kleines e und ein Vorzeichen getrennt sein Die oben formulierte Regel ist eine willkurliche Festlegung auf ein einheitliches Format Genauso gut k nnten f r Hexadezimalzahlen die Verwendung von Kleinbuchstaben vorgeschrieben werden oder ein gro es E f r Exponentialdarstellung verlangt werden Jedoch k nnen bei Kleinbuchstaben die Ziffer 6 und der Buchstabe b leicht verwechselt werden wenn etwa w hrend der Fehlersuche Notizen gemacht werden Das kleine e in der Darstellung von Exponentialzahlen ist die Standardeinstellung von vielen Mathematikpaketen und von ANSI C Das Vorzeichen unterstreicht das Exponentialformat zus tzlich vergleichen Sie
101. f condition outcomes if a amp amp b printf hello Testcase 1 a No practical meaning Testcase 2 a as stand alone test metric Stephan Griinfelder Condition Decision Coverage Condition coverage Min decision coverage condition coverage Condition decision coverage combines the requirements for decision coverage with those for condition coverage That is there must be sufficient test cases to toggle the decision outcome between true and false and to toggle each condition value between true and false Stephan Griinfelder Modified Condition Decision Coverage The MC DC criterion enhances the condition decision coverage criterion by requiring that each condition be shown to independently affect the outcome of the decision The independence requirement ensures that the effect of each condition is tested relative to the other conditions However achieving MC DC requires in general a minimum of n 1 test cases for a decision with n inputs For the example A or B test cases TF FT and FF provide MC DC For decisions with a large number of inputs MC DC requires considerably more test cases than any of the coverage measures discussed before NASA TM 2001 210876 Stephan Griinfelder Multiple Condition Coverage Finally multiple condition coverage requires test cases that ensure each possible combination of inputs to a decision is executed at least once that is multiple c
102. fficient Start the CU DSP Software via a Linux Terminal Start the utility EDSPMon Fill the top half of the stack with a nonzero pattern i e OxDEAD The syntax of the filling command dmm is obtained with the help command The stack address is found when looking for seg_stack in the link description file Exit EDSPMon Perform a recording with an Impedance Test Start EDSPMon make a dump of the memory region filled before he dump file contains only words of the defined pattern This means that at most 50 of the stack space Is used in normal operation Manual test 3 1 8 Volume Testing Volume Testing subjects the target of test to large amounts of data to determine if limits are reached that cause the software to fail Volume Testing also identifies the continuous maximum load or volume the target of test can handle for a given period For example if the target of test is processing a set of database records to generate a report a Volume Test would use a large test database and check that the software behaved normally and produced the correct report For the ID of Volume Test Descriptions use the acronym VT 3 1 9 Input Range Testing This is a bit validation testing Check if the results for strange input deliver still useful results despite that you tested the full range on algorithmic level in unit tests For example a respiratory effort sensor is designed for patients with up to 1 50m of thorax circumfence What if
103. final compiler switches Stephan Griinfelder Getting started with Cantata Total recall SSCASE 3 SSCALL debounc_Debounce SSNULL UnderTest c SSINPUTS _tDebID 2 _iRawSignal 0 OUTPUTS UnderTest cti y Driver c UnderTest o y y Stub o Driver o TestProgramm exe O Stephan Gr nfeder 4 Getting started with Cantata Abbreviations AAA AAA VALLAS IAAI LANLA AAA SSCASE 1 COM do a square of an in range value SSCALL maths range l SSINPUTS H op SQUARE _value 100 call_count 5 SSOUTPUTS M_maths_result 10000 R_ NO_ERROR call_count 6 AAA AAA AAA AAA AAA AAA dd dd dd dd dd Stephan Griinfelder Getting started with Cantata To set up the Cantata environment run begin bat in a Command Window To make a test for source file src c with test case definition file test tcd type mktest src test in the command window To execute the test start the created executable Stephan Griinfelder Getting started with Cantata Testing the file LVA maths4 maths c see maths tcd AAA AAA AAA AAA SSCASE 1 COMMENT do a square of an in range value SSCALL maths range l SSINPUTS maths_op SQUARE maths_value 100 call_count 5 SSOUTPUTS M_maths_result 10000 R_maths NO_ERROR call_count 6 AAA AAA AAA AAA AAA AAA AAA AAA Stephan Griinfelder Getting started with Cantata Testing the file LV A maths4 maths c see maths t
104. gacy code Programming errors programmers like anyone else can make mistakes Stephan Griinfelder Definitions Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase Software verification looks for consistency completeness and correctness of the software and its supporting documentation as it is being developed and provides support for a subsequent conclusion that software is validated U S Department Of Health and Human Services Food and Drug Administration CDRH General Principles of Software Validation Final Guidance for Industry and FDA Staff Stephan Griinfelder Definitions Software validation is the confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled IEEE Standard Glossary of Software Engineering Terminology 1990 Verification asks the question Are we building the product right Validation asks Are we building the right product Everybody else Stephan Griinfelder Definitions Software verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase IEEE Standard Glossary of Software Engineering Terminology 1990 Stephan Griinfelde
105. gi ambe revealed z Stephan Gr nfelder Unit Testing on the test How would you verify the following code unsigned short intsqrt unsigned uilnput unsigned short hiRoot 0 unsigned short uiRemHi 0 uiRemLo uilnput unsigned stert uiTestDiv A short iBits for iBits 0 iBits lt 16 iBits uiRemHi uiRemHi lt lt 2 uiRemLo lt lt 30 gt uiRemLo lt lt 2 hiRoot lt lt 1 uiTestDiv hiRoot lt lt 1 1 if uiRemHi gt uiTestDiv iRemHi uiTestDiv LRoot return hiRoot Host target testing Why to run unit tests in the host environment e A bottleneck may form of many developers competing for time on the target environment in order to test software The target environment may not yet be available Target environments are usually less sophisticated and less convenient to work with than host environments Instrumented code and test program might be too big for the target environment No printf of test results Stephan Griinfelder Host target testing A suggested strategy for crosstesting is 1 Execute tests in debug mode using instrumented software If possible in the host environment Ensure that coverage objectives are achieved Correct any errors in the software and in the test script 2 Verify that tests execute correctly in the target environment by repeating tests in target environment using uninstrumented software compiled with the
106. guideline for the size of the units is the following The units should differ in risk likelihood attributes and the units should differ in risk impact attributes Examples for units are source code modules functional components or library packages The splitting should be stopped when no existing unit contains parts that differ considerablly in a likelihood or in an impact attribute Likelihood Attributes For each unit determine a scale factor as the largest value of any of the qualities described n the following table Level of Optimization Defects Found Ear Changes Resources lier very small established function no optimization never ality never changed small lintrec uently revised Hess optimization infrequentl frequently revised heavy optimization requently very large permanently revised hon heavy optimization permanentls Classify the software change you are going to make according to the following table and take the largest scale factor as before RiskyCompany Inc Risk based Testing Donotusethiswithoutmodification 12 Work Instructions UK 12WA Exercise Scale Modification Requirements Design Newness of used Technologies Quality not modi clear requirements de festablished technologies used technology 15 hed bugtix sign well known and is used for this functionality small modifi elear requirements de fwell known technologies used but it was not cations sign partly unclear used for this functionali
107. h br uchte man nur eine message die beides glchztg macht start und SetRepIntv R SRD PP 70 1 Start Command Upon receipt of the data bytes 2nd byte XX the IOPS software shall start reporting the debounced oil pressure switch state at intervals specified in R SRD PP 60 The IOPS software shall not care about the 2 byte Shall not care about the 2 byte ist ein Nicht Requirement und so nicht testbar R SRD PP 80 1 Report Message Format The IOPS shall report the debounced oil pressure switch state by sending the following PP bus message 1st byte 2nd byte where STC 1 in case of an open switch and STC 0 in case of a closed switch 5 1 3 Requirements on the Sensor Interface Low oil pressure opens the oil pressure switch and the LSB of the digital I O port register of the MC4711 becomes 1 High oil pressure closes the switch the LSB of the I O port register becomes zero HW To ease the distinction in the following the term position will be used for the physical state of the sensor the raw sensor value whereas the debounced switch state is what the IOPS reports R SRD SI 10 1 Switch Position Sampling Rate The IOPS software shall sample the position of the oil pressure switch at a rate of 1kHz R SRD SI 20 1 Switch Position Spikes To compute the debounced oil pressure switch state the IOPS software shall use an algorithm that is tolerant to single outliers of the raw sensor position V llig redundant zu n
108. hall have Injection mass instaed of Injection quantity systemkonstante PRP_NORM_CONV_FAC J t wertp TROPRPHIGH_RES FACT1_RES INJ MASS RES Nm ma hub 1 IT Stephan Griinfelder Introduction to the Virtual Project MyConsultant TheCompany Ltd Intelligent Oil Pressure Switch Plan reviews Establish test plan Testing Unit Integration System Stephan Griinfelder Review Meeting of the IOPS SRD 1 0 x what kind of review meeting O Stephan Griinfelder Bad requirement 7 EA ee A R SRD CrCtl 15 2 When the last state of the panel was in NEUTRAL and the current position is COAST SET and the Governor is not ACTIVE and no shut off conditions present the CCTL state maching mode shall transit to MODE SET O Stephan Griinfelder Review of the IOPS SRD 1 0 Technical feasibility In Consistency E x AN Write short sentences Ne Clearly define what is part of the requirement and what is not shall should delimiters Avoid passive voice ee d Avoid multiple statements in one sentence the software checks if the input condition holds and the state matches or matched in the previous query Use tables lists and enumerations to state larger amounts of requirement text Use diagrams to illustrate complex requirements Avoid common speech and undefined abbreviations Keep requirements descriptions short Avoid reduncancies make unambiguous cross references only Avoid ant
109. hecking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder if x if y statement else something_else Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder void shame void int a b c m n p scanf Sd amp a if a b 6 else c b a c while n Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index types e Hierarchies of types Stephan Gr nfelder char cUartData char OxFA main unsigned uiA unsigned cUartData Capabilities of static code checkers Intendation checking Finding of common errors Initialization tracking Value tracking Evaluation order checking Function semantics Strong types e Index typ
110. his is planned for phase 3 ST Alt FTO1 fails when stalling the engine by mistake a MIN error occurs at DFP_AltExcl All other tests pass without problem Stephan Griinfelder Example test metrics Test coverage see unit 5 Test Progress instructions exercised total number of instructions Test costs Cost to locate defect Error ratio number of errors detected versus software system unit size Test efficiecy defects located by testing versus total system defects Effectiveness of testing loss due to problems versus test costs Rerun analysis rerun hours versus production hours Test automation ratio Stephan Griinfelder Test results may be reported in a variety of ways Some common means of recording results are Who wants to read all that test result forms recording the tester date and outcome of the test cases executed by the procedure execution logfiles Managers and SQAs want summary reports Stephan Griinfelder Unit 8 Verification of Low Level Software Stephan Griinfelder Generating and using system test error statistics Why statistics on system testing Find weaknesses in previous testing steps Find weaknesses of the system test process if flaw was found after testing Assess readiness for delivery Questions of cost and effectiveness as presented in unit 7 Stephan Griinfelder Generating and using system test error statistics Why statistics on
111. hod is not inherited by Derived but is instead overridden For the overriding definition Derived helper the only valid context is Derived Hierarchical Integration Testing Let us consider the level of testing required for inherited methods which are inherited using the example shown in figure 4 Base methods DerivedA DerivedB Base Inherited methods Inherited methods New methods New methods Figure 4 The software under test The Hierarchical Integration Testing HIT approach to unit testing was proposed as a technique for ensuring thorough class testing see Harrold for full details HIT recommends that as a first step all methods be tested fully in the context of a particular class the base class or for abstract base classes a particular derived class For a base class this would typically be interpreted as a coverage requirement of 100 decision coverage of each defined method in the context of the particular class This 7 IPL Information Processing Ltd 3 9 1 3 9 2 3 10 criterion is also known as Once Full coverage and is equivalent to the minimum traditional coverage requirement for thorough unit testing This recommendation applies to all classes so that re definitions of a method in a derived class overridden methods are tested with the same thoroughness as the original base class definition Interaction Coverage The HI
112. hort Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 esting for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated esting for the following conditions requires that a known database state be achieved Several database fields pointers and keys should be corrupted manually and directly within the database via database tools Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed In all cases above the application database and system should upon completion of recovery procedures return to a known desirable state his state includes data corruption limited to the known corrupted fields pointers or keys and reports indicating the processes or transactions that were not completed due to interruptions Recovery testing is highly intrusive Procedures to disconnect cabling Considerations simulating power or communication loss may not be desirable or feasible Alternative methods such as diagnostic software tools may be required Resources from the Systems or Computer Operations Database and Networking groups are required These tests would normally run after office hours or on an isolated machine 3 1 12 Configuration Testing Configuration testing verifies the operation of the target of test on different software a
113. iNewLatchValue GetValueForLatch SetLatchValue iNewLatchValue Push iNewLatchValue oder PushOnStack Standardisierung der Namensgebung Wie k nnen wir nun diese Erfahrungswerte in einen Standard einbringen Der erste Schritt ist wie erw hnt das Festhalten von Fachw rtern wie in Tabelle 1 gezeigt Die Liste der Fachw rter sollte auch branchenspezifische Begriffe umfassen und daher wesentlich umfangreicher als das gezeigte Beispiel sein Des weiteren m ssen wir die Verwendung dieser Begriffe standardisieren Regel 8 Verwendung von Fachbegriffen in Bezeichnern Die in Tabelle 1 angef hrten Fachbegriffe d rfen nur in der beschriebenen Form verwendet werden Regel 9 Verwendung von Get Set Take in Bezeichnern Die Vorsilben Get Set und Take m ssen von einem Hauptwort gefolgt werden das das von der Operation betroffene Objekt oder seine Komponente bezeichnet Dank dieser Regel sind auch die gelegentlich anzutreffenden und sehr rref hrenden Funktionsnamen der folgenden Art nicht gestattet ulNewLatchValue GetLatchValue berechne neuen Wert port_io LATCH1 uiNewLatchValue setze den Wert in Die Funktion GetLatchValue holt den neuen Wert nicht vom Register Latch sondern berechnet ihn daher ist die Bezeichnung GetValueForLatch viel angebrachter Die Wahl von Namen selbst ist schwer zu standardisieren Wohl aber k nnen wir Richtlinien aufstellen w e d e folgenden Empfehlungen und
114. icipating the software design Write testable requirements Content Functional Requirements Usability Requirements Requirements on Reliability and Accuracy Performance Requirements Supportability coding std maintainance access Design Constraints language code re use Interfaces hardware software user Standards legal constraints Stephan Griinfelder Verification of Low Level Software Contents Using UML to analyse requirements amp scenarios FMEA Fault Trees Review of the Software Requirements Document 2 0 Technical Review Meeting Test automation advantages drawbacks costs Writing a System Test Plan moderated team work Traceability Stephan Griinfelder Stephan Griinfelder Contents UML as Analysis Tool Unit 2 continued e Black box testing techniques e System test design principles categories examples e System test design exercise Stephan Griinfelder Stephan Griinfelder UML as Analysis Tool mino swe semenado a BI kMirorkemany Miners 1 l l l l l l l l l l l l A l l l l l l l Resad i I Restoreldenr 3 Stephan Griinfelder Stephan Griinfelder FMEA Failure Mode an Effect Analysis Part amp Potential Potential S Potential Function Failure Stephan Griinfelder FMEA likelyhood of occurance OCC Ranking Possible Probability of Failure Failure Rates 6 7 8 0 2 Very H
115. idered to be methods of the class in the sense that when they are invoked the object does not yet exist and thus there is no state with which to associate the coverage Alternatives are similarly defined for each of the traditional structural coverage metrics 11 IPL Information Processing Ltd 4 7 4 8 As with the standard coverage metrics system wide averages of state based context coverage across all classes in the system can also be defined What Are The Contexts The contexts for state based context coverage are just the states appropriate to the class Thus in the bounded stack example the contexts are empty partially full and full Unfortunately the presence of these states is a design feature which is not directly visible in the code In order for a tool to automatically gather state specific coverage information the code must be changed so that it defines the possible states and so that the tool can determine the current state The simplest solution is to define an additional member function which returns a string containing the current state For example class BoundedStack PUGLIE private const char eppe s user context funetton const 4 if num_elements 0 return empty else if num_elements max_elements return full else return partially full When provided by the user this specially named member function is used automatically by Cantata to det
116. iert dass sie f r eine Vielzahl von Programmiersprachen anwendbar sind Die Beachtung dieser Vorschriften erleichtert vor allem die Zusammenarbeit im Team und erh ht die Wartbarkeit der Software Das Layout von Quellcode ist nicht nur eine Frage pers nlichen Geschmacks oder eine Frage des Programmierstils Ein vereinheitlichtes Code Layout in einem Softwareprojekt ist eine wichtige Ma nahme zur besseren Interaktion von Teammitgliedern und damit ein unverzichtbarer Bestandteil eines Codierungsstandards 1 Im folgenden wird eine solche Standardisierung vorgestellt und mit Programmbeispielen illustriert Weil C die meist verbreitete Sprache im Sektor Eingebettete Systeme ist und das Layout zwangsweise mit der verwendeten Programmiersprache variiert sind die meisten Programmbeispiele dieses Artikels in C verfasst und sind damit automatisch auch f r C anwendbar Die hier angesprochenen Themen sind aber weitgehend sprachunabhangig und auf alle prozeduralen hoheren Programmiersprachen anwendbar insbesondere auch f r Java und Ada Der Gro teil des Artikels ist auch fur die Programmierung in Assembler relevant Regeln fur ein professionelles Layout das Leerzeichen In einem fr heren Artikel wurden bereits Regeln zur Namensgebung und Zahlendarstellung vorgestellt 2 Wir werden diesen Satz von Regeln nun erweitern Einige der Regeln werden erfahrene Programmierer als berfl ssig erachten weil sie diese ohnehin intuitiv anwenden ohne sich d
117. igh 5 Extremely High Failure Almost Inevitable Stephan Gr nfelder FMEA RPN Risk Priority Number RPN OCC SEV DET O ID R Effects of E Cause s of C E P Failure V Failure C IT IN SULIDOUISUY JO UOISIAIG SIUN JO OOYOS OPE IOJO 99MOS A 1000 rating implies a certain failure that is very likely hazardous and impossible to detect A 1 rating is a failure that is highly unlikely obvious and unimportant Rating below 30 are reasonable for typical applications Stephan Griinfelder FMEA serverity ranking SEV Effect Criteria Severity of Effect ci So citect Very Minor Very minor elleel on produci or system BEE perlormance Wiin Minor effect on product or system performance DN MN small effect on product pertormange Ihe product docs pol require repan Moderne Moderate effect on product performance The product requires re fh Signiticgant Product performance is degraded Comton o Be conviene Bunzlions may mot aperale 7 Major Product performance is severely allected mii funciona The avaiem mav not be operable xtreme Product is inoperable with loss of primary function he system is inoperable y AETIOLI Failure involves hazardous outcomes and or noncompliance wilh pol results or stars Havardous Failure is hazardous and occurs wilhoui warning lt suspends operation of the system anor involves nonsemplancg wih govi regulaleens FMEA likelyhood of detection DET Detec
118. ignored there is great resistance to reviews Stephan Griinfelder Dialog produces helpful pressure to clear up and explain the individual position Therefore the developer often becomes aware of defects himself which he had overlooked working all alone Reviews can be applied early in software development process Reviews can be applied before executable code is available to test it So the latency period of faults in the software development can be shortened significantly Stephan Griinfelder How to review a SRD Project Accepted Software ACCEPTANCE TESTS Stephan Griinfelder How to review a SRD How to review a SRD Stylistic Checklist Technical feasibility Write short sentences Clearly define what is part of the requirement and what is not shall should delimiters Avoid passive voice Avoid multiple statements in one sentence the software checks if the input condition holds and the state matches or matched in the previous query Use tables lists and enumerations to state larger amounts of requirement text Stephan Griinfelder Stephan Griinfelder How to review a SRD How to review a SRD Stylistic Checklist Contents Checklist RUP Use diagrams to illustrate complex requirements Functional Requirements Avoid common speech and undefined abbreviations Usability Requirements Keep requirements descriptions short Requirements on Reliability and Accuracy Avoid redunca
119. ilben klar wird Nun m ssen wir die Verwendung dieser Tabelle als Regel erfassen Regel 17 Schreibweise von Variablen und Konstanten Bezeichner fur Variablen und Konstanten mit mehr als einem Buchstaben mussen mit einem in Tabelle 2 erfasstem Pr fix versehen sein Der dem Pr fix folgende Variablenname selbst muss Empfehlung 15 befolgen Ein dem Pr fix folgender Namen f r Konstanten muss n Blockbuchstaben geschrieben sein G ltige Bezeichner f r Variablen und Konstanten sind dann zum Beispiel fPI 3 14159 typenbehaftete Konstante bDoorOpen true Bool sche Variable ulBaudRate 1200 e Ganzzahl ger Besitiver Werk y wBaudRate 0x04B0 ganzzahliger pos Wert 16 Bit breit fSimple 1 1234 einfache Gleitkommazahl dfDouble 4 0e 83 Gleitkommazahl h herer Aufl sung ppiJunk 0 ein Zeiger auf einen Zeiger auf einen ganzzahligen Wert Variable Type Boolean character d double precision width must be followded by another prefix e mern f floating point number in the default precision of the processor short integer uses only half of the default bit length of the processor integer default bit length of the processor pointer should be followded by another prefix that identifies the type to which the pointer is pointing to string the identification of the end of the string is supported by the A itself zero terminated Zerocterminated sg _
120. inability of the design Style use the same language as the A Use a design tool with a code SRD e e Visualisation use standardised figures generator and In the best Case a reverse to capture your design UML HOOD i S e Clarity pe of the design engineering interface Stephan Griinfelder Stephan Griinfelder Select an integration test cde Aal the IOPS SW Buttom up unit testing McCabe s structured integration testing unit 4 Set break points at interfaces and inspect data and control flow Perform system tests with an instrumented code that reveals Call Pair Coverage Perform system tests and analyse the Call Pair Coverage manually Stephan Griinfelder Stephan Griinfelder Detailed Design Review Unit 4 Verification of Low Level Software Stephan Griinfelder Code metrics Stephan Griinfelder Code metrics cyclomatic complexity A control graph represents the control flow in a module Control graphs are simplified flowcharts Blocks of statements with sequential logic are represented as nodes in the graph Branches between blocks of statements called edges are represented as arrows connecting the nodes McCabe defines the cyclomatic complexity v of a control graph as v e n 2 where e e is the number of edges e n is the number of nodes Stephan Griinfelder Contents Unit 4 Code metrics for Unit Testing and Integration Testing Bas
121. ings that are not required do not invent pass fail criteria if they are not properly defined e mean Le when you design the tests your intention must be to find bugs to crash the system not to proof that everything works smoothly from possible input ranges of data driven tests always take an invalid input one on the border an valid input on the border and its neighbour For example if an algorithm has to work on integers from 0 to 100 test the algorithm with inputs 1 0 1 99 100 101 e automatic from the last item it is already clear that manual testing gets boring and is prone to errors be creative to find means to do tests fully automatically This also may include the creation of new requirements to improve testability of the system An example test design is given below We assume that the software allows the user or another system via a command interface to select an unsigned 16 bit integer output range of a signal In case the signal amplitude does not fit within this range it must be clipped The example text contains reference numbers in parentheses which refer to comments given later Medcare hf CONFI DENTIAL Page 7 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 Identification ST CUDSP FTO2 Verify that the selectable signal clipping works Switch the signal source to test ramp mode 1 Select an output range from 0 to 0 2 Process the signal for 2 seconds verify tha
122. intf Die vertikale Ausrichtung des Blockende Zeichens passe Mich zum Blockbesginn 2eichen Listing 2 Veranschaulichung von Regel 8 Klammersetzung gem der im Artikel definierten om la MOJO Soo anime rola Klammer 7 OO SO mente 2 keamesteerz Dei Uneerprogrammene i GetXY 81X amp 1Y 73 Klemme rm ths rs Sis ona EE for itt or Kemi toll erie den mili oe Sten Eimpurvellue Anderung a Programmtlusses while k gt 30 ee icles e r o la cua Solera Gi eee roroa Ver e l E Ee beer exit 1 PN A ech Schluss loa O CLS IE ine SEN ee alien Se ano Er ser Melia y if 1 1 exit 0 Programm kuss de Mince EE SA esp telar mein SEMA SE Ee Eer Prever le e i reet e a I andere g ngige Klammersetzungsvorschriften und deren Slot center EE leg renta lente Se EE el EE DEE ono o if i Resale rol ende era eae Nachteile joer Unkon ene rome i Ken Implementierungen der C Standardbibliothek Wenn exit ein Makro ist dann kann die folgende Zeile So a EA a El AA pore levee er E E Cli ie EE Ee Die von if erwirkte Programmverzweigung unterscheidet wenig von einen kunktronsnamen 27 if 1 MS AA in KEE Listing 3 Beispiele zar Klammersetzung Regel 9 Klammern fur den Aufruf von Unterprogrammen Vor ffnenden Klammern die Parameter vom Bezeichner eines Unterprogramms trennen darf kein Leerzeichen stehen Regel 10 Klammern und Schl sselworte Zwischen einem Schl sselwort das
123. ion coverage ge 9 total number of decision outcomes Decision coverage measures the proportion of decision outcomes which have been executed A decision outcome is the evaluation of a control flow condition to true or false or for SEH or o While construct a to 2 O outcomes true and false and each switch statement corresponds to N 1 decision outcomes where there are N ases and a default case Stephan Griinfelder 21 relation to McCabe s complexity metrics Condition Coverage number of condition outcomes exercised Statement Coverage number of instrumented statements executed Statement coverage total number of instrumented statements a amp amp b printf hello Testcase l a 0 b 0 no pracical meaning Stephan Griinfelder Decision Coverage Branch Coverage number of decision outcomes exercised Decision coverage g total number of decision outcomes a amp amp b printf hello Condition coverage total number of condition outcomes A condition is either a decision except case statements or is the operand of a Boolean operator and is not itself the result of a Boolean operator Each condition has two possible outcomes true and false Stephan Gr nfelder Testcase 1 a Testcase 2 a Stephan Gr nfelder Condition Coverage number of condition outcomes exercised Condition coverage total number o
124. ion for maths tcd maths4 solution maths5 tcd pdf Stephan Griinfelder Testing test metrics example solution do nothing int a int b nop else nop else Would structured testing find the problem Testcase 1 a Would structured testing be able to find all possible problems in this function Testcase 2 a Stephan Gr nfelder 6 Testing test metrics Assume you can test all possible paths through a program Can you have full confidence in the tested program by having all paths tested How long would it take to test all paths of a normal program Stephan Griinfelder Advanced test tools Cantata is a tool that serves the teaching purpose but is superseded by an advanced product s You can inspect what happens inside Have a look at the CTI files the mktest bat and the test code generated What can state of the art tools do better Stephan Griinfelder Advanced test tools Advanced test tools Test tool is part of the IDE No TCD files The tool parses the source code and generates the TC environment by itself i e empty stubs and drivers the executable will not increase No definition of expected output necessary The tool Graphical display of boundary value analysis as a executes the code with the defined input and classification tree suggests the expected output In case a test case reveals an error the debugger of the IDE automatically jumps into the affected
125. ionality which differs the customer trom other competitors RiskyCompany Inc Risk based Testing Donotusethiswithoutmodification 12 UK 12WA Exercise Work Instructions Scale Modification customer demands rework customer demands rework and will not pay the whole amount customer demands rework and demands a fine customer demands rework and demands a very hich fine 2 not safety relevant D product damage possible o 9 impact on person s safety possible S Risk Assessment and Test Extent Now feed the scales into the Excel sheet found on the management intranet page and press OK to compute the risk level ranging from to 3 The following table gives the test procedure and tool required for the obtained risk level Risk Level Test Methods Test Tools System Testing only Simulator or target hardware Unit Testing 100 decision coverage and Cantatat 3 0 on host or tot System Testing target hardware Integration Testing 100 Call Pair Covg Cantatat 3 0 on target System Testing target hardware Unit Testing 100 MC DC Cantata 3 0 on target Warning this plan is pure fiction It is used in an exercise and should not be used in real life without implementing the conclusions drawn in the exercise 3 E4 ESA PSS 05 0 Issue 2 February 1991 FORM TEMPLATES REVIEW ITEM DISCREPANCY RID NO DATE ORIGINATOR 1 DOCUMENT TITLE 2 DOCUMENT REFERENCE NUMBER 3 DOCUMENT ISSUE REVISION NUMBER 4
126. ionen sondern sorgt nur fur ein sauberes Erscheinungsbild des Quellcodes Empfehlung 23 Zeilentrennung und Listen Die Zeilentrennung bei Auflistungen von Daten etwa die Initialisierung einer Feldvariable oder die Liste der Parameter bei einem Funktionsaufruf sollte nach dem Trennungszeichen erfolgen Der neue Eintrag in der neuen Zeile sollte linksb ndig nach dem ersten Eintrag der Liste ausgerichtet sein Bei Dezimalzahlen kann es auch g nstig sein sich bei der vertikalen Ausrichtung am Dezimalpunkt zu orientieren anstatt einfach linksbundig zu formatieren Dementsprechend k nnte man Empfehlung 23 auch umformulieren Zu guter Letzt wollen wir zum Thema Zeilenlange noch erw hnen dass das in Regel 19 geforderte Format der Funktionsbeschreibung und ggf auch ein Datei Header am besten exakt die maximal zul ssige Zeilenl nge verwendet um deren Einhaltung beim Programmieren zu erleichtern sofern ein Editor dies nicht unterst tzt Der Programmkopf In jeder Quelldatei sollte mit Hilfe eines standardisierten Datei Headers dokumentiert sein wer sie zu welchem Zweck schrieb Ein firmenspezifischer Codierungsstandard verweist hier am Besten auf Vorlagen in elektronischer Form die allen Programmierern zug nglich sind Welche Elemente ein solcher Datei Header beinhalten soll ist Geschmackssache die unten angef hrte Liste bietet eine breite Auswahl Am besten ist eine automatische Aktualisierung von m glichst vielen Elementen bei Verwe
127. keiner Weise getrennt In der Standard Template Library wird pl tzlich zwischen dem Zeitwort und der Destination ein Unterstreichungszeichen eingef hrt und die Funktion push_back definiert In Sprachen wie Ada oder Modula2 deren Entwicklung viel langsamer vor sich ging und die unter anderem auch deshalb weit weniger verbreitet sind finden sich derartige Unschonheiten nicht Weitere Ma nahmen Die vorgestellten lexikalischen Regeln s nd ein wichtiger Baustein eines Coding Standards Volle Geltung erlangen sie allerdings erst mit weiteren Standardisierungen die das Layout das Design das Konfigurationsmanagement und auch Elemente von verwendeten Programmiersprachen betreffen 2 Wir werden in unserem n chsten Artikel die vorgestellten lexikalischen Regeln um Feinheiten in Bezug auf Benennung von Makros und Dateien erweitern und uns ausf hrlich mit dem Code Layout auseinandersetzen Referenzen 1 http msdn microsoft com library techart hunganotat htm 2 Codierungsstandards in der Software Entwicklung fur Eingebettete Systeme Professionelles Codelayout Tipps zur Verbesserung und Standardisierung des Layouts von Quellcode Wenn ein professioneller Programmierstil in Form von Regeln und Empfehlungen dokumentiert ist so sprechen wir von einem Software Codierungsstandard Im folgenden Artikel werden Regeln vorgestellt die das Code Layout betreffen und wesentlicher Bestandteil eines solchen Standards sind Die Regeln sind so formul
128. l interrupts but the timer interrupt It contains an endless loop that waits with idle until the timer interrupt comes gets the switch position with the help of Dio and processes this data with a TDebouncer It sends MSG_OILSWITCH messages at the required intervals The interval length is measured with the help of ulSystemTime The self test 1s a takeover from the KJ project For its design refer to KJADD 6 4 4 Subordinates Main uses a TDebouner the Dio and the system library This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 10 6 4 5 Dependencies The only public function in Main is main It must be the first C function called by the runtime environment 6 4 6 Interfaces main does not expect any parameters 6 4 7 Resources The object hosts an empty PP bus Receive Interrupt service routine and requires an extra program memory segment for the self test 7 Feasibility and Resource Estimates From experience with similar projects it is estimated that less than 25 of the on chip memory are used and the CPU is idle 92 of the time 8 Traceability Matrix The following table depicts the trace form software requirements to the C function implementing the requirements R SRD PP 70 Start Command Main ProgrammingMode TT TT E R SRD SI 10 Switch Position Sampling Rate Debou
129. lar intervals via status messages on the PP bus 4 2 Purpose and General Functional Principle After power up the IOPS gets programmed The debounce times and report rates are negotiated via the PP bus Upon a start command from the main control the MC4711 Micro Controller starts transmitting the debounced state of the oil pressure switch at the negotiated rate in the range of seconds Primarily this messages are sent to show that the IOPS is alive However whenever the debounced oil pressure switch state changes the IOPS immediately sends a state message to the main control which must start appropriate actions During start up the MC4711 performs a self test If it fails then the IOPS does not respond to any command to show it is broken In case of errors during the operation the MC4711 reboots assertion failure A Program Operation e sa ae automatic unless Start Command processor start up memcheck fails Figure 1 State transitions of the IOPS TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 4 3 Hardware The IOPS is based on the MC4711 which implements a fully operational PP bus controller Thus issues like bus arbitration address decoding and message checksums are fully transparent to the firmware The MC4711 is a 16 bit controller running at 10MHz with 16kB on board RAM and 16kB EEPROM It also contains a digital I O port One of its pins is connected to the mechanical switch one to a
130. le users Successful completion of the test scripts without any failures and within acceptable time allocation ppeoiak For client server based systems comprehensive performance testing Considerations includes having a background workload on the server here are several methods that can be used to perform this including Create virtual user load to simulate many clients usually several hundred Remote Terminal Emulation tools are used to accomplish this load This technique can also be used to load the network with traffic Use multiple physical clients each running test Medcare hf CONFI DENTIAL Page 10 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 scripts to place a load on the system For embedded real time systems you should consider ways to measure the performance e g toggling a pin and recording its status with a digital storage oscilloscope or measuring idle cycles in a RTOS This might impose testability requirements on the software and hardware of the test object 3 1 6 Load Testing RUP defines Load testing as a performance test which subjects the target of test to varying workloads to measure and evaluate the performance behaviors and ability of the target of test to continue to function properly under these different workloads The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload For the
131. llen einer Programmiersprache zu tappen Dazu selbst braucht man zwar nicht unbedingt einen Codierungsstandard weil es gute Literatur am B chermarkt 2 Beitr ge im WWW 3 in Zeitschriften 4 und im g nstigsten Fall automatische Erkennungssysteme 5 gibt doch sollten derartige Vorschriften im Standard nicht fehlen Im einfachsten Fall bestehen die sprachabhangigen Designanforderungen aus Verboten von Sprachkonstrukten So verbieten die meisten Codierungsstandards f r C die Verwendung der goto Anweisung und einige C Standards die Verwendung von Objektattributen der Klass f kation protected Neben der Beachtung von Verboten kann auch Befolgung von Geboten die Robustheit und Zuverl ssigkeit des Programms erh hen Beispielsweise ist bei der Verwendung von Mehrfachvererbung oder beim berladen von Operatoren Vorsicht geboten Diese Themen sind daher Gegenstand von vielen Codierungsstandards fur C Ein guter Codierungsstandard widmet sich auch ausfuhrlich dem Thema Fehlerbehandlung Vor allem in C ist dies schon historisch gesehen ein Problem fur sich selbst Nicht einmal die Erfinder der Programmiersprache konnten sich auf ein einheitliches Design bei der Fehlerbehandlung einigen Regeln f r das bersetzen In Codierungsstandards wird h ufig auf Richtlinien zur bersetzung des Programms vergessen Die Programmierung ist mit dem Erstellen des Quelltextes noch nicht vor ber Je nach verwendeter Sprache sollte man Richtlinien f r Com
132. m den Beginn einer neuen Funktion leichter zu erkennen Wir formulieren unsere n chste Regel gem diesem Beispiel rder ER cla MIES tinga A Blickfang 1 3 Leerzeilen davor da ausserhalb von Funktionen Empfehlung 17 int ErsteVariablendeklaration int ZweiteVariablendeklaration KK KK KK KK KKK KK KR KK KK KK KK KK KK KK AA ner warnt KK KK KK KK KKK KK KR KK KH KK KK AAA Die malo ao 28 6 cerco Oy EEE AA static void DieFunktion int iParameter Diese Funktion demonstriert unter anderem die neg Einr ckung von Sprungmarken Der Parameter iParameter ist ein reines Anschauungsobjekt ohne Bedeutung KK KK KK IK KK KK KK IK KK KK KK IK HH HH HH KH KK KK KK KK IK KK KK KK KK KK i1Parametertt Blickfang 2 2 Leerzeilen davor da innerhalb einer Funktion Empfehlung 17 27 if iParameter gt 10 i i1Parametert if 1Parameter gt 20 goto Label void WeitererProgrammcode Label void WeitererProgrammcode if 1Parameter gt 100 O joss sia io loli Store od Ee Ehe zur lo 7 Mex eee Ceca O aereo is EE Eer kee kee Se SE doi oo EN o ol os Parameter Oy return D REO yf KK KK KK KK KK KK KK KK KK KK KK KK AA static int WeitererProgrammcode void Diese Funktion macht nachts Im Eehlerfall st der R ckgabewert 1 ansonsten 0 KK KK IK IK KK KK KK I KK KK KK KK HK HH HK HK KK HH KK IK KK KK KK KK KK Eee michwer ni ee ioe CSI See Ze
133. merged into one with a boolean parameter determining the behaviour class Base 1 Bubbre v id foo 6r baribocl Flag 4 e flag herzen EN helper This example is for the purposes of explanation only In practice such a transformation would not normally be made if foo ing and bar ing are separate enough concepts to have different names then it is unlikely that the merged method would be functionally cohesive A better solution would be to extract the common code into separate private methods invoked by both foo and bar 6 OIPL Information Processing Ltd 3 8 3 9 private virtual void helper bi class Derived public Base private virtual void helper I void test_driver Base base Derived derived base foo_or_bar false fi Test Case Al derived foo_or_bar true Ek Test Case Al The branches of foo_or_bar have not been fully tested in the context of either Base Or Derived only 50 inheritance context decision coverage has been achieved in each case Note that in this example traditional decision coverage would misleadingly indicate 100 coverage of Base foo_or_bar What Are The Contexts In the examples above the valid contexts for the inherited methods Base foo and Base bar Or Base foo_or_bar are simply Base and Derived For the method Base helper the sole valid context is Base since the met
134. meter durch die Reihenfolge der m Bezeichner der Funktion vorkommenden Hauptw rter definiert wird w e n WriteSampleToDAC int iSample int 1ConverterID oder indem immer zuerst das betroffene Objekt stehen muss was am besten mit einem objektorientierten Design vereinbar ist und auch von allen mir bekannten C Code Generatoren so gemacht wird Leider ist die Sprache C hier selbst inkonsistent wie man an den Funktionen fputc und fprintf erkennt Ein weiteres Design Detail kann durch Standardisierung Reibungsflachen bei der Zusammenarbeit m Team gl tten Ich empfehle w rmstens die Reihenfolge der Deklarationen in Dateien zu reglementieren Beispielsweise Regel 19 Reihenfolge von Deklarationen in Header Dateien In einer Header Date m ssen Deklarationen in folgender Reihenfolge erfolgen Makros Typen Variablen Initialisierungsroutinen andere Funktionen Regel 20 Reihenfolge von Definitionen und Deklarationen In einer Implementierungs Date m ssen Deklarationen und Definitionen in folgender Reihenfolge erfolgen verpflichtendes include der Header Date Makros Typen globale Variable lokale Variable das sind Variable mit dem Attr but static Prototypen von lokalen Funktionen globale Funktionen lokale Funktionen Undefinierte Ergebnisse und Schnittstellen Die Sprache C l sst den Compilerherstellern einige Freiheiten Beispielsweise ist die Reihenfolge der Auswertung von arithmetischen Ausdr cken nicht definier
135. methods in the context of the derived class The test cases form a parallel inheritance hierarchy which mirrors the inheritance structure of the software under test and enables base class test cases to be easily re used to test derived classes see Figure 5 TestBase Test Base methods TestDerivedA TestDerivedB Re test inherited Re test inherited methods methods Test new methods Test new methods Figure 5 Test classes and software under test form parallel inheritance hierarchies IPL Information Processing Ltd 4 1 This re use of base class test cases has the additional benefit of automatically testing the design for conformance to the Liskov Substitutability Principle LSP The LSP is an important object oriented design principle described in Liskov which helps ensure that inheritance hierarchies are well defined The use of a parallel inheritance hierarchy also forms the basis of the PACT method described in McGregor The only costs for this re use are the small initial effort to ensure that the test cases are structured so as to be re usable and the CPU time required to re run the test cases State Based Context Coverage In most object oriented systems there will exist a number of classes which can best be described as state machines Objects of these classes can exist in any of a number of distinct states and the behaviour of each class is qualitatively different
136. n was eigentlich abgebrochen wird Das gleiche gilt f r die Anweisung continue Regel 11 Kommentare f r break continue Zu jeder break oder cont inue Instruktion in einer Schleife muss ein Kommentar angeben welche Schleife betroffen ist Listing 4 illustriert eindrucksvoll wie Kommentare die Verschachtelungen verdeutlichen k nnen und w e wichtig es daher st die Sprungbefehle break und continue mit Kommentaren zu versehen Ein weiterer Befehl erlaubt uns vorzeitig aus dem Programmfluss auszubrechen return Strikte Codierungsstandards f r C gestatten nur exakt eine return Anweisung pro Funktion Die Lesbarkeit von Code kann aber aufgrund dieser Restriktion sehr leiden besonders wenn eine hohe Verschachtelungstiefe von if Instruktionen verschiedene Fehlerfalle unterscheidet Auch die korrekte Freigabe lokal benutzter Ressourcen kann schwieriger werden Ein Trick dem beizukommen ist eine Dummy Schleife wie sie in Listing 5 zu sehen ist mit definierten Variablenwerten f r nicht benutzte Ressourcen zu kombinieren Wir sehen n Listing 5 dass das Blockende der Schleife eigentlich als Sprungmarke verwendet wird und die Schleifenabbr che dort die Funktion einer got o Anweisung erf llen Wer eis Leics ae N a Owe tds Oa ae AO en while bIrgenwas ae ae eee ato if bNochwas break AS S Bite a aise ae EE if bIrgendwas amp amp bNochwas Ome ine e ero male kk See SONO ale eo eye ie MOIS elo ele le me
137. n address byte it is followed by two data bytes and a checksum byte The first and last bytes are stripped off by the PP bus controller R SRD PP 05 2 Ready Message If the self test R SRD INIT 10 passes the IOPS software shall send a PP bus message of the following format 2nd bys where VER identifies the firmware version Comment This message informs the main control about unwanted re boots of the MC4711 of the IOPS and about the need to re program the IOPS The exact format of VER is up to the software design R SRD PP 10 2 Message Definitions deleted Table 2 deleted R SRD PP 20 1 PP bus Performance Upon receipt of a command via the PP bus the IOPS shall reply within Ims measured between the first byte sent and the last byte received R SRD PP 30 1 Reply Message Format The first data bytes of the reply message of the IOPS shall be the ID 23 The second byte shall be a copy of the first data byte of the command the IOPS is replying to R SRD PP 40 1 SetPosDebTime Command Upon receipt of the data bytes 1st byte 2nd byte TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 8 the IOPS software shall set the positive debounce time for the oil pressure switch to an appropriate offset POS where POS shall be interpreted as a signed two bit complement number and the programmable range shall be from 0 to 2 seconds Comment the positive debounce time 1s the debounce time for
138. n external watchdog and one to a light emitting diode HW 5 Specific Software Requirements This chapter contains the formal requirements on the IOPS software 5 1 Functional Requirements 5 1 1 Requirements on the Initialisation Process R SRD INIT 10 1 Self Test After reset a selft test 1s performed that checks the RAM and the processor core R SRD INIT 20 1 Self Test Fail Silence The IOPS software shall only reply to PP bus commands when the self test at start up passes 5 1 2 Requirements on the PP bus Communication Each PP bus message consists of 4 bytes The first byte is an address byte it 1s followed by two data bytes and a checksum byte The first and last bytes are stripped off by the PP bus controller R SRD PP 10 1 Message Definitions The first data bytes shall be a message identifier according to the following table and the second data byte shall represent a parameter byte Die Beschreibung the fist bytes shall be a msg id ist eine Unsinn Darauf hat die IOPS SW keinen Einfluss Dieses Req ist v llig redundant zu anderen ID meaning direction set the state report interval control unit to sensor oil switch state report sensor to control unit acknowledge programming parameter sensor to control unit Table 2 IOPS related PP bus messages and meanings R SRD PP 20 1 PP bus Performance Upon receipt of a command via the PP bus the IOPS shall reply within Ims measured between the first byte sent
139. n falsche Blockstrukturen vort uscht 3 Um derartigen Fehlern nicht nur mit Layout Ma nahmen zu begegnen beachtet man am besten Regel 8 Geschwungene Klammern beim if statement Ist ein i statement l nger als eine Zeile lang so m ssen die Bl cke f r jeden m glichen Programmpfad mit geschwungenen Klammern gefasst werden Um den gegenseitigen Ausschluss bei zusammenh ngenden i f else Folgen zu betonen notieren wir Regel 9 Blockstruktur bei else if Wenn mehrere 1f statements durch else gekoppelt sind dann m ssen diese dem Layout von Listing 2 gehorchen if 4 x printf Einzeiliges if keine geschw Klammern Netter Trick am Rande Beachwenn ole w esobenstehengde sek statement Ee Wahl der Reihenfolge von Konstanter und Varibler den verlosen En Bene Ee 1f iRegel 8 Pes una se langer EE EH EE sono dl claveeeie Blloele alter surely a else Weder MalseN Block im geschwungene klommern gerasse sen 1f iRegel 9 AR else if x gt 4711 fam A oe a else if x 12 Ge ES aia else Fall 4 Die einzelnen F lle sind wie in einem switch statement auf gleichem Einr ckungs Niveau Der Zeilenbeginn mit else if erinnert dass die Bl cke sich aber gegen seitig ausschlie en Wenn else und if durch einen Zeilenvorschub getrennt sind ist dies nicht mehr sofort er Sere oleae 2 A A F F Listing 2 Beispiel zu Regeln 8 und 9 Wie man in
140. nc GetNewDebouncer Opern o R SRD SD 20 R SRD SD 30 1 Programming Language This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at Traceability Matrix for the Exercise R SRD PP 30 Reply Message Format ST IOPS FTO2 R SRD SB 10 Maximum CPU Load ST IOPS FT06 Medcare Projectname Test Object Software Test Plan Copyright 2004 Medcare hf All Rights Reserved Document Number D 0209 00 Document Revision 1 0 Date 3 Sep 2002 Document Classification CONFI DENTI AL This document contains proprietary confidential information that belongs exclusively to Mecare hf IS 105 Reykjavik Austurhli 7 No part of this publication may be reproduced transmitted transcribed stored in a retrieval system or translated into any language or computer language in any form or by any means electronic mechanical optical chemical manual or otherwise without the prior written authorization from Medcare hf PREPARED CHECKED FUNCTION SIGNATURE DATE Not the SW Designer Test Design The SW Designer Software Design Sys Knowledge Person System Engineer Stefan Stefansson Project Manager Document Distribution write here all persons involved in the project and let the project manager approve this list Document Change Log Modified Section Change Description 1 0 3 Sep 2002 ai initial version Sepp Hintergruber Medcare hf CON
141. ncies make unambiguous cross Performance Requirements references only Supportability coding standard maintenance access Avoid anticipating the software design Design Constraints language code re use Write testable requirements Interfaces hardware software user Standards legal constraints Stephan Griinfelder Stephan Griinfelder How to review a SRD Example Requirement Consistency Checklist PSS 05 R SRD Strt 10 2 If the memory self test fails Danger if the DSP shall clear the error register within different terms are used for the same thing 50ms after the start of the self test the same term is used for different things incompatible actions are required at the same time actions are required in the wrong order Stephan Griinfelder Stephan Griinfelder R SRD Strt 10 2 If the memory self test fails the DSP shall clear the error register within SOms after the start of the self test Stephan Griinfelder gt A Bad requirement 2 x O R SRD 5 2 12 1 To optimise gear shifting in the automatic transmission the state of the compressor shall be frozen for the time of the gear shift Stephan Griinfelder Pr Bad requirement 4 ES E R SRD AC 35 2 If the A C pressure falls below a minimum hysteresis threshold an instant shut off condition shall be fulfilled An instant shut off shall also be fulfilled when the A C pressure is over a maximum hysteresis threshold When using an A
142. nd hardware configurations In most production environments the particular hardware specifications for the client workstations network connections and database servers vary Client workstations may have different software loaded for example applications drivers etc and at any one time many different combinations may be active using different resources When designing tests think of interactions with software that is not a target of test Are there different versions that must be supported or configuration changes that might influence the test result For the ID of Configuration Test Descriptions use the acronym CT 3 1 13 Installation Testing Installation testing has two purposes The first is to insure that the software can be installed under normal and abnormal conditions Abnormal conditions include insufficient disk space lack of privilege to create directories etc The second purpose is to verify that once installed the software operates correctly This usually means running a number of the tests that were developed for Function Testing For test design consider to verify that the target of test properly installs onto each required hardware configuration under the following normal conditions e new installation a new machine never installed previously e update machine previously installed same version e update machine previously installed older version On the installed version run a defined subset of function
143. ndards erleichtert allerdings die Interpretation und verk rzt damit gegebenenfalls die Einarbeitungszeit eines neuen Mitarbeiters Warum Codierungsstandards Eine verk rzte Einarbeitungszeit neuer Mitarbeiter ist bei weitem nicht der einzige Grund der die Beachtung eines Codierungsstandards besonders m Bereich Eingebettete Systeme rechtfertigt Die Anwendung eines guten Codierungsstandards erleichtert das Schreiben von portierbarer Software erleichtert die Erstellung von robusten und zuverlassigen Programmen kann den Testaufwand erheblich reduzieren erhoht die Wartbarkeit des Codes erhoht die Lesbarkeit des Codes und erleichtert damit die Kooperation von Programmierern Dies gilt jedoch nur wenn der Einsatz eines Codierungsstandards rechtzeitig erfolgt Von der gewaltsamen Einf hrung von Codierungsstandards in laufenden Projekten in denen bereits Codiert wird ist eher abzuraten Ein Codierungsstandard ist nur rentabel wenn er 1m gesamten Projektzeitraum Anwendung findet Im folgenden widmen wir uns den Themen die ein solcher Standard abdecken sollte oder abdecken kann Er umfasst meist allgemeing ltige Vorschriften die unabh ngig von der verwendeten Programmiersprache sind und sprachabh ngige Bestimmungen Wir folgen diesem Muster und wenden uns zun chst allgemeing ltigen Vorschriften zu Im Normalfall unterscheidet ein Standard zwischen Regeln die beachtet werden m ssen und Empfehlungen die beachtet werden sollten L
144. ndete Abk rzung Chn1 ist gem Regel 2 wohldefiniert Einsatz in der Praxis Wenn Sie die vorgestellten Regeln und Empfehlungen in Ihrem eigenen Coding Standard verwenden dann sollten Sie einen formaleren Stil w hlen als Sie es hier m Artikel vorfinden Beispielsweise k nnen S e m Standard das Kap tel Namensgebung definieren und n Unterkapitel Generelle Richtlinien Namen f r Variablen Funktionsnamen u s w teilen Das erh ht den Wert des Dokuments als Nachschlagewerk die im Artikel gew hlte Reihenfolge ist rein didaktisch begr ndet und muss nicht unbedingt eine gl ckliche Wahl f r ein verbindliches Dokument sein Regeln in Ihrem Coding Standard sollten mit eindeutigen Bezeichnern versehen sein Die im Artikel gew hlte einfache Nummerierung l sst zwar ein einfaches Umwandeln einer Empfehlung in eine Regel zu ist aber ungeschickt wenn neue Regeln in der Mitte des Texts hinzugef gt werden Ein bessern geeigneter Bezeichner ist etwa R Nam Gen 4 2 f r die vierte Regel zur Namensgebung Unterkapitel Generelles Diese Regel wurde zuletzt in Version 2 des Coding Standards ge ndert Empfehlung E Nam File 1 1 identifiziert die erste Empfehlung zur Namensgebung von Files und ist seit Version 1 des Coding Standards unver ndert Diese Art von Bezeichnern l sst sich dann einfach in einem Protokoll f r ein Code Review verwenden um dem Programmautor aufzuzeigen welche Regel oder Empfehlung er verletzt ha
145. ndung einer computerunterst tzten Versionskontrolle e Copyright Statement mit Erw hnung der Firma des Erstellungsdatums und des Datums der letzten nderung e Name des Projekts f r das d e Quelldatei erstellt wurde e Verwendungszweck der Date des Moduls Querverweis auf ein Design Dokument oder Referenzen zu anderer verwendeter Literatur verantwortlicher Programmierer verantwortlicher Tester Teststatus verwendeter Editor verwendetes CASE Tool oder Dokumentations Tool verwendeter Compiler verwendetes Lint Programm aktuelle Versionsnummer und ganz wichtig die Revision History Es kann nicht oft genug betont werden wie wertvoll eine richtig gef hrte Revision History f r das Arbeiten mit der Quelldatei sein kann Sie ist ein berblick ber den Werdegang der Datei wer wann was und warum ge ndert hat Die entscheidende Information ist das warum denn wann was ge ndert wurde kann jederzeit mit einem elektronischen Versionsvergleich auch festgestellt werden Den Grund f r die durchgef hrten nderungen zu kennen kann viel Zeit und rger sparen insbesondere dann wenn man sp ter in Versuchung kommt eine nderung wieder zu revidieren deren genaue Ursache nicht mehr bekannt ist Sprache Werkzeuge amp Design Die vorgestellten Regeln zum Layout von Quellcode zu Zahlenformaten und zur Namensgebung sind weitgehend sprachunabh ngig 2 In Listing 5 k nnen wir aber sehen dass die Sprache C und viele andere Sprach
146. ner Funktion pr ft der Compiler Typen und Seiteneffekte sind unwahrscheinlicher als beim Makro Beispiele wo eine Inline Funktion Fehler vermieden hatte die bei der Verwendung von funktionsartigen Makros passieren konnen sind in der Funktion Horror in Listing 6 zu finden Die letzte Warnung zum Thema undefinierte Ergebnisse gilt Puffergr en Das ungepr fte Uberschreiten von Feldgrenzen ist ein schwer zu erkennender Fehler und die von Hackern am meisten benutzte Sicherheitsliicke in vernetzten Systemen In C gibt es keine Uberpriifung von Array Indizes und daher kann man dieses Problem nicht automatisch unterbinden Was aber 1m Rahmen eines Codierungsstandards m gl ch ist ist die Verwendung von Funktionen zu verbieten die Feldgrenzen nicht berpr fen Ein gutes Beispiel dazu ist sprintf 1st der erzeugte String zu gro f r den verwendeten Puffer so ist alles m glich vom glimpflichen Verlauf bis zum Programmabsturz an einer vollig anderen Stelle Die meisten Compiler bieten eine Umgehung solcher potentiellen Fehlerquellen an in unserem Beispiel ist das die Funktion EE Die Schlussbemerkung Die Beachtung von Codierungsstandards ist eine wichtige Ma nahme zur Qualitatsverbesserung und Effizienzsteigerung in der teamorientierten Software Entwicklung Codierungsstandards findet man im erzkonservativen Sektor der Entwicklung von Software f r sicherheitskritische Systeme genauso wie bei den Alternativen den Propheten v
147. never thrown IPL Information Processing Ltd 4 2 4 3 4 4 Using White Box Coverage Metrics If entry point coverage does not ensure thorough testing perhaps we should use a stronger coverage requirement say 100 decision coverage Unfortunately there are disadvantages to the adoption of such a requirement One factor is that there may be decisions in the code which do not correspond to features of the public interface Typical examples include error handling code and defensive programming idioms In these cases 100 decision coverage may be difficult to achieve A more significant problem is the inability of traditional structural coverage metrics to identify code which is missing altogether For example consider what would happen if the BoundedStack implementor forgot to check for the stack empty condition in pop Requiring 100 decision coverage would not help find this fault the missing condition is not there to be covered We Can Do Better Actually we can write a better test set than that required by any traditional structural coverage metric and without any knowledge of the internal details of the class The UML state transition diagram see figure 6 shows how the behaviour of the class changes depending on the current state This type of diagram is commonly used to describe the state dependent behaviour of classes Throws E BoundedStack underflow NS N N gt Q pop construction p
148. no header file 6 4 2 Purpose Main implements the big bulk of software requirements on the IOPS Virtually all except the debouncing and the low level routines 6 4 3 Function Main implements the following state machine The text at the transition edges indicates what happens inside main c invalid or no command received wait with for until the watchdog reboots the processor ProgrammingMode returns and main calls OperationalMode selftest returns to main which calls ProgrammingMode Operation Figure 2 UML state chart for the IOPS software The main function initialises the hardware and called components calls selftest sends the message MSG_READY to the main control After that 1t passes the control to ProgrammingMode and OperationalMode The private member function ProgrammingMode interprets and dispatches the PP bus commands and replies to them If a syntactically correct but semantically unkown command is received it stops kicking the watchdog The same happens if no valid command has been received since start up for 10 seconds To be able to respond to the PP bus commands in time and kick the watchdog ProgrammingMode enables the PP bus receive interrupt and the timer interrupt The function idle is called in a loop After this call ProgrammingMode checks which interrupt has woken up the CPU The private member function OperationalMode disables al
149. nt Stephan Griinfelder Organisational Approaches for Unit Testing Stephan Griinfelder Organisational Approaches for Unit Testing Stephan Griinfelder Top Down Testing teg Cua aerer Fee Ea Bi Tested Stephan Gr nfelder Isolation Testing ra ra Stephan Griinfelder Integration Testing Stephan Griinfelder Bottom Up Testing A Driver Cua erer Ei Hua Bi Tested Stephan Gr nfelder Isolation testing tool support l instrumenter J target compiler compiler target linker Integration Testing Integration tests verify that the software components work correctly with the rest of the system and as specified in the architectural design Consequently integration tests checks that e all data exchanged across an interface agrees with the data structure specifications and e confirm that all the control flows in the ADD have been implemented Stephan Griinfelder Integration Testing Possible Approaches e Buttom up unit testing as shown before McCabe s structured integration testing unit 4 Set break points at interfaces and inspect data and control flow Perform system tests with an instrumented code that reveals Call Pair Coverage Perform system tests and analyse the Call Pair Coverage manually Stephan Griinfelder How does SW design influence testing Example 2 no problem
150. ocument Distribution List Hansi Hinterseer Arnold Schwarzenegger Cindy Crawford Hubert von Goisern Change Log deleted R SRD PP 10 acc to MoM RID 2 R SRD PP 70 reworded the requirement e D D D refined R SRD SI 30 with a figure that explains the debouncing in detail acc to MoM RID 5 Refined R SRD RA 10 deleted R SRD SI 20 acc to MoM RID A Das Datum und die Ausgabenummer in der Kopfzeile stimmen nicht TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 3 Table of Contents MS o ee es see E er et ee 4 Ma e A ne ed erstere 4 132 SADOUL TALS and Previous Ist ee A 4 E E eet EE 4 2 LEE 4 2 1 Appleable Documents ansehen endl ansias 4 224 ANA AAA ee O O 5 S SE Rene A O 5 3 1 Requirement LOMA and Nimbeins zes aan Denia Def 5 3 2 EEN essen sehen 5 3 3 General Technical Terms and Eeer Eed 6 A iD e AAA ale 6 41 OPS Et 6 4 2 Purpose and General Functional Prmncuple 6 AOS EN oa 7 eh SPec SOf EIER eege 7 Sal Funcion Require me Eeer 7 5 1 1 Requirements on the Initialisation Process 7 5 1 2 Requirements on the PP bus Communcatpon a 1 3 1 5 Requirements on the Sensor Interface za aan essen 8 SLA Relabil Wand A CCU see ee 9 3 2 SO Ware Bude Lesers esse a Na ee esse 9 353 SO W re DES oculista cdas 10 o Kee 10 TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 4 1 Intoduction 1 1 Purpose This document is part of the Project Little
151. of a closed switch Was wenn nach der READY Nachricht gleich ein START Kommand kommt Welche Default Werte Wenn das nicht spezifiziert ist und egal ist dann ins User Manual Sowas k nnte man ggf durch Aufzeichnen von Szenarios Sequence Diagrams erkennen 5 1 3 Requirements on the Sensor Interface Low oil pressure opens the oil pressure switch and the LSB of the digital I O port register of the MC4711 becomes 1 High oil pressure closes the switch the LSB of the I O port register becomes zero HW To ease the distinction in the following the term position will be used for the physical state of the sensor the raw sensor value whereas the debounced switch state is what the IOPS reports R SRD SI 10 1 Switch Position Sampling Rate The IOPS software shall sample the position of the oil pressure switch at a rate of 1kHz R SRD SI 20 2 Switch Position Spikes deleted R SRD SI 30 2 Debouncing Algorithm To compute the debounced oil pressure switch state the IOPS software shall use an algorithm that TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 2 0 Page 9 integrates over the raw sensor values as outlined in Figure 2 If all raw values sampled within the debounce time correspond to a different state than the current debounced oil pressure switch state then the state flips and it takes at least the same number of samples of opposite switch positions to flip the state again raw position deb state
152. of complex thread interaction 1ssues Conclusion Traditional structural coverage metrics are inadequate measures of test thoroughness for object oriented software systems New object oriented context coverage metrics are required to ensure thorough testing Inheritance state based and thread based context coverage metrics are a useful and practical addition to the unit tester s tool set Inheritance context coverage can be used in conjunction with traditional structural coverage metrics and with little additional cost to ensure that polymorphic interactions between methods are fully tested in each derived class Similar techniques can be applied to uses of template based compile time polymorphism State based context coverage can be used again in conjunction with traditional structural coverage metrics to ensure that classes whose behaviour depends on an internal state have been thoroughly tested In particular state based entry point coverage 1s an appropriate metric for black box unit testing of classes with state dependent behaviour The underlying techniques of context coverage can also be extended to apply to assist with other coverage problems such as the testing of multi threaded applications References Binder Binder B The FREE Approach to Testing Object Oriented Software An Overview http www rbsc com pages FREE html Harrold Harold MI and J D McGregor Incremental Testing of Object Oriented Class Structures h
153. on Extreme Programming XP und Co Ihre Einf hrung und Durchsetzung kostet aber einiges an Kraft Wie XP Guru Kent Beck in seinem letzten Buch bemerkt Programmierer sind Individualisten sie w rden eher die Firma verlassen als ihre geschwungenen Klammern anders zu platzien 6 Doch zum Gl ck gibt uns der Guru noch einen wichtigen Hinweis es sel denn man kann sie davon berzeugen dass die Chance Mitglied 1m Gewinner Team zu sein dann gr er ist Referenzen 1 Codierungsstandards in der Software Entwicklung f r Eingebettete Systeme Ein guter Programmstil will standardisiert sein Professionelles Codelayout 4 Steve Dewhurst One at a Time Please C C Users Journal 2001 H 8 S 46 bis 50 European Space Agency ESA PSS 05 10 Guide to Software Verification and Validation Siehe zum Beispiel http esapub esrin esa it pss pss ct03 htm 6 Kent Beck Extreme Programming Explained Addison Wesley 2001 melde echten siete rede rinnen de fire SUPA RIDINGS ices x Cay besser seberenreherperreke 4 define SOU ARE EE EE jek ie alee EE E EE EE oad Horror neigen Sirois EINE zu 5 SILO Oa oe sie Eeer oo 2 ar le Wee oe dose She eses 10 el oe 36 SOUARE AM Stops ee EE o x 2 x SQUARE2 x Sa EE N KKK KK KK KKK KK KK KKK KK KK KK KK KK IK IK KK KK KK KK KK KK KK KK KK Vord marn Dieses Programm wird fehlerfrei und ohne Warnungen unter MS Warsueds Or 6 Deub
154. on with the software The goal of Ul testing is to ensure that the User Interface provides the user with the appropriate access and navigation through the functions of the target of test In addition Ul testing ensures that the objects within the UI function as expected and conform to corporate or industry standards Do not place tests into this subsection that check functional requirements on the user interface These tests belong into section 3 1 2 Instead use this section to uncover implicit requirements that were forgotten to be included into the Software Requirements Specification and check the usability of the product and the robustness of the Ul Medcare hf CONFI DENTIAL Page 9 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 3 1 5 Identification ST Test Object Acronym UI01 Navigation through the target of test properly reflects business functions and requirements including window to window field to field and use of access methods tab keys mouse movements accelerator keys Window objects and characteristics such as menus size position state and focus conform to standards Technique Create or modify tests for each window to verify proper navigation and object states for each application window and objects EES Each window successfully verified to remain consistent with benchmark a version or within acceptable standard Gier Pi all properties for custom and thi
155. onal information in the form of the additional member function to return the current state In contrast traditional structural coverage metrics such as decision and condition coverage are based purely on the structure of the software under test and therefore require no additional information As a result traditional structure coverage metrics are typically weak at highlighting faults of omission requirements which have simply not been implemented Suppose through an oversight that the code to implement a particular requirement is missing There is no hint in the code that the requirement exists and no traditional structural coverage metric will force the testing of the missing requirement The use of an independent source of additional information means that state based context coverage has the potential to go beyond the constraints of traditional structural coverage metrics and highlight these faults of omission For example areas of unimplemented functionality can be identified by analysing those areas for which state based entry point context coverage has not been achieved while 100 traditional non context decision coverage has been achieved Achieving State Based Coverage Achieving 100 state based entry point coverage typically requires more test cases than are required for traditional entry point coverage and fewer than are required for traditional decision coverage Moreover because the test cases which are required to
156. ondition coverage requires exhaustive testing of the input combinations to a decision In theory multiple condition coverage is the most desirable structural coverage measure but it is impractical for many cases For a decision with n inputs multiple condition coverage requires 2 tests Stephan Griinfelder Condition Decision Coverage Condition coverage Min decision coverage condition coverage a amp amp b printf hello Testcase l a Testcase 2 a Stephan Griinfelder Modified Condition Decision Coverage printf hello Testcase l a Testcase 2 a Testcase 3 a Stephan Griinfelder Multiple Condition Coverage b printf hello Testcase 1 Testcase 2 Testcase 3 Testcase 4 Stephan Griinfelder Unit Testing on the test Given you test a unit and have reached multiple condition coverage Is this a sufficient criteria to stop unit testing Stephan Griinfelder Host target testing Recall from unit 3 isolation testing CASE 3 SSCALL debounc_Debounce SSNULL UnderTest c SSINPUTS _tDebID 2 _iRawSignal 0 OUTPUTS UnderTest cti 0 Driver c UnderTest o y y Driver o TestProgramm exe TT emmmer Host target testing Wei should one run unit tests on the target it tests are re run for integration ere is no nn a stubbed eal world tt data KSC e e C library Are and compiler bu
157. overed in the context of another derived class a Coverage achieved by testing DerivedA J Coverage achieved by testing DerivedB Inherited methods not exercised 2 Misleading coverage reported by traditional structural coverage metrics 5 Figure 3 Only 50 coverage of inherited methods in each derived class yet Base appears fully tested using traditional metrics This problem applies to all the traditional structural coverage metrics none of them take into account the interactions between inherited base class methods and the overridden methods in each derived class What Is Inheritance Context Coverage Inheritance context coverage is not a single metric but rather a way of extending the interpretation of any of the traditional structural coverage metrics to take into account the additional interactions which occur when methods are inherited Inheritance context coverage provides alternative metric definitions which consider the levels of coverage achieved in the context of each class as separate measurements The inheritance context definitions regard execution of the routine in the context of 5 IPL Information Processing Ltd 3 6 3 7 the base class as separate from execution of the routine in the context of a derived class Similarly they regard execution of the routine in the context of one derived class as separate from execution in the context of another derived class To achieve 100 inheritance context
158. piler Warnungen erstellen und Schalter f r Sprachstandards empfehlen Im g nstigsten Fall gibt es eine Norm f r Makefiles und die Verwendung einer Make Utility Probleme bei der Einf hrung eines Codierungsstandards in ein Unternehmen Wenn S e heute n Ihrer Softwareabteilung erstmals einen Codierungsstandard einf hren so d rfen S e nicht unbedingt mit Freudenspr ngen Ihrer Mitarbeiter rechnen Manche Softwareentwickler f hlen sich durch solche Standards in ihrer Kreativit t eingeschr nkt Auch ist es schwer einen einheitlichen Programmierstil zu finden der von allen freiwillig akzeptiert wird Einige k nnten ihren Programmierstil als eine pers nliche Note sehen und sich daher nur ungern auf einen Standard einlassen Die Einf hrung eines Codierungsstandards verfehlt seinen Zweck wenn e der Standard von den Mitarbeitern nicht als wichtig anerkannt wird und daher e er nicht rigoros eingehalten wird oder die Einhaltung nie berpr ft wird e die Software nur von einer einzigen Person entwickelt und gewartet wird und diese sehr erfahren und gewissenhaft ist Um einer Ablehnung durch Mitarbeiter entgegenzusteuern sollten diese vor der Einf hrung umfassend informiert werden und am besten am Standard mitarbeiten Es st auch wichtig anzumerken dass die Einf hrung eines Codierungsstandards nat rlich nicht automatisch gute Software garantiert und dies sollte auch bei weitem nicht die einzige Ma nahme zur Qualitatsverbesserung in
159. plate given below is straight out of RUP It describes the whole class of tests covered in this subsection and should give you ideas to design your own business cycle tests Identification ST Test Object Acronym BC01 Test Objective Ensure proper target of test and background processes function according to required business models and schedules Technique Testing will simulate several business cycles by performing the following e The tests used for target of test s function testing will be modified or enhanced to Increase the number of times each function is executed to simulate several different users over a specified period All time or date sensitive functions will be executed using valid and invalid dates or time periods All functions that occur on a periodic schedule will be executed or launched at the appropriate time Testing will include using valid and invalid data to verify the following the expected results occur when valid data is used the appropriate error or warning messages are displayed when invalid data is used Each business rule is properly applied All planned tests have been executed All identified defects have been addressed sc System dates and events may require special support activities Business Considerations model is required to identify appropriate test requirements and procedures 3 1 4 User Interface Testing User Interface UI testing verifies a user s interacti
160. r dpa 30 9 2003 Stephan Gr nfelder Ariane 5 crashed after the maiden launch The proximate cause of the crash was an overflow error due to an attempt to convert a 64 bit floating point value into a 16 bit integer Motivation THE LOSS OF EUROPE S ARIANE yagene eggene THE LOSS OF EUROPE S ARIANE 5 SUPER ROCKET AAA A A A A A erabruecht PR This error occurred in code Y Al that was non functional WU after liftoff when the error d 3 occurred Apparently an ae inertial platform from the Se Ariane 4 was used aboard the Ariane 5 without proper testing Stephan Griinfelder A Self Assessment Test A program reads three integer values from the command line The three values are interpreted as representing the lengths of the sides of a triangle The program prints a message that states weather the triangle is scalene isosceles or eq u i l ate ral allgemeines Dreieck gleichschenkelig gleichseitig Stephan Gr nfelder Evaluate your testing Stephan Gr nfelder Testing Embedded Systems is Fun mmm Ss Stephan Griinfelder Evaluate your testing Solution Stephan Griinfelder Evaluate your testing Stephan Griinfelder Why does software contain bugs Miscommunication or no communication Software complexity Changing requirements Time pressure Psychological issues at meetings general Poorly documented or poorly designed le
161. r Definitions verification activities include technical reviews walkthroughs and software inspections checking that design components are traceable to software requirements testing and audits European Space Agency Board for Software Standardisation and Control ESA software engineering standards Stephan Griinfelder Definitions Testing is the process of analyzing a software item to detect the differences between existing and required conditions and to evaluate the features of the software item Debugging means to detect locate and correct faults in a computer program Stephan Griinfelder Software Lifecycle Model SOFTWARE REQUIREMENTS ested ubsystems ARCHITECTURAL SVVPI INTEGRATION DESIGN t TESTS 3 D ADD e Tested Units Stephan Griinfelder Special considerations for embedded systems Stephan Griinfelder Special considerations for embedded systems How to run a unit test on the target hardware when the test tool is designed for PC software i e expects a stdio library and unlimited memory Stephan Griinfelder Costs of flaw repair vs flaw detection time DD UT project phase Stephan Griinfelder Special considerations for embedded systems Integration testing must consider software hardware interfaces How can you access test and debug data in the fully integrated system Stephan Griinfelder Special considerations for embedd
162. r function comment lines code lines gt 20 maximum nesting level of 5 Stephan Griinfelder Integration testing depth What kind of errors pass W integration testing y with 100 Call A Pair Coverage but are found A o with McCabe s 3 lt a Structured Integration Testing Stephan Griinfelder Use of software metrics for verification e Effort estimation of unit and integration tests e Rejection of designs that exceed metric thresholds i e e functions with v gt 10 e goto statements e more than one exit point per function e less than 20 comment lines e nesting level higher than 5 Stephan Griinfelder Code reviews Code reviews can be partially automated by software tools unit 5 However a manual review is indispensable and the cheapest and most effective way to find software errors Stephan Griinfelder Code reviews Code reviews Each programmer may have his her personal programming style and personal ideas of good or bad program code The need of code reviews means that programmers need to work as a team but different programming styles make the teamwork difficult Why not after unit testing Software coding standards Stephan Griinfelder Stephan Griinfelder Software coding standards Software coding standards help to Lexical standards Hungarian notation file ies names function names acronym standards e imp
163. r now that the functions each contain linear code only there are no decisions or loops at all Using a traditional structural coverage metric such as statement coverage as our guide we would answer yes to both questions since running test_driver would achieve 100 coverage of Base foo Base bar Base helper and Derived helper Compile Time Polymorphism With Templates The C template feature provides a form of compile time polymorphism As with inheritance based polymorphism a routine from one class can be invoked on objects of different types The template class corresponds to the base class where the routine is defined The instantiations correspond to derived classes which inherit the routine The template routine can in turn call helper routines where the particular helper routine invoked will depend on the type of the object For example a list template might invoke the contained object s copy constructor The copy constructor invoked will be the one corresponding to the type of the contained object which will be specific to a particular instantiation of the list template For the remainder of this paper only inheritance based run time polymorphism will be discussed However the principles and techniques involved apply equally to template based compile time polymorphism What Did We Miss We have not fully tested the interactions between Base and Derived Specifically we have not tested the intera
164. rd PLS Project Little Stream PP bus PowerPlant bus a company standard to interconnect sensors in a power plant RD Reference Document SRD Software Requirements Document 2 Documents In the event of a conflict between this document and an Applicable Document AD the AD shall have the precedence In the event of a conflict between this document and a Reference Document RD this document shall have precedence Any such conflict should however be brought to the attention of TheCompany Ltd for resolution This document has been established based on the issues of ADs and RDs as given below Issue changes of ADs and RDs will lead to an update of this document only in case of impacts on its content The valid documentation status is reflected in the relevant Configuration Items Data List 2 1 Applicable Documents MRD TheCompany 004537 Little Stream Marketing Requirements Document V2 1 ICD ABB IA PL 1520 00 PowerPlan Bus Interface Control Document Release 1 0 HW TheCompany 004545 IOPS PCB Design 1 0 TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 5 2 2 Reference Documents CS1 F Griesauer Guter Code braucht Ordnung Teil 1 Universelle Regeln zur Namensgebung und zu Zahlenformaten Elektronik Heft 18 2001 S 52 59 CS2 S Programmierer Guter Code braucht Ordnung Teil 2 Das Code Layout Elektronik Heft 8 2002 S 74 81 CS3 A Schlau Guter Code braucht Ordnung Teil 3 Fehlervermeidung
165. rd party objects can be accessed Considerations Performance Profiling Performance profiling is a performance test in which response times transaction rates and other time sensitive requirements are measured and evaluated The goal of Performance Profiling is to verify performance requirements have been achieved Performance profiling is implemented and executed to profile and tune a target of test s performance behaviors as a function of conditions such as workload or hardware configurations Identification ST Test Object Acronym PPO1 Verify performance behaviors for designated transactions or business functions under the conditions of normal anticipated workload and anticipated worst case workload Use Test Procedures developed for Function or Business Cycle esting Modify data files to increase the number of transactions or the scripts to increase the number of iterations each transaction occurs Scripts should be run on one machine best case to benchmark single user single transaction and be repeated with multiple clients virtual or actual see Special Considerations below For Real Time Systems the requirements on the performance should be well defined Other systems might soft criteria as the RUP defines Single Transaction or single user Successful completion of the test scripts without any failures and within the expected or required time allocation per transaction Multiple transactions or multip
166. rgends verwendet 4 General Description 4 1 IOPS Environment The objective of PLS is to provide the power plant designer with a set of sensors that all can communicate with the bus master the main control unit of the power plant The Intelligent Oil Pressure Sensor is one of them The IOPS hosts a mechanical switch that opens if the oil pressure of the turbine lubrication is lower than a temperature dependent threshold and closes if it is higher In normal operation the switch should be closed and an open switch would indicate a failure in the lubrication system However when the turbine runs on low speed it might open temporarily and when the turbine stops it must open otherwise it would mean that the switch is stuck The main control unit obtains the status of all sensors at regular intervals via status messages on the PP bus 4 2 Purpose and General Functional Principle After power up the IOPS gets programmed The debounce times and report rates are negotiated via the PP bus Upon a start command from the main control the MC4711 starts transmitting the debounced state of the oil pressure switch at the negotiated rate in the range of seconds Primarily this messages are sent to show that the IOPS is alive However whenever the debounced oil pressure switch state changes the IOPS immediately sends a state message to the main control which must start appropriate actions During start up the MC4711 performs a self test If it fails
167. rove the portability of the code Code layout rules e assisting in writing robust code Comment rules what has to be commented e improve the readability of the code where to which extent and consequently ease co operation in Design rules goto s number of exit points a team of programmers and reviewers Scale build rules no warnings ab Avoidance of language pitfalls Stephan Griinfelder Stephan Griinfelder Software coding standards Software coding standards layout example layout example ifdef SCHLECHTES_LAYOUT ifdef BESSERES_LAYOUT struct TPaar int iX int iY tPaar Regel 1 verletzt int iWertl Regel 1 verletzt int iWertl int iWert2 1 iWert3 2 Regel 1 verletzt int iWert2 1 iWert3 2 tPaar iX 12 tPaar iX 12 Regel 2 verletzt tPaar iY tPaar iX 19 tPaar iY tPaar iX 19 Regel 3 verletzt iWertl iWert2 iWert3 iWertl iWert2 iWert3 Regel 4 verletzt int piWert2 siWertl int piWert2 amp iWertl Regel 5 verletzt iKeineZeigerVariable iScheinbarZeigerVariable assert iWertl iWert2 assert iWertl iWert2 ms a EX iWert3 iWertl iWert2 3 iWert3 iWertl iWert2 3 dl 1 EX iWert3 iWertl iWert2 3 iWert3 iWertl iWert2 3 Stephan Gr nfelder Stephan Gr nfelder Software coding standards design example int Horror int main int i 12 int piArr
168. rs Listing 4 Beispiel zur Wichtigkeit von Kommentaren bei break und continue Die goto Anweisung ist nicht gerade popular in strukturierten Programmiersprachen und daher verbieten sie viele Codierungsstandards F r Eingebettete Systeme muss aber gelegentlich auf elegantes Design verzichtet werden wenn effiziente Code Generierung 1m Vordergrund steht Wenn in Listing 5 die break Instruktionen durch got o Anweisungen ersetzt werden dann kann man auch nicht plotzlich von schlechtem Design sprechen nur weil von goto Gebrauch gemacht wird Trotzdem empfehlen wir Empfehlung 12 Goto Anweisung Die got o Instruktion sollte nicht verwendet werden weil goto unglaublich gefahrliche Konstrukte erlaubt wie Listing 6 demonstriert Listing 6 hat noch mit zwei weiteren unglaublichen Stilbluten aufzuwarten Im Initialisierungsteil der for Schleife ist ein Funktionsaufruf zu finden der uberhaupt nichts mit der Initialisierung des Schleifenz hlers zu tun hat der Schleifenzahler ist als Index von piArray verwendet und wurde einen ungultigen Index erreichen weil in der Abbruchbedingung der Schleife ein Gr er gleich statt einem Gr er Zeichen verwendet wird Daher Regel 13 Verwendung des Schleifenz hlers in der for Schleife Die Ausdr cke in den runden Klammer der for Instruktion d rfen nur zum Setzen Pr fen und Ver ndern des Schleifenz hlers dienen Empfehlung 14 Abbruchbedingung in der for Schleife Die Abbruchbedingung des Schleifenz hle
169. rs sollte m t einem Gr er oder Kleiner Zeichen erfolgen nicht mit gr er gleich oder kleiner gleich SEA LEE alle verwendeten Resourcen m ssen im Kontext der Funktion definiert werden TResourcel ptResl NULL TResource2 ptRes2 NULL TResource3 ptRes3 NULL eo A O o le 54 ptResl malloc sizeof TResourcel 1f NULL ptResl Bm re POr eN EISOR HEr TEUER TRE D Pasa Aussceeg aS A EE ptRes2 malloc sizeof Tresource2 1f NULL ptRes2 FehlerReport KEIN_SPEICHER_FUER_RES2 breaks y E ans humic mony er ptRes3 malloc sizeof Tresource2 1f NULL ptRes3 FehlerReport KEIN_SPEICHER_FUER_RES3 make o s US Sed SO en Rania 2 I fe cela ok poleas ea nenmss na menge nem else yjyoleejelese Block sr chen ger ee whe Beiter rare ausschlie t sondern stehen einfach auf gleicher Einr ckungstiefe wie alle anderen Instruktionen der Funktion die sich nicht um das Bereitstellen EE DoSomething DoAnything nass er Dumm AS die gleichen Aufr umarbeiten f r alle Fehlerf lle oe URC MC Lee ANISM aie even Mole aa EE if ptResl NULL free ptResl if ptRes2 Le NULL free ptRes2 ie oebes eS NULL mises om INS es return jase erp ile en de iil NAGE re ua A O Listing 5 Eine Dummy Schleife und definierte Werte NULL f r nicht benutzte Resourcen erlauben die Verwendung von einem einzigen Exit Pfad pro Funktion ohne die Verschachtelungs
170. s Criteria Special Automatic test with a manual set up Considerations gt for this section think of tests that might destroy the integrity of the data obscure combination of data accesses obscure sizes Function Testing Function testing of the target of test focuses on the requirements for test that can be traced directly to use cases or system requirements The goals of these tests are to verify proper data acceptance processing and retrieval and the appropriate implementation of the requirements This type of testing is based upon black box techniques that is verifying the application and its internal processes by interacting with the application via its interfaces and analyzing the output or results This section will comprise the biggest part of the document In case of pairing in the sense of XP this section might just refer to the directory of the test cases which must be reviewed by a pair programmer and the organization of the files there When you pair it is recommended to first agree on a mockup of the test before implementing the test IMPORTANT If you do not pair then describing the test in textual form is the only way to review the test design Note that a textual description might be the only way to let Medcare hf CONFI DENTIAL Page 6 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 a systems engineer a hardware engineer an application expert to review the tes
171. s interfaces are effectively ignored Since polymorphism and encapsulation of behaviour are major features of any object oriented design metrics which ignore them are insufficient for determining whether the software under test has been thoroughly tested A New Way to Measure Coverage To address this Cantata introduces an extension to traditional structural coverage context coverage Context coverage is a way of gathering more data on how the software under test executes The context coverage approach can be applied to the testing of both polymorphic and state dependent behaviour The approach can also be extended to aid in the testing of multi threaded applications By using these additional object oriented context coverage metrics in combination with traditional coverage metrics we can ensure that the structure of the code has been fully exercised and thus have high confidence in the quality of our test set Three varieties of OO context coverage metrics are defined Inheritance context coverage metrics are designed to help measure how well the polymorphic calls in the system have been tested State based context coverage metrics are designed to improve the testing of classes with state dependent behaviour User defined context coverage metrics are also supported allowing the application of the context coverage approach to other cases where traditional structural coverage metrics are inadequate such as multi threaded applications
172. sprechende Typendefinition in einem Makro adaptiert werden der Rest des Quellcodes ist jedoch von der Adaption nicht betroffen und somit leichter portierbar Ihr pers nlicher Codierungs Standard kann eine entsprechende Regel vorsehen die die Verwendung dieser Typen vorschreibt Da eine derartige Regel sprachabhangig ist und wir uns in diesem Artikel mit weitgehend sprachunabh ngigen Aspekten befassen wird auf dieses Thema nicht weiter eingegangen Motivation einer guten Namensgebung Eine der wichtigsten Stutzen eines sauberen Programmierstils ist die Wahl aussagekraftiger Bezeichner fur Module Quelldateien Funktionen Datentypen und Variablen In diesem Artikel werden englischsprachige Namen verwendet weil nahezu alle kommerziellen Bibliotheken und die Programmiersprachen selbst Bezeichner in dieser Sprachen haben Ein haufiger Fehler von unerfahrenen Programmierern ist die Verwendung von zu kurzen bedeutungslosen Namen oder die unsachgem e Verwendung von Fachbegriffen Hier kann mit einem Coding Standard entgegengesteuert werden Er sollte eine Liste von Fachbegriffen beinhalten deren Bedeutung erl utern und die Verwendung dieser Begriffe in einem anderen Kontext verbieten Um die Wichtigkeit dieser Standardisierung zu unterstreichen hier ein paar Programmzeilen die die Regeln der guten Namensgebung schmerzlich verletzen a GetStack hole oberstes Element vom Stack Sea l GetLatchValue 1 neuer Wert f r das Register i
173. ss method and process seeding each with valid and invalid data or requests for data Inspect the database to ensure the data has been populated as intended all database events occurred properly or review the returned data to ensure that the correct data was retrieved for the correct reasons ou should specify the All database access methods and processes function as designed and without any data corruption Special Testing may require a DBMS development environment or drivers to Considerations enter or modify data directly in the databases Best perform the tests automatically in this way regression tests are accelerated the manual inspection of data is not needed and more realistic chunks of data can be used for testing Such tests also apply to firmware Even though there is no database it produces data and the integrity can be tested For example Identification ST CUDSP 1T02 est Obkeive _ Make sure the channel data is tagged with the right ID codes Set the ADC to test mode by shortcutting the test pins on blabla Start a recording via the command START_REC Set the system to the highest data sampling possible And change the sampling rate during the recording from highest to lowest rates at least twice For each data packet delivered by the test object verify that the channel ID is identical to the channel when being interpreted as unsigned 16 bit words Completion All verifications described above pas
174. t Empfehlenswert ist auch die Standardisierung und Protokollierung von Code Inspektionen und Code Reviews mit Hilfe von Checklisten Der Umfang an Standards und Vorschriften die den Programmierern zugemutet wird h ngt blicherweise stark vom Einsatzfeld der Software ab Die Standards zur Entwicklung von Firmware eines Herzschrittmachers sind sicherlich umfangreicher als die f r eine Windows Applikation bei der die Erwartungshaltung bez glich Softwarequalit t ohnehin recht gering st Scherz beiseite auch auf dem PC Sektor haben Coding Standards l ngst Einzug gehalten die Urform der Ungarischen Notation wurde von einem Mitarbeiter von Microsoft publiziert und im Application Programmers Interface WIN API auch weitgehend umgesetzt Leider finden sich gute Beispiele f r die Missachtung von lexikalischen Standards selbst in weit verbreiteten Programmiersprachen wenn sie zu schnell gewachsen sind wie C eindrucksvoll demonstriert so kann der Zustand der Klasse iostream etwa durch setstate gesetzt werden was unseren Anspr chen an einen Standard schon sehr nahe kommt aber die Breite der Zahlendarstellung wird mit width gesetzt anstatt mit setwidth Zu viele K che verderben den Brei die Mitglieder des C Konsortiums konnten sich offensichlich auf keine einheitliche Namensgebung einigen Aber auch auf keine einheitliche Schreibweise die Klasse istream definiert die Funktion putback put und back sind in
175. t Scale Safety 1 foe component protection and not MIT relevant umponenl protection MET relevant Scale ustomer Importance Risk based testing is the application of Risk Management to testing Hall03 defines a surprise factor as the likelihood that the risk is visible functionality ts nice to have functionality ts standard requirement functionality is important e g new functionality based on changed laws functionality is very important for the customer e g a functionality which differs the customer from other competitors Stephan Griinfelder Risk based testing A possible score for the testing effort requirement is likelinood x impact x surprise Similar scores may be used to select the tool test coverage test team automation extent see example guideline appended to lecture notes Stephan Griinfelder Conclusion e Different bugs are found in different phases of the software development with different techniques document reviews code inspection UT IT ST e No single of the above mentioned techniques can claim to find all bugs e IT IS ALL ABOUT MONEY Tune your testing according to the you get Stephan Griinfelder How likely do we detect a bug in an operational system Stephan Griinfelder Conclusion e Verification Testing Validation are related techniques but different things e Testing is a creative job Experience and training is needed e T
176. t design The existence of the textual description does not mean a test review does not have to take place What follows is a generic test description adapted from RUP Identification IST Test Object Acronym FTO1 e proper target of test functionality including navigation data entry processing and retrieval Technique Execute each use case use case flow or function using valid and invalid data to verify the following e The expected results occur when valid data is used e The appropriate error or warning messages are displayed when invalid data is used Each business rule is properly applied In case Verifications described above do not pass describe any tolerances here Identify or describe those items or issues internal or external that impact the implementation and execution of function test Where RUP defines business rules as a declaration of policy or condition that must be satisfied within the business Business rules are kinds of requirements on how the business must operate They can be laws and regulations imposed on the business but also express the chosen business architecture and style The test plan you write should now create instances of this class of tests covering all the requirements of the Software Requirements Specification Try to make the tests e orthogonal i e when one requirement changes take care that not all tests have to be revised e basic i e do not test th
177. t sofern die Mathematik offen l sst welcher Teilausdruck zuerst errechnet werden muss Des weiteren ist das Ergebnis eines Right Shift von negat ven ganzen Zahlen nicht definiert Ein Compiler kann wahlweise das neue h herwertige Bit mit einer Eins oder einer Null auff llen Zu beiden genannten Fehlerquellen finden Sie in Listing 6 in der Funktion Horror ein Beispiel Solche Ambivalenzen sind vielen C Profis bekannt sollten aber durch Regeln in einem C Codierungsstandard erfasst werden um Junior Programmierer zu warnen Beachten Sie auch dass in C beim Prototyp einer Funktion die Argumente undefiniert sind wenn keine angegeben werden so wie in Listing 6 zu sehen ist Dies kann naturlich zu Problemen bei der Integration von verschiedenen Modulen fuhren Regel 21 Prototypen Zu jeder Funktion muss ein Prototyp geschrieben werden der alle Argumente definiert Wenn wir Empfehlung 15 folgen dann ist die Header Date der richtige Platz f r Prototypen global sichtbarer Funktionen und die Implementierungs Datei der Platz von Prototypen lokal sichtbarer Funktion wie in Regel 20 bereits festgehalten Gute Lint Programme berpr fen die Einhaltung von Regel 21 automatisch Wenn ein Compiler Inline Funktionen zur Verf gung stellt und Portierbarkeit des Codes nicht gefordert ist dann empfehle ich die Verwendung von Inline Funktion der Verwendung von funktionsartigen Makros vorzuziehen auch wenn es sich nicht um ANSI C handelt Beim Aufruf ei
178. t at least one design item e an object is a class unless we talk about instances of an object e an instance of an object is a typedefed identifier that identifies one usage of a class with specific data e C functions operating on data belonging exclusively to a class are called member functions of the class The following acronyms are used in this document AD Applicable Document CPU Central Processing Unit IOPS Intelligent Oil Pressure Sensor 00 Object Oriented PLS Project Little Stream RD Reference Document SRD Software Requirements Document 2 Documents In the event of a conflict between this document and an Applicable Document AD the AD shall have the precedence In the event of a conflict between this document and a Reference Document RD this document shall have precedence Any such conflict should however be brought to the attention of TheCompany Ltd for resolution This document follows the ESA guidelines PSS 05 04 with minor modifications Stephan Gr nfelder stephan gruenfelder gmx at TheCompany Ltd Document No 004599 Date 15 Sep 2003 Issue 1 0 Page 5 This document has been established based on the issues of ADs and RDs as given below Issue changes of ADs and RDs will lead to an update of this document only in case of impacts on its content The valid documentation status 1s reflected in the relevant Configuration Items Data List 2 1 Applicable Documents SRD TheCompany 004589 IOPS Softwar
179. t the output is a zero line with the correct number of samples 3 Select an output range from 0 to 1 Process the signal for 2 seconds verify that the output is zero sample followed by ones Verify that the number of samples is correct Select an output range from 100 to 200 Process the signal for 0 5 seconds verify that the output comprises 100 zero samples followed by a ramp from 100 to 200 and samples of the value 200 Verify that the number of samples is correct 4 Perform similar tests for output ranges 65534 to 65535 and 65535 to 65535 Select reversed input ranges i e from 1 to 0 and from 65535 to 1 and process the signal for 2 seconds with these selections 2 All verifications described above pass The reversed input ranges shall result in an error log but shall not stop the system i e at least a correct number of output samples must be given S he software under test is run in batch mode to allow the test to be run Considerations automatically However the signal source must be switched manually to ramp mode to be fixed in release 2 0 6 1 We assume that the input signal can be switched to a ramp function covering all possible input values within 1 second If such a test function can help to automate a lot of tests it is worth adding such a testability requirement for the device software providing the input The implementation of this additional requirement will pay off by making testing easier
180. ten Art und Weise macht es leichter die L sung zu verstehen und vermeidet unn tige Neuentwicklungen So kann auch die Einf hrung von Standards in einer nat rlichen Sprache Missverst ndnisse ausr umen und die Eindeutigkeit von Aussagen erh hen Ein gutes Beispiel daf r ist die Verwendung der Juristensprache bei der Erstellung von Vertr gen Die dort verwendeten Redewendungen s nd m Idealfall unmissverst ndlich und exakt Als solche gen gen sie den Anforderungen eines Vertragstexts und sch tzen die Unterzeichner vor Unannehmlichkeiten oder Gesetzeswidrigkeit des Vertrags Allerdings st eine solche Fachsprache nicht gerade f r jedermann verst ndlich Sie muss erlernt werden Ist sie jedoch einmal erlernt so st das schnelle und unmissverst ndliche Formulieren und Verstehen komplexer juristischer Sachverhalte wesentlich leichter als zuvor Formale Sprachen also Programmiersprachen sind von sich aus unmissverstandlich weil sie sich sonst nicht in Maschinenanweisungen bersetzen lie en Allerdings oft nur f r den Computer denn jeder der einmal ein Computerprogramm fragwurdigen Stils studieren musste we wie leicht Fehlinterpretationen zustandekommen und wie schwer es oft ist dem Programm zu folgen Genau wie in der naturlichen Sprache helfen hier Standards Anders als in der nat rlichen Sprache muss dieser Standard aber nicht erst erlernt werden um dem Leser die Interpretation von Quelldateien zu erleichtern Die Kenntnis des Sta
181. tests to verify the correct installation For the ID of Configuration Test Descriptions use the acronym IN O Medcare hf CONFI DENTI AL Page 14 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 3 1 14 Software Build Consistency Check 3 2 RUP has no test reserved to check if the tested software build is actually the one intended to test But this document has The tests addresses the execution of a quality assurance policy Identification ST CUDSP SBO1 Test Objective Check the consistency of the labeled source code in the version control system and the object of test Technique On a clean PC install the compiler get the software sources of the target of test follow the build instructions for the software he resulting executable is the target of test Criteria Bd he target of test should also be found in the version control system Considerations Consider to make a snapshot of source directories and store them separately out of the version control system Test Tools The following tools will be employed for the testing campaign Think that test tools could be test data generators network load generators defect racking tools profilers emulators oscilloscopes and many more It is necessary to plan what Is needed at what time needs to be purchased needs to be developed to avoid surprises when the project runs out of time Medcare hf CONFI DENTIAL Page
182. the transition closed to opened switch R SRD PP 50 1 SetNegDebTime Command Upon receipt of the data bytes 1st byte 2nd byte the IOPS software shall set the negative debounce time for the oil pressure switch to an appropriate offset NEG where NEG shall be interpreted as a signed two bit complement number and the programmable range shall be from 0 to 2 seconds Comment the negative debounce time is the debounce time for the transition opened to closed switch R SRD PP 60 1 SetRepIntv Command Upon receipt of the data bytes 2nd byte the IOPS software shall report the debounced oil pressure switch state at intervals of min SEC 30 seconds as soon as it has been switched to operational mode by the message of R SRD PP 70 R SRD PP 70 2 Start Command Upon receipt of the data bytes 1st byte 2nd byte the IOPS software shall start reporting the debounced oil pressure switch state at intervals specified in R SRD PP 60 The value of the 2 byte of this message is not defined Comment Theoretically there is no need for a separate Start Command The IOPS software could transit to operational mode as soon as it receives the SetRepIntv Command However this is not wanted to be compatible with other sensors of the LSP R SRD PP 80 1 Report Message Format The IOPS shall report the debounced oil pressure switch state by sending the following PP bus message where STC 1 in case of an open switch and STC 0 in case
183. there is an extremely big person using the sensor Can the software still deliver useful results i e do filter coefficients and algorithms need adaptation For the ID of Input Range Test Descriptions use the acronym RT 3 1 10 Security and Access Control Testing Security and Access Control Testing focus on two key areas of security Application level security including access to the Data or Business Functions System level Security including logging into or remote access to the system Application level security ensures that based upon the desired security actors are restricted to specific functions or use cases or are limited in the data that Is available to them For example everyone may be permitted to enter data and create new accounts but only managers can delete them If there is security at the data level testing ensures that user type one can see all customer information including financial data however user two only sees the demographic data for the same client System level security ensures that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways When designing tests create tests for each user type and verify each permission by creating transactions specific to each user type Modify user type and re run tests for Medcare hf CONFI DENTIAL Page 12 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002
184. tiefe unn tig in die Hohe zu treiben Vorschriften an das Design In jedem Grundkurs zu Softwaredesign wird man aufgeklart dass globale Variablen schlecht sind und dass man m glichst wenige Schnittstellen zwischen Programm Modulen C Quelldateien haben sollte Als Begriindung wird meist Ubersichtlichkeit und Wartbarkeit des Programms angegeben Nun hat man bei der Programmierung Eingebetteter Systeme oft ganz andere Sorgen als ein elegantes Design Code muss sehr schnell sein und wenig Speicher verbrauchen Daher werden die einmal gelernten Design Richtlinien gerne vergessen und es wird in wildesten Stilen programmiert Davon ist dringend abzuraten Eingebettete Systeme haben namlich noch eine Eigenschaft die vom Projektmanagement gerne unter den Tisch fallen gelassen wird sie sind nicht einfach zu testen Je sauberer und modularer das Design ist desto besser lassen sich Programmteile isolieren und testen Auch der Umfang von Software Software Integrationstests wird durch ein durchdachtes Design drastisch reduziert 5 Daher folgende dringende Empfehlungen Empfehlung 15 Modulares Design Die C Software sollte modular und bestenfalls objektorientiert strukturiert werden Es sollte m glichst wenige Schnittstellen Programmaufrufe gemeinsame Variablen zwischen den Quelldateien geben Empfehlung 16 Design und Effizienz Software sollte zuerst nach den Anforderungen guten Designs entworfen werden erst optimiert werden wenn es sein muss
185. tion Probability Ls Almost Certain Detection ery High Chance of Detection High Probability of Detection Moderately High Chance of Detection Moderate Chance of Detection Low Probability of Detection Very Low Probability of Detection Remote Chance of Detection BU d Very Remote Chance of Detection Absolute Uncertainty No Control Stephan Griinfelder FMEA Example Part amp Potential Potential Function Failure Effects of Potential Cause s of C IDMA Interface transfer of EEC data from DSP to MPC Mode MPC reads other data than DSP writes Failure EEC displayed is incorrect Failure Static discharge when touching the device during application of the electrodes SULIDOUISUY JO UOISIAIG SIUI FO OOYOS OPLI 99MOS SULIDOUISUY JO UOISIAIG SIUI JO JOOYDS OPLI 99MOS Stephan Griinfelder FTA Fault Tree Analysis c Quality Management amp Training Limited 2003 Typical Fault Tree Anastlyses Stephan Griinfelder gt IOPS SRD 1 0 exhibits a system design flaw Stephan Griinfelder Review Meeting What type of review meeting Stephan Griinfelder FMEA FTA for IOPS FMEA e FTA with following top level scenarios 1 the IOPS is alive but does not communicate via the PP bus 2 the IOPS uses undefined or wrong debounce parameters Af Use UML sequence diagrams for analysis Stephan Gr nfel
186. try to do them as automatic as possible and as mean as possible The objective of the test design must be to break the test object not to show that it works fine 3 1 Testing Types In case the test object has some test features test signal generators etc that have impact on the subsequently described test cases mention them here briefly Every test gets a unique ID which should be used in the file names for automatic tests The ID consists of a subsequently explained prefix a hyphen a test object identifier and a test number that includes the type of the test For example ST CUDSP FT02 identifies the functional system test number two for the Digital Signal Processor in the Communication Unit of the PowerEmbla 3 1 1 Data Integrity Testing The databases and the database processes should be tested as a subsystem within the project These subsystems should be tested without the target of test s User Interface as the interface to the data Additional research into the DataBase Management System DBMS needs to be performed to identify the tools and techniques that may exist to support the testing identified below Medcare hf CONFI DENTIAL Page 5 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 3 1 2 Identification S Test Object Acronym IT01 Test Objective Ensure database access methods and processes function properly and without data corruption Invoke each database acce
187. ttp www cs clemson edu johnmc papers TESTING HITYhit ps Liskov Liskov B and J Wing A Behavioral Notion of Subtyping ACM Transactions on Programming Languages and Systems Vol 16 No 6 November 1994 pages 1811 1841 McGregor McGregor J D and A Kare PACT An Architecture for Object Oriented Component Testing Proceedings of the Ninth International Software Quality Week May 1996 14 IPL Information Processing Ltd Codierungsstandards in der Software Entwicklung fur Eingebettete Systeme Codierungsstandards haben in die Software Entwicklungsabteilungen von Unternehmen verschiedenster Branchen Einzug gehalten Diese oft firmenspezifischen Standards schreiben den vor in welchem Stil ein Software Ingenieur zu programmieren hat wobei machtige Standards nahezu alle Aspekte der Programmierung abdecken vom Schriftbild des Programms bis zu Designrichtlinien oder einschrankungen Der folgende Artikel beleuchtet die Bedeutung solcher Standards speziell fur den Bereich Eingebettete Systeme und gibt einen Uberblick iiber die Themen die ein Codierungsstandard behandeln sollte Auch Probleme die mit der Einf hrung eines solchen Standards in einen Betrieb einhergehen werden behandelt Sprachstandards nicht nur fur Technik amp Software Einer der vielen Nutzen von technischen Standards ist das Ausschalten von leicht vermeidbaren Fehlern und das messbare Einhalten von Qualitatskriterien Das L sen von Problemen in einer standardisier
188. tuelle Ersetzung mit Hilfe von Makros Makros k nnen Parameter ben tigen und damit Funktionen imitieren Sie unterscheiden sich aber in jedem Fall von Funktionen wie sp ter gezeigt wird Um C Makros deutlich von anderen Sprachelementen zu unterscheiden verlangen wir eine reservierte Schreibweise Regel 5 Schreibweise von Makros Namen f r Makros d rfen nur Gro buchstaben und das Unterstreichungszeichen enthalten Der Pre Processor gestattet auch die bedingte bersetzung von Code Von dieser F higkeit sollte aber nur sehr sparsam Gebrauch gemacht werden Manche Autoren raten sogar g nzlich von deren Verwendung ab 4 Tippfehler bei der Schreibweise eines Makros k nnen zu unerwarteten Ergebnissen f hren der Quellcode wird schwer leserlich Daher fordern die folgenden Regeln r gorose Tests und Dokumentation Regel 6 Dokumentation bedingter Ubersetzung Alle Makros zur bedingten bersetzung m ssen im Datei Header und im Designdokument beschrieben werden Regel 7 Wert eines Makros Erwartet eine Quelldate dass ein Makros einen bestimmten Wertebereich hat so muss ein Compilerfehler erzeugt werden wenn es ein einen ung ltigen Wert aufweist Ein Beispiel zu Regel 7 st n Listing 1 zu finden der Compiler stoppt wenn das Makro CPU einen unerwarteten Wert hat Hat ein Makro keinen berpr fbaren Wert so ist diese Technik nicht m glich Auch dazu sehen wir im Folgenden ein Beispiel In Listing 1 wird einfach gepr ft ob DEBUG
189. tural coverage metrics The alternative definitions differ in that they separately measure coverage in different contexts With inheritance context coverage the contexts depend on the inheritance structure of the software under test Similarly with state based context coverage the contexts correspond to the potential states of objects of the class under test Thus the state based context coverage metrics regard execution of a routine in the context of one state that is when invoked on an object in that state as separate from execution of the same routine in another state To achieve 100 state based context coverage the routine must be exercised in each appropriate context state Definition The state based context coverage variant of entry point coverage for a class in the context corresponding to a particular state is given by the number of methods which have been invoked on objects in that state divided by the total number of methods in the class The overall state based context entry point coverage is then defined as the average of the state based context entry point coverage in each state appropriate to the class Thus the overall state based context entry point coverage for a routine is given by NumberOfStates MethodsExercisedInState State BasedContextEntryPointC 4 100 Cet ep re RA ee ad NumberOfMethodsInClass x NumberOfStates i Note that for the purposes of state based context coverage constructors are not cons
190. tus ST CUDSP FT01 R MH 10 Button Debouncing ST CUDSP FT01 ST CUDSP FT02 AA AAA Zn o EE NOTE In case you do module testing white box function level testing or SW SW integration testing then just describe the the test strategy i e use of a module test tool compiler settings for the test environment in the next chapter and refer to the test cases which should be in electronic form only O Medcare hf CONFI DENTI AL Page 4 D 0209 00 Short Projectname Object Test Plan Date 3 Sep 2002 Issue 1 0 3 Test Strategy The Test Strategy presents the recommended approach to the testing of the target of test The previous section Requirements for Test described what will be tested this describes how the target of test will be tested For each type of test provide a description of the test and a short description what is covered with the test If a type of test will not be implemented and executed indicate this in a sentence Stating the test will not be implemented or executed and stating the justification such as This test will not be implemented or executed This test is not appropriate The main considerations for the test strategy are the techniques to be used and the criterion for Knowing when the testing is completed In addition to the considerations provided for each test below testing should only be executed using known controlled databases in secured environments IMPORTANT When defining tests
191. ty essential design requirements new technologies but it 1s used for a while It 1s modifications partly unclear sure that it is the required solution but it Is not controlled completely design requirements new technologies used for the first time new developedjcompletely unclear Then classify external circumstances according the the table below and note the largest scale factor corresponding to these influences Experience External Development Change of Developer Time Pressure very experi no problems with exter no change of developers normal time pres enced devel nal development sure oper s experienced Junimportant problems juncritical change of develop increased time developer s with external develop fers e g same know how pressure ment change very early in devel opment phase INeXperl important problems with very critical change of devel high time pressure enced devel external development opers e g change very late oper s in development phase very mexpe critical external devel very critical change of devel very high time rienced de Jopment opers eo change very late pressure e g veloper s in development phase many change of require developers changed ment near delivery Impact Attributes Scale Customer Importance is nice to have is Standard requirement is Important e g new functionality based on changed laws functionality is very important for the customer e g a funct
192. u fordern wie am Ende von Listing 4 zu sehen ist Es ist in Assembler auch schwierig f r jeden Sprung eine Einr ckung vorzusehen weil z B Fehlerbehandlungen zu unz hligen Spr ngen f hren k nnen In einem derartigen Fall st die Verzweigungsstruktur meist wesentlich komplizierter als in einer Hochsprache und die Einr ckungen waren dann eher kontraproduktiv Empfehlung 14 hilft beim Verfolgen von Sprungmarken und verzerrt dabei nicht den Kontext eines Sprungs Ein Beispiel f r eine negative Einr ckung ist ebenfalls am Ende von Listing 4 zu finden genauso wie die Kommentierung des Blockendes Vertikale Ausrichtung und Kommentarzeilen Der Beginn einer neuen Zeile oder die Verwendung von Leerzeilen kann die Leserlichkeit von Programmcode deutlich erh hen Hand in Hand mit dem berlegten Umgang mit dem Zeilenvorschub geht die gro z gige Vervollst ndigung des Codes mit Kommentaren Dabei ist es vorteilhaft Kommentare die ein Statement n der selben Zeile erl utern von jenen zu unterscheiden die eine eigene Zeile beanspruchen Empfehlung 16 Ganzzeilige Kommentare und Leerzeilen Kommentare die zumindest eine eigene Zeile beanspruchen sollten beschreiben was in den folgenden Programmzeilen bis zur n chsten Leerzeile passiert und linksb ndig nach diesen ausgerichtet sein Ausnahme Funktionsbeschreibungen s ehe Regel 19 Empfehlung 17 Blickfang Kommentare und Leerzeilen Kommentare die die Bedeutung mehrerer Programm
193. uments ansehen endl ansias 4 224 ANA AAA ee O O 5 S SE Rene A O 5 3 1 Requirement ELO Mat and Nimbeins zes aan Denia Def 5 3 2 EY POStap Mic CONE ae eege 5 3 3 General Technical Terms and Phiiaseszs ea asien 6 A iD e AAA ale 6 4t IOPS ENVIronment nia o e o Pa oa 6 4 2 Purpose and General Functional Prncple 6 AOS RW AEG oa 7 eh SPec SOf EIER eege 7 Sil Funcion Require me Eeer 7 5 1 1 Requirements on the Initialisation Drocess 7 5 1 2 Requirements on the PP bus Communicator 1 3 1 3 Requirements on the Sensor Interface aaa essen 8 SLA Reliability and A CCU see ee 9 3 2 SOU EE 9 35 SO Ware Desten EE 9 o Kee 10 TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 4 1 Intoduction 1 1 Purpose This document is part of the Project Little Stream PLS a sensor network for medium sized water power plants As a Software Requirements Document SRD it is the baseline for the software development for the Intelligent Oil Pressure Sensor IOPS which reports the oil pressure state of a turbine on the PowerPlant bus 1 2 About this Issue Issue 1 0 of the document was prepared for the PLS IOPS System Requirements Review It is mainly based on the PLS Marketing Requirements Document MRD and on the PowerPlant bus Interface Control Document ICD 1 3 Acronyms AD Applicable Document CPU Central Processing Unit IOPS Intelligent Oil Pressure Sensor LSB Least Significant Bit PCB Printed Circuit Boa
194. ung auf dieser Eigenschaft aufbauen und nur so das Z hlen von Leerzeichen in Strings m glich ist Regel 21 Maximale Zeilenbreite von Quellcode Jede Zeile des Quellcodes darf max mal 90 Zeichen umfassen Ausdr cke d e diesen Schwellwert berschreiten m ssen auf mehrere Zeilen aufgeteilt werden Regel 21 ist eine der wichtigsten der in diesem Artikel vorgestellten Richtlinien und gleichzeitig die kontroversiellste Regeln zur Namensgebung sollen uns einerseits dazu bringen aussagekr ftige und damit zumeist auch l ngere Namen zu w hlen Kommentare und die zuvor vorgestellten Regeln zur Verwendung des Leerzeichens machen Programmzeilen ebenfalls l nger als unbedingt notwendig Andererseits verlangt Regel 21 eine Beschr nkung der Zeilenlange und damit entweder einen Kompromiss oder die Aufteilung einzelner Ausdr cke auf mehrere Zeilen Damit diese Aufteilung nicht zu einer unbeholfenen Notl sung wird formulieren wir analog zu Regel 7 die folgende Empfehlung 22 Zeilentrennung und Operatoren Die Trennung eines Ausdrucks sollte an der Stelle eines Operators erfolgen der eine keine h here Priorit t n der ar thmetischen Auswertung hat als der vorhergehende oder folgende Operator Beispiel Weder der Editor noch der Debugger von MSVC 6 0 macht den Programmierer darauf aufmerksam dass rrt mlich eine zweite Instruktion weit ans Ende einer Zeile plaziert wurde Die folgende Empfehlung verhindert 1m Regelfall keine Fehlinterpretat
195. ush destruction pop partially full push ush Throws N SECH pop destruction BoundedStack overflow a pop destruction NS NS NS NS ki push Figure 6 State transition diagram for BoundedStack We can use the additional information provided in the state transition diagram to design a test set which thoroughly exercises the BoundedStack class Writing State Driven Test Cases The aim of our test design is to exercise every method in every possible state In the improved test set which follows the push and pop methods are invoked on an empty partially full and full stack 10 IPL Information Processing Ltd 4 5 4 6 int better test _driver BoundedStack stack 2 stack push 3 push when empty stack push 1 push when partially full try I stack piish 9 i J push when full catch BoundedStack overflow expected to throw stack pop pop when full stack pop pop when partially full try stack pop pop when empty catch BoundedStack underflow expected to throw 7i destructor called amplveitiy at end oT block The crucial issue is does this test set fully exercise the BoundedStack class State based context coverage 1s designed to answer this question State Based Context Coverage State based context coverage is similar to inheritance context coverage it provides alternative definitions of the traditional struc
196. ve readability Binary numbers are tagged with a subscript b like 0101 Hexadecimal numbers are tagged with a subscript h like 3FA9 Numbers without subscripts are to be interpreted as decimals TheCompany Ltd Document No 004589 Date 28 Aug 2003 Issue 1 0 Page 6 3 3 General Technical Terms and Phrases In the following table a definition of used technical terms and phrases is found kick a watchdog reset the watchdog timer 1 e reload it with a previously defined value mask an interrupt disable interrupt serving but latch the interrupt a company standard interconnection for sensors in a power plant Table 1 Technical terms used in this document 4 General Description 4 1 IOPS Environment The objective of PLS is to provide the power plant designer with a set of sensors that all can communicate with the bus master the main control unit of the power plant The Intelligent Oil Pressure Sensor is one of them The IOPS hosts a mechanical switch that opens if the oil pressure of the turbine lubrication is lower than a temperature dependent threshold and closes if it is higher In normal operation the switch should be closed and an open switch would indicate a failure in the lubrication system However when the turbine runs on low speed it might open temporarily and when the turbine stops it must open otherwise it would mean that the switch is stuck The main control unit gets the status of all sensors at regu
197. xercised as shown in figure 2 Base foo Exercised in B1 bar Exercised in B2 helper Exercised in B1 and B2 Derived foo y Exercised in B3 bar Exercised in B4 helper Exercised in B3 and B4 Figure 2 Better test cases give 100 inheritance context coverage 4 OIPL Information Processing Ltd 3 4 II Traditional Coverage Is Not Enough It is clear that when methods are inherited by a derived class some further testing is necessary This is true both for those methods which have been inherited unchanged and for those which have been overridden Coverage measurement needs to be more context dependent recording the class of the specific object on which the method was executed i e the context in which the coverage was achieved Coverage achieved in the context of one derived class should not be taken as evidence that the method has been fully tested in the context of another derived class Unfortunately traditional structural coverage metrics do just that They treat any execution of a routine whether it is in the context of the base class or a derived class as equivalent Thus Base bar is wrongly considered 100 covered when it has been exercised in the context of class Derived only As figure 3 shows OO code may be wrongly considered 100 covered by traditional metrics when in fact it has been 50 covered in the context of one derived class and 50 c
198. ystem Test Plan moderated team work Traceability Stephan Griinfelder Participants amp Expectations w e Who are you e What is your experience with software verification What do you expect from the course Stephan Griinfelder Contents Unit 1 continued e Case studies of requirements e Review of the Software Requirements Document 1 0 e Walkthrough Review Meeting Stephan Griinfelder Contents Unit 2 continued e Black box testing techniques e System test design principles categories examples e System test design exercise Stephan Griinfelder Contents Unit 3 Discussion of the system test design Organisational Approaches for Unit Testing Integration test plan What is good SW design how does it affect testing Technical review of the Architectural Design Document Stephan Griinfelder Contents Unit 5 Code review meeting software inspection Capabilities of static code checking tools Application of a code checker to the reviewed software Follow up review metric calculation and static check Unit test design Host target testing Getting started with Cantata and the TCD file format Stephan Griinfelder Contents Unit 7 Design and implementation of unit tests Bug tracking Generating and using unit test error statistics A note on OO test metrics Unit test Summary report System test readiness review Stephan Griinfelder Contents Unit 4
199. zeilen beschreiben welche auch durch einzelne Leerzeilen getrennt sein k nnen sollten durch Verwendung von speziellen Kommentarzeichen die Aufmerksamkeit des Lesers erwecken Diesen Blickfang Kommentaren sollten innerhalb einer Funktion zwei aufeinanderfolgenden Leerzeilen vorangehen ansonsten drei Leerzeilen Regel 18 Leerzeilen zwischen Funktionen bzw Unterprogrammen Funktionen oder in Assembler global sichtbare Einsprungadressen bzw deren Beschreibung m ssen vom vorhergehenden Quellcode durch drei Leerzeilen getrennt sein Beispiele zur Beachtung dieser Richtlinien sind in Listing 4 zu sehen Es macht Sinn den Blickfang Kommentar zu standardisieren In Regel 18 wird die Beschreibung der Funktion oder des Unterprogramms erw hnt In der Tat sollte zu jeder Funktion eine Beschreibung ihrer Schnittstelle existieren Das Format einer derartigen Funktionsbeschreibung k nnte und sollte ebenfalls Bestandteil eines Codierungsstandards sein Etwa die verpflichtende und einheitliche Deklaration von Eingabe Ausgabe und Ein Ausgabeparametern das Erw hnen aller verwendeten globalen Variablen die Beschreibung des R ckgabewerts und allenfalls Fehlerfalle Am Besten ist es ein Beispiel der standardisierten Funktionsbeschreibung in elektronischer Form zur Verf gung zu stellen und m Codierungsstandard darauf zu verweisen Listing 4 zeigt eine informelle Beschreibung der Funktionen mit einem einheitlichen Kommentar als visuelle Hilfe u

Download Pdf Manuals

Related Search

Related Contents

Owner Instructions Mode d`emploi  Proto Balance Mail – SMTP/POP Load Balancer Mail User Manual  NOMEX Multimeter  WebExTM Recorder and Player User's Guide for  RELATIONS PUBLIQUES  ÄKTA avant Operating Instructions  Reference and User Manual  NGCC Teleost Remonter annuel 2013 Index    Istruzioni d`uso Silver Schmidt  

Copyright © All rights reserved. Failed to retrieve file