Pozitivno i negativno testiranje. Pozitivno razmišljanje u svijetu negativnog testiranja Pozitivno i negativno testiranje

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

Negativni testni slučajevi se koriste za provjeru funkcionalnosti aplikacije pod uvjetom 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 kada u upitu postoje jednostruki navodniki (na primjer, Jonesov auto).
Koristite jednostruke navodnike prilikom provjere valjanosti svakog polja unosa koje je u interakciji s bazom podataka.

Potreban unos podataka - Specifikacija vaše aplikacije treba jasno da definiše polja koja zahtevaju obavezan unos podataka.
Osigurajte 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, broj telefona ili poštanski broj, itd.)
Uvjerite se da svako polje dozvoljava samo tip podataka koji je specificiran u specifikaciji da se unese ili pohrani (na primjer, 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 maksimalni dozvoljeni broj znakova u svakom polju (na primjer, broj znakova u polju korisničkog imena ne smije biti veći od 50).
Uvjerite se da 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 trebaju ispravno funkcionirati, već i upozoravati korisnika na ograničenja, na primjer, uz pomoć napomena s objašnjenjima ili poruka o grešci.

Test numeričkih granica - Numerička polja vaše aplikacije mogu imati ograničenja na dozvoljene numeričke 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 je sasvim logično pretpostaviti da obračunata kamata ne može uzeti negativnu vrijednost).
Osigurajte da aplikacija prikazuje poruku o grešci kada su vrijednosti izvan važećeg raspona (na primjer, poruka o grešci bi se trebala pojaviti kada unesete vrijednost od 9 ili 51 u polje s važećim rasponom vrijednosti od 10 do 50 ili kada unosite negativnu vrijednost u polje, čije vrijednosti moraju biti pozitivne).

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 moraju biti u rasponu od -32768 do 32767 i dugog cijelog broja od -2147483648 do 2147483647).
Provjerite granične vrijednosti varijabli koje se koriste 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 nastupio (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 provjeru valjanosti unesenih vrijednosti (na primjer, 31.11.2009. nije ispravan datum). Također, ne zaboravite provjeriti datume u prijestupnoj godini (godine koje su djeljive sa 4 i djeljive sa 100 i 400 u isto vrijeme su prijestupne godine).

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

Mi (nije takva tajna) smo veoma zabrinuti za kvalitet naših proizvoda i sa strepnjom gledamo kako se sistem ruši. To opravdava postojanje testera u svijetu. Zbog toga se osjećamo kao heroji: veliki Tester je došao i spasio svoje korisnike od strašnih kritičnih grešaka!

A naši testeri nikada ne zaboravljaju negativno testiranje, iako nisu svi progeri sretni zbog toga. Ali takve provjere nisu hir “zlih testera” one su uzrokovane potrebom da se zatvore ranjivosti i zaštite od hakera i botova koji ulaze u sistem, Dos/DDos napada.

Naravno, koji je poziv specijalista za testiranje? Moramo pronaći probleme. Problemi o kojima najčešće niko nema vremena da razmišlja, niko ne želi da vidi ili da se bavi. A ako se provjeri ne samo ispravan rad sistema, već i njegovo abnormalno ponašanje, onda se dodaje napetost u timu.

Vidite, programeri pišu softver, ciljajući na rezultat, na planirano izdanje, leteći na krilima inspiracije! I tu dolazi faza provjere i brojnih ispravki i uređivanja “idealnog” koda. I to je to, sakrijte se negdje, sistem se testira.

Kako nikoga ne bi iritirali, neki stručnjaci mogu odgoditi negativno testiranje za kasnije ili ga potpuno zanemariti (užas!) kako bi smanjili rokove i budžete. Pa, zašto provjeravati da li program čak i ne radi ono što bi trebao, zar ne? Ne.

Pozitivno i negativno testiranje

Ali prvo stvari. Prilikom testiranja softvera pomoću test slučajeva, postoje dva skupa provjera: pozitivna i negativna. Štaviše, obično je više ovih potonjih nego prvih.

Pozitivno testiranje- ovo je provjera rada sistema za usklađenost sa njegovim normalnim (standardnim, očekivanim) ponašanjem, prema tehničkim specifikacijama i. Odnosno, ovdje gledamo da li softver radi ono što se od njega očekuje, da li implementacija ispunjava savremene zahtjeve, da li su podržane smjernice za korisnički interfejs itd.

A negativno testiranje- ovo je testiranje sistema na abnormalno ponašanje. Provjeravamo da li je softver otporan na pogrešan unos podataka, kako se rješavaju iznimne situacije, koje informacije se prikazuju u porukama o grešci, da li je moguće poremetiti funkcioniranje proizvoda i/ili utjecati na performanse rješenja i tako on.

Već smo rekli da neki specijalisti ostavljaju negativan test za kasnije ili ga potpuno zaboravljaju, što je skoro ista stvar. Znate, ono što je odloženo za kasnije gotovo uvijek ostaje neispunjeno.

Stoga, po našem mišljenju,

Negativni i pozitivni testovi ne moraju biti razdvojeni i vremenski razmaknuti.

Jer možemo li reći da sistem radi kako treba ako samo testiramo njegov odgovor na ispravne ulaze?

Pozitivno-negativno testiranje

Prilikom testiranja, kako su intuicija, instinkti, lovački instinkti važni - nazovite to kako želite. I ovdje sjedi naš inženjer i provjerava obrazac za registraciju, na primjer.

Provjerava sve po specifikacijama i scenarijima testiranja, gleda kako se obrađuju podaci koje korisnik mora unijeti u polja (usput rečeno, nije činjenica da će unijeti) i onda eto - uvid! Čini mu se da ako u ovo polje za prijavu unese neki “%adynadyn/>”, a ne običan tekst, onda će se nešto sigurno dogoditi. Nešto mračno i sumorno nije u redu.

I šta? Mora sebi reći: „Ne. Trenutno moram da uradim pozitivan test i ništa više. Imam negativan termin za sljedeću sedmicu, tada će doći vrijeme za %adynadyn/>. Možda"?

Vjerujemo da je ovaj pristup negativnom testiranju neučinkovit, a evo zašto:

1. Ako radite pozitivno i negativno testiranje odvojeno, to će potrajati duže. Barem zato što će ovo već biti dvije iteracije testiranja.
2. Testeri i koderi žive pod rokovima. A ako je vrijeme strogo ograničeno, onda odgađanje negativnog testa za kasnije povećava rizik da će na kraju biti zaboravljen. Uostalom, što je bliže trenutku X, vrijeme brže leti, prije morate završiti zadane zadatke, popraviti nedostatke, primijeniti konačne poslovne zahtjeve (koji se mogu promijeniti) i završiti gomilu drugih stvari. Rok - zauzeto vrijeme!
3. Razdvajanje negativnog i pozitivnog testiranja, po našem mišljenju, jednostavno je u suprotnosti sa prirodom testera! Uostalom, njegov glavni zadatak je provjeriti sistem za sve moguće radnje krajnjeg korisnika. Ali ljudi su uglavnom nelogični i mogu da rade sve vrste opscenih stvari sa softverom;)

