Testmodell ist eine logische Struktur, die die Funktionalität des Systems und/oder das Benutzerverhalten beschreibt, nach der Testfälle generiert werden. Das Erstellen eines Testmodells beginnt mit dem Erstellen einer Struktur, und dann wird die genehmigte Struktur mit Testfällen gefüllt.

Modelle werden normalerweise basierend auf Anforderungen und/oder erwartetem Verhalten des Systems erstellt. Das Erstellen und Verwalten eines Testmodells eignet sich für große Systeme mit komplexer Geschäftslogik und ist schwierig auf Projekte mit agilen Methoden anzuwenden, weil die Kosten für die Aufrechterhaltung des Testmodellmanagements und des Qualitätssicherungsprozesses werden zu hoch sein.

Testmodellmanagement ist ein Prozess, der die Abdeckung des Testmodells, die Qualität der Szenarien, die das Testmodell beschreiben, und seine Aktualisierung steuert.

Das Testmodellmanagement ist ein durchgängiger Prozess Lebenszyklus Produkt.

Modellabdeckung testen

Um die Abdeckung aller Anforderungen zu steuern, können Sie Tracematrizen verwenden, die die Abdeckung von Anforderungen durch Testszenarien ermitteln (siehe Beispiel).
Bevor die Testfälle beschrieben werden, muss der Aufbau des Testmodells mit dem Kunden abgestimmt werden.

Skriptqualität

Um die Qualität von Szenarien zu steuern, ist es notwendig, nicht nur den Beschreibungsgrad von Testfällen, sondern auch deren Qualität zu kontrollieren.

Bevor mit der Beschreibung von Testfällen begonnen wird, ist es notwendig, die Anforderungen für jede Beschreibungsebene und die Kriterien für die Qualität der Beschreibung von Testfällen zu definieren.

Mögliche Beschreibungsebenen von Testfällen:

Auf der 4. Ebene kann die Vereinbarung mit dem Kunden durch eine Vereinbarung ersetzt werden.

Die Qualitätskriterien für die Beschreibung von Testfällen können wie folgt aussehen:

• Testfälle müssen entsprechend den Anforderungen geschrieben werden

Beim Testen wird überprüft, ob ein Produkt seine Anforderungen erfüllt. Daher ist es notwendig, im Teil der allgemeinen Beschreibung des Testfalls (in Testtrackingsystemen wird meist der Begriff „Summary“ verwendet) auf eine konkrete Anforderung in Verbindung mit Fragmenten des Anforderungstextes hinzuweisen. Somit wird für alle Projektbeteiligten klar, auf welcher Grundlage dieser Testfall geschrieben wurde.

• Verwenden Sie detaillierte Voraussetzungen

Wie spart man Zeit bei Testfällen?

Legen Sie Formatierungsregeln für alle Testfälle fest. So wird der Testfall für jeden Projektbeteiligten leicht verständlich und lesbar. Bei einem Projekt können Sie beispielsweise die folgenden Regeln eingeben:

• Alle Eingabeparameter sollten rot markiert sein.
• Alle Skripte müssen blau markiert sein,
• Alle Namen von Schaltflächen, Feldern, Blöcken sind kursiv und fett gedruckt.
• Wichtige Passagen sind unterstrichen.
• Jeder durchgeführte Schritt muss ein erwartetes Ergebnis haben.
• Jeder Schritt in Testfällen sollte nur eine Aktion und das erwartete Ergebnis dazu beschreiben. Diese. Beim Empfang eines fehlgeschlagenen Testfalls in einem bestimmten Schritt sollte eindeutig klar sein, bei welcher Aktion der Fehler auftritt.
• Das erwartete Ergebnis muss eindeutig sein.

Testfälle müssen eindeutig sein, d.h. sollten so konzipiert und formuliert sein, dass sie keine missverständliche Interpretation zulassen, aber von allen Beteiligten klar verstanden werden.

Wenn das Schreiben von Testfällen lange dauert, kann es vorkommen, dass ein Spezialist seine Fehler nicht mehr sieht. Dazu brauchen Sie einen Blick von der Seite - hier hilft es Querrezension. Diese Phase wird in Fällen empfohlen, in denen die Entwicklung eines Testmodells zeitlich ausgedehnt und langwierig ist. Zum Beispiel, wenn die Entwicklung von Testszenarien länger als 1 Monat dauert.

Der Skript-Qualitätskontrollprozess kann durchgeführt werden mit Testmodellsteuerung- speziell vorbereitete Vorlage.

Update des Testmodells

Es ist notwendig, das Testmodell und die Testfälle selbst regelmäßig zu aktualisieren, um die Anforderungen zu erfüllen, sowie die Prioritäten der Testfälle zu überprüfen.

Zum Aktualisieren Sie können eine "Anforderungsmatrix" pflegen(Requirement Traceability Matrix): Nach jeder Änderung einer bestimmten Anforderung wird aus dem Testtracking-System eine Auswahl aller auf diese Anforderung bezogenen Testszenarien getroffen und aktualisiert.

Kontrollen des Testmodells:

• Testschiene
• Testlink
• Jira+Zephyr
• Microsoft-Testmanager (MTM)
• übertreffen

Testen ist ein Prozess, mit dem Sie die Qualität des hergestellten Produkts bewerten können. Ein hochwertiges Softwareprodukt muss sowohl funktional als auch nichtfunktional die Anforderungen daran erfüllen. Das PS muss alle erforderlichen VIs implementieren und darf keine Fehler aufweisen – Unterschiede zwischen den realen Eigenschaften oder dem Verhalten von den erforderlichen. Außerdem muss der PS die Eigenschaften Zuverlässigkeit (es darf keine Aufhänger, Abstürze etc. geben), Sicherheit, die gewünschte Performance bereitstellen, einfach zu bedienen, erweiterbar etc. sein. Testen ist also ein Prozess der Analyse des PS , mit dem Ziel, Defekte zu identifizieren und die Eigenschaften von PS zu beurteilen.

Ziele des Testprozesses

Der Zweck des Testens ist es, die Qualität zu bewerten Softwareprodukt durch

• Komponenten-Interaktionsprüfungen;
• Überprüfung der korrekten Integration von Komponenten;
• Überprüfung der Richtigkeit der Umsetzung aller Anforderungen und Identifizierung von Mängeln.

Merkmale des Testprozesses in RUP

