Die Bedeutung von Softwaretests
Programmtests sind von entscheidender Bedeutung, da sie es Ihnen ermöglichen, etwaige Fehler in der Software frühzeitig zu erkennen und zu korrigieren, bevor Sie das Endprodukt ausliefern. Ein gut getestetes Softwareprodukt bietet Zuverlässigkeit, Sicherheit und hervorragende Leistung, das spart Zeit und Geld und verbessert die Kundenzufriedenheit.
Softwaretests sind aus den folgenden Gründen notwendig:
1. Sicherheit
Da ein bestimmtes Produkt getestet wird, können die Benutzer sicher sein, dass sie ein zuverlässiges Produkt erhalten werden. Auch die persönlichen Daten des Nutzers können sicher sein. Mithilfe von Softwaretests können die Nutzer Produkte erhalten, die frei von Schwachstellen sind.
2. Kostengünstig
Softwaretests haben viele Vorteile. Einer der wichtigsten Gründe, warum sich Unternehmen für Softwaretestdienste entscheiden, ist die Kosteneffizienz des Projekts.
Das Testen von Software besteht aus mehreren Initiativen. Wenn Sie einen Fehler in einem frühen Stadium des Entwicklungsprozesses entdecken, sind die Kosten für seine Behebung geringer. Daher müssen Sie die Prüfung so schnell wie möglich abschließen. Wenn Sie Qualitätsanalysten oder Tester für Projekte engagieren, die über viel Erfahrung verfügen und eine technische Ausbildung absolviert haben, investieren Sie und das Projekt wird davon profitieren.
3. Qualität des Produkts
Das Testen von Software ist eine Kunst, die dazu beiträgt, dass sich ein Unternehmen auf dem Markt einen Namen macht, indem es dem Kunden ein qualitativ hochwertiges Produkt gemäß den Anforderungspapieren liefert.
4. Zufriedenheit des Kunden
Alle das führt zu einem zufriedenen Kunden! Als Kunden erwarten wir alle Systemstabilität. Wenn Sie während des Lebenszyklus der Entwicklung testen, können Sie sehen, wie gut das Programm konzipiert wurde. Dies erhöht das Vertrauen der Kunden.
5. Verbesserungen des Entwicklungsprozesses
Mithilfe der Qualitätssicherung können Sie eine Reihe von Szenarien und Fehlern ausfindig machen. Sie können sie dazu verwenden, um das Problem zu reproduzieren.
Es ist ganz einfach und die Entwickler müssen das Problem so schnell wie möglich beheben. Darüber hinaus sollten Softwaretester mit dem Entwicklungsteam zusammenarbeiten, das trägt zur Beschleunigung des Entwicklungsprozesses bei.
6. Das Hinzufügen neuer Funktionen ist einfach
Änderungen sind umso schwieriger, je stärker integriert und je älter der Code ist. Tests helfen Entwicklern Verkalkungen zu vermeiden, indem sie ihnen die Möglichkeit geben, neue Funktionen einzubauen. Als neuer Entwickler kann es schwierig sein, ältere Abschnitte Ihrer Codebasis zu ändern, aber mit Hilfe von Tests können Sie feststellen, ob Sie etwas Wichtiges kaputt gemacht haben. So kann sich Ihr Programm auf dem Markt abheben.
Kategorien von Softwaretests
Es gibt eine Vielzahl von Softwaretests, jeder mit seinen eigenen Zielen und Strategien:
- Benutzerfreundlichkeitstests: Überprüfung der Fähigkeit eines Kunden, eine Aufgabe mit einem System oder einer Online-Anwendung auszuführen.
- Abnahmetests: Prüfung, ob das Softwaresystem die Anforderungen erfüllt.
- Integrationstests: In dieser Phase des Softwaretests werden einzelne Einheiten/Komponenten zusammengeführt und als Gruppe getestet.Ziel dieser Testebene ist es, Fehler in der Art und Weise zu finden, wie die integrierten Einheiten zusammenwirken. Bei Integrationstests werden Testtreiber und Teststümpfe eingesetzt.
- Funktionstests: Sie überprüfen, ob das Softwaresystem die funktionalen Anforderungen und Spezifikationen erfüllt. Sie können damit überprüfen, ob die Ausgabe eines Softwareprogramms die funktionalen Anforderungen erfüllt, indem Sie eine akzeptable Eingabe machen.
- Leistungstests: Leistungstests sind eine Art von nicht-funktionalen Softwaretests, bei denen die Stabilität, Geschwindigkeit, Skalierbarkeit und Reaktionsfähigkeit einer Anwendung unter verschiedenen Arbeitsbelastungen untersucht wird.
- Regressionstests: Bei dieser Art von Softwaretests wird sichergestellt, dass eine Anwendung nach Codeänderungen, Aktualisierungen oder Upgrades weiterhin wie implementiert funktioniert.
- Stresstest: Hierbei wird getestet, ob das System einer bestimmten Belastung standhalten kann, bevor es abstürzt. Diese Art von Test ist ein nicht-funktionaler Test.
- Unit-Test: Testen einzelner Module auf Fehler. Hier geht es um die Genauigkeit der Funktionalität der unabhängigen Module. Der Hauptzweck dieser Testphase besteht darin, jede Komponente des Systems zu isolieren, damit Fehler identifiziert, analysiert und korrigiert werden können.
- Nicht-funktionales Testen: Nicht-funktionales Testen ist eine Art des Testens von Software, die nicht-funktionale Aspekte der Software wie Zuverlässigkeit, Lasttests, Leistung und Verantwortlichkeit überprüft. Der Hauptzweck des nicht-funktionalen Testens besteht darin, die Leserate des Softwaresystems anhand von nicht-funktionalen Kriterien zu bestimmen.
In diesem Artikel konzentrieren wir uns mehr auf Unit-Tests konzentrieren.
Wir verwenden die folgenden Tools für den Unit-Test der Software:
Google Test (GTest)
- Es basiert auf der xUnit-Architektur.
- Es ist eine Sammlung von „Frameworks" für die Entwicklung und Automatisierung von Testfällen.
- Es ist eine Bibliothek zum Schreiben von C++-Tests.
Der Zweck der Verwendung eines Google Tests:
- Mit Google Test können wir bessere C++-Tests entwickeln.
- Es trennt die Tests, indem es jeden Test an einem bestimmten Element ausführt, wodurch sie unabhängig und wiederholbar werden.
- Google Test ist portabel und wiederverwendbar, da es auf einer Vielzahl von Betriebssystemen (Linux, Windows und Mac) und Compilern läuft.
- Wenn Tests fehlschlagen, sollten so viele Informationen wie möglich über das Problem bereitgestellt werden.
Google Mock (GMock)
- Es basiert auf der xUnit-Architektur.
- Es ist eine Sammlung von „Frameworks" für die Entwicklung und Automatisierung von Testfällen.
- Es ist eine Bibliothek zum Schreiben von C++-Tests.
Der Zweck der Verwendung eines Google Tests:
- Mit Google Test können wir bessere C++-Tests entwickeln.
- Es trennt die Tests, indem es jeden Test an einem bestimmten Element ausführt, wodurch sie unabhängig und wiederholbar werden.
- Google Test ist portabel und wiederverwendbar, da es auf einer Vielzahl von Betriebssystemen (Linux, Windows und Mac) und Compilern läuft.
- Wenn Tests fehlschlagen, sollten so viele Informationen wie möglich über das Problem bereitgestellt werden.
Üben mit Google Test und Google Mock
Technologie Google Test und Google Mock erfordern die Verwendung eines Build-Systems wie CMake, Bazel, Meson oder eines anderen Build-Systems.
Schritte zur Einrichtung von Google Test und Google Mock unter Verwendung des Meson Build Systems:
Projekt-Setup mit Meson: Hierfür benötigen wir eine Wrap-Datei mit der notwendigen Konfiguration. Für weitere Details über den Inhalt einer solchen Datei laden wir Sie ein, die offizielle Dokumentation des Mesonenbausystems https://mesonbuild.com/Wrap-dependency-system-manual.html zu lesen.
[wrap-file]
directory = googletest-release-1.11.0
source_url = https://github.com/google/googletest/archive/release-1.11.0.zip
source_filename = gtest-1.11.0.zip
source_hash = 353571c2440176ded91c2de6d6cd88ddd41401d14692ec1f99e35d013feda55a
patch_filename = gtest_1.11.0-1_patch.zip
patch_url = https://wrapdb.mesonbuild.com/v2/gtest_1.11.0-1/get_patch
patch_hash = d38c39184384608b08419be52aed1d0f9d9d1b5ed71c0c35e51cccbdddab7084
[provide]
gtest = gtest_dep
gtest_main = gtest_main_dep
gmock = gmock_dep
gmock_main = gmock_main_dep
Sobald die Konfiguration für diese Wrap-Datei fertig ist, können wir sie in unser Projekt herunterladen.
# gtest_proj is a variable with which we can download Google Test and Google Mock
# It will be downloaded to the subdirectory where our wrap file is located.
gtest_proj = subproject('gtest')
-> Erstellen der ausführbaren Datei:
e = executable('logic-tests',
sources: src,
dependencies: [gtest_dep, gmock_dep], dupa :
link_with: [gtest_lib, gmock_lib]
)
Die folgenden Daten werden in die ausführbare Datei aufgenommen:
- sein Name zwischen ' '
- den Quelldateien, die wir testen wollen.
src = [
'Parallelepiped_test.cpp',
'Parallelepiped.cpp',
]
- Zugang zu Bibliotheken und Nutzung von Abhängigkeiten
# gtest_dep => creating dependency for GTest
gtest_dep = gtest_proj.get_variable('gtest_dep')
# gmock_dep => creating dependency for GTest
gmock_dep = gtest_proj.get_variable('gmock_dep')
# obtaining the libraries
gtest_lib = static_library('gtest', install : true)
gmock_lib = static_library('gmock', install: true)
Vorbereitung auf das Prüfverfahren:
- Schreiben der Hauptfunktion, die dem Test entspricht:
int main(int argc, char **argv)
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
- Mock Class-Vorbereitung
class MockParallelepiped
{
public:
MOCK_METHOD(int, ParallelepipedArea, (int , int ));
};
Mocks in Tests einbinden:
- Importieren Sie die Google Mock-Namen aus dem Testing-Namensraum, damit Sie sie ohne Einschränkungen verwenden können. Sie müssen dies nur einmal pro Code tun. Denken Sie daran, dass Namensräume eine gute Idee sind und Ihrer Gesundheit zugute kommen).
- Erfinden Sie einige fiktive Dinge.
- Definieren Sie Ihre Erwartungen an sie. Zum Beispiel: Wie oft werden Sie eine Funktion aufrufen? Welche Argumente verwenden Sie? Was soll es tun und so weiter).
- Führen Sie einen Code aus, der die Mocks verwendet; optional können Sie Google Test Assertions verwenden, um das Ergebnis zu überprüfen. Wenn Sie eine gefälschte Methode mehr als einmal oder mit falschen Parametern aufrufen, erhalten Sie sofort eine Fehlermeldung.
- Wenn ein Mock zerstört wird, prüft Google Mock, ob alle mit ihm verbundenen Erwartungen erfüllt sind.
Üben mit Google Test und Google Mock
Die Funktion, die wir testen wollen:
int ParallelepipedArea(int length, int width)
{
int area = length * width;
return area;
}
int ParallelepipedVolume(int height, int length, int width)
{
int area = ParallelepipedArea(length, width);
int volume = height * area;
return volume;
}
Unser Google Test und Google Mock Test:
TEST(Parallelepiped_test, ParallelepipedVolume)
{
MockParallelepiped parallelepiped_mock_obj;
// values for the parameters of our functions
int length = 1;
int width = 1;
int height = 1;
ON_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width))
.WillByDefault(testing::Return(11));
EXPECT_EQ(ParallelepipedVolume(height, length, width), 11);
}
Der nächste Schritt besteht darin, die Datei zu kompilieren und auszuführen, um die Testergebnisse zu sehen.
PS C:\Users\siclo\OneDrive\Desktop\Testare\lovelybuild> meson compile
[2/2] Linking target logic-tests.exe
PS C:\Users\siclo\OneDrive\Desktop\Testare\lovelybuild> .\logic-tests.exe
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from Parallelepiped_test
[ RUN ] Parallelepiped_test.ParallelepipedVolume
[ OK ] Parallelepiped_test.ParallelepipedVolume (0 ms)
[----------] 1 test from Parallelepiped_test (17 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (59 ms total)
[ PASSED ] 1 test.
Nun, da wir das Ende des Artikels erreicht haben, wollen wir ein wenig über unseren Test sprechen.
Die Funktion, die wir testen wollen, ist „ParallelepipedVolume", diese Funktion gibt das Volumen zurück. In dieser Funktion finden wir eine weitere Funktion namens „ParallelepipedArea", die die Fläche liefert.
Mit dem Makro „ON_CALL" haben wir die Funktion „ParallelepipedArea" dazu gebracht, etwas anderes zu liefern als das, was sie liefern würde, wenn wir die spezifischen Parameterwerte eingeben würden.
Und im Makro „EXPECT_EQ" erwarten wir, dass die Funktion „ParallelepipedVolume" angesichts des obigen Beispiels das Richtige liefert.
Dependency Injection-Beziehung:
Dependency Injection ist eine Entwurfstechnik, bei der ein Objekt mit einem anderen Objekt, auf das es angewiesen ist, zusammengebracht wird. Diese Technik trennt die Verantwortlichkeiten für die Erstellung und Verwendung von Objekten, das zu losen verbundenen Anwendungen führt.
Ein Entwurfsmuster ist eine Lösung, die zur Behebung eines allgemeinen Problems bei der Entwicklung von Software verwendet wird. Es ist eine Beschreibung oder Vorlage für die Lösung eines Problems, die auf eine Vielzahl von Szenarien angewendet werden kann.
Lassen Sie uns nun veranschaulichen, worüber wir gerade gesprochen haben:
class interfaceParallelepiped
{
public:
virtual int ParallelepipedArea(int length, int width) = 0;
};
class parallelepiped : public interfaceParallelepiped
{
public:
int ParallelepipedArea(int length, int width)
{
int area = length * width;
return area;
}
int ParallelepipedVolume(int height, int length, int width, interfaceParallelepiped& interface_parallelepiped_obj)
{
int area = interface_parallelepiped_obj.ParallelepipedArea(length, width);
int volume = height * area;
return volume;
}
};
class mockParallelepiped
{
public:
MOCK_METHOD(int, ParallelepipedArea, (int, int));
};
TEST(testing_files, ParallelepipedVolume)
{
mockParallelepiped parallelepiped_mock_obj;
parallelepiped parallelepiped_obj;
ON_CALL(parallelepiped_mock_obj,ParallelepipedArea(1,1)).WillByDefault(testing::Return(2));
EXPECT_EQ(parallelepiped_obj.ParallelepipedVolume(1, 1, 3, parallelepiped_obj), 3);
}
Ausgangstest:
PS C:\Users\siclo\OneDrive\Desktop\Testare\lovelybuild> .\logic-tests.exe
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from testing_files
[ RUN ] testing_files.ParallelepipedVolume
[ OK ] testing_files.ParallelepipedVolume (3 ms)
[----------] 1 test from testing_files (17 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (55 ms total)
[ PASSED ] 1 test.
Lassen Sie uns ein wenig über unser Beispiel sprechen. Wir wollen dieselbe Funktion testen und Mocks auf dieselbe Funktion anwenden wie zuvor, nur dass wir es diesmal mit einem Entwurfsmuster namens Dependency Injection machen werden.
Wie Sie sehen können, haben wir eine Klasse „interfaceParallelepiped", die eine rein virtuelle Funktion namens „ParallelepipedArea" enthält. Diese Schnittstelle wird von einer „Parallelepiped"-Klasse geerbt, die die rein virtuelle Funktion überschreibt, sodass unsere Klasse nicht abstrakt ist. Die überschriebene Funktion wird so implementiert, dass sie die Fläche unseres Parallelepipeds zurückgibt. In dieser Klasse werden wir auch eine Funktion hinzufügen, die das Volumen unseres Parallelepipeds zurückgibt. Diese Funktion mit der Bezeichnung „ParallelepipedVolume" erhält 4 Parameter. Drei sind für Höhe, Länge und Breite und die vierte wird eine Instanz unserer Schnittstelle sein, mit deren Hilfe wir die Funktion „ParallelepipedArea" aufrufen, die die Fläche zurückgibt.
Als Nächstes erstellen wir eine „mockParallelepiped"-Klasse, die die Funktion innerhalb der Funktion, die wir testen wollen, nachahmt, genauer gesagt die Funktion „ParallelepipedArea". Wenn wir mit diesen Dingen fertig sind, können wir die Testfunktion vorbereiten. Es ist nicht viel anders als in unserem ersten Beispiel, solange wir in unserer Testfunktion eine Instanz der Klasse „Parallelepiped" für das Makro „EXPECT_EQ" erzeugen, unsere Instanz als Parameter an unsere Funktion übergeben und wir die Funktion auch mit unserer Instanz aufrufen werden.
Weitere Merkmale:
⦁ Mehrere Erwartungen in einem einzigen Test:
Ein Integrationstest kann mehr als eine Erwartung beinhalten. Wenn Sie mehrere Erwartungen in einer Funktion verwenden, ist die Reihenfolge, in der sie verarbeitet oder ausgewertet werden, ebenfalls wichtig. Die Erwartungen werden in der umgekehrten Reihenfolge bewertet, in der sie definiert wurden. Die ursprüngliche Erwartung, deren Abgleicher passt, wird immer für Aktion und Kardinalität verwendet.
ON_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)) .WillByDefault(testing::Return(20));
ON_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)) .WillByDefault(testing::Return(30));
ON_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)) .WillByDefault(testing::Return(40));
⦁ Erwartungen mit Kardinalitäten:
EXPECT_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)).Times(1) .WillOnce(testing::Return(20));
Sie können eine direkte Zahl zur Angabe der Kardinalität verwenden. In dieser Situation sollten Sie die Funktion genau einmal aufrufen. Null ist ebenfalls eine gültige Angabe. Damit wird überprüft, dass die Funktion nicht aufgerufen wurde. Es kann auch eine Mindestanzahl angegeben werden:
EXPECT_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)).Times( AtLeast(1).WillOnce(testing::Return(20));
Damit die Bedingung im obigen Beispiel erfüllt ist, muss die Funktion mindestens einmal aufgerufen werden. Sie ist auch dann erfolgreich, wenn sie mehrmals aufgerufen wird.
⦁ Erwartungshaltung mit Aktionen:
Sie können Aktionen verwenden, um einem Fake ein bestimmtes Verhalten zu geben. Die Definition eines Rückgabewerts ist eine gute Illustration dafür.
EXPECT_CALL(parallelepiped_mock_obj, ParallelepipedArea(length, width)).Times(1) .WillOnce(testing::Return(20));
Beim Funktionsaufruf wird der Wert 20 zurückgegeben.
int value_returned = 20;
int * pointer = &value_returned;
EXPECT_CALL(parallelepiped_mock_obj, ParallelepipedArea(2, 2)).Times(1) .WillOnce(testing::ReturnPointee(pointer));
Gibt den durch den Zeiger angegebenen Wert zurück, d. h. den Wert in der Variablen „value_returned". Weitere Informationen finden Sie auch hier:
https://google.github.io/googletest/reference/actions.html
Assertion
Das Ergebnis einer Zusicherung kann ein Erfolg, ein nicht-fataler Fehler oder ein fataler Fehler sein. Tritt ein fataler Fehler auf, wird die laufende Funktion abgebrochen. Andernfalls wird das Programm normal fortgesetzt. Assertionen werden in Tests verwendet, um sicherzustellen, dass sich der getestete Code richtig verhält. Ein Test schlägt fehl, wenn er abstürzt oder eine fehlgeschlagene Zusicherung enthält; andernfalls ist er erfolgreich.
Die meisten der unten aufgeführten Makros werden als Paar mit einer EXPECT_-Variante und einer ASSERT_-Variante dargestellt. Mit dem EXPECT_-Makro können wir nicht-fatale Fehler erhalten und die aktuelle Funktion weiterlaufen lassen, während ASSERT_ fatale Fehler verursacht und die aktuelle Funktion abbricht.
EXPECT_EQ(ParallelepipedVolume(height, length, width), 11);
- Prüfen Sie, ob das, was er zurückgibt, gleich dem ist, was er eigentlich zurückgeben sollte, kurz gesagt, prüfen Sie, ob zwei Werte gleich sind.
EXPECT_NE(ParallelepipedVolume(height, length, width), 3);
- Es ist genau das Gegenteil des EXPECT_EQ-Makros, es prüft, ob zwei Werte ungleich sind.
Zusammenfassung
Abschließend zeigen die Beschreibungen, wie nützlich Google Test und Google Mock für die Erstellung automatisierter Tests in C++ sind. Mit Meson können die Bibliotheken leicht in bestehende Projekte integriert werden.
Darüber hinaus bietet Google Test mehrere grundlegende Optionen zum Schreiben von Behauptungen. Sie können auch Logmeldungen und skalierte Traces verwenden, um zusätzliche Informationen für Tests bereitzustellen.
Außerdem ermöglicht das Framework die Untersuchung komplizierterer Probleme wie Ausnahmen und Abbrüche.Der größte Schwachpunkt des Frameworks ist die fehlende Unterstützung für asynchrone Funktionstests. Benutzer auf verschiedenen Plattformen können Probleme haben, da Google Test nicht als Threadsave gilt.
Referenzen:
Weitere Artikel anschauen:
Yocto-Projekt
Das Yocto-Projekt ist ein Open-Source-Community-Projekt, das Entwicklern hilft, angepasste Systeme auf der Basis von Linux zu erstellen. Es verfügt über ein zugängliches Toolset, das
Platzierung der Komponenten
Die Platzierung von Bauteilen ist einer der kritischsten Teile des PCB-Designs. Zunächst müssen Sie die grundlegenden Kriterien für die Anordnung von
Linux-Systemprogrammierung
Dieser Artikel konzentriert sich auf Linux -Systemaufrufe und andere Low-Level-Operationen, wie zum Beispiel die Funktionen der C-Bibliothek. Systemprogrammierung ist der Prozess der Erstellung von
EMV-Prüfung
Wenn ein elektrisches Produkt auf elektromagnetische Verträglichkeit (EMV) geprüft wird, wird festgestellt, ob es in der elektromagnetischen Umgebung,
BSP-Entwicklungsprozess
Jedes Board wird von den Herstellern mit einem Basis-BSP (Board Support Package) ausgeliefert. In den meisten Fällen müssen jedoch verschiedene Stufen der Anpassung den strengen
Kosten der BSP-Entwicklung
Das Board Support Package (BSP) stellt die Softwareverbindungsschicht dar, die es traditionell einem Echtzeitbetriebssystem (RTOS) ermöglicht, auf einer bestimmten Hardwareumgebung