Mi, kao testeri, veoma smo zabrinuti ako sistem sadrži greške u provjerama koje spadaju u negativnu kategoriju. A pogotovo ako su posljedice takvih grešaka kritične za cijeli sistem. Ali ne plašimo se da ih prijavimo. Pogotovo sa takvim asom u rukavu – u našem timu imamo testere. A ko može tvrdoglavo braniti “idealnost” koda kada blagim glasovima razbijaju performanse projekta na komadiće? Ista stvar.

Dakle, koje zaključke možemo izvući?

Ne zaboravite na negativno testiranje, kombinirajte ga s pozitivnim, okupite iskusne stručnjake u timu i pokušajte prebaciti zadatak izvještavanja na ramena djevojaka! Preporučujemo sve osim zadnjeg 100%, a vaš projekt menadžer će to riješiti.

I, naravno, obavezno provjerite svoj proizvod, nemojte misliti da će programeri odmah napisati čist i lijep kod - i dalje nećete proći bez grešaka! Da ne spominjemo brojne ranjivosti, o čemu svjedoče lični i povjerljivi podaci koji redovno cure na mrežu.

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

· “Pozitivno” testiranje.” U ovoj fazi potrebno je provjeriti izlaz aplikacije kada primi „ispravne“ ulazne podatke.

· “Negativno” testiranje. Ovo je završna faza početnog testiranja. Potrebno je vidjeti kako se aplikacija ponaša kada daje "netačne" podatke kao ulaz. Ako je takva opcija opisana u specifikaciji (a treba je opisati), onda je potrebno usporediti očekivani rezultat s 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 omogućava razumijevanje glavnih faza testiranja aplikacije: gdje i kako aplikacija treba ispravno raditi, kako postupati u situacijama greške: izdati poruke o grešci, upisati grešku u datoteku dnevnika operacija, zaustaviti izvršenje itd.

1) provjeriti kako aplikacija radi kada dobije ispravne podatke kao ulaz;

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 granicama prihvatljivih 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 (standardnom, očekivanom) ponašanju sistema koji se testira. Glavna svrha "pozitivnog" testiranja je provjeriti može li sistem raditi ono za što je dizajniran.

« Negativno» 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, izuzetne situacije, “preterana” stanja itd.

Osnovni cilj “negativnog” testiranja je provjeriti otpornost sistema na utjecaje “negativne” vrste: provjera netačnog skupa podataka, provjera obrade izuzetnih situacija (kako u implementaciji samih softverskih algoritama tako i u logici poslovnim pravilima) itd.

“Pozitivnom” i “negativnom” testiranju treba da prethodi rad koji treba izvršiti “ dim» 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 od testiranja sistema radi provjere izvodljivosti funkcionalnih zahtjeva, tj. sposobnost programa da pod određenim uslovima rešava probleme potrebne korisnicima. Funkcionalni zahtjevi definiraju šta program radi i koje probleme rješava.

Testiranje opterećenja. Općenito, očekivano korištenje aplikacije simulira se simuliranjem rada više korisnika u isto vrijeme. Ova vrsta testiranja je najpogodnija za sisteme sa više korisnika, a posebno za one koji koriste arhitekturu klijent-server (na primer, Web serveri).

Testiranje na stres– vrsta softverskog testiranja koja procjenjuje pouzdanost i stabilnost sistema kada se prekorače granice normalnog rada. Testiranje stresa je posebno neophodno za softver koji je „kritičan za misiju“. Testiranje stresa je obično bolje u otkrivanju kvaliteta kao što su robusnost, dostupnost i rukovanje izuzecima sistema pod velikim opterećenjem od onoga što se smatra pokazateljem ispravnog ponašanja u normalnim uslovima.

Ispitivanje stabilnosti. Ova vrsta testiranja sastoji se od provjere funkcionalnosti programa tokom dugotrajnog rada sa očekivanim nivoom opterećenja. Prije nego što počnete provjeravati rad sistema pod maksimalnim i kritičnim opterećenjima, potrebno je provjeriti njegov rad pod uvjetima navedenim u funkcionalnim zahtjevima, odnosno raditi sistem u normalnom režimu duže vrijeme. Glavni cilj ovakvog 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