Das Testen ist ein iterativer Prozess, der durchgeführt wird in allen Phasen des Lebenszyklus. Das Testen beginnt von vorne Erstphase Anforderungen an ein zukünftiges Produkt identifizieren und eng mit aktuellen Aufgaben verzahnen. Für jede Iteration werden das Ziel des Testens und Methoden zu dessen Erreichung festgelegt. Am Ende jeder Iteration wird festgestellt, inwieweit dieses Ziel erreicht wurde, ob zusätzliche Tests erforderlich sind, ob die Prinzipien und Testwerkzeuge geändert werden sollten.

Jeder festgestellte Mangel wird mit einer Beschreibung der Situation, in der er festgestellt wurde, in der Projektdatenbank erfasst. Der Analytiker stellt fest, ob es sich um einen echten Fehler handelt und ob es sich um eine Wiederholung eines zuvor entdeckten Fehlers handelt. Der gefundene Fehler wird zugeordnet eine Priorität A zeigt die Wichtigkeit des Fixes an. Der Entwickler, der für die Entwicklung des Subsystems, der Komponente oder der Klasse verantwortlich ist, oder eine andere vom Manager bestimmte Person, fährt mit der Behebung des Fehlers fort. Die Reihenfolge der Fehlerbeseitigung richtet sich nach deren Priorität. Der Tester wiederholt die Tests und ist überzeugt (oder nicht überzeugt), dass der Fehler behoben wurde.

Testentwickler verantwortlich für die Planung, Entwicklung und Durchführung von Tests. Er erstellt einen Testplan und -modell, Testverfahren (siehe unten) und wertet die Testergebnisse aus.

Tester (Tester) verantwortlich für die Durchführung von Systemtests. Zu seinen Aufgaben gehören das Einrichten und Ausführen von Tests, das Bewerten der Testleistung, das Beheben von Fehlern und das Aufzeichnen erkannter Fehler.

Artefakte

Beim Testen werden folgende Dokumente erstellt:

Versuchsplan– ein Dokument, das die Teststrategie in jeder Iteration definiert. Es enthält eine Beschreibung der Ziele des Testens in der aktuellen Iteration sowie der Strategien, die verwendet werden. Der Plan gibt an, welche Ressourcen erforderlich sind, und enthält eine Liste von Tests.

Testmodell ist eine Darstellung dessen, was und wie getestet wird. Das Modell umfasst eine Reihe von Kontrollaufgaben, Testmethoden, Testszenarien und erwarteten Ergebnissen (Testfälle), Testskripte und Beschreibungen von Testinteraktionen.

• Kontrollaufgabe– eine Reihe von Testdaten, Testausführungsbedingungen und erwarteten Ergebnissen.
• Testmethode– ein Dokument mit Anweisungen zur Einrichtung und Durchführung von Kontrollaufgaben sowie zur Bewertung der erzielten Ergebnisse.
• Testskript- Dies ist eine vereinfachte Beschreibung des Tests, einschließlich der Ausgangsdaten, Bedingungen und Handlungsabläufe sowie der erwarteten Ergebnisse.
• Testskript ist ein Programm, das beim automatisierten Testen mit Testwerkzeugen ausgeführt wird.
• Beschreibung der Testinteraktion ist ein Diagramm von Sequenzen oder Kooperationen, das den zeitlich geordneten Fluss von Nachrichten zwischen Testkomponenten und dem Testobjekt widerspiegelt.

Testergebnisse und Daten, die während der Durchführung von Tests erhalten wurden.

Workload-Modell wird verwendet, um externe Funktionen, die von Endbenutzern ausgeführt werden, den Umfang dieser Funktionen und die durch diese Funktionen erzeugte Arbeitslast zu modellieren. Das Modell ist für die Durchführung von Belastungs- und/oder Belastungstests bestimmt, die den Betrieb des Systems unter realen Bedingungen simulieren.

Mängel- dies sind Beschreibungen der Tatsachen der Nichterfüllung des Systems mit den Anforderungen, die während der Prüfung festgestellt wurden. Sie sind eine Art von Änderungsanträgen.

Testarbeiten werden in jeder Iteration in allen Phasen durchgeführt, aber die Ziele in den verschiedenen Phasen des Projekts unterscheiden sich erheblich.

Phase des Projekteintritts. In dieser Phase erfolgt die Vorbereitung auf die Prüfung. Es enthält:

• Erstellen Sie einen Testplan mit Testanforderungen und Teststrategien. Für alle Arten von Tests (Funktion, Last usw.) kann ein einziger Plan oder für jeden Typ separate Pläne erstellt werden.
• Analyse des Prüfumfangs.
• Formulierung von Qualitätskriterien und Durchführung der Prüfung.
• Installation und Vorbereitung für den Betrieb von Prüfwerkzeugen.
• Formulierung von Anforderungen an das PS-Entwicklungsprojekt, bestimmt durch die Erfordernisse des Testens.

Entwicklungsphase. In den Iterationen dieser Phase beginnt die Konstruktion des Testmodells und der zugehörigen Artefakte. Da das VI-Modell in dieser Phase bereits vorhanden ist, können Sie mit dem Entwurf von Testszenarien beginnen. Gleichzeitig ist von der Durchführung von Tests abzuraten, da in dieser Phase meist noch keine fertigen PS-Fragmente vorliegen. Folgende Tätigkeiten werden durchgeführt:

• Entwicklung von Testszenarien.
• Erstellung von Testskripten.
• Entwicklung von Steuerungsaufgaben.
• Entwicklung von Testmethoden.
• Entwicklung eines Workload-Modells.

Konstruktionsphase. In dieser Phase entstehen fertige Systemfragmente und Prototypen, die getestet werden müssen. Gleichzeitig werden in fast jeder Iteration alle Module überprüft (sowohl bereits entwickelte und getestete als auch neue in der aktuellen Iteration hinzugefügt). Tests, die in früheren Iterationen angewendet wurden, werden auch in nachfolgenden Iterationen für Regressionstests verwendet, d. h. um zu überprüfen, ob die zuvor implementierte Systemfunktionalität in der neuen Iteration erhalten bleibt. Folgende Tätigkeiten werden durchgeführt:

• Erstellen Sie für jede Iteration einen Testplan.
• Verfeinerung und Ergänzung des Testmodells.
• Durchführung von Tests.
• Beschreibung der festgestellten Mängel.
• Beschreibung der Testergebnisse.
• Auswertung der Testergebnisse.

Basierend auf den Testergebnissen werden Änderungen am Programmcode vorgenommen, um die identifizierten Fehler zu beseitigen, wonach der Test wiederholt wird.

