Softwareprüfung ist eine Untersuchung, die geführt ist, um Miteigentümer mit der Information über die Qualität des Produktes oder Dienstes unter dem Test zu versorgen. Softwareprüfung kann auch eine objektive, unabhängige Ansicht von der Software zur Verfügung stellen, dem Geschäft zu erlauben, die Gefahren der Softwaredurchführung zu schätzen und zu verstehen. Testtechniken schließen ein, aber werden auf, der Prozess nicht beschränkt, ein Programm oder Anwendung mit der Absicht durchzuführen, Softwareprogrammfehler (Fehler oder andere Defekte) zu finden.

Softwareprüfung kann als der Prozess der Bestätigung festgesetzt werden und dass ein Softwareprogramm/Anwendung/Produkt nachprüfend:

1. entspricht den Anforderungen, die sein Design und Entwicklung geführt haben;
2. Arbeiten, wie erwartet; und
3. kann mit denselben Eigenschaften durchgeführt werden.

Softwareprüfung, abhängig von der verwendeten Probemethode, kann jederzeit im Entwicklungsprozess durchgeführt werden. Jedoch kommt der grösste Teil der Testanstrengung traditionell vor, nachdem die Voraussetzungen definiert worden sind und der Codierprozess vollendet worden ist, dieses Bestechen eines Programmfehlers gezeigt, ist wenn gefunden, früher im Entwicklungsprozess weniger teuer. Obwohl in den Flinken Annäherungen der grösste Teil der Testanstrengung, umgekehrt, andauernd ist. Als solcher wird die Methodik des Tests durch die angenommene Softwareentwicklungsmethodik geregelt.

Verschiedene Softwareentwicklungsmodelle werden die Testanstrengung an verschiedenen Punkten im Entwicklungsprozess einstellen. Neuere Entwicklungsmodelle, solcher als Flink, verwenden häufig Test gesteuerte Entwicklung und legen einen vergrößerten Teil der Prüfung in den Händen des Entwicklers, bevor es eine formelle Mannschaft von Prüfern erreicht. In einem traditionelleren Modell kommt der grösste Teil der Testausführung vor, nachdem die Voraussetzungen definiert worden sind und der Codierprozess vollendet worden ist.

Übersicht

Prüfung kann alle Defekte innerhalb der Software nie völlig identifizieren. Statt dessen stattet es eine Kritik oder Vergleich aus, der den Staat und das Verhalten des Produktes gegen Orakel — Grundsätze oder Mechanismen vergleicht, durch die jemand ein Problem anerkennen könnte. Diese Orakel können einschließen (aber werden auf nicht beschränkt) Spezifizierungen, Verträge, vergleichbare Produkte, vorige Versionen desselben Produktes, Schlussfolgerungen über beabsichtigten oder erwarteten Zweck, Benutzer oder Kundenerwartungen, relevante Standards, anwendbare Gesetze oder andere Kriterien.

Jedes Softwareprodukt hat ein Zielpublikum. Zum Beispiel ist das Publikum für die Videospiel-Software von der Bankverkehrssoftware völlig verschieden. Deshalb, wenn sich eine Organisation entwickelt oder sonst in ein Softwareprodukt investiert, kann sie bewerten, ob das Softwareprodukt für seine Endbenutzer, sein Zielpublikum, seine Käufer und andere Miteigentümer annehmbar sein wird. Softwareprüfung ist der Prozess des Versuchens, diese Bewertung zu machen.

Eine Studie, die durch NIST 2002 geführt ist, berichtet, dass Softwareprogrammfehler die amerikanische Wirtschaft $ 59.5 Milliarden jährlich kosten. Mehr als ein Drittel dieser Kosten konnte vermieden werden, wenn bessere Softwareprüfung durchgeführt wurde.

Geschichte

Die Trennung des Beseitigens von der Prüfung wurde von Glenford J. Myers 1979 am Anfang eingeführt. Obwohl seine Aufmerksamkeit auf der Brechungsprüfung war ("ein erfolgreicher Test, ist derjenige, der einen Programmfehler" findet), hat es den Wunsch der Softwaretechnikgemeinschaft illustriert, grundsätzliche Entwicklungstätigkeiten wie das Beseitigen von dieser der Überprüfung zu trennen. Dave Gelperin und William C. Hetzel klassifiziert 1988 die Phasen und Absichten in der Softwareprüfung in den folgenden Stufen:

• Bis 1956 - das Beseitigen bei orientiertem
• 1957-1978 - Demonstration hat orientiert
• 1979-1982 - Zerstörung hat orientiert
• 1983-1987 - Einschätzung hat orientiert
• 1988-2000 - Verhinderung hat orientiert

Softwareprobethemen

Spielraum

Ein primärer Zweck zu prüfen ist, Softwaremisserfolge zu entdecken, so dass Defekte entdeckt und korrigiert werden können. Prüfung kann nicht feststellen, dass ein Produkt richtig unter allen Bedingungen fungiert, aber nur feststellen kann, dass es richtig unter spezifischen Bedingungen nicht fungiert. Das Spielraum der Software, die häufig prüft, schließt Überprüfung des Codes sowie Ausführung dieses Codes in verschiedenen Umgebungen und Bedingungen sowie dem Überprüfen der Aspekte des Codes ein: Tut es tut, was es tun und tun soll, was es tun muss. In der aktuellen Kultur der Softwareentwicklung kann eine Probeorganisation von der Entwicklungsmannschaft getrennt sein. Es gibt verschiedene Rollen, um Gruppenmitglieder zu prüfen. Information ist auf Softwareprüfung zurückzuführen gewesen kann verwendet werden, um den Prozess zu korrigieren, durch den Software entwickelt wird.

Funktionell gegen die nichtfunktionelle Prüfung

Funktionelle Prüfung bezieht sich auf Tätigkeiten, die eine spezifische Handlung oder Funktion des Codes nachprüfen. Diese werden gewöhnlich in der Codevoraussetzungsdokumentation gefunden, obwohl einige Entwicklungsmethodiken von Gebrauch-Fällen oder Benutzergeschichten arbeiten. Funktionsprüfungen neigen dazu zu antworten, dass die Frage "der Benutzer kann tun, tut das" oder "diese besondere Eigenschaft-Arbeit."

Nichtfunktionelle Prüfung bezieht sich auf Aspekte der Software, die mit einer Sonderaufgabe oder Benutzerhandlung, wie Skalierbarkeit oder andere Leistung, Verhalten unter bestimmten Einschränkungen oder Sicherheit nicht verbunden sein kann. Prüfung wird den Flocke-Punkt, den Punkt bestimmen, an denen Extremen der Skalierbarkeit oder Leistung zu nicht stabiler Ausführung führt. Nichtfunktionelle Voraussetzungen neigen dazu, diejenigen zu sein, die die Qualität des Produktes besonders im Zusammenhang der Eignungsperspektive seiner Benutzer widerspiegeln.

Defekte und Misserfolge