Prilikom testiranja softverskog proizvoda koristi se veliki broj različitih vrsta testova. Najširu i najdetaljniju klasifikaciju predložio je autor knjige “Testing Dot Com” Roman Savin. Kombinovao je tipove testiranja prema karakteristikama kao što su objekt, subjekt testiranja, nivo, pozitivnost testiranja i stepen automatizacije testiranja. Klasifikacija je dopunjena na osnovu izvora kao što su knjiga Sama Kanera „Testiranje softvera” i onlajn resurs posvećen testiranju „O testiranju – Testiranje softvera”.

Testiranjem objekta

• · Funkcionalno testiranje. Funkcionalno testiranje je jedna od najčešće korištenih vrsta testiranja danas. Svrha takvog testiranja je utvrditi koliko dobro razvijeni softver zadovoljava zahtjeve korisnika u pogledu funkcionalnosti. Drugim riječima, provođenje funkcionalnih testova omogućava vam da provjerite sposobnost informacionog sistema da riješi probleme korisnika.
• · Nefunkcionalno testiranje. Omogućava vam da provjerite usklađenost svojstava softvera sa navedenim nefunkcionalnim zahtjevima. Dakle, nefunkcionalno testiranje je testiranje svih svojstava programa koja nisu vezana za funkcionalnost sistema. Takva svojstva mogu se predstaviti karakteristikama u smislu parametara kao što su:
• - Pouzdanost (sposobnost sistema da reaguje na neočekivane situacije).
• - Performanse (sposobnost sistema da radi pod velikim opterećenjima).
• - Pogodnost (proučavanje pogodnosti korisnika sa aplikacijom).
• - Skalabilnost (mogućnost skaliranja aplikacije i vertikalno i horizontalno).
• - Sigurnost (istraživanje mogućnosti ometanja aplikacije i krađe korisničkih podataka od strane napadača).
• - Prenosivost (mogućnost prijenosa aplikacije na određeni skup platformi)

I mnoge druge kvalitete.

