Methodisches Testen von Programmen
... Anforderungen die an den Prozess gestellt werden, müssen auch durch seine Teilkomponenten erfüllt werden. So könnte es bei einem Prozess der sehr oft ausgeführt wird und eine festgelegte maximale Antwortzeit erfüllen muss, wichtig sein auch gekaufte Standardprodukte einem Lasttest zu unterziehen.Für weitergehende Informationen bezüglich des Tests von Software siehe zum Beispiel [Mye01]. ...
... Der Implementierungsaufwand in diesen Fällen fällt relativ gering aus. Da es im Bereich Qualiätssicherung sehr gut anwendbare Literatur (beispielsweise [Mye01], [AGB03]) gibt, und das Testen ebenfalls nicht zu den Schwerpunkten dieser Arbeit zählt, wird davon abgesehen, diese Problematik zu detailliert zu beschreiben. ...
Für die erfolgreiche IT-Unterstützung abteilungs- und standortübergreifender Anwendungsszenarien müssen die vorhandenen und zukünftig einzusetzenden Informationssysteme miteinander integriert werden. Aufgrund der sich häufig ändernden Geschäftsprozesse ist hierzu ein flexibler Integrationsansatz nötig, der mit geringem Zeit- und Kostenaufwand auch an geänderte Abläufe anpassbar ist. Dies bedingt, dass die vorhandenen, teilweise sehr heterogenen Systeme mit einer geeigneten standardisierten Schnittstelle versehen und als Service gekapselt werden. Die eigentliche Realisierung des anwendungsübergreifenden Workflows erfolgt dann durch eine zentrale Workflow-Orchestrierungsengine, die die einzelnen Services anspricht und miteinander verbindet.
In der ausgeschriebenen Diplomarbeit sollen am Beispiel eines Szenarios aus dem e-Government-Umfeld die in Form ereignisgesteuerter Prozessketten (EPKs) modellierten Geschäftsprozesse auf eine geeignete Service-orientierte Architektur abgebildet werden und dort mit Hilfe einer passenden Workflow-Orchestrierungssprache in ihrem Ablauf unterstützt werden. Als Orchestrierungssprache ist BPEL (Business Process Execution Language) vorgesehen.
... In the following several test design techniques are presented and explained in more detail based on [17][18][19][20], [13, p. 35ff], and [21, p. 11]: ...
... visited January 2013 17 FitNesse: http://fitnesse.org/, visited: December 2012 18 FIT: http://fit.c2.com/, visited: December 201219 WIKI is a hypertext-system for a website which allows its users to add, modify, or delete its content via a web browser. ...
Abstract
In today’s world the complexity of industrial automation systems increases
rapidly. Because of this complexity, the development of such automation sys-
tems becomes more time consuming and has to deal with adaptations of the
industrial automation code on short notice. The engineering efficiency has to
be increased in terms of reusability support of tested and testable software
components for upcoming projects in order to reduce the development time
and costs.
The intention of this thesis is to make a significant step towards an increase
in the quality of industrial automation software by providing a test infrastruc-
ture with appropriate testing techniques for industrial automation software.
To ensure the high software quality, testing processes are necessary which as-
sist the development engineers during the life-cycle of developing industrial
automation systems. Currently there is no systematic test process for testing
industrial control software in the industry. First steps are available in academia
to adapt testing techniques from the software engineering domain applied on
the industrial automation domain.
A new test framework is developed in this thesis which is able to sup-
port testing of industrial automation software, i.e. based on IEC 61131 and
IEC 61499, on various levels of detail and from different perspectives. New
criteria are proposed for selecting Unified Modeling Language (UML) mod-
els which are useable for specifying tests of industrial automation software.
According to the developed test framework, different testing techniques con-
sidering the different test levels are presented which are able to test industrial
automation software considering the Test-First Development (TFD) strategy.
Finally, a new automation component architecture and a new component de-
sign for developing industrial automation applications are introduced to sup-
port testability. Therefore, it is now possible to increase the quality of indus-
trial control software by using the newly developed test infrastructure.
... Grundsätzlich kann sorgfältiges Softwaretesten die Qualität und die Sicherheit von Software massiv erhöhen. Zum allgemeinen Thema "Testing" wurden aber bereits seit vielen Jahren zahlreiche Arbeiten verfasst (Myers 2001, Sommerville 2011 Für die Bildung der Metriken selbst ist aber immer noch wenig Hilfestellung vorhanden. Der Ansatz der Autoren, wonach Sicherheitsmetriken -zumindest für betriebliche Anwendungssysteme -entlang deren Lebenszyklusprozesse gebildet werden sollten, könnte damit die noch offenen Aufgaben zur Bildung der notwendigen Sicherheitsmetriken unterstützen. ...
Die vorliegende Arbeit schlägt eine prozessorientierte Sicht auf Informationssicherheitsaufgaben in Unternehmen vor, auf deren Grundlage prozessbasierte KPIs für die Informationssicherheit implementiert werden können. Dabei gibt es Kennzahlen, die den Prozess als solchen betreffen, und solche, die seinen Output betreffen. Die Unterscheidung zwischen diesen Kategorien ist fließend. Dem gegenüber stehen nicht-prozessbasierte Kennzahlen, die eindeutig rein technischer Natur sind. Diese Arbeit konzentriert sich auf Sicherheitsaufgaben im Zusammenhang mit betrieblichen An-wendungssystemen. Dadurch werden die Systeme erfasst, in denen die betrieblich relevanten Daten mit dem höchsten Schadenspotenzial verarbeitet werden, ohne sich in infrastrukturellen Details zu verlieren. Die Untersuchung erfolgt gegliedert nach den Lebenszyklusphasen betrieblicher Anwendungssysteme durch Betrachtung der jeweils relevanten Sicherheitsprozesse und der Anwendbarkeit prozessorientierter Sicherheitsmetriken. Bei der vorliegenden Arbeit handelt es sich um eine Neuauflage eines früheren Artikels der Autoren mit einer knappen Reflektion über die Entwicklungen in den letzten Jahren.
... Experten aus der Anwendungsdomäne können somit das Verhalten spezifizieren, ohne sich Gedankenüber konkrete implementationstechnische Einschränkungen (Datentypenkonvertierungen, etc.) machen zu müssen. Zudem Neben den hier erwähnten gibt es noch eine Fülle weiterer Black-Box-Test-Verfahren, die jedoch im Rahmen der Diplomarbeit nicht weiter betrachtet werden [Mye01]. ...
... For the execution of the functional test, two different methods are proposed within the literature [6]: ...
... Verification checks whether the system has been developed according to its specification and confirms consistency, completeness and correctness of the system. The methodology for verification is either a program proof (Schmitz et al. 1982) or a test strategy (Myers 1976Myers , 1982 ). The program proof confirms total correctness of the program logic with mathematical methods, the test strategy confirms partial correctness of the program with given test cases. ...
The evaluation of clinical information systems is essential as they are increasingly used in clinical routine and may even influence patient outcome on the basis of reminder functions and decision support. Therefore we try to answer three questions in this paper: what to evaluate; how to evaluate; how to interpret the results. Those key questions lead to the discussion of goals, methods and results of evaluation studies in a common context. We will compare the objectivist and the subjectivist evaluation approach and illustrate the evaluation process itself in some detail, discussing different phases of software development and potential evaluation techniques in each phase. We use four different practical examples of evaluation studies that were conducted in various settings to demonstrate how defined evaluation goals may be achieved with a limited amount of resources. This also illustrates advantages, limitations and costs of the different evaluation methods and techniques that may be used when evaluating clinical information systems.
... A lot of work has been done in the realm of testing that aims to make sure that the test suite covers all relevant cases. A classical example is the use of code coverage metrics[40] in order to make sure that the test suite covers all parts (statements, paths, etc.) of the system. However, their significance in multi-threaded systems is limited because the effects of concurrency are not accounted for. ...
In this work we follow an intermediate approach that tries to use sound and conservative static code analysis techniques to avoid certain classes of bugs without having to conduct a full blown formal proof of correctness. The methods developed in this work are tailored to concurrent systems where global data is shared between all threads. While this requirement is not strictly necessary for the soundness of the analysis we shall see that it greatly increases the accuracy. In this context accuracy refers to the likelihood that a problem reported by the analysis is caused by an actual bug in the software and not by an inadequacy of the analysis methods. The usefulness of the methods presented will be supported by several case studies conducted on real life software systems of significant size.
Die harten Marktanforderungen an die Elektronikproduktion bezüglich niedriger Herstellungskosten und kurzer Produktlebenszeiten lassen sich nur durch den effizienten Einsatz moderner automatisierter Produktionsanlagen, wie z. B. SMD-Bestücklinien, erfüllen. Diese Anlagen sind auf Grund der geforderten Flexibilität, der hohen Produktionsleistung und der geforderten hohen Produktqualität geprägt durch komplexe Steuerungssoftware. Häufig stellt die Entwicklung der Steuerungssoftware den entscheidenden Faktor dar, der die Marktreife der Produktionsanlagen verzögert. Gerade bei Steuerungssoftware mit hoher a-priori-Anpaßbarkeit, die durch Parametrierung an unterschiedliche Anlagenlayouts angepaßt werden kann, kommt es entscheidend darauf an, bereits während der Entwicklungs- und Testphasen die Anzahl der Fehler so weit wie möglich zu reduzieren, da die Fehler, die erst nach der Auslieferung entdeckt werden, viele Kunden betreffen, damit sehr hohe Behebungskosten nach sich ziehen und das Image des Herstellers entscheidend beeinträchtigen. Es wurde gezeigt, daß zum gesamtheitlichen Testen der auf einem Linienrechner eingesetzten Steuerungssoftware, bei dem neben der Benutzerkommunikation auch die Anlagenkommunikation getestet wird, die Simulation ein geeignetes Hilfsmittel darstellt. Das entwickelte Simulationssystem HSSIM bildet das Kommunikationsverhalten aller Bestückautomaten einer SMD-Bestücklinie gegenüber dem übergeordneten Linienrechner nach und überprüft die empfangenen Datentelegramme auf Fehlerfreiheit. Durch HSSIM wird während der Testphase eine beträchtliche Kosteneinsparung erzielt, da die Kapitalbindungskosten für eine statt des Simulationssystems benötigte Bestücklinie sowie die Verbrauchskosten während der Tests entfallen. Durch die einfache Parametrierbarkeit des Systems kann die Zahl der Testfälle erhöht werden, was dazu führt, daß während der Testphase in kürzerer Zeit eine größere Anzahl Fehler entdeckt und behoben wird. Zum Speichern und Verwalten der zwischen Linienrechner und Bestückautomaten übertragenen Daten wurde das Programmpaket HSMON entwickelt, dessen Kern eine relationale Datenbank bildet. Mit den in der Datenbank gespeicherten Daten können während der Testphasen unterschiedliche Testläufe miteinander verglichen und Änderungen im Kommunikationsverhalten des Linienrechners gegenüber den Bestückautomaten ermittelt werden. Durch den Einsatz von Standardsoftware wurden verschiedene Möglichkeiten realisiert, die gespeicherten Daten zu visualisieren und somit einer optischen Plausibilitätskontrolle zu unterziehen. Diese Funktionalität ermöglicht vor allem während der Inbetriebnahme der Bestücklinien eine Überprüfung der übertragenen Daten. Neben fehlerfreier Steuerungssoftware erfordert die steigende Komplexität der Produktionsanlagen qualifiziertes und gut geschultes Personal um einen effizienten Betrieb mit hoher Auslastung zu ermöglichen. Die kurzen Innovationszyklen und der Zwang zu Kostenersparnis führen dazu, daß die Einarbeitung in die Bedienung der Anlagen in Zukunft möglichst ohne kostenintensive Kurse in Eigenverantwortung erfolgen muß. Zur Ausbildung bietet sich hier der Einsatz von Lernsoftware an, die sich auf einfache Art vervielfältigen und an die Kunden verteilen läßt. Die Motivierung der Lernenden durch die multimedialen Möglichkeiten der Lernsoftware führen in kurzer Zeit zu einem hohen Lernerfolg. Das Lernprogramm HSLERN bietet dem Anlagenbediener die Möglichkeit, sich das zum Betrieb einer SMD-Bestückanlage notwendige Wissen anzueignen und durch die enthaltenen Tests und Übungen zu festigen. Da der Lernerfolg entscheidend verbessert wird, wenn das Erlernte in geeigneter Form trainiert werden kann, wurde ein integriertes Gesamtsystem entwickelt, das neben der Lernkomponente HSLERN auch das Simulationssystem HSSIM und das Visualisierungssystem HSMON umfaßt. Nach dem Wissenserwerb kann der Bediener am Linienrechner die zur Bestückung von Leiterplatten notwendigen Dateneingaben sowie die Steuerung der Bestückautomaten üben. Das Simulationssystem HSSIM ersetzt dabei die reale Bestückanlage. Durch die Überprüfung und die Visualisierung der während der Bedienung eingegebenen Daten mit HSMON, die in Form der Datentelegramme vom Linienrechner an das Simulationssystem übergeben werden, wird der Lernende auf etwaige Eingabefehler hingewiesen.
In diesem Kapitel wird die methodische Vorgehensweise in der Individualentwicklung aufgezeigt. Es liegt also der Schwerpunkt auf den Methoden zur Analyse, Entwurf, Implementierung und Test von IS. Hierbei liegt der Schwerpunkt bei der objektorientierten Softwareentwicklung und den unterschiedlichen statischen und dynamischen Modellen, die UML anbietet.
Der kombinierte Black-Box- und Glass-Box-Test bietet Möglichkeiten, neue Testfälle zu finden, indem er unüberdeckte Codeblöcke aufzeigt. Jeder unüberdeckte Codeblock entspricht einem neuen potenziellen Testfall. Diese Liste von Testfallempfehlungen kann zur Verbesserung einer existierenden Systemtestsuite verwendet werden. Eine Hürde auf dem Weg zur Verbesserung einer existierenden Systemtestsuite ist die notwendige Wirtschaftlichkeit. Die Kosten der wahrscheinlich verhinderten Fehler müssen die Kosten der Testsuiteverbesserung übersteigen.
Um einem Tester die wirtschaftliche Abarbeitung der Testfallempfehlungen zu ermöglichen, sollten diese priorisiert werden. So soll erreicht werden, dass der Tester seine Zeit für die Erstellung von Testfällen mit hoher Wahrscheinlichkeit, einen Fehler zu finden, einsetzt.
In dieser Diplomarbeit wird ein Modell für die Priorisierung von Testfallempfehlungen vorgestellt. Das Modell basiert auf Heuristiken, die die Fehlerfindwahrscheinlichkeit und mögliche Fehlerschwere von Testfallempfehlungen bewerten. Die Heuristiken nehmen ihre Informationen dazu aus verschiedenen Quellen, unter anderem aus dem Quellcode und der Versionsgeschichte des Programms. Alle Heuristiken stammen dabei aus der bestehenden Literatur zu den Themen "risikobasierter Test"' und "Fehlerprognose"'. Das Priorisierungsmodell ist allerdings nicht starr auf eine Menge von Heuristiken ausgelegt, sondern kann durch zusätzliche Heuristiken erweitert werden.
Das Modell wurde als CodeCover-Erweiterung implementiert und fügt der Eclipse-Integration von CodeCover eine weitere Sicht hinzu. Mit Hilfe dieser CodeCover-Erweiterung können nach einem Testdurchlauf mit CodeCover Testfallempfehlungen generiert und mit Hilfe mehrerer Heuristiken priorisiert werden. Die Implementierung ist dabei als Framework für die Erprobung weiterer Heuristiken zur Priorisierung von Testfallempfehlungen geeignet.
Die Arbeit schließt mit einer Erprobung der CodeCover-Erweiterung bei einem Industriepartner.
Das auf Basis von Web-Anwendungen implementierte Benutzeroberflächen-Konzept ermöglicht die Realisierung von Konsistenzprüfungen, eine unkomplizierte Fehlerbehandlung bei Daten-Inkonsistenz und die schrittweise Integration der entwickelten Dokumentengesteuerten Projektabwicklung in die bisherige Arbeitsumgebung der Firma Innovations- Solutions AG (ISAG). Zusammen mit dem strukturierten und erweiterbaren Datenbankschema werden die Fehlermöglichkeiten verringert und der Fehlerentdeckungsaufwand sowie der Arbeitsaufwand zur Projektabwicklung reduziert. Das neu entwickelte kombinierte Konzept einer gesamtheitlichen Prozess-Steuerung der Projektabwicklung, die in einzelnen Projektabschnitten eine Dokumenten-Steuerung zulässt, basiert auf Bonita Open Solution und Apache Tomcat und bindet die als Web-Anwendungen implementierten Benutzeroberflächen ein. Die dafür definierten Softwaretests sind optimal auf die unterschiedlichen Eigenschaften der hier verwendeten Werkzeuge abgestimmt. Die pilothafte Implementierung der kombinierten Projektabwicklung zeigt neue Möglichkeiten zu strukturierter und effizienter Projektabwicklung in kleinen und mittleren Unternehmen.
Probably everyone has an idea about the meaning of quality. However, when it comes to quality in the real world, i.e. in conjunction with a software development project, disagreements between the persons involved often lead to further problems. Especially in the case of customer complaints about faults in a software product, it seems to be unclear not only what the requirements are, but also if the software has the „right“ characteristics with regard to these requirements. This article aims to reduce the confusion arisen about quality, requirement and characteristic.
Software can be tested in several ways: either according to the operational profile of the user, or by following a systematic testing approach. If the latter is chosen, then it becomes difficult to estimate the number of failures in the software, or its reliability. In this paper, we present a software reliability model, the Rivers-Vouk model, which specifically addresses the issues of systematic testing. Using an intuitive model framework its assumptions are compared to those of a model designed for operational testing. The Rivers-Vouk model has been applied to a test project at imbus AG and the results of the failure prediction are discussed. In the conclusion the PETS project is briefly reviewed whose aim it is to incorporate data on the software process maturity into software reliability models.
Mit dem ständig zunehmenden Einsatz von Rechnersystemen in sicherheitsrelevanten technischen Bereichen werden auch an die Software die gleichen hohen Zuverlässigkeits- und Sicherheitsanforderungen wie an konventionelle, Hardware-implementierte sicherheitsrelevante Systeme gestellt. Damit steigen die Anforderungen an die Qualität der Software und ihren Entwicklungsprozeß. Eine bedeutende Rolle bei der Entwicklung und Zulassung sicherheitsrelevanter Software kommt der Verifikation und Validation zu, wobei der systematische Test unverzichtbarer Bestandteil dieser Software-Prüfung ist. Da die existierenden Standards und Richtlinien zur Qualitätssicherung und Zulassung, insbesondere zur Prüfung sicherheitsrelevanter Software zwar systematische Tests, in der Regel aber keine konkreten Methoden und Verfahren vorschreiben, wird im vorliegenden Beitrag eine umfangreiche Untersuchung des State-of-the-Art auf dem Gebiet der Testmethoden und -verfahren einerseits und der Automatisierung des Tests andererseits vorgestellt. Ziel dieser Untersuchung ist, auf der Basis einer leistungs- und aufwandsorientierten Bewertung der verschiedenen Ansätze die Auswahl der im konkreten Anwendungsfall geeignetsten Methoden, Verfahren und Werkzeuge zu unterstützen.
Nach einer kurzen Einführung in die Situation bei der Standardisierung der Entwicklung, Prüfung und Zulassung sicherheitsrelevanter Software und Hinweisen auf entsprechende Richtlinien wird die große Bedeutung des systematischen Tests im Rahmen von Prüfung und Zulassung hervorgehoben.
Anschließend werden alle wichtigen Methoden und Verfahren zum Testen von Software klassifiziert und beschrieben, wobei drei verschiedene Klassifizierungskriterien und -schemata vorgestellt und angewendet werden. Nach einer vergleichenden Bewertung dieser Verfahren wird der Stand der Technik auf dem Gebiet der Automatisierung des Tests beschrieben. Zu jedem Testverfahren und zu jedem Automatisierungsansatz werden ausführliche Hinweise auf weiterführende Literatur gegeben.
Aus einer zusammenfassenden Beurteilung des Stands der Wissenschaft und Technik und den Erkenntnissen über eine effektive, Sicherheits- und hohen Zuverlässigkeitsanforderungen Rechnung tragende Teststrategie werden Anforderungen an neue, leistungsfähigere Testverfahren aufgestellt.
Ein gesondertes Kapitel ist den speziellen Problemen beim Test von parallelen, verteilten und Realzeit-Systemen gewidmet. Die existierenden Probleme und die wenigen auf diesem Gebiet bereits existierenden Lösungsansätze werden kurz zusammengefaßt.
Das Papier schließt mit einem kurzen Resümee und einem Ausblick auf die Arbeiten, die in Zukunft auf dem Gebiet des systematischen Testens von Software weiterhin Gegenstand der Forschung sein müssen.
Mit steigender Komplexität werden bei der Inbetriebnahme verteilter und vernetzter Automatisierungssysteme zahlreiche Störungen, Laufzeitfehler und Echtzeitprobleme sichtbar. Viele Fehler treten nur sporadisch auf - meist auch noch zu einer Zeit, wenn qualifiziertes Wartungspersonal nicht anwesend ist. Besonders in der Inbetriebnahmephase neuer Anlagen häufen sich solche transienten Fehler. Nur selten hat das Ingenieurpersonal die Chance, diese kurzzeitigen Störungen im Zusammenwirken von Technik, Benutzer und Umwelt umfassend zu beobachten und diagnostisch auszuwerten. Im Fehlerfalle geht außerdem alles sehr schnell und ist mit bloßem Auge am Meßgerät nicht mehr zu verfolgen.
Ein sicherheitskritisches verteiltes Realzeitsystem ist ein elektronisches System, in dem ein Systemausfall eine ernsthafte Gefahr verursachen kann, die menschliches Leben oder die Umgebung gefährdet. Für die Entwicklung solcher Systeme ist es wünschenswert in einer frühen Entwicklungsphase zu beurteilen, ob das System solch ein gefährliches Ereignis verursachen kann, bevor die Hardware des Systems aufgebaut wird und bevor das System in Betrieb genommen wird. Diese Arbeit schlägt Methoden und Techniken vor, um das Verhalten solcher Systeme mit einem Simulationsmodell in einer frühen Entwicklungsphase zu validieren. Das Simulationsmodell repräsentiert die Systemarchitektur (Hardware und Software) des Systems, wie sie in der Designspezifikation spezifiziert ist. Das Systemmodell basiert auf einer strikten Unterscheidung zwischen der Anwendersoftware, die die gewünschte Funktionalität des Systems darstellt, und der Hardware- und Softwareplattform, die die Anwendersoftware ausführt. Diese strikte Trennung ermöglicht Einblicke in die komplexen Abhängigkeiten zwischen Hardware- und Softwarebausteinen des Systems. Der Ansatz erlaubt es eine fehlertolerante Systemarchitektur während eines Fehlers zu bewerten, der durch einen fehlerhaften Hardwarebaustein oder Störungen verursacht wurde. Das in dieser Arbeit vorgeschlagene Prinzip der Validierung ist wie folgt: eine Stimuli regt das Systemmodell mit realistischen und sicherheitsrelevanten Testszenarien an. Ein Beobachtersystem überwacht die Signale, die vom System erzeugt werden und beurteilt ob das System eine der vordefinierten Bedingungen verletzt. Die Bedingungen stellen Sicherheitsauflagen dar, die das System erfüllen muß, um in seiner Umgebung sicher zu funktionieren. Ein wesentliches Teil der Validierung ist die Fehlerinjektion. Diese Technik löst Fehler während des Testszenarios aus, die im realen System durch fehlerhafte Hardwarebausteine oder Störungen verursacht werden. Das Beobachtersystem bewertet die Reaktion des Systems während diesen Fehlerzuständen und hält in einem Dokument fest, ob das System eine der vordefinierten Bedingungen verletzt hat. Die Fallstudie wendet den Ansatz an einem Brake-by-Wire (BbW) Systems eines Kraftfahrzeuges an. Die Fallstudie zeigt, wie die vorgeschlagenen Techniken und Methoden die Entwicklung eines elektronischen Systems in einer frühen Entwicklungsphase unterstützen können. Die Testszenarien decken auf, daß die Sicherheitsauflagen nicht erfüllt werden, falls das BbW System nach der untersuchten Designspezifikation realisiert wird.
München, Techn. Univ., Diss., 2005.
Software companies have to face serious problems about how to measure the progress of test activities and quality of software products in order to estimate test completion criteria, and if the shipment milestone will be reached on time. Measurement is a key activity in testing life cycle and requires established, managed and well documented test process, defined software quality attributes, quantitative measures, and using of test management and bug tracking tools. Test metrics are a subset of software metrics (product metrics, process metrics) and enable the measurement and quality improvement of test process and/or software product. The goal of this paper is to briefly present Fabasoft best practices and lessons learned during functional and system testing of big complex software products, and to describe a simple test metrics model applied to the software test process with the purpose to better control software projects, measure and increase software quality.
Software companies have to face serious problems about how to measure the progress of test activities and quality of software products in order to estimate test completion criteria, and if the shipment milestone will be reached on time. Measurement is a key activity in testing life cycle and requires established, managed and well documented test process, defined software quality attributes, quantitative measures, and using of test management and bug tracking tools. Test metrics are a subset of software metrics (product metrics, process metrics) and enable the measurement and quality improvement of test process and/or software product. The goal of this paper is to briefly present Fabasoft best practices and lessons learned during functional and system testing of big complex software products, and to describe a simple test metrics model applied to the software test process with the purpose to better control software projects, measure and increase software quality.
ResearchGate has not been able to resolve any references for this publication.