Nicht alle Softwaredefekte werden durch das Codieren von Fehlern verursacht. Eine allgemeine Quelle von teuren Defekten wird durch Voraussetzungslücken, z.B, unerkannte Voraussetzungen verursacht, die auf Fehler der Weglassung durch den Programm-Entwerfer hinauslaufen. Eine allgemeine Quelle von Voraussetzungslücken ist nichtfunktionelle Voraussetzungen wie Testbarkeit, Skalierbarkeit, Haltbarkeit, Brauchbarkeit, Leistung und Sicherheit.

Softwareschulden kommen durch die folgenden Prozesse vor. Ein Programmierer macht einen Fehler (Fehler), der auf einen Defekt (Schuld, Programmfehler) im Softwarequellcode hinausläuft. Wenn dieser Defekt in bestimmten Situationen durchgeführt wird, wird das System falsche Ergebnisse erzeugen, einen Misserfolg verursachend. Nicht alle Defekte werden auf Misserfolge notwendigerweise hinauslaufen. Zum Beispiel werden Defekte im toten Code auf Misserfolge nie hinauslaufen. Ein Defekt kann sich in einen Misserfolg verwandeln, wenn die Umgebung geändert wird. Beispiele dieser Änderungen in der Umgebung schließen die Software ein, die auf einer neuen Computerhardware-Plattform, Modifizierungen in Quelldaten wird führt oder mit verschiedener Software aufeinander wirkt. Ein einzelner Defekt kann auf eine breite Reihe von Misserfolg-Symptomen hinauslaufen.

Entdeckung von Schulden früh

Es wird allgemein geglaubt, dass früher ein Defekt das preiswertere gefunden wird, soll er es befestigen. Der folgende Tisch zeigt die Kosten, den Defekt abhängig von der Bühne zu befestigen, die es gefunden wurde. Zum Beispiel, wenn ein Problem in den Voraussetzungen nur Postausgabe gefunden wird, dann würde es 10-100mal mehr kosten, um zu befestigen, als wenn es bereits durch die Voraussetzungsrezension gefunden worden war. Moderne dauernde Aufstellungsmethoden und wolkenbasierte Dienstleistungen können weniger für die Umgruppierung und Wartung kosten als in der Vergangenheit.

Vereinbarkeitsprüfung

Ein häufiger Grund des Softwaremisserfolgs (echt oder wahrgenommen) ist ein Mangel an seiner Vereinbarkeit mit anderer Anwendungssoftware, Betriebssysteme (oder Betriebssystemversionen, alt oder neu), oder Zielumgebungen, die sich außerordentlich vom Original unterscheiden (wie ein Terminal oder GUI Anwendung hat vorgehabt, auf der Arbeitsfläche geführt zu werden, die jetzt erforderliche, eine Webanwendung zu werden, die in einem WWW-Browser machen muss). Zum Beispiel, im Fall von einem Mangel an der rückwärts gerichteten Vereinbarkeit, kann das vorkommen, weil die Programmierer entwickeln und Software nur auf der letzten Version der Zielumgebung prüfen, die nicht alle Benutzer führen können. Das läuft auf die unbeabsichtigte Folge hinaus, dass die letzte Arbeit auf früheren Versionen der Zielumgebung, oder auf der älteren Hardware nicht fungieren kann, dass frühere Versionen der Zielumgebung zum Verwenden fähig waren. Manchmal können solche Probleme durch das proaktive Entziehen der Betriebssystemfunktionalität in ein getrenntes Programm-Modul oder Bibliothek befestigt werden.

Eingangskombinationen und Vorbedingungen

Ein sehr grundsätzliches Problem mit der Softwareprüfung besteht darin, dass die Prüfung unter allen Kombinationen von Eingängen und Vorbedingungen (anfänglicher Staat) sogar mit einem einfachen Produkt nicht ausführbar ist. Das bedeutet, dass die Zahl von Defekten in einem Softwareprodukt sehr groß sein kann und Defekte, die vorkommen, selten sind schwierig, in der Prüfung zu finden. Bedeutsamer können nichtfunktionelle Dimensionen der Qualität (wie es dagegen sein soll, was es tun soll) — Brauchbarkeit, Skalierbarkeit, Leistung, Vereinbarkeit, Zuverlässigkeit - hoch subjektiv sein; etwas, was genügend Wert einer Person einsetzt, kann zu einem anderen untragbar sein.

Statisch gegen die dynamische Prüfung

Es gibt viele Annäherungen an die Softwareprüfung. Rezensionen, walkthroughs, oder Inspektionen werden als statische Prüfung betrachtet, wohingegen wirklich die Durchführung des programmierten Codes mit einem gegebenen Satz von Testfällen dynamische Prüfung genannt wird. Statische Prüfung kann sein (und ist leider in der Praxis häufig) weggelassen. Dynamische Prüfung findet statt, wenn das Programm selbst zum ersten Mal verwendet wird (der allgemein als der Anfang der Probebühne betrachtet wird). Dynamische Prüfung kann beginnen, bevor das Programm um 100 % abgeschlossen ist, um besondere Abteilungen des Codes (Module oder getrennte Funktionen) zu prüfen. Typische Techniken dafür verwenden entweder Stummel/Fahrer oder Ausführung von einer Testhilfeprogramm-Umgebung. Zum Beispiel sind Spreadsheet-Programme, durch ihre wirkliche Natur, geprüft weit gehend interaktiv ("im Fluge"), mit Ergebnissen gezeigt sofort nach jeder Berechnung oder Textmanipulation.

Softwareüberprüfung und Gültigkeitserklärung

Softwareprüfung wird in Verbindung mit der Überprüfung und Gültigkeitserklärung verwendet:

• Überprüfung: Haben wir das Softwarerecht gebaut? (d. h., tut es vergleicht die Spezifizierung).
• Gültigkeitserklärung: Haben wir die richtige Software gebaut? (d. h., ist das, was der Kunde will).

Die Begriffe Überprüfung und Gültigkeitserklärung werden austauschbar in der Industrie allgemein gebraucht; es ist auch üblich, diese zwei falsch definierten Begriffe zu sehen. Gemäß dem IEEE Standardwörterverzeichnis der Softwaretechnikfachsprache:

: Überprüfung ist der Prozess, ein System oder Bestandteil zu bewerten, um zu bestimmen, ob die Produkte einer gegebenen Entwicklungsphase die am Anfang dieser Phase auferlegten Bedingungen befriedigen.

: Gültigkeitserklärung ist der Prozess, ein System oder Bestandteil während oder am Ende des Entwicklungsprozesses zu bewerten, um zu bestimmen, ob es angegebene Voraussetzungen befriedigt.

Gemäß dem IS0 9000 Standard:

: Überprüfung ist Bestätigung durch die Überprüfung und durch die Bestimmung von objektiven Beweisen, die angegeben haben, dass Forderungen erfüllt worden sind.

: Gültigkeitserklärung ist Bestätigung durch die Überprüfung und durch die Bestimmung von objektiven Beweisen, dass die Forderungen für einen spezifischen beabsichtigten Gebrauch oder Anwendung erfüllt worden sind.

Die Softwareprobemannschaft