• · Testiranje korisničkog interfejsa. To je testiranje ispravnog prikaza elemenata korisničkog interfejsa na različitim uređajima, ispravnost njihovog odgovora na izvršavanje različitih radnji korisnika, kao i procjena očekivanog ponašanja programa u cjelini. Ovakvo testiranje omogućava da se proceni koliko će korisnik efikasno moći da radi sa aplikacijom i koliko izgled aplikacije odgovara odobrenim dokumentima koje su kreirali dizajneri. Prilikom provođenja testiranja korisničkog sučelja, glavni zadatak testera je identificirati vizualne i strukturne nedostatke u grafičkom sučelju aplikacije, provjeriti sposobnost i jednostavnost navigacije u aplikaciji i osigurati da aplikacija obrađuje unos s tastature, miša i drugog unosa uredjaje ispravno. Testiranje korisničkog interfejsa je neophodno kako bi se osiguralo da je interfejs usklađen sa odobrenim zahtevima i standardima i da bi se osiguralo da korisnik može da komunicira sa grafičkim interfejsom aplikacije.
• · Testiranje upotrebljivosti. Ovo je metoda testiranja koja vam omogućava da procenite stepen lakoće upotrebe aplikacije, brzinu učenja korisnika pri radu sa programom, kao i koliko korisnici proizvoda koji se razvija smatraju razumljivim i privlačnim u kontekstu datim uslovima. Takvo testiranje je neophodno kako bi se osiguralo najpozitivnije korisničko iskustvo pri radu s aplikacijom.
• · Sigurnosno testiranje. Omogućava vam da identifikujete glavne softverske ranjivosti u odnosu na razne napade uljeza. Kompjuterski sistemi su često podložni sajber napadima s ciljem ometanja rada informacionog sistema ili krađe povjerljivih podataka. Sigurnosno testiranje omogućava analizu stvarnog odgovora i efikasnosti odbrambenih mehanizama koji se koriste u sistemu prilikom pokušaja prodora. Tokom testiranja sigurnosti, tester pokušava izvršiti iste radnje koje bi izvršio pravi napadač. Kada tester pokuša da hakuje sistem, može se koristiti bilo koje sredstvo: napad na sistem pomoću posebnih uslužnih programa; pokušava otkriti prijave i lozinke korištenjem vanjskih sredstava; DDOS napadi; ciljano generiranje grešaka za otkrivanje mogućnosti prodora u sistem tokom njegovog oporavka; iskorištavanje poznatih nezakrpljenih ranjivosti sistema.
• · Ispitivanje instalacije. Ovaj pojam označava testiranje ispravnosti instalacije (instalacije) određenog softverskog proizvoda. Takvo testiranje se obično odvija u veštački stvorenim okruženjima kako bi se utvrdio stepen spremnosti softvera za upotrebu. Glavni razlozi za sprovođenje ovakvih testova su povezani sa potrebom da se proveri ispravno ponašanje softverskog proizvoda tokom automatizovane implementacije ili ažuriranja. Osiguranje ispravne i stabilne instalacije softvera vrlo je važan faktor pri kreiranju softverskog proizvoda, jer omogućava korisnicima da brže i uz manje napora počnu koristiti proizvod, a pritom se osigurava da se proizvod jednako korektno ponaša u svim testiranim softverskim okruženjima.
• · Testiranje konfiguracije. Testiranje konfiguracije je dizajnirano da procijeni performanse softvera pod različitim konfiguracijama sistema. Ovisno o vrsti softverskog proizvoda koji se testira, testiranje konfiguracije može služiti u različite svrhe. Obično je to ili određivanje optimalne hardverske konfiguracije koja obezbjeđuje dovoljne parametre performansi za rad softvera, ili provjera određene hardverske konfiguracije (ili platforme, koja osim hardvera uključuje softver treće strane neophodan za rad programa) radi kompatibilnosti sa proizvodom koji se testira. Ako govorimo o klijent-server softveru, tada se testiranje konfiguracije provodi zasebno za server i zasebno za klijenta. Obično, kada se testira kompatibilnost servera sa određenom konfiguracijom, zadatak je pronaći optimalnu konfiguraciju, jer je stabilnost i performanse servera bitna. Dok pri testiranju klijenta, naprotiv, pokušavaju identificirati softverske nedostatke u bilo kojoj konfiguraciji i, ako je moguće, ukloniti ih.
• · Testiranje pouzdanosti i oporavak od kvarova (testiranje na stres). Ova vrsta testiranja se često provodi za softver koji radi s vrijednim korisničkim podacima, čiji je neprekidan rad i brzina oporavka od kvarova kritični za korisnika. Testiranje kvarova i oporavak testiraju sposobnost programa da se brzo i uspješno oporavi od kvara hardvera, prekida mreže ili kritičnih grešaka u samom softveru. Ovo omogućava procjenu mogućih posljedica kvara i vremena potrebnog za naknadni oporavak sistema. Na osnovu podataka dobijenih tokom testiranja može se procijeniti pouzdanost sistema u cjelini i, uz nezadovoljavajuće performanse, mogu se preduzeti odgovarajuće mjere za poboljšanje sistema oporavka.
• · Testiranje lokalizacije. Lokalizacijsko testiranje omogućava da se utvrdi koliko je proizvod prilagođen stanovništvu određenih zemalja i koliko odgovara njegovim kulturnim karakteristikama. Obično se razmatraju kulturološke i jezičke nijanse, odnosno prevod korisničkog interfejsa, prateće dokumentacije i fajlova na određeni jezik, a takođe se ispituje ispravnost formata valuta, brojeva, vremena i telefonskih brojeva.
• · Testiranje opterećenja. Testiranje opterećenja vam omogućava da identifikujete maksimalan broj sličnih zadataka koje program može da obavlja paralelno. Najpopularnija svrha testiranja opterećenja u kontekstu klijent-server aplikacija je procjena maksimalnog broja korisnika koji mogu istovremeno koristiti usluge aplikacije.
• · Ispitivanje stabilnosti. Testiranje stabilnosti provjerava funkcionalnost aplikacije tokom dugotrajne upotrebe pod umjerenim opterećenjima. Ovisno o vrsti aplikacije, formiraju se određeni zahtjevi za vrijeme njenog neprekidnog rada. Testiranje stabilnosti nastoji da identifikuje nedostatke aplikacije kao što su curenje memorije, prisustvo izraženih skokova opterećenja i drugi faktori koji mogu sprečiti da aplikacija radi u dužem vremenskom periodu.
• · Volumensko testiranje. Zadatak volumenskog testiranja je da identifikuje odgovor aplikacije i proceni moguće pogoršanje u radu softvera uz značajno povećanje količine podataka u bazi podataka aplikacije. Obično ovo testiranje uključuje:
• - Mjerenje vremena izvršenja operacija koje se odnose na dobijanje ili promjenu podataka baze podataka pri određenom intenzitetu zahtjeva.
• - Identifikacija zavisnosti povećanja vremena rada od obima podataka u bazi podataka.
• - Određivanje maksimalnog broja korisnika koji mogu istovremeno raditi sa aplikacijom bez primjetnih kašnjenja iz baze podataka.
• Testiranje skalabilnosti. Ovo je vrsta testiranja softvera dizajnirana da testira sposobnost proizvoda da poveća (ili ponekad smanji) određene nefunkcionalne karakteristike. Neke vrste aplikacija moraju se lako skalirati i, naravno, u isto vrijeme, ostati operativne i izdržati određeno opterećenje korisnika.

Promjena vezano za testiranje

• · Uračunljivost je jedan od tipova ispitivanja čija je svrha dokazivanje performansi određene funkcije ili modula u skladu sa tehničkim zahtjevima koje je naveo kupac. Sanitarno ispitivanje se često koristi za testiranje nekog dijela programa ili aplikacije kada se na njemu izvrše određene promjene zbog faktora okoline. Ova vrsta testiranja se obično izvodi ručno.
• · Testiranje dima je kratka serija testova, čija je svrha da potvrdi da je instalirana aplikacija pokrenuta i da obavlja funkcije nakon što je novi ili uređeni kod napravljen. Po završetku testiranja najvažnijih segmenata aplikacije daje se objektivna informacija o prisustvu ili odsustvu nedostataka u radu testiranih segmenata. Na osnovu rezultata ispitivanja dima donosi se odluka da li se aplikacija šalje na poboljšanje ili je potrebno u potpunosti ispitati.
• · Regresijsko testiranje - testiranje usmjereno na otkrivanje grešaka u već testiranim područjima. Regresijsko testiranje provjerava u proizvodu greške koje su se možda pojavile kao rezultat dodavanja novog odjeljka programa ili ispravljanja drugih grešaka. Svrha ove vrste testiranja je da se uveri da ažuriranje gradnje ili ispravljanje grešaka ne rezultira novim greškama.

