Simptomi

29.11.2021 Testiranje web servisa.

Korištenje eksternih SOAP usluga Operacije
SOAP (Simple Object Access Protocol) je standardizirani protokol za prijenos poruka između klijenta i servera. Obično se koristi u kombinaciji sa HTTP(S), ali može raditi i sa drugim protokolima sloja aplikacije (kao što su SMTP i FTP). SOAP testiranje sa stanovišta tehnika testiranja ne razlikuje se suštinski od rada sa drugim API-jima, ali zahteva

preliminarne pripreme

(u smislu teorije protokola) i specijalni alati za testiranje. U ovom članku želio bih formulirati malu kontrolnu listu potrebnih znanja i vještina, koja će biti podjednako korisna i SOAP testeru (koji često nema pojma za šta da se uhvati nakon postavljanja zadatka) i menadžeru koji je prinuđeni da evaluiraju znanje testera i razviju planove za obuku.

Teorijska osnova
Činjenica da je SOAP protokol ima mnogo implikacija za testiranje: potrebno je proučiti sam protokol, "primarne" standarde i protokole na kojima se zasniva, i (po potrebi) postojeće ekstenzije.

XML
XML je jezik za označavanje sličan HTML-u. Svaka poruka poslana/primljena putem SOAP-a je XML dokument u kojem su podaci prikladno strukturirani i laki za čitanje, na primjer:
Julia
Natasha

Podsjetnik

Ne zaboravite napisati članak!
Više o XML-u možete saznati na w3schools ili kodnetu (na ruskom). Obavezno obratite pažnju na opis imenskih prostora (metod za rješavanje sukoba pri opisivanju elemenata u XML-u) - njihova upotreba je potrebna u SOAP-u.

...

...

XSD
U svom radu možete naići i na razne “proširenja” SOAP-a - standarde poput WS-*. Jedan od najčešćih je WS-Security, koji vam omogućava rad sa enkripcijom i elektronskim potpisima. Često se uz njega koristi i WS-Policy, pomoću koje možete upravljati pravima za korištenje vaše usluge.

Primjer korištenja WS-Security-a:

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

Sva ova proširenja su prilično složene strukture koje se ne koriste u svakoj SOAP usluzi; njihova detaljna studija u početnoj fazi savladavanja SOAP testiranja vjerovatno neće biti relevantna.

Alati

Kao što već razumete, SOAP je ozbiljna stvar da biste radili sa njim, morate poznavati teoriju i brojne standarde. U praksi, takva složenost bi dovela do veoma značajnih troškova rada (na primjer, svaki put biste morali pogledati dijagram u bilježnici i slati zahtjeve sa curl-om). Stoga su stvoreni alati koji olakšavaju rad sa SOAP-om.

XML/XSD uređivači
Dobar tester počinje testiranje u fazi pisanja dokumentacije, pa je zgodno koristiti posebne uređivače za testiranje kola. Dva najpoznatija su Oxygen (cross-platform) i Altova (samo za Windows); oboje su plaćeni. Ovo su vrlo moćni programi koje analitičari aktivno koriste kada opisuju usluge.

U mojoj praksi, tri funkcije uređivača su se pokazale korisnima: XSD vizualizacija, XML generisanje zasnovano na XSD-u i XML validacija zasnovana na XSD-u.

1. XSD vizualizacija potrebno za vizuelni prikaz dijagrama, omogućavajući vam da brzo identifikujete potrebne elemente i atribute, kao i postojeća ograničenja. Na primjer, za CheckTextRequest, element teksta je obavezan, a sva tri atributa su opciona (sa atributom options koji ima zadanu vrijednost nula).

Vizualizacija je neophodna kada postoji mnogo tipova i ograničenja u dijagramu. Ako vam treba samo ovo i ne želite da plaćate posebne uređivače, onda možete razmotriti besplatne alternative (na primjer, JDeveloper).

2. XML generisanje bazirano na XSD-u korisno kada želite vidjeti valjan primjer poruke. Koristim ga da brzo eksperimentišem s mogućim dovršenjima poruka i testiram nijanse kako ograničenja funkcioniraju.

3. Nakon korištenja funkcije iz tačke 2, korisno je izvršiti XML validacija u odnosu na XSD– odnosno provjerite ispravnost poruke. Zajedno, funkcije 2 i 3 vam omogućavaju da uhvatite nezgodne nedostatke u XSD-u čak i kada je sama usluga u razvoju.

Alat za testiranje – SoapUI

SOAP testiranje gotovo uvijek uključuje korištenje SoapUI. O korištenju ovog alata možete pročitati u raznim izvorima (,), ali će biti najefikasnije pročitati zvaničnu dokumentaciju. Identifikujem 8 uslovnih nivoa znanja o SoapUI:

Nivo 1 – Mogu slati zahtjeve
Naučite da kreirate projekat zasnovan na WSDL-u. SoapUI može generirati sve potrebne upite za vas; Sve što trebate učiniti je provjeriti da li su ispravno popunjeni i kliknuti na dugme “Pošalji”. Nakon što ste razvili vještine za kreiranje valjanih upita, morate savladati umjetnost kreiranja pogrešnih upita koji uzrokuju greške.

Nivo 2 – Mogu raditi Test Suites i Test Cases
Počnite raditi mini-autotestove. Kompleti za testiranje i testni slučajevi vam omogućavaju da kreirate skripte za testiranje API-ja, pripremite podatke za zahtjeve i automatski provjerite primljeni odgovor kako biste bili sigurni da odgovara onome što se očekuje. U početku se mogu koristiti jednostavno kao kolekcije upita. Na primjer, ako ste kreirali kvar i želite ga brzo provjeriti nakon što ga popravite, možete dodijeliti poseban komplet za testiranje posebno za zahtjeve za kvar.

Nivo 3 – Mogu pisati tvrdnje
Nakon savladavanja test slučajeva, bit će vam korisno naučiti kako ih učiniti automatski provjerljivim. Nakon toga više nećete morati očima tražiti informacije o odgovoru: ako postoji automatska provjera, slučajevi će biti označeni zelenom (ako je provjera prošla) ili crvenom (ako nije prošla). SoapUI pruža veliki skup mogućih tvrdnji, ali najprikladnije i najjednostavnije su Contains i Not Contains. Uz njihovu pomoć možete provjeriti dostupnost konkretan tekst u primljenom odgovoru. Ove provjere također podržavaju pretraživanja regularnih izraza.

Nivo 4 – koristite XPath i/ili XQuery u tvrdnjama
Za one koji su malo upoznati sa korisničkim sučeljem koji koristi Selenium, XPath jezik je poznata stvar. Grubo govoreći, XPath vam omogućava da tražite elemente u XML dokumentu. XQuery je slična tehnologija koja interno može koristiti XPath; ovaj jezik je mnogo moćniji, podsjeća na SQL. Oba ova jezika mogu se koristiti u tvrdnjama. Provjere uz njihovu pomoć su ciljanije i stabilnije, tako da će vaši predmeti uživati veće povjerenje.

Nivo 5 – Mogu pisati složene testove koristeći posebne korake

Testni slučajevi mogu sadržavati ne samo jedan zahtjev, već i nekoliko (na primjer, kada želite emulirati standardni korisnički scenario “kreiraj entitet” → “izvoz entitet”). Između zahtjeva mogu postojati i drugi posebni koraci, na primjer:

Properties and Property Transfer (pomozite ponovnom korištenju podataka i prijenosu između zahtjeva);
JDBC zahtjev (koristi se za dohvaćanje podataka iz baze podataka);
Uslovni Goto (omogućava vam da napravite grane ili petlje u testnom slučaju);
Pokreni TestCase (pomaže da se neki tipični upiti stave u odvojene test slučajeve i da se pozovu gdje je potrebno).

Nivo 6 – korištenje Groovy skripti

SoapUI vam omogućava da pišete Groovy skripte na raznim mjestima. Najjednostavniji slučaj je generiranje podataka u samom upitu pomoću umetanja $(=). Stalno koristim ove umetke:

$(=novi datum().format(“gggg-MM-dd’T’HH:mm:ss”))– da unesete trenutni datum i vrijeme u traženom formatu;
$(=java.util.UUID.randomUUID())– da biste umetnuli ispravno formiran nasumični GUID.

Pune skripte se mogu koristiti kao koraci u slučajevima i provjerama. U nekom trenutku ćete otkriti da se nekoliko posebnih koraka sa petog nivoa može zamijeniti jednom skriptom.

Nivo 7 – korištenje MockServices
SoapUI baziran na WSDL-u može generirati lažne objekte. Lažni objekat je najjednostavnija simulacija usluge. Uz pomoć “mocks” možete započeti pisanje i otklanjanje grešaka test slučajeva čak i prije nego što je usluga stvarno dostupna za testiranje. Mogu se koristiti i kao „stubovi“ za privremeno nedostupne usluge.

Nivo 8 – SoapUI Bog
Znate li razliku između plaćenog i besplatne verzije SoapUI i koristite SoapUI API u kodu. Koristite dodatke i pokrećete slučajeve kroz komandnu liniju i/ili CI. Vaši testni slučajevi su jednostavni i laki za održavanje. Generalno, na ovom instrumentu ste "pojeli psa". Voleo bih da razgovaram sa nekim ko je savladao SoapUI na ovom nivou. Ako ste jedan, prijavite se u komentarima!