Softwareprüfung kann von Softwareprüfern getan werden. Bis zu den 1980er Jahren wurde der Begriff "Software-Prüfer" allgemein gebraucht, aber später wurde es auch als ein getrennter Beruf gesehen. Bezüglich der Perioden und der verschiedenen Absichten in der Softwareprüfung sind verschiedene Rollen gegründet worden: Betriebsleiter, Testleitung, prüft Entwerfer, Prüfer, Automationsentwickler, und prüft Verwalter.

Softwarequalitätssicherung (SQA)

Obwohl umstritten, ist Softwareprüfung ein Teil des Prozesses der Softwarequalitätssicherung (SQA). In SQA sind Softwareprozess-Fachmänner und Rechnungsprüfer um den Softwareentwicklungsprozess aber nicht gerade die Kunsterzeugnisse wie Dokumentation, Code und Systeme besorgt. Sie untersuchen und ändern den Softwaretechnikprozess selbst, um die Anzahl von Schulden zu vermindern, die in der gelieferten Software enden: die so genannte Defekt-Rate.

Was eine "annehmbare Defekt-Rate" einsetzt, hängt von der Natur der Software ab; ein Flugsimulator-Videospiel würde viel höhere Defekt-Toleranz haben als Software für ein wirkliches Flugzeug.

Obwohl es nahe Verbindungen mit SQA gibt, bestehen prüfende Abteilungen häufig unabhängig, und es kann keine SQA-Funktion in einigen Gesellschaften geben.

Softwareprüfung ist eine Aufgabe, die beabsichtigt ist, um Defekte in der Software durch das Kontrastieren einem Computer die erwarteten Ergebnisse des Programms mit seinen wirklichen Ergebnissen für einen gegebenen Satz von Eingängen zu entdecken. Im Vergleich ist QA (Qualitätssicherung) die Durchführung von Policen, und Verfahren haben vorgehabt, Defekte davon abzuhalten, an erster Stelle vorzukommen.

Prüfung von Methoden

Die Kasten-Annäherung

Softwareprobemethoden werden ins Weiß - und Prüfung des schwarzen Kastens traditionell geteilt. Diese zwei Annäherungen werden verwendet, um den Gesichtspunkt zu beschreiben, dass ein Testingenieur nimmt, wenn er Testfälle entwirft.

Prüfung des weißen Kastens

Prüfung des weißen Kastens besteht darin, wenn der Prüfer Zugang zu den inneren Datenstrukturen und Algorithmen einschließlich des Codes hat, der diese durchführt.

Typen des weißen Kastens, der prüft

:The im Anschluss an Typen der Prüfung des weißen Kastens bestehen:

:* API-Prüfung (Anwendung, Schnittstelle programmierend) - Prüfung des Anwendungsverwendens öffentlicher und privater APIs

:* Codeeinschluss - schaffende Tests, um einige Kriterien des Codeeinschlusses (z.B zu befriedigen, kann der Testentwerfer Tests schaffen, um alle Behauptungen im Programm zu veranlassen, mindestens einmal durchgeführt zu werden)

,

:* Schuld-Spritzenmethoden - Besserung des Einschlusses eines Tests durch das Einführen von Schulden, um Codepfade zu prüfen

:* Veränderungsprobemethoden

:* Statische Prüfung - Alle Typen

Testeinschluss

:White-Kasten-Probemethoden können auch verwendet werden, um die Vollständigkeit eines Testgefolges zu bewerten, das mit Probemethoden des schwarzen Kastens geschaffen wurde. Das erlaubt der Softwaremannschaft, Teile eines Systems zu untersuchen, die selten geprüft werden und sicherstellt, dass die wichtigsten Funktionspunkte geprüft worden sind.

:Two-Standardformen des Codeeinschlusses sind:

:* Funktionseinschluss, der über Funktionen berichtet, hat durchgeführt

:* Behauptungseinschluss, der auf der Zahl von Linien meldet, die durchgeführt sind, den Test zu vollenden

Sie beide geben einen Codeeinschluss metrisch, gemessen als ein Prozentsatz zurück.

Prüfung des schwarzen Kastens

Prüfung des schwarzen Kastens behandelt die Software als ein "schwarzer Kasten" - ohne irgendwelche Kenntnisse der inneren Durchführung. Probemethoden des schwarzen Kastens schließen ein: Das Gleichwertigkeitsverteilen, Grenze schätzt Analyse, Vollpaare, die, Fusseln-Prüfung, musterbasierte Prüfung, Forschungsprüfung und Spezifizierungsbasierte Prüfung prüfen.

Mit Sitz in:Specification Prüfung: Spezifizierungsbasierte Prüfung hat zum Ziel, die Funktionalität der Software gemäß den anwendbaren Voraussetzungen zu prüfen. So gibt der Prüfer Daten darin ein, und sieht nur die Produktion von, der Testgegenstand. Dieses Niveau der Prüfung verlangt gewöhnlich, dass gründliche Testfälle dem Prüfer zur Verfügung gestellt werden, der einfach dann nachprüfen kann, dass für einen eingegebenen gegebenen der Produktionswert (oder Verhalten), entweder "ist" oder, "ist nicht" dasselbe als der erwartete im Testfall angegebene Wert.

Mit Sitz in:Specification Prüfung ist notwendig, aber es ist ungenügend, um vor bestimmten Gefahren zu schützen.

:Advantages und Nachteile: Der Prüfer des schwarzen Kastens hat keine "Obligationen" mit dem Code, und eine Wahrnehmung eines Prüfers ist sehr einfach: Ein Code muss Programmfehler haben. Mit dem Grundsatz, "Fragen und sollen Sie erhalten," finden Prüfer des schwarzen Kastens Wanzen, wo Programmierer nicht tun. Andererseits, wie man gesagt hat, ist Prüfung des schwarzen Kastens "wie ein Spaziergang in einem dunklen Irrgarten ohne ein Leuchtfeuer gewesen," weil der Prüfer nicht weiß, wie die Software, die wird prüft, wirklich gebaut wurde. Infolgedessen gibt es Situationen, wenn (1) ein Prüfer viele Testfälle schreibt, um etwas zu überprüfen, was durch nur einen Testfall, und/oder (2) geprüft worden sein könnte, werden einige Teile des Zurückendes überhaupt nicht geprüft.

Deshalb ist Prüfung des schwarzen Kastens im Vorteil "einer unangeschlossenen Meinung", einerseits, und der Nachteil des "Rollladen-Erforschens", auf dem anderen.

Prüfung des grauen Kastens