Po nivou testiranja

• · Jedinično testiranje (Testovi jedinica). Sastoji se od provjere svakog pojedinačnog modula (originalnog elementa sistema) pokretanjem automatiziranih testova u vještačkom okruženju. Implementacije takvih testova često koriste različite stubove i drajvere za simulaciju rada stvarnog sistema. Automatsko testiranje jedinica je prva prilika za pokretanje i provjeru izvornog koda. Kreiranje jediničnih testova za sve sistemske module omogućava vam da vrlo brzo identifikujete greške u kodu koje se mogu pojaviti tokom razvoja.
• · Integracijsko testiranje. Ovo je testiranje pojedinačnih modula sistema za ispravnu interakciju. Glavni cilj integracijskog testiranja je pronalaženje nedostataka i identifikovanje nepravilnog ponašanja povezanog sa greškama u interpretaciji ili implementaciji interakcije između modula.
• · Testiranje sistema. Ovo je testiranje programa u cjelini; takvo testiranje potvrđuje da program ispunjava navedene zahtjeve.
• · Testiranje prihvatljivosti. Ovo je sveobuhvatan test kojim se utvrđuje stvarni nivo spremnosti sistema za upotrebu od strane krajnjih korisnika. Testiranje se provodi na osnovu skupa test scenarija koji pokrivaju glavne poslovne operacije sistema.

Izvođenjem koda

• · Statičko ispitivanje. To je identifikacija artefakata koji se pojavljuju tokom razvoja softverskog proizvoda analizom izvornih datoteka kao što su dokumentacija ili programski kod. Takvo testiranje se vrši bez direktnog pokretanja koda, kvalitet izvornih datoteka i njihova usklađenost sa zahtjevima se procjenjuju ručno ili pomoću pomoćnih alata. Statičko testiranje treba obaviti prije dinamičkog testiranja, tako da će greške pronađene tokom faze statičkog testiranja biti jeftinije. Sa stanovišta izvornog koda, statičko testiranje se izražava u reviziji koda. Tipično, revizija koda pojedinačnih datoteka se vrši nakon svake promjene ovih datoteka od strane programera, ali samu reviziju može izvršiti ili drugi programer, ili vodeći programer, ili pojedini zaposlenik angažovan na reviziji koda. Upotreba statičkog testiranja omogućava održavanje kvaliteta softvera u svim fazama razvoja i smanjuje vrijeme razvoja proizvoda.
• · Dinamičko testiranje. Za razliku od statičkog testiranja, ova vrsta testiranja uključuje pokretanje izvornog koda aplikacije. Dakle, dinamičko testiranje sadrži mnoge druge vrste testiranja, koje su već opisane gore. Dinamičko testiranje vam omogućava da identifikujete greške u ponašanju programa analizom rezultata njegovog izvršavanja. Ispada da gotovo sve postojeće vrste testiranja odgovaraju klasi dinamičkog testiranja.

Po subjektu testiranja

• · Alfa testiranje. Ovo testiranje se izvodi na najranijim verzijama kompjuterskog softvera (ili hardverskog uređaja). Alfa testiranje gotovo uvijek sprovode sami programeri softvera. Tokom procesa alfa testiranja, programeri aplikacija pronalaze i ispravljaju greške i probleme u programu. Obično, tokom Alpha testiranja, ređe dolazi do imitacije rada sa programom od strane programera sa punim radnim vremenom, pravi rad i potencijalnih korisnika i kupaca sa proizvodom. Alfa testiranje se u pravilu provodi u vrlo ranoj fazi razvoja softvera, ali se u nekim slučajevima može koristiti za gotov ili skoro gotov proizvod, na primjer, kao testiranje prihvatljivosti.
• · Beta testiranje. Testiranje proizvoda koji je još u razvoju. U beta testiranju, ovaj proizvod je dostupan malom broju korisnika kako bi proučili i prijavili nove probleme s kojima se korisnici susreću. Takvo testiranje je neophodno kako bi se pronašle greške koje su programeri možda propustili. Obično se beta testiranje provodi u dvije faze: zatvoreno beta testiranje i otvoreno beta testiranje. Zatvoreni beta test je testiranje na strogo ograničenom krugu odabranih korisnika. Takvi korisnici mogu biti poznanici programera ili njihove kolege koji nisu direktno povezani sa razvojem proizvoda koji se testira. Otvoreno beta testiranje uključuje kreiranje i puštanje javne beta verzije za javnost. U ovom slučaju, svaki korisnik može djelovati kao beta tester. Povratne informacije od ovakvih beta testera se vrše korišćenjem pregleda na sajtu i analitičkih sistema i evidentiranja radnji korisnika koji su ugrađeni u ovi sistemi su neophodni za analizu ponašanja korisnika i otkrivanje poteškoća i grešaka na koje nailaze.

Prema pozitivnosti scenarija

• · Pozitivno testiranje. Testovi sa pozitivnim scenarijem provjeravaju sposobnost programa da izvrši svoju predviđenu funkcionalnost. Po pravilu se za takvo testiranje razvijaju testni scenariji čije izvođenje, u normalnim radnim uslovima softvera, ne bi trebalo da izazove poteškoće.
• · Negativno testiranje. Negativno testiranje softvera događa se u scenarijima koji odgovaraju abnormalnom ponašanju programa. Takvi testovi provjeravaju ispravan rad programa u vanrednim situacijama. Ovo pomaže da se osigura da program proizvodi ispravne poruke o grešci, da ne ošteti korisničke podatke i da se općenito ponaša ispravno u situacijama u kojima nije predviđeno normalno ponašanje proizvoda. Glavni cilj negativnog testiranja je provjera otpornosti sistema na različite utjecaje, sposobnost ispravne validacije ulaznih podataka i rukovanja izuzetnim situacijama koje nastaju kako u samim softverskim algoritmima tako i u poslovnoj logici.