Bereitstellungsphase. In Iterationen dieser Phase wird das gesamte PS als Softwareprodukt getestet. Die durchgeführten Aktivitäten ähneln den Aktivitäten der vorherigen Phase. Die Fehlererkennung bestimmt die Notwendigkeit von Änderungen und erneuten Tests. Der iterative Prozess wird wiederholt, bis die Testbeendigungskriterien erfüllt sind.

Die Testergebnisse werden auf der Grundlage von Testmetriken bewertet, die es ermöglichen, die Qualität des getesteten PS und des Testprozesses selbst zu bestimmen.

Instrumentelle Unterstützung

Da der iterative Testprozess mehrere Wiederholungen von Tests beinhaltet, wird manuelles Testen ineffizient und erlaubt keine gründliche Bewertung der Qualität des Softwareprodukts. Dies gilt insbesondere für Belastungs- und Belastungstests, bei denen Sie die Arbeitslast simulieren und eine erhebliche Datenmenge sammeln müssen. Die Lösung besteht darin, Tools zu verwenden, die die Automatisierung des Kompilierens und Ausführens von Tests unterstützen.

Wie der Entwicklungsprozess folgt auch der Software-Nachtestprozess einer bestimmten Methodik. Unter Methodik verstehen wir in diesem Fall die verschiedenen Kombinationen von Prinzipien, Ideen, Methoden und Konzepten, auf die Sie bei der Arbeit an einem Projekt zurückgreifen.

Derzeit gibt es eine ziemlich große Anzahl unterschiedlicher Testansätze mit jeweils eigenen Ausgangspunkten, Ausführungsdauern und Methoden, die in jeder Phase verwendet werden. Und die Wahl des einen oder anderen kann eine ziemliche Herausforderung sein. In diesem Artikel werden wir uns verschiedene Ansätze für das Testen von Software ansehen und über ihre Hauptmerkmale sprechen, um Ihnen zu helfen, sich in der bestehenden Vielfalt zurechtzufinden.

Wasserfallmodell (Linear sequentielles Softwarelebenszyklusmodell)

Das Wasserfallmodell ist eines der ältesten Modelle, das nicht nur für die Softwareentwicklung oder das Testen, sondern für fast jedes andere Projekt verwendet werden kann. Seine Grundprinzip ist die Reihenfolge, in der Aufgaben ausgeführt werden. Das bedeutet, dass wir erst mit dem nächsten Entwicklungs- oder Testschritt fortfahren können, nachdem der vorherige erfolgreich abgeschlossen wurde. Dieses Modell eignet sich für kleine Projekte und ist nur anwendbar, wenn alle Anforderungen klar definiert sind. Die Hauptvorteile dieser Methodik sind wirtschaftliche Effizienz, Benutzerfreundlichkeit und Dokumentationsverwaltung.

Der Software-Testprozess beginnt nach Abschluss des Entwicklungsprozesses. In dieser Phase werden alle erforderlichen Tests von Einheiten auf Systemtests übertragen, um den Betrieb der Komponenten sowohl einzeln als auch als Ganzes zu kontrollieren.

Neben den oben genannten Vorteilen hat dieser Testansatz auch seine Nachteile. Es besteht immer die Möglichkeit, kritische Fehler im Testprozess zu finden. Dies kann dazu führen, dass eine der Systemkomponenten oder sogar die gesamte Logik des Projekts komplett geändert werden muss. Eine solche Aufgabe ist jedoch beim Wasserfallmodell nicht möglich, da die Rückkehr zum vorherigen Schritt in dieser Methodik verboten ist.

Erfahren Sie mehr über das Wasserfallmodell aus dem vorherigen Artikel..

V-Modell (Verifikations- und Validierungsmodell)

Wie das Wasserfallmodell basiert auch das V-Modell auf einer direkten Abfolge von Schritten. Der Hauptunterschied zwischen diesen beiden Methoden besteht darin, dass das Testen in diesem Fall parallel zur entsprechenden Entwicklungsphase geplant wird. Gemäß dieser Softwaretestmethodik beginnt der Prozess, sobald die Anforderungen definiert sind und es möglich wird, mit dem statischen Testen zu beginnen, d.h. Verifizierung und Überprüfung, wodurch mögliche Softwarefehler zu einem späteren Zeitpunkt vermieden werden. Für jede Ebene der Softwareentwicklung wird ein geeigneter Testplan erstellt, der die erwarteten Ergebnisse und Ein- und Ausstiegskriterien für dieses Produkt definiert.

Das Schema dieses Modells zeigt das Prinzip der Aufteilung von Aufgaben in zwei Teile. Diejenigen, die sich auf Design und Entwicklung beziehen, sind auf der linken Seite platziert. Aufgaben im Zusammenhang mit Softwaretests befinden sich auf der rechten Seite:

Die Hauptschritte dieser Methodik können variieren, beinhalten aber typischerweise Folgendes:

• Bühne Anforderungsdefinitionen. Zu dieser Phase gehört die Abnahmeprüfung. Seine Hauptaufgabe besteht darin, die Bereitschaft des Systems für den endgültigen Einsatz zu beurteilen.
• Das Stadium, in dem High-Level-Design oder High-Level-Design (HDL). Diese Phase bezieht sich auf Systemtests und beinhaltet eine Bewertung der Erfüllung der Anforderungen für integrierte Systeme.
• Detaillierte Entwurfsphase(Detailed Design) findet parallel zur Integrationstestphase statt, in der die Interaktionen zwischen den verschiedenen Komponenten des Systems getestet werden
• Nach Codierungsphase Ein weiterer wichtiger Schritt beginnt – Unit-Tests. Es ist sehr wichtig darauf zu achten, dass das Verhalten einzelner Teile und Komponenten der Software korrekt ist und den Anforderungen entspricht.

Der einzige Nachteil der betrachteten Testmethodik ist das Fehlen vorgefertigter Lösungen, die angewendet werden könnten, um Softwarefehler zu beseitigen, die während der Testphase gefunden wurden.

inkrementelles Modell

Diese Methodik kann als Multikaskaden-Softwaretestmodell beschrieben werden. Der Workflow ist in mehrere Zyklen unterteilt, die jeweils auch in Module unterteilt sind. Jede Iteration fügt der Software bestimmte Funktionen hinzu. Das Inkrement besteht aus drei Zyklen:

1. Design und Entwicklung
2. testen
3. Implementierung.

In diesem Modell ist die gleichzeitige Entwicklung verschiedener Produktversionen möglich. Beispielsweise kann sich die erste Version in der Testphase befinden, während sich die zweite Version in der Entwicklung befindet. Die dritte Version kann gleichzeitig die Designphase durchlaufen. Dieser Prozess kann bis zum Ende des Projekts fortgesetzt werden.

