Pozitivno i negativno testiranje. Pozitivno razmišljanje u svijetu negativnog testiranja Koji od ovih testova je negativan

Besplatan prijevod članka "Top 10 negativnih test slučajeva" Stevea Millera.

Negativni test slučajevi se koriste za testiranje performansi aplikacije, pod uslovom da se na njen ulaz primaju „netačni“ podaci. Takvi testni slučajevi se moraju koristiti tokom testiranja. Ispod je deset najpopularnijih negativnih scenarija testa:

Ugrađeni pojedinačni citat - Većina SQL baza podataka ima problema sa jednostrukim navodnicima u upitu (na primjer, Jonesov auto).
Koristite jednostruke navodnike prilikom provjere valjanosti svakog polja za unos baze podataka.

Potreban unos podataka - U specifikaciji vaše aplikacije, polja koja zahtijevaju obavezan unos podataka trebaju biti jasno definirana.
Provjerite da se obrasci koji imaju polja definirana kao obavezna ne mogu sačuvati ako u njima nema podataka.

Tipovi podataka polja (test tipa polja) - Specifikacija vaše aplikacije treba jasno definirati tipove podataka za svako od polja (polja datuma/vremena, numerička polja, polja za unos telefonskog ili poštanskog broja, itd.)
Uvjerite se da vam svako polje dozvoljava samo unos ili pohranjivanje podataka navedenog tipa (na primjer, vaša aplikacija ne bi trebala dozvoliti unos ili pohranjivanje slova ili posebnih znakova u numerička polja).

Test veličine polja - Specifikacija vaše aplikacije treba jasno definirati maksimalan broj znakova dozvoljen u svakom od polja (na primjer, broj znakova u polju korisničkog imena ne smije biti veći od 50).
Provjerite da li vam aplikacija ne dozvoljava da unesete ili pohranite više znakova nego što je navedeno u specifikaciji. Ne zaboravite da ova polja ne samo da moraju ispravno funkcionirati, već i upozoravaju korisnika na ograničenja, na primjer, s objašnjenjima ili porukama o grešci.

Test numeričkih granica - Numerička polja u vašoj aplikaciji mogu imati ograničenja u pogledu broja dozvoljenih vrijednosti. Ova ograničenja mogu biti navedena u specifikaciji vaše aplikacije ili proizilaze iz logike programa (na primjer, ako testirate funkcionalnost vezanu za obračun kamate na računu, onda bi bilo sasvim logično pretpostaviti da je obračunata kamata ne može imati negativnu vrijednost).
Provjerite da li aplikacija šalje poruku o grešci ako su vrijednosti izvan dozvoljenog raspona (na primjer, poruka o grešci bi se trebala pojaviti kada unesete vrijednosti 9 ili 51 u polje s važećim rasponom vrijednosti od 10 do 50, odnosno prilikom unosa negativne vrijednosti u polje , koja mora biti pozitivna).

Test numeričkih granica - Većina baza podataka i programskih jezika definiraju numeričke vrijednosti kao varijable nekog tipa (na primjer, cijeli ili dugi cijeli broj), koje zauzvrat imaju ograničenja na dozvoljene numeričke vrijednosti (na primjer, cjelobrojne vrijednosti mora biti u rasponu od -32768 do 32767, i dug cijeli broj od -2147483648 do 2147483647).
Provjerite granične vrijednosti korištenih varijabli za numerička polja čije granične vrijednosti nisu jasno definirane specifikacijom.

Test granica datuma - Vrlo često u aplikacijama postoje logična ograničenja za polja koja sadrže datum i vrijeme. Na primjer, ako provjeravate polje koje sadrži datum rođenja korisnika, onda bi bilo sasvim logično zabraniti unos datuma koji još nije stigao (tj. datuma u budućnosti) ili ograničiti unos datuma koji se od današnjeg razlikuje za više od 150 godina.

Datum valjanosti - Polja datuma uvijek trebaju imati validaciju unesenih vrijednosti (na primjer, 31-11-2009 nije ispravan datum). Takođe, ne zaboravite na provjeru datuma u prijestupnoj godini (godine koje su djeljive sa 4 m i djeljive sa 100 i 400 u isto vrijeme su prijestupne godine).