Prüfung des grauen Kastens (amerikanische Rechtschreibung: Prüfung des grauen Kastens) schließt habende Kenntnisse von inneren Datenstrukturen und Algorithmen zum Zwecke des Entwerfens von Tests ein, während man jene Tests am Benutzer oder Niveau des schwarzen Kastens durchführt. Der Prüfer ist nicht erforderlich, vollen Zugang zum Quellcode der Software zu haben. Die Manipulierung von Eingangsdaten und die Formatierung der Produktion qualifizieren sich als grauer Kasten nicht, weil der Eingang und die Produktion klar außerhalb des "schwarzen Kastens" sind, dass wir das System unter dem Test nennen. Diese Unterscheidung ist besonders wichtig, wenn sie Integrationsprüfung zwischen zwei Modulen des von zwei verschiedenen Entwicklern geschriebenen Codes führt, wo nur die Schnittstellen für den Test ausgestellt werden. Jedoch qualifiziert sich das Ändern eines Datenbehältnisses wirklich als grauer Kasten, weil der Benutzer nicht normalerweise im Stande sein würde, die Daten außerhalb des Systems unter dem Test zu ändern. Prüfung des grauen Kastens kann auch Rücktechnik einschließen, um, zum Beispiel, Grenzwerte oder Fehlermeldungen zu bestimmen.

Indem

er die zu Grunde liegenden Konzepte dessen weiß, wie die Software arbeitet, macht der Prüfer besser informierte Probewahlen, während er die Software von der Außenseite prüft. Gewöhnlich wird einem Prüfer des grauen Kastens erlaubt, seine Probeumgebung aufzustellen; zum Beispiel, Säen eine Datenbank; und der Prüfer kann den Staat des Produktes beobachten, das nach dem Durchführen bestimmter Handlungen wird prüft. Zum Beispiel in der Prüfung eines Datenbankproduktes kann er/sie eine SQL-Abfrage auf der Datenbank anzünden und dann die Datenbank beobachten, um sicherzustellen, dass die erwarteten Änderungen widerspiegelt worden sind. Prüfung des grauen Kastens führt intelligente Testdrehbücher durch, die auf der beschränkten Information gestützt sind. Das wird besonders für das Datentyp-Berühren, Ausnahme-Berühren und so weiter gelten.

Sehprüfung

Das Ziel der Sehprüfung ist, Entwickler mit der Fähigkeit zu versorgen, zu untersuchen, was am Punkt des Softwaremisserfolgs durch das Präsentieren der Daten auf solche Art und Weise geschah, dass der Entwickler leicht nd die Information kann, die er verlangt, und die Information klar ausgedrückt wird.

Am Kern der Sehprüfung ist die Idee, dass, sich jemandem zeigend ein Problem (oder ein Testmisserfolg), anstatt es gerade zu beschreiben, außerordentlich Klarheit und das Verstehen vergrößert. Sehprüfung verlangt deshalb die Aufnahme des kompletten Testprozesses - das Gefangennehmen von allem, was auf dem Testsystem im Videoformat vorkommt. Produktionsvideos werden durch den Echtzeitprüfer-Eingang über das Bild in einer Bildernetzkamera und den Audiokommentar von Mikrofonen ergänzt.

Sehprüfung stellt mehrere Vorteile zur Verfügung. Die Qualität der Kommunikation wird drastisch vergrößert, weil Prüfer das Problem (und die Ereignisse zeigen können, die bis dazu führen) dem Entwickler im Vergleich mit gerade dem Beschreiben davon, und das Bedürfnis, Testmisserfolge zu wiederholen, aufhören wird, in vielen Fällen zu bestehen. Der Entwickler wird alle Beweise haben, die er eines Testmisserfolgs verlangt und sich stattdessen auf die Ursache der Schuld konzentrieren kann, und wie es befestigt werden sollte.

Sehprüfung ist für Umgebungen besonders gut passend, die flinke Methoden in ihrer Entwicklung der Software einsetzen, da flinke Methoden größere Kommunikation zwischen Prüfern und Entwicklern und Kollaboration innerhalb von kleinen Mannschaften verlangen.

Ad hoc sind die Prüfung und die Forschungsprüfung wichtige Methodiken, um Softwareintegrität zu überprüfen, weil sie verlangen, dass weniger Vorbereitungszeit durchführt, während wichtige Programmfehler schnell gefunden werden können. In der Ad-Hoc-Prüfung, wo Prüfung auf eine improvisierte, improvisierte Weise stattfindet, die Fähigkeit eines Testwerkzeugs visuell zu registrieren wird alles, was auf einem System vorkommt, sehr wichtig.

Sehprüfung sammelt Anerkennung in der Kundenannahme und Brauchbarkeitsprüfung, weil der Test von vielen am Entwicklungsprozess beteiligten Personen verwendet werden kann. Für den Kunden wird es leicht, ausführlich berichtete Programmfehler-Berichte und Feed-Back, und für Programm-Benutzer zur Verfügung zu stellen, Sehprüfung kann Benutzerhandlungen auf dem Schirm, sowie ihre Stimme und Image registrieren, um ein ganzes Bild zur Zeit des Softwaremisserfolgs für den Entwickler zur Verfügung zu stellen.

Prüfung von Niveaus

Tests werden oft dadurch gruppiert, wo sie im Softwareentwicklungsprozess, oder durch das Niveau der Genauigkeit des Tests hinzugefügt werden.

Die Hauptniveaus während des Entwicklungsprozesses, wie definiert, durch den SWEBOK-Führer sind Einheit - Integration - und System, das prüft, die durch das Testziel bemerkenswert sind, ohne ein spezifisches Prozessmodell einzubeziehen. Andere Testniveaus werden durch das Probeziel klassifiziert.

Testziel

Einheitsprüfung

Einheitsprüfung, auch bekannt als Teilprüfung, beziehen sich auf Tests, die die Funktionalität einer spezifischen Abteilung des Codes gewöhnlich am Funktionsniveau nachprüfen. In einer objektorientierten Umgebung ist das gewöhnlich am Klassenniveau, und die minimalen Einheitstests schließen die Konstrukteure und destructors ein.

Diese Typen von Tests werden gewöhnlich von Entwicklern geschrieben, weil sie am Code (Stil des weißen Kastens) arbeiten, um sicherzustellen, dass die Sonderaufgabe, wie erwartet, arbeitet. Eine Funktion könnte vielfache Tests haben, um Eckfälle oder andere Zweige im Code zu fangen. Einheitsprüfung allein kann die Funktionalität eines Stückes der Software nicht nachprüfen, aber wird eher verwendet, um zu versichern, dass die Bausteine die Software Arbeit unabhängig von einander verwenden.

Integrationsprüfung

Integrationsprüfung ist jeder Typ der Software, die prüft, der sich bemüht, die Schnittstellen zwischen Bestandteilen gegen ein Softwaredesign nachzuprüfen. Softwarebestandteile können auf eine wiederholende Weise oder alle zusammen ("Urknall") integriert werden. Normalerweise wird der erstere als eine bessere Praxis betrachtet, da sie Schnittstelle-Problemen erlaubt, schneller lokalisiert und befestigt zu werden.

Integrationsprüfung arbeitet, um Defekte in den Schnittstellen und der Wechselwirkung zwischen einheitlichen Bestandteilen (Module) auszustellen. Progressiv größere Gruppen von geprüften Softwarebestandteilen entsprechend Elementen der architektonischen Planung werden integriert und bis zu den Softwarearbeiten als ein System geprüft.

Systemprüfung

Systemprüfung prüft ein völlig einheitliches System, um nachzuprüfen, dass sie seinen Anforderungen entspricht.

Systemintegrationsprüfung