Offensichtlich erfordert diese Methodik die schnellstmögliche Erkennung der maximal möglichen Anzahl von Fehlern in der zu testenden Software. Sowie die Implementierungsphase, die die Bestätigung der Lieferbereitschaft des Produkts an den Endverbraucher erfordert. All diese Faktoren erhöhen das Gewicht der Testanforderungen erheblich.

Im Vergleich zu früheren Methoden ist das inkrementelle Modell hat mehrere wichtige Vorteile. Es ist flexibler, Anforderungsänderungen führen zu geringeren Kosten und der Software-Testprozess ist effizienter, da das Testen und Debuggen durch die Verwendung kleiner Iterationen viel einfacher ist. Es ist jedoch erwähnenswert Gesamtwert immer noch höher als beim Kaskadenmodell.

Spiralmodell

Das Spiralmodell ist eine Softwaretestmethodik, die auf einem inkrementellen Ansatz und Prototyping basiert. Es besteht aus vier Stufen:

1. Planung
2. Risikoanalyse
3. Entwicklung
4. Klasse

Unmittelbar nach Abschluss des ersten Zyklus beginnt der zweite. Das Testen von Software beginnt in der Planungsphase und dauert bis zur Bewertungsphase. Der Hauptvorteil des Spiralmodells besteht darin, dass die ersten Testergebnisse unmittelbar nach den Ergebnissen der Tests in der dritten Stufe jedes Zyklus erscheinen, was zur korrekten Qualitätsbewertung beiträgt. Es ist jedoch wichtig zu bedenken, dass dieses Modell ziemlich teuer sein kann und nicht für kleine Projekte geeignet ist.

Obwohl dieses Modell ziemlich alt ist, bleibt es sowohl für Tests als auch für die Entwicklung nützlich. Außerdem, Hauptziel Viele Methoden zum Testen von Software, einschließlich des Spiralmodells, haben sich in letzter Zeit geändert. Wir verwenden sie nicht nur, um Fehler in Anwendungen zu finden, sondern auch, um die Gründe herauszufinden, die sie verursacht haben. Dieser Ansatz hilft Entwicklern, effizienter zu arbeiten und Fehler schnell zu beheben.

Lesen Sie mehr über das Spiralmodell im vorherigen Blogbeitrag..

Agil

Agile Softwareentwicklungsmethodik und Softwaretest können als eine Reihe von Ansätzen beschrieben werden, die sich auf die Verwendung interaktiver Entwicklung, die dynamische Bildung von Anforderungen und die Sicherstellung ihrer Umsetzung als Ergebnis ständiger Interaktion innerhalb einer selbstorganisierenden Organisation konzentrieren. Arbeitsgruppe. Die meisten agilen Softwareentwicklungsmethoden zielen darauf ab, Risiken durch Entwicklung in kurzen Iterationen zu minimieren. Eines der Hauptprinzipien dieser flexiblen Strategie ist die Fähigkeit, schnell auf mögliche Änderungen zu reagieren, anstatt sich auf eine langfristige Planung zu verlassen.

Erfahren Sie mehr über Agilität(Hinweis - Artikel auf Englisch).

Extreme Programmierung (XP, Extreme Programming)

Extreme Programming ist ein Beispiel für agile Softwareentwicklung. Eine Besonderheit dieser Methodik ist das „Pair Programming“, eine Situation, in der ein Entwickler am Code arbeitet, während sein Kollege den geschriebenen Code ständig überprüft. Der Softwaretestprozess ist sehr wichtig, da er bereits beginnt, bevor die erste Codezeile geschrieben wird. Jedes Anwendungsmodul sollte einen Komponententest haben, damit die meisten Fehler in der Codierungsphase behoben werden können. Eine weitere Besonderheit ist, dass der Test den Code bestimmt und nicht umgekehrt. Das bedeutet, dass ein bestimmter Codeabschnitt nur dann als vollständig betrachtet werden kann, wenn alle Tests bestanden wurden. Andernfalls wird der Code abgelehnt.

Die Hauptvorteile dieser Methodik sind ständige Tests und kurze Releases, was zur Gewährleistung beiträgt hohe Qualität Code.

Gedränge

Scrum – Teil der Agile-Methodik, ein iterativer inkrementeller Rahmen, der geschaffen wurde, um den Softwareentwicklungsprozess zu verwalten. Nach Scrum-Prinzipien sollte das Testteam an folgenden Schritten beteiligt sein:

• Teilnahme an der Scrum-Planung
• Unit-Testing-Unterstützung
• User-Story-Tests
• Arbeiten Sie mit dem Kunden und dem Product Owner zusammen, um Akzeptanzkriterien festzulegen
• Bereitstellung automatisierter Tests

Darüber hinaus sollten QA-Mitglieder wie andere Teammitglieder bei allen täglichen Besprechungen anwesend sein, um zu besprechen, was gestern getestet und getan wurde, was heute getestet wird, sowie den Gesamtfortschritt der Tests.

Gleichzeitig führen die Prinzipien der agilen Methodik in Scrum zur Herausbildung von Besonderheiten:

• Die Aufwandsschätzung für jede User Story ist ein Muss
• Der Tester muss auf die Anforderungen achten, da sie sich ständig ändern können.
• Das Risiko einer Regression steigt mit häufigen Codeänderungen.
• Gleichzeitige Planung und Durchführung von Tests
• Missverständnisse zwischen Teammitgliedern, falls die Anforderungen des Kunden nicht ganz klar sind

Erfahren Sie mehr über die Scrum-Methodik aus einem früheren Artikel..

Fazit

Abschließend ist festzuhalten, dass die Praxis der Verwendung der einen oder anderen Softwaretestmethodik heute einen multiversalen Ansatz impliziert. Mit anderen Worten, Sie sollten nicht erwarten, dass eine Methode für alle Arten von Projekten geeignet ist. Die Wahl eines davon hängt von einer Vielzahl von Aspekten ab, wie z. B. der Art des Projekts, Kundenanforderungen, Fristen und vielen anderen. Aus Sicht des Softwaretestens ist es üblich, dass einige Methoden früh in der Entwicklung mit dem Testen beginnen, während es bei anderen üblich ist, zu warten, bis das System fertig ist.

Egal, ob Sie Hilfe bei der Softwareentwicklung oder beim Testen benötigen, ein engagiertes Team von Entwicklern und QA-Ingenieuren steht bereit.

Testen von Webdiensten