Web sesije (testiranje web sesije) - Mnoge web aplikacije koriste sesije pretraživača za praćenje prijavljenih korisnika, primjenu postavki specifičnih za aplikaciju za određenog korisnika itd. Istovremeno, mnogi funkcionalni dijelovi sistema ne mogu ili ne bi trebali raditi bez prethodnog prijavljivanja na sistem. Provjerite da funkcionalnost ili stranice koje se nalaze iza lozinke nisu dostupne neautoriziranom korisniku.

Veoma zabrinut za kvalitet proizvoda. Ovo objašnjava dostupnost softverskih testera širom svijeta. Pružanjem, ovi ljudi osiguravaju njen kvalitet.

Mnogi testeri nikada neće zaboraviti negativno testiranje, iako nisu svi programeri zadovoljni ovim. Takva kontrola je potrebna za zaštitu od hakera, botova, Dos/DDos napada.

Koji je poziv testera? Moraju pronaći probleme koji drugima nisu vidljivi. Nemojte odugovlačiti sa negativnim testiranjem ili time dovodite sistem u opasnost.

Pozitivno i negativno testiranje

Počnimo od samog početka. Postoje 2 vrste kontrole kada su test slučajevi uključeni u testiranje: pozitivna i negativna. Ovo drugo ima prednost.

pozitivno testiranje je proces provjere ispravnog ponašanja prema specifikacijama i dokumentaciji. Pozitivno testiranje se vrši kako bi se osiguralo da sistem radi upravo ono što se očekuje.

Negativno testiranje je proces provjere nepravilnog ponašanja. Kroz takvo testiranje možemo saznati da će se sistem nositi sa nepredviđenim situacijama.

pozitivno-negativno testiranje

Da biste izvršili testiranje softvera, morate imati intuiciju ili lovački instinkt. Tester je svestrana osoba koja može obavljati i poslovnu analizu i testiranje.

Testeri provjeravaju da li proces radi ispravno: da li postoji usklađenost sa tehničkim zahtjevima i scenarijima testiranja. Razdvojeno pokretanje pozitivnog i negativnog testiranja trajat će duže nego da se svi rade u isto vrijeme. To je zato što postoje dvije iteracije testa.

Na kraju krajeva, što je bliže satu X, to brže vrijeme prolazi i prije morate završiti zadatke, popraviti nedostatke, primijeniti poslovne zahtjeve (koji se mogu razlikovati) i učiniti više. Rok je najtoplije vrijeme!

Razdvajanje negativnog i pozitivnog testiranja jednostavno je protiv prirode testera! Njegov zadatak je da provjeri sistem za sve moguće radnje krajnjeg korisnika.

Ljudi su u osnovi nelogični i mogu uzrokovati probleme u softveru. Negativno testiranje će pomoći u izbjegavanju problema.

Eiiiiii... Ovo je zadnji unos u ciklusu! Najkraći je, najjednostavniji i gotovo se u potpunosti sastoji od stvarnih priča. Koliko je to moguće - glupo smešno. Postoji čak i video snimljen specijalno za snimanje upravo u vrijeme pisanja. Sveže gospodine. Nažalost, nisam pomislio da napravim screenshot sa porukom o padu Youtube klijenta, odgovaralo bi. Pao u pravu prilikom postavljanja videa koji je umetnut u članak. Ok, dajmo moj zaključani ekran.

Na početku testiranja, bez obzira da li se radi o novom projektu ili o onom koji je već trebao biti zakopan, općenito je uvijek jasno odakle početi. Osim, naravno, do trenutka kada je testiranje počelo, nijedna karika u lancu nije radila zajedno. Obično, testeri lektorišu zahteve i druge dokumente sa neruskim nazivima, kao što su "BRC", "EsArky" i "User Story" i shvate kako da napišu test slučaj kako bi on proverio implementaciju svih ovih dokumenata. Ovo je sve jasno, na površini i nema smisla zadržavati se na tome. Ali tu je i ponašanje samog Androida, koje ponekad ne znaju ne samo analitičari, već čak ni arhitekte i neki programeri. I ako se prisjetimo da se, samo uz custom, pojavljuje dosta takvih funkcija. I ne govorim o stresnim scenarijima kada nema memorije ili se baterija naglo izvadi (nekako sam na GNU/Linux terminalu sreo ogorčenje osobe da ne pokazuje lozinku pri ulasku, ali ima pokvarenu tastaturu i ne razumije da li unosi lozinku ili tastatura opet ne radi), već o redovnom ponašanju prilagođavanja Androida, pa čak i ponašanju ugrađenom u AOSP. Odnosno, redovno ponašanje sistema koje može negativno uticati na testirani proizvod. Takozvani negativni scenariji.