Systemintegrationsprüfung prüft nach, dass ein System zu irgendwelchen Außen- oder in den Systemanforderungen definierten Drittsystemen integriert wird.

Ziele der Prüfung

Prüfung des rückwärts Gehens

Prüfung des rückwärts Gehens konzentriert sich darauf, Defekte zu finden, nachdem eine Hauptcodeänderung vorgekommen ist. Spezifisch bemüht es sich, Softwarerückwärts Gehen oder alte Programmfehler aufzudecken, die zurückgekommen sind. Solches rückwärts Gehen kommt vor, wann auch immer Softwarefunktionalität, die vorher richtig Halt arbeitete, der, wie beabsichtigt, arbeitet. Gewöhnlich kommt rückwärts Gehen vor, als sich eine unbeabsichtigte Folge des Programms ändert, wenn der kürzlich entwickelte Teil der Software mit dem vorher vorhandenen Code kollidiert. Die übliche Methodik der Prüfung des rückwärts Gehens schließt das Wiederholen von vorher durchgeführten Tests und die Überprüfung ein, ob vorher feste Schulden wiedererschienen sind. Die Tiefe der Prüfung hängt von der Phase im Ausgabe-Prozess und der Gefahr der Komfortmerkmale ab. Sie können entweder, für Änderungen hinzugefügt spät in der Ausgabe oder gehalten abgeschlossen sein, zum sehr seichten unsicher zu sein, aus positiven Tests auf jeder Eigenschaft bestehend, wenn die Änderungen in der Ausgabe früh oder gehalten sind, um der niedrigen Gefahr zu sein.

Annahmeprüfung

Annahmeprüfung kann eines von zwei Dingen bedeuten:

1. Ein Rauch-Test wird als eine Abnahmeprüfung vor dem Einführen eines neuen verwendet bauen zum Hauptprobeprozess, d. h. vor der Integration oder dem rückwärts Gehen.
2. Annahmeprüfung, die vom Kunden häufig in ihrer Laboratorium-Umgebung auf ihrer eigenen Hardware durchgeführt ist, ist als Benutzerakzeptanz-Prüfung (UAT) bekannt. Annahmeprüfung kann als ein Teil der Hand - vom Prozess zwischen irgendwelchen zwei Phasen der Entwicklung durchgeführt werden.

Alpha-Prüfung

Alpha-Prüfung wird vorgetäuscht oder wirkliche betriebliche Prüfung von potenziellen Benutzern/Kunden oder einer unabhängigen Testmannschaft an der Seite der Entwickler. Alpha-Prüfung wird häufig für die Standardsoftware als eine Form der inneren Annahmeprüfung verwendet, bevor die Software zur Beta-Prüfung geht.

Beta-Prüfung

Beta-Prüfung kommt nach der Alpha-Prüfung und kann als eine Form der Außenbenutzerakzeptanz-Prüfung betrachtet werden. Versionen der Software, die als Beta-Versionen bekannt ist, werden zu einem beschränkten Publikum außerhalb der Programmiermannschaft veröffentlicht. Die Software wird zu Gruppen von Leuten veröffentlicht, so dass weitere Prüfung sicherstellen kann, dass das Produkt wenige Schulden oder Programmfehler hat. Manchmal werden Beta-Versionen zum offenen Publikum bereitgestellt, um das Feed-Back-Feld zu einer maximalen Zahl von zukünftigen Benutzern zu vergrößern.

Nichtfunktionelle Prüfung

Spezielle Methoden bestehen, um nichtfunktionelle Aspekte der Software zu prüfen. Im Gegensatz zur funktionellen Prüfung, die die richtige Operation der Software gründet (zum Beispiel, dass es das erwartete in den Designvoraussetzungen definierte Verhalten vergleicht), prüft nichtfunktionelle Prüfung nach, dass die Software richtig fungiert, selbst wenn es ungültige oder unerwartete Eingänge erhält. Softwareschuld-Einspritzung, in der Form von fuzzing, ist ein Beispiel der nichtfunktionellen Prüfung. Nichtfunktionelle Prüfung, besonders für die Software, wird entworfen, um zu gründen, ob das Gerät unter dem Test ungültige oder unerwartete Eingänge dulden kann, dadurch die Robustheit von Eingangsgültigkeitserklärungsroutinen sowie Fehlermanagement-Routinen gründend. Verschiedene kommerzielle nichtfunktionelle Probewerkzeuge werden von der Softwareschuld-Spritzenseite verbunden; es gibt auch zahlreiche offene Quelle und verfügbare Werkzeuge der kostenlosen Software, die nichtfunktionelle Prüfung durchführen.

Softwareleistungsprüfung

Leistungsprüfung wird im Allgemeinen durchgeführt, um zu bestimmen, wie ein System oder Subsystem in Bezug auf die Ansprechbarkeit und Stabilität unter einem besonderen Arbeitspensum leisten. Es kann auch dienen, um andere Qualitätsattribute des Systems, wie Skalierbarkeit, Zuverlässigkeit und Quellengebrauch zu untersuchen, zu messen, gültig zu machen oder nachzuprüfen.

Lastprüfung ist mit in erster Linie Prüfung beschäftigt, die das System fortsetzen kann, unter einer spezifischen Last, ob das zu bedienen, große Mengen von Daten oder eine Vielzahl von Benutzern sein. Das wird allgemein Softwareskalierbarkeit genannt. Die zusammenhängende Lastprobetätigkeit, wenn durchgeführt, als eine nichtfunktionelle Tätigkeit wird häufig Dauerprüfung genannt. Volumen-Prüfung ist eine Weise, Funktionalität zu prüfen. Betonungsprüfung ist eine Weise, Zuverlässigkeit unter unerwarteten oder seltenen Arbeitspensen zu prüfen. Stabilitätsprüfung (häufig gekennzeichnet als Last oder Dauerprüfung) Kontrollen, um zu sehen, ob die Software unaufhörlich gut in oder über einer annehmbaren Periode fungieren kann.

Es gibt wenig Konsens darüber, wie die spezifischen Absichten der Leistungsprüfung sind. Die Begriff-Lastprüfung, Leistungsprüfung, Zuverlässigkeitstest, und Volumen-Prüfung, wird häufig austauschbar verwendet.

Brauchbarkeitsprüfung

Brauchbarkeitsprüfung ist erforderlich, um zu überprüfen, ob die Benutzerschnittstelle leicht ist, zu verwenden und zu verstehen. Es wird hauptsächlich mit dem Gebrauch der Anwendung betroffen.

Sicherheitsprüfung

Sicherheitsprüfung ist für die Software notwendig, die vertrauliche Daten bearbeitet, um Systemeindringen durch Hacker zu verhindern.

Internationalisierung und Lokalisierung

Die allgemeine Fähigkeit der Software, die zu internationalisieren und zu lokalisieren ist, kann ohne wirkliche Übersetzung, durch das Verwenden der Pseudolokalisierung automatisch geprüft werden. Es wird nachprüfen, dass die Anwendung noch sogar arbeitet, nachdem es in eine neue Sprache übersetzt oder an eine neue Kultur (wie verschiedene Währungen oder Zeitzonen) angepasst worden ist.

