Vorbereitung für eingebettete Softwaretests_8 Softwaretests

Softwaretest

Testen: Betreiben eines Programms unter festgelegten Bedingungen, um Fehler zu erkennen und die Softwarequalität zu bewerten.

Objekte: Programme, Daten, Dokumente.

Zweck: Fehler finden, prüfen, ob sie den Benutzeranforderungen entsprechen, und die Fehlerursache ermitteln (Qualität kann nicht analysiert werden).

Eingebettete Hardware wird in der Regel mit speziellen Prüfgeräten getestet. Bei der Software stehen neben der logischen Korrektheit auch die Systemleistung und -robustheit, die Echtzeitleistung und die Analyse der Kombination von Software und Hardware im Fokus.

Testmethoden

Dynamisch: Blackbox, Whitebox, Greybox.

• Blackbox: Testen Sie die Funktion des Programms und behandeln Sie das Programm als Blackbox.

• Weiße Box: Transparente weiße Box, die die spezifische Logik des Codes testet.

• Gray Box: eine Kombination aus beiden, die häufig bei Systemtests verwendet wird.

Statisch: Inspektion an der Rezeption, Codeüberprüfung, Code-Komplettlösung.

• Kontrollen vor Ort: Entwickler selbst überprüfen.
• Codeüberprüfung: Menschliche Überprüfung durch Entwickler und Tester.
• Code-Komplettlösung: Bietet Inspektion von Testfällen.

Äquivalenzklasseneinteilung: Wenn das Programm beispielsweise 1 _{1000 eingibt, tatsächlich 2} 10 äquivalent ist, testen Sie einfach einen typischen Wert.

Grenzwertanalyse: Grenze.

Falsche Vermutung: Möglicherweise stimmt etwas nicht.

Kausalität: Bei komplexen Programmeingabebeziehungen wie Einschränkungen, Kombinationen usw. ist es schwierig, sie mit Äquivalenzklassen und Grenzwerten auszudrücken.

Logische Abdeckungstests müssen jede Abdeckung verstehen und wissen, wie viele Testfälle sie benötigt.

Informationen zum Verständnis der verschiedenen Urteile hier finden Sie in diesem Artikel: Dynamische White-Box-Tests – Testmethode für die Logikabdeckung_Deep Autumn Hongfengs Blog – CSDN-Blog

Beispiel:

Anweisungsabdeckung sc: Alle Anweisungen (quadratische) werden einmal ausgeführt, nicht alle Fälle werden einmal ausgeführt. Die beiden Urteile können also TT FF oder TF FT sein, zwei Testfälle.

Entscheidungsabdeckung/Branchenabdeckung (DC): Jedes Urteil wurde einmal vollstreckt, oder TT FF oder TF FT können erfüllt werden.

Bedingungsabdeckung: Alle logischen Urteile (d. h. eine einzelne logische Bedingung) wurden mindestens einmal erfüllt. Das heißt, x>0 x<0 y>0 y<0 magic>0 magic<0 ist mindestens einmal passiert.

Bedingungsentscheidungsabdeckung: Sowohl die Bedingungs- als auch die Entscheidungsabdeckung sind erfüllt.

Bedingte Kombinationsabdeckung: Alle möglichen Situationen in jeder bedingten Anweisung müssen auftreten, d. h. x>0 y>0, x>0 y<0, x<0 y>0, x<0 y<0 und magic> Die Kombination von 0 magic<0 wurde verwendet und die Anweisungen in verschiedenen bedingten Abdeckungen müssen nicht kombiniert werden.

Pfadabdeckung: Solange alle möglichen Fälle im Flussdiagramm aufgetreten sind. Dies ist der Fall, in dem die beiden Wenns TT, TF, FT und FF sind. Aus der Abbildung ist jedoch ersichtlich, dass wenn x y>0, magic=x+y+10 auch >0 sein muss, also bedeutet x>0 y>0 magic<0, dass TF unmöglich ist. Es gibt also nur drei Fälle.

Abdeckung der geänderten Bedingungsbeurteilung:

1. Alle möglichen Ausgabeergebnisse werden angezeigt.
2. Die Änderung einer der zahlreichen Voraussetzungen kann Auswirkungen auf das Urteilsergebnis haben.

Beispiel: Programm

{
    
    
    if(A&&(B||C))
        return true;
}

Erstens deckt die Kombination der Bedingungen alle Möglichkeiten ab: ABC ist 000.001.010.011.100.110.111.

Anweisungsabdeckung: Solange sie wahr ist, können alle Anweisungen ausgeführt werden. 1 Anwendungsfall reicht aus.

Decken Sie alle Möglichkeiten ab, benötigen Sie nur eines von 0 Ergebnissen und eines von 1 Ergebnissen. Eine weitere Anforderung ist jedoch: Es gibt einen Anwendungsfall, der nur eine Eingabe im Testfall ändert, und eine Änderung dieses Anwendungsfalls kann zu einer Änderung des Ergebnisses führen.

Eine Änderung von 000 ändert das Ergebnis nicht.

Ändern Sie einfach 001 in 101 und 26 kann herausgenommen werden.

usw.

Durch Ändern von A ändert sich das Ergebnis: 26,37,48.

Durch Ändern von B ändert sich das Ergebnis: 57.

Durch Ändern von C ändert sich das Ergebnis: 56.

Daher müssen mindestens folgende Werte enthalten sein: 5,6,7,3.

Testphase, Testniveau

Unit-Tests: Code-Tests, z. B. White-Box-Tests.

Integrationstests: Modulkombinationstests. Bei der inkrementellen Gruppenmontage wird zunächst ein Teil getestet und dann schrittweise neue Module integriert, beginnend auf der oberen oder unteren Ebene. Zum Beispiel White-Box-Tests.

• Treibermodul: Entwickelt für Treibertests.
• Stub-Modul: Es wird vorübergehend entwickelt und bereitgestellt, um vom zu testenden Modul aufgerufen zu werden.

Bestätigungstest:

• Abnahmetest: Der Benutzer führt einen Abnahmetest für das Projekt durch, um festzustellen, ob es der Softwareanforderungsspezifikation srs entspricht.
• Alpha-Test: Test in der Entwicklungsumgebung, Übergang zur Beta.
• Betatests: Tests der tatsächlichen Benutzerumgebung. Veröffentlichung erst nach Bestehen möglich.

Systemtests: Stellen Sie das System in die tatsächliche Umgebung und testen Sie seine Leistung. Zum Beispiel Gray-Box-Tests.

Debuggen

Cross-Debugging ist unerlässlich. Der Debugger und das Hojo-Programm befinden sich auf verschiedenen Computern, und es gibt eine Kommunikationsmethode zum Herstellen des Kontakts. Auf dem Zielcomputer befindet sich normalerweise ein Agent, der den Debugger bei der Ausführung unterstützt.

Durch das Debuggen kann die Ausführung des Programms gesteuert und Informationen wie Speicher, Register und Variablen geändert werden.

Direkter Test: Host-Ziel

Debug-Monitor-Methode: Der Debugger auf dem Host-Computer wird über JTAG usw. auf den Monitor des Zielcomputers heruntergeladen.

ROM-Emulatormethode: Fügen Sie ihn in den Zielcomputer ein, emulieren Sie ein schreibgeschütztes ROM und stellen Sie eine Verbindung zum Hostcomputer her.

Online-Emulator-Methode: Simulieren Sie die CPU.

On-Chip-Debugging-Methode: Einige Registerwerte auf dem Mikrocontroller können über die JTAG-Schnittstelle abgerufen werden. Unterstützt jetzt im Allgemeinen zwei Modi zum Debuggen und Ausführen.

Simulatormethode: Alle befinden sich auf der Entwicklungsplattform und simulieren die Hardware vollständig.

Der Unterschied zwischen Debuggen und Testen: Beim Testen geht es darum, Fehler zu finden, beim Debuggen geht es darum, Fehler zu lokalisieren und das Programm zu ändern, um nach dem Testen die erwarteten Ergebnisse zu erzielen.

Software-Rezension

Verifizierung und Bestätigung

Konzentrieren Sie sich auf Prozesse und Ergebnisse.