Objawy

29.11.2021 Testowanie usług internetowych.

Korzystanie z zewnętrznych usług SOAP Operacje
SOAP (prosty protokół dostępu do obiektów) to ustandaryzowany protokół przesyłania wiadomości pomiędzy klientem a serwerem. Zwykle jest używany w połączeniu z protokołem HTTP(S), ale może także współpracować z innymi protokołami warstwy aplikacji (takimi jak SMTP i FTP). Testowanie SOAP z punktu widzenia technik testowania nie różni się zasadniczo od pracy z innymi API, ale wymaga

wstępne przygotowanie

(w zakresie teorii protokołów) i specjalne narzędzia testujące. W tym artykule chciałbym sformułować małą listę kontrolną niezbędnej wiedzy i umiejętności, która będzie równie przydatna zarówno dla testera SOAP (który często nie ma pojęcia, czego się chwycić po ustaleniu zadania), jak i menedżera, który jest zmuszeni do oceny wiedzy testerów i opracowania planów szkoleń.

Podstawa teoretyczna
Fakt, że SOAP jest protokołem, ma wiele implikacji dla testowania: należy przestudiować sam protokół, „podstawowe” standardy i protokoły, na których jest oparty, oraz (jeśli to konieczne) istniejące rozszerzenia.

XML-a
XML to język znaczników podobny do HTML. Każda wiadomość wysyłana/odbierana za pośrednictwem protokołu SOAP jest dokumentem XML, w którym dane mają wygodną strukturę i są łatwe do odczytania, na przykład:
Julia
Natasza

Przypomnienie

Nie zapomnij napisać artykułu!
Możesz dowiedzieć się więcej o XML w w3schools lub codenet (w języku rosyjskim). Koniecznie zwróć uwagę na opis przestrzeni nazw (metoda rozwiązywania konfliktów przy opisywaniu elementów w XML) - ich użycie jest wymagane w SOAP.

...

...

XSD
W swojej pracy możesz także natknąć się na różne „rozszerzenia” SOAP – standardy takie jak WS-*. Jednym z najpopularniejszych jest WS-Security, który umożliwia pracę z szyfrowaniem i podpisami elektronicznymi. Często razem z nim używana jest WS-Policy, za pomocą której możesz zarządzać prawami do korzystania z Twojej usługi.

Przykład użycia WS-Security:

Alicja
6S3P2EWNP3lQf+9VC3emNoT57oQ=
YF6j8V/CAqi+1nRsGLRbuZhi
2008-04-28T10:02:11Z

Wszystkie te rozszerzenia są dość złożonymi strukturami, które nie są używane w każdej usłudze SOAP; jest mało prawdopodobne, aby ich szczegółowe badania na początkowym etapie opanowania testowania SOAP były istotne.

Narzędzia

Jak już rozumiesz, SOAP to poważna sprawa; aby z nim pracować, musisz znać teorię i liczne standardy. W praktyce taka złożoność wiązałaby się z bardzo dużymi kosztami pracy (np. za każdym razem trzeba byłoby patrzeć na diagram w notatniku i wysyłać żądania za pomocą curl). Dlatego stworzono narzędzia ułatwiające pracę z SOAP.

Edytory XML/XSD
Dobry tester rozpoczyna testowanie już na etapie pisania dokumentacji, dlatego do testowania obwodów wygodnie jest skorzystać ze specjalnych edytorów. Dwie najbardziej znane to Oxygen (wieloplatformowa) i Altova (tylko Windows); obaj są płatni. Są to bardzo potężne programy, z których analitycy aktywnie korzystają przy opisywaniu usług.

W mojej praktyce przydatne okazały się trzy funkcje edytora: wizualizacja XSD, generowanie XML na podstawie XSD oraz walidacja XML na podstawie XSD.

1. Wizualizacja XSD potrzebne do wizualnej reprezentacji diagramu, co pozwala szybko zidentyfikować wymagane elementy i atrybuty, a także istniejące ograniczenia. Na przykład w przypadku żądania CheckTextRequest wymagany jest element tekstowy, a wszystkie trzy atrybuty są opcjonalne (atrybut opcji ma domyślną wartość zero).

Wizualizacja jest konieczna, gdy na diagramie występuje wiele rodzajów i ograniczeń. Jeśli potrzebujesz tylko tego i nie chcesz płacić za specjalne edytory, możesz rozważyć bezpłatne alternatywy (na przykład JDeveloper).

2. Generowanie XML w oparciu o XSD przydatne, gdy chcesz zobaczyć prawidłowy przykład wiadomości. Używam go do szybkiego eksperymentowania z możliwymi uzupełnieniami wiadomości i testowania niuansów działania ograniczeń.

3. Po skorzystaniu z funkcji z punktu 2 warto przeprowadzić Walidacja XML względem XSD– czyli sprawdź poprawność wiadomości. Łącznie funkcje 2 i 3 pozwalają wychwycić trudne defekty w XSD, nawet gdy sama usługa jest w fazie rozwoju.

Narzędzie testowe – SoapUI