Die meisten Der beste Weg Bewerten Sie, ob wir das Produkt gut getestet haben – Analysieren Sie übersehene Mängel. Diejenigen, mit denen unsere Benutzer, Implementierer und Unternehmen konfrontiert sind. An ihnen kann man vieles ablesen: Was wir nicht gründlich genug geprüft haben, welchen Bereichen des Produkts mehr Aufmerksamkeit geschenkt werden sollte, wie hoch der Prozentsatz an Auslassungen im Allgemeinen ist und wie dynamisch sich die Änderungen entwickeln. Mit dieser Metrik (vielleicht die häufigste beim Testen) ist alles in Ordnung, aber ... Als wir das Produkt veröffentlichten und von den übersehenen Fehlern erfuhren, war es möglicherweise zu spät: Auf Habré erschien ein wütender Artikel über uns, Mitbewerber sind Kritik breitet sich rasant aus, Kunden haben das Vertrauen in uns verloren, Management ist unzufrieden.

Um dies zu verhindern, versuchen wir in der Regel, die Qualität der Tests vor der Veröffentlichung zu bewerten: Wie gut und gründlich prüfen wir das Produkt? Welche Bereiche werden nicht beachtet, wo liegen die Hauptrisiken, welche Fortschritte? Und um all diese Fragen zu beantworten, werten wir die Testabdeckung aus.

Warum evaluieren?

Alle Bewertungsmetriken sind Zeitverschwendung. Zu diesem Zeitpunkt können Sie testen, Fehler starten und Autotests vorbereiten. Welchen magischen Vorteil ziehen wir aus Testabdeckungsmetriken, um Testzeit zu opfern?

1. Finden Sie Ihre Schwachstellen. Natürlich brauchen wir das? nicht nur um zu trauern, sondern um zu wissen, wo Verbesserungen erforderlich sind. Welche Funktionsbereiche werden nicht durch Tests abgedeckt? Was haben wir nicht geprüft? Wo liegen die größten Risiken für fehlende Fehler?
2. Selten erhalten wir eine 100%ige Abdeckung durch Evaluationsergebnisse. Was ist zu verbessern? Wohin gehen? Wie hoch ist der Prozentsatz jetzt? Wie können wir es durch eine beliebige Aufgabe erhöhen? Wie schnell kommen wir auf 100? All diese Fragen bringen Transparenz und Klarheit in unseren Prozess., und die Antworten darauf werden durch die Abdeckungsschätzung gegeben.
3. Fokus der Aufmerksamkeit. Nehmen wir an, unser Produkt hat ungefähr 50 verschiedene Funktionsbereiche. herauskommen eine neue Version, und wir beginnen mit dem Testen des ersten von ihnen und finden dort Tippfehler und Schaltflächen, die sich um ein paar Pixel verschoben haben, und andere Kleinigkeiten ... Und jetzt ist die Zeit zum Testen vorbei, und diese Funktionalität wurde im Detail getestet. Und die restlichen 50? Die Abdeckungsbewertung ermöglicht es uns, Aufgaben basierend auf aktuellen Realitäten und Fristen zu priorisieren.

Wie bewerten?

Bevor Sie eine Metrik implementieren, ist es wichtig zu entscheiden, wie Sie sie verwenden möchten. Beginnen Sie mit der Beantwortung genau dieser Frage – höchstwahrscheinlich verstehen Sie sofort, wie Sie diese am besten berechnen. Und ich werde in diesem Artikel nur einige Beispiele und meine Erfahrungen darüber teilen, wie dies getan werden kann. Nicht um blind Lösungen zu kopieren, sondern damit sich Ihre Vorstellungskraft auf diese Erfahrung stützen und eine für Sie ideale Lösung durchdenken kann.

Bewertung der Anforderungsabdeckung durch Tests

Nehmen wir an, Sie haben Analysten in Ihrem Team, die ihre Zeit nicht umsonst verbringen. Arbeitszeit. Basierend auf den Ergebnissen ihrer Arbeit wurden Anforderungen im RMS (Requirements Management System) erstellt - HP QC, MS TFS, IBM Doors, Jira (mit zusätzlichen Plugins) usw. In diesem System stellen sie Anforderungen, die den Anforderungen für die Anforderungen entsprechen (sorry für die Tautologie). Diese Anforderungen sind atomar, nachvollziehbar, spezifisch… Im Allgemeinen ideale Bedingungen zum Testen. Was können wir in einem solchen Fall tun? Wenn Sie einen skriptbasierten Ansatz verwenden, verknüpfen Sie Anforderungen und Tests. Wir führen Tests im selben System durch, stellen eine Anforderungstestverbindung her und können jederzeit einen Bericht darüber einsehen, welche Anforderungen Tests haben, welche nicht, wann und mit welchem ​​Ergebnis diese Tests bestanden wurden.
Wir bekommen eine Abdeckungskarte, wir decken alle ungedeckten Anforderungen ab, alle sind glücklich und zufrieden, wir übersehen keine Fehler ...

Okay, gehen wir zurück auf die Erde. Höchstwahrscheinlich haben Sie keine detaillierten Anforderungen, sie sind nicht atomar, einige der Anforderungen gehen im Allgemeinen verloren und es bleibt keine Zeit, jeden Test oder zumindest jeden zweiten zu dokumentieren. Sie können verzweifeln und weinen, oder Sie können zugeben, dass Testen ein Kompensationsprozess ist, und je schlechter wir mit Analytik und Entwicklung im Projekt sind, desto mehr sollten wir selbst versuchen, die Probleme anderer Prozessbeteiligter zu kompensieren. Lassen Sie uns die Probleme separat analysieren.

Problem: Anforderungen sind nicht atomar.

Auch Analysten sündigen manchmal mit einem Salat im Kopf, und das ist meist mit Problemen des gesamten Projekts behaftet. Beispiel: Sie entwickeln einen Texteditor und haben möglicherweise (unter anderem) zwei Anforderungen in Ihrem System: „HTML-Formatierung muss unterstützt werden“ und „Beim Öffnen einer Datei in einem nicht unterstützten Format wird ein Popup-Fenster mit einer Frage angezeigt muss auftauchen." Wie viele Tests sind für den grundlegenden Nachweis der 1. Anforderung erforderlich? Und zum 2.? Der Unterschied in den Antworten beträgt höchstwahrscheinlich etwa das Hundertfache !!! Wir können nicht sagen, dass dies ausreicht, wenn es mindestens 1 Test für die 1. Anforderung gibt - aber für die 2. höchstwahrscheinlich vollständig.