Ukratko ću opisati neke negativne scenarije i pokušati dati konkretne primjere.

• Problemi u komunikaciji. Najjednostavniji primjer je Fly Mode. Na primjer, aplikacija za bilježenje Google Keep ili nije testirana u načinu rada u avionu ili pronađene greške nisu utjecale na izdanje. Reproduciranje problema je vrlo jednostavno:
• Uključite način rada u avionu
• Dodirnite liniju Zabilježite ...
• Na ekranu koji se pojavi izvršite akciju Delete
• Uživajte u animaciji pomicanja prethodno sačuvanih bilješki

Pored Fly Mode, postoji i nestabilna veza sa gubitkom paketa, i veoma spora konekcija, i zatvoreni portovi preko kojih radi vaša aplikacija, te prisustvo Wi-Fi veze, ali bez pristupa internetu.

• Nema pristupa trgovini aplikacijama. Na primjer, da biste testirali kupovinu unutar aplikacije, build se mora učitati u trgovinu u posebnom odjeljku. Ako ga nema, ili iste verzije nema (govorimo o kodu verzije - internoj verziji), tada nećete testirati kupovinu. Ako je korisnik odletio na odmor u Kinu, gdje je sve jako tužno sa povezivanjem na Google Play, ne bi trebao izgubiti licencu za koju je platio novac.
• Rad aplikacije s ograničenim dozvolama, ako je ciljni API nivo ispod 23, tj. manji od Androida 6, i kada je verzija API-ja 23 i više. U prvom slučaju, aplikacija je naslijeđena, ali dozvole se i dalje mogu oduzeti. U drugom slučaju, i dalje će početi primati nove izuzetke koje ranije nije poznavao.
• Režim uštede baterije. Implementacija i Doze i App Standby, kao i alternativne implementacije alternativno nadarenih proizvođača poput Samsunga (i Sony STAMINA u prvoj verziji), kada je sve implementirano užasno pogrešno, ali morate živjeti s tim. Prihvatljivo je da aplikacija ne vrši provjere na vrijeme, ne šalje statistiku, ne ažurira podatke. Ali nije dozvoljeno pasti, smrzavati se, nikada ne obavljati zakazane zadatke.
• Promijenite datum, vrijeme, vremensku zonu. Ljudi mogu letjeti na praznike i poslovna putovanja u druge zemlje gdje je vremenska zona drugačija. Ako avion pređe 180. meridijan, onda bi korisnik mogao ući u jučerašnji dan sa stanovišta aplikacije.

  Prava priča o neuspjehu. Roditeljska kontrola u KIS-u za Windows pojavila se u verziji 7.0 2006. godine. Istovremeno, proizvod je imao ugrađenog novinskog agenta, nimalo isti kao što je sada. Pretpostavljalo se da će se preko njega slati razne vijesti o prijetnjama, svakojakim "šta ima novo" i slično. Postojala je greška u verziji izdanja, koju su korisnici već instalirali. Ako u Windowsu vratite vrijeme prije početka licence, zaštita je onemogućena. Strogo govoreći, neadministratori ne mogu mijenjati vrijeme, ali prije 10 godina kompanije nisu posebno pratile prava korisnika i tamo je svaki računovođa bio lokalni administrator. Jedan od naših klijenata u svojoj maloj kancelariji postavio je roditeljski nadzor tako da korisnici ne mogu surfati internetom osim na dozvoljenim stranicama. Draconian setup i lozinkom su zaštitili postavke. Sve je funkcionisalo dobro dok nije poslata vijest ugrađenom agentu za vijesti da je vrijeme za nadogradnju na novu verziju 7.0.1, koja je, između ostalog, ispravila grešku zbog koje je zaštita bila isključena kada se vrijeme vratilo prije početka licence. Korisnik je pročitao vijest, oduševio se i smanjio zaštitu predloženom metodom. Nekoliko dana kasnije ova njegova priča dospela je na tada popularni bash.org.ru. Od tada ovakva vijest više nije dolazila do korisnika.

  I nemojte misliti da takve greške nisu dozvoljene. Sjetite se priče sa iOS-om koja se desila ove godine, iako je od početka godine prošlo samo 3 mjeseca ( Napomena: da, ovo je prilično staro predavanje, dugo sam ga htio objaviti). Telefoni su se smanjivali ako vrijeme pomjerite bliže početku računanja vremena unix-a. I kako je Apple popravio ovu grešku? Zabranili su pomjeranje vremena dalje od kritičnog datuma, što NIJE rješenje za problem. Napadači su počeli podizati svoje Wi-Fi tačke s imenima koja se obično nalaze u bilo kojem McDonald'su i kroz njih prenose lažno vrijeme. Uređaji su se automatski povezivali na takve tačke i otkrivali NTP servere od kojih je traženo vrijeme. Apple se jednostavno nije pobrinuo da iOS ne koristi lažne NTP servere. Tako je iOS ponovo nažvrljan.