Testowanie SOAP prawie zawsze wiąże się z użyciem SoapUI. O korzystaniu z tego narzędzia można przeczytać w różnych źródłach (,), jednak najskuteczniejsze będzie zapoznanie się z oficjalną dokumentacją. Wyróżniam 8 warunkowych poziomów biegłości SoapUI:

Poziom 1 – Potrafię wysyłać prośby
Naucz się tworzyć projekt w oparciu o WSDL. SoapUI może wygenerować dla Ciebie wszystkie niezbędne zapytania; Wystarczy sprawdzić, czy są one poprawnie wypełnione i kliknąć przycisk „Wyślij”. Kiedy już rozwiniesz umiejętności tworzenia prawidłowych zapytań, musisz opanować sztukę tworzenia błędnych zapytań powodujących błędy.

Poziom 2 – Potrafię wykonywać zestawy testów i przypadki testowe
Zacznij robić mini-autotesty. Zestawy testowe i przypadki testowe umożliwiają tworzenie skryptów testujących API, przygotowywanie danych do żądań i automatyczne sprawdzanie otrzymanej odpowiedzi, aby upewnić się, że jest zgodna z oczekiwaniami. Na początku można ich używać po prostu jako kolekcji zapytań. Na przykład, jeśli stworzyłeś usterkę i chcesz ją szybko sprawdzić po naprawieniu, możesz przydzielić oddzielny zestaw testowy specjalnie na potrzeby zgłaszania usterek.

Poziom 3 – Potrafię pisać twierdzenia
Po opanowaniu przypadków testowych przydatne będzie nauczenie się, jak sprawić, by były one automatycznie weryfikowalne. Po tym nie będziesz już musiał szukać informacji o odpowiedzi oczami: jeśli nastąpi weryfikacja automatyczna, sprawy zostaną oznaczone na zielono (jeśli weryfikacja została zaliczona) lub na czerwono (jeśli nie została zaliczona). SoapUI zapewnia duży zestaw możliwych asercji, ale najwygodniejsze i najprostsze to Zawiera i Nie zawiera. Za ich pomocą możesz sprawdzić dostępność konkretny tekst w otrzymanej odpowiedzi. Te kontrole obsługują również wyszukiwanie wyrażeń regularnych.

Poziom 4 – używaj XPath i/lub XQuery w asercjach
Dla tych, którzy są trochę zaznajomieni z interfejsem użytkownika przy użyciu Selenium, język XPath jest czymś znanym. Z grubsza mówiąc, XPath umożliwia wyszukiwanie elementów w dokumencie XML. XQuery to podobna technologia, która może wewnętrznie wykorzystywać XPath; ten język jest znacznie potężniejszy, przypomina SQL. Obydwa te języki można stosować w asercjach. Kontrole z ich pomocą są bardziej ukierunkowane i stabilne, dzięki czemu Twoje sprawy będą cieszyć się większą pewnością.

Poziom 5 – Potrafię pisać złożone testy wykorzystując specjalne kroki

Przypadki testowe mogą zawierać nie tylko jedno żądanie, ale także kilka (na przykład, gdy chcesz emulować standardowy scenariusz użytkownika „utwórz encję” → „eksportuj encję”). Pomiędzy żądaniami mogą występować inne specjalne kroki, na przykład:

Właściwości i transfer właściwości (pomagają w ponownym wykorzystaniu danych i przesyłaniu ich między żądaniami);
Żądanie JDBC (służy do pobierania danych z bazy danych);
Warunkowe Goto (pozwala na tworzenie rozgałęzień lub pętli w przypadku testowym);
Uruchom TestCase (pomaga umieścić niektóre typowe zapytania w oddzielnych przypadkach testowych i wywołać je w razie potrzeby).

Poziom 6 – korzystanie ze skryptów Groovy

SoapUI umożliwia pisanie skryptów Groovy w różnych miejscach. Najprostszym przypadkiem jest wygenerowanie danych w samym zapytaniu za pomocą wstawek $(=). Cały czas korzystam z tych wkładek:

$(=nowa data().format(“rrrr-MM-dd’T’HH:mm:ss”))– wstawić aktualną datę i godzinę w wymaganym formacie;
$(=Java.util.UUID.randomUUID())– aby wstawić poprawnie utworzony losowy identyfikator GUID.

Pełnoprawne skrypty mogą być używane jako kroki w sprawach i kontrolach. W pewnym momencie odkryjesz, że kilka specjalnych kroków z piątego poziomu można zastąpić jednym skryptem.

Poziom 7 – korzystanie z MockServices
SoapUI oparty na WSDL może generować obiekty próbne. Próbny obiekt to najprostsza symulacja usługi. Za pomocą „makiet” możesz rozpocząć pisanie i debugowanie przypadków testowych jeszcze zanim usługa będzie faktycznie dostępna do testów. Można ich także używać jako „odcinków” dla tymczasowo niedostępnych usług.

Poziom 8 – Bóg SoapUI
Czy znasz różnicę między płatnym a darmowe wersje SoapUI i użyj interfejsu API SoapUI w kodzie. Używasz wtyczek i uruchamiasz sprawy za pomocą wiersza poleceń i/lub CI. Twoje przypadki testowe są proste i łatwe w utrzymaniu. Generalnie „zjadłeś psa” na tym instrumencie. Chętnie porozmawiam z kimś, kto opanował SoapUI na tym poziomie. Jeśli nim jesteś, zarejestruj się w komentarzu!