Die wirkliche Übersetzung in menschliche Sprachen muss auch geprüft werden. Mögliche Lokalisierungsmisserfolge schließen ein:

• Software wird häufig durch das Übersetzen einer Liste von Schnuren aus dem Zusammenhang lokalisiert, und der Übersetzer kann die falsche Übersetzung für eine zweideutige Quellschnur wählen.
• Technische Fachsprache kann inkonsequent werden, wenn das Projekt von mehreren Menschen ohne richtige Koordination übersetzt wird, oder wenn der Übersetzer unklug ist.
• Wörtliche wortwörtliche Übersetzungen können unpassend, künstlich oder zu technisch auf der Zielsprache klingen.
• Unübersetzte Nachrichten auf der ursprünglichen Sprache können hart codiert im Quellcode verlassen werden.
• Einige Nachrichten können automatisch in der Durchlaufzeit geschaffen werden, und die resultierende Schnur kann ungrammatisch, funktionell falsch, irreführend oder verwirrend sein.
• Software kann eine Tastatur-Abkürzung verwenden, die keine Funktion auf dem Tastatur-Lay-Out der Quellsprache hat, aber verwendet wird, um Charaktere im Lay-Out der Zielsprache zu tippen.
• Software kann an Unterstützung für die Charakter-Verschlüsselung der Zielsprache Mangel haben.
• Schriftarten und Schriftart-Größen, die auf der Quellsprache passend sind, können auf der Zielsprache unpassend sein; zum Beispiel können CJK Charaktere unlesbar werden, wenn die Schriftart zu klein ist.
• Eine Schnur auf der Zielsprache kann länger sein, als die Software behandeln kann. Das kann die Schnur teilweise unsichtbar für den Benutzer machen oder die Software veranlassen, abzustürzen oder schlecht zu funktionieren.
• Software kann an richtiger Unterstützung Mangel haben, um bidirektionalen Text zu lesen oder zu schreiben.
• Software kann Images mit dem Text zeigen, der nicht lokalisiert wurde.
• Lokalisierte Betriebssysteme können Anlagenkonfigurationsdateien und Umgebungsvariablen und verschiedene Formate für das Datum und die Währung verschieden genannt haben.

Um diese und anderen Lokalisierungsprobleme zu vermeiden, muss ein Prüfer, der die Zielsprache weiß, das Programm mit allen möglichen Gebrauch-Fällen für die Übersetzung führen, um zu sehen, ob die Nachrichten lesbar, richtig im Zusammenhang übersetzt sind und Misserfolge nicht verursachen.

Zerstörende Prüfung

Zerstörende Prüfung versucht, die Software oder ein Subsystem zu veranlassen, zu scheitern, um seine Robustheit zu prüfen.

Der Probeprozess

Traditioneller CMMI oder Wasserfall-Entwicklungsmodell

Eine übliche Praxis der Softwareprüfung ist, dass Prüfung von einer unabhängigen Gruppe von Prüfern durchgeführt wird, nachdem die Funktionalität entwickelt wird, bevor es dem Kunden verladen wird. Diese Praxis läuft häufig auf die Probephase hinaus, die als ein Projektpuffer wird pflegt, Projektverzögerungen dadurch zu ersetzen, die der Prüfung gewidmete Zeit in Verlegenheit bringend.

Eine andere Praxis soll Software anfangen, die im gleichen Moment die Projektanfänge prüft, und es ist ein dauernder Prozess, bis das Projekt fertig ist.

Flinkes oder Äußerstes Entwicklungsmodell

Im Gegensatz, einige erscheinende Softwaredisziplinen wie äußerste Programmierung und die flinke Softwareentwicklungsbewegung, kleben Sie an einem "probegefahrenen" Softwareentwicklungsmodell. In diesem Prozess werden Einheitstests zuerst, von den Softwareingenieuren (häufig mit dem Paar geschrieben, das in der äußersten Programmiermethodik programmiert). Natürlich scheitern diese Tests am Anfang; weil, wie man erwartet, sie. Dann, da Code geschrieben wird, passiert er zusätzlich größere Teile der Testgefolge. Die Testgefolge werden unaufhörlich als neue Misserfolg-Bedingungen aktualisiert, und Eckfälle werden entdeckt, und sie werden mit irgendwelchen Tests des rückwärts Gehens integriert, die entwickelt werden. Einheitstests werden zusammen mit dem Rest des Softwarequellcodes aufrechterhalten und allgemein in den bauen Prozess integriert (mit von Natur aus interaktiven Tests, die zu teilweise manuellem verbannen werden, bauen Annahmeprozess). Die äußerste Absicht dieses Testprozesses ist, dauernde Integration zu erreichen, wo Softwareaktualisierungen zum Publikum oft veröffentlicht werden können.

Ein Beispielprobezyklus

Obwohl Schwankungen zwischen Organisationen bestehen, gibt es einen typischen Zyklus für die Prüfung. Die Probe ist unten unter Organisationen üblich, die das Wasserfall-Entwicklungsmodell verwenden.

• Bedarfsanalyse: Prüfung sollte in der Voraussetzungsphase des Softwareentwicklungslebenszyklus beginnen. Während der Designphase arbeiten Prüfer mit Entwicklern in der Bestimmung, welche Aspekte eines Designs prüfbar sind und damit, welche Rahmen jene Tests arbeiten.
• Testplanung: Teststrategie, Prüfplan, Prüfstand-Entwicklung. Da viele Tätigkeiten während der Prüfung ausgeführt werden, ist ein Plan erforderlich.
• Testentwicklung: Testverfahren, Testdrehbücher, Testfälle, prüfen datasets, prüfen Schriften, um in der Prüfung der Software zu verwenden.
• Testausführung: Prüfer führen die Software durch, die auf den Plänen gestützt ist, und prüfen Dokumente dann geben irgendwelche zur Entwicklungsmannschaft gefundenen Fehler aus.
• Testbericht: Sobald Prüfung vollendet wird, erzeugen Prüfer Metrik und machen Schlussberichte auf ihrer Testanstrengung, und ob die geprüfte Software zur Ausgabe bereit ist.
• Testergebnisanalyse: Sich Oder Defekt-Analyse, wird von der Entwicklungsmannschaft gewöhnlich zusammen mit dem Kunden getan, um das zu entscheiden, welche Defekte zugeteilt werden sollten, zurückgewiesen befestigt haben (d. h. Software gefunden hat, die richtig arbeitet), oder gefügt hat, um später befasst zu werden.
• Wieder testender Defekt: Sobald ein Defekt von der Entwicklungsmannschaft befasst worden ist, wird er von der Probemannschaft wieder getestet. AUCH BEKANNT ALS Entschlossenheitsprüfung.
• Prüfung des rückwärts Gehens: Es ist üblich, ein kleines Testprogramm einer Teilmenge von Tests für jede Integration der neuen, modifizierten oder befestigten Software bauen zu lassen, um sicherzustellen, dass die letzte Übergabe nichts zerstört hat, und dass das Softwareprodukt noch als Ganzes richtig arbeitet.
• Testverschluss: Sobald der Test den Ausgangskriterien, die Tätigkeiten wie das Gefangennehmen der Schlüsselproduktionen, Lektionen gelernt, Ergebnisse, Klotz entspricht, werden mit dem Projekt verbundene Dokumente archiviert und als eine Verweisung für zukünftige Projekte verwendet.