• Promjena lokalizacije sistema, jezika interfejsa. Korisnik ima pravo da promijeni jezik sistema sto puta dnevno i to mu niko ne može zabraniti. Zadatak testera je osigurati da proizvod, prvo, ispravno reagira na ovo (automatski mijenja jezik u željeni), a drugo, da se uopće ne ruši. Osim lokalizacije, korisnik ima pravo mijenjati fontove i veličine, birajući one koje su mu ugodne za čitanje. Aplikacija ne bi trebala indeksirati ako korisnik napravi razumne promjene.
• tapjaking. Spomenuo sam ovu stvar na prvom predavanju. Da vas podsjetim da se radi o presretanju tapova koje prima aktivnost aplikacije A, dok je korisnik pokušao doći do aplikacije B. Samo aktivacija aplikacije A je transparentna. Ne izgleda kao sigurno rješenje od Googlea, ali tako rade aplikacije za kontrolu svjetline i temperature boje na uređajima. Korisnici su zadovoljni takvim aplikacijama, a budući da im Android omogućava rad bez root-a, to se mora uzeti u obzir. Na primjer, ako imate aplikaciju koja koristi kod ili, recimo, sliku za autorizaciju, morate koristiti zaštitu od tapjackinga, na primjer, postavite filterTouchesWhenObscured na true.
• Direktan poziv na aktivnost. To sam već rekao, ali hajde da ponovimo. Aktivnosti su jedna od ulaznih tačaka u aplikaciju. Savršeno je prihvatljivo imati nekoliko različitih aktivnosti koje mogu pozvati vanjske aplikacije, nikad ne znate zašto. To će biti aktivnosti koje se izvoze. Ali može se desiti da da biste pozvali neku aktivnost, morate joj proslediti parametre. Aplikacija treće strane ih neće prenijeti. U najboljem slučaju, korisnik će vidjeti neku vrstu krivog ekrana, u najgorem slučaju, vaša aplikacija će se srušiti. Dakle, ne isplati se, da tako kažem, bespotrebno sijati svoje golo dupe. Po defaultu, izvezena zastavica je postavljena na true, a ako ste sigurni da ih vanjske aplikacije ne bi trebale pozvati, trebali biste je postaviti na false. Pa, tester mora provjeriti kako će se aplikacija ponašati ako je pozovete da se aktivira iz drugih aplikacija.
• Ubica sistema. Općenito se zove OOM Killer - Out Of Memory Killer. Sistem počinje da UBIJA ako aplikacija s kojom korisnik komunicira u tom trenutku nema dovoljno memorije za rad. Naravno, ubica nije glup, povinuje se određenim algoritmima, birajući mete (npr. sistem će lako ubiti pozadinski servis, ali će servis u prednjem planu sačuvati do poslednjeg; servis prednjeg plana je obično onaj koji uvlači svoju ikonu oblast za obaveštavanje, na primer, plejer), ali to je suština toga. U pravilu, na modernim uređajima, OOM Killer ne bjesni mnogo. Sada je memorija postavljena od jednog gigabajta i više. Ali to se ne odnosi na igre. Igre su toliko teške, toliko jedu memoriju da koliko god je prosipate, ona ipak neće biti dovoljna. I općenito, što više RAM-a stave u uređaje, to će aplikacije biti deblje, a igre najdeblje. Međutim, oni će ostati jednako dosadni i nepotrebni.

  Rezultat je da će vaš proizvod zajamčeno potpasti pod OOM Killer. Vaš zadatak je da se uvjerite da to ne dovede do ničega lošeg i da će proizvod porasti čim ssbbw aplikaciju sruši sistem (ako proizvod to zahtijeva, naravno). I sistem će to učiniti prvom prilikom, neće vam dozvoliti da živite u pozadini takvog ssbbw-a.
  Još jedan zaključak je da ni vaša aplikacija ne bi trebala biti ssbbw. Programer bi trebao otkriti svako curenje čak i prije nego što napiše stvarni kod. Vaši testovi performansi bi svakako trebali imati skripte za testiranje kada majmun pokrene gomilu događaja. Ako je kod dobro napisan, sakupljač smeća će osloboditi memoriju i sistem neće ubiti proces aplikacije. Ako je sve loše i aplikacija teče iz svih pukotina, sistem će je pucati. Naravno, nakon toga će se ponovo pokrenuti i memorije više neće biti, jer nakon ubijanja procesa sakupljač smeća sve čisti, ali ako je mamac pokazala da aplikacija curi u testu za 15 minuta, onda korisnik je imao ova curenja, doduše kasnije, ali to je to. će se pojaviti podjednako.