Testowanie z językami programowania

Oto przykład, jak wygląda żądanie do API YandexSpeller wykonane przy użyciu groovy-wslite:

importuj plik wslite.soap.*
klient def = nowy klient SOAP("http://speller.yandex.net/services/spellservice?WSDL")
def odpowiedź = klient.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
ciało (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
tekst („błąd”)
}
}
}
twierdzenie „błąd” == odpowiedź.CheckTextResponse.SpellResult.error.s.text()
potwierdzić „1” == [e-mail chroniony]()

O ile wiem, nie ma jeszcze frameworków wysokiego poziomu (jak Rest-assured) do testowania SOAP, ale ostatnio pojawiło się ciekawe narzędzie - karate. Za jego pomocą można opisać przypadki testowania SOAP i REST w postaci skryptów typu Cucumber / Gherkin. Dla wielu testerów przejście na karate będzie idealnym rozwiązaniem, ponieważ takie scenariusze, pod względem złożoności pisania i obsługi przypadków, będą plasować się gdzieś pośrodku pomiędzy wykorzystaniem SoapUI, a napisaniem własnego frameworka do testowania SOAP.

Wniosek

Jest mało prawdopodobne, że kiedykolwiek będziesz chciał przetestować SOAP tylko dla siebie (tak jak w przypadku REST). Jest to protokół o dużej wadze, używany w poważnych rozwiązaniach dla przedsiębiorstw. Ale jego ciężkość jest jednocześnie prezentem dla testera: wszystkie zastosowane technologie są ustandaryzowane, a narzędzia do pracy są wysokiej jakości. Od testera wymagana jest jedynie chęć ich poznania i wykorzystania.

Zróbmy taką samą listę kontrolną niezbędnych umiejętności dla testera. Jeśli więc dopiero zaczynasz testować usługi SOAP, musisz wiedzieć i umieć korzystać z:

WSDL.
MYDŁO.
Edytory XML/XSD (na poziomie wizualizacji XSD).
SoapUI na poziomie 1.

Jak widać główny nacisk położony jest na poznanie standardów; w SoapUI wystarczy po prostu umiejętność wykonywania zapytań. Kiedy zagłębisz się w testowanie SOAP, napotkasz zadania, które będą wymagały poważniejszych umiejętności i wiedzy, ale nie powinieneś próbować uczyć się wszystkiego na raz. Dużo ważniejsza jest konsekwencja w zwiększaniu poziomu złożoności realizowanych zadań. Stosując się do tej wskazówki, pewnego dnia zdasz sobie sprawę, że stałeś się dobrym specjalistą w tej dziedzinie!

Usługi internetowe w 1C

W tym artykule omówione zostaną kwestie integracji 1C z istniejącymi usługami internetowymi i wykorzystania samego 1C jako usługi internetowej.

W tym przypadku usługi sieciowe będą rozumiane jako systemy działające w Internecie i umożliwiające interakcję z nimi nie tylko za pośrednictwem protokołu SOAP (który jest właśnie usługą sieciową), ale także w inny sposób, w tym poprzez zwykłe żądania HTTP(S).

Ryzyko związane z korzystaniem z usług internetowych 1C

Platforma 1C81 wprowadziła wdrożenie usług sieciowych.

Ale ich użycie jest obarczone ryzykiem:

1C8 nie działa dobrze na HTTPS, nie ma narzędzi diagnostycznych, więc czasami nie da się zrozumieć, dlaczego, nawet jeśli jest certyfikat, usługa nie chce działać przez HTTPS. Rozwiązaniem jest wdrożenie usług internetowych za pośrednictwem CURL lub utworzenie tunelu HTTPS.
1C8 przestrzega swoich zasad sprawdzania poprawności schematów WSDL. Czasami z niewyjaśnionych powodów schemat WSDL nie chce zostać załadowany do łącza WS. Przyczynę możesz znaleźć tylko na forum partnerskim u jednego specjalisty. Nie ma narzędzi do diagnostyki schematu WSDL, nie jest wskazywana nawet przyczyna ani linia, w której ładowanie schematu zostało przerwane.

Zasady budowania usług sprzedażowych

Klient otrzymuje dokument sprzedaży (paragon) tylko w przypadku pomyślnego przeprowadzenia transakcji serwisowej. W przeciwnym wypadku możliwa jest sytuacja, gdy klient otrzymuje czek i ma pewność, że otrzymał usługę, choć w rzeczywistości jej nie otrzymał.

Korzystanie z zewnętrznych usług SOAP

Usługi sieciowe SOAP wykorzystują schematy WSDL i obiekty XDTO do reprezentowania danych.

Ładowanie WSDL

Aby skorzystać z usługi zewnętrznej należy pobrać jej schemat WSDL.

Sprawdzanie ważności schematu WSDL