Po stepenu automatizacije

• · Ručno testiranje. Ručno testiranje se provodi bez upotrebe dodatnog softvera, omogućava vam da provjerite program ili web stranicu simulacijom radnji korisnika. U ovom modelu, tester djeluje kao korisnik, prateći određene skripte dok istovremeno analizira izlaz programa i cjelokupno ponašanje.
• · Automatsko testiranje. Takvo testiranje omogućava da se korištenjem dodatnog softvera za automatizaciju testiranja značajno ubrza proces testiranja. Takav dodatni softver vam omogućava da pratite i upravljate izvođenjem testova i uporedite očekivane i stvarne rezultate programa. O tome će se detaljnije govoriti kasnije.

Aaaa i... Ovo je zadnji unos u nizu! Najkraći je, najjednostavniji i gotovo se u potpunosti sastoji od stvarnih priča. Ako je moguće - glupo i smiješno. Postoji čak i video snimljen specijalno za snimanje upravo u vrijeme pisanja. Sveže, gospodine. Nažalost, nisam mislio da napravim snimak ekrana poruke o padu Youtube klijenta. Pao u pravu prilikom postavljanja videa koji je umetnut u članak. Ok, neka bude moj zaključani ekran.

Na početku testiranja, bez obzira da li se radi o novom projektu ili o onom koji treba zakopati, općenito je uvijek jasno odakle početi. Osim ako, naravno, do početka testiranja nijedna karika u lancu nije radila kako treba. Tipično, testeri čitaju zahtjeve i druge dokumente s nazivima koji nisu na ruskom jeziku, kao što su „BEC“, „ESArchi“ i „User Story“ i shvate kako da napišu probni slučaj tako da on provjeri izvršenje svih ovih dokumenata. Sve je to na površini jasno i nema smisla zadržavati se na tome. Ali tu je i ponašanje samog Androida, kojeg ponekad ne znaju samo analitičari, već čak ni arhitekti i neki programeri. A imajući na umu da samo kod prilagođenih, pojavljuje se dosta takvih funkcija. I ne govorim o stresnim scenarijima kada nema memorije ili se odjednom izvadi baterija (jednom sam na GNU/Linux terminalu naišao na ogorčenje osobe jer ne pokazuje lozinku pri ulasku, ali ima zaglupljenu tastaturu i ne razumije da li unosi lozinku ili tastatura opet ne radi), već o standardnom ponašanju prilagođavanja Androida, pa čak i ponašanju svojstvenom AOSP-u. Odnosno, standardna ponašanja sistema koja mogu negativno uticati na proizvod koji se testira. Takozvani negativni scenariji.

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

• Problemi u komunikaciji. Najjednostavniji primjer je Fly Mode. Na primjer, aplikacija Google Keep bilješke ili nije testirana u načinu rada u avionu, ili pronađene greške nisu utjecale na izdanje. Vrlo je lako reproducirati problem:
• Uključite način rada u avionu
• Dodirnite liniju Zabilježite...
• Na ekranu koji se pojavi izvršite akciju Brisanje
• Uživanje u animaciji pomeranja prethodno sačuvanih beleški

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

• Nema pristupa trgovini aplikacijama. Na primjer, da biste testirali kupovinu unutar aplikacije, potrebno je da sklop bude objavljen u trgovini u posebnom odjeljku. Ako ga nema, ili ako nije ista verzija (govorimo o kodu verzije - internoj verziji), tada nećete testirati kupovinu. Ako korisnik ode na odmor u Kinu, gdje je veza s Google Playom jako tužna, licenca za koju je platio ne bi smjela otpasti.
• Rad aplikacije s ograničenim dozvolama, ako je ciljni API nivo niži od 23, odnosno manji od Androida 6 i kada je verzija API-ja 23 i viša. U prvom slučaju, aplikacija je naslijeđena, ali dozvole se i dalje mogu oduzeti. U drugom slučaju, počet će primati nove izuzetke koje ranije nije znao.
• Režim uštede baterije. Implementacija i Doze i App Standby, kao i alternativne implementacije alternativno nadarenih proizvođača poput Samsunga (i STAMINA iz Sonyja u prvoj verziji), kada je sve implementirano užasno pogrešno, ali s tim se mora živjeti. Dozvoljeno je da aplikacija ne vrši provjere na vrijeme, ne šalje statistiku, ne ažurira podatke. Ali nije prihvatljivo rušenje, zamrzavanje ili nikad dovršavanje planiranih zadataka.
• Promjena datuma, vremena, vremenske zone. Ljudi mogu letjeti na odmore i poslovna putovanja u druge zemlje gdje je vremenska zona drugačija. Ako avion pređe 180. meridijan, onda bi korisnik mogao završiti „u jučer“ sa stanovišta aplikacije.

  Istinita priča o neuspjehu. Roditeljski nadzor u KIS-u za Windows pojavio se u verziji 7.0 2006. godine. U isto vrijeme, proizvod je imao ugrađenog novinskog agenta, nimalo nalik onome š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 korisnička prava i svaki računovođa je imao lokalnog administratora. Jedan od naših klijenata u svojoj maloj kancelariji postavio je roditeljski nadzor tako da korisnici ne mogu da surfuju internetom osim na ovlašćenim sajtovima. Drakonowski je konfigurirao i lozinkom zaštitio postavke. Sve je funkcionisalo u redu dok nije poslata vijest ugrađenom agentu za vijesti da je vrijeme za ažuriranje na novu verziju 7.0.1 koja je, između ostalog, ispravila bug zbog kojeg je zaštita bila onemogućena kada se vrijeme vrati prije početka licence. Korisnik je pročitao vijesti, bio sretan i isključio zaštitu na predloženi način. Nekoliko dana kasnije, ova njegova priča pojavila se na tada popularnom bash.org.ru. Od tada korisnici više ne primaju ovakve vijesti.

  I nemojte misliti da on ne pravi takve greške. 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, već duže vrijeme želim da ga objavim). Telefoni se isključuju ako postavite vrijeme bliže početku računanja unix vremena. I kako je Apple popravio ovu grešku? Zabranili su promjenu vremena dalje od kritičnog datuma, što NIJE rješenje za problem. Napadači su počeli da postavljaju svoje Wi-Fi tačke sa imenima koja se obično nalaze u svim vrstama McDonald'sa i preko njih prenose lažno vreme. Uređaji su se automatski povezivali na takve tačke i detektovali NTP servere od kojih su tražili vreme. Apple se jednostavno nije pobrinuo da iOS ne koristi lažne NTP servere. Tako je iOS ponovo izgrađen.