Automatisierte Prüfung

Viele Programmiergruppen verlassen sich immer mehr auf die automatisierte Prüfung, besonders Gruppen dieser Gebrauch

probegefahrene Entwicklung. Es gibt vieles Fachwerk, um Tests in zu schreiben, und dauernde Integrationssoftware wird Tests automatisch jedes Mal durchführen, wenn Code in ein Versionsregelsystem überprüft wird.

Während Automation alles nicht wieder hervorbringen kann, was ein Mensch tun kann (und alle Weisen, wie sie denken, sie zu tun), kann es für die Prüfung des rückwärts Gehens sehr nützlich sein. Jedoch verlangt es wirklich ein gut entwickeltes Testgefolge, Schriften zu prüfen, um aufrichtig nützlich zu sein.

Prüfung von Werkzeugen

Programm-Prüfung und Schuld-Entdeckung kann bedeutsam durch die Prüfung von Werkzeugen und Testhilfeprogrammen geholfen werden.

Prüfende/die Fehler beseitigende Werkzeuge schließen Eigenschaften ein wie:

• Programm-Monitore, volle oder teilweise Überwachung des Programm-Codes erlaubend, einschließlich:
• Befehlssatz-Simulator, ganze Instruktionsniveau-Überwachung und Spur-Möglichkeiten erlaubend
• Programm-Zeichentrickfilm, schrittweise Ausführung und bedingten Unterbrechungspunkt am Quellniveau oder in der Maschine erlaubend, codiert
• Codeeinschluss meldet
• Formatierte Müllkippe oder das symbolische Beseitigen, Werkzeuge, die Inspektion von Programm-Variablen auf dem Fehler oder an gewählten Punkten erlauben
• Automatisierte funktionelle GUI Prüfung von Werkzeugen werden verwendet, um Systemebene-Tests durch den GUI zu wiederholen
• Abrisspunkte, Zeitverhalten-Vergleichen erlaubend, gemacht zu werden
• Leistungsanalyse (oder Kopierfräswerkzeuge), der helfen kann, Krisenherde und Quellengebrauch hervorzuheben

Einige dieser Eigenschaften können in Integrated Development Environment (IDE) vereinigt werden.

• Eine Probetechnik des rückwärts Gehens soll einen Standardsatz von Tests haben, die vorhandene Funktionalität bedecken, die auf beharrliche tabellarische Daten hinauslaufen, und Voränderungsdaten zu vergleichen, um Daten postzuändern, wo es Unterschiede mit einem Werkzeug wie diffkit nicht geben sollte. Entdeckte Unterschiede zeigen unerwartete Funktionalitätsänderungen oder "rückwärts Gehen" an.

Maß in der Softwareprüfung

Gewöhnlich wird Qualität zu solchen Themen wie Genauigkeit, Vollständigkeit, Sicherheit beschränkt, aber kann auch mehr technische Voraussetzungen, wie beschrieben, unter dem ISO normalen ISO/IEC 9126, wie Fähigkeit, Zuverlässigkeit, Leistungsfähigkeit, Beweglichkeit, Haltbarkeit, Vereinbarkeit und Brauchbarkeit einschließen.

Es gibt mehrere oft verwendete Softwaremaßnahmen, häufig genannt Metrik, die verwendet werden, um bei der Bestimmung des Staates der Software oder der Angemessenheit der Prüfung zu helfen.

Prüfung von Kunsterzeugnissen

Der Softwareprobeprozess kann mehrere Kunsterzeugnisse erzeugen.

Prüfplan: Eine Testspezifikation wird einen Prüfplan genannt. Die Entwickler sind sich dessen wohlbewusst, welche Prüfpläne durchgeführt werden und diese Information zum Management und den Entwicklern bereitgestellt wird. Die Idee ist, sie vorsichtiger zu machen, wenn sie ihren Code entwickelt oder zusätzliche Änderungen vornimmt. Einige Gesellschaften haben ein Dokument des höheren Niveaus genannt eine Teststrategie.

Rückverfolgbarkeitsmatrix: Eine Rückverfolgbarkeitsmatrix ist ein Tisch, der Voraussetzungen oder Designdokumente aufeinander bezieht, um Dokumente zu prüfen. Es wird verwendet, um Tests zu ändern, wenn zusammenhängende Quelldokumente geändert werden, um Testfälle für die Ausführung auszuwählen, wenn man für Tests des rückwärts Gehens durch das Betrachten des Voraussetzungseinschlusses plant.

Testfall: Ein Testfall besteht normalerweise aus einem einzigartigen Bezeichner, Voraussetzungsverweisungen von einer Designspezifizierung, Vorbedingungen, Ereignissen, einer Reihe von Schritten (auch bekannt als Handlungen), um zu folgen, Produktion, erwartetes Ergebnis und wirkliches Ergebnis einzugeben. Klinisch definiert ist ein Testfall ein Eingang und ein erwartetes Ergebnis. Das kann so pragmatisch sein, wie 'für die Bedingung x Ihr abgeleitetes Ergebnis y ist', wohingegen andere Testfälle ausführlicher das Eingangsdrehbuch beschrieben haben, und welche Ergebnisse erwartet werden könnten. Es kann gelegentlich eine Reihe von Schritten sein (aber geht häufig werden in einem getrennten Testverfahren enthalten, das gegen vielfache Testfälle, als Angelegenheit für die Wirtschaft ausgeübt werden kann), aber mit einem erwartetem Ergebnis oder erwartetem Ergebnis. Die fakultativen Felder sind ein Testfall-Personalausweis, prüfen Schritt oder Ordnung der Ausführungszahl, verwandter Voraussetzung (En), Tiefe, prüfen Kategorie, Autor und Ankreuzfelder dafür, ob der Test automatable ist und automatisiert worden ist. Größere Testfälle können auch erforderliche Staaten oder Schritte und Beschreibungen enthalten. Ein Testfall sollte auch einen Platz für das wirkliche Ergebnis enthalten. Diese Schritte können in einem Textverarbeitungsprogramm-Dokument, Spreadsheet, Datenbank oder anderem allgemeinem Behältnis versorgt werden. In einem Datenbanksystem können Sie auch im Stande sein, vorige Testergebnisse zu sehen, wer die Ergebnisse erzeugt hat, und welche Anlagenkonfiguration verwendet wurde, um jene Ergebnisse zu erzeugen. Diese vorigen Ergebnisse würden gewöhnlich in einem getrennten Tisch versorgt.

Testschrift: Eine Testschrift ist ein Verfahren, oder Code programmierend, der Benutzerhandlungen wiederholt. Am Anfang wurde der Begriff aus dem Produkt der durch automatisierte Testwerkzeuge des rückwärts Gehens geschaffenen Arbeit abgeleitet. Testfall wird eine Grundlinie sein, um Testschriften mit einem Werkzeug oder einem Programm zu schaffen.