Testiranje programskim jezicima

Evo primjera kako izgleda zahtjev za YandexSpeller API, napravljen pomoću groovy-wslite:

import wslite.soap.*
def client = novi SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
tijelo (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
tekst ("greška")
}
}
}
assert "error" == response.CheckTextResponse.SpellResult.error.s.text()
potvrditi "1" == [email protected]()

Koliko ja znam, još ne postoje okviri visokog nivoa (poput Rest-assured) za SOAP testiranje, ali se nedavno pojavio zanimljiv alat - karate. Uz njegovu pomoć, možete opisati slučajeve za testiranje SOAP-a i REST-a u obliku skripti kao što je Cucumber / Gherkin. Za mnoge testere okretanje karateu će biti idealno rješenje, jer će takvi scenariji, u smislu složenosti pisanja i pratećih slučajeva, ležati negdje na sredini između korištenja SoapUI-ja i pisanja vlastitog okvira za testiranje SOAP-a.

Zaključak

Malo je vjerovatno da ćete ikada poželjeti testirati SOAP samo za sebe (kao što biste mogli s REST-om). Ovo je težak protokol koji se koristi u ozbiljnim poslovnim rješenjima. Ali njegova težina je ujedno i dar testeru: sve tehnologije koje se koriste su standardizirane, a postoje i visokokvalitetni alati za rad. Sve što se traži od testera je želja da ih nauči i koristi.

Hajde da sastavimo istu kontrolnu listu potrebnih vještina za testera. Dakle, ako tek počinjete da testirate SOAP usluge, morate znati i moći koristiti:

WSDL.
SOAP.
XML/XSD uređivači (na nivou XSD vizualizacije).
SoapUI na nivou 1.

Kao što vidite, glavni naglasak je na učenju standarda u SoapUI-u, dovoljno je samo biti u mogućnosti da izvršite upite. Dok uronite u SOAP testiranje, naići ćete na zadatke koji će zahtijevati ozbiljnije vještine i znanja, ali ne biste trebali pokušavati naučiti sve odjednom. Mnogo je važnija doslednost u povećanju stepena složenosti zadataka koji se obavljaju. Prateći ovu preporuku, jednog dana ćete shvatiti da ste postali dobar specijalista u ovoj oblasti!

Web usluge u 1C

Ovaj članak će raspravljati o integraciji 1C s postojećim web servisima i korištenju samog 1C kao web usluge.

U ovom slučaju, web servisi će se shvatiti kao sistemi koji rade na Internetu i pružaju interakciju s njima ne samo putem SOAP-a (koji je upravo web servis), već i na druge načine, uključujući redovne HTTP(S) zahtjeve.

Rizici korištenja 1C web usluga

Platforma 1C81 uvela je implementaciju web servisa.

Ali njihova upotreba je puna rizika:

1C8 ne radi dobro preko HTTPS-a, nema dijagnostičkih alata, pa je ponekad nemoguće razumjeti zašto, čak i ako postoji certifikat, servis ne želi raditi preko HTTPS-a. Rješenje je implementacija web servisa putem CURL-a ili podizanje HTTPS tunela.
1C8 se pridržava svojih pravila za validaciju WSDL shema. Ponekad, iz neobjašnjivih razloga, WSDL šema ne želi da se učita u WS vezu. Razlog možete saznati samo na forumu partnera od jednog stručnjaka. Ne postoje alati za dijagnostiku WSDL sheme, čak ni razlog ili linija na kojoj je učitavanje sheme prekinuto.

Pravila za usluge prodaje zgrada

Kupcu se izdaje prodajni dokument (priznanica) samo ako je transakcija usluge uspješna. Inače je moguća situacija da klijent dobije ček i uvjeren je da je dobio uslugu, a zapravo nije.

Korištenje eksternih SOAP usluga

SOAP web servisi koriste WSDL šeme i XDTO objekte za predstavljanje podataka.

Učitavanje WSDL

Da biste koristili eksterni servis, morate preuzeti njegovu WSDL shemu.

Provjera valjanosti WSDL sheme

Ponekad se WSDL šema ne učitava u 1C. Možete provjeriti valjanost (ispravnost) sheme koristeći bilo koji validator WSDL sheme, na primjer http://www.validwsdl.com/.

Morate prenijeti shemu na neku http stranicu (možete koristiti ftp) i naznačiti adresu datoteke u koju je shema učitana:

Značajke učitavanja WSDL-a u 1C