• veliki podaci. Ako vaša aplikacija radi s korisničkim podacima, budite spremni na to da korisnik može hraniti nešto vrlo veliko bez ikakvih skrivenih motiva. Na primjer, ja, kao korisnik, sasvim očekujem da će Youtube klijent preuzeti moj video, ma koliko ovaj video bio težak. Očekujem da će arhiver stati na bilo koju dubinu arhive, koja teži 5 puta više od sve raspoložive RAM memorije uređaja. Ovo je u redu. Ako vam neko kaže da „niko nikada neće hraniti tako velike fajlove“, onda najverovatnije govornik jednostavno nije baš dobar programer.
• Najgluplja, a samim tim i najsmješnija situacija koja uzrokuje neispravan rad aplikacije, sve do pada, je jednostavna rotacija ekrana. Koliko je takvih padova otkriveno u fazi testiranja! Pogotovo ako se pojavi neki popup. Na iskačućim prozorima, iskusni tester odmah počinje da okreće telefon! Dešavalo se i da je ceo tim testirao proizvod samo na telefonima, gde je rotacija ekrana za aplikaciju bila blokirana. A onda, kada su tableti doneti, ispostavilo se da na tabletima aplikacija pada skoro na svakom ekranu. Jer fragmenti. Bilo je različitih interfejsa na ekranu i na telefonu, a nepravilna upotreba fragmenata je dovela do tužnog rezultata.
• Dvostruki, trostruki tapas. Iz nekog razloga, neki ljudi misle da niko više ne dodiruje elemente interfejsa. Ali ne! Da! I to ne zato što testiram, već zato što možda u rukama imam stari Android 4.0 telefon koji se već jedva vrti, a ekran mu slabo reaguje. Možda nije jasno da li je bilo pritiska ili ne i dobijaju se dupli dodiri. Ne zato što su “dvostruki” (u smislu ne oni koji se rade u intervalu manjim od sekunde), već zato što ih je bilo dva ili više dok je aplikacija “razmišljala”. Na primjer, prilikom formiranja liste mnogih elemenata.
• Jedna od praktičnih karakteristika Androida 6, kada nije dovoljno testirana, dovodi do užasnih rezultata. Sve do toga da je njegovo korištenje izričito zabranjeno u aplikaciji, što za sada dozvoljava Google. Ova karakteristika je backup i vraćanje iz sigurnosne kopije. Inače, nije novo, backup se pojavio još u Androidu 2.2, ali ne znam za nijednu aplikaciju koja bi koristila ovu dobrotu.
  Samo po sebi, stvaranje sigurnosne kopije i njeno vraćanje nije strašno. Problemi počinju ako proizvod koristi vezivanje za ID uređaja i ID instalacije. Čak i unutar istog uređaja, to može dovesti do problema, a na kraju krajeva, Android sam dozvoljava vraćanje iz sigurnosne kopije na bilo koji uređaj sa Android 6: sistem pravi sigurnosnu kopiju aplikacija sa uređaja A, a korisnik kupuje uređaj B i vraća ih sve na to. I ove aplikacije rade istovremeno na dva uređaja, iako imaju različite identifikatore. Ako se radi o klijent-server aplikaciji u kojoj se sva komunikacija odvija na tokenima, ovdje ima puno problema.

  Borbeni primjer je kul aplikacija Talon za Twitter. Nisam resetovao svoj uređaj jako dugo, tako da ne znam da li je autor ispravio ovu grešku. Kada sam mu rekao za to, rekao mi je zašto je došlo do greške (iako već znam zašto!), ali nije rekao da li će ispraviti ponašanje. Generalno, ova aplikacija ima neku vrstu čarobnjaka za instalaciju koji govori o mogućnostima ovog Twitter klijenta, tražeći usput potrebne dozvole. Sve je jasno prema Google smjernicama, odmah na bilješkama. Kada je čarobnjak za konfiguraciju završen i dobijene potrebne dozvole, podignuta je zastavica o tome kako se ne bi svaki put ponovo prolazilo kroz konfiguraciju. A aplikacija je napravljena sigurnosna kopija zajedno sa ovom zastavicom. Zajedno s njim je restauriran. Iako prema zadanim postavkama sve aplikacije novog tipa (tj. targetApi nivo >= 23) imaju onemogućene dozvole. Pokrenuli ste aplikaciju, ali ona ne može normalno raditi. Budući da nema provjere dostupnosti dozvola, sve provjere su ostale u čarobnjaku za početno podešavanje, koji se nije pokrenuo jer je zastavica postavljena na "master already passed". Osim toga, nakon pokretanja, klijent nije preuzimao tweetove, što je davalo mlatenje sa samog Twittera. Zato što zakopani token nije bio važeći na novoj instalaciji i bilo je potrebno zatražiti novu, a ovaj zahtjev je također napravljen u čarobnjaku za instalaciju na samom prvom koraku!