Testgefolge: Der grösste Teil des verbreiteten Ausdruckes für eine Sammlung von Testfällen ist ein Testgefolge. Das Testgefolge enthält häufig auch ausführlichere Instruktionen oder Absichten für jede Sammlung von Testfällen. Es enthält bestimmt eine Abteilung, wo der Prüfer die während der Prüfung verwendete Anlagenkonfiguration identifiziert. Eine Gruppe von Testfällen kann auch erforderliche Staaten oder Schritte und Beschreibungen der folgenden Tests enthalten.

Testdaten: In den meisten Fällen werden vielfache Sätze von Werten oder Daten verwendet, um dieselbe Funktionalität einer besonderen Eigenschaft zu prüfen. Alle Prüfwerte und veränderliche Umweltbestandteile werden in getrennten Dateien gesammelt und als Testdaten versorgt. Es ist auch nützlich, dem Daten dem Kunden und mit dem Produkt oder einem Projekt zur Verfügung zu stellen.

Testgeschirr: Auf die Software, Werkzeuge, Proben des Dateneingangs und der Produktion und der Konfigurationen wird alles insgesamt als ein Testgeschirr verwiesen.

Zertifikate

Mehrere Zertifikat-Programme bestehen, um die Berufssehnsüchte von Softwareprüfern und Qualitätssicherungsfachmännern zu unterstützen. Kein Zertifikat zurzeit angeboten verlangt wirklich, dass der Bewerber die Fähigkeit unter Beweis stellt, Software zu prüfen. Kein Zertifikat basiert auf einem weit akzeptierten Körper von Kenntnissen. Das hat einige dazu gebracht zu erklären, dass das Probefeld zum Zertifikat nicht bereit ist. Zertifikat selbst kann eine Produktivität einer Person, ihre Sachkenntnis oder praktische Kenntnisse nicht messen, und kann ihre Kompetenz oder Professionalismus als ein Prüfer nicht versichern.

Software, die Zertifikat-Typen prüft

:* Prüfungsbasiert: Formalisierte Prüfungen, die passiert werden müssen; kann auch durch den zum Selbststudium [z.B, für ISTQB oder QAI] erfahren werden

:* Ausbildungsbasiert: Lehrer-geführte Sitzungen, wo jeder Kurs [z.B, Internationales Institut für die Software passiert werden muss, die (IIST)] Prüft.

Prüfung von Zertifikaten

:* Der beglaubigte Partner in der Softwareprüfung hat sich angeboten durch den QAI (GEWORFEN)

:* CATe, der vom Internationalen Institut für die Software angeboten ist, die Prüft

:* Der beglaubigte Betriebsleiter in der Software, die (CMST) Prüft, der durch den QAI angeboten ist

:* Beglaubigter Softwareprüfer (CSTE), der von Quality Assurance Institute (QAI) angeboten ist

:* Certified Software Test Professional (CSTP), der vom Internationalen Institut für die Software angeboten ist, die Prüft

:* CSTP(TM) (australische Version) angeboten von K. J. Ross & Associates

:* ISEB, der vom Informationssystemüberprüfungsausschuss angeboten ist

:* ISTQB Beglaubigter Prüfer, Fundament-Niveau (CTFL), der durch die Internationale Software angeboten ist, die Qualifikationsausschuss Prüft

:* ISTQB Beglaubigter Prüfer, Fortgeschrittenes Niveau (CTAL), der durch die Internationale Software angeboten ist, die Qualifikationsausschuss Prüft

:* TMPF TMap Folgendes Fundament, das vom Überprüfungsinstitut für die Informationswissenschaft angeboten ist

:* TMPA TMap Als nächstes Fortgeschritten angeboten vom Überprüfungsinstitut für die Informationswissenschaft

Qualitätssicherungszertifikate

:* CMSQ hat sich durch Quality Assurance Institute (QAI) geboten.

:* CSQA, der von Quality Assurance Institute (QAI) angeboten ist

:* CSQE, der von der amerikanischen Gesellschaft für die Qualität (ASQ) angeboten ist

:* CQIA, der von der amerikanischen Gesellschaft für die Qualität (ASQ) angeboten ist

Meinungsverschiedenheit

Einige der Hauptsoftwareprobemeinungsverschiedenheiten schließen ein:

Was setzt verantwortliche Softwareprüfung ein?: Mitglieder der "Zusammenhang-gesteuerten" Schule der Prüfung glauben, dass es keine "besten Methoden" der Prüfung, aber eher gibt, dass Prüfung eine Reihe von Sachkenntnissen ist, die dem Prüfer erlauben, Probemethoden auszuwählen oder zu erfinden, um jeder einzigartigen Situation anzupassen.

Flink gegen den traditionellen: Sollten Prüfer lernen, unter Bedingungen der Unklarheit und unveränderlichen Änderung zu arbeiten, oder sollten sie auf Prozess "Reife" zielen? Die flinke Probebewegung hat wachsende Beliebtheit seit 2006 hauptsächlich in kommerziellen Kreisen erhalten, wohingegen militärische und Regierungssoftwareversorger diese Methodik sondern auch die traditionellen testletzten Modelle (z.B im Wasserfall-Modell) verwenden.

Forschungstest gegen scripted: Sollten Tests zur gleichen Zeit entworfen werden, weil sie durchgeführt werden oder sollten sie im Voraus entworfen werden?

Manuelle Prüfung gegen den automatisierten: Einige Schriftsteller glauben, dass Testautomation hinsichtlich seines Werts so teuer ist, dass sie sparsam verwendet werden sollte. Mehr insbesondere stellt probegefahrene Entwicklung fest, dass Entwickler Einheitstests des Typs XUnit vor dem Codieren der Funktionalität schreiben sollten. Die Tests können dann als eine Weise betrachtet werden, die Voraussetzungen zu gewinnen und durchzuführen.

Softwaredesign gegen die Softwaredurchführung: Sollte Prüfung nur am Ende oder während des ganzen Prozesses ausgeführt werden?

Wer beobachtet die Wachmänner?: Die Idee besteht darin, dass jede Form der Beobachtung auch eine Wechselwirkung ist - kann die Tat der Prüfung auch das betreffen, das geprüft wird.

Siehe auch

• Annahme, die prüft
• Vollpaare, die prüfen
• Automatisierte Prüfung
• Dynamische Programm-Analyse
• Formelle Überprüfung
• GUI Software, die prüft
• Unabhängige Testorganisation
• Handbuch, das prüft
• Orthogonale Reihe, die prüft
• Paar, das prüft
• Kehren Sie semantische Rückverfolgbarkeit um
• Softwaretestbarkeit
• Statische Codeanalyse
• Orthogonale Defekt-Klassifikation
• Testverwaltungswerkzeuge
• Web, das prüft

Links

• "Software, die Software besser" Economist.com macht
• Automatisierte Software, die Metrik einschließlich der manuellen Probemetrik prüft