Posebnost učitavanja WSDL-a u 1C je da se važeće šeme možda neće učitati. Nema ugrađenog validatora, tako da morate tražiti grešku koristeći destruktivnu analizu, sukcesivno smanjujući broj elemenata u kolu. Možete, na primjer, izbrisati opis web usluge.

Obrada za testiranje pokrenute eksterne web usluge

Da biste testirali radnu eksternu web uslugu, koristite obradu "Test ArbitraryWebService.epf" iz paketa za ovaj članak.

Testiranje se može koristiti na primjeru usluge Morpher, koja odbija imena (adresa usluge http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

Na ovaj način možete testirati bilo koji servis koji ima jednostavne ulazne tačke koje sadrže parametre jednostavnih tipova: broj, datum, string.

Tokom obrade možete odrediti i login i lozinku koji su potrebni za autorizaciju pristupa web servisu.

Standardni alati za servise za otklanjanje grešaka

Za otklanjanje grešaka možete koristiti program SoapUI, koji može poslati proizvoljan zahtjev web servisu i od njega dobiti odgovor.

SOAP i HTTPS

Nažalost, SOAP se u 1C ponaša prilično hirovito kada radi preko HTTPS protokola, praksa pokazuje da je nemoguće ostvariti HTTPS vezu, iako je ta mogućnost deklarirana u platformi. Nedostatak dijagnostičkih alata i alata za otklanjanje grešaka za otkrivanje razloga zašto veza nije uspostavljena uzima svoj danak. Stoga je zgodno koristiti SOAP preko CURL-a.

Ugrađeni mehanizam za korištenje HTTPS-a podrazumijeva da svi certifikati moraju biti objavljeni u zajedničkoj pem datoteci u direktoriju programa 1C.

Korištenje 1C kao usluge

Pravila za razvoj usluge zasnovane na 1C

Operacija Zdravo

Pravilo dobre forme je kreiranje operacije u servisu koja obavještava da je usluga dostupna. To olakšava život integratorima, lakše će provjeriti da li je komunikacija sa servisom uspostavljena.

Na primjer, možete koristiti operaciju Hello bez parametara, koja jednostavno vraća Booleovu vrijednost True.

Objavljivanje web servisa

Postupak je dobro opisan u dokumentaciji: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:

Zadatak objavljivanja Web servisa svodi se na postavljanje *.1cws konfiguracijskih datoteka Web servisa u odgovarajući direktorij web servera sa odgovarajućim postavkama za web server. Da biste objavili Web servise, potrebno je izvršiti naredbu menija „Administracija | Objavljivanje web usluga."

Kao rezultat izvršavanja ove naredbe, otvorit će se prozor za objavljivanje Web usluga.

Prozor za objavljivanje Web usluga sadrži putanju do web servera i dvije liste:

“Web usluge” - lista konfiguracijskih web servisa;
“Publikacija” - lista web servisa objavljenih na navedenom web serveru.

Pomoću dugmeta "Veza..." treba da navedete web server na kojem želite da objavite Web servise.

Prozor za odabir putanje web servera vam omogućava da odredite putanju na dva načina:

na kartici "Datoteke" - ova metoda se koristi kada se objavljivanje vrši na istom računaru na kojem je instaliran web server. Putanja je lokalni direktorij koji odgovara Internet stranici sa koje će biti pozvan objavljen Web server;
na kartici "FTP lokacija" - ovaj metod se koristi kada trebate objaviti web uslugu na udaljenom računaru. Da biste objavili, morate navesti parametre FTP veze sa udaljenim računarom i direktorijum u kojem će web usluga biti objavljena.

Odabrani web servis se objavljuje pomoću dugmeta “Objavi”.

Da biste otkazali objavljivanje web usluge, koristite dugme „Izbriši“.

Možete objaviti u lokalnom direktoriju ili putem FTP-a. Također možete objaviti na udaljenom poslužitelju putem UNC putanje ako je udaljeni poslužitelj dio lokalne mreže.

Nakon objavljivanja, web usluga je dostupna na adresi “http://localhost/test.1cws” ili “http://xxx.ru/test.1cws”, gdje je xxx.ru adresa udaljenog servera i lokalnog hosta je tipična adresa lokalnog servera.

Autorizacija za 1C web servis

Za pristup servisu potrebno je proći autentifikaciju.

Pitanja autorizacije su dobro obrađena ovde: http://www.forum.mista.ru/topic.php?id=341168 iu dokumentacionom fajlu:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm

Tipično, web usluga radi pod jednim određenim korisnikom (obično posebno kreiranim). Možete "prikačiti" 1C korisnika koristeći Windows autentifikaciju za Windows korisnika IUSR_ (onemogućite 1C autorizaciju za korisnika). Alternativno, možete obrisati listu korisnika 1C, tada autorizacija nije potrebna.

Ako je potrebno nekoliko korisnika, tada možete kreirati nekoliko prijava za web server, svakom od njih dodijeliti Windows korisnika i, u skladu s tim, registrirati pristup korisnicima Windowsa u 1C.

U svojstvima korisnika i lozinke WSProxy objekta, ne koristi se 1C prijava, već prijava korisnika web servera.

Testiranje 1C web servisa

Da biste testirali 1C kao web uslugu, koristite obradu "Test ArbitraryWebService.epf", kao što je opisano u odjeljku "Testiranje pokrenute eksterne web usluge".

Datoteka 1cws je WSDL opis 1C web usluge.

Korištenje usluga u maloprodaji

Obično se maloprodajne usluge koriste za pružanje raznih usluga stanovništvu - primanje plaćanja, vraćanje kredita, Transferi novca, kupovina softver i tako dalje.

U ovom slučaju, u 1C se generira račun za pruženu uslugu, u kojem se pohranjuju parametri transakcije. Nakon čega se ovaj ček ispisuje klijentu sa detaljne informacije o pruženoj usluzi. Moguće je ispisati preliminarni ček kako bi klijent svojim potpisom potvrdio unesene podatke iz njegovih riječi.

Usluga se može integrirati na različite načine u maloprodajni program napisan na 1C jeziku (UT, Retail i drugi):

Obrada ili kod se mogu napisati na 1C jeziku, koji obavlja sav posao sa uslugom.
Može se koristiti program koji radi s uslugom, a u 1C prenosi samo informacije za probijanje provjere.

Organizacija servisnih podataka u 1C

Da biste pohranili informacije o transakciji u priznanicu, potrebno je kreirati dodatni tabelarni dio „Složena prodaja“ sa detaljima:

Nomenklatura - veza do nomenklature čeka.
Parametar - link na referentnu knjigu “Složena prodaja: parametri”.
Vrijednost - vrijednost parametra, složenog tipa. Reprezentacija stringa mora biti prilično duga (1024 karaktera) da bi se prilagodio tekstu provjere.

Direktorij “Složena prodaja: parametri” sadrži listu parametara transakcije.

Isplativije je koristiti tabelarni dio nego skup detalja, jer transakcija ih može imati puno, a u drugim provjerama koje nisu povezane s uslugom, ovi detalji se neće koristiti i zauzimat će dodatni prostor. Osim toga, ovakvo rješenje je univerzalno za bilo koju uslugu i ne zahtijeva restrukturiranje podataka nakon implementacije nove usluge.

Prodavcu se daje poseban bookmark (ili odštampani obrazac, kako se ne bi mijenjala konfiguracija), u kojem može vidjeti pločicu sa detaljima transakcije za ček.

Korištenje obrade u 1C jeziku

Pogledajmo primjer uvjetne usluge Paym za konfiguraciju “Retail”.

Kreirajmo unaprijed definirani element imenika nomenklature "Paym" u 1C. U načinu rada 1C:Enterprise, nakon ažuriranja konfiguracije, potrebno mu je dodijeliti tip proizvoda „Usluga“.
U proceduri „Dodaj stavku u tabelu. dio" modula obrasca "Registracija prodaje", nazivamo obradu rada sa uslugom, napisanu na 1C jeziku. Ako je uplata uspješna, evidentiramo i knjižimo ček:

Ako (Nomenklatura = Imenici.Nomenklatura.Paym) AND (Vrsta transakcije prijenosa. Vrste operacija Provjera KKM. Povratak) Tada Obrada plaćanja = Funkcije Dajte eksternu obradu ("Plaćanje");

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

U suprotnomAko Tip transakcije prijenosa.Vrste operacijaProvjerite KKM.Povrat i odabir.NomenclatureLink = Directories.Nomenclature.Paym Onda //Osipov PaymMaster ComplexSales Line = ComplexSales.Find(Directories.ComplexSalesParameters.PaymReceties"); "Pro

Ako je složena prodajna linija nedefinirana, onda je naziv proizvoda = skraćeno LP (složena prodajna linija. vrijednost);

endIf;

Posebno pitanje je kako osigurati završetak transakcije. One. ako se transakcija dogodila u servisu, kako osigurati da nije izgubljena u 1C. Najoptimalniji način je usaglašavanje registara. Ali ovo je tema za posebno razmatranje.

Korištenje programa koji se integriraju sa 1C

XDTO

XDTO se često koristi u web servisima. Evo najvažnijih savjeta i recepata za korištenje XDTO u 1C.

XDTO u 1C platformi

XDTO paketi, opisani u grani “XDTO objekti” konfiguracije, dostupni su za kreiranje tipova i objekata u globalnoj tvornici XDTO Factory. Ovo nije odmah očigledno.

Neki tipovi u šemi nemaju ime da biste ih dobili, morate proći kroz hijerarhiju tipova.

Primjer opisuje sistemsku listu koja sadrži XDTO strukture. Da biste kreirali samu strukturu, morali ste dobiti njen tip ovako:

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

Uobičajeni problemi sa XDTO Različiti formati XSD shema U nekim formatima oznake se zovu xs:, u nekim xsd:, ali 1C sigurno razumije oba formata. Jednom je došlo do situacije da je XSD uvezen u 1C normalno bez grešaka, ali nije kreirao niti jedan paket. Razlog je bio nedostatak atributa

targetNamespace

na oznaci, shodno tome, 1C nije znao u koji paket da postavi dijagram, ali nije generisao greške.

Servisna podrška

S obzirom da je servis kombinacija dva sistema - 1C i eksternog, može doći do grešaka u oba sistema, što umanjuje ukupnu pouzdanost rada.

Da bi se lakše razumjeli razlozi kvarova u servisu, preporučuje se korištenje niza mjera.

Zahtjevi za evidentiranje
- Linkovi
XDTO
- Dobar opis XDTO-a http://pro1c.org.ua/index.php?showtopic=214
- Besplatne zanimljive web usluge:
Aeroflot - informacije o rasporedu aviona
- Morpher - deklinacija imena http://www.morpher.ru/WebServices/Morpher.aspx
  - Nesastavljeno:
  - Instaliranje i korištenje Web usluga
  - v8: kako promijeniti apache konfiguracijski fajl?
  - Knjiga znanja: v8: Korišćenje eksternih web servisa u 1C:Enterprise 8;

IN poslednjih godina Povećano je korištenje API-ja i oslanjanje na web usluge. Evo liste od 12 alata za testiranje web servisa koji će vam značajno pomoći.

U posljednjih nekoliko godina porasla je popularnost i korištenje web servisa ili API-ja. Web usluga ili API je skup procedura ili softverskih komponenti koje pomažu aplikaciji da komunicira ili izvrši neki proces/transakciju formiranjem veze između druge aplikacije ili servera. Postoje uglavnom dvije vrste web servisa: REST i SOAP za prijenos podataka i informacija putem Internet protokola.

Budući da su ovi web servisi dostupni na Internetu i distribuirani u različitim mrežama, ranjivi su na viruse i sigurnosne prijetnje koje utiču na procese koji se na njih oslanjaju. Stoga, testiranje web servisa ili API-ja postaje neophodno kako bi se osiguralo da ispravno funkcioniraju i da ispravno odgovaraju na zahtjeve. Testiranje softvera je obećavajuća oblast u oblasti informacionih tehnologija na kojoj možete dobiti potrebna znanja

Na tržištu postoji nekoliko komercijalnih i besplatnih alata za testiranje za testiranje njihove povezanosti, odziva i performansi. Ovi alati za testiranje automatiziraju testiranje za određeni scenarij kao što je funkcionalno testiranje, testiranje opterećenja, testiranje performansi itd.

Evo 12 sjajnih alata za testiranje web usluga koje biste trebali uzeti u obzir za svoje zahtjeve za testiranje API-ja ili web servisa:

SoapUI

SoapUI je alat za testiranje na više platformi otvorenog koda. Može automatizirati funkcionalne, regresijske, konzistentne i testove opterećenja i SOAP i REST usluga. Jednostavan je za korištenje i podržava napredne tehnologije i standarde za modeliranje i podsticanje ponašanja web servisa.

Ključne karakteristike:

Pruža ispis, izvoz i HTML izvještaje na nivou Project, TestSuite, TestCase ili LoadTest.
Interoperabilnost sa Hudson, Bamboo, Maven, ANT i JUnit.
Omogućava vam da razvijete vlastiti skup funkcija u obliku SoapUI dodataka.
Snima, prati i prikazuje sve podatke.
Podržava WS-Security i SSL dešifriranje.

TestingWhiz

TestingWhiz je alat za automatizaciju testiranja bez koda koji je kompatibilan sa API-jima/web uslugama. Omogućava vam da izvršite testiranje funkcionalnosti, interoperabilnosti i opterećenja i rad sa REST i SOAP web servisima preko WSDL interfejsa preko HTTP-a i FTP-a.

Ključne karakteristike:

Podržava poređenje nizova za validaciju API odgovora.
Pomaže u pronalaženju defekata API-ja pomoću integriranih alata za praćenje problema kao što su JIRA, Mantis i Fogbugz.
Generiše vizualne zapise i izvještaje o testiranju putem e-pošte.
Pruža kontinuiranu integraciju sa Jenkins, Bamboo & Hudson.
Podržava testiranje na osnovu podataka i ključnih riječi.

SOAPSonar

SOAPSonar pruža end-to-end testiranje web servisa za HTML, XML, SOAP, REST i JSON. Pruža testiranje funkcionalnosti, performansi, kompatibilnosti i sigurnosti korištenjem standarda OASIS i W3C.

Ključne karakteristike:

Podržava testiranje ranjivosti XSD mutacija.
Pruža sveobuhvatnu analizu WSDL-a i šeme.
Obavlja testiranje opterećenja sa simulacijom ponašanja i višestrukim istovremenim procesima opterećenja.
Pruža izvještaje u XML, DOC, XLS, PDF, RTF i RPT formatima.
Interagira sa HP centrom za kvalitetu.

SOAtest

SOAtest je alat za testiranje i validaciju API-ja i aplikacija vođenih API-jem. Pruža robusnu podršku funkcionalnih blokova, integraciju, sigurnost, simulaciju, testiranje opterećenja koristeći tehnologije kao što su REST, JSON, MQ, JMS, TIBCO, HTTP i XML.

Ključne karakteristike:

Pruža end-to-end testiranje
Podržava 120+ protokola/tipova poruka.
Dolazi sa sučeljem lakim za korištenje.
Pomaže vam da kreirate složene, proširive i višekratne testove bez kodiranja.
Podržava kontinuirano testiranje integracije

TestMaker

TestMaker je alat otvorenog koda za testiranje i praćenje performansi web servisa i SOA aplikacija koristeći PushtoTest. Radi na Jythonu (Python napisan u Javi). TestMaker može prenamijeniti Selenium testove, SoapUI testove, Sahi testove ili bilo koje testove napisane u Groovy, Java, Python, PHP, Ruby i Perl u funkcionalne testove opterećenja.

Ključne karakteristike:

Koristi upit komandne linije za testiranje funkcionalnosti, opterećenja i performansi.
Intuitivno izgled sa standardnim multi-window IDE.
Pruža kontrolnu tablu za pokretanje testova i prikaz rezultata u realnom vremenu.
Omogućava pristup svim Java bibliotekama i klasama jezika Jython.

Poštar

Postman je još jedan alat za testiranje API/web servisa koji ima moćnu podršku za HTTP klijente. Ima alat za pravljenje upita jednostavan za upotrebu koji vam omogućava da pišete test slučajeve i upravljate podacima odgovora i vremenima odgovora za efikasno testiranje i upravljanje API test slučajevima.

Ključne karakteristike:

Omogućava da se API-ji organiziraju u funkcije koje se zovu Postman sklopovi.
Olakšava saradnju i dijeljenje API podataka i kontrola.
Omogućava vam pisanje logičkih testova u Postman Interface.

vRest

VRest je alat dizajniran za testiranje, benchmarking REST APIS-a i web servisa. Takođe podržava testiranje web, mobilnih i desktop aplikacija koje su u interakciji sa API-jima ili HTTP uslugama trećih strana.

Ključne karakteristike:

Ima funkciju lažnog servera za kreiranje lažnih API-ja za nekoliko minuta.
Postoji proširenje za Chrome za snimanje i reprodukciju test slučajeva.
Podržava integraciju sa Jenkinsom za kontinuirani rad servera i Jira za praćenje problema.
Olakšava upravljanje dozvolama.
Omogućava vam izvoz i uvoz test slučajeva i izvještaja iz vanjskih alata kao što su Postman Collections, Swagger 2.

HttpMaster

HttpMaster je još jedan ekskluzivni alat za testiranje REST web servisa. Pomaže testerima da testiraju ponašanje REST API-ja i validiraju izlaz u formatima kao što su XML, JSON i HTML. Sa svojim univerzalnim HTTP alatom, HttpMaster također pomaže programeru da modelira aktivnost klijenta i ponašanje odgovora API aplikacije.

Ključne karakteristike:

Ima jednostavan za korištenje i elegantan korisnički interfejs koji ne zahtijeva napredne tehničke vještine.
Koristi HTTP metode kao što su GET, POST, DELETE, itd.
Obezbeđuje Razne vrste i test izraze da olakšaju testiranje.
Koristi interfejs komandne linije za kreiranje i pokretanje testa.
Omogućava vam da pohranite sve informacije - API pozive i podatke o projektu na jednom mjestu.

Runscope

Runscope je jednostavan alat za testiranje i praćenje performansi API-ja. Runscope takođe podržava testiranje API-ja i pozadine mobilnih aplikacija.

Ključne karakteristike:

Omogućava vam da kreirate testove sa dinamičkim podacima čak i za složene slučajeve.
Prikazuje metriku i analitiku za prepoznavanje problema.
Radi s alatima kao što su HipChat, Webhooks, Slack i PagerDuty za obavještenje o neuspjehu API-ja.
Omogućava vam ponovno korištenje i pokretanje testova na više mjesta.
Olakšava centralizovano upravljanje testiranjem za poboljšanu saradnju.

Silovanje

Rapise je robustan alat za automatizaciju sa moćnim i proširivim karakteristikama. Zasnovan je na otvorenoj i fleksibilnoj arhitekturi za brzo funkcionalno testiranje REST/SOAP web servisa. Rapise takođe pruža podršku za testiranje web aplikacija ugrađenih u Javu, .NET, Ajax, Silverlight i Flash.

Ključne karakteristike:

Koristi standardne HTTP metode kao što su POST, GET, PUT i DELETE.
Omogućava vam pohranjivanje zahtjeva za prototipove na određenoj web usluzi.
Sadrži ugrađeni alat za izgradnju REST definicija i biblioteku objekata.
Ima moćne mogućnosti izvještavanja.
Podržava testiranje između pretraživača i paralelno izvršavanje.

WebInject

WebInject je besplatni alat za automatizirano funkcionalno, prihvatljivo i regresijsko testiranje web servisa. To je alat za komandnu liniju i baziran je na Perlu, što olakšava pokretanje testova jer nema potrebe da trošite vreme na komandnu liniju. Takođe, nema IDE interfejs, što znači da se testovi pišu eksterno korisnički interfejs WebInject. Može raditi na platformama sa Perl interpretatorom.

Ključne karakteristike:

Omogućava prikaz rezultata u realnom vremenu.
Prati vrijeme odziva sistema.
Podržava različite namjene - i punu platformu za testiranje i samostalni tester.
Kreira izvještaje u HTML i XML formatima.
Omogućava integraciju sa drugim sistemom kao dodatak za eksterno praćenje.

Oluja

Konačno, Storm je još jedan alat otvorenog koda iz CodePlex-a za testiranje web servisa napisanih u Javi ili .NET-u. Trenutno podržava samo SOAP web servis.

Ključne karakteristike:

Omogućava vam testiranje više web usluga iz jednog korisničkog interfejsa.
Pomaže u uređivanju sirovih SOAP zahtjeva.
Omogućava vam referenciranje metoda web usluga koje sadrže složene tipove podataka.
Podržava testiranje WCF aplikacija.

Naravno, lista se ovdje ne završava, jer postoji veliki izbor alata za testiranje web servisa.

Prijavite se sada ili zatražite poziv uz besplatne konsultacije!

Danas je rijetkost da moderna aplikacija funkcionira bez API-ja. Ovo vrijedi i za jednostavnu web stranicu i za visoko opterećene distribuirane sisteme. API testiranje je jedan od glavnih zadataka u procesu osiguranja kvaliteta. Nije iznenađujuće da potražnja za testerima koji znaju kako testirati API-je raste iz dana u dan. Na ovom kursu ćete steći razumijevanje o metodama, alatima i pristupima u API testiranju, steći potrebna znanja koja će nesumnjivo pozitivno utjecati na vašu vrijednost kao stručnjaka za testiranje.

Ovaj kurs će biti koristan studentima koji su upoznati sa osnovama testiranja softvera koji žele da napreduju i unaprede svoje veštine.

Program kursa:

Lekcija 1. Uvodno. SOAP protokol

Ukratko o predavaču;
Ciljevi kursa;
Šta je API, WS i zašto su potrebni;
Uloga API testiranja u procesu osiguranja kvaliteta;
Pregled alata za testiranje WS-a;
Metode korištene u WS testiranju;
Istorija SOAP-a;
Terminologija i glavni koncepti (XML, XSD, Endpoint, WSDL).

Lekcija 2: SOAP protokol. REST arhitektura

Terminologija i glavni koncepti (UDDI, XSLT, XPath, XQuery, HTTP metode, HTTP statusi);
Struktura i glavne komponente SOAP-a;
Obim primjene;
Karakteristike rada;
Prednosti i nedostaci;
Karakteristike REST arhitekture;
Terminologija i glavni koncepti (WADL, RESTful, JSON, JSONPath);
REST principi;
Statusni kod i glavni statusi;
CRUD glagoli;
Prednosti i nedostaci.

Lekcija 3. Predstavljamo SoapUI. Rad sa REST projektom