• U Androidu, počevši od verzije (ako me sjećanje ne vara) 2.2.1, postalo je moguće redovno premjestite dio podataka aplikacije na memorijsku karticu. Polako je ova prilika počela da se gubi, sve dok joj u Androidu 6 Google nije dao drugi život, značajno je poboljšavši. Ako proizvođač uređaja u svom običaju nije prekršio ponašanje AOSP-a u ovoj situaciji, onda čim Android otkrije memorijsku karticu, nudi izbor hoće li je korisnik ponekad izvući ili ne. Ako korisnik kaže da ne planira da je onemogući, Android formatira karticu u svoj sistem datoteka i montira je kao dio glavne memorije, dozvoljavajući aplikacijama da se tamo instaliraju. I evo nekoliko zamki:
• Ako aplikacija koristi tvrdo kodirane staze, onda je sve izgubljeno. Ali to je tako loš ton da se nadam da to niko neće uraditi.
• Ako je aplikacija zatražila od sistema putanje prilikom prvog pokretanja i zauvek ih zakopala, onda će to biti potpuno isto kao i sa tvrdo kodiranim

• Kako se aplikacije ažuriraju, korisnici će dobijati nove verzije iz prodavnice aplikacija i instalirati ih na postojeću. Zbog toga provjerite ažuriranje aplikacije na novu verziju je obavezan scenario. U normalnoj situaciji, sve bi trebalo biti u redu, ali kada morate podržati mnoge specifične uređaje sa svojim specifičnim ponašanjem, format postavki se može promijeniti. Ovo gotovo nikada ne dovodi do pada ako je kod napisan manje ili više dobro, obrađuje razne izuzetke. Ali gubitak nekih postavki je već loš. Na primjer, imali smo situaciju da su korisnici mjesecima formirali anti-spam listu, blokirali brojeve taksija, banaka, naplatnih službi, a onda su, nakon ažuriranja na novu verziju, sve liste bile izgubljene. Upravo zato što je promijenjen format postavki i upravo ovdje, na ovom mjestu, postavke nisu pročitane od strane nove verzije proizvoda.
• Osim ažuriranja proizvoda na novu verziju, postoji rjeđa, ali mnogo tvrda opcija - ažuriranje firmvera na novu verziju, da sa ispravnim proizvodom. Navest ću dva primjera, od kojih sam jedan već spomenuo.
• Uobičajeno sigurnosno ažuriranje za Android 5.1, koje je uzelo i onemogućilo doživotne OS čipove koje je aplikacija koristila
• Nakon ažuriranja sa Androida 4.4 na Android 5.0, promijenili su se putevi instaliranih aplikacija. Ranije su instalirane aplikacije bile pohranjene na jednoj poznatoj putanji (/data/app/com.package.name.apk). U jednom od naših proizvoda za potrebe interne sigurnosti postoji provjera na kojoj je putanji zaštićena aplikacija dostupna i da li se promijenila. Stiglo je ažuriranje na 5.0 i apsolutne putanje su promijenjene za već instalirane aplikacije (data/app/com.package.name/base.apk). Proizvod je oglasio alarm da je aplikacija ugrožena. Ispravljeno, naravno.

