Was ist SOA-Test? Tutorial mit Beispiel
Redaktion
⚡ Intelligente Zusammenfassung
SOA-Tests validieren eine serviceorientierte ArchiEine Architektur, in der lose gekoppelte Dienste Nachrichten über ein Netzwerk austauschen und dabei jeden Dienst einzeln, die Integrationen zwischen ihnen und den gesamten Geschäftsablauf von Anfang bis Ende überprüfen.
Was ist SOA-Test?
SOA (Serviceorientiert). Architektur) Testen ist das Testen des SOA-Architekturstils, bei dem die Anwendungskomponenten so konzipiert sind, dass sie über Kommunikationsprotokolle, typischerweise über ein Netzwerk, miteinander kommunizieren.
Was ist SOA?
SOA ist eine Methode zur Integration von Geschäftsanwendungen und -prozessen, um den Geschäftsanforderungen gerecht zu werden.
In Software EngineeringSOA bietet Agilität und Flexibilität für Geschäftsprozesse. Änderungen an einem Prozess oder einer Anwendung können gezielt auf eine bestimmte Komponente ausgerichtet werden, ohne das Gesamtsystem zu beeinträchtigen.
Softwareentwickler, die im SOA-Bereich arbeiten, entwickeln entweder eigene Programmbausteine oder kaufen diese zu. Leistungen.
Was ist Dienst?
Das untenstehende Diagramm zeigt ein Zahlungsgateway, das als Dienst veröffentlicht wurde und von mehreren E-Commerce-Websites aufgerufen werden kann.
- Ein Dienst kann eine funktionale Einheit einer Anwendung oder eines Geschäftsprozesses sein, die von jeder anderen Anwendung oder jedem anderen Prozess wiederverwendet oder wiederholt werden kann. (Beispielsweise ist im obigen Bild das Zahlungsgateway ein Dienst, der von jeder E-Commerce-Website wiederverwendet werden kann. Immer wenn eine Zahlung erforderlich ist, ruft die E-Commerce-Website den Zahlungsgateway-Dienst auf. Nachdem die Zahlung über das Gateway abgeschlossen wurde, wird eine Antwort an die E-Commerce-Website zurückgesendet.)
- Die Dienstleistungen sind einfach zu montieren und die Komponenten lassen sich leicht neu konfigurieren.
- Dienstleistungen lassen sich mit Bausteinen vergleichen. Sie können jede benötigte Anwendung erstellen, und das Hinzufügen oder Entfernen von ihnen aus der Anwendung oder dem Geschäftsprozess ist einfach.
- Dienstleistungen werden eher durch die von ihnen ausgeführte Geschäftsfunktion definiert als durch Codeblöcke.
Web Services
Die meisten SOA-Dienste werden als Webdienste bereitgestellt, daher ist es sinnvoll, die Mechanismen eines Webdienstaufrufs vor den Testschichten festzulegen.
Web-Services Es handelt sich um unabhängige Anwendungskomponenten, die über das Internet verfügbar sind.
Sie können im Web veröffentlicht, gefunden und genutzt werden und kommunizieren über das Internet. Die folgende Abfolge zeigt die Interaktion zwischen Anbieter, Register und Nutzer.
- Der Dienstanbieter veröffentlicht den Dienst im Internet.
- Der Client sucht in der Webdienstregistrierung nach einem bestimmten Webdienst.
- A URL und der wsdl Die benötigten Webdienste werden zurückgegeben. Verwendung der WSDL und der URLDie Kommunikation zwischen Dienstanbieter und Anfragendem erfolgt über SOAP-Nachrichten.
- Wenn ein Verbraucher einen Webdienst aufruft, wird eine HTTP-Verbindung zum Anbieter hergestellt.
- Es wird eine SOAP-Nachricht erstellt, um den Provider anzuweisen, die erforderliche Webdienstlogik aufzurufen.
- Die vom Anbieter empfangene Antwort ist eine SOAP-Nachricht, die in die HTTP-Antwort eingebettet ist. Diese HTTP-Antwort stellt das Datenformat dar, das von der Verbraucheranwendung verstanden werden kann.
Beispiel
Der untenstehende Screenshot zeigt einen Wetterbericht, der von einem externen Dienst bereitgestellt und in die Startseite einer Suchmaschine eingebettet ist.
Die Startseite einer Website und eine Suchmaschine zeigen einen täglichen Wetterbericht an. Anstatt den Wetterberichtbereich von Grund auf neu zu programmieren, kann ein Wetterberichtdienst von einem Anbieter erworben und in die Seiten integriert werden.
SOA-Testschichten
SOA besteht aus verschiedenen Technologien, und Anwendungen, die mit SOA entwickelt wurden, verfügen über verschiedene, lose gekoppelte Dienste. Das folgende Diagramm veranschaulicht die drei Ebenen, die ein Testplan abdecken muss.
Beim SOA-Testing sollten sich die Tests auf drei Systemebenen konzentrieren.
Diensteschicht
Diese Schicht besteht aus den von einem System bereitgestellten Diensten, die sich aus Geschäftsfunktionen ableiten.
Nehmen wir beispielsweise eine Wellness-Website, die aus Folgendem besteht:
- Gewicht Tracker
- Blutzucker Tracker
- Ausgleich bei Blutdruckschwankungen Tracker
TracDie KERS zeigen die jeweiligen Daten und das Datum ihrer Eingabe an. Die Dienstschicht besteht aus den Diensten, die die jeweiligen Daten aus der Datenbank abrufen:
- Gewicht TracKer-Service
- Blutzucker TracKer-Service
- Ausgleich bei Blutdruckschwankungen TracKer-Service
- Anmeldedienst
Prozessschicht
Die Prozessschicht besteht aus den Prozessen, der Sammlung von Diensten, die Teil einer einzelnen Funktionalität sind.
Die Prozesse können Teil einer Benutzeroberfläche (z. B. einer Suchmaschine) oder Teil eines ETL-Tools sein, das Daten aus der Datenbank abruft.
Der Schwerpunkt dieser Ebene liegt auf Benutzeroberflächen und Prozessen. Die Benutzeroberfläche der Gewichtung tracDer Schwerpunkt liegt auf ker und dessen Integration in die Datenbank.
Folgende Funktionen sind zu berücksichtigen:
- Hinzufügen neuer Daten
- Bearbeiten vorhandener Daten
- Ein neues erstellen tracker
- Löschen von Daten
Verbraucherschicht
Diese Ebene besteht hauptsächlich aus Benutzerschnittstellen, wie die folgende Abbildung zeigt.
Auf Grundlage dieser Schichten ist das Testen einer SOA-Anwendung in drei Ebenen unterteilt:
- Service Level
- Schnittstellenebene
- End-to-End-Level
Die beiden Vorgehensweisen unterscheiden sich: Für die Testplanung wird ein Top-Down-Ansatz verwendet, für die Testdurchführung hingegen ein Bottom-Up-Ansatz.
Strategie für SOA-Tests
Testplanungsansatz
- Die SOA-Tester sollten die gesamte Architektur der Anwendung verstehen.
- Die Anwendung muss in unabhängige Dienste aufgeteilt werden (ein Dienst, der über eine eigene Anfrage- und Antwortstruktur verfügt und nicht von einem anderen Dienst abhängig ist, um eine Antwort zu bilden).
- Die Anwendungsstruktur muss in drei Komponenten neu organisiert werden – Daten, Dienste und Frontend-Anwendungen.
- Alle Komponenten müssen sorgfältig analysiert und Geschäftsszenarien ausgearbeitet werden.
- Die Geschäftsszenarien sollten in allgemeine Szenarien und anwendungsspezifische Szenarien unterteilt werden.
- A Rückverfolgbarkeitsmatrix sollte vorbereitet sein, und alle Testfälle sollten sein tracauf Geschäftsszenarien angewendet.
Testausführungsansatz
- Jede Servicekomponente sollte getestet werden.
- Integrationstests Die Überprüfung der Servicekomponenten sollte durchgeführt werden, um den Datenfluss durch die Services und die Datenintegrität zu validieren.
- Systemtest Das vollständige Modell sollte erstellt werden, um den Datenfluss zwischen der Frontend-Anwendung und der Datenbank zu validieren.
- Performance Testing Dies sollte für eine Feinabstimmung und optimale Leistung erfolgen.
SOA-Testmethoden
1) Geschäftsszenario-gesteuerte datenbasierte Tests
- Es sollten verschiedene betriebswirtschaftliche Aspekte des Systems analysiert werden.
- Szenarien sollten auf der Grundlage der Integration der verschiedenen Webdienste der Anwendung und der Webdienste mit der Anwendung entwickelt werden.
- Die Dateneinrichtung sollte auf der Grundlage der oben genannten Szenarien erfolgen.
- Die Dateneinrichtung sollte auch End-to-End-Szenarien abdecken.
2) Stubs
- Dummy-Schnittstellen werden erstellt, um Dienste zu testen.
- Über diese Schnittstellen können verschiedene Eingaben bereitgestellt und die Ausgaben validiert werden.
- Wenn eine Anwendung eine Schnittstelle zu einem externen Dienst nutzt, der nicht getestet wird (ein Drittanbieterdienst), kann während des Integrationstests ein Stub erstellt werden.
3) Regressionstests
- Regressionstests Die Anwendung sollte bei mehreren Releases aktualisiert werden, um die Stabilität und Verfügbarkeit der Systeme zu gewährleisten.
- Es wird eine umfassende Regressionstestsuite erstellt, die die Dienste abdeckt, die einen wichtigen Teil der Anwendung bilden.
- Diese Testsuite kann über mehrere Releases des Projekts hinweg wiederverwendet werden.
4) Service-Level-Tests
Die Service-Level-Tests umfassen die Prüfung der Komponente auf Funktionalität, Sicherheit, Leistung und Interoperabilität. Jeder einzelne Service muss zunächst unabhängig getestet werden.
5) Funktionsprüfung
Funktionsprüfung sollte bei jedem Service durchgeführt werden, um:
- Stellen Sie sicher, dass der Dienst auf jede Anfrage die richtige Antwort liefert.
- Stellen Sie sicher, dass die richtigen Fehlermeldungen für Anfragen mit ungültigen oder fehlerhaften Daten empfangen werden.
- Prüfen Sie jede Anfrage und Antwort für jede Operation, die der Dienst zur Laufzeit ausführen muss.
- Überprüfen Sie die Fehlermeldungen, wenn ein Fehler auf Server-, Client- oder Netzwerkebene auftritt.
- Überprüfen Sie, ob die empfangenen Antworten das richtige Format haben.
- Prüfen Sie, ob die in der Antwort empfangenen Daten den angeforderten Daten entsprechen.
6) Sicherheitstests
Die Sicherheitsprüfung des Webdienstes ist ein wichtiger Aspekt bei der Prüfung der Serviceebene der SOA-Anwendung, da sie die Sicherheit der Anwendung gewährleistet.
Folgende Faktoren müssen beim Testen berücksichtigt werden:
- Der von WS-Security definierte Branchenstandard sollte vom Webdienst eingehalten werden.
- Sicherheitsmaßnahmen sollten einwandfrei funktionieren.
- Datenverschlüsselung und digitale Signaturen auf den Dokumenten.
- Authentifizierung und Autorisierung.
- SQL-Injection, Malware, XSS, CSRF und andere Schwachstellen sollen auf dem System getestet werden. XML.
- Denial-of-Service-Angriffe.
7) Leistungstests
Die Leistungsfähigkeit des Dienstes muss getestet werden, da Dienste wiederverwendbar sind und mehrere Anwendungen denselben Dienst nutzen könnten.
Folgende Faktoren werden bei der Prüfung berücksichtigt:
- Leistung und Funktionalität des Dienstes müssen unter hoher Belastung getestet werden.
- Die Leistung des Dienstes muss verglichen werden, wenn er einzeln funktioniert und wenn er in die Anwendung integriert ist.
- Lastprüfung Der Service sollte durchgeführt werden, um die Antwortzeit zu überprüfen, Engpässe aufzudecken, die Auslastung von CPU und Speicher zu überprüfen und die Skalierbarkeit vorherzusagen.
8) Prüfung der Integrationsebene
- Die Service-Level-Testung gewährleistet das ordnungsgemäße Funktionieren der einzelnen Dienste; sie garantiert jedoch nicht das Funktionieren der gekoppelten Komponenten.
- Bei den Integrationstests liegt der Fokus hauptsächlich auf der Schnittstellen.
- Diese Phase deckt alle möglichen Geschäftsszenarien ab.
- In dieser Phase sollten erneut nicht-funktionale Tests der Anwendung durchgeführt werden. Sicherheits-, Compliance- und Leistungstests gewährleisten die Verfügbarkeit und Stabilität des Systems in allen Aspekten.
- Die Kommunikations- und Netzwerkprotokolle sollten getestet werden, um die Konsistenz der Datenkommunikation zwischen den Diensten zu validieren.
9) End-to-End-Tests
Diese Phase stellt sicher, dass die Anwendung sowohl funktional als auch nicht-funktional den Geschäftsanforderungen entspricht.
Die folgenden Artikel werden garantiert getestet während End-to-End-Tests:
- Alle Dienste funktionieren nach der Integration wie erwartet
- Ausnahmebehandlung
- Benutzeroberfläche der Anwendung
- Korrekter Datenfluss durch alle Komponenten
- Geschäftsprozess
Herausforderungen beim SOA-Testing
Die Anwendung dieser Methoden ist selten unkompliziert, und die folgenden Schwierigkeiten treten bei fast jedem SOA-Programm wieder auf.
- Fehlende Schnittstellen für Dienste.
- Der Testprozess erstreckt sich über mehrere Systeme, was einen komplexen Datenbedarf mit sich bringt.
- Die Anwendung besteht aus einer Sammlung verschiedener Komponenten, die sich tendenziell ändern, weshalb Regressionstests häufiger erforderlich sind.
- Aufgrund des mehrschichtigen Aufbaus ist es schwierig, Defekte zu isolieren.
- Da ein Dienst von verschiedenen Schnittstellen genutzt wird, ist die Last schwer vorherzusagen, was die Planung von Leistungstests umständlich macht.
- SOA ist eine Sammlung heterogener Technologien. Das Testen einer SOA-Anwendung erfordert Personen mit unterschiedlichen Kompetenzen, was wiederum die Planungs- und Ausführungskosten erhöht.
- Da die Anwendung mehrere Dienste integriert, bringt das Sicherheitstesting einige Schwierigkeiten mit sich. Die Validierung von Authentifizierung und Autorisierung gestaltet sich schwierig.
SOA-Testtools
Auf dem Markt sind zahlreiche SOA-Testtools erhältlich, die Anwender beim Testen von SOA-Anwendungen unterstützen. Hier sind einige der gängigsten SOA-Testtools.
1) SoapUI
SoapUI ist ein Open-Source-Tool für funktionale Tests von Diensten und API-Tests.
- Desktopanwendung
- Unterstützt mehrere Protokolle – SOAP, REST, HTTP, JMS, AMF, JDBC
- Webdienste können entwickelt, überprüft und aufgerufen werden.
- Kann auch für Lasttests verwendet werden. Automatisierungstestsund Sicherheitstests
- Stubs können von MockServices erstellt werden
- Webdienstanfragen und -tests können automatisch über den Webdienstclient generiert werden.
- Verfügt über integrierte Berichtswerkzeuge
- Entwickelt von SmartBear, das sowohl das Open-Source SoapUI Vertrieb und das kommerzielle ReadyAPI Ausgabe
2) Broadcom Service Virtualization (ehemals iTKO LISA)
LISA ist eine Produkt-Suite, die eine Lösung für Funktionstests verteilter Systeme wie SOA bietet. Das Produkt wurde von iTKO an CA Technologies übertragen und wird heute unter dem Namen Broadcom Service Virtualization vertrieben.
- Kann auch für Regressions-, Integrations-, Last- und Leistungstests verwendet werden.
- Kann zum Entwerfen und Ausführen von Tests verwendet werden.
3) UFT One (ehemals HP Service Test)
Service Test ist ein funktionales Testtool, das sowohl UI- als auch Shared-Services-Tests unterstützt. Die API-Testfunktionen wurden in Unified Functional Testing integriert, das jetzt von [Name des Unternehmens/der Organisation] vertrieben wird. OpenText as UFT One.
- Sowohl Funktionstests als auch Leistungstests von Diensten können mit einem einzigen Skript durchgeführt werden.
- Integriert in Quality Center, jetzt verkauft als OpenText ALM / Qualitätszentrum.
- Es lassen sich enorme Mengen an Diensten und Daten verwalten.
- Unterstützt Interoperabilitätstests durch Simulation von JEE-, AXIS- und DotNet-Clientumgebungen.
4) Parasoft SOAtest
Parasoft SOAtest ist eine Suite von Test- und Analysetools, die für das Testen von APIs und API-gesteuerten Anwendungen entwickelt wurde.
- Unterstützt Webdienste, REST, JSON, MQ, JMS, TIBCO, HTTP und XML-Technologien.
- Funktions-, Komponenten-, Integrations-, Regressions-, Sicherheits-, Interoperabilitäts-, Konformitäts- und Leistungstests sind möglich.
- Stubs können erstellt werden mit Parasoft Virtualisieren, die leistungsfähiger sind als SoapUI MockServices.
Anwendungsfälle für SOA-Tests
Das untenstehende Beispiel wendet die oben genannten Strategien, Methoden und Werkzeuge schrittweise auf eine einzelne E-Commerce-Website an.
Betrachten Sie eine E-Commerce-Website, die die folgenden Funktionen und Unterfunktionen enthält.
Auftragsabwicklung
Das nachstehende Diagramm unterteilt die Auftragsabwicklung in die Teilfunktionen, die zu Dienstleistungen werden.
PHASE 1
In der ersten Phase des SOA-Tests, der Teststrategiephase, wird die Anwendung in Dienste und Geschäftsfunktionen unterteilt.
Betrachten wir die folgenden Dienste in der Anwendung.
- Bestellung anlegen
- Überprüfen Sie den Kundenstatus
- Auftragsstatus ändern
- Bestellstatus überprüfen
- Inventar prüfen
Die Geschäftsfunktionen entsprechen den Funktionen der Website.
Hinweis: Das Teststrategiedokument enthält die Liste der Dienste und Funktionen, die getestet werden müssen.
PHASE 2
Dies ist die Testplanungsphase. Testfälle werden für jedes Level geschrieben.
End-to-End-Ebene. Für jeden Anwendungsfall und jeden Arbeitsablauf werden Testfälle erstellt. Nachfolgend finden Sie Beispiele für Testfälle.
- Erstellen Sie eine Bestellung mit einem aktiven Benutzer.
- Erstellen Sie eine Bestellung mit einem inaktiven Benutzer.
- Erstellen Sie eine Bestellung mit einem verfügbaren Produkt, wobei die Bestellmenge kleiner als die verfügbare Menge ist.
- Erstellen Sie eine Bestellung mit einem verfügbaren Produkt, wobei die Bestellmenge größer als die verfügbare Menge ist.
- Erstellen Sie eine Bestellung mit mehreren Artikeln.
- Eine Bestellung vollständig stornieren.
- Eine Bestellung teilweise stornieren.
Integrationsgrad. Für die Integration von Datenbank und Benutzeroberfläche werden Testfälle erstellt. Nachfolgend finden Sie Beispieltestfälle.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. Stellen Sie sicher, dass die Bestellung in der Datenbank erstellt wird.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. Überprüfen Sie, ob der für die Bestellung berechnete Preis korrekt ist.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. Überprüfen Sie, ob die verfügbare Produktmenge um den Bestellwert reduziert wird.
- Überprüfen Sie, ob der auf der Benutzeroberfläche angezeigte Status der Bestellung mit dem in der Datenbank übereinstimmt.
- Stornieren Sie die Bestellung und überprüfen Sie, ob der Status der Bestellung in der Datenbank geändert wurde.
- Bei der ersten Zahlung sollten Sie überprüfen, ob die in der Benutzeroberfläche eingegebenen Zahlungsdaten in der Datenbank gespeichert wurden.
- Überprüfen Sie bei der Rückgabe von Zahlungen, ob die Zahlungsdetails in der Datenbank auf der Benutzeroberfläche angezeigt werden.
Service Level. Jeder Dienst wird auf alle Datenbedingungen getestet. Nachfolgend einige Beispiele.
| Nein. | Bestelldetails | Bestellbedingung |
|---|---|---|
| 1 | Bestellung anlegen. Anzahl der Artikel = 1 | Bestellmenge < Menge in der Datenbank |
| 2 | Bestellung anlegen. Anzahl der Artikel > 1 | Bestellmenge < Menge in der Datenbank |
| 3 | Bestellung anlegen. Anzahl der Artikel = 1 | Bestellmenge > Menge in der Datenbank |
| 4 | Bestellstatus überprüfen | Status der Datenbank = Aktiv |
| 5 | Bestellstatus überprüfen | Status in der Datenbank = Ausgeliefert |
| 6 | Bestellstatus überprüfen | Status in der Datenbank = Abgebrochen |
| 7 | Bestellstatus überprüfen | Bestell-ID = Ungültig |
| 8 | Überprüfen Sie die Produktverfügbarkeit | Produktmenge >0 |
| 9 | Überprüfen Sie die Produktverfügbarkeit | Produktmenge =0 |
| 10 | Überprüfen Sie die Produktverfügbarkeit | Produkt-ID = ungültig |
PHASE 3 — Testdurchführung
Die Testdurchführung erfolgt nach dem Bottom-up-Ansatz: Zuerst werden Tests auf Serviceebene durchgeführt, dann auf Integrationsebene und zuletzt auf End-to-End-Ebene.
1) Serviceniveau
Nehmen wir an, dass die SoapUI Das Tool dient zum Testen der Anwendung. Die WSDL und URL werden im Testfenster angezeigt SoapUIDie Anfrage für jeden Dienst wird im Anfragefenster angezeigt. Durch die Anpassung der Daten gemäß den Testfällen auf Dienstebene werden für jeden Testfall Anfragen erstellt.
| Testfall | PREISANFRAGE (Request) | Erwartete Antwort |
|---|---|---|
| Bestellung erstellen. Anzahl der Artikel = 1, Bestellmenge < Datenbankmenge | x2 2 | o3251 Erfolgreich |
| Bestellung erstellen. Anzahl der Artikel > 1, Bestellmenge < Datenbankmenge | y1 1 y2 3 | o3251 Erfolgreich |
| Bestellung erstellen. Anzahl Artikel = 1, Bestellmenge > Datenbankmenge | x23 200 | Null Erfolglos |
| Bestellstatus prüfen. Status in der Datenbank = Aktiv | o9876 | Aktiv Erfolgreich |
| Bestellstatus prüfen. Status in der Datenbank = Versendet | o9656 | Versand Erfolgreich |
| Bestellstatus prüfen. Bestellnummer = Ungültig | y5686 | null Erfolglos |
| Produktverfügbarkeit prüfen. Produktmenge >0 | d34 | 34 Ja Erfolgreich |
| Produktverfügbarkeit prüfen. Produktmenge = 0 | y34 | 0 NEIN Erfolgreich |
| Produktverfügbarkeit prüfen. Produkt-ID = ungültig | sder | Erfolglos |
2) Integrationsebene
Die Integrationstests werden auf der Benutzeroberfläche und der Datenbank ausgeführt. Erstellen Sie eine Bestellung mit einem einzelnen Artikel:
- Ein Benutzer öffnet die Website.
- Der Benutzer möchte eine Bestellung aufgeben.
- Der Benutzer wählt ein gültiges Produkt und die entsprechende Menge aus und speichert die Bestellung.
- Es sollte eine Meldung angezeigt werden, die bestätigt, dass die Bestellung erfolgreich aufgegeben wurde.
- Der Benutzer öffnet die Datenbank und prüft, ob die Bestelldetails mit den auf der Website eingegebenen Daten übereinstimmen.
3) End-to-End-Ebene
Die Geschäftsprozesse und Anwendungsfälle werden über die Benutzeroberfläche ausgeführt. Erstellen Sie eine Bestellung mit mehreren Artikeln:
- Ein Benutzer öffnet die Website.
- Der Benutzer möchte eine Bestellung aufgeben.
- Der Nutzer erkundigt sich nach einem gültigen Produkt und der gewünschten Menge und fügt diese dem Warenkorb hinzu.
- Weitere gültige Produkte werden in den entsprechenden Mengen hinzugefügt und die Bestellung gespeichert. Die Zahlung erfolgt über eine neue Zahlungsmethode und die Bestellung wird aufgegeben.
- Es sollte die Meldung „Bestellung erfolgreich aufgegeben“ angezeigt werden.
- Ein Tester sollte überprüfen, ob der gesamte Ablauf ohne Datenverfälschung vollständig abläuft.
