Software-QA/Testing: Testing mit Demonstration lernen

1. Übersicht: Hallo und willkommen zu meinem neuen Kurs , der vor Kurzem für Qualitätssicherungspersonal entwickelt wurde , das eine AS-Zertifizierung erwerben möchte , oder für diejenigen, die mehr über das QA-Konzept erfahren möchten. Dieser Kurs ist also in allen Videos enthalten. Mein Fokus lag darauf, alle Themen zu behandeln, die in IS als Grundlagen-Silben behandelt werden In den IST-Grundlagenlaboren gibt es also sechs Kapitel. Kapitel eins befasst sich mit den Grundlagen des Testens, in dem ich alle grundlegenden Konzepte im Zusammenhang mit dem Testen erörtert habe alle grundlegenden Konzepte im Zusammenhang mit dem In Kapitel zwei geht es also um den Entwicklungslebenszyklus und den Testlebenszyklus. Dann sind wir zu Kapitel drei übergegangen, dem es um statische Tests geht. Kapitel vier befasste sich mit Testtechniken. Wir haben verschiedene Testtechniken besprochen, White-Box, Blackbox, erfahrungsbasiert, kichernd und so weiter In Kapitel fünf geht es um die Organisation von Tests. Wir haben alles besprochen der Organisation des Tests, seiner Planung und der Testvorbereitung zu tun hat. All diese Dinge werden also besprochen. Dann gehen wir zu Kapitel sechs über, dem letzten Kapitel in diesem Kurs, dem Sport zum Testen. Also besprechen wir, wie wir das beste Tool auswählen können. Was sollten wir bei der Auswahl des Tools beachten ? Weil nicht jedes Tool in jeder Umgebung geeignet ist. Damit haben wir all diese Dinge abgeschlossen. Also melde dich für Happy Testing an. 2. Einführung in SQA: Hallo. Okay. In dieser Sitzung werden wir über Qualitätssicherung sprechen, aber vorher wollen wir darüber sprechen, was Qualität ist. Wenn wir also über Qualität sprechen, wenn wir darüber sprechen, wann wir sagen, dass dieses Produkt Qualität ist, hohe Qualität. Das heißt also, es ist exzellent, es ist überlegen. Es hat eine gewisse Klasse, es ist herausragend. Es hat einen gewissen Wert für unsere Kunden, und es lohnt sich Das sind also die Synonyme für also was bedeutet gute Qualität oder schlechte Qualität? Wenn wir uns also das Tonium von Qualität und Minderwertigkeit ansehen , so sind minderwertige Produkte nicht von guter Also Produkte, die minderwertig sind, die nicht brauchbar sind , haben keinen Wert Das sind also Produkte oder Dienstleistungen, die von geringer Qualität sind. Niemand möchte also Produkte von geringer Qualität kaufen. In Ihrem Leben werden Sie auf viele Produkte stoßen. Wenn jemand sagen würde, dass jemand verkauft verkauft, und sagen würde, dass dieses Produkt von geringer Qualität ist, würde es niemand kaufen. Die Leute würden also gerne das Produkt oder die Dienstleistung kaufen , die von hoher Qualität sind. Dies sind also einige der Begriffe , die in unserem täglichen Leben allgemein verwendet werden, wenn wir etwas kaufen , z. B. wenn wir einen Fernseher, einen Kühlschrank oder ähnliches kaufen. Lassen Sie uns also über die Softwarequalität sprechen. Diese Begriffe beziehen sich also auch auf die Softwarequalität. Wenn wir über Software sprechen, sprechen wir insbesondere über das Softwareprodukt oder die Softwaredienstleistung. Lassen Sie uns also diese Definition besprechen, die ich als Definition eins aufgeführt habe. Das bedeutet, dass die geringe Anzahl von Fehlern, wenn sie eingesetzt werden, täglich gegen Null geht. Das heißt, wenn wir Softwareprodukte oder Dienstleistungen anbieten, sollte es bei der Bereitstellung keinen Fehler geben. Das sollten fehlerfreie Produkte sein. Software wird also definitiv von Menschen entwickelt und Menschen machen Fehler Es kann Fehler in der Software geben. Deshalb versuchen wir, diese Fehler so weit wie möglich zu minimieren. So können wir unseren Kunden qualitativ hochwertige Softwareprodukte oder Dienstleistungen anbieten. Lassen Sie uns also über die nächste Definition sprechen, die sich auf die Mehrheit der von uns befragten Kunden mit hoher Benutzerzufriedenheit bezieht. Wenn unsere Kunden zufrieden sind, geben sie uns gutes Feedback. Sie beziehen sich auf andere Menschen. Wenn also die Mehrheit unserer Kunden zufrieden ist, dann machen wir gute Arbeit. Wir produzieren qualitativ hochwertige Produkte oder Softwaredienstleistungen. Diese Definitionen sind also speziell auf die Softwarequalität zugeschnitten. Okay? Also in Definition drei, eine Struktur, die Fehlbehebungen oder das Auftreten neuer Fehler bei Reparaturen minimieren kann . Unsere Softwarestruktur sollte also so beschaffen sein , dass Fehlerkorrekturen minimiert werden können. Mann, wann immer es ein Problem gibt, beheben wir das Problem, dann sollte es auch nicht auf die anderen Module auswirken. Deshalb machen wir Regressionstests, wir testen das ganze Zeug erneut Wir machen auch Automatisierung. Also, um unsere Taschen zu minimieren und all diese Probleme zu beheben. Lassen Sie uns also über Definition vier sprechen, nämlich effektive Kunden für den Fall, dass ein Problem auftritt. Immer wenn es ein Problem gibt, ruft der Kunde an, um sich zu wundern. Wonder sollte also reagieren und Anbieter sollten umgehend reagieren, um das Problem zu beheben, denn effektiver Kundensport ist für den Kunden sehr wichtig. Weil sie zahlen , nutzen sie unseren Service. Sie bezahlen ihren Rettungsschwimmer. Unser Geschäft läuft also wegen unseres Kunden. Kunden sollten also glücklich sein und wir sollten sie unterstützen. Lassen Sie uns also über Definition fünf sprechen, schnelle Reparatur von Defekten, insbesondere bei SWAT-Defekten Wenn ein Kunde anruft, gibt es ein Problem, und wenn es ein dringendes Problem gibt, zum Beispiel das Sicherheitsproblem, gibt es so etwas, etwas geht kaputt, etwas funktioniert nicht Dann ist das ein großer SWAT-Bug. Es sollte dringend behoben werden. Und wir sollten nicht auf Arbeitstage warten. Wir sollten das so schnell wie möglich in kürzester Zeit beheben . Okay. Nun, das sind einige technische Definitionen. Lassen Sie uns nun über einen Sinn für Ästhetik sprechen , der hinter der Abwesenheit von Mängeln steht. Ich meine also Qualitätsprodukt, egal ob es sich um Software, Hardware oder irgendein Produkt handelt. Das heißt, das ist wunderschön. Dann hat es Sinn für Schönheit, Sinn für Zweckmäßigkeit. Wenn es unseren Zweck nicht erfüllt, den Zweck unserer Kunden nicht erfüllt. Das bedeutet also, dass dieses Produkt von geringer Qualität ist. Ein Sinn für Eleganz , der über das bloße Fehlen von Strömungen hinausgeht , hat wohlgeformte Anforderungen. Hochwertige Produkte bedeuten also, dass sie den Kundenanforderungen entsprechen und dass gut formulierte Anforderungen bearbeitet, dokumentiert und dem Kletterer mitgeteilt werden. Unser Produkt oder unsere Dienstleistung erfüllt also die Kundenanforderungen. Also das steckte fast hinter den verärgerten Artefakten. Also, wenn wir jetzt über die Software-Qualitätssicherung sprechen die Software-Qualitätssicherung meinen wir, dass wir unseren Kunden und Klienten die Sicherheit geben . Der Begriff Softwarequalitätssicherung würde also bedeuten , dass der Softwarestipendium von hoher Qualität ist. Wir garantieren also bei der Sicherung der Softwarequalität, wir garantieren, dass unser Softwareprodukt oder unsere Dienstleistung von hoher Qualität ist, und wir ergreifen einige Präventivmaßnahmen, wir ergreifen einige präventive Maßnahmen. Fassen Sie nun die Dinge zusammen , die wir in dieser Sitzung besprochen haben. Zunächst habe ich darüber gesprochen, was Qualität ist. Und, wissen Sie, die hochwertigen Produkte, die für unsere Kunden einen gewissen Wert haben. Wenn wir also über Software-Qualitätssicherung sprechen, dann bedeutet das, dass unsere Software den Zweck erfüllt und die Anforderungen gut formuliert dokumentiert sind und unsere Kunden mit unserem Service und unseren Produkten zufrieden sind . Und bei der Qualitätssicherung von Software garantieren wir unseren Kunden, dass wir qualitativ hochwertige Produkte herstellen. Das ist es. Okay. 3. Grundlagen des Testens: Okay. Willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir uns Grundlagen des Testens befassen. In diesem Kapitel, Grundlagen des Testens, haben wir folgende Inhalte. Was ist Testen? Warum ist Testen notwendig? Sieben Testprinzipien, Testprozess in der Testpsychologie. Also, was ist Testen? Allgemein wird angenommen, dass Tests auf die Ausführung beschränkt sind, aber das ist falsch, okay? Testaktivitäten bestehen auch vor und nach der Testausführung. Also andere Aktivitäten während des Lebenszyklus der Softwareentwicklung. Tests tragen also auch zu unseren Ansichten bei. Wenn wir über den Testprozess und den Aufgabenprozess sprechen , planen wir, führen Analysen durch, entwickeln Strategien, Strategien zur manuellen Testautomatisierung , automatisierte Strategien und wählen das Tool aus. Dann entwerfen wir, entwerfen Testfälle, entwerfen Skripte und bereiten die Umgebung vor. Dann haben wir die Ausführung. Bei der letzten Prozessausführung haben wir also gerade Testberichte generiert, haben wir also gerade Testberichte die das Management, die Fehlerverfolgung, die Fehleranalyse und die Berichte aufzeigen . Lassen Sie uns also über objektive Tests sprechen. Beim Testen geht es also darum, die Auswirkungen zu finden, Vertrauen in die Qualität zu gewinnen , also Informationen bereitzustellen, und es stellt die Informationen über unser Produkt , das der Kunde jetzt fehlerfrei verwenden kann, und so weiter. Also, um unsere Produkte zu bewerten , um zu überprüfen, ob alle Anforderungen erfüllt wurden oder nicht. Diese Informationen sind daher nützlich , um das Risiko zu verringern, das mit der Einhaltung kontextueller rechtlicher und regulatorischer Anforderungen und Standards Lassen Sie uns also darüber sprechen, was Testen ist. In der Co-Frage haben wir also statische Tests und dynamische Tests. Wenn wir also die Tests in Bezug auf statische Tests klassifizieren, wir statische Tests durch, ohne das Produkt auszuführen, ohne den Code auszuführen, ohne den Code auszuführen Beim dynamischen Testen führen wir das Produkt aus, wir führen es aus Wenn wir also über statische Tests sprechen, ist das eine Art von Fall, dass wir beispielsweise bei statischen Tests Überprüfungen durchführen, technische Prüfungen und Inspektionen durchführen Level-Tests handelt es sich also um Komponententests, Integrationstests, Systemtests, Abnahmetests und nicht funktionale Tests Im Grunde haben wir also Unit-Tests, dann haben wir Integration, ein System, dann haben wir Akzeptanz, Akzeptanz auf Benutzerebene und so weiter Wenn wir über Debugging und Testen sprechen, dann sind das zwei verschiedene Beim Testen geht es also darum, Fehler zu finden indem die Fehler in der Anwendung Diese Aktivität wird normalerweise vom Tester durchgeführt. Dual-Puts testen also auch. Debuggen ist also eine Entwicklungsaktivität. Wenn wir Automatisierung betreiben, tragen wir die Hitze eines Entwicklers auf, wir debuggen Dabei geht es um die Analyse von Fehlern, die Suche nach der Grundursache und die Behebung dieser Fehler Diese Aktivität wird also häufig von Entwicklern ausgeführt. Es ging also nur um die Grundlagen des Testens. Okay, vielen Dank. 4. Testpsychologie: Hallo. Willkommen zu einer weiteren Sitzung. Dies ist das letzte Thema in unserem ersten Kapitel, dem es um die Einführung ging. Das ist also 1.5 Testpsychologie. Wir werden also über die Psychologie des Testens, die Denkweise von Testern und Entwicklern sprechen und darüber, wie wir effektiv kommunizieren können , um eine bessere Qualität zu erreichen und die positive Beziehung aufrechtzuerhalten Zum Schluss werden wir also über Teststufen und Teststufen sprechen , damit wir diese Werte in einem Produkt von weitaus besserer Qualität erreichen können in einem Produkt von weitaus besserer Qualität Lassen Sie uns also über Testpsychologie sprechen. Wie Sie wissen, Tester und das Einholen der Teilnahmevoraussetzungen Sitzungen zur Verfeinerung der Geschichte teil Sie führen das Produkt aus und finden die Mängel. Sie nehmen es also als Kritik wahr , mit der sie den Autor und sein Produkt kritisieren Da die Entwickler erwarten, dass ihr Code korrekt ist, haben sie einen Bestätigungsfehler, der es ihnen schwer macht, zu akzeptieren, dass ihr Code falsch ist In der Regel führt das zu Konflikten. Informationen, die vom Tester wahrgenommen werden, enthalten daher oft schlechte Nachrichten. Es ist ein übliches menschliches Merkmal, die Barriere schlechter Nachrichten dafür verantwortlich zu machen. Aufgrund dieser psychologischen Fakten empfinden manche Menschen das Testen als zerstörerische Aktivität, obwohl sie erheblich zum Projektfortschritt und zur Produktqualität beitragen . Informationen über Mängel und Misserfolge sollten auf konstruktive Weise kommuniziert werden. Auf diese Weise können Spannungen zwischen Entwicklern und Testern abgebaut werden. Lassen Sie uns einige der effektiven Kommunikationswege besprechen . So können wir die Spannungen zwischen Entwicklern und Testern verringern zwischen Entwicklern und Testern Beginnen Sie also eher mit Zusammenarbeit als mit Schlachten. Erinnern Sie alle an das gemeinsame Ziel einer besseren Qualität. Qualität liegt nicht in der Verantwortung des Qualitätssicherungsteams oder des Entwicklers. Qualität liegt in der Verantwortung aller. Jeder sollte sich für ein qualitativ besseres Produkt einsetzen und Produkte besserer Qualität entwickeln. Kommunizieren Sie Testergebnisse und andere Erkenntnisse neutral und sachlich, ohne die Person zu kritisieren, die den defekten Artikel hergestellt hat Da Software von Menschen entwickelt wird, machen Menschen Fehler Es kann Probleme auf der Entwicklungsseite geben, sie haben die Anforderungen aufgrund von zu hohem Druck und anderen Faktoren verfehlt , sie haben also Bugs eingeführt. Auf diese Weise sollte der Fokus unserer Show auf Bugs liegen und nicht auf der Person , die den Bug verursacht hat oder der den Bug in das Softwareprodukt eingeführt hat . Versuchen Sie also zu verstehen, wie sich die andere Person fühlt und warum sie möglicherweise über negative Informationen nachdenkt. Bestätigen Sie also, dass die andere Person verstanden hat , was Sie gesagt haben und in welchem Forum. Testan und Entwickler denken normalerweise unterschiedlich. Entwickler denken also normalerweise , dass sie die richtigen Produkte gebaut haben Mit der richtigen Einstellung können Sie mehr Fehler finden Sie können das Produkt verbessern. Einstellung der Tester sollte also Neugier, professionellen Pessimismus, kritische Liebe zum Detail und Motivation für gute und positive Beziehungen zwischen ihren Kollegen beinhalten kritische Liebe zum Detail und Motivation für gute und Motivation für positive Denkweise der Tester wächst und reift, je mehr Erfahrung die und Sehen wir uns dieses Beispiel an: Nehmen wir an, es handelt sich um Person A und Person B. Nehmen wir an, Person A wurde getestet und Person B ist Entwickler Also Person A sagt, das sind sechs, und Person B, das ist Entwickler, sagt, es sind neun. Beide haben recht. Sie irren sich nicht, aber sie sind an einem anderen Ort. Sie sollten also die Perspektive des anderen verstehen , sie sollten sich respektieren. Anstatt darüber miteinander zu streiten , sind es neun. Ich sagte, das sind neun, und die QA wird sagen: Nein, das sind sechs, und in diesem Fall wird es zu Spannungen zwischen Entwickler und Tester kommen. Und das wird nun dazu beitragen , die Qualität zu verbessern. Das ist keine gute Angewohnheit. Das schafft Probleme im Team. Denkweise eines Entwicklers kann also einige Elemente der Denkweise von Testern beinhalten Entwickler können ihr Produkt mit der richtigen Einstellung testen. Aber Entwickler werden in der Regel, wenn sie die Erfahrung sammeln, Architekten Sie sind nicht daran interessiert, die Mängel zu finden und herauszufinden, was mit diesen Lösungen schief gehen könnte. Sie entwickeln und gestalten diese Lösungen. Bestätigungsfehler macht es ihnen schwer, Fehler in ihrem eigenen Produkt zu finden. Okay, lassen Sie uns über unabhängige Tests sprechen. Wenn einige der Testaktivitäten von unabhängigen Testern durchgeführt werden , erhöht Effektivität der Fehlererkennung. Unabhängige Tester bieten eine andere Perspektive als diejenigen, die ein Arbeitsergebnis herstellen. Unabhängige Tester sind Tester von Drittanbietern eine andere kognitive Voreingenommenheit haben als andere In der Stufe kann also ein Test von der Person entworfen werden, die die Software und den Test geschrieben hat Test wurde von einer anderen Person entworfen, es kann sein oder ihr Kollege. Dann Tests, die von Personen aus verschiedenen Organisationsgruppen oder von Testspezialisten entworfen wurden . Dabei handelt es sich um speziell dafür vorgesehene QATMs , die die Testfälle schreiben Und Tests, die von Personen aus verschiedenen Organisationen und Unternehmen entworfen wurden aus verschiedenen Organisationen und Unternehmen In der Regel werden Audits durch Dritte durchgeführt oder die Tests werden von Dritten durchgeführt Okay, das war's von meiner Seite. Vielen Dank. Wir sehen uns bei einer weiteren Sitzung. Danke. Okay. 5. Testprozess: Hallo. Okay. In dieser Sitzung werden wir über den Testprozess sprechen. Der Testprozess ist ein sehr wichtiges Thema und wir werden uns ausführlich mit dem Testprozess befassen. Okay, lassen Sie uns besprechen, was ein Testprozess ist. Wie Sie wissen, ist es bei der Qualitätssicherung von entscheidender Bedeutung, den wichtigsten Aspekt des Testprozesses zu implementieren , um gründliche und effektive Tests zu gewährleisten Zuallererst sollten Sie also verstehen, was ein Testprozess ist Beim Testen führen wir also verschiedene Aktivitäten durch. Zum Beispiel, wenn ein Projekt in SIS durchgeführt wird, beinhaltet die Qualitätssicherung, und so führt das Qualitätssicherungsteam die Planung durch. Was den Testprozess anbelangt, so besteht er aus der Verfolgung vieler Aktivitäten, beispielsweise der Testplanung, Testüberwachung und -kontrolle. Bei der Testplanung planen wir also all die Dinge, welche Ressourcen wir verwenden werden, was der Zeitplan ist, all diese Dinge. Und die Testüberwachung und -steuerung, wir überwachen, wir sammeln die Informationen über die Tests und ihre Umgebungen. Und als Teil der Testanalyse analysieren wir unsere Testergebnisse. Und im Testdesign entwerfen wir, eigentlich entwerfen wir die Testfälle. Lassen Sie mich Ihnen zum Beispiel zeigen, dass ich Ihnen den Bildschirm zeigen werde, um Ihnen die Testfälle zu zeigen. Und bei der Aufgabenplanung planen wir tatsächlich, wir planen zum Beispiel den APA-Aufgabenplan, Aufgabenplanung für die Automatisierung wurde durchgeführt. Bei der Testimplementierung implementieren wir also diese Testfälle, unabhängig davon, ob es sich um manuelle oder automatisierte Testfälle handelt, und bei der Testausführung führen wir diese Testfälle aus. manuelle Testfall wird von einem manuellen Tester ausgeführt und automatisierte Testfälle werden von einem automatisierten Tester ausgeführt. Und am Ende haben wir einen Testabschluss nach dem anderen, all diese Testfälle sind abgeschlossen. Jetzt fassen wir die Dinge zusammen und es wird ein Bericht erstellt , der den Stakeholdern mitgeteilt wird Lassen Sie mich den Bildschirm teilen. Ich kann dir den Testplan zeigen. Ein Beispiel für einen Testplan. Dies ist eigentlich ein API-Testplan, wie Sie hier sehen können. Dies ist eine API-Testebene. Es sieht also so aus, als würden wir die objektiven API-Beschreibungen, den Umfang, ihren Umfang, die Umgebung und die Testdaten definieren Umfang, ihren Umfang, die Umgebung , aus denen wir die Testdaten erhalten. Was wird der Test sein, in welcher Umgebung werden wir das Verfahren zur Mängelmeldung verwenden , in der wir die Mängel melden werden , und wie wird das Verfahren zur Meldung des Testumfangs aussehen Risiko und Risikominderung Es wurden sehr wichtige Risikobereiche identifiziert und es wurden Maßnahmen zur Risikominderung verfasst. Bei Testtools, also Tools, wir für API-Tests verwenden werden, können Sie sich darauf verlassen, dass wir SNG oder andere Dinge testen, denen wir Rollen und Verantwortlichkeiten , weil wir im Qualitätssicherungsteam unterschiedliche Rollen und Verantwortlichkeiten haben Führungskräfte haben unterschiedliche Rollen. Lead Adiner erstellen in der Regel den Testplan und haben unterschiedliche Verantwortlichkeiten Sie leiten das Team und kommunizieren mit den Stakeholdern. Und Junioren haben unterschiedliche Aufgaben. Senioren haben unterschiedliche Aufgaben, und hier haben wir Testresultate. Es ging also um den Testplan. Und wir bereiten auch die Testfälle vor. Sie können sehen, dass Testfälle unterschiedliche Elemente haben , zum Beispiel Testfall-ID , Testfallbeschreibung und Vorbedingungsschritte beinhalten tatsächliche Ergebnisse und erwartete Ergebnisse In diesem Fall haben wir also Testdaten. Wir haben also verschiedene Testfälle. Früher haben wir diese Testfälle geschrieben. Manuelle Tester haben früher Testfälle geschrieben , und in der Analysephase legen wir dann gemeinsam fest, welche Testfälle wir automatisieren werden und so weiter Gehen wir also zurück zu den Folien und okay, hören wir auf zu teilen Okay. Also im Testprozess kontextuellen Faktoren , die den Aufgabenprozess für die Organisation beeinflussen den Aufgabenprozess für gehören zu den kontextuellen Faktoren , die den Aufgabenprozess für die Organisation beeinflussen, aber nicht beschränkt auf Also werden Softwareentwicklung, Liecon Mad und Projektmethodik verwendet, wobei Testlevel und Testtyp berücksichtigt In einigen Organisationen haben wir also einen Reifegrad erreicht, sie haben den CMII-Reifegrad fünf erreicht Sie sind gut ausgereift. Sie verwenden die Testebene, wir haben Komponententests Integrationstests, sodass die Komponententests im Komponententest automatisiert werden. Diese sind also sehr wichtig. Produkt- und Projektrisiken, Geschäft für Männer, weil viele dann unterschiedliche Geschäfte sein können. Lebensrettende Geschäfte, Geschäfte können unterschiedlich sein, und es kommt darauf So erforderten organisatorische Einschränkungen, beispielsweise Budgetressourcen, Zeitrahmen, Komplexität, bauliche und regulatorische Anforderungen, Unternehmensrichtlinien und -praktiken bauliche und regulatorische Anforderungen, Unternehmensrichtlinien und -praktiken, interne und externe Standards Das sind also Faktoren, die unseren Testprozess beeinflussen. Lassen Sie uns nun über die Aufgabenplanung sprechen. Und bei dieser Aufgabenplanung führen wir die folgenden Hauptaktivitäten durch, den Umfang und das Risiko festlegen indem wir den Umfang und das Risiko festlegen und das Testziel festlegen. Bei der Aufgabenplanung haben wir also den Testplan vorbereitet. Wir haben den API-Testplan vorbereitet, manuellen Test durchgeführt und die Planung abgeschlossen. Wir haben die Automatisierung vorbereitet, zum Beispiel sind die UI-Testpläne fertig, und die Entwickler haben früher Unit-Testpläne erstellt und so weiter. In dieser Phase verfolgen wir also einen umfassenden Testansatz. Wir definieren den allgemeinen Testansatz, planen Testaktivitäten und weisen Ressourcen für die Aktivitäten Daher werden verschiedenen Quellen Manager zugewiesen , sodass Testleiter und Testmanager sehr wichtig sind und in dieser Sitzung eine Schlüsselrolle spielen Sie planen die Testaktivitäten, weisen die betroffenen Ressourcen zu, definieren die Menge, die Einzelheiten und die Vorlage für die Dokumentation. Daher werden auch Testpläne dokumentiert. Planung von MTCs zur Überwachung und Steuerung daher sehr wichtig, da wir am Ende dieser Aktivität dem Management etwas zeigen müssen Die Met Ss sind also vorbereitet. Also sind Daten sehr wichtig. der Suche nach Eintrittsprüfungen in der User Story haben wir Ein- und Austrittskriterien, der User Story haben wir Ein- und Austrittskriterien wir definieren, weil diese sehr wichtig sind , um Tests zu beenden Entscheidungen über die Automatisierung zu treffen In dieser Testplanungssitzung entscheiden wir also, wie wir die Tests automatisieren wollen und wie sie, Zeitplan sie haben und so weiter Also entscheiden wir über die Automatisierung, wie viel Automatisierungsaufwand erforderlich sein wird, wo die Quellen in ihren Kostenaufwand einbezogen werden, alles ist dabei geplant. Aktivität in der Ex, wir haben Testüberwachung und Kontrolle. Also haben wir unsere Testaktivitäten überwacht. Es ist ein Prozess zur Messung des Projektfortschritts. Also werden Testmediziner gesammelt, diese enthalten Einrichtungsformeln, zum Beispiel eine Deckung von Defekten Wenn wir von der Ausführungsrate sprechen, ist das die Anzahl der akuten Testfälle unsere Gesamtzahl der geplanten Testpläne für die Ausführung im Jahr 200 Daher werden Formeln für die Testausführungsrate definiert, und Testkontrolle beinhaltet das Ergreifen der erforderlichen Maßnahmen , um die Testziele zu erreichen. der Testanalysephase analysieren wir also die Informationen, die für den Start der Testanalyse und die Erstellung unserer Testfälle erforderlich sind. In der Testanalysephase variieren wir die Testbasis und die Testelemente, um Fehler verschiedener Art wie mehrdeutige Emissionen, Inkonsistenzen, Ungenauigkeiten usw. zu identifizieren Fehler verschiedener Art wie mehrdeutige Emissionen, Inkonsistenzen, Ungenauigkeiten In der Testanalysephase hatten wir also das SRS-Dokument mit den Anforderungen, sodass im SRS-Dokument etwas übersehen werden kann In dieser Phase analysieren wir diese Dinge Wir identifizieren Funktionen und eine Reihe von Funktionen, die getestet werden sollen. In diesem Fall analysieren wir auch, welche Funktionen getestet werden, welche automatisiert werden, Funktionen automatisiert werden und so weiter. In dieser Phase definieren wir priorisierte Testbedingungen für jedes Feature auf der Grundlage des LC-Up-Tests Dabei werden funktionale, nichtfunktionale Strukturmerkmale, andere geschäftliche und technische Faktoren sowie die Höhe der Risiken Beim Testdesign haben wir unsere Testfälle tatsächlich entworfen, und wir priorisieren unsere Testfälle Im Testdesign identifizieren wir die erforderlichen Testdaten, um die getesteten Testfälle zu unterstützen Im Fall der Automatisierung verwenden wir also möglicherweise eine Faker-Bibliothek Wir haben Testdaten in Excel, CSV-Dateien usw. Beim Aufgabendesign entwerfen wir die Testumgebung und identifizieren die erforderliche Infrastruktur und Tools. Nehmen wir also beim Aufgabendesign an, dass wir drei Umgebungen haben Dav-Umgebung, Staging Wir berücksichtigen also auch die Umgebung, in der wir die Testumgebung vorbereiten eine bidirektionale Rückverfolgbarkeit zwischen Aufgabenbasis und Aufgabenfällen herstellen Aufgabenbasis und Aufgabenfällen Testfälle sollten bis zu den Anforderungen rückverfolgbar sein. Testfälle, die ich Ihnen gezeigt habe, basieren beispielsweise auf unseren Anforderungen. In der agilen Umgebung haben wir also Anwenderberichte. Diese sollten also unsere User Stories verknüpfen. Jira ist also ein Tool, das dabei hilft. Also sollten alle Dinge in Jira vorhanden sein. Bei der Testimplementierung führen wir also die folgenden Aktivitäten durch: die Entwicklung und das Schreiben von Testverfahren und möglicherweise die Erstellung automatisierter Testschrecken Wir befinden uns also in der Implementierungsphase, also haben wir früher automatisierte Testskripte erstellt In dieser Phase erstellen wir also eine Testsuite aus Testverfahren und automatisierten Testskripten ordnen die Testsuite innerhalb eines Ausführungsplans so an , dass eine effiziente Ausführung gewährleistet den Aufbau der Testumgebung, einschließlich möglicher Testsysteme, Servicevirtualisierung , Simulatoren und anderer Infrastrukturelemente überprüft, ob alles, was benötigt wird, korrekt eingerichtet wurde Bei der Testimplementierung bereiten wir also die Testdaten vor und stellen sicher, dass sie ordnungsgemäß in die Testumgebung geladen werden. Dabei wird sehr fein aktualisiert bidirektionale Rückverfolgbarkeit zwischen Testbasis, Testbedingung, Testfällen, Testverfahren und Testquelle In der Testausführungsphase führen wir unsere Testfälle also tatsächlich aus und zeichnen dabei die IDs, die Version des Testelements, Version des Testelements, NTA-Betreff-Testtools und die Testware Wir führen Tests manuell oder über ein automatisiertes Tool aus. vergleichen den tatsächlichen Wert mit dem erwarteten Fehler, falls ein Fehler auftritt, Wir vergleichen den tatsächlichen Wert mit dem erwarteten Fehler, falls ein Fehler auftritt, und protokollieren diesen Fehler im Fehlerberichtstool. Wir analysieren Anomalien, um ihre wahrscheinlichen Fälle zu ermitteln. Ein Ausfall kann also auf Fehler im Code zurückzuführen sein, aber es kann auch zu sehr positiven Ergebnissen kommen Also protokollieren wir das interessierende Ergebnis im Pass-Fail-Block. Wir wiederholen die Testaktivitäten. Wenn es beispielsweise eine Anomalie gibt oder wir Pläne für erneute Tests oder die Durchführung von Korrekturtests haben, führen wir Wiederholungstests und Regressionstests Und so werden all diese Aktivitäten in einer Testausführung ausgeführt Nach Abschluss des Tests ist dies also die letzte Phase, und das ist der Abschluss der Dinge. Nach Abschluss des Tests überprüfen wir also, ob alle defekten Ports geschlossen sind, geben eine Änderungsanforderung ein oder schützen den Iter vor Fehlern, die am Ende des Testausschlusses unverdient bleiben Wir erstellen einen zusammenfassenden Testbericht , der an die Beteiligten weitergeleitet wird In der Regel bereiten Aufgabenleiter und Manager die Berichte vor und sie kommunizieren vielleicht wöchentlich, normalerweise wöchentlich, wöchentliche Updates von der Q-Abteilung werden beispielsweise an StakehDerf, CEO und CTO usw. die Berichte vor und sie kommunizieren vielleicht wöchentlich, normalerweise wöchentlich, wöchentliche Updates gesendet CEO und CTO Also haben wir ein Archiv fertiggestellt, die Testumgebung, die Testdaten, die Testinfrastruktur und andere Tests wurden später wiederverwendet . In der Phase des Testabschlusses übergaben wir den Test also an das Wartungsteam, andere Projektelemente und an alle, die von seiner Nutzung profitieren könnten Wir analysieren den letzten Teil der abgeschlossenen Testaktivitäten, um zu ermitteln, welche Änderungen für zukünftige Iterationen, Releases oder Projekte erforderlich zukünftige Iterationen, Releases oder Die Lektion ist also nicht dokumentiert. In diesem Fall können wir uns also verbessern. Also verbessern wir unsere Testmehrheit. Da die Testmehrheit verbessert werden kann, haben wir wieder Zugriff auf die Daten. Wir haben also Daten, wir haben Erfahrung, wir sammeln die Erfahrung bei all diesen Testaktivitäten in diesem Prozess. Deshalb entwickeln wir unseren Testprozess weiter, indem wir die gesammelten Informationen durch kollektive Intelligenz nutzen. Bei Testprodukten gibt es also viele Arbeitsprodukte. Das Arbeitsprodukt der Testplanung, wir haben, die Testplanung umfasst in der Regel Testpläne. Testpläne enthalten Informationen über die Testbasis, mit der die anderen Testprodukte verknüpft werden , sowie Informationen zur Rückverfolgbarkeit Das Arbeitserzeugnis der Testüberwachung und -kontrolle umfasst in der Regel die Art der Testberichte, den Testbericht, Pressebericht und den zusammenfassenden Testbericht Testüberwachung und Kontrolle des Arbeitsfortschritts sollten daher auch Aspekte des Projektmanagements berücksichtigt werden, wie z. B. die Zusammenstellung von Aufgaben, Zuweisung von Ressourcen und die Nutzung des Arbeitsaufwands Arbeitsprodukten der Testanalyse gehören definierte, priorisierte Testbedingungen, von denen jede im Idealfall eine bidirektionale Rückverfolgbarkeit auf bestimmte Elemente der Testbasis bietet, die Bei explorativen Tests kann die Testanalyse die Erstellung einer Testcharta beinhalten Im Arbeitstext zum Testdesign werden also Ergebnisse des Testdesigns in Testfällen und einer Reihe von Testfällen zusammengefasst, um die in den Tests definierte Testbedingung auszuüben . Testdesign führt auch zur Identifizierung des Entwurfs und der erforderlichen Testdaten, zum Testdesign der Testumgebung sowie zur Infrastruktur und zum Tool zur Identifizierung, da diese Ergebnisse sehr aussagekräftig dokumentiert werden. In der Testdesignarbeit Pat haben wir also Testdaten. Testdaten können sich in einer CSV-Datei in unserer Datenbank befinden. Wir haben eine separate Q-Datenbank zum Testen. Im Arbeitsprodukt der Testimplementierung haben wir also das Testverfahren und die Reihenfolge dieser Testverfahren, Zeitplan für die Testausführung. Testimplementierung kann auch zur Erstellung und Überprüfung von Testdaten und der Testumgebung führen zur Erstellung und Überprüfung . Im Arbeitsprodukt Testausführung führen in dieser Phase, wie Sie wissen, wir in dieser Phase, wie Sie wissen, Testfälle aus. Also bereiten wir den Fehlerbericht vor, dokumentieren den Status der einzelnen Testfälle, die Testprozeduren, bereiten das Testprotokoll vor, überspringen bewusst Testfälle usw. und dokumentieren, welche Testobjekte, welches Testtool und welcher Test wo an den Tests überspringen bewusst Testfälle usw. und dokumentieren, welche Testobjekte, welches Testtool beteiligt waren Im Projekt zum Abschluss des Tests ist dies also unsere letzte Phase In dieser Phase führen wir Tests durch. Wir bereiten den zusammenfassenden Bericht und Maßnahmen zur Verbesserung nachfolgender Projekte oder Iterationen In diesem Fall haben wir möglicherweise Blockelemente, abgeschlossene Testware, bestandene und fehlgeschlagene Tests, all diese Dinge sind in diesem Bericht Lassen Sie mich also im letzten Abschnitt über die Rückverfolgbarkeit zwischen Testbasis und Test Work Protect sprechen Rückverfolgbarkeit zwischen Testbasis und Test Work Neben der Bewertung der Testabdeckung, der guten Testbarkeit, des Sports, der Analyse der Auswirkungen von Änderungen, der Erstellung und dem Testen von Prüffunktionen sind Tests also nur überprüfbar, Testen von Prüffunktionen sind Tests also wenn wir jeden einzelnen Schritt dokumentiert haben Zum Beispiel haben wir die Anforderungen dokumentiert, wir haben die Testfälle geschrieben, wir bereiten den Automatisierungsbildschirm vor, wir führen ihn aus und alle Ressourcen werden bei jedem Standup-Meeting synchronisiert Wir führen täglich ein Stand-up-Meeting durch. Alles ist dokumentiert, sodass wir prüfen und uns verbessern können Prozessverbesserungen sind also sehr wichtig. Tag für Tag sollten wir uns verbessern. Das Team sollte sich verbessern, die Prozesse sollten verbessert werden. Erfüllung der RT-Sensibilisierungskriterien. Verbesserung des Verständnisses der Tests, des Fortschrittsberichts und des zusammenfassenden Berichts , sodass Fortschrittsberichts und des zusammenfassenden Berichts auch der Status der einzelnen Elemente der Testgrundlage berücksichtigt wird. Zum Beispiel Anforderungen, die ihre Tests bestehen, Anforderungen, die ihren Test nicht bestanden haben , und Anforderungen, bei denen noch Tests ausstehen, die den Beteiligten den technischen Aspekt der Tests in einer noch Tests ausstehen, die den Beteiligten den technischen Aspekt der Tests für sie verständlichen Form vermitteln. Bereitstellung von Informationen zur Bewertung der Produktqualität, Prozessfähigkeit und des Projektfortschritts sowie der Geschäftsziele. Es ging also nur um den Testprozess. Okay, wir sehen uns in der nächsten Sitzung. Vielen Dank. Tschüss. 6. Internationales Softwaretest-Qualifikationsgremium: Hallo. Okay. In dieser Sitzung werden wir mit ISTGB über ihre Zertifizierungen sprechen und darüber, warum wir uns für Zertifizierungen entscheiden sollten TGB steht also für International Software Testing Qualification Board, und sie führen Sie bieten auch die Schulung an. Sie haben also eine Mutterorganisation und eine Kinderorganisation, und jedes Land führt seine Prüfungen Sie haben also einen Lehrplan, ganzen Welt befolgt wird , und es gibt daher Zuallererst sollten Sie an dieser Prüfung teilnehmen, weil sie Ihnen die Gültigkeit verleiht und sie international anerkannt ist, und sie sind leicht Wenn Sie also erscheinen, bestehen Sie die Prüfung, sie ist lebenslang gültig. Ähm, es ist ein bisschen teuer, aber es bietet Ihnen Vorteile bei der Jobsuche Normalerweise bevorzugen Arbeitgeber Kandidaten STV-Zertifizierungen Also kann jeder an der Prüfung teilnehmen. Es gibt keine Einschränkungen in Bezug auf Alter, Bildung oder Ähnliches. Sie können also erscheinen und ihre Zertifizierung bestehen. Die Grundstufe ist also die Basiszertifizierung. Zunächst werden Sie auf der Grundstufe erscheinen , und danach können Sie weitere Zertifizierungen und andere Zertifizierungen durchführen. Auf der Grundlagenebene bestehen sie also aus sechs Kapiteln, beginnend mit den Grundlagen des Testens, und dann dem zweiten Kapitel, Tests während des gesamten Lebenszyklus der Softwareentwicklung durchgeführt werden. Und im dritten Kapitel geht es um die ersten Tests. Das vierte Kapitel befasst sich mit Testtechniken, fünfte Kapitel mit dem Testmanagement und das sechste Kapitel mit dem Werkzeugsport zum Testen Also besprechen wir alle Dinge im Detail. Also lass uns auf ihre Website springen und nachsehen. Lass mich das grün teilen. Okay. Okay, wie du siehst, ist das ihre offizielle Seite, stwb dot also ihre Homepage sehen, Sie können also ihre Homepage sehen, ihre Homepage, willkommen bei ISTQB ist ein weltweit führendes Zertifizierungssystem im Bereich Softwaretests Bis Juni 2023 hat das ISTQB mit seinem umfangreichen Netzwerk von akkreditierten Schulungsanbietern, Mitgliedsgremien und Prüfungsanbietern 1,3 Millionen Prüfungen durchgeführt und mehr als 957 als Zertifizierungen in über 130 Ländern ausgestellt Zertifizierungen in über 130 Ländern mit seinem umfangreichen Netzwerk akkreditierten Schulungsanbietern, Mitgliedsgremien und Prüfungsanbietern Mitgliedsgremien Somit ist IS Two B eines der größten und etabliertesten Zertifizierungssysteme für wonderneutrale Fachkräfte der Welt Also solltest du gehen, auf jeden Fall, du solltest dich dafür entscheiden. Sehen wir uns ihre Zertifizierungsprüfung F an und so weiter. Ihre Zertifizierung, wann immer Sie neu in der Testbranche sind oder bereits etabliert sind, und die IS Two B-Zertifizierung werden Sie während Ihrer gesamten Karriere unterstützen. Arbeitgeber, das Programm für zertifizierte ISTB-Tester hilft Ihnen dabei , diese Fähigkeiten in Ihrem Team zu entwickeln und zu bewerten , und unterstützt Sie bei der Rekrutierung IST B-Zertifizierung bietet Schulungsanbietern also vielfältige Möglichkeiten, ihr Schulungsportfolio zu erweitern . Hier in der Kursgrundlage haben sie also ein zertifiziertes Test-Foundation-Level. Derzeit haben sie V 4.0, was neu ist. Dann haben sie das Tested Foundation Level zertifiziert. Sie können es erneut versuchen, wenn Sie die alten Zertifizierungen durchführen, 3.1 Auf der Kernebene verfügen sie über Testanalyse, Testautomatisierungstechnik , Spezialisten, sie haben eine Testautomatisierungsstrategie und KI-Tests Auf der agilen Seite haben sie agile Tester und sie sind auf Grundlagenebene, agile Tester, sie haben einen Vorsprung im Voraus. Sie haben einen technischen Tester von JL. Sie haben Situationen auf Expertenebene, können auf den Testprozess zugreifen und die Verbesserung des Testprozesses im Bereich Testmanagement auf Expertenebene zertifiziert Sie sind im Bereich Testmanagement auf Expertenebene zertifiziert und müssen mit dem Testmanagement und dem operativen Testmanagement beginnen , also über mehr als diese Zertifizierung verfügen. Lassen Sie mich also eines der lokalen Vorzeichen für die Durchführung der Prüfung aufzeigen . Das kannst du sehen Das ist PST w dot PK, das Prüfungen in Pakistan durchführt, und es gibt Prüfungen in verschiedenen Städten, Lao Trachis Samba, und Sie können Du kannst zahlen. Auf jeden Fall müssen Sie online bezahlen und Sie können sich registrieren, und okay, entweder Sie können sich registrieren, sie werden Ihnen eine E-Mail schicken und an diesem Tag können Sie auf der erscheinen, also ging es ein bisschen um ihre Zertifizierung, und auf jeden Fall sollten Sie die Zertifizierung erhalten. Du solltest deine Zertifizierung vorzeigen. Es ging also nur um ISTQB. Okay, vielen Dank. Tschüss. 7. Testprinzipien: Hallo, willkommen zu einer weiteren Sitzung. Dies ist eine sehr interessante Sitzung, da ich in dieser Sitzung über Ihre Testprinzipien sprechen werde. Dieses Thema ist in Kapitel eins enthalten, und in Abschnitt 1.3 behandeln wir die Prinzipien des Testens. Wir haben sieben Testprinzipien. Prinzip eins ist, dass das Testen das Vorhandensein von Fehlern zeigt. Prinzip zwei: Eine erschöpfende Prüfung ist nicht möglich. Prinzip drei: Frühzeitiges Testen. Prinzip vier ist die Clusterbildung von Defekten, Prinzip fünf ist das Pestizid-Paradoxon Prinzip sechs: Das Testen ist kontextabhängig. Prinzip 77, Fehlen des Fehlers FLC. Diese Testprinzipien sind sehr wichtig. sind nicht theoretisch und haben eine praktische Umsetzung, daher sollte sich jeder Tester dessen bewusst sein. Dieses Prinzip bietet eine Grundlage für fundierte Entscheidungen während des Testprozesses. Durch die Anwendung dieser Prinzipien können sich die Tester also auf Bereiche mit hohem Risiko konzentrieren. Wenn wir zum Beispiel sagen, dass umfassende Tests unmöglich sind können wir nicht alles testen , also sollten wir uns auf Bereiche mit hohem Risiko konzentrieren Vermeiden Sie häufige Fallstricke und stellen Sie sicher, dass ihre Tests sowohl effizient als auch wirksam Sehen wir uns also das erste Prinzip im Detail an. Testen zeigt das Vorhandensein von Fehlern, Testen zeigt das Vorhandensein von Fehlern, jetzt deren Fehlen. Wir können also nicht sagen, dass wir zu 100% getestet haben, sodass es keine Fehler gibt. Es ist möglich, dass wir die Anforderung nicht erfüllt haben. Tests können also zeigen , dass Fehler in der Systemsoftware vorhanden sind , aber unabhängig von der Anzahl der Fehler, die wir zu einem Zeitpunkt gefunden haben, können wir nicht sagen, dass es keine Fehler mehr gibt. In diesem Fall können wir das also nicht sagen, oder wir können diese nicht als Nachweis für die Richtigkeit vorlegen. Das nächste Prinzip ist also, dass erschöpfende Tests unmöglich sind. Alles zu testen, jede Permutation ist unmöglich. Es kann also viele Eingabekombinationen geben. Es ist also nicht möglich, alles in begrenzter Zeit und mit begrenztem Budget zu testen . Als Alternative zu umfassenden Tests sollten Risikoanalysen und Prioritäten verwendet werden, um Risikoanalysen und Prioritäten sich auf die Testbemühungen zu konzentrieren Lassen Sie mich also ein Beispiel nennen. Zum Beispiel gibt es einen Bildschirm auf der Seite. Es gibt 515 Eingabefelder für Entschuldigung denen jedes fünf mögliche Werte akzeptiert Um zu testen, kann die Anzahl der erforderlichen Testfälle also zwischen fünf und 15 liegen Sie können also sehen, dass es mehr als 30 Millionen Testfälle geben kann . Wir können also nicht innerhalb der begrenzten Zeit und des begrenzten Budgets testen. Umfassende Tests sind also unmöglich. Jeder Tester sollte sich von Okay bewusst sein. Und das dritte Prinzip ist das frühe Testen. Frühzeitiges Testen spart Zeit und Mühe. Wie Sie hier sehen können, können Sie die Fehler sehen. Sie können sehen, dass die Bugs immer größer werden. Auf der rechten Seite haben wir Zeit, wir haben Zeit, wenn Bugs gefunden werden. Im oberen Pfeil sind das Budget und die damit verbundenen Kosten aufgeführt. Wie Sie in der Spezifikation sehen können, ist der Bug im Design kleiner und wird immer größer im Code sowie beim Testen und Releasen. In der Leasingphase ist es also am teuersten, ihn zu beheben, und es wird mehr Zeit in Anspruch nehmen. Um also Fehler früher zu finden oder um zu verhindern, dass Fehler während der Entstehung von Fehlern auftreten, müssen die Tester so früh wie möglich in den Entwicklungszyklus einbezogen werden . Daher müssen die Testaktivitäten mit den entsprechenden Entwicklungsaktivitäten koordiniert werden . Sie sollten mit der Spezifikation beginnen. Also sollten wir Linkstests durchführen. Das Testen sollte also beginnen, sobald das Projekt beginnt. Tester leisten also gute Beiträge zu Rezensionen und müssen daran teilnehmen Dies hilft ihnen, die Anforderungen früher zu verstehen und die Aufgabenfälle zu einem früheren Zeitpunkt im Lebenszyklus vorzubereiten einem früheren Zeitpunkt im Lebenszyklus Daher sollte der Testfall früher vorbereitet werden , bevor der Code geschrieben wird. Im vierten Prinzip geht es also um das Clustering von Defekten. Sie kennen also die 80-20-Regel, 80% Bugs in 20% Modulen gefunden werden Der Defekt ist also gebündelt. Es ist möglich, dass mehr Fehler in den Malar-Modulen gebündelt sind , als wenn sie auf größere und andere Module verteilt In dieser Hinsicht muss ein Tester also proportionale Testfälle berücksichtigen und vorbereiten, um ein solches System zu testen Lassen Sie uns nun über das Pestizid-Paradoxon sprechen. Also das Prinzip ist fünf und wir sprechen davon, dass unser Test immun wird Wenn also dieselben Tests immer und immer wieder vorbereitet werden , helfen dieselben Testfälle, über die wir lernen, irgendwann dieselben Testfälle, über die dabei , neue Fehler zu finden. Wenn dies zum Beispiel sowohl für manuelle als auch für automatisierte Tests im Automatisierungsfall gilt und wir das Skript geschrieben haben, führen wir dasselbe Skript immer wieder aus. Ich werde keine neuen Bugs finden. Also sollten wir uns verbessern, wir sollten unsere Testfälle aktualisieren, egal ob diese manuell oder automatisiert sind. Dieses Prinzip hilft also auch , unsere Testfälle zu verbessern und zu wachsen. dieses Problem zu lösen, müssen die Testfälle für Pestizide also irgendwann überprüft und überarbeitet nächste Testprinzip ist also , dass das Testen kontextabhängig ist In diesem sechsten Prinzip sprechen wir also über den Kontext. Das Testen wird also in verschiedenen Kontexten unterschiedlich durchgeführt. Wenn wir es beispielsweise mit lebensrettenden Anwendungen zu tun haben, werden unsere Kontexte beim Testen der E-Commerce-Site unterschiedlich sein . Zwei verschiedene Softwaretests mit unterschiedlichen Strategien. Ihre Strategien für Automatisierung und manuelle Tests werden unterschiedlich sein. Schauen wir uns nun das siebte Prinzip an, das darin besteht, dass das Fehlen von Fehlern falsch ist. Daher ist es letztlich wichtig, die Anforderungen zu erfüllen. nicht möglich, einen Reparaturfehler zu finden, wenn das gebaute System die Bedürfnisse und Erwartungen der Benutzer nicht erfüllt. Wenn wir also das System gebaut haben und es bereits vor einem Bug steht, es aber die Benutzeranforderungen nicht erfüllt, dann wird es als System verwendet. In diesem Prinzip geht es also um dieses Thema. Also sollten wir den Kunden einbeziehen, wir folgen der Agil-Philosophie, Methodik der kindlichen Entwicklung Unsere Kunden sind also involviert, also sollten sie über die Fortschritte auf dem Laufenden gehalten werden Es ist also besser, all diesen Prinzipien zu folgen. Deshalb sollten wir uns all dieser Dinge bewusst sein. Vielen Dank. Tschüss. 8. Warum Tests notwendig sind: Hallo. Willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir also darüber sprechen, warum Tests notwendig sind. Wir sind also im ersten Kapitel, dem es um die Grundlagen des Testens geht. In den Grundlagen des Testens geht es in 1.2 also darum, warum Tests notwendig sind. Tests sind also notwendig , weil sie helfen, Fehler zu erkennen. So wird sichergestellt, dass unsere Software erwartete Funktionalität erfüllt und die Erwartungen und Bedürfnisse der Benutzer Es hilft also, zukünftige Probleme zu vermeiden , da unsere Internetteams, QA-Teams und sogar Entwickler die Fehler identifizieren und beheben Es ist also auch kostengünstig denn wann immer Fehler einem früheren Zeitpunkt im Lebenszyklus der Softwareentwicklung behoben werden, ist es kostengünstig, da es in der späteren Phase teurer und zeitaufwändiger wird, es in der späteren Phase teurer und zeitaufwändiger wird die Fehler zu beheben Es hilft auch, die Risiken zu identifizieren , da wir die Sicherheitslücken beheben, da dies später zu vielen Problemen und Sicherheitsproblemen führen kann. So wird das Vertrauen gestärkt, dass unsere Software die Anforderungen erfüllt und die Erwartungen der Benutzer erfüllt Testen ist also auf jeden Fall notwendig. Äh, wenn Tester an der Überprüfung der Anforderungen oder der Verfeinerung der Benutzergeschichte beteiligt könnten Fehler an diesen Arbeitsergebnissen festgestellt werden , da die Tester an den statischen Tests beteiligt sind Bei statischen Tests haben sie also früher die User Stories überprüft. Sie sind Teil der Verfeinerung des User-Story-Prozesses und führen Reviews und statische Code-Analysen durch Tester während der Entwicklung des Systems eng mit dem Systemdesigner zusammenarbeiten , kann das Verständnis aller Beteiligten für das Design und die Art und Weise, wie es getestet werden kann, Wenn Tester also eng mit dem Designer zusammenarbeiten , während der Code noch unterentwickelt ist kann das Verständnis beider Parteien für den Code und dessen Durchführung verbessert werden, da die Tester eng mit den Designern, Entwicklern und allen Beteiligten zusammenarbeiten Designern, Entwicklern und allen So gewinnen sie ein besseres Verständnis für das Produkt. Wenn die Software vor der Veröffentlichung getestet, verifiziert und validiert wurde, können Fehler erkannt werden, die andernfalls möglicherweise übersehen worden wären, und der Prozess der Behebung des Fehlers, der den Fehler verursachen kann, unterstützt werden. Lassen Sie uns also ein wenig über Qualitätssicherung und Qualitätskontrolle sprechen . Wenn wir also über Qualitätssicherung sprechen, obwohl die Leute oft den Begriff Qualitätssicherung verwenden , ist das nur QA und wird als Testen bezeichnet. Qualitätssicherung und Testen sind nicht dasselbe, aber sie sind verwandt. Also meine QA sind nicht nur Tester. QA ist eigentlich Prozessraum. Wenn wir über QA sprechen, bedeutet das, dass wir über den Prozess sprechen. Qualitätssicherung konzentriert sich in der Regel auf die Einhaltung der richtigen Prozesse , um die Gewissheit zu schaffen , dass das angemessene Qualitätsniveau erreicht wird Wenn die Prozesse im Allgemeinen von hoher Qualität sind, was zur Fehlervermeidung beiträgt Wenn wir also von einer Qualitätssicherung sprechen, bedeutet das, dass wir Fehler verhindern. Wenn wir über Tests sprechen, erkennen wir Fehler. Das eine ist die Erkennung, das andere die Prävention. Also an der Spitze steht bei uns das Qualitätsmanagement. Im Rahmen des Qualitätsmanagements haben wir die Qualitätssicherung, und dann ist das Testen Teil der Qualitätssicherung. Die Qualitätskontrolle umfasst verschiedene Aktivitäten, einschließlich Testaktivitäten, die das Erreichen eines angemessenen Qualitätsniveaus unterstützen. Testaktivitäten sind Teil unseres VA-Softwareentwicklungs - oder Wartungsprozesses. Lassen Sie uns also ein wenig über Fehler, Defekte und Misserfolge sprechen . Fehler sind also ein Fehler. Da Software von Menschen entwickelt wird, können Menschen Fehler machen. Eine menschliche Handlung, die falschen Ergebnissen führt , wird als schwerwiegende Fehler bezeichnet Also die Herstellung eines Fehlers in der Software, der auch als Defector Bug bezeichnet Die Person hat also einen Fehler gemacht und dieser Fehler ist in die Software eingedrungen Bei diesem Fehler im Softwareaufruf-Bug kann es also zu einem Fehler kommen, wenn er weit ausgeführt wird, weil ein Fehler aufgetreten ist. Es kann viele Ursachen für diesen Fehler geben. Entwickler können also unter Druck geraten, Anforderungen können missverstanden werden und so weiter Dieser Fehler ist also im Code, und wenn er ausgeführt wird, führt das zu einem Fehler Eine Abweichung der Software von erwarteten Lieferung ist ein Kartenfehler. Wie Sie auf diesem Bild sehen können, können Sie hier sehen, wie eine Person hier Fehler macht, und dieser Fehler liegt in der Software. Bei der Ausführung, die den Fehler verursacht hat, können Sie sehen, dass es viele Ursachen für Softwarefehler gibt. Fehler können aus vielen Gründen auftreten. Zum Beispiel Zeitdruck, fehleranfällige menschliche Mitarbeiter, unzureichende oder unzureichend qualifizierte Projektteilnehmer. Also Missverständnisse zwischen den Projektteilnehmern , einschließlich Fehlkommunikation über die Anforderungen und das Design Wenn also die Anforderung und der Entwurf nicht dokumentiert sind, sie nicht ordnungsgemäß kommuniziert, was zu Problemen führen kann Also Komplexität des Codes, manchmal sind Codes zu komplex, insbesondere Schlüsselcode Äh, wenn die Entwurfsarchitektur, das zugrundeliegende Problem gelöst werden muss Also Missverständnisse über systemübergreifende Intrase-Schnittstellen, vor allem, wenn solche systeminternen und systemübergreifenden Interaktionen zahlreich Das kann also das Problem in der Software verursachen. Also neue, unbekannte Technologien Wenn die Entwickler und das Team mit der neuen Technologie nicht vertraut sind, werden sie gebeten , in dieser Technologie oder in der Technologie zu programmieren oder in der Technologie zu programmieren die die Softwarefehler verursachen kann Das kann also zu einer Katastrophe führen. Das ist es. Okay. Danke. 9. Statisches Testen: Nun, wir kommen zu einer weiteren Sitzung. In dieser Sitzung werden wir über statische Tests sprechen. Derzeit befinden wir uns in Kapitel drei, dem es um statische Tests geht. In Kapitel drei haben wir also zwei Themen, 3.1 und 3.2. 3.1 befasst sich mit den Grundlagen statischer Tests und 3.2 mit dem Testprozess. Was ist also statisches Testen? Im Gegensatz zu dynamischen Tests, bei denen die Ausführung der zu testenden Software erforderlich ist. Beim statischen Testen analysieren wir den Code, ohne ihn auszuführen. Die statische Analyse ist wichtig für sicherheitskritische Systeme. Zum Beispiel nukleare oder medizinische Software für die Luftfahrt. Bei den statischen Tests analysieren wir also die Software, bei der es sich Benutzerhandbuch handeln kann, das ein Dokument zur Spezifikation der Softwareanforderungen, Webseiten, Verträge, Modelle, Aktivitätsdiagramme usw. Auf diese Weise können wir einige Vorteile statischer Tests nutzen. Statische Tests können eine Vielzahl von Vorteilen bieten. Wenn statische Tests früh im Lebenszyklus der Softwareentwicklung eingesetzt werden, ermöglichen sie die Früherkennung von Fehlern und diesen Produkten. also fast immer viel billiger, statische Testtechniken zu verwenden, um Fehler zu finden zu beheben ist also fast immer viel billiger, statische Testtechniken zu verwenden, um Fehler zu finden und diese Fehler dann umgehend , als dies im späteren Lebenszyklus der Fall wäre. wir beispielsweise bei statischen Tests Wenn wir beispielsweise bei statischen Tests die statischen Tests auf der Grundlage der Anforderungen nach dem Dokument mit der Anforderungsbeschreibung durchgeführt haben , können wir die Mängel und fehlenden Anforderungen identifizieren fehlenden Anforderungen auf diese Weise die Fehler verhindern. Vorbeugen ist also besser als Heilen. Es wird uns also helfen, Kosten zu sparen , indem wir Testkosten und -zeit reduzieren und Entwicklungskosten und -zeit reduzieren. Oder die Senkung der Gesamtqualitätskosten über die gesamte Lebensdauer der Software, da weniger Fehler später im Lebenszyklus und nach der Auslieferung in die Produktion auftreten. Es hilft also, die Kommunikation zwischen den Teammitgliedern zu verbessern , da es sich dabei Überprüfungen oder formelle informelle Überprüfungen sodass es typischerweise Mängel gibt , die bei statischen Tests festgestellt werden können , oder Fehler. Zum Beispiel kann jede Anforderung mehrdeutige Anforderungen, Fehler, Fehlerkommission, Inkonsistenz und Redundanz enthalten . Konstruktionsfehler und Codierungsfehler werden bei statischen Tests, Abweichungen von Standards, falsche Schnittstellen, Spezifikationen, Sicherheitslücken, Lücken und Inkonsistenzen festgestellt Abweichungen von Standards, falsche Schnittstellen, Spezifikationen, Sicherheitslücken, Lücken und Inkonsistenzen bei statischen Tests, Abweichungen von Standards, falsche Schnittstellen, Spezifikationen, Sicherheitslücken, Lücken und Inkonsistenzen festgestellt. Im nächsten Thema werden wir also Überprüfungsprozess bis dahin besprechen 10. KategorienTesttechniken: Hallo und willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir also über Kategorien von Testtechniken sprechen. In Abschnitt 4.1 geht es also um Kategorien von Testtechniken. Es gibt also drei Kategorien von Testtechniken, die in diesem Lehrplan besonders erwähnt werden in diesem Lehrplan besonders erwähnt Blackbox, White-Box und erfahrungsbasiert. Wie Sie wissen, handelt es sich bei Blackbox-Testtechniken um unterschiedliche Testansätze. Da wir das System früher vom schwarzen Bass aus gesehen haben, gehen wir nicht ins Detail, sondern in der weißen Box, gehen wir ins Detail und es gibt verschiedene Testtechniken, auf die wir später eingehen werden , und Erfahrungsbasis wie sich zeigt, dass sie auf den Erfahrungen von Testan basieren, also gibt es unterschiedliche Testtechniken Wie Sie wissen, befinden wir uns im vierten Kapitel, und dies ist das erste Thema in diesem Kapitel In Kapitel vier geht es um Testtechniken. Die erste Technik ist also die Black-Box-Technik. Also in der Blackbox, Testbedingungen, Testfälle und aus der Testbasis abgeleitete Testdaten. Dazu können die Softwareanforderungen, spezifische Anwendungsfälle und die Benutzergeschichte gehören. In diesem Fall sind diese Tests also unsere Testbasis das Dokument mit der Spezifikation der Softwareanforderungen. Wenn es irgendwelche User Stories gibt, können wir das normalerweise in einer agilen Umgebung tun Wir haben User Stories und all diese Dinge geschrieben. Testfälle können also verwendet werden, um Lücken zwischen den Anforderungen und der Implementierung der Anforderungen zu erkennen zwischen den Anforderungen . Wie Sie wissen, haben wir früher Testfälle geschrieben, indem wir die Anforderungen überprüft haben, um indem wir die Anforderungen überprüft Beschreibungsdokument mit den Anforderungen zu überprüfen. Durch das Schreiben der Testfälle können wir also darum bitten, die Lücken in der Anforderung zu identifizieren. Umfang wird also auf der Grundlage des in der Aufgabenbasis getesteten Elements und der in der Testbasis angewandten Techniken gemessen in der Aufgabenbasis getesteten Elements und der . Es hängt also von der Reichweite ab. wir in der Blackbox haben, hängt davon ab, in welchem Testlevel wir uns befinden. Reichweite ist also ein Maß, das auf den in dieser Teststufe getesteten Items basiert . Wenn wir uns zum Beispiel auf Einheitsebene befinden, wird es verschiedene Erfassungstechniken geben , auf die wir später eingehen werden. Wie Sie also wissen, verwenden wir bei Black-Bus-Testtechniken die Equalenzpartitionierung Wir verfügen über Grenzwertanalysen, Entscheidungstabellen, Tests bei Zustandsübergängen und Tests in Anwendungsfällen Bei White-Box-Tests werden Testfälle und Tests also Testfälle von der Testbasis abgeleitet. In diesem Fall besteht unsere Testbasis aus Softwarecode, Softwarearchitektur, detailliertem Design und anderen Informationsquellen. Wie wir im Fall Black Bask wissen, bestand unsere Testbasis aus der Spezifikation der Softwareanforderungen In diesem Fall haben wir also den Code, weil wir White-Box- und White-Box-Tests durchführen Abdeckung wird also auf der Grundlage des innerhalb der ausgewählten Struktur getesteten Objekts gemessen . Zum Beispiel Code oder Schnittstelle. In diesem Fall befinden wir uns also innerhalb des Codes. Unsere Testbasis zur Messung der Abdeckung wird also anders sein. Wir werden das später besprechen. Daher werden bei der Spezifikation häufig zusätzliche Quellen oder Informationen verwendet zusätzliche Quellen oder Informationen , um das erwartete Ergebnis der Testfälle zu bestimmen. Im Spezifikationsdokument ist also normalerweise alles geschrieben, also leiten wir die Testfälle davon ab. In diesem Fall identifizieren wir also das Ergebnis des Testfalls. In der weißen Box, den Testtechniken, gibt es also Tests und Berichterstattung auf Aussagen und DCN-Tests und Berichterstattung Diese beiden Techniken werden also in der weißen Box angewendet. In BIG Da haben wir also Kontoauszüge getestet. Wir testen alle Anweisungen im Code. Und andere Techniken, die Tests und Berichterstattung erfordern. Also werden wir besprechen, wie wir die DCIN-Tests durchführen können und wie wir die DCN-Tabelle verwenden können Bei erfahrungsbasierten Testtechniken haben wir also Fehler bei der Annahme, dass sie auf der Erfahrung des Testers beruhen Sie verwenden also das Erraten von Fehlern. Sie raten aufgrund ihrer Erfahrung. Sie wissen, dass es wahrscheinlich ist , dass diese Glühbirne da sein wird. Deshalb führten sie früher explorative Tests und prüfungsbasierte Tests Bei Tests, die auf Schecks basieren, haben sie also die Checkliste, sodass sie identifizieren können Bei explorativen Tests untersuchen sie das Produkt und identifizieren das Problem anhand ihrer Erfahrungen Bei erfahrungsbasierten, gängigen Testtechniken gehören also erfahrungsbasierten, gängigen Testtechniken gehören die folgenden Testfälle mit Testbedingungen und aus der Testbasis abgeleitete Testdaten In diesem Fall wird unsere Testbasis das Wissen von Testern, Entwicklern oder Benutzern und deren Erfahrung beim Testen dieser Arbeitsprodukte sein. Dieses Wissen und diese Erfahrung umfassen die erwartete Nutzung der Software, ihre Umgebung, wahrscheinliche Fehler und die Verteilung dieser Fehler. Die internationale Norm ISO ICE I 3e29 119-4 enthält eine Beschreibung der Testtechniken und der entsprechenden Deckungsmaße Daher ist es sehr wichtig, die richtige Technik für unser Projekt auszuwählen für unser Projekt Bei der Erstellung von Testfällen verwenden Tester daher im Allgemeinen eine Kombination von Testtechniken, um das beste Ergebnis für ihren Testaufwand zu erzielen das beste Ergebnis für ihren Testaufwand In diesem Fall können sie erfahrungsbasierte Testtechnik verwenden Beispielsweise können sie Fehler mit der Black-Box-Testtechnik erraten , z. B. bei der Grenzwertanalyse usw. Sie verwenden also eine Kombination oder Technik, die auf dem Projekt und der Anforderung basiert Einige Techniken eignen sich eher für bestimmte Situation und ein bestimmtes Testniveau, andere für unser Testniveau. Bei einigen Techniken, wissen Sie, werden wir, wenn wir uns auf Einheitsebene befinden, die White-Box-Testtechniken anwenden , die besser geeignet sind, weil wir White-Box-Tests durchführen. Wenn wir uns auf einer höheren Ebene befinden und beispielsweise Tests zur Benutzerakzeptanz durchführen, wird die Black-Box-Testtechnik verwendet. Ein angemessenes Maß an Formalität hängt vom Testkontext ab, einschließlich des Reifegrads des Testentwicklungsprozesses, Zeitbeschränkungen, Sicherheits- und behördlichen Anforderungen Wenn es beispielsweise strenge Sicherheits- und Regelmäßigkeitsanforderungen gibt , sollten wir auf jeden Fall automatisierte Komponententests durchführen und dann früher mit dem Testen beginnen Das Wissen und die Fähigkeiten der beteiligten Personen, das Lebenszyklusmodell der Softwareentwicklung eingehalten wird Die Wahl der zu verwendenden Testtechniken hängt also von einer Reihe von Faktoren ab. Zum Beispiel die Art der Systemkomponente und damit die Art der Systemkomponente, die Komponente des Systems, Komplexität, regulatorische Standards, Kunden- und Vertragsanforderungen, Risikoniveau , Risikoarten und Testziele. Daher ist es sehr wichtig, die richtigen Techniken unter Berücksichtigung dieser Faktoren auszuwählen ist es sehr wichtig, die richtigen Techniken unter Berücksichtigung dieser Faktoren da die Auswirkungen von der verfügbaren Dokumentation, den Tests sowie den Kenntnissen und Fähigkeiten abhängen . Wenn also ein kompetenterer Test über Wissen verfügt, dann kann er eine Kombination durchführen, alle Techniken kombinieren, alle Techniken kombinieren um mehr Fehler im Arbeitsergebnis zu identifizieren. Es hängt also auch vom verfügbaren Tool ab. Sie haben Erfahrung mit den verschiedenen Tools, die mit diesem Tool zur Verfügung stehen, werden dann in der Lage sein, mehr Fehler schnell zu identifizieren. Zeit und Budget sind sehr wichtig weil wir viel Zeit und Budget zur Verfügung gestellt haben. Dann haben wir Zeit, einige Forschungsanalysen zu zwei Techniken durchzuführen , und wir können mehr Fehler identifizieren. Modell der Lebensdauer der Softwareentwicklung, erwartete Nutzung der Software, vorherige Erfahrung mit der Verwendung der Techniken auf dem zu testenden Komponentensystem und Art der in der Softwarekomponente zu erwartenden Defekte Okay, das ist es. Wir sind am Ende dieser Sitzung angelangt. In der nächsten Sitzung werden wir uns eingehend mit der Blackbug-Technik befassen. Dann von 11. Erfahrungsbasierte Testtechniken: Hallo und willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir über erfahrungsbasierte Testtechniken sprechen. Bei erfahrungsbasierten Testtechniken werden also nur die Namen genannt, bei denen wir die Erfahrung anwenden. Diese Techniken hängen also von der Erfahrung des Testers ab. Je mehr Erfahrung der Tester hat, desto mehr wird er in der Lage sein, die Fehler zu finden , und wenn der Senior beispielsweise die Junioren anleiten kann , kann er den Junior darüber informieren , dass solche Fehler auftreten werden In den erfahrungsbasierten Testtechniken können wir also Fehler finden, die mit formalen Techniken nicht möglich sind , indem wir formale Techniken anwenden Daher mischen wir in der Regel erfahrungsbasierte Techniken mit formaleren Techniken. Bei den erfahrungsbasierten Techniken haben wir Fehler beim Erraten, wobei wir die Fehler aufgrund der Erfahrung erraten Regel hängt es also vom Wissen und Können des Testers ab. Basierend auf diesen Kenntnissen und Fähigkeiten erraten sie den Fehler Sie können zum Beispiel vermuten, dass das Produkt getestet wird, und lassen Sie uns vermuten, dass sie die Feldbegrenzung für die Feldvalidierung nicht darauf angewendet haben . Das ist also eine informellere Art des Testens. Bei explorativen Tests untersuchen wir das Produkt. Explorative Tests im Allgemeinen werden erfahrungsbasierte Testtechniken angewendet, wenn uns keine Dokumentation zur Verfügung steht Insbesondere bei experimentellen Tests untersuchen wir das Produkt, da uns keine formelle Wir haben keine RS-Anforderungen, daher ist auch kein Benutzerhandbuch verfügbar Also machen wir uns auf den Weg und untersuchen das Produkt . In dieser Sitzung identifizieren wir die Lücken und erstatten dem Manager Bericht. Bei den Checkli-Tests haben wir also die Deshalb haben unsere leitenden Mitarbeiter die Checkliste auf der Grundlage ihrer Erfahrungen entwickelt Und so können wir diese Bereiche übernehmen. Zum Beispiel haben sie die Sicherheitscheckliste zum Testen entwickelt , UI-Testliste ist nur eine UI-Richtlinie. All diese sind also geschrieben. Diese auf Checklisten basierende Anleitung enthält also einige Anweisungen. also irrtümlich eine Erkundung erraten haben, haben wir keine Anleitung Techniken, die auf Checklisten basieren, haben also ihre eigenen Vorteile. Das sind also die Techniken , die in den Arbeiten erwähnt werden. Es gibt auch andere Techniken, also sollten Sie diese Techniken mit formelleren Techniken anwenden diese Techniken mit formelleren Techniken Unser Ziel ist es also , die Lücken und Probleme zu identifizieren, damit wir besser zur Qualität beitragen und unseren Kunden und Kunden qualitativ hochwertige Produkte liefern können. In diesem Sinne herzlichen Dank. Tschüss. 12. Wartungstests: Hallo, und dann komm zu einer anderen Sitzung. In dieser Sitzung werden wir also über Wartungstests sprechen. Wir befinden uns in Kapitel zwei und in Kapitel zwei, dem es um Tests während des gesamten Lebenszyklus geht. 2.4 befasst sich mit Wartungstests, und 2.4 ist unser letztes Thema in diesem Kapitel. Wann immer wir die Software entwickelt haben, haben wir sie bereitgestellt, sobald Produktionsumgebung bereitgestellt wurde und die Kunden sie verwenden, sodass die Wartung beginnt. Der Wartungszeitraum kann sich also über mehrere Jahre erstrecken. Im Laufe der Jahre pflegen wir die Software also . Wir planen, wir planen Aktivitäten und ungeplante Aktivitäten. planen also Aktivitäten, wann immer sie vom Kunden eine Änderung verlangen oder wenn sich eine Umgebung geändert hat und so weiter ungeplanten Aktivitäten gibt es beispielsweise Sicherheitsprobleme oder -mängel , die wir sofort beheben müssen Wartungstests sind daher sehr wichtig. Wenn im Rahmen der Wartung Änderungen vorgenommen werden, sollten Wartungstests durchgeführt werden. Eine Wartungsversion kann Wartungstests auf mehreren Teststufen erfordern . Mehrere Teststufen bedeuten also, dass die Systemakzeptanz innerhalb der Einheit erfolgen kann Systemakzeptanz innerhalb der Einheit wobei je nach Umfang verschiedene Testtypen verwendet werden. Es hängt also von seinem Umfang ab. Lassen Sie uns also über den Umfang der Wartungstests sprechen. Der Umfang ist also der Grad des Risikos der Änderung. Zum Beispiel der Grad, in dem der Änderungsbereich der Software mit anderen Komponenten des Systems kommuniziert anderen Komponenten des Systems Also die Größe des bestehenden Systems, wenn also die Größe des bestehenden Systems groß ist, dann wird der Anwendungsbereich groß sein Der Umfang der Änderung, wenn die Auswirkungen groß sind, dann wird der Umfang groß sein, und wir müssen viel Arbeit in Bezug auf Tests tun. Regressionstests und erneute Tests werden also auf allen Teststufen durchgeführt Es gibt einige Auslöser für Wartungstests. So gibt es zum Beispiel bei einigen Planänderungen mehrere Gründe, warum Software gewartet wird und somit Wartungstests stattfinden, sowohl ungeplant als auch geplant ungeplant Änderungen, z. B. beim Planen von geplanten Erweiterungen, kann es einige Verbesserungen geben, es kann einige Versionen geben, wir haben die Veröffentlichungen geplant Es kann also einen Migrationsplan geben. Zum Beispiel sind wir von einer Plattform auf eine andere migriert Angenommen, wir haben von Windows zu Mac OS gewechselt. Es kann also Ausmusterung kommen, weil Software nach langer Zeit in den Ruhestand geht Wenn wir also über Wartungstests und Internet nach allem sprechen , dann wird es komplexer Daher werden Tests auf Testebene erforderlich sein. Ob Netzwerkebene oder Anwendungsebene, wir überprüfen auch den Sicherheitsaspekt und Datenschutzaspekt, da wir im Internet der Dinge physische Geräte haben. Wir haben Serces Layer. Wir haben Kommunikationsschicht, Suchschicht und API-Kommunikation, Kommunikation Drittanbietern und so weiter Im Fall des Internet der Dinge können Wartungstests also durch die Einführung völlig neuer oder modifizierter Dinge ausgelöst werden . Zum Beispiel Hardwaregeräte , Ergänzungen und so weiter. Daher müssen die Auswirkungen von Wartungstests, die Nebenwirkung und der betroffene Bereich im die Nebenwirkung und der betroffene Bereich im System auf Regression getestet werden Eine Folgenabschätzung kann durchgeführt werden, bevor eine Änderung vorgenommen wird. Deshalb führen wir immer dann eine Folgenabschätzung durch, wenn wir Wartungstests planen. Deshalb planen wir die Ressourcen entsprechend. Wir planen die Zeit, den Zeitplan und so weiter. Analysieren Sie die Auswirkungen der Änderungen , die für Wartungsarbeiten vorgenommen wurden, um die beabsichtigten Folgen sowie die erwarteten und möglichen Nebenwirkungen der Änderung zu ermitteln sowie die erwarteten und möglichen Nebenwirkungen der Änderung Eine Folgenabschätzung kann sich daher als schwierig erweisen. Wenn also die Spezifikation, zum Beispiel Geschäftsanforderung oder die Anwenderstory, Dokumente zur Architekturplanung nicht mehr vorhanden sind oder fehlen. Wenn wir also keine Unterlagen haben, wird es schwierig sein, die Auswirkungen zu analysieren. Wir können die Folgenabschätzung nicht korrekt durchführen. Wenn keine Aufgabenfälle geschrieben wurden, kann das ein Grund sein. bidirektionale Rückverfolgbarkeit zwischen Aufgabenbasis und Aufgabenfall wird beibehalten Und dein Sport ist, dass wir nicht existieren. Die beteiligten Personen verfügen nicht über Domänen- oder Systemkenntnisse. Wenn unser Team also noch frisch ist oder kein Experte auf diesem Gebiet ist , wird es schwierig sein, die Auswirkungen zu analysieren. wurde zu wenig Aufmerksamkeit Bei der Entwicklung von Software wurde zu wenig Aufmerksamkeit geschenkt. Bei der Entwicklung sollten wir also auch berücksichtigen, dass diese Software im Laufe der Jahre laufen wird und dass dies auch weiterhin der Fall sein wird. Deshalb sollten wir die besten Programmierpraktiken anwenden. Zusammenfassend lässt sich sagen, dass Wartungstests ein wichtiger Teil des Lebenszyklus der Softwareentwicklung sicherstellen, dass die Anwendung nach jeder Änderung stabil, funktionsfähig und sicher bleibt nach jeder Änderung stabil, funktionsfähig und sicher Wenn wir also die Änderung vorgenommen haben, stellen Sie sicher, dass sich die Änderung nicht negativ auf die anderen Module ausgewirkt hat und keine neuen Fehler verursacht hat. Es gibt keine Sicherheitslücken aufgrund dieser Änderungen und so weiter Durch einen systematischen Ansatz für Wartungstests können Unternehmen Risiken minimieren und die Zuverlässigkeit und Leistung ihrer Anwendung im Laufe der Zeit aufrechterhalten die Zuverlässigkeit und Leistung ihrer Anwendung im Laufe der Zeit Das ist es also. Ich danke dir vielmals. Tschüss. 13. SDM: Hallo und willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir über Softwareentwicklungsmodelle sprechen. Da wir unser erstes Kapitel über grundlegende Tests abgeschlossen haben . Jetzt sind wir in Kapitel zwei, dem es um das Testen des Lebenszyklus geht. In Kapitel zwei haben wir also ein Softwareentwicklungsmodell, das etwa 2.1 und 2.2 umfasst Wir werden uns mit den Teststufen befassen. 2.3 werden wir über Testtypen sprechen, und dann werden wir im letzten 2.4 über Wartungstests sprechen. Wir haben also viele Lebenszyklusmodelle für die Softwareentwicklung, Wasserfallmodell, also ein sequentielles Entwicklungsmodell, und dann ein gemeinsames Modell Dann haben wir iterative Modelle. Wir werden all diese nacheinander besprechen. Zuallererst, die Industrie, folgten wir dem Wasserfall-Modell. Im Wasserfallmodell haben wir einen sequentiellen Ablauf von Schritten, in denen die Anforderungen erfasst werden Dann gehen wir zu den Systemanforderungen über. Nach den Geschäftsanforderungen gehen wir zu den Systemanforderungen über, dann entwerfen wir und dann detailliert, dann programmieren wir und testen nach dem Testen, wir liefern Produkte an Kunden. Beim Modell Water Far können wir also nicht zurückgehen, wenn wir eine Phase abgeschlossen haben. Um dieses Problem zu lösen, folgen wir dem V-Modell. V-Modell, wir haben entsprechende Testaktivitäten. In der Phase der Geschäftsanforderungen führen wir beispielsweise Akzeptanztests durch. Wenn wir uns in der Phase der Systemanforderungen befinden, führen wir Systemtests durch. Wenn wir uns in der Phase des Architekturentwurfs befinden, führen wir Integrationstests durch. Also testen wir das System, das gesamte System, um sicherzustellen, dass sie zusammenarbeiten. Wir testen viele Teile, bei denen es sich um Integrationen von Drittanbietern usw. handeln kann. Beim detaillierten Design führen wir Komponententests auf Einheitenebene durch, auf Ebene der Codierungseinheiten führen wir Komponententests durch. Diese werden also im V-Modell durchgeführt. Und wie Sie wissen, ist das QA-Team beteiligt. Daher nehmen sie normalerweise an der Überprüfung teil. Sie finden die Probleme heraus, und es handelt sich somit um eine verbesserte Version im Vergleich zu einem Modell mit Wasserfallfunktion. Mm. Im Testlebenszyklus, in jedem Lebenszyklusmodell der Softwareentwicklung, gibt es mehrere Merkmale eines guten Testens. Wenn wir also sagen, dass dies ein gutes Modell ist, zeigt das, dass es in jeder Aktivität eine entsprechende Testaktivität gibt. Wissen Sie, wenn wir uns zum Beispiel in der Entwicklungsphase befinden, machen wir Einheiten, die wir entwickeln, also werden Unit-Tests durchgeführt. Jede Teststufe hat also Testziele, die für diese Stufe spezifisch sind. Testanalyse und das Testdesign für ein bestimmtes Testlevel beginnen also bestimmtes Testlevel beginnen während der entsprechenden Entwicklungsaktivitäten. Wenn wir also die Software auf Einheitsebene entwickeln, führen wir Unit-Tests durch. Also das QA-Team auf dieser Ebene, das QA-Team analysiert und designt und White-Box-Tests werden durchgeführt. Wenn wir also White-Bulk-Tester haben, führen sie White-Bak-Tests durch Tester nehmen also an Diskussionen teil, um eine definierte Anforderung beim Design oder bei der Herstellung Ihres Produkts zu definieren Design oder bei der Herstellung Ihres Produkts zu Daher ist die Teilnahme der Tester in jeder Phase sehr wichtig. Lassen Sie uns nun über das Lebenszyklusmodell der Softwareentwicklung sprechen . Wissen Sie, wie bei Mardel bei der sequentiellen Entwicklung beschreiben wir den Softwareentwicklungsprozess einen linearen sequentiellen Fluss Bei der inkrementellen Entwicklung hingegen definieren wir bei Mardel das Anforderungsdesign . Wir testen das System auf PCs, was bedeutet, dass die Softwarefunktionen schrittweise erweitert werden. Im iterativen Entwicklungsmodell definieren wir die Anforderungen also in Bezug auf die Art der Funktionen Wir entwerfen, bauen und testen diese wenigen Funktionen gemeinsam in Form von seriellen internen Zyklen Oft feste Länge und Dauer. Das kann zum Beispiel eine Woche, zwei Wochen, drei Wochen oder vier Wochen sein. In Agile Scrum folgen wir in der Regel dem Druck von zwei Wochen. In diesem Sprint definieren wir also die Anforderungen an die Funktionen und liefern diese Funktionen innerhalb von zwei Wochen Im iterativen Entwicklungsmodell haben wir einen rationalen, einheitlichen Prozess Bei einem rationalen einheitlichen Prozess dauert die Iteration also in der Regel relativ lang, beispielsweise zwei oder drei Monate In Scrum ist jede Iteration relativ kurz. Das können Tage oder wenige Wochen sein. Die Funktionsinkremente sind also gering. Es kann Verbesserungen geben, zwei oder drei neue Funktionen werden in jedem Inkrement hinzugefügt In Kanban kann es sich um eine Iteration mit fester Länge oder ohne Iteration G can burn Boards haben keine feste Länge und keine Iterationen mit fester Länge keine Iterationen mit fester Wir folgen den Sprints nicht wie in Agile Scrum. Im Gegensatz zur Erstellung experimenteller Inkremente in Spiralprototypen Erstellung experimenteller Inkremente in Spiralprototypen Lassen Sie uns also über ein Jacrum-Framework sprechen. In einem Jazz-Scrum haben wir einen Produktrückstand. Alle Produktfunktionen sind also im Produkt-Backlog aufgeführt Normalerweise listen wir all diese in unserem Tool auf, das Jira heißt, und wir führen ein Sprint-Planungstreffen Alle Funktionen werden in unserem Sprint-Planungstreffen besprochen Also kommt das Team zusammen und diskutiert. Sprints können also eine Woche, zwei Wochen, drei Wochen oder vier Wochen dauern, bis zu vier Wochen Nach vier Wochen stellen wir diese Funktionen unseren Kunden zur Verfügung. Mm. Also Sprints, wenn wir die Sprints definieren, und während Sprints können wir keine neuen Funktionen hinzufügen Also führen wir tägliche Stand-up-Meetings durch, bei denen das Team zusammenkommt und bespricht, was jeder Einzelne besprochen hat, was er oder sie am letzten Tag getan hat, was er oder sie heute tut und gibt es irgendwelche Hindernisse Und dann haben wir normalerweise während des Sprints Sprint-Reviews gemacht, Reviews in der Mitte des Sprints. Und nach dem Ende machen wir, wir haben unseren Auftritt beendet, wir haben alle Funktionen fertiggestellt. Wir machen Sprint-Rektosekte. In der Sprint-Retrospektive besprechen wir, was schief gelaufen ist, was verbessert werden kann usw. So können wir uns im nächsten Sprint verbessern. Daher ist ein kontextbezogenes Softwareentwicklungsmodell sehr wichtig. Wenn wir ein Lebenszyklusmodell für die Softwareentwicklung für unser Projekt auswählen Lebenszyklusmodell für die Softwareentwicklung , sollten wir die Kontexte im Auge behalten. Softwareentwicklungsmodell muss ausgewählt und an den Projektkontext und die spezifischen Merkmale angepasst werden. Ich nehme an, es ist das Szenario, alles ist perfekt, die Anforderungen können nicht geändert werden. Alles ist perfekt und wir haben viel Zeit. Dann ist in diesem Fall das Wasser-FD-Modell nützlich. Aber normalerweise ändern sich in der realen Welt die Dinge, die Anforderungen ändern sich. Also folgten wir früher anderen Modellen, zum Beispiel Gil Scrum In diesem Fall können wir diese Modelle also auch kombinieren, zum Beispiel können wir Scrum mit dem V-Modell kombinieren, und so weiter, je nach Anforderung, insbesondere im Fall des Internet der Dinge, wir haben physische Geräte, wir haben APIs, wir haben eine Serviceebene Wir haben viele Dinge, die miteinander verbunden sind. In diesem Fall ist es für ein bestimmtes Modell also eine große Herausforderung. Für jede Phase sollten wir also bei Bedarf ein anderes Modell Wir können das Modell kombinieren. Wir können unser Kundenmodell erstellen. Das hängt von Projekt Produkt und Projekteigenschaften ab. Das war's also für diese Lektion. Dann danke ich dir vielmals. Tschüss. 14. Teststufen: Willkommen zu einer weiteren Sitzung. Wir sind im zweiten Kapitel und in Abschnitt 2.2 geht es um Teststufen. In der Teststufe stellen wir also sicher, dass wir in jeder Teststufe die gewünschte Qualität erreicht haben . Im unteren Bereich haben wir Unit-Tests. Wir stellen also sicher, dass Komponententests einheitlich sind was bedeutet, dass einzelne Komponenten gut getestet wurden und keine Fehler auf eine höhere Ebene übersprungen werden Auf der höheren Ebene haben wir also einen Systemtest, Integrationstest an der Spitze und einen Benutzerakzeptanztest Wir haben Alpha-Tests und Betatests. Alpha-Tests werden also in der Softwareentwicklungsabteilung durchgeführt. Die Kontrollumgebung , in der Betatests durchgeführt werden, aber von einem breiteren Publikum durchgeführt werden. Wenn wir also über Komponententests sprechen, sie normalerweise von Entwicklern durchgeführt. Integrationstests werden von Testern durchgeführt, Systemtests werden von Testern durchgeführt und Akzeptanztests werden von Endbenutzern durchgeführt In diesem Kapitel haben wir also vier Stufen Komponententests, die auch als Komponententests, Integrationstests, Systemtests und Abnahmetests bezeichnet werden. Testlevel ist also eine Gruppe von Testaktivitäten, die gemeinsam organisiert und verwaltet werden. Teststufen zeichnen sich also durch folgende Eigenschaften und spezifische Ziele aus. Jede Teststufe hat also ein bestimmtes Ziel für diese Stufe. Die Testbasis bezieht sich auf Drive-Testfälle. Testobjekte, d. h. das, was getestet wird , und in der Regel Fehler und Fehler, spezifische Herangehensweisen und Verantwortlichkeiten. Wenn wir also über Komponententests sprechen , konzentrieren sich Komponententests, auch bekannt als Tests auf Einheiten- oder Modulebene , auf jede einzelne Komponente, die testbar ist Sehen Sie, zu objektiven Tests oder Komponententests gehören also auch die Reduzierung des Risikos Diese Ziele galten also für alle Teststufen. Wir reduzieren das Risiko und überprüfen, ob das funktionale und das nicht funktionale Verhalten der Komponenten oder Systeme spezifiziert sind. So bauen wir Vertrauen in die Qualität der Komponente auf. So können wir Vertrauen aufbauen. Also haben wir einen Test. Wir haben die Tests auf Komponentenebene durchgeführt. Wir haben Reviews durchgeführt, wir haben White-Bug-Tests durchgeführt. Normalerweise werden Tools beim Testen von Einheiten verwendet. also Fehler in dieser Komponente finden , können wir nicht zu einem höheren Testlevel übergehen. Prävention ist also sehr wichtig. So können wir verhindern die Fehler in Richtung eines höheren Testniveaus bewegen. Als Testgrundlage für Komponententests dienen detaillierte Entwurfs- und Codedatenmodule Also auf Codeebene, zum Beispiel Komponententests, kann es eine Klasse geben, es kann Datenmodule Testobjekte, in der Regel Testobjekte für Modulcode von Komponententesteinheiten, datenstrukturierte Klassen, Datenbankmodule usw. Wenn wir also über Integrationstests sprechen, die in Abschnitt 2.2 0.2 beschrieben sind. Integrationstests konzentrieren sich also auf Interaktionen zwischen Komponentensystemen. Zum Ziel von Integrationstests gehört, Ziel von Integrationstests wie bereits erwähnt, die Reduzierung des Risikos. Bei Integrationstests werden also alle Komponenten zusammen integriert, sodass wir den Datenfluss überprüfen. Bei Integrationstests überprüfen wir also, ob das funktionale und das nicht funktionale Verhalten der Schnittstellen dem Entwurf und den Spezifikationen entspricht. Vertrauen in die Qualität der Schnittstellen aufbauen. Auf dieser Integrationsebene testen wir also die Komponenten, testen wir also die Komponenten indem wir ihren Datenfluss überprüfen, indem wir sie integrieren. So bauen wir das Vertrauen auf dieser Ebene auf. Das Auffinden von Fehlern, die möglicherweise an den Schnittstellen selbst liegen erfolgt innerhalb der Komponente oder des Systems. So wird verhindert, dass Fehler auf ein höheres Testniveau gelangen. Testbasis für diese Integrationstests sind also Software, unser Systemdesign und Sequenzdiagramme, sodass wir Schnittstellen und jedes Kommunikationsprotokoll spezifizieren können jedes Kommunikationsprotokoll spezifizieren Es kann Anwendungsfälle, Architekturkomponenten, Workflows, Definitionen externer Schnittstellen geben, diese Dokumente können vorhanden sein. Testen Sie also das Objekt. Typischerweise umfassen Tests für Integrationstests Subsystemdatenbanken, Infrastrukturschnittstellen, Anwendungsprogrammierschnittstellen und Mikrostrukturen Dies sind Testobjekte für Integrationstests. Wenn wir über Systemtests sprechen, dann konzentrieren sich Systemtests auf das Verhalten und Fähigkeiten des gesamten Systems oder Protokolls. Also testen wir das System als Ganzes. Wir haben also ein integriertes System, das funktioniert. Systemtests erhalten häufig Informationen , die von den Beteiligten verwendet werden, um eine Entscheidung über die Veröffentlichung zu treffen Systemtests können auch die gesetzlichen Anforderungen erfüllen gesetzlichen Anforderungen erfüllen Unabhängiger Tester, in der Regel kann es einen Tester von Drittanbietern geben , der Systemtests durchführt. Ihre Ergebnisse sind daher für die Interessengruppen sehr wichtig. Testbasis unserer Systemtests umfasst also das System, unsere Softwareanforderungsspezifikation, wir haben SRS-Dokumente Im SRS-Dokument haben wir also funktionale, nicht funktionale Anforderungen Wir haben einen Risiko-LC-Bericht, Anwendungsfälle, Epen und Anwenderberichte Wenn wir AJR Scrum folgen, haben wir Epix Module sind also Systemverhalten, Zustandsdiagramm, System, sind Also typischerweise Testobjekt für Systemtestanwendungen, Hardware- und Softwaresysteme, Betriebssysteme, testende Systeme, also Systemkonfigurations - und Konfigurationsdaten. Lassen Sie uns also über Akzeptanztests sprechen, die in Abschnitt 2.2 0.4 behandelt werden. Abnahmetests wie Systemtests konzentrieren sich in der Regel auf das Verhalten und die Fähigkeiten des Systems als Gesamtsystem. Bei den Abnahmetests handelt es sich also objektive Abnahmetests, die Vertrauen in die Qualität des Gesamtsystems schaffen und dazu führen, dass das System vollständig ist und wie erwartet funktioniert. Überprüfung, ob das funktionale und das nichtfunktionale Verhalten des Systems spezifiziert sind Bei den Abnahmetests führen wir also Alpha-Tests und Betatests Wir führen Benutzerakzeptanztests, betriebliche Abnahmetests durch und vertragliche behördliche Abnahmetests durchgeführt. Alpha-Tests werden in der Kontrollumgebung durchgeführt. In der Regel führt das Qualitätssicherungsteam, das interne Team Alpha-Tests durch Regel führt das Qualitätssicherungsteam, das interne Team Alpha-Tests und Betatests werden von unseren Endbenutzern durchgeführt. Spezifische Ansätze und Verantwortlichkeiten. Für Abnahmetests sind häufig der Kunde, der Geschäftsanwender, die Produktinhaber oder die Betreiber des Systems verantwortlich , oder es können auch andere Beteiligte beteiligt sein Abnahmetests durchgeführt Bei der Installation oder Integration von Cord-Softwareprodukten können Daher kann es sein, dass vor dem Systemtest ein Abnahmetest für eine neue Funktionserweiterung durchgeführt wird. Testgrundlagen für Abnahmetests gehören Geschäftsprozesse, Benutzeranforderungen, Vorschriften und Verträge sowie Standardanwendungsfälle. Es kann Anwendungsfälle, Dokumente, Dokumente Systemanforderungen , System - Benutzerdokumentation und Installationsverfahren geben. Also haben wir das Installationsverfahren definiert, wir können installieren, wie wir die Software installieren können. Der Risikoanalysebericht kann also da sein. Testobjekten für Abnahmetests gehören das zu testende System, Daten zur Überprüfung der Systemkonfiguration, Geschäftsprozesse für ein vollständig integriertes System, Wiederherstellungssystem und die Host-Seite Aus Gründen der Geschäftskontinuität und der Notfallwiederherstellung ist es daher sehr wichtig, die Wiederherstellung zu planen, damit wir Failover-Systeme, Betriebs- und Wartungsprozesse für Berichte, vorhandene und konvertierte Produktionsdaten usw. Es ging also um die Teststufen, die sehr wichtig sind Zumindest solltest du über ihre Stufen Bescheid wissen. Wie wir in dieser Sitzung besprochen haben, haben wir im unteren Teil Tests auf Unit-Ebene, die vom Entwickler durchgeführt werden, dann haben wir Integrationstests, Akzeptanztests und so weiter. In diesen Labels gab es also vier Komponententests, Integrationssysteme und Abnahmetests. Also das ist es. Ich danke dir vielmals. Tschüss. 15. Testprinzipien: Hallo, willkommen zu einer weiteren Sitzung. Dies ist eine sehr interessante Sitzung, da ich in dieser Sitzung über Ihre Testprinzipien sprechen werde. Dieses Thema ist in Kapitel eins enthalten, und in Abschnitt 1.3 behandeln wir die Prinzipien des Testens. Wir haben also sieben Testprinzipien. Prinzip eins ist, dass das Testen das Vorhandensein von Fehlern zeigt. Prinzip zwei: Eine erschöpfende Prüfung ist nicht möglich. Prinzip drei: Frühzeitiges Testen. Prinzip vier ist die Clusterbildung von Defekten, Prinzip fünf ist das Pestizid-Paradoxon Prinzip sechs: Tests sind kontextabhängig, Prinzip 7: Fehlerfreiheit FLC Diese Testprinzipien sind sehr wichtig. Diese sind nicht theoretisch, praktisch umgesetzt, sodass sich jeder Tester dessen bewusst sein sollte. Dieses Prinzip bietet eine Grundlage für fundierte Entscheidungen während des Testprozesses. Durch die Anwendung dieser Prinzipien können sich die Tester also auf Bereiche mit hohem Risiko konzentrieren. Wenn wir zum Beispiel sagen, dass umfassende Tests unmöglich sodass wir nicht alles testen können, sollten wir uns auf Bereiche mit hohem Risiko konzentrieren, häufige Fallstricke vermeiden und sicherstellen, dass ihre Tests sowohl effizient als auch wirksam Schauen wir uns also das erste Prinzip im Detail an. Tests zeigen das Vorhandensein eines Defekts. Die Prüfung zeigt das Vorliegen eines Fehlers, nicht dessen Fehlen. Wir können also nicht sagen, dass wir zu 100% getestet haben, sodass es keine Fehler gibt. Es ist möglich, dass wir die Anforderung nicht erfüllt haben. Tests können also zeigen , dass Fehler in der Systemsoftware vorhanden sind , aber unabhängig von der Anzahl der Fehler, die wir zu einem Zeitpunkt gefunden haben, können wir nicht sagen, dass es keine Fehler mehr gibt. Deshalb können wir auch in diesem Fall nicht sagen, dass wir diese nicht als Beweis für die Richtigkeit vorlegen können. Das nächste Prinzip ist also, dass erschöpfende Tests unmöglich sind. Alles zu testen, jede Permutation ist unmöglich. Es kann also viele Eingabekombinationen geben. Es ist also nicht möglich, alles in begrenzter Zeit und mit begrenztem Budget zu testen . Als Alternative zu umfassenden Tests sollten Risikoanalysen und Prioritäten verwendet werden, um Risikoanalysen und Prioritäten sich auf die Testbemühungen zu konzentrieren Lassen Sie mich also ein Beispiel nennen. Zum Beispiel gibt es einen Bildschirm auf der Seite. Es gibt 515 Eingabefelder für Entschuldigung denen jedes fünf mögliche Werte akzeptiert Um zu testen, kann die Anzahl der erforderlichen Testfälle also zwischen fünf und 15 liegen Sie können also sehen, dass es mehr als 30 Millionen Testfälle geben kann . Wir können also nicht innerhalb der begrenzten Zeit und des begrenzten Budgets testen. Umfassende Tests sind also unmöglich. Jeder Tester sollte sich von Okay bewusst sein. Und das dritte Prinzip ist das frühe Testen. Frühzeitiges Testen spart Zeit und Mühe. Wie Sie hier sehen können, können Sie die Fehler sehen. Sie können sehen, dass Bugs immer größer werden. Auf der rechten Seite haben wir Zeit, wir haben Zeit, wenn Bugs gefunden werden. Im oberen Pfeil sind das Budget und die damit verbundenen Kosten aufgeführt. Wie Sie in der Spezifikation sehen können, ist der Bug im Design kleiner und wird immer größer im Code sowie beim Testen und Releasen. In der Release-Phase ist es also am teuersten, ihn zu beheben, und es wird mehr Zeit in Anspruch nehmen. Um Fehler früher zu finden oder um zu verhindern, dass Fehler während der Entstehung von Fehlern auftreten, müssen die Tester so früh wie möglich in den Entwicklungszyklus einbezogen werden . Daher müssen die Testaktivitäten mit den entsprechenden Entwicklungsaktivitäten koordiniert werden . Sie sollten mit der Spezifikation beginnen. Also sollten wir Linkstests durchführen. Das Testen sollte also beginnen, sobald das Projekt beginnt. Tester leisten also gute Beiträge zu Rezensionen und müssen daran teilnehmen Dies hilft ihnen, die Anforderungen früher zu verstehen und die Aufgabenfälle zu einem früheren Zeitpunkt im Lebenszyklus vorzubereiten einem früheren Zeitpunkt im Lebenszyklus Daher sollte der Testfall früher vorbereitet werden , bevor der Code geschrieben wird. Im vierten Prinzip geht es also um das Clustering von Defekten. Sie kennen also die 80-20-Regel, 80% Bugs in 20% Modulen gefunden werden Der Defekt ist also gebündelt. Es ist möglich, dass mehr Fehler in den Malar-Modulen gebündelt sind , als wenn sie auf größere und andere Module verteilt In dieser Hinsicht muss ein Tester also proportionale Testfälle berücksichtigen und vorbereiten, um ein solches System zu testen Lassen Sie uns nun über das Pestizid-Paradoxon sprechen. Also das Prinzip ist fünf und wir sprechen davon, dass unser Test immun wird Wenn also dieselben Tests immer und immer wieder vorbereitet werden , helfen dieselben Testfälle, über die wir lernen, irgendwann dieselben Testfälle, über die dabei , neue Fehler zu finden. Wenn dies zum Beispiel sowohl für manuelle als auch für automatisierte Tests im Automatisierungsfall gilt und wir das Skript geschrieben haben, führen wir dasselbe Skript immer wieder aus. Ich werde keine neuen Bugs finden. Also sollten wir uns verbessern, wir sollten unsere Testfälle aktualisieren, egal ob diese manuell oder automatisiert sind. Dieses Prinzip hilft also auch , unsere Testfälle zu verbessern und zu wachsen. dieses Problem zu lösen, müssen die Testfälle für Pestizide also irgendwann überprüft und überarbeitet nächste Testprinzip ist also , dass das Testen kontextabhängig ist In diesem sechsten Prinzip sprechen wir also über den Kontext. Das Testen wird also in verschiedenen Kontexten unterschiedlich durchgeführt. Wenn wir es beispielsweise mit lebensrettenden Anwendungen zu tun haben, werden sich unsere Kontexte unterscheiden wenn wir die E-Commerce-Website testen. Zwei verschiedene Softwaretests mit unterschiedlichen Strategien. Ihre Strategien für Automatisierung und manuelle Tests werden unterschiedlich sein. Schauen wir uns nun das siebte Prinzip an, das darin besteht, dass das Fehlen von Fehlern falsch ist. Daher ist es letztlich wichtig, die Anforderungen zu erfüllen. nicht möglich, einen Reparaturfehler zu finden, wenn das gebaute System die Bedürfnisse und Erwartungen der Benutzer nicht erfüllt. Wenn wir also das System gebaut haben und es bereits vor einem Bug steht, es aber die Benutzeranforderungen nicht erfüllt, dann wird es als System verwendet. In diesem Prinzip geht es also um dieses Thema. Also sollten wir die Kunden einbeziehen, wir folgen der Ajil-Philosophie, Methodik der kindlichen Entwicklung Unsere Kunden sind also involviert, also sollten sie über die Fortschritte auf dem Laufenden gehalten werden Es ist also besser, all diesen Prinzipien zu folgen. Deshalb sollten wir uns all dieser Dinge bewusst sein. Vielen Dank. Tschüss. 16. Teststufen: Willkommen zu einer weiteren Sitzung. Wir sind im zweiten Kapitel und in Abschnitt 2.2 geht es um Teststufen. In der Teststufe stellen wir also sicher, dass wir in jeder Teststufe die gewünschte Qualität erreicht haben . Im unteren Bereich haben wir Unit-Tests. Wir stellen also sicher, dass Komponententests einheitlich sind was bedeutet, dass einzelne Komponenten gut getestet wurden und keine Fehler auf eine höhere Ebene übersprungen werden Auf der höheren Ebene haben wir also einen Systemtest, Integrationstest an der Spitze und einen Benutzerakzeptanztest Wir haben Alpha-Tests und Betatests. Alpha-Tests werden also in der Softwareentwicklungsabteilung durchgeführt. Die Kontrollumgebung , in der Betatests durchgeführt werden, aber von einem breiteren Publikum durchgeführt werden. Wenn wir also über Komponententests sprechen, sie normalerweise von Entwicklern durchgeführt. Integrationstests werden von Testern durchgeführt, Systemtests werden von Testern durchgeführt und Akzeptanztests werden von Endbenutzern durchgeführt In diesem Kapitel haben wir also vier Stufen Komponententests, die auch als Komponententests, Integrationstests, Systemtests und Abnahmetests bezeichnet werden. Testlevel ist also eine Gruppe von Testaktivitäten, die gemeinsam organisiert und verwaltet werden. Teststufen zeichnen sich also durch folgende Eigenschaften und spezifische Ziele aus. Jede Teststufe hat also ein bestimmtes Ziel für diese Stufe. Die Testbasis bezieht sich auf Drive-Testfälle. Testobjekte, d. h. das, was getestet wird , und in der Regel Fehler und Fehler, spezifische Herangehensweisen und Verantwortlichkeiten. Wenn wir also über Komponententests sprechen , konzentrieren sich Komponententests, auch bekannt als Tests auf Einheiten- oder Modulebene , auf jede einzelne Komponente, die testbar ist Sehen Sie, zu objektiven Tests oder Komponententests gehören also auch die Reduzierung des Risikos Diese Ziele galten also für alle Teststufen. Wir reduzieren das Risiko und überprüfen, ob das funktionale und das nicht funktionale Verhalten der Komponenten oder Systeme spezifiziert sind. So bauen wir Vertrauen in die Qualität der Komponente auf. So können wir Vertrauen aufbauen. Also haben wir einen Test. Wir haben die Tests auf Komponentenebene durchgeführt. Wir haben Reviews durchgeführt, wir haben White-Bug-Tests durchgeführt. Normalerweise werden Tools beim Testen von Einheiten verwendet. also Fehler in dieser Komponente finden , können wir nicht zu einem höheren Testlevel übergehen. Prävention ist also sehr wichtig. So können wir verhindern die Fehler in Richtung eines höheren Testniveaus bewegen. Als Testgrundlage für Komponententests dienen detaillierte Entwurfs- und Codedatenmodule Also auf Codeebene, zum Beispiel Komponententests, kann es eine Klasse geben, es kann Datenmodule Testobjekte, in der Regel Testobjekte für Modulcode von Komponententesteinheiten, datenstrukturierte Klassen, Datenbankmodule usw. Wenn wir also über Integrationstests sprechen, die in Abschnitt 2.2 0.2 beschrieben sind. Integrationstests konzentrieren sich also auf Interaktionen zwischen Komponentensystemen. Zum Ziel von Integrationstests gehört, Ziel von Integrationstests wie bereits erwähnt, die Reduzierung des Risikos. Bei Integrationstests werden also alle Komponenten zusammen integriert, sodass wir den Datenfluss überprüfen. Bei Integrationstests überprüfen wir also, ob das funktionale und das nicht funktionale Verhalten der Schnittstellen dem Entwurf und den Spezifikationen entspricht. Vertrauen in die Qualität der Schnittstellen aufbauen. Auf dieser Integrationsebene testen wir also die Komponenten, testen wir also die Komponenten indem wir ihren Datenfluss überprüfen, indem wir sie integrieren. So bauen wir das Vertrauen auf dieser Ebene auf. Das Auffinden von Fehlern, die möglicherweise an den Schnittstellen selbst liegen erfolgt innerhalb der Komponente oder des Systems. So wird verhindert, dass Fehler auf ein höheres Testniveau gelangen. Testbasis für diese Integrationstests sind also Software, unser Systemdesign und Sequenzdiagramme, sodass wir Schnittstellen und jedes Kommunikationsprotokoll spezifizieren können jedes Kommunikationsprotokoll spezifizieren Es kann Anwendungsfälle, Architekturkomponenten, Workflows, Definitionen externer Schnittstellen geben, diese Dokumente können vorhanden sein. Testen Sie also das Objekt. Typischerweise umfassen Tests für Integrationstests Subsystemdatenbanken, Infrastrukturschnittstellen, Anwendungsprogrammierschnittstellen und Mikrostrukturen Dies sind Testobjekte für Integrationstests. Wenn wir über Systemtests sprechen, dann konzentrieren sich Systemtests auf das Verhalten und Fähigkeiten des gesamten Systems oder Protokolls. Also testen wir das System als Ganzes. Wir haben also ein integriertes System, das funktioniert. Systemtests erhalten häufig Informationen , die von den Beteiligten verwendet werden, um eine Entscheidung über die Veröffentlichung zu treffen Systemtests können auch die gesetzlichen Anforderungen erfüllen gesetzlichen Anforderungen erfüllen Unabhängiger Tester, in der Regel kann es einen Tester von Drittanbietern geben , der Systemtests durchführt. Ihre Ergebnisse sind daher für die Interessengruppen sehr wichtig. Testbasis unserer Systemtests umfasst also das System, unsere Softwareanforderungsspezifikation, wir haben SRS-Dokumente Im SRS-Dokument haben wir also funktionale, nicht funktionale Anforderungen Wir haben einen Risiko-LC-Bericht, Anwendungsfälle, Epen und Anwenderberichte Wenn wir AJR Scrum folgen, haben wir Epix Module sind also Systemverhalten, Zustandsdiagramm, System, sind Also typischerweise Testobjekt für Systemtestanwendungen, Hardware- und Softwaresysteme, Betriebssysteme, testende Systeme, also Systemkonfigurations - und Konfigurationsdaten. Lassen Sie uns also über Akzeptanztests sprechen, die in Abschnitt 2.2 0.4 behandelt werden. Abnahmetests wie Systemtests konzentrieren sich in der Regel auf das Verhalten und die Fähigkeiten des Systems als Gesamtsystem. Bei den Abnahmetests handelt es sich also objektive Abnahmetests, die Vertrauen in die Qualität des Gesamtsystems schaffen und dazu führen, dass das System vollständig ist und wie erwartet funktioniert. Überprüfung, ob das funktionale und das nichtfunktionale Verhalten des Systems spezifiziert sind Bei den Abnahmetests führen wir also Alpha-Tests und Betatests Wir führen Benutzerakzeptanztests, betriebliche Abnahmetests durch und vertragliche behördliche Abnahmetests durchgeführt. Alpha-Tests werden in der Kontrollumgebung durchgeführt. In der Regel führt das Qualitätssicherungsteam, das interne Team Alpha-Tests durch Regel führt das Qualitätssicherungsteam, das interne Team Alpha-Tests und Betatests werden von unseren Endbenutzern durchgeführt. Spezifische Ansätze und Verantwortlichkeiten. Für Abnahmetests sind häufig der Kunde, der Geschäftsanwender, die Produktinhaber oder die Betreiber des Systems verantwortlich , oder es können auch andere Beteiligte beteiligt sein Abnahmetests durchgeführt Bei der Installation oder Integration von Cord-Softwareprodukten können Daher kann es sein, dass vor dem Systemtest ein Abnahmetest für eine neue Funktionserweiterung durchgeführt wird. Testgrundlagen für Abnahmetests gehören Geschäftsprozesse, Benutzeranforderungen, Vorschriften und Verträge sowie Standardanwendungsfälle. Es kann Anwendungsfälle, Dokumente, Dokumente Systemanforderungen , System - Benutzerdokumentation und Installationsverfahren geben. Also haben wir das Installationsverfahren definiert, wir können installieren, wie wir die Software installieren können. Der Risikoanalysebericht kann also da sein. Testobjekten für Abnahmetests gehören das zu testende System, Daten zur Überprüfung der Systemkonfiguration, Geschäftsprozesse für ein vollständig integriertes System, Wiederherstellungssystem und die Host-Seite Aus Gründen der Geschäftskontinuität und der Notfallwiederherstellung ist es daher sehr wichtig, die Wiederherstellung zu planen, damit wir Failover-Systeme, Betriebs- und Wartungsprozesse für Berichte, vorhandene und konvertierte Produktionsdaten usw. Es ging also um die Teststufen, die sehr wichtig sind Zumindest solltest du über ihre Stufen Bescheid wissen. Wie wir in dieser Sitzung besprochen haben, haben wir im unteren Teil Tests auf Unit-Ebene, die vom Entwickler durchgeführt werden, dann haben wir Integrationstests, Akzeptanztests und so weiter. In diesen Labels gab es also vier Komponententests, Integrationssysteme und Abnahmetests. Also das ist es. Ich danke dir vielmals. Tschüss. 17. Konfigurationsmanagement: Verwaltung der Konfiguration. Lassen Sie uns über das Konfigurationsmanagement sprechen. Der Zweck des Konfigurationsmanagements besteht darin, die Integrität einer Komponente oder eines Systems herzustellen und aufrechtzuerhalten . Während der Testplanung definieren wir daher die Infrastruktur für das Konfigurationsmanagementverfahren . Wir schreiben die Tools, welche Tools für das Konfigurationsmanagement verwendet werden. Zum Beispiel können wir Tools verwenden, wir haben verschiedene Tools für das Konfigurationsmanagement. Wir identifizieren es im Testplan. Das Konfigurationsmanagement kann also beinhalten, Folgendes sicherzustellen. Alle Testobjekte sind eindeutig von Virgin Control gekennzeichnet. Der Zweck besteht also darin, dass alle Artikel eindeutig identifiziert werden sollten. Es sollte keine Doppelarbeit geben, damit wir die Änderungen verfolgen und sie miteinander in Beziehung setzen können und sie miteinander in Beziehung setzen Auf alle identifizierten Dokumente von Softwareprodukten in der Dokumentation eindeutig Bezug In Version 5.5 gibt es also Risiken beim Testen birgt also einige Risiken, also müssen wir risikobasierte Analysen und risikobasierte Tests durchführen, damit wir diese Risiken minimieren können Risiko beinhaltete also die Möglichkeit zukünftiger Ereignisse, die negative Folgen haben Die Höhe des Risikos wird durch die Wahrscheinlichkeit eines Ereignisses und die Auswirkungen dieses Ereignisses bestimmt . Wenn die Auswirkungen also groß sind, müssen wir uns auf jeden Fall dieses Produkt ansehen. Hier sind einige Produkte, bei denen das Projektrisiko besteht. Das Risiko, das sich auf unser Produkt auswirkt, ist also das Produktrisiko und die Risiken, die sich auf unser Projektrisiko auswirken. Produktrisiko beinhaltete also die Möglichkeit, dass unser Arbeitsprodukt, beispielsweise Spezifikationskomponente oder ein Code nicht erfüllt die legitimen Bedürfnisse seiner Nutzer und Interessengruppen Projekte beinhalten also Situationen, die eintreten sollten und sich negativ auf die Verfügbarkeit des Projekts auswirken Zum Beispiel haben wir eine falsche Projektplanung, wir haben einen Mangel an Ressourcen. Es gibt Konflikte, Nichtverfügbarkeit und so weiter. Dies sind projektbezogene Risiken. Mm. Relatives Produktrisiko, unser Produkt funktioniert nicht richtig. Software erfüllt also möglicherweise nicht ihre beabsichtigte Funktion gemäß der Spezifikation, Software erfüllt ihre beabsichtigte Funktion möglicherweise nicht gemäß den Bedürfnissen von Benutzern und Interessengruppen. Diese beziehen sich also auf Produkte. Sie wissen also vor allem, dass bei Produkten unser Code ausgeführt wird. Vielleicht ist dies ein Code, der in unserer Produktionsumgebung oder in einer lokalen Umgebung ausgeführt unserer Produktionsumgebung oder in einer lokalen Umgebung Eine Systemarchitektur unterstützt möglicherweise einige nicht funktionale Anforderungen nicht ausreichend. So ist unser Produkt beispielsweise nicht zuverlässig, nicht benutzerfreundlich und erfüllt nicht die Sicherheits- und behördlichen Anforderungen. Das sind produktbezogene Risiken. Bestimmte Berechnungen können unter bestimmten Umständen falsch durchgeführt werden Umständen falsch durchgeführt Wenn das Ergebnis falsch ist, Berechnung falsch, das ist ein Produktivitätsrisiko Struktur der Schleifensteuerung, zum Beispiel das Problem beim Loop-Looping Der Code ist also falsch, der Code gibt ein falsches Ergebnis. Reaktionszeit auf Produktrisiken und diese nicht funktionalen Anforderungen sind also möglicherweise unzureichend für leistungsstarkes Transaktionsverarbeitungssystem. Das Feedback zur Benutzererfahrung entsprach nicht den Produkterwartungen. Es gibt also ein gewisses Projektrisiko, sodass wir beispielsweise die Projekte verzögern. Die beteiligten Personen sind also nicht qualifiziert, nicht geschult, es gibt also Konflikte zwischen den Menschen, und späte Änderungen können zu Problemen führen. Wenn also keine angemessene Kommunikation zwischen dem Entwicklungsteam und dem QA-Team stattfindet und der Q-Manager die Beteiligten nicht informiert, handelt es sich um Projektrisiken In den Projekten gibt es also vielleicht einige der möglicherweise falschen Einstellungen gegenüber den Erwartungen an die Tests Zum Beispiel, wenn man nicht einschätzt wichtig es ist, Fehler beim Testen zu finden Wertschätzung ist also sehr wichtig, wenn Tester Tests durchführen Deshalb sollten sie für ihre Ergebnisse gewürdigt werden Das ist also sehr wichtig. Und die Anforderungen an das Projektrisiko sind möglicherweise nicht gut genug definiert. Die Anforderung ist möglicherweise nicht erfüllt. Die Testumgebung ist möglicherweise nicht rechtzeitig bereit. Datenkonvertierung, Migrationsplanung und andere Tools können zu spät kommen. Schwächen im Entwicklungsprozess können sich daher auf die Konsistenz oder Qualität der Projektarbeit auswirken . schlechtes Fehlermanagement ist ein weiteres risikoorientiertes Testen und Produktivitätsmanagement im Rahmen eines Projekts. Deshalb sollten wir risikobasierte Tests durchführen. risikobasierter Testansatz bietet produktive Möglichkeiten zur Reduzierung des Produktrisikos. Risikobasierte Tests stützen sich daher auf das kollektive Wissen und Erkenntnisse der Projektbeteiligten und führen Produktrisikoanalysen durch. Um sicherzustellen, dass die Wahrscheinlichkeit eines Produktausfalls minimiert wird, bieten Risikomanagementaktivitäten einen disziplinären Ansatz Um regelmäßig zu analysieren und neu zu bewerten, was schiefgehen kann Stellen Sie also fest, mit welchen Risiken es wichtig ist, umzugehen. Wenn wir also das Risiko früher kennen , können wir es auf jeden Fall minimieren, Maßnahmen zur Minderung dieser Risiken ergreifen und Notfallpläne erstellen, um mit dem Risiko umzugehen, falls es entstehen sollte bevor es zum tatsächlichen Risiko wird Beim Mängelmanagement besteht unser Zweck der Tests also darin, die Mängel zu finden Daher ist das Mängelmanagement sehr wichtig. Um alle Fehler bis zur Behebung zu bewältigen, sollte die Organisation einen Fehlermanagementprozess einrichten. Daher sollte die Organisation das Fehlermanagement einrichten. Zum Beispiel sollte Jira da sein, um die Fehler melden zu können. Im Fehlermanagement kann also ein Fehler während der Codierung, der statischen Analyse und der Überprüfung gemeldet werden Codierung, der statischen Analyse und der Überprüfung All dies während dynamischer Tests, wir melden den Fehler nicht nur bei dynamischen Tests, sondern auch bei Überprüfungen bei statischen LCs und Dokumenten Um einen effektiven Test und einen effizienten Defektmanagementprozess zu gewährleisten, kann die Organisation eines effizienten Fehlermanagementprozesses einen Standard für die Attribute definieren Deshalb sollten wir auch ein Meldeverfahren haben, wie Fehler gemeldet werden, wie sie kommuniziert werden und so weiter Das Mängelmanagement verfolgt also in der Regel die folgenden Ziele mit Mängelmeldungen. Im Fehlerbericht, der in der Regel von einem QA-Mitarbeiter erstellt wird, werden also der Regel von einem QA-Mitarbeiter erstellt wird, andere Parteien über alle eingetretenen Nebenwirkungen informiert . Es bietet Testmanagern also die Möglichkeit die Qualität der Arbeitsergebnisse und die Auswirkungen auf die Tests zu verfolgen . Es bietet also Ideen für die Entwicklung und Verbesserung der Testprozesse. Damit kommen wir zu dieser Sitzung , in der es um Testorganisation ging. In der Testorganisation ist es also sehr wichtig, unsere Testaktivitäten zu organisieren, damit wir davon profitieren können. Okay, damit vielen Dank. Tschüss. 18. Testtypen: Hallo und willkommen zu einer weiteren Sitzung. In dieser Sitzung werden wir also über Testtypen sprechen. Zuvor haben wir über Teststufen gesprochen. Es gab also vier Teststufen: Komponentenintegration, System und Akzeptanz. Also die Testtypen, wir haben manuelles Testen, Automatisierungstests. Bei den manuellen Tests haben wir White Box, Black Box und Grey Bass. Gray Ba liegt also zwischen White Bass und Black Box. In der weißen Box haben wir Zugriff auf den Code. Wir tauchen tief in den Code ein und finden die Fehler dort heraus. Bei den Blackbox-Tests haben wir keinen Zugriff auf den Code. Wir betrachten das System als Blackbox. Also führen wir funktionale und nicht funktionale Tests daran durch. Bei den Funktionstests überprüfen wir den funktionalen Aspekt der Software, ob sie ordnungsgemäß funktioniert oder nicht. Und diese Funktionalität kann das Einloggen in Ihre Station, Hinzufügen eines Benutzers, das direkte Hinzufügen zur Position usw. sein. Deshalb stellen wir sicher, dass all diese Funktionen problemlos funktionieren. Wenn es ein Problem gibt, melden wir diesen Fehler. Im nicht funktionierenden Bereich führen wir Leistungstests und Sicherheitstests durch. Bei den Leistungstests führen wir Auslastungstests, Testtests und Benutzerfreundlichkeit durch. Deshalb führen wir auch Usability-Tests durch, um sicherzustellen , dass die Funktionen unserer Software für unsere Kunden nutzbar sind. Während des Testens melden wir den Fehler. erneutes Testen bedeutet also, dass wir die Box gemeldet haben und das Problem behoben ist Jetzt testen wir, ob wir sicherstellen, dass das Problem behoben ist. Dann schließen wir es. Bei Regressionstests ist es also möglich, dass die Reparatur der Box zu anderen Problemen geführt hat Wenn wir also die Box in einem Modul repariert haben, kann dies möglicherweise zu einer anderen Regressionsbox Bei Regressionstests stellen wir also sicher, dass alle zugehörigen Module funktionieren und dass es aufgrund dieser Änderungen keine Probleme gibt Wenn wir also über Tests im Zusammenhang mit Änderungen sprechen , heißt das, dass wir die Software testen müssen, wenn es Änderungen gibt wir die Software testen müssen Wir müssen sicherstellen, dass sich die Änderung nicht negativ auf unsere Software ausgewirkt hat. Es liegt in unserer Verantwortung, unseren Kunden das qualitativ hochwertige Produkt zu liefern. Sie also an einen Punkt, denken Sie daran , dass es für die Durchführung möglich ist, jeden der oben genannten Testtypen auf jeder Testebene durchzuführen. Alle Testtypen, die ich erwähnt habe, Black Box, White Box, Gray Box, sollten also Black Box, White Box, Gray Box, auf Testebene durchgeführt werden. Wenn wir beispielsweise Komponententests durchführen, bei den Komponententests sicher, wir bei den Komponententests sicher, dass die Komponente keinen Funktionsfehler oder kein leistungsbezogenes Problem aufweist . Darin gibt es keine Endlosschleife. Wenn wir uns also auf der Integrationsebene befinden, stellen wir sicher, dass es korrekt funktioniert unabhängig davon, ob es sich um funktionale und nicht funktionale Aspekte handelt. Das Gleiche gilt für Systemtests und Abnahmetests. Das ist es. Danke. Tschüss. 19. Testmanagement123: Hallo und willkommen zur Wettersitzung. In dieser Sitzung werden wir also über Testmanagement sprechen. In Kapitel fünf geht es also um Testmanagement. Wenn wir also über das Testmanagement sprechen, bezieht sich Testmanagement auf den Prozess der Organisation und Steuerung der Testaktivitäten. Wir haben also Testaktivitäten. In diesem Prozess organisieren wir also alle Aktivitäten, wir kontrollieren sie. Es beinhaltet also Planung, Ausführung, Überwachung und Berichterstattung, um sicherzustellen, dass das Softwareprodukt der gewünschten Qualität und dem gewünschten Standard entspricht . Ein effektives Testmanagement stellt sicher, dass unsere Testaktivitäten optimiert, dokumentiert und kontrolliert werden , um Risiken und Fehler zu minimieren Daher ist es sehr wichtig, einen ordnungsgemäßen Testmanagementprozess zu einen ordnungsgemäßen Testmanagementprozess implementieren, denn in der größeren Organisation , in der wir über ausgereifte Prozesse verfügen, haben wir auch die richtigen Testmanagement-Richtlinien implementiert Im Testmanagement haben wir also Testpläne. Wir haben richtige Organisationen mit testunabhängiger Ebene. In der Testorganisation haben wir also Unabhängigkeit und weniger Unabhängigkeit , unabhängige Tester einzustellen Bei Unabhängigkeitstests haben wir also den Entwickler, der sein eigenes Produkt testet Also, es ist kein Tester involviert. Der Entwickler testet also oder der Autor testet seinen eigenen Quellcode. Eine weitere Stufe, die unabhängig vom Testen ist, besteht also der Tester aus dass der Tester aus einer anderen Abteilung diese Software testet. Das können Buddy-Tests sein und so weiter. dritte Ebene kann also ein unabhängiges Tester-Team sein , das die Software mit Organisation testet. Sie berichten also ihrem QM-Hauptfach und so weiter. Sie wissen also, wenn wir darüber sprechen Entwickler ihre eigenen Schutzmaßnahmen testen, verstehen sie das System, testen aber vorsichtig. Dies hängt von der Bereitstellung ab, wohingegen unabhängige Tester etwas über das System lernen müssen, damit sie versuchen, es zu knacken, und es ist daher von der Qualität abhängig. Auf einer anderen Ebene könnten also unabhängige Tester aus anderen Abteilungen sein. Sie können Benutzerexperten auf diesem Gebiet sein, zum Beispiel Leistungstester, Usability-Tester , Compliance-Mitarbeiter usw. So und auf einer anderen Ebene könnten unabhängige Tester von Drittanbietern oder anderen Organisationen sein, die ihr Produkt testen. Wir haben einen Vertrag abgeschlossen. Sie haben einen Vertrag mit uns, also testen sie ihr Protokoll Es können interne Offshore-Teams sein. Das bringt also einige potenzielle Vorteile der Unabhängigkeit mit sich. Unabhängige Tester finden mit größerer Wahrscheinlichkeit Fehler, die Entwickler aus geschäftlichen Gründen nicht finden können So können unabhängige Tester die Annahmen der Beteiligten bei der Spezifikation verifizieren, infrage stellen und widerlegen Beteiligten bei Unabhängige Tests können also fachspezifisch sein, sodass sie die von unseren Stakeholdern getroffenen Annahmen infrage stellen können und so weiter Das ist also der Vorteil unabhängiger Tests, aber es gibt auch einige Nachteile möglichen Nachteilen unabhängiger Tests gehört, dass es sich um ein unabhängiges Team handelt, sodass der Entwickler möglicherweise das Qualitätsgefühl verliert Daher könnte Delper denken, dass die Verantwortung für die Qualität beim Testteam liegt Ein weiterer Grund könnte sein, dass sie keinen regelmäßigen Kontakt zum Entwicklungsteam haben, sodass es zu Kommunikationslücken kommen kann und es zu Schuldzuweisungen zwischen dem Entwickler und dem unabhängigen Testteam kommen kann Schuldzuweisungen zwischen dem Entwickler und dem unabhängigen Testteam Also unabhängiger Tester. Ein weiterer Punkt ist, dass unabhängigen Testern möglicherweise einige wichtige Informationen über das Produkt fehlen. Als unabhängiger Tester, weit entfernt vom Entwicklungsteam, kann es also zu Missverständnissen kommen, obwohl sie möglicherweise falsch kommunizieren obwohl sie möglicherweise falsch Und das gilt auch, wenn Sie über die Aufgaben von Testmanagern und Testern sprechen über die Aufgaben von Testmanagern und Testern An diesen Arbeiten sind also zwei Personen beteiligt Testmanager und Tester. Bei Quatem haben wir also auch andere Rollen als Automatisierungsingenieur, Nachwuchskräfte Aber im Labor haben wir zwei Testrollen: Testmanager und Aktivitäten und Aufgaben, die von diesen Rollen ausgeführt werden, hängen also vom Projekt- und Produktkontext Es hängt also davon ab, um welche Art von Projekt es sich handelt und welche Art von Produkt sie testen. Es kann also E-Commerce-Anwendungen geben, es wird sicherheitskritische Anwendungen die von den Fähigkeiten der Personen in ihrer Rolle in der Organisation abhängen . Lassen Sie uns also über einen Testmanager sprechen. Testmanager verwaltet die Testaktivitäten, verwaltet das Team. Als Manager ist er oder sie also verantwortlich für die Planung der Testaktivitäten, Vorbereitung der Testpläne, betreut, leitet die Teams, Entwickler, die die Testautomatisierungsstrategie entwickeln, manuelle Automatisierungsstrategien, manuelle Automatisierungsstrategien, schreibt Anleitungen für das Team, wie man Tests schreibt, ich sehe, wie man Fehler meldet und die Testumgebungen vorbereitet , Testautomatisierungsumgebung Also vielleicht plant er, zum Beispiel einen Manager zu geben, falls es dort kein Tool zur Fehlerberichterstattung gibt Er oder sie wird also für die Budgetierung und die Zuweisung der Ressourcen verantwortlich sein für die Budgetierung und die Zuweisung der Ressourcen verantwortlich Das sind also alles Aktivitäten, Manager ist daran beteiligt Ein Testmanager initiiert also auch das NLC-Design, die Implementierung und die Ausführung von Testmonitoren und Testfortschrittsberichten Testmanager erstellt also die Testfortschrittsberichte, teilt die Ergebnisse mit den Beteiligten, überprüft den Status und definiert die Ausgangskriterien auf Erledigt Der Testmanager bereitet also auch Testfortschrittsberichte vor und liefert sie, Sie wissen schon, jeden Tag, vielleicht wöchentlich. Daher wird auch eine Planung auf der Grundlage der Testergebnisse und des Fortschritts übernommen Planung auf der Grundlage der Testergebnisse und des Fortschritts Also auch Sportdefektmanagementsystem, Konfigurationsmanagementsystem und so weiter Die Aufgaben eines Testmanagers sind also, dass er viele Aufgaben hat. Als Manager fördert er oder sie die Interessenvertretung der Tester Also Testteam und andere Berufe innerhalb. Testmanager befürwortet also das Testteam, die Verteidigung, das Testteam leitet die Mentoren an, entwickelt die Fähigkeiten, die entwickelt die Fähigkeiten, die für ihre Karriere entscheidend sind, und so weiter Wenn wir also über die Tester sprechen, ist der Tester die Person, die in die Fußstapfen des Managers tritt Also prüft und trägt dazu bei, den Testplan zu analysieren und zu überprüfen, welche Anforderungen die User Stories haben, was auch immer in der User Story steht, überprüft und untersucht, was der Akzeptanzbereich ist, was die Ausgangskriterien sind und bereitet den Testplan Identifiziert und dokumentiert somit die Testbedingung. Ebenso untersucht und rückverfolgbar, also die Rückverfolgbarkeit zwischen Testfällen, Testräumen usw. Tester verwenden also auch die Tests, die von einer anderen Person, einer anderen Q-Person oder einer jüngeren Person geschrieben wurden , und entwerfen und implementieren die Weißt du, vielleicht automatisiert. Wenn es keinen spezialisierten Automatisierungstester gibt, bereiten sie auch die Testfälle vor, automatisierte Testfälle. Tester führt also aus, bewertet die Ergebnisse und dokumentiert Abweichungen von den erwarteten Daher verwendet es auch ein geeignetes Tool, um den Testprozess zu vereinfachen und Tests nach Bedarf zu automatisieren Wann immer eine Automatisierung erforderlich ist, automatisieren sie diese. Tester testen auch die nicht funktionalen Anforderungen Benutzerfreundlichkeit, Sicherheit, Kompatibilität und Portabilität usw. Überprüft also Tests, die von einer anderen Person entwickelt wurden. Dies liegt in der Verantwortung des Testers. Lassen Sie uns nun über den Testplan sprechen. Der Testplan enthält also ein Dokument , in dem der Umfang, das Ziel und das Testrisiko angegeben sind. Im Testplan haben wir im Testplan alle Dinge aufgelistet. Zum Beispiel gibt es einen Testplan für die Automatisierung Wir haben aufgelistet, welches Tool wir verwenden werden. W-Ressourcen bedeuten alt, wenn wir anfangen? Welche Einstiegskriterien werden die Austrittskriterien sein? Im Testplan definieren wir also den Gesamtansatz für das Testen, Integration und die Koordination der Aktivitäten in der gesamten Software Wir definieren auch, welche Software oder welcher Lebenszyklus eingehalten wird und wie wir den Testplan entsprechend planen Im Testplan übernehmen wir also auch die Planung und Planung der Testanalyse-, Design-, Implementierungs -, Ausführungs- und Bewertungsaktivitäten. Diese sind also erledigt. Wir wählen auch Medikamente für die Überwachung und Kontrolle aus. Also die Budgetierung der Testaktivitäten und die Festlegung des Detaillierungsgrades und der Struktur der Testdokumentation Es ging also ein bisschen um das Testflugzeug. Lassen Sie uns also über die Teststrategie sprechen. Also wurde der Test auf hohem Niveau studiert. Die Teststrategie bietet also eine allgemeine Beschreibung unserer Testbemühungen Es kann also analytisch, modellbasiert, methodisch und prozessorientiert sein modellbasiert, methodisch und prozessorientiert Gezielt kann gerichtet, Regression, umgekehrte und reaktive Regression sein. Also und hängt vom Projekt und den Produkt - und Projekteigenschaften Wenn wir also über Einstiegskriterien sprechen, wissen wir, dass sie in der User Story stehen. In der User Story haben wir also die Versuchs- und Austrittskriterien geschrieben. typischen Einstiegskriterien gehört also die Verfügbarkeit testbarer Anforderungen, zum Beispiel eine User Story Unsere Modelle, wenn wir einer modellbasierten Teststudie folgen, also Verfügbarkeit von Testobjekten, die die Ausgangskriterien für alle vorherigen Teststufen erfüllt haben die Ausgangskriterien für alle vorherigen Teststufen erfüllt Also Verfügbarkeit der Testumgebung. Wenn die Testumgebung verfügbar ist, können wir sagen, dass unsere Einstiegskriterien Verfügbarkeit der erforderlichen Testtools, Verfügbarkeit von Testdaten und anderen erforderlichen Ressourcen sind. Lassen Sie uns also einfach über die Austrittskriterien sprechen, wenn wir das System verlassen. Also planen, Testfälle werden ausgeführt. Wie Sie wissen, können wir nicht alles testen. Also, wenn wir das gewünschte Qualitätsniveau erreichen. Wenn also meistens Bugs mit hohem Proty-Status behoben sind, können wir sagen, dass wir die Exit-Kriterien erfüllt haben Der Ausgangsbereich ist also auch im Testplan definiert. Behalten Sie auch die User-Stories bei. Also bei den Ausstiegskriterien auch die Anzahl der ist auch die Anzahl der geschätzten verbleibenden Mängel ausreichend gering. Unser objektiver Test besteht also darin, die Mängel und Probleme im Produkt zu identifizieren. Wenn diese Werte also ausreichend niedrig sind, können wir sagen, dass wir die Austrittskriterien erfüllt haben. Das bewertete Niveau an Zuverlässigkeit, Leistung, Effizienz, Benutzerfreundlichkeit, Sicherheit und anderen relevanten Qualitätsmerkmalen ausreichend. Im Testausführungsplan können die Testsuiten also in einem Testausführungsplan angeordnet werden einem Testausführungsplan , der die Reihenfolge definiert , in der sie ausgeführt werden können. Zeitplan für die Testausführung sollte daher Faktoren wie Priorisierung, Abhängigkeiten, Bestätigung und Test berücksichtigen Faktoren wie Priorisierung, Abhängigkeiten, Bestätigung und Test Also Regressionstests und die effizientesten Sequenzen für die Testausführung Also im Zeitplan, wissen Sie, haben wir einen Zeitplan, die Testfälle, dass es einige Faktoren gibt , die den Testaufwand beeinflussen Faktoren, die die Testbemühungen beeinflussen, können Produkteigenschaften gehören. Unser Produkt, das wir entwickeln werden, ist also unser Entwicklungsprozess. Was ist also mit dem Entwicklungsprozess? Wir sind Waterfall Gil Scrum und so weiter gefolgt. Eigenschaften Menschen und die Testergebnisse. Also Produkteigenschaften. Sie wissen also, wir haben Produkteigenschaften und Projektakzismus. Produkt ist eigentlich das Produkt , das wir für unseren Kunden bauen In Projekt sechs gibt es also die Größe des Projekts. Es kann klein oder groß genug sein. Also das mit dem Produkt verbundene Risiko, die Qualität der Testbasis und die Komplexität der Produktbereiche, die Anforderung an Qualitätsmerkmale wie Sicherheit, Zuverlässigkeit usw. Detailliertheit der Anforderungen an die Testdokumentation, Anforderung zur Einhaltung gesetzlicher und behördlicher Vorschriften. Sind einige der Produkteigenschaften. Wenn wir also über die Merkmale des Entwicklungsprozesses sprechen , ist dies Stabilität und Reife der Organisation. Wenn die Organisation also ausgereift ist, wird sie definitiv über einen ordnungsgemäß dokumentierten, gut etablierten Prozess verfügen . Und dem sie in ihrem Entwicklungsprozess folgen. Der Testansatz, der Einsatz der Tools, unabhängig davon, welche Tools Sie verwenden der Testprozess und der Zeitdruck. Wenn wir also von Eigenschaften von Menschen sprechen, meinen wir mit Personenmerkmalen Personen, die über Fachwissen, Fähigkeiten und Erfahrungen der beteiligten Personen verfügen, vor allem, wenn sie Erfahrung mit ähnlichen Produkten oder Dienstleistungen haben . Zusammenhalt und Führung im Team. Dies sind einige Merkmale anderer Personen, und die Testergebnisse können die Anzahl und Schwere der festgestellten Mängel den Umfang der erforderlichen Nacharbeit Wenn es also um Testschätzungstechniken geht, gibt es eine Reihe von Schätzmethoden, mit denen der Aufwand für DUC-Tests bestimmt werden bestimmt Eine davon ist das Testen auf Metriken. Bei den metrikbasierten Tests schätzen wir den Testaufwand also auf der Grundlage von Kennzahlen von Landwirten, ähnliche Projekte basieren auf typischen Werten Bei den auf Experten basierenden Techniken schätzen wir den Testaufwand also auf der Grundlage der Erfahrung des Eigentümers von einer Testaufgabe nach der anderen Also Testüberwachung und -kontrolle, was in Abschnitt 5.3 beschrieben ist Der Zweck der Testüberwachung besteht also darin, Informationen zu sammeln und Feedback und Transparenz über die Testaktivitäten zu geben. zu überwachenden Informationen können also manuell über Atom und durch automatisierte Automatisierungssoftware gesammelt werden manuell über Atom und . Testkontrolle beschreibt also jede Leit- oder Korrekturentscheidung aufgrund der gemeldeten Möglichkeit zur Erfassung von Informationen und Medikamenten getroffen Möglichkeit zur Erfassung von Informationen und Medikamenten Bei der Testüberwachung und -kontrolle , einem Beispiel für Testkontrolle, gehört zu den Maßnahmen die Neupriorisierung von Tests, wenn identifizierte Zum Beispiel besteht ein gewisses Risiko, dass wir zu spät liefern werden Wir priorisieren die Tests, unseren Testaufwand. ändern also den Testplan aufgrund der Verfügbarkeit oder Nichtverfügbarkeit der Testumgebung oder der Ressourcen, wenn die Umgebung nicht verfügbar ist, also müssen wir den Zeitplan ändern, den Zeitplan aktualisieren, also neu bewerten, ob es sich bei dem Testobjekt um eine interne Führungskraft handelt, weil es sich bei der Überarbeitung um eine interne Führungskraft handelt Wir müssen also eine Neubewertung vornehmen. Dies ist eine fortlaufende Aktivität, daher ist die Überwachung und Kontrolle von Tests eine fortlaufende Aktivität. MTC testet gerade, wir wissen, wie Sie testen. Es gibt also einige Spiele, die wir verwenden. Mets können während und am Ende der Testaktivitäten gesammelt werden während und am Ende der Testaktivitäten Während des Projekts werden also Mediziner gesammelt. Fortschritte im Einklang mit dem Plan, Zeitplan und Budget, aktuelle Qualität der Testperson, Angemessenheit des Testansatzes, Effektivität der Testaktivitäten Hinblick auf Es gibt also einige häufig vorkommende Testdurcheinander : prozentualer Anteil des Flugzeugs, geleistete Arbeit bei der Vorbereitung der Testfälle, prozentualer Anteil der Flugzeuge und Arbeit bei der Vorbereitung der Testumgebung Ein weiterer Aspekt ist die Ausführung von Testfällen, z. B. die Anzahl der durchgeführten Testfälle, fehlgeschlagenen Tests usw. Übliche Tests beinhalten also Fehlerinformationen und Fehlerdichte. Das ist die Testabdeckung der Anforderung, zum Beispiel kann User Story Acceptance City Rs programmieren. Also Aufgabenerledigung, Ressourcenzuweisung, Nutzung und Aufwand. Testkosten gehören die Kosten im Vergleich zum Nutzen der Suche nach dem nächsten Fehler oder die Kosten im Vergleich zum Nutzen der Ausführung des NAS-Textes. Einige Zwecke, Inhalte und Zielgruppen für Testberichte. Die Hauptzielgruppe für Testberichte sind also Stakeholder. Der Zweck der Testberichterstattung besteht zu den Testaktivitäten zusammenzufassen und Informationen zu den Testaktivitäten zusammenzufassen und an die Beteiligten weiterzugeben, damit sie sich ein Bild dann eine fundierte Entscheidung treffen können Während der Testüberwachung und -kontrolle erstellt der Testmanager daher regelmäßig Berichte über den Testfortschritt für die Beteiligten diese Weise können sie über die Qualität des Produkts auf dem Laufenden gehalten werden. Sie können zur richtigen Zeit die richtige Entscheidung treffen. In der Regel können Testfortschrittsberichte und Testzusammenfassungsberichte eine Zusammenfassung der durchgeführten Tests , Informationen darüber, was während des Testzeitraums passiert ist, Abweichungen vom Plan, einschließlich Abweichungen vom Zeitplan während der Testaktivitäten, den Status der Tests und die Produktqualität in Bezug auf den Austritt enthalten , Informationen darüber, was während des Testzeitraums passiert ist , Abweichungen vom Plan, einschließlich Abweichungen vom Zeitplan während der Testaktivitäten, den Status der Tests und die Produktqualität in während der Testaktivitäten, den Status der Tests und , die Definition von erledigt, wenn wir über den Testfortschritt sprechen Berichte und Testzusammenfassungen können Faktoren enthalten , die den Fortschritt blockiert haben oder weiterhin blockieren Es werden also Medikamente gegen Mängel, Testfälle, Umfang der Tests, Fortschritt der Aktivitäten, Ressourcenverbrauch, Risiken in Wohngebieten, wiederverwendbare Testprodukte hergestellt. Konfigurationsmanagement. Lassen Sie uns über das Konfigurationsmanagement sprechen. Der Zweck des Konfigurationsmanagements besteht darin, die Integrität einer Komponente oder eines Systems herzustellen und aufrechtzuerhalten . Während der Testplanung definieren wir daher die Infrastruktur für die Konfigurationsmanagementverfahren . Wir schreiben die Tools, welche Tools für das Konfigurationsmanagement verwendet werden. Zum Beispiel können wir Tools verwenden, wir haben verschiedene Tools für das Konfigurationsmanagement. Wir identifizieren es im Testplan. Das Konfigurationsmanagement kann also beinhalten, Folgendes sicherzustellen. Alle Testobjekte sind eindeutig von Virgin Control gekennzeichnet. Der Zweck besteht also darin, dass alle Artikel eindeutig identifiziert werden sollten. Es sollte keine Überschneidungen geben, damit wir die Änderungen verfolgen und miteinander in Beziehung setzen Auf alle identifizierten Dokumente von Softwareprodukten in der Dokumentation eindeutig verwiesen In Version 5.5 gibt es also Risiken beim Testen birgt also einige Risiken, also müssen wir risikobasierte Analysen durchführen, risikobasiert, damit wir diese Risiken mindern können Risiken beinhalten also die Möglichkeit zukünftiger Ereignisse, die negative Folgen haben Die Höhe des Risikos wird durch die Wahrscheinlichkeit eines Ereignisses und die Auswirkungen dieses Ereignisses bestimmt . Wenn die Auswirkungen also groß sind, müssen wir uns auf jeden Fall das Produkt ansehen, müssen wir uns auf jeden Fall das Produkt ansehen, also die Summe des Produkts im Projektrisiko. Das Risiko, dass unser Produkt beeinträchtigt wird, ist das Produktrisiko und das Risiko, das sich auf unser Projektrisiko auswirkt. Produktrisiko beinhaltete also die Möglichkeit, dass unser Arbeitsprodukt, beispielsweise Spezifikationskomponente oder ein Code die legitimen Bedürfnisse von Benutzern und Interessengruppen nicht erfüllt . Projekte beinhalten Situationen , die eintreten sollten und sich negativ auf die Verfügbarkeit des Projekts auswirken können. Zum Beispiel haben wir eine falsche Projektplanung, wir haben einen Mangel an Ressourcen. Es gibt Konflikte, Nichtverfügbarkeit und so weiter. Dies sind projektbezogene Risiken. Relatives Produktrisiko, unser Produkt funktioniert nicht richtig. Software erfüllt also möglicherweise nicht ihre beabsichtigte Funktion gemäß der Spezifikation, Software erfüllt ihre beabsichtigte Funktion möglicherweise nicht gemäß den Bedürfnissen von Benutzern und Interessengruppen. Diese beziehen sich also auf Produkte. Diese Produkte, die Sie besonders kennen, sind also unser Code, der ausgeführt wird. Vielleicht ist dies ein Code, der in unserer Produktionsumgebung oder in einer lokalen Umgebung ausgeführt unserer Produktionsumgebung oder in einer lokalen Umgebung Eine Systemarchitektur unterstützt möglicherweise einige nicht funktionale Anforderungen nicht ausreichend. So ist unser Produkt beispielsweise nicht zuverlässig, nicht benutzerfreundlich und erfüllt nicht die Sicherheits- und behördlichen Anforderungen. Das sind produktbezogene Risiken. Eine bestimmte Berechnung kann unter bestimmten Umständen falsch durchgeführt werden Umständen falsch durchgeführt Wenn also das Ergebnis falsch ist, Berechnung falsch, das ist ein Produktivitätsrisiko. Struktur der Regelschleife, zum Beispiel das Problem beim Loop-Looping Der Code ist also falsch, der Code gibt ein falsches Ergebnis. Reaktionszeit auf Produktrisiken und diese nicht funktionalen Anforderungen sind also möglicherweise unzureichend für leistungsstarkes Transaktionsverarbeitungssystem. Das Feedback zur Benutzererfahrung entsprach möglicherweise nicht den Produkterwartungen. Es bestehen also einige Projektrisiken, z. B. Verzögerungen bei den Projekten. Also sind die beteiligten Personen nicht qualifiziert, nicht geschult, es gibt also Konflikte zwischen den Menschen, und späte Änderungen können zu Problemen führen. Wenn also keine angemessene Kommunikation zwischen dem Entwicklungsteam und dem QA-Team stattfindet und die QS-Manager die Stakeholder nicht informieren, handelt es sich um Projektrisiken In den Projekten, die wir haben, gibt es vielleicht einige von ihnen, vielleicht gibt es eine falsche Einstellung zu den Erwartungen, die an Tests gestellt werden Erwartungen, die an Tests gestellt Zum Beispiel, wenn wir nicht wissen, wie wichtig es ist, Fehler beim Testen zu finden Wertschätzung ist also sehr wichtig, wenn Tester Tests durchführen Deshalb sollten sie für ihre Ergebnisse gewürdigt werden Das ist also sehr wichtig. Und das Projektrisiko, das wir haben, ist möglicherweise nicht gut genug definiert. Die Anforderung ist möglicherweise nicht erfüllt. Die Testumgebung ist möglicherweise nicht rechtzeitig bereit. Datenkonvertierung, Migrationsplanung und andere Tools können zu spät kommen. Schwächen im Entwicklungsprozess können sich daher auf die Konsistenz oder Qualität der Projektarbeit auswirken . Das Management von Hafendefekten ist ein weiteres risikoorientiertes Testen und Produktivitätsmanagement im Rahmen eines Projekts. Deshalb sollten wir risikobasierte Tests durchführen. risikobasierter Testansatz bietet produktive Möglichkeiten zur Reduzierung des Produktrisikos. Risikobasierte Tests stützen sich daher auf das kollektive Wissen und Erkenntnisse der Projektbeteiligten und führen Produktrisikoanalysen durch. Um sicherzustellen, dass die Wahrscheinlichkeit eines Produktausfalls minimiert wird, bieten Risikomanagementaktivitäten einen disziplinären Ansatz Um regelmäßig zu analysieren und neu zu bewerten, was schiefgehen kann Stellen Sie also fest, mit welchen Risiken es wichtig ist, umzugehen. Wenn wir also das Risiko früher kennen , können wir es definitiv minimieren. Maßnahmen zur Minderung dieser Risiken und erstellen Sie Notfallpläne, um mit dem Risiko umzugehen, falls es entstehen sollte bevor es zum tatsächlichen Im Fehlermanagement besteht unser Zweck des Testens also darin, die Mängel zu finden Daher ist das Mängelmanagement sehr wichtig. Um unsere Fehler bis zur Behebung zu bewältigen, sollte die Organisation also sollte die Organisation einen Prozess für das Mängelmanagement einrichten. Deshalb sollte die Organisation das Mängelmanagement einrichten. Zum Beispiel sollte Jira da sein, damit wir die Fehler melden können. Im Fehlermanagement kann also ein Fehler während der Codierung, der statischen Analyse und der Überprüfung gemeldet werden Codierung, der statischen Analyse und der Überprüfung All dies während dynamischer Tests, wir melden den Fehler nicht nur bei dynamischen Tests, sondern auch bei Überprüfungen bei statischen LCs und Dokumenten. Um einen effektiven Test zu haben, kann eine effiziente Organisation des Fehlermanagementprozesses effiziente Organisation des Fehlermanagementprozesses einen Standard für die Attribute definieren Deshalb sollten wir auch ein Meldeverfahren haben, wie Fehler gemeldet werden, wie sie kommuniziert werden und so weiter Das Mängelmanagement, in der Regel Mängelmeldungen, verfolgt also die folgenden Ziele. Im Mängelbericht , der in der Regel von einem QA-Mitarbeiter erstellt wird, werden also , der in der Regel von einem QA-Mitarbeiter erstellt wird, andere Parteien über alle eingetretenen unerwünschten Ereignisse informiert . Es bietet Testmanagern also die Möglichkeit die Qualität der Arbeitsergebnisse und die Auswirkungen auf die Tests zu verfolgen . Es bietet also Ideen für die Entwicklung und Verbesserung der Testprozesse. Damit kommen wir zu dieser Sitzung, in der es um Testorganisation ging. In der Testorganisation ist es also sehr wichtig, unsere Testaktivitäten zu organisieren, damit wir davon profitieren können. Okay, damit vielen Dank. Tschüss.