Pa, to je sve za sada. Sada pišem izvještaj o problemima koji su specifični samo za određene verzije Androida, samo za određeni firmver, samo za određene uređaje. Zato ne isključujte! Međutim, jedan dio već znate - oni su opisani upravo u ovoj seriji unosa.
Ćao ćao!

Zašto ljudi rade psihološke testove? Naravno, svako ima svoje motive. Neko želi da razume sebe i „shvati šta sam ja“. Neko želi da potvrdi preovlađujuće mišljenje o svom karakteru. Neko samo ubija slobodno vrijeme i zabavlja se. Ali svi, iako često ne svjesni, odnosno čisto, žele čuti nešto dobro o sebi. Zašto? Da, i to podiže raspoloženje. Test koji vam nudimo da položite ima jedinu svrhu - da unesete kap pozitivnog u vaše trenutno stanje. Zapravo, ovo uopće nije test, već nešto poput pozitivnog predviđanja. A oni se, kao što znate, vrlo često ostvaruju!

06.10.2018 16947 +67

Želite znati kako drugi ljudi doživljavaju vaše ime? Besplatna online usluga fonozemantske analize omogućava vam da saznate kako se određena riječ percipira na podsvjesnom nivou. Pomoću njega možete, na primjer, odabrati ime za dijete ili ime za kompaniju.
Saznajte kako ćete se osjećati za mjesec dana! Upravo sada na našoj stranici možete potpuno besplatno izračunati svoje bioritme. Na osnovu rezultata proračuna dobićete lične preporuke i raspored za promjenu bioritma za sljedeći mjesec.
Popularni psihološki testovi Ogroman broj popularnih psiholoških testova za svačiji ukus. Za muškarce, za žene, ezoterično, profesionalno... I sve to online, besplatno i bez registracije!

· Ispitivanje dima. U ovoj fazi potrebno je provjeriti da li sistem uopće radi (da li radi ispravno, da li ispravno rješava greške itd.). Ovo se radi kako bi se razumjelo da li je aplikacija prikladna za dalje testiranje ili u početku ne radi ispravno.

"Pozitivno" testiranje. U ovoj fazi morate provjeriti rezultat aplikacije kada primi "ispravne" ulazne podatke.

"Negativno" testiranje. Ovo je završna faza početnog testiranja. Potrebno je pogledati kako se aplikacija ponaša, dajući "netačne" podatke na ulaz. Ako je takva varijanta opisana u specifikaciji (a treba je opisati), onda je potrebno uporediti očekivani rezultat sa dobivenim.