• Promjena lokalizacije sistema i jezika interfejsa. Korisnik ima pravo da promijeni jezik sistema sto puta dnevno i niko mu to 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 sruši. Osim lokalizacije, korisnik ima pravo mijenjati tipove i fontove, birajući one koje mu je ugodno čitati. Aplikacija se ne bi trebala raspasti ako korisnik napravi razumne promjene.
• tapjaking. Ovu stvar sam spomenuo na prvom predavanju. Da vas podsjetim da je ovo presretanje tapova koje je primila aktivnost aplikacije A, dok je korisnik pokušavao doći do aplikacije B. Jednostavno, aktivnost aplikacije A je transparentna. Ovo ne zvuči kao sigurno rješenje od Googlea, ali ovako rade aplikacije za kontrolu svjetline i temperature boje na uređajima. Korisnicima su takve aplikacije zgodne, 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. Sasvim je prihvatljivo imati nekoliko različitih aktivnosti koje mogu pozvati vanjske aplikacije, nikad ne znate zašto. To će biti izvozne aktivnosti. Ali može biti da da biste pozvali neku aktivnost morate joj proslediti parametre. I 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 biste trebali, da tako kažem, bespotrebno pokazivati ​​golu zadnjicu vani. Po defaultu, izvezena zastavica je postavljena na true, a ako ste sigurni da vanjske aplikacije ne bi trebale da ih pozivaju, trebali biste je postaviti na false. Pa, tester mora provjeriti kako će se aplikacija ponašati ako se njena aktivacija pozove iz drugih aplikacija.
• Ubica sistema. Općenito se zove OOM Killer - Out Of Memory Killer. Sistem počinje KILLING ako aplikacija sa kojom korisnik komunicira u ovom trenutku nema dovoljno memorije za rad. Naravno, ubica nije glup, on se povinuje određenim algoritmima, birajući mete (npr. sistem će lako ubiti pozadinski servis, ali će servis u prednjem planu sačuvati do poslednjeg; prvi plan je obično onaj koji crta svoju ikonu u području obavijesti, na primjer - player ), ali to je suština toga. Po pravilu, OOM Killer nije previše agresivan na modernim uređajima. Danas je memorija postavljena na jedan gigabajt i više. Ali ovo se ne odnosi na igre. Igre su toliko teške, jedu toliko memorije da koliko god da uložite, to ipak neće biti dovoljno. I općenito, što više RAM-a stave u uređaje, to će aplikacije biti deblje, a igre najdeblje. U isto vrijeme, oni će ostati jednako dosadni i nepotrebni.

  Suština je da će vaš proizvod zajamčeno potpasti pod OOM Killer. Vaš posao je da se pobrinete da ništa loše ne dođe od ovoga i da se proizvod podigne čim ssbbw aplikaciju zalupi sistem (ako proizvod to zahtijeva, naravno). I sistem će to učiniti prvom prilikom, neće dozvoliti takvom ssbbwu da živi u pozadini.
  Još jedan zaključak je da ni vaša aplikacija ne bi trebala biti ssbbw aplikacija. Svako curenje mora biti otkriveno od strane programera prije nego što napiše stvarni kod. Vaši testovi performansi bi svakako trebali imati test scenarije kada majmun generiše 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 curi iz svih pukotina, sistem će je pucati. Naravno, nakon ovoga će se ponovo pokrenuti i memorije više neće biti, jer nakon ubijanja procesa sakupljač smeća sve čisti, ali ako je mamac pokazao da aplikacija curi u svom testu za 15 minuta, tada će korisnik doživite ova curenja i kasnije, ali to će se jednako pokazati.