Ein Anforderungstest garantiert uns also überhaupt nichts! Was bedeutet unsere Reichweitenstatistik in diesem Fall? Fast nichts! Wir müssen uns entscheiden!

1. In diesem Fall kann die automatische Berechnung der Anforderungsabdeckung durch Tests entfernt werden – sie trägt immer noch keine semantische Last.
2. Für jede Anforderung, beginnend mit der höchsten Priorität, bereiten wir Tests vor. Bei der Vorbereitung analysieren wir, welche Tests für diese Anforderung erforderlich sind, wie viele werden ausreichen? Wir führen eine vollwertige Testanalyse durch und wischen nicht beiseite „es gibt einen Test, aber okay“.
3. Je nach verwendetem System exportieren/laden wir Tests nach Bedarf hoch und… wir testen diese Tests! Sind sie genug? Idealerweise sollten solche Tests natürlich mit einem Analysten und einem Entwickler dieser Funktionalität durchgeführt werden. Drucken Sie die Tests aus, sperren Sie Ihre Kollegen in den Besprechungsraum und lassen Sie nicht los, bis sie sagen „Ja, diese Tests reichen“ (dies geschieht nur mit schriftlicher Vereinbarung, wenn diese Worte zur Abmeldung gesprochen werden, auch ohne Analyse der Tests. Während eines mündlichen Gesprächs schütten Ihre Kollegen eine Wannenkritik, verpasste Tests, falsch verstandene Anforderungen usw. aus - das ist nicht immer angenehm, aber zum Testen sehr nützlich!)
4. Nach Abschluss der Tests on Demand und Vereinbarung der Vollständigkeit kann diese Anforderung im System mit dem Status „durch Tests abgedeckt“ gekennzeichnet werden. Diese Information bedeutet viel mehr als "hier gibt es mindestens 1 Test".

Natürlich erfordert ein solcher Vereinbarungsprozess vor allem am Anfang viel Ressourcen und Zeit, bis sich die Praxis entwickelt hat. Führen Sie daher nur hochpriore Anforderungen und neue Verbesserungen daran durch. Verschärfen Sie im Laufe der Zeit die restlichen Anforderungen, und alle werden glücklich sein! Aber ... und wenn es gar keine Auflagen gibt?

Problem: Es gibt überhaupt keine Anforderungen.

Sie fehlen im Projekt, sie werden mündlich besprochen, jeder macht was er will/kann und wie er es versteht. Wir testen das gleiche. Dadurch bekommen wir nicht nur beim Testen und Entwickeln jede Menge Probleme, sondern auch anfänglich fehlerhafte Implementierungen von Features – wir wollten etwas ganz anderes! Hier kann ich die Option „Anforderungen selbst definieren und dokumentieren“ empfehlen und habe diese Strategie sogar ein paar Mal in meiner Praxis angewendet, aber in 99% der Fälle gibt es keine solchen Ressourcen im Testteam – also lassen Sie uns viel weniger gehen ressourcenintensiver Weg:

1. Erstellen Sie eine Funktionsliste. Sami! In Form eines Google-Tablets, im PBI-Format in TFS - beliebig wählen, solange es kein Textformat ist. Wir müssen noch Status sammeln! Wir nehmen alle Funktionsbereiche des Produkts in diese Liste auf und versuchen, eine allgemeine Dekompositionsebene zu wählen (Sie können Softwareobjekte oder Benutzerskripts oder Module oder Webseiten oder API-Methoden oder Bildschirmformulare schreiben ... .) - aber nicht alles auf einmal ! EIN Dekompositionsformat, das es Ihnen einfacher und klarer macht, wichtige Dinge nicht zu verpassen.
2. Wir koordinieren die VOLLSTÄNDIGKEIT dieser Liste mit Analysten, Entwicklern, Unternehmen, innerhalb unseres Teams ... Versuchen Sie alles zu tun, um keine wichtigen Teile des Produkts zu verlieren! Wie tief die Analyse ist, liegt bei Ihnen. In meiner Praxis gab es nur wenige Produkte, für die wir mehr als 100 Seiten in der Tabelle erstellt haben, und das waren Riesenprodukte. Meistens sind 30-50 Zeilen ein erreichbares Ergebnis für eine sorgfältige Weiterverarbeitung. In einem kleinen Team ohne dedizierte Testanalysten mehr fichelista-Elemente wären zu schwierig zu warten.
3. Danach gehen wir die Prioritäten durch und verarbeiten jede Zeile der Fichelliste wie im oben beschriebenen Anforderungsabschnitt. Wir schreiben Tests, diskutieren, einigen uns auf Suffizienz. Wir markieren die Stati, für welche Features es genug Tests gibt. Wir erhalten Status, Fortschritt und Erweiterung der Tests durch die Kommunikation mit dem Team. Alle sind glücklich!

Aber... Was ist, wenn die Anforderungen gepflegt werden, aber nicht in einem nachvollziehbaren Format?

Problem: Anforderungen sind nicht nachvollziehbar.

Es gibt eine riesige Menge an Dokumentation zum Projekt, Analysten tippen mit einer Geschwindigkeit von 400 Zeichen pro Minute, Sie haben Spezifikationen, technische Spezifikationen, Anweisungen, Referenzen (meistens geschieht dies auf Kundenwunsch), und all dies fungiert als Anforderungen, und alles ist schon lange im Projekt Verwirrt, wo Sie nach welchen Informationen suchen sollen?
Wiederholen Sie den vorherigen Abschnitt und helfen Sie dem gesamten Team beim Aufräumen!

1. Wir erstellen eine Featureliste (siehe oben), jedoch ohne detaillierte Beschreibung der Anforderungen.
2. Für jede Funktion sammeln wir Links zu technischen Spezifikationen, Spezifikationen, Anweisungen und anderen Dokumenten.
3. Wir gehen nach Prioritäten, bereiten Tests vor und vereinbaren deren Vollständigkeit. Alles ist beim Alten, nur dank der Zusammenfassung aller Dokumente auf einer Platte erhöhen wir den einfachen Zugriff darauf, transparente Status und Konsistenz der Tests. Am Ende ist alles super und alle sind glücklich!

Aber… Nicht mehr lange… Anscheinend haben Analysten in der letzten Woche 4 verschiedene Spezifikationen aktualisiert, basierend auf Kundenanfragen!!!

Problem: Die Anforderungen ändern sich ständig.