U fazi proučavanja specifikacije utvrđuje se kada i kako sama aplikacija treba da radi, kada i kako treba da reaguje na greške, odnosno kako sistem ili njegovi moduli treba da reaguju na netačne podatke ili netačno ponašanje korisnika.

Dokumentacija vam omogućava da sami shvatite glavne faze provjere aplikacije: gdje i kako aplikacija treba ispravno raditi, kako riješiti situacije greške: izdati poruke o grešci, upisati grešku u datoteku dnevnika rada, zaustaviti izvršavanje itd. .

1) provjeriti kako aplikacija radi kada dobije valjan unos;

2) ako sve radi kako treba, kako je opisano u specifikaciji, sljedeći korak je provjera graničnih vrijednosti (minimalne i maksimalne vrijednosti tačnih podataka);

3) provjeriti rad aplikacije prilikom unosa podataka koji nisu u opsegu važećih vrijednosti (provjera obrade neispravnih ulaznih vrijednosti).

Prva dva paragrafa opisuju proces koji se naziva "pozitivno" testiranje.

« pozitivno» testiranje- ovo je testiranje podataka ili scenarija koji odgovaraju normalnom (redovnom, očekivanom) ponašanju sistema koji se testira. Glavna svrha "pozitivnog" testiranja je provjeriti može li sistem raditi ono za što je stvoren.

« negativan» testiranje- radi se o testiranju podataka ili scenarija koji odgovaraju abnormalnom ponašanju sistema koji se testira, kao i izdavanje raznih poruka o grešci, izuzecima, "izvan" stanja itd.

Glavni cilj "negativnog" testiranja je provjeriti otpornost sistema na efekte "negativne" vrste: provjera pogrešnog skupa podataka, provjera obrade izuzetnih situacija (kako u implementaciji samih softverskih algoritama tako i u logici). pravila poslovanja) itd.

“Pozitivnom” i “negativnom” testiranju treba da prethodi rad na implementaciji “ flue» testiranje, tokom kojeg se vrši brzo, plitko testiranje najkritičnije funkcionalnosti na jednostavnim, odnosno tipičnim scenarijima uz minimum provjera („da nema dima“). Može se izvesti i na "pozitivnim" i na "negativnim" podacima

Definirajte funkcionalno testiranje, testiranje opterećenja, naprezanja i stabilnosti.

Funkcionalno testiranje sastoji se u testiranju sistema radi provjere izvodljivosti funkcionalnih zahtjeva, tj. sposobnost programa da u određenim uslovima rešava zadatke potrebne korisnicima. Funkcionalni zahtjevi definiraju šta program radi i koje zadatke rješava.

Testiranje na stres. Općenito, očekivana upotreba aplikacije se modelira emulacijom rada više korisnika u isto vrijeme. Takvo testiranje je najpogodnije za višekorisničke sisteme, a posebno one koji koriste arhitekturu klijent-server (na primjer, web serveri).

stres testiranje- vrsta softverskog testiranja koja ocjenjuje pouzdanost i stabilnost sistema u uslovima prekoračenja granica normalnog rada. Testiranje na stres je posebno neophodno za "kritičan" softver. Testiranje stresa je obično bolje u otkrivanju kvaliteta kao što su robusnost, dostupnost i sposobnost upravljanja izuzecima od strane sistema pod velikim opterećenjem od onoga što se smatra znakom ispravnog ponašanja u normalnim uslovima.

Ispitivanje stabilnosti. Ova vrsta testiranja se sastoji u provjeravanju operativnosti programa tokom dugotrajnog rada sa očekivanim nivoom opterećenja. Prije početka provjere rada sistema pri maksimalnim i kritičnim opterećenjima, potrebno je provjeriti njegov rad pod uslovima koji su propisani funkcionalnim zahtjevima, odnosno raditi sistem u normalnom režimu duže vrijeme. Glavni zadatak ovog testiranja je otkrivanje curenja memorije, kao i provjera da su brzina obrade i vrijeme odziva aplikacije bili isti na početku i na kraju testa.

Pitanja za temu 18