• Big Data. Ako vaša aplikacija radi s korisničkim podacima, budite spremni na to da korisnik bez razmišljanja unese nešto vrlo veliko. Na primjer, ja kao korisnik u potpunosti očekujem da će Youtube klijent preuzeti moj video, ma koliko ovaj video bio težak. Očekujem da će se arhivator uklopiti u bilo koju dubinu arhive, koja teži 5 puta više od cjelokupne dostupne RAM memorije uređaja. Ovo je u redu. Ako vam neko kaže da "niko nikada neće hraniti tako velike datoteke", onda najvjerovatnije govornik jednostavno nije baš dobar programer.
• Najgluplja i stoga najsmješnija situacija koja uzrokuje kvar aplikacije, čak i pad, je jednostavna rotacija ekrana. Koliko je sličnih padova identifikovano tokom faze testiranja! Pogotovo ako se pojavi neka vrsta pop-up prozora. U 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 isporučeni, ispostavilo se da su se aplikacije na tabletima srušile na skoro svakom ekranu. Ali zato što su fragmenti. Bilo je različitih interfejsa na ekranu i na telefonu, a nepravilna upotreba fragmenata je dovela do tužnog rezultata.
• Dvostruki, trostruki dodiri. 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 imam u rukama stari telefon na Androidu 4.0, koji se jedva kreće, a ekran mu ne reaguje previše. Možda nije jasno da li je došlo do klika ili ne i rezultat je dvostruki dodir. Ne zato što su “dvostruki” (u smislu ne oni koji se rade s intervalom manjim od sekunde), već zato što ih je bilo dva ili više dok je aplikacija “razmišljala”. Na primjer, dok je formirao listu mnogih elemenata.
• Jedna od zgodnih karakteristika Androida 6, ako nije dovoljno testirana, dovodi do užasnih rezultata. Do te mjere da je njegovo korištenje izričito zabranjeno u aplikaciji, što za sada dozvoljava Google. Ova karakteristika - sigurnosno kopiranje i vraćanje iz sigurnosne kopije. Inače, nije novo, backup se pojavio u Androidu 2.2, ali ne znam ni jednu aplikaciju koja koristi ovu lepinju.
  Kreiranje sigurnosne kopije i njeno vraćanje samo po sebi nije strašno. Problemi počinju ako proizvod koristi vezivanje za identifikator uređaja i identifikator instalacije. Čak i unutar istog uređaja, to može dovesti do problema, ali 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, gdje se sva komunikacija obavlja pomoću tokena, ovdje ima puno problema.

  Borbeni primjer je cool aplikacija Talon za Twitter. Nisam resetovao uređaj jako dugo i stoga ne znam da li je autor ispravio ovu grešku. Kada sam ga prijavio, 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. Općenito, 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 iz bilješki. Kada je čarobnjak za instalaciju završen i potrebne dozvole su primljene, postavljena je zastavica o tome kako ne bi morali svaki put ponovo prolaziti kroz instalaciju. A aplikacija je napravljena sigurnosna kopija zajedno sa ovom zastavicom. Zajedno s njim je restauriran. Iako su prema zadanim postavkama za sve aplikacije novog tipa (tj. targetApi nivo >= 23) dozvole onemogućene. Pokrenuli ste aplikaciju, ali ona ne može ispravno raditi. Budući da nema provjere dostupnosti dozvola, sve provjere su ostale u čarobnjaku za početno podešavanje, koji nije započeo jer je zastavica postavljena na „čarobnjak je već prošao“. Osim toga, nakon lansiranja, klijent nije učitavao tvitove, zadajući udarac samom Twitteru. Zato što zakopani token nije bio važeći na novoj instalaciji i bilo je potrebno zatražiti novi, a ovaj zahtjev je također napravljen u čarobnjaku za instalaciju u prvom koraku!

• U Androidu, počevši od verzije (ako me sjećanje ne vara) 2.2.1, postalo je moguće premjestite neke podatke aplikacije na memorijsku karticu. Polako je ova funkcija počela da se gasi, sve dok joj u Androidu 6 Google nije dao drugi život, značajno je poboljšavši. Ako proizvođač uređaja svojim običajem nije prekršio AOSP ponašanje 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 ga ne planira onemogućiti, onda Android formatira karticu u svoj sistem datoteka i povezuje je kao dio glavne memorije, omogućavajući instaliranje aplikacija tamo. I evo nekoliko zamki:
• Ako aplikacija koristi tvrdo kodirane staze, sve je izgubljeno. Ali ovo je toliko loš ukus da se nadam da to niko neće uraditi.
• Ako je aplikacija zatražila od sistema putanje kada je prvi put pokrenuta i pohranila ih zauvijek, tada će biti potpuno isto kao i kod tvrdo kodiranih

• Kako se aplikacije ažuriraju, korisnici će dobiti nove verzije iz trgovine aplikacija i instalirati ih na postojeću. Jer provjeravam ažuriranje aplikacije na novu verziju- obavezna skripta. U normalnoj situaciji sve bi trebalo biti u redu, ali kada morate podržati mnoge određene uređaje sa njihovim 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 efikasno i obrađuje razne izuzetke. Ali jednostavno gubljenje nekih postavki je već loše. Na primjer, imali smo situaciju da su korisnici mjesecima kreirali antispam listu, blokirali brojeve taksija, banaka i servisa za naplatu, a onda su, nakon ažuriranja na novu verziju, sve liste bile izgubljene. Upravo zato što se promijenio format postavki i upravo ovdje, upravo 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 samog firmvera za novu verziju, ali sa ispravnim proizvodom. Navest ću dva primjera, od kojih je jedan već ispričan.
• Uobičajeno sigurnosno ažuriranje za Android 5.1, koje je preuzelo i onemogućilo doživotne karakteristike OS-a koji je aplikacija koristila
• Nakon ažuriranja 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). Jedan od naših proizvoda u svrhu interne sigurnosti provjerava s koje je putanje dostupna zaštićena aplikacija i da li se promijenila. Stiglo je ažuriranje na 5.0 i apsolutne putanje su se promijenile 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, neke od njih već znate - oni su direktno opisani u ovoj seriji postova.
Bye bye!