Czasami schemat WSDL nie ładuje się do 1C. Ważność (poprawność) schematu możesz sprawdzić za pomocą dowolnego walidatora schematu WSDL, np. http://www.validwsdl.com/.

Należy wgrać schemat na jakąś stronę http (można skorzystać z ftp) i wskazać adres pliku, w którym załadowany jest schemat:

Funkcje ładowania WSDL w 1C

Osobliwością ładowania WSDL w 1C jest to, że nie można załadować prawidłowych schematów. Nie ma wbudowanego walidatora, dlatego trzeba szukać błędu za pomocą analizy niszczącej, sukcesywnie zmniejszając liczbę elementów w obwodzie. Możesz na przykład usunąć opis usługi internetowej.

Przetwarzanie w celu testowania działającej zewnętrznej usługi internetowej

Aby przetestować działającą zewnętrzną usługę internetową, użyj przetwarzania „Test ArbitraryWebService.epf” z pakietu tego artykułu.

Do testowania można posłużyć się przykładem usługi Morpher, która odrzuca nazwy (adres usługi http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

W ten sposób możesz przetestować dowolną usługę posiadającą proste punkty wejścia zawierające parametry prostych typów: liczba, data, string.

W trakcie przetwarzania możesz podać także login i hasło, które wymagane są do autoryzacji dostępu do serwisu.

Standardowe narzędzia do debugowania usług

Do debugowania możesz użyć programu SoapUI, który może wysłać dowolne żądanie do usługi internetowej i otrzymać od niej odpowiedź.

SOAP i HTTPS

Niestety SOAP w 1C zachowuje się dość kapryśnie podczas pracy poprzez protokół HTTPS, praktyka pokazuje, że nie da się osiągnąć połączenia HTTPS, choć na platformie zadeklarowano taką możliwość; Brak narzędzi diagnostycznych i debugujących pozwalających znaleźć przyczyny nienawiązania połączenia zbiera swoje żniwo. Dlatego wygodnie jest używać SOAP poprzez CURL.

Wbudowany mechanizm korzystania z protokołu HTTPS oznacza, że wszystkie certyfikaty muszą być opublikowane we wspólnym pliku pem w katalogu programu 1C.

Używanie 1C jako usługi

Zasady opracowywania usługi w oparciu o 1C

Operacja Witam

Dobrą praktyką jest utworzenie w serwisie operacji informującej o dostępności usługi. Ułatwia to życie integratorom, łatwiej będzie im sprawdzić, czy nawiązano komunikację z usługą.

Na przykład można użyć operacji Hello bez parametrów, która po prostu zwraca wartość logiczną True.

Publikowanie usługi internetowej

Procedura jest dobrze opisana w dokumentacji: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:

Zadanie publikowania serwisów WWW sprowadza się do umieszczenia plików konfiguracyjnych *.1cws usług WWW w odpowiednim katalogu serwera WWW z odpowiednimi ustawieniami dla serwera WWW. Aby opublikować serwisy WWW należy wykonać polecenie menu „Administracja | Publikowanie usług internetowych.”

Wykonanie tego polecenia spowoduje otwarcie okna publikowania usług sieciowych.

Okno publikowania usług WWW zawiera ścieżkę do serwera WWW oraz dwie listy:

„Usługi sieciowe” – lista konfiguracji usług sieciowych;
„Publikacja” – lista serwisów WWW opublikowana na wskazanym serwerze WWW.

Za pomocą przycisku „Połączenie…” należy określić serwer WWW, na którym chcesz publikować usługi WWW.

Okno wyboru ścieżki serwera WWW umożliwia określenie ścieżki na dwa sposoby:

w zakładce „Pliki” – tę metodę stosuje się w przypadku, gdy publikacja odbywa się na tym samym komputerze, na którym zainstalowany jest serwer WWW. Ścieżką jest katalog lokalny odpowiadający stronie internetowej, z której zostanie wywołany opublikowany serwer WWW;
na zakładce „Witryna FTP” - tę metodę stosuje się, gdy zachodzi potrzeba opublikowania usługi internetowej na komputerze zdalnym. Aby opublikować, należy określić parametry połączenia FTP z komputerem zdalnym oraz katalog, w którym zostanie opublikowany serwis WWW.

Wybrany serwis WWW zostanie opublikowany za pomocą przycisku „Publikuj”.

Aby anulować publikację serwisu internetowego, użyj przycisku „Usuń”.

Możesz publikować w katalogu lokalnym lub przez FTP. Można także publikować na serwerze zdalnym za pośrednictwem ścieżki UNC, jeśli serwer zdalny jest częścią sieci lokalnej.

Po publikacji usługa internetowa jest dostępna pod adresem „http://localhost/test.1cws” lub „http://xxx.ru/test.1cws”, gdzie xxx.ru to adres zdalnego serwera i localhost to typowy adres lokalnego serwera.

Autoryzacja do usługi internetowej 1C

Aby uzyskać dostęp do usługi, musisz przejść uwierzytelnienie.

Kwestie autoryzacji są dobrze rozwiązane tutaj: http://www.forum.mista.ru/topic.php?id=341168 oraz w pliku dokumentacji:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm

Zazwyczaj usługa internetowa działa w ramach jednego konkretnego użytkownika (zwykle specjalnie utworzonego). Możesz „dołączyć” użytkownika 1C za pomocą uwierzytelniania Windows do użytkownika Windows IUSR_ (wyłącz autoryzację 1C dla użytkownika). Alternatywnie możesz wyczyścić listę użytkowników 1C, wtedy autoryzacja nie jest wymagana.

Jeśli potrzebnych jest kilku użytkowników, możesz utworzyć kilka loginów do serwera WWW, przypisać użytkownika Windows do każdego z nich i odpowiednio zarejestrować dostęp do użytkowników Windows w 1C.

We właściwościach User i Password obiektu WSProxy nie jest używany login 1C, ale login użytkownika serwera WWW.

Testowanie usługi internetowej 1C

Aby przetestować 1C jako usługę internetową, użyj przetwarzania „Test ArbitraryWebService.epf”, jak opisano w sekcji „Testowanie działającej zewnętrznej usługi internetowej”.

Plik 1cws to opis WSDL usługi internetowej 1C.

Korzystanie z usług w Detalu

Zazwyczaj usługi detaliczne służą ludności do świadczenia różnych usług – przyjmowania płatności, spłacania pożyczek, przelewy pieniężne, zakup oprogramowanie itp.

W takim przypadku w 1C generowany jest paragon za świadczoną usługę, w którym zapisywane są parametry transakcji. Następnie ten czek jest drukowany klientowi szczegółowe informacje o świadczonej usłudze. Istnieje możliwość wydrukowania czeku wstępnego, tak aby Klient własnoręcznie potwierdził wprowadzone dane swoim podpisem.

Usługę można zintegrować na różne sposoby z programem detalicznym napisanym w języku 1C (UT, Retail i inne):

Przetwarzanie lub kod można zapisać w języku 1C, który wykonuje całą pracę z usługą.
Można użyć programu, który współpracuje z usługą, a w 1C przesyła tylko informacje dotyczące kontroli wykrawania.

Organizacja danych serwisowych w 1C

Aby zapisać informację o transakcji na paragonie należy utworzyć dodatkową część tabelaryczną „Sprzedaż kompleksowa” zawierającą szczegóły:

Nomenklatura - link do nomenklatury czeku.
Parametr - link do podręcznika „Sprzedaż kompleksowa: Parametry”.
Wartość - wartość parametru, typ złożony. Ciąg reprezentujący musi być dość długi (1024 znaki), aby pomieścić tekst kontrolny.

Katalog „Sprzedaż kompleksowa: Parametry” zawiera listę parametrów transakcji.

Bardziej opłaca się korzystać z części tabelarycznej niż zestawu szczegółów, ponieważ transakcja może mieć ich dużo, a przy innych kontrolach niezwiązanych z usługą dane te nie zostaną wykorzystane i zajmą dodatkowe miejsce. Dodatkowo takie rozwiązanie jest uniwersalne dla dowolnej usługi i nie wymaga restrukturyzacji danych po wdrożeniu nowej usługi.

Sprzedający otrzymuje osobną zakładkę (lub formularz drukowany, aby nie zmieniać konfiguracji), w której może przeglądać tabliczkę ze szczegółami transakcji do czeku.

Korzystanie z przetwarzania w języku 1C

Spójrzmy na przykład usługi warunkowej Paym dla konfiguracji „Retail”.

Stwórzmy predefiniowany element katalogu nomenklatury „Paym” w 1C. W trybie 1C:Enterprise po aktualizacji konfiguracji należy przypisać jej typ produktu „Usługa”.
W procedurze „Dodaj pozycję do tabeli. część” modułu formularza „Rejestracja sprzedaży”, nazywamy przetwarzaniem pracy z usługą napisaną w języku 1C. Jeżeli płatność przebiegła pomyślnie, rejestrujemy i wysyłamy czek:

Jeśli (Nomenklatura = Katalogi. Nomenklatura. Płatność) AND (Typ transakcji przelewu. Rodzaje operacji Sprawdź KKM. Zwrot) Następnie Przetwarzanie płatności = Funkcje Podaj przetwarzanie zewnętrzne („Paym”);

PaymentForm = PaymentProcessing.GetForm();
Wynik = PaymentForm.OpenModal();

W przeciwnym razieJeśli typ transakcji przelewu.Typy operacjiSprawdź KKM.Zwrot i wybór.NomenclatureLink = Katalogi.Nomenklatura.Zapłać następnie //Osipov PaymMaster ComplexSales Line = ComplexSales.Find(Directories.ComplexSalesParameters.PaymReceiptText, "Właściwości");

Jeśli złożona linia sprzedaży nie jest zdefiniowana, wówczas Product.Name = skrócony LP (złożona linia sprzedaży. Wartość);

koniecJeśli;

Osobną kwestią jest to, jak zapewnić sfinalizowanie transakcji. Te. jeśli transakcja miała miejsce w serwisie, jak upewnić się, że nie zostanie utracona w 1C. Najbardziej optymalnym sposobem jest uzgodnienie rejestrów. Ale to temat na osobne rozważania.

Korzystanie z programów integrujących się z 1C

XDTO

XDTO jest często używane w usługach internetowych. Oto najważniejsze wskazówki i przepisy dotyczące korzystania z XDTO w 1C.

XDTO na platformie 1C

Pakiety XDTO, opisane w gałęzi konfiguracji „Obiekty XDTO”, są dostępne do tworzenia typów i obiektów w globalnej fabryce XDTO Factory. Nie jest to od razu oczywiste.

Niektóre typy w schemacie nie mają nazwy; aby je uzyskać, należy przejść przez hierarchię typów.

W przykładzie opisano listę System zawierającą struktury XDTO. Aby stworzyć samą strukturę, trzeba było uzyskać jej typ w następujący sposób:

Typ = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;

Typowe problemy z plikiem XDTO Różne formaty schematów XSD W niektórych formatach tagi nazywane są xs:, w niektórych xsd:, ale 1C bezpiecznie rozumie oba formaty. Kiedyś doszło do sytuacji, w której XSD został zaimportowany do 1C normalnie bez błędów, ale nie utworzył ani jednego pakietu. Powodem był brak atrybutu

docelowa przestrzeń nazw

odpowiednio na tagu 1C nie wiedział, w którym pakiecie umieścić diagram, ale nie generował błędów.

Wsparcie serwisowe

Biorąc pod uwagę, że usługa jest połączeniem dwóch systemów - 1C i zewnętrznego, w obu systemach mogą wystąpić błędy, co zmniejsza ogólną niezawodność działania.

Aby ułatwić zrozumienie przyczyn awarii usług, zaleca się zastosowanie zestawu środków.

Rejestrowanie żądań
- Spinki do mankietów
XDTO
- Dobry opis XDTO http://pro1c.org.ua/index.php?showtopic=214
- Darmowe ciekawe usługi internetowe:
Aeroflot - informacje o rozkładach lotów
- Morpher - deklinacja nazw http://www.morpher.ru/WebServices/Morpher.aspx
  - Niezmontowany:
  - Instalowanie i korzystanie z usług internetowych
  - v8: jak zmienić plik konfiguracyjny Apache?
  - Księga wiedzy: v8: Korzystanie z zewnętrznych usług sieciowych w 1C:Enterprise 8;

W ostatnie lata Wzrosło wykorzystanie interfejsów API i zależność od usług sieciowych. Oto lista 12 narzędzi do testowania usług internetowych, które znacznie Ci pomogą.

W ciągu ostatnich kilku lat wzrosła popularność i wykorzystanie usług internetowych lub interfejsów API. Usługa sieciowa lub interfejs API to zestaw procedur lub składników oprogramowania, które pomagają aplikacji komunikować się lub przeprowadzać pewien proces/transakcję poprzez utworzenie połączenia między inną aplikacją lub serwerem. Istnieją głównie dwa rodzaje usług internetowych: REST i SOAP do przesyłania danych i informacji za pośrednictwem protokołu internetowego.

Ponieważ te usługi internetowe są dostępne w Internecie i rozproszone w różnych sieciach, są one podatne na wirusy i zagrożenia bezpieczeństwa, które wpływają na procesy, które się na nich opierają. Dlatego konieczne staje się testowanie usług sieciowych lub interfejsów API, aby upewnić się, że działają prawidłowo i prawidłowo reagują na żądania. Testowanie oprogramowania to obiecujący obszar w branży IT, w którym możesz zdobyć niezbędną wiedzę

Na rynku dostępnych jest kilka komercyjnych i bezpłatnych narzędzi testowych umożliwiających sprawdzenie ich łączności, reakcji i wydajności. Te narzędzia testowe automatyzują testowanie dla określonego scenariusza, takiego jak testy funkcjonalne, testy obciążeniowe, testy wydajnościowe itp.

Oto 12 świetnych narzędzi do testowania usług internetowych, które powinieneś wziąć pod uwagę w kontekście wymagań dotyczących testowania interfejsu API lub usług internetowych:

MydłoUI

SoapUI to wieloplatformowe narzędzie do testowania typu open source. Może automatyzować testy funkcjonalne, regresyjne, spójności i obciążenia zarówno usług SOAP, jak i REST. Jest łatwy w użyciu i obsługuje zaawansowane technologie i standardy modelowania i motywowania zachowań usług internetowych.

Kluczowe funkcje:

Zapewnia drukowanie, eksportowanie i raporty HTML na poziomie projektu, TestSuite, TestCase lub LoadTest.
Współpraca z Hudson, Bamboo, Maven, ANT i JUnit.
Umożliwia rozwijanie własnego zestawu funkcji w postaci wtyczek SoapUI.
Rejestruje, monitoruje i wyświetla wszystkie dane.
Obsługuje deszyfrowanie WS-Security i SSL.

TestowanieWhiza

TestingWhiz to „bezkodowe” narzędzie do automatyzacji testów, które jest kompatybilne z interfejsami API/usługami internetowymi. Umożliwia przeprowadzanie testów funkcjonalności, interoperacyjności i obciążenia oraz pracę z usługami internetowymi REST i SOAP poprzez interfejs WSDL poprzez HTTP i FTP.

Kluczowe funkcje:

Obsługuje porównywanie ciągów w celu sprawdzenia poprawności odpowiedzi API.
Pomaga w wyszukiwaniu defektów API za pomocą zintegrowanych narzędzi do śledzenia problemów, takich jak JIRA, Mantis i Fogbugz.
Generuje dzienniki wizualne i raporty z testów za pośrednictwem poczty elektronicznej.
Zapewnia ciągłą integrację z Jenkins, Bamboo & Hudson.
Obsługuje testowanie oparte na danych i słowach kluczowych.

SOAPSonar

SOAPSonar zapewnia kompleksowe testowanie usług internetowych dla HTML, XML, SOAP, REST i JSON. Zapewnia testy funkcjonalności, wydajności, kompatybilności i bezpieczeństwa przy użyciu standardów OASIS i W3C.

Kluczowe funkcje:

Obsługuje testowanie podatności na mutację XSD.
Zapewnia wszechstronną analizę WSDL i schematu.
Wykonuje testy obciążenia z symulacją behawioralną i wieloma jednoczesnymi procesami ładowania.
Dostarcza raporty w formatach XML, DOC, XLS, PDF, RTF i RPT.
Współpracuje z Centrum Jakości HP.

Test SOA

SOAtest to narzędzie do testowania i walidacji interfejsów API oraz aplikacji opartych na interfejsach API. Zapewnia solidną obsługę bloków funkcyjnych, integrację, bezpieczeństwo, symulację, testowanie obciążenia przy użyciu technologii takich jak REST, JSON, MQ, JMS, TIBCO, HTTP i XML.

Kluczowe funkcje:

Zapewnia kompleksowe testowanie
Obsługuje ponad 120 protokołów/typów wiadomości.
Wyposażony w łatwy w użyciu interfejs.
Pomaga tworzyć złożone, rozszerzalne i wielokrotnego użytku testy bez kodowania.
Obsługuje ciągłe testy integracyjne

Kreator testów

TestMaker to narzędzie typu open source do testowania i monitorowania wydajności usług internetowych i aplikacji SOA za pomocą PushtoTest. Działa na Jythonie (Python napisany w Javie). TestMaker może przekształcić testy Selenium, testy SoapUI, testy Sahi lub dowolne testy napisane w Groovy, Java, Python, PHP, Ruby i Perl w testy funkcjonalne i obciążeniowe.

Kluczowe funkcje:

Używa zapytań wiersza poleceń do testowania funkcjonalności, obciążenia i wydajności.
Intuicyjny wygląd ze standardowym wielookienkowym IDE.
Udostępnia panel kontrolny umożliwiający uruchamianie testów i wyświetlanie wyników w czasie rzeczywistym.
Umożliwia dostęp do wszystkich bibliotek Java i klas języka Jython.

Listonosz

Postman to kolejne narzędzie do testowania API/usług internetowych, które ma potężną obsługę klienta HTTP. Posiada łatwy w obsłudze kreator zapytań, który umożliwia pisanie przypadków testowych oraz zarządzanie danymi i czasami odpowiedzi w celu wydajnego testowania i zarządzania przypadkami testowymi API.

Kluczowe funkcje:

Umożliwia organizowanie interfejsów API w funkcje zwane zespołami Postmana.
Ułatwia współpracę i udostępnianie danych API oraz elementów sterujących.
Umożliwia pisanie testów logicznych w interfejsie Postmana.

vRest

VRest to narzędzie przeznaczone do testowania, benchmarkingu REST APIS i usług internetowych. Obsługuje także testowanie aplikacji internetowych, mobilnych i stacjonarnych, które współdziałają z interfejsami API innych firm lub usługami HTTP.

Kluczowe funkcje:

Posiada funkcję próbnego serwera do tworzenia fałszywych interfejsów API w ciągu kilku minut.
Istnieje rozszerzenie do przeglądarki Chrome umożliwiające nagrywanie i odtwarzanie przypadków testowych.
Obsługuje integrację z Jenkinsem w celu ciągłego działania serwera i Jira w celu śledzenia problemów.
Ułatwia zarządzanie uprawnieniami.
Umożliwia eksport i import przypadków testowych oraz raportów z narzędzi zewnętrznych takich jak Postman Collections, Swagger 2.

HttpMaster

HttpMaster to kolejne ekskluzywne narzędzie do testowania usług internetowych REST. Pomaga testerom testować zachowanie interfejsów API REST i weryfikować dane wyjściowe w formatach takich jak XML, JSON i HTML. Dzięki uniwersalnemu narzędziu HTTP HttpMaster pomaga także programistom modelować aktywność klienta i zachowanie odpowiedzi aplikacji API.

Kluczowe funkcje:

Posiada łatwy w użyciu i elegancki interfejs użytkownika, który nie wymaga zaawansowanych umiejętności technicznych.
Używa metod HTTP, takich jak GET, POST, DELETE itp.
Zapewnia różne typy i wyrażenia testowe, aby ułatwić testowanie.
Używa interfejsu wiersza poleceń do tworzenia i uruchamiania testu.
Umożliwia przechowywanie wszystkich informacji – wywołań API i danych projektu w jednym miejscu.

Zakres działania

Runscope to proste narzędzie do testowania i monitorowania wydajności API. Runscope wspiera także testowanie API i backendu aplikacji mobilnych.

Kluczowe funkcje:

Umożliwia tworzenie testów z danymi dynamicznymi nawet dla skomplikowanych przypadków.
Wyświetla metryki i analizy w celu zidentyfikowania problemów.
Współpracuje z narzędziami takimi jak HipChat, Webhooks, Slack i PagerDuty w celu powiadamiania o awariach API.
Umożliwia ponowne wykorzystanie i uruchamianie testów w wielu miejscach.
Ułatwia scentralizowane zarządzanie testami w celu poprawy współpracy.

Gwałcić

Rapise to solidne narzędzie do automatyzacji z potężnymi i rozszerzalnymi funkcjami. Opiera się na otwartej i elastycznej architekturze umożliwiającej szybkie testowanie funkcjonalności usług sieciowych REST/SOAP. Rapise zapewnia także wsparcie dla testowania aplikacji internetowych osadzonych w Java, .NET, Ajax, Silverlight i Flash.

Kluczowe funkcje:

Używa standardowych metod HTTP, takich jak POST, GET, PUT i DELETE.
Umożliwia przechowywanie żądań prototypowych w odniesieniu do określonej usługi internetowej.
Zawiera wbudowany konstruktor definicji REST i bibliotekę obiektów.
Posiada zaawansowane możliwości raportowania.
Obsługuje testowanie w różnych przeglądarkach i wykonywanie równoległe.

WebInject

WebInject to bezpłatne narzędzie do automatycznych testów funkcjonalnych, akceptacyjnych i regresyjnych usług internetowych. Jest to narzędzie wiersza poleceń oparte na języku Perl, co ułatwia uruchamianie testów, ponieważ nie ma potrzeby spędzania czasu w wierszu poleceń. Nie ma także interfejsu IDE, co oznacza, że testy są pisane zewnętrznie interfejs użytkownika WebInject. Może działać na platformach z interpreterem Perla.

Kluczowe funkcje:

Zapewnia wyświetlanie wyników w czasie rzeczywistym.
Monitoruje czas reakcji systemu.
Obsługuje różne zastosowania - zarówno pełnoprawną platformę testową, jak i samodzielny tester.
Tworzy raporty w formatach HTML i XML.
Umożliwia integrację z innym systemem jako wtyczka do zewnętrznego monitoringu.

Burza

Wreszcie Storm to kolejne narzędzie typu open source firmy CodePlex do testowania usług internetowych napisanych w języku Java lub .NET. Obecnie obsługuje tylko usługę sieciową SOAP.

Kluczowe funkcje:

Umożliwia testowanie wielu usług internetowych z jednego interfejsu użytkownika.
Pomaga edytować surowe żądania SOAP.
Umożliwia odwoływanie się do metod usług internetowych, które zawierają złożone typy danych.
Obsługuje testowanie aplikacji WCF.

Oczywiście lista na tym się nie kończy, ponieważ istnieje ogromna różnorodność narzędzi do testowania usług internetowych.

Zarejestruj się już teraz lub poproś o bezpłatną konsultację telefoniczną!

Obecnie rzadko zdarza się, aby nowoczesna aplikacja działała bez API. Dotyczy to zarówno prostej witryny internetowej, jak i mocno obciążonych systemów rozproszonych. Testowanie API jest jednym z głównych zadań w procesie zapewnienia jakości. Nic dziwnego, że zapotrzebowanie na testerów, którzy wiedzą, jak testować API, rośnie z dnia na dzień. Na tym kursie zdobędziesz wiedzę na temat metod, narzędzi i podejść w testowaniu API, zdobędziesz niezbędną wiedzę, która niewątpliwie wpłynie pozytywnie na Twoją wartość jako specjalisty ds. testów.

Ten kurs będzie przydatny dla studentów zaznajomionych z podstawami testowania oprogramowania, którzy chcą się dalej rozwijać i doskonalić swoje umiejętności.

Program kursu:

Lekcja 1. Wprowadzający. Protokół SOAP

Krótko o wykładowcy;
Cele kursu;
Co to jest API, WS i dlaczego są potrzebne;
Rola testów API w procesie zapewnienia jakości;
Przegląd narzędzi testowych WS;
Metody stosowane w testowaniu WS;
Historia SOAP-u;
Terminologia i główne pojęcia (XML, XSD, Endpoint, WSDL).

Lekcja 2: Protokół SOAP. Architektura REST

Terminologia i główne pojęcia (UDDI, XSLT, XPath, XQuery, metody HTTP, statusy HTTP);
Struktura i główne elementy SOAP;
Zakres zastosowania;
Cechy pracy;
Zalety i wady;
Cechy architektury REST;
Terminologia i główne koncepcje (WADL, RESTful, JSON, JSONPath);
zasady REST;
Kod statusu i główne statusy;
Czasowniki CRUD;
Zalety i wady.

Lekcja 3. Przedstawiamy SoapUI. Praca z projektem REST