Natürlich wäre es schön, ein festes System zu testen, aber unsere Produkte sind normalerweise live. Der Kunde hat nach etwas gefragt, etwas hat sich außerhalb unseres Produktes in der Gesetzgebung geändert, und irgendwo haben Analysten einen vorletzten Analysefehler gefunden... Anforderungen leben ihr eigenes Leben! Was zu tun ist?

1. Angenommen, Sie haben bereits Links zu TK und Spezifikationen in Form einer Feature-Liste, PBI, Anforderungen, Wiki-Notizen usw. gesammelt. Angenommen, Sie haben bereits Tests für diese Anforderungen. Und jetzt ändern sich die Anforderungen! Dies kann eine Änderung im RMS oder eine Aufgabe im TMS (Task Management System) oder ein Brief in der Post bedeuten. In jedem Fall führt es zum gleichen Ergebnis: Ihre Tests sind veraltet! Oder sie sind irrelevant. Dies bedeutet, dass sie aktualisiert werden müssen (Abdeckung durch Tests alte Version Produkt wird irgendwie nicht sehr beachtet, oder?)
2. In der Featureliste, im RMS, im TMS (Test Management System - testrails, sitechco, etc) müssen Tests sofort und unbedingt als irrelevant markiert werden! In HP QC oder MS TFS kann dies automatisch erfolgen, wenn Anforderungen aktualisiert werden, und in einem Google-Tablet oder Wiki müssen Sie die Stifte ablegen. Aber Sie sollten gleich sehen: Die Tests sind irrelevant! Das bedeutet, dass wir auf einen vollständigen Neupfad warten: aktualisieren, die Testanalyse erneut ausführen, die Tests neu schreiben, den Änderungen zustimmen und erst danach das Feature/die Anforderung erneut als „durch Tests abgedeckt“ markieren.

In diesem Fall erhalten wir alle Vorteile der Testabdeckungsbewertung, und das sogar in der Dynamik! Alle sind glücklich!!! Aber…
Aber Sie haben sich so sehr auf die Arbeit mit Anforderungen konzentriert, dass Sie jetzt nicht genug Zeit haben, um die Tests zu testen oder zu dokumentieren. Meiner Meinung nach (und es gibt Platz für einen religiösen Streit!) sind Auflagen wichtiger als Tests, und das ist auch besser so! Zumindest sind sie in Ordnung, und das gesamte Team weiß Bescheid, und die Entwickler tun genau das, was nötig ist. ABER FÜR DIE DOKUMENTATION VON TESTS IST KEINE ZEIT!

Problem: Nicht genug Zeit, um Tests zu dokumentieren.

Tatsächlich kann die Ursache dieses Problems nicht nur Zeitmangel sein, sondern auch Ihre ganz bewusste Entscheidung, sie nicht zu dokumentieren (wir mögen es nicht, wir vermeiden die Pestizidwirkung, das Produkt ändert sich zu oft usw.). Aber wie ist die Testabdeckung in diesem Fall zu bewerten?

1. Sie benötigen weiterhin Anforderungen als vollständige Anforderungen oder als Feature-Liste, sodass einer der obigen Abschnitte, abhängig von der Arbeit der Analysten am Projekt, weiterhin erforderlich ist. Haben Sie eine Anforderungs-/Funktionsliste?
2. Wir beschreiben und einigen uns mündlich auf eine kurze Teststrategie, ohne spezifische Tests zu dokumentieren! Diese Strategie kann in einer Tabellenspalte, auf einer Wiki-Seite oder in einer Anforderung im RMS spezifiziert werden und muss wiederum vereinbart werden. Als Teil dieser Strategie werden Überprüfungen auf unterschiedliche Weise durchgeführt, aber Sie werden wissen: wann das letzte Mal getestet und mit welcher Strategie? Und das, sehen Sie, ist auch nicht schlecht! Und alle werden glücklich sein.

Aber… Was sonst "aber"? Die???

Sprich, wir werden alles umrunden, und mögen hochwertige Produkte mit uns sein!

| Unterrichtsplanung für das Schuljahr | Hauptphasen der Modellierung

Lektion 2
Hauptphasen der Modellierung

Durch das Studium dieses Themas lernen Sie:

Was ist Modellieren;
- was als Prototyp für die Modellierung dienen kann;
- Welchen Stellenwert hat die Modellierung in der menschlichen Tätigkeit?
- Was sind die Hauptphasen der Modellierung?
- was ist ein Computermodell;
Was ist ein computerexperiment.

Computerexperiment

Um neuen Designentwicklungen Leben einzuhauchen, neue technische Lösungen in die Produktion einzuführen oder neue Ideen zu testen, braucht es ein Experiment. Ein Experiment ist ein Experiment, das mit einem Objekt oder Modell durchgeführt wird. Es besteht darin, einige Aktionen auszuführen und zu bestimmen, wie die experimentelle Probe auf diese Aktionen reagiert.

In der Schule machst du Experimente in den Fächern Biologie, Chemie, Physik, Erdkunde.

Beim Testen neuer Produktmuster in Unternehmen werden Experimente durchgeführt. Üblicherweise wird dazu ein speziell erstellter Aufbau verwendet, der es ermöglicht, ein Experiment unter Laborbedingungen durchzuführen, oder das reale Produkt selbst wird allen möglichen Tests unterzogen (ein Full-Scale-Experiment). Um beispielsweise die Leistungseigenschaften einer Einheit oder Baugruppe zu untersuchen, wird sie in einen Thermostaten gelegt, in speziellen Kammern eingefroren, auf Vibrationsständern getestet, fallen gelassen usw. Es ist gut, wenn es sich um eine neue Uhr oder einen Staubsauger handelt - der Verlust bei der Zerstörung ist nicht groß. Was, wenn es ein Flugzeug oder eine Rakete ist?

Labor- und Großversuche erfordern große Materialkosten und Zeit, aber ihre Bedeutung ist dennoch sehr groß.

Mit Entwicklung Computertechnologie Eine neue einzigartige Forschungsmethode erschien - ein Computerexperiment. In vielen Fällen helfen Computersimulationsstudien und ersetzen manchmal sogar Versuchsmuster und Prüfstände. Die Phase der Durchführung eines Computerexperiments umfasst zwei Phasen: die Erstellung eines Experimentplans und die Durchführung einer Studie.

Versuchsplan

Der Versuchsplan sollte den Arbeitsablauf mit dem Modell klar wiedergeben. Der erste Schritt in einem solchen Plan ist immer, das Modell zu testen.

Testen ist der Prozess der Überprüfung der Korrektheit des konstruierten Modells.

Test - eine Reihe von Anfangsdaten, mit denen Sie die Richtigkeit der Konstruktion des Modells bestimmen können.

Um sicher zu sein, dass die erhaltenen Modellierungsergebnisse korrekt sind, ist es notwendig: ♦ den entwickelten Algorithmus zum Erstellen des Modells zu überprüfen; ♦ sicherstellen, dass das konstruierte Modell die Eigenschaften des Originals, die in der Simulation berücksichtigt wurden, korrekt widerspiegelt.

Zur Überprüfung der Korrektheit des Modellkonstruktionsalgorithmus wird ein Testsatz von Ausgangsdaten verwendet, bei dem das Endergebnis im Voraus bekannt oder auf andere Weise vorgegeben ist.

Wenn Sie beispielsweise Berechnungsformeln in der Modellierung verwenden, müssen Sie mehrere Optionen für die Ausgangsdaten auswählen und diese „manuell“ berechnen. Dies sind Testobjekte. Wenn das Modell erstellt wird, testen Sie mit denselben Eingaben und vergleichen die Ergebnisse der Simulation mit den Schlussfolgerungen, die Sie durch Berechnung erhalten haben. Wenn die Ergebnisse übereinstimmen, ist der Algorithmus korrekt entwickelt, wenn nicht, muss die Ursache für ihre Abweichung gesucht und beseitigt werden. Testdaten spiegeln möglicherweise überhaupt nicht die reale Situation wider und tragen möglicherweise keinen semantischen Inhalt. Die während des Testprozesses erzielten Ergebnisse können Sie jedoch dazu veranlassen, über eine Änderung des ursprünglichen Informations- oder Zeichenmodells nachzudenken, vor allem in dem Teil davon, in dem der semantische Inhalt festgelegt ist.

Um sicherzustellen, dass das konstruierte Modell die Eigenschaften des Originals widerspiegelt, die in der Simulation berücksichtigt wurden, ist es notwendig, ein Testbeispiel mit realen Quelldaten auszuwählen.

Nachforschungen anstellen

Wenn Sie nach dem Testen Vertrauen in die Korrektheit des konstruierten Modells haben, können Sie direkt mit der Studie fortfahren.

Der Plan sollte ein Experiment oder eine Reihe von Experimenten umfassen, die den Zielen der Simulation entsprechen. Jedes Experiment muss von einem Verständnis der Ergebnisse begleitet werden, das als Grundlage für die Analyse der Ergebnisse der Modellierung und das Treffen von Entscheidungen dient.

Das Schema zur Vorbereitung und Durchführung eines Computerexperiments ist in Abbildung 11.7 dargestellt.

Reis. 11.7. Schema eines Computerexperiments

Analyse der Simulationsergebnisse

Das ultimative Ziel der Modellierung ist es, eine Entscheidung zu treffen, die auf der Grundlage einer umfassenden Analyse der Simulationsergebnisse entwickelt werden sollte. Diese Phase ist entscheidend - entweder Sie setzen das Studium fort oder beenden es. Abbildung 11.2 zeigt, dass die Ergebnisanalysephase nicht autonom existieren kann. Die gewonnenen Schlussfolgerungen tragen oft zu einer weiteren Versuchsreihe und manchmal zu einer Änderung des Problems bei.

Die Ergebnisse aus Tests und Experimenten dienen als Grundlage für die Entwicklung einer Lösung. Wenn die Ergebnisse nicht den Zielen der Aufgabe entsprechen, bedeutet dies, dass in den vorherigen Phasen Fehler gemacht wurden. Dies kann entweder eine falsche Problemstellung oder eine zu vereinfachte Konstruktion eines Informationsmodells oder eine erfolglose Wahl einer Modellierungsmethode oder -umgebung oder eine Verletzung technologischer Methoden beim Erstellen eines Modells sein. Wenn solche Fehler identifiziert werden, muss das Modell korrigiert werden, dh zu einer der vorherigen Stufen zurückkehren. Der Prozess wird wiederholt, bis die Ergebnisse des Experiments den Zielen der Simulation entsprechen.

Die Hauptsache ist, dass der erkannte Fehler auch das Ergebnis ist. Wie das Sprichwort sagt, lernt man aus seinen Fehlern. Auch der große russische Dichter A. S. Puschkin schrieb darüber:

Oh, wie viele wundervolle Entdeckungen wir haben
Bereiten Sie den Geist der Erleuchtung vor
Und Erfahrung, der Sohn schwieriger Fehler,
Und Genie, Freund der Paradoxien,
Und Zufall, Gott ist der Erfinder...

Kontrollfragen und Aufgaben

1. Was sind die zwei Haupttypen von Modellierungsproblemen?

2. In dem bekannten „Problembuch“ von G. Oster steht folgendes Problem:

Die böse Hexe, die unermüdlich arbeitet, verwandelt täglich 30 Prinzessinnen in Raupen. Wie viele Tage wird sie brauchen, um 810 Prinzessinnen in Raupen zu verwandeln? Wie viele Prinzessinnen müssten pro Tag in Raupen verwandelt werden, um die Arbeit in 15 Tagen zu erledigen?
Welche Frage lässt sich der Art „Was passiert, wenn …“ zuordnen und welche – der Art „Wie macht man das …“?

3. Nennen Sie die bekanntesten Ziele der Modellierung.

4. Formalisieren Sie das spielerische Problem aus G. Osters „Problembuch“:

Aus zwei 27 km voneinander entfernten Ständen sprangen zwei kampflustige Hunde gleichzeitig aufeinander zu. Der erste läuft mit einer Geschwindigkeit von 4 km / h und der zweite mit 5 km / h.
Wie lange wird der Kampf beginnen?

5. Nennen Sie möglichst viele Merkmale des Objekts „Paar Schuhe“. Erstellen Sie ein Informationsmodell eines Objekts für verschiedene Zwecke:
■ Auswahl an Wanderschuhen;
■ Auswahl eines geeigneten Schuhkartons;
■ Kauf von Schuhpflegecreme.

6. Welche Eigenschaften eines Teenagers sind für eine Berufswahlempfehlung wesentlich?

7. Warum ist der Computer in der Simulation weit verbreitet?

8. Nennen Sie die Ihnen bekannten Werkzeuge der Computermodellierung.

9. Was ist ein Computerexperiment? Gib ein Beispiel.

10. Was ist Modelltest?

11. Welche Fehler treten im Modellierungsprozess auf? Was ist zu tun, wenn ein Fehler gefunden wird?

12. Was ist die Analyse von Simulationsergebnissen? Welche Schlussfolgerungen werden normalerweise gezogen?