Testare pozitivă și negativă. Gândire pozitivă într-o lume a testării negative Care dintre aceste teste este negativ?

Traducere gratuită a articolului „Top 10 Negative Test Cases” de Steve Miller.

Cazurile de testare negative sunt folosite pentru a verifica funcționalitatea aplicației, cu condiția ca date „incorecte” să fie primite la intrarea acesteia. Astfel de cazuri de testare trebuie utilizate în timpul testării. Mai jos sunt cele mai populare zece scenarii de testare negativă:

Citate unică încorporată - Majoritatea bazelor de date SQL au probleme când există ghilimele simple în interogare (de exemplu, mașina lui Jones).
Utilizați ghilimele simple atunci când validați fiecare câmp de intrare care interacționează cu baza de date.

Introducerea datelor obligatorii - Specificațiile aplicației dvs. ar trebui să definească în mod clar câmpurile care necesită introducerea obligatorie a datelor.
Asigurați-vă că formularele care au câmpuri definite ca obligatorii nu pot fi salvate dacă nu există date în ele.

Tipuri de date de câmp (test de tip de câmp) - Specificațiile aplicației dvs. ar trebui să definească în mod clar tipurile de date pentru fiecare dintre câmpuri (câmpuri de dată/oră, câmpuri numerice, câmpuri de număr de telefon sau cod poștal etc.)
Asigurați-vă că fiecare câmp permite introducerea sau stocarea numai a tipului de date specificat de specificație (de exemplu, aplicația nu trebuie să permită introducerea sau stocarea de litere sau caractere speciale în câmpuri numerice).

Test pentru dimensiunea câmpului - Specificațiile aplicației dvs. ar trebui să definească în mod clar numărul maxim permis de caractere în fiecare câmp (de exemplu, numărul de caractere din câmpul nume de utilizator nu trebuie să depășească 50).
Asigurați-vă că aplicația nu vă permite să introduceți sau să stocați mai multe caractere decât cele specificate în specificație. Nu uitați că aceste câmpuri nu numai că ar trebui să funcționeze corect, ci și să avertizeze utilizatorul despre limitări, de exemplu, cu ajutorul unor note explicative sau mesaje de eroare.

Testul limitelor numerice - Câmpurile numerice ale aplicației dvs. pot avea restricții cu privire la valorile numerice permise. Aceste restricții pot fi specificate în specificația aplicației dvs. sau pot urma din logica programului (de exemplu, dacă testați funcționalitatea legată de calcularea dobânzii la un cont, atunci este destul de logic să presupunem că dobânda acumulată nu poate ia o valoare negativă).
Asigurați-vă că aplicația afișează un mesaj de eroare atunci când valorile sunt în afara intervalului valid (de exemplu, un mesaj de eroare ar trebui să apară atunci când introduceți o valoare de 9 sau 51 într-un câmp cu un interval de valori valid de la 10 la 50 sau când introduceți o valoare negativă într-un câmp, ale cărui valori trebuie să fie pozitive).

Testul limitelor numerice - Majoritatea bazelor de date și limbajelor de programare definesc valori numerice ca variabile de un anumit tip (de exemplu, întreg sau întreg lung), care la rândul lor au restricții asupra valorilor numerice permise (de exemplu, valorile întregi trebuie să fie în intervalul de la -32768 la 32767 și un întreg lung de la -2147483648 la 2147483647).
Verificați valorile limită ale variabilelor utilizate pentru câmpurile numerice ale căror valori limită nu sunt definite clar de specificație.

Testul limitelor datei - Foarte des în aplicații există restricții logice pentru câmpurile care conțin data și ora. De exemplu, dacă verificați un câmp care conține data de naștere a utilizatorului, atunci ar fi destul de logic să interziceți introducerea unei date care nu a avut loc încă (adică o dată în viitor) sau să restricționați intrarea. a unei date care diferă de cea de astăzi cu peste 150 de ani.

Valabilitate data - Câmpurile de dată ar trebui să aibă întotdeauna o verificare a validității valorilor introduse (de exemplu, 31/11/2009 nu este o dată validă). De asemenea, nu uitați de verificarea datelor într-un an bisect (anii divizibili cu 4 și divizibili cu 100 și 400 în același timp sunt ani bisecti).

Testarea sesiunii web - Multe aplicații web folosesc sesiuni de browser pentru a urmări utilizatorii conectați, pentru a aplica setări specifice aplicației unui anumit utilizator etc. În același timp, multe părți funcționale ale sistemului nu pot sau nu ar trebui să funcționeze fără a se conecta mai întâi la sistem. Asigurați-vă că funcționalitatea sau paginile din spatele unei parole nu sunt accesibile unui utilizator neautorizat.

Foarte preocupat de calitatea produselor. Aceasta explică disponibilitatea la nivel mondial a testerelor de software. Oferind, acești oameni asigură calitatea acestuia.

Mulți testeri nu vor uita niciodată de testarea negativă, deși nu toți programatorii sunt fericiți de asta. Un astfel de control este necesar pentru a proteja împotriva hackerilor, roboților, atacurilor Dos/DDos.

Care este chemarea specialiștilor în testare? Ei trebuie să găsească probleme care nu sunt vizibile pentru alții. Nu amânați cu testarea negativă, altfel expuneți sistemul la pericol.

Testare pozitivă și negativă

Să începem de la început. Există 2 tipuri de control atunci când cazurile de testare sunt incluse în testare: pozitiv și negativ. Acesta din urmă are avantajul.

Testare pozitivă este un proces de verificare a comportamentului corect în conformitate cu cerințele tehnice și documentația. Testarea pozitivă este efectuată pentru a se asigura că sistemul face exact ceea ce se așteaptă.

Testare negativă este un proces de verificare a comportamentului incorect. Printr-o astfel de testare, putem afla că sistemul poate face față situațiilor neașteptate.

Testare pozitiv-negativ

Pentru a efectua testarea software-ului, trebuie să aveți intuiție sau instinct de vânătoare. Un specialist în testare este o persoană versatilă care poate efectua atât analize de afaceri, cât și testare.

Testerii verifică dacă procesul este efectuat corect: dacă respectă cerințele tehnice și scenariile de testare. Efectuarea separată a testelor pozitive și negative va dura mai mult decât efectuarea lor simultan. Acest lucru se datorează faptului că există două iterații de testare.

La urma urmei, cu cât ora X se apropie, cu atât timpul trece mai repede și sarcinile trebuie finalizate mai repede, defectele remediate, cerințele de afaceri (care pot varia) aplicate și multe altele făcute. Termenul limită este cel mai tare moment!

Separarea testelor negative și pozitive este pur și simplu contrară naturii testerului! Sarcina sa este de a verifica sistemul pentru toate acțiunile posibile ale utilizatorului final.

Oamenii sunt în general ilogici și pot cauza probleme în software. Testarea negativă va ajuta la evitarea problemelor.

Aaaaand... Aceasta este ultima intrare din serie! Este cea mai scurtă, cea mai simplă și constă aproape în întregime din povești reale. Dacă se poate - prost și amuzant. Există chiar și un videoclip filmat special pentru înregistrare chiar în momentul scrierii. Proaspăt, domnule. Din păcate, nu m-am gândit să fac o captură de ecran a mesajului despre prăbușirea clientului Youtube; A căzut chiar la încărcarea videoclipului care a fost inserat în articol. Bine, să fie ecranul meu de blocare.

La începutul testării, indiferent dacă este un proiect nou sau care ar trebui îngropat, în general este întotdeauna clar de unde să începem. Cu excepția cazului în care, desigur, până la începutul testării, niciuna dintre verigile din lanț nu funcționa corect. De obicei, testerii citesc cerințe și alte documente cu nume non-rusești, cum ar fi „BEC”, „ESArchi” și „User Story” și își dau seama cum să scrie un caz de testare, astfel încât să verifice execuția tuturor acestor documente. Toate acestea sunt clare la suprafață și nu are rost să ne gândim la el. Dar există și comportamentul Android în sine, de care uneori nu numai analiștii, ci chiar arhitecții și unii dezvoltatori nu sunt conștienți. Și amintindu-ne că numai cu cele personalizate, apar destul de multe astfel de funcții. Și nu mai vorbesc de scenarii stresante când nu există memorie sau bateria este scoasă brusc (am întâlnit odată indignarea unei persoane la terminalul GNU/Linux pentru că nu afișează parola la intrare, dar are tastatura buggy). și nu înțelege dacă introduce parola sau tastatura nu funcționează din nou), ci despre comportamentul standard al personalizării Android și chiar despre comportamentul inerent AOSP. Adică, comportamente standard ale sistemului care pot afecta negativ produsul testat. Așa-numitele scenarii negative.

Voi descrie pe scurt câteva scenarii negative și voi încerca să dau exemple specifice.

• Probleme de comunicare. Cel mai simplu exemplu este modul Fly. De exemplu, aplicația de note Google Keep fie nu a fost testată în modul avion, fie erorile găsite nu au afectat lansarea. Este foarte ușor să reproduci problema:
• Activați modul avion
• Atingeți linia Ia o notă...
• Pe ecranul care apare, efectuați acțiunea Ștergere
• Bucură-te de animația cadru cu cadru a mișcării notelor salvate anterior

Pe lângă Fly Mode, există o conexiune instabilă cu pierdere de pachete, o conexiune foarte lentă, porturi închise prin care rulează aplicația ta și prezența unei conexiuni Wi-Fi, dar fără acces la Internet.

• Nu există acces la magazinul de aplicații. De exemplu, pentru a testa achizițiile în aplicație, aveți nevoie ca ansamblul să fie postat într-o secțiune specială a magazinului. Dacă nu există, sau dacă nu este aceeași versiune (vorbim despre codul versiunii - versiunea internă), atunci nu veți testa achiziția. Dacă un utilizator pleacă în vacanță în China, unde conexiunea la Google Play este foarte tristă, nu ar trebui să cadă licența pentru care a plătit bani.
• Operarea aplicației cu permisiuni limitate, dacă Nivelul API țintă este mai mic decât 23, adică mai mic decât Android 6, și când versiunea API este 23 sau mai mare. În primul caz, aplicația este moștenită, dar permisiunile pot fi în continuare eliminate. În al doilea caz, va începe să primească noi excepții pe care nu le cunoștea înainte.
• Modul de economisire a bateriei. Implementarea atât a Doze, cât și a App Standby, precum și a implementărilor alternative ale producătorilor talentați alternativ precum Samsung (și STAMINA de la Sony în prima versiune), când totul este implementat teribil de greșit, dar trebuie să trăiești cu asta. Este permis ca o aplicație să nu efectueze verificări la timp, să nu trimită statistici, să nu actualizeze datele. Dar nu este acceptabil să blocați, să blocați sau să nu finalizați niciodată sarcinile planificate.
• Schimbarea datei, orei, fusului orar. Oamenii pot zbura în vacanțe și călătorii de afaceri în alte țări în care fusul orar este diferit. Dacă avionul traversează meridianul 180, atunci utilizatorul poate ajunge „în ieri” din punctul de vedere al aplicației.

  O poveste adevărată a eșecului. Controlul parental din KIS pentru Windows a apărut în versiunea 7.0 în 2006. În același timp, produsul avea încorporat un agent de știri, deloc asemănător cu ceea ce este acum. S-a presupus că prin ea vor fi trimise diverse știri despre amenințări, tot felul de „ce este nou” și altele asemenea. A existat o eroare în versiunea de lansare, care a fost deja instalată de utilizatori. Dacă setați ora din Windows înainte de începerea licenței, protecția a fost dezactivată. Strict vorbind, non-administratorii nu pot schimba ora, dar acum 10 ani companiile nu monitorizau în mod special drepturile utilizatorilor și fiecare contabil de acolo avea un administrator local. Unul dintre clienții noștri din micul său birou a configurat controale parentale, astfel încât utilizatorii să nu poată naviga pe internet decât pe site-uri autorizate. Drakonowski a configurat și a protejat prin parolă setările. Totul a funcționat bine până când știrea a fost trimisă agentului de știri încorporat că era timpul să se actualizeze la noua versiune 7.0.1 care, printre altele, a remediat o eroare care a cauzat dezactivarea protecției atunci când ora a fost schimbată înapoi. înainte de începerea licenței. Utilizatorul a citit știrea, s-a bucurat și a dezactivat protecția folosind metoda propusă. Câteva zile mai târziu, această poveste de la el a apărut pe popularul bash.org.ru de atunci. De atunci, știri de acest fel nu au mai fost primite de utilizatori.

  Și să nu credeți că nu face astfel de greșeli. Amintiți-vă povestea cu iOS care s-a întâmplat anul acesta, deși au trecut doar 3 luni de la începutul anului ( Notă: da, aceasta este o prelegere destul de veche, îmi doream să o postez de mult timp). Telefoanele sunt oprite dacă setați ora mai aproape de începutul calculului timpului Unix. Și cum a remediat Apple această eroare? Ei au interzis schimbarea orei mai mult decât data critică, ceea ce NU a fost o remediere a problemei. Atacatorii au început să-și configureze punctele Wi-Fi cu nume care se găsesc de obicei în tot felul de McDonald's și transmit timp fals prin ele. Dispozitivele s-au conectat automat la astfel de puncte și au detectat servere NTP de la care au solicitat ora. Apple pur și simplu nu s-a asigurat că iOS nu folosește servere NTP false. Astfel, iOS a fost din nou reconstruit.

• Schimbarea localizării sistemului și a limbii interfeței. Utilizatorul are dreptul de a schimba limba sistemului de o sută de ori pe zi și nimeni nu îi poate interzice acest lucru. Sarcina testatorului este să se asigure că produsul, în primul rând, răspunde corect la aceasta (schimbă automat limba în cea dorită) și, în al doilea rând, nu se blochează deloc. În plus față de local, utilizatorul are dreptul de a schimba fonturile și fonturile, alegându-le pe cele pe care îi place să le citească. Aplicația nu ar trebui să se destrame dacă utilizatorul face modificări rezonabile.
• tapjaking. Am menționat acest lucru chiar în prima prelegere. Permiteți-mi să vă reamintesc că aceasta este o interceptare a atingerilor primite de activitatea aplicației A, în timp ce utilizatorul încerca să ajungă la aplicația B. Pur și simplu, activitatea aplicației A este transparentă. Aceasta nu pare o soluție sigură de la Google, dar așa funcționează aplicațiile de control al luminozității și al temperaturii culorii pe dispozitive. Utilizatorii găsesc astfel de aplicații convenabile și, deoarece Android le permite să funcționeze fără root, acest lucru trebuie luat în considerare. De exemplu, dacă aveți o aplicație care folosește un cod sau, să zicem, o imagine pentru autorizare, trebuie să utilizați protecția împotriva tapajului, de exemplu, setați filterTouchesWhenObscured la true.
• Apel direct la Activitate. Am spus deja asta, dar hai să o repetăm. Activitățile sunt unul dintre punctele de intrare în aplicație. Este destul de acceptabil să existe mai multe activități diferite care pot apela aplicații externe, nu știi niciodată de ce. Acestea vor fi activități de export. Dar se poate ca, pentru a apela o activitate, trebuie să-i treci parametri. Și o aplicație terță parte nu le va transfera. În cel mai bun caz, utilizatorul va vedea un fel de ecran strâmb, în ​​cel mai rău caz, aplicația dvs. se va bloca. Deci, ca să spunem așa, nu ar trebui să-ți arăți fundul gol afară în mod inutil. În mod implicit, indicatorul exportat este setat la adevărat și, dacă sunteți sigur că aplicațiile externe nu ar trebui să le apeleze, ar trebui să îl setați la fals. Ei bine, testerul trebuie să verifice cum se va comporta aplicația dacă activarea ei este apelată din alte aplicații.
• Ucigaș de sistem. În general, se numește OOM Killer - Out Of Memory Killer. Sistemul începe KILLING dacă aplicația cu care utilizatorul interacționează în acest moment anume nu are suficientă memorie pentru a funcționa. Desigur, ucigașul nu este prost, se supune anumitor algoritmi, alegând ținte (de exemplu, sistemul va ucide cu ușurință serviciul de fundal, dar va salva serviciul de prim-plan până la ultimul; serviciul de prim-plan este de obicei cel care își desenează pictograma în zona de notificare, de exemplu - un jucător ), dar acesta este esențialul. De regulă, OOM Killer nu este foarte agresiv pe dispozitivele moderne. În prezent, memoria este setată la un gigaoctet și mai mult. Dar acest lucru nu se aplică pentru jocuri. Jocurile sunt atât de grele, mănâncă atât de multă memorie încât, indiferent cât de mult ai pune, tot nu va fi suficient. Și, în general, cu cât pun mai multă RAM în dispozitive, cu atât aplicațiile vor fi mai grase, iar jocurile vor fi cele mai grase. În același timp, vor rămâne la fel de plictisitoare și inutile.

  Concluzia este că produsul dvs. este garantat să se încadreze în OOM Killer. Treaba ta este să te asiguri că nu iese nimic rău din asta și că produsul se ridică de îndată ce aplicația ssbbw este lovită de sistem (dacă produsul necesită acest lucru, desigur). Și sistemul va face acest lucru cu prima ocazie, nu va permite unui astfel de ssbbw să trăiască în fundal.
  O altă concluzie este că nici aplicația dvs. nu ar trebui să fie un ssbbw. Orice scurgeri trebuie detectate de dezvoltator înainte de a scrie codul real. Testele de performanță ar trebui să aibă cu siguranță scenarii de testare când maimuța generează o mulțime de evenimente. Dacă codul este scris bine, colectorul de gunoi va elibera memorie și sistemul nu va opri procesul de aplicare. Dacă totul este rău și aplicația se scurge din toate crăpăturile, sistemul o va trage. Desigur, va decola din nou după aceasta și nu va mai fi memorie, deoarece după uciderea procesului, colectorul de gunoi curăță totul, dar dacă momeala a arătat că aplicația se scurge în testul său în 15 minute, atunci utilizatorul va experimentați aceste scurgeri chiar și mai târziu, dar toate acestea se vor arăta în mod egal.

• Big Data. Dacă aplicația dvs. funcționează cu datele utilizatorului, fiți pregătit pentru ca utilizatorul să alimenteze ceva foarte mare fără să vă gândiți. De exemplu, eu, ca utilizator, mă aștept pe deplin ca clientul Youtube să-mi descarce videoclipul, indiferent cât de greu este acest videoclip. Mă aștept ca arhivatorul să se potrivească în orice adâncime a arhivei, care cântărește de 5 ori mai mult decât întreaga memorie RAM disponibilă a dispozitivului. E bine. Dacă cineva vă spune că „nimeni nu va alimenta niciodată fișiere atât de mari”, atunci cel mai probabil vorbitorul nu este un dezvoltator foarte bun.
• Cea mai stupidă și, prin urmare, amuzantă situație care face ca aplicația să funcționeze defectuos, chiar să se blocheze, este una simplă rotirea ecranului. Câte căderi similare au fost identificate în timpul etapei de testare! Mai ales dacă apare un fel de pop-up. La ferestre pop-up, un tester experimentat începe imediat să întoarcă telefonul! De asemenea, s-a întâmplat ca întreaga echipă să testeze produsul numai pe telefoane, unde rotația ecranului pentru aplicație a fost blocată. Și apoi, când tabletele au fost livrate, s-a dovedit că aplicațiile de pe tablete s-au blocat pe aproape fiecare ecran. Dar pentru că fragmente. Au existat diferite interfețe pe ecran și pe telefon, iar utilizarea incorectă a fragmentelor a dus la un rezultat trist.
• Apăsări duble, triple. Din anumite motive, unii oameni cred că nimeni nu face atingeri multiple pe elementele interfeței. Dar nu! Da! Și nu pentru că testez, ci pentru că s-ar putea să am în mâini un telefon vechi pe Android 4.0, care abia se poate mișca, iar ecranul său nu este foarte receptiv. Este posibil să nu fie clar dacă a existat un clic sau nu și rezultatul atingerilor duble. Nu pentru că sunt „duble” (în sensul nu cele care se fac cu un interval mai mic de o secundă), ci pentru că au fost două sau mai multe dintre ele în timp ce aplicația era „gândită”. De exemplu, în timp ce forma o listă cu multe elemente.
• Una dintre caracteristicile convenabile ale Android 6, dacă nu este suficient de testată, duce la rezultate groaznice. Până la punctul în care utilizarea sa este interzisă în mod explicit în aplicație, ceea ce, deocamdată, este permis de Google. Această caracteristică - backup și restaurare din backup. Apropo, nu este nou, backup a apărut în Android 2.2, dar nu cunosc o singură aplicație care să folosească acest bun.
  Crearea unei copii de rezervă și restaurarea acesteia în sine nu este înfricoșătoare. Problemele încep dacă produsul utilizează o legătură cu identificatorul dispozitivului și identificatorul instalării. Chiar și în cadrul aceluiași dispozitiv, acest lucru poate duce la probleme, dar restaurarea dintr-o copie de rezervă este permisă de Android însuși pe orice dispozitiv cu Android 6 la bord: sistemul face copii de rezervă ale aplicațiilor de pe dispozitivul A, iar utilizatorul cumpără dispozitivul B și le restaurează pe toate. pe ea. Și aceste aplicații funcționează simultan pe două dispozitive, deși au identificatori diferiți. Dacă aceasta este o aplicație client-server, în care toată comunicarea se face folosind token-uri, există o mulțime de probleme aici.

  Un exemplu de luptă este aplicația cool Talon pentru Twitter. Nu am resetat dispozitivul de foarte mult timp și, prin urmare, nu știu dacă autorul a remediat această eroare. Când i-am raportat-o, mi-a spus de ce a apărut eroarea (chiar dacă știu deja de ce!), dar nu a spus dacă va corecta comportamentul. În general, această aplicație are un fel de asistent de instalare care vorbește despre capacitățile acestui client Twitter, solicitând permisiunile necesare pe parcurs. Totul este clar conform ghidurilor Google, chiar din note. Când vrăjitorul de configurare a fost finalizat și au fost primite permisiunile necesare, a fost ridicat un semnalizare despre acest lucru pentru a nu fi nevoie să parcurgeți din nou configurarea de fiecare dată. Și aplicația a fost susținută împreună cu acest steag. Împreună cu el a fost restaurată. Deși în mod implicit, permisiunile sunt dezactivate pentru toate aplicațiile de tip nou (adică nivelul targetApi >= 23). Lansați aplicația, dar nu funcționează corect. Deoarece nu există nicio verificare pentru disponibilitatea permisiunilor, toate verificările au rămas în vrăjitorul inițial de configurare, care nu a pornit deoarece marcajul a fost setat la „vrăjitorul a fost deja trecut”. În plus, după lansare, clientul nu a încărcat tweet-uri, dând o lovitură Twitter în sine. Pentru că jetonul îngropat nu era valabil pe noua instalare și a fost necesar să se solicite unul nou, iar această solicitare a fost făcută și în asistentul de instalare la primul pas!

• În Android, pornind de la versiunea (dacă memoria îmi servește corect) 2.2.1, a devenit posibil să mutați unele date aplicației pe cardul de memorie. Încet, această caracteristică a început să fie eliminată, până când în Android 6 Google i-a dat o a doua viață, îmbunătățind-o semnificativ. Dacă producătorul dispozitivului în mod personalizat nu a rupt comportamentul AOSP în această situație, atunci de îndată ce Android detectează cardul de memorie, acesta oferă posibilitatea de a alege dacă utilizatorul îl va scoate uneori sau nu. Dacă utilizatorul spune că nu intenționează să o dezactiveze, atunci Android formatează cardul în sistemul său de fișiere și îl conectează ca parte a memoriei principale, permițând instalarea aplicațiilor acolo. Și iată câteva capcane:
• Dacă aplicația folosește căi hardcoded, atunci totul este pierdut. Dar acesta este un gust atât de prost încât sper să nu o facă nimeni.
• Dacă aplicația a cerut sistemului căi când a fost lansată prima dată și le-a stocat pentru totdeauna, atunci va fi exact la fel ca în cazul celor codificate

• Pe măsură ce aplicațiile sunt actualizate, utilizatorii vor primi versiuni noi din magazinul de aplicații și le vor instala peste cea existentă. Deoarece verificarea actualizării aplicației la noua versiune- script obligatoriu. Într-o situație normală, totul ar trebui să fie bine, dar atunci când trebuie să susțineți multe dispozitive specifice cu comportamentul lor specific, formatul setărilor se poate schimba. Acest lucru nu duce aproape niciodată la blocări dacă codul este scris mai mult sau mai puțin eficient și gestionează diverse excepții. Dar pur și simplu pierderea unora dintre setări este deja rău. De exemplu, am avut o situație în care utilizatorii au petrecut luni de zile creând o listă antispam, blocând un număr de taxiuri, bănci și servicii de colectare, iar apoi, după actualizarea la o nouă versiune, toate listele s-au pierdut. Tocmai pentru că s-a schimbat formatul setărilor și tocmai aici, tocmai în acest loc, setările nu au fost citite de noua versiune a produsului.
• Pe lângă actualizarea produsului la o versiune nouă, există o opțiune mai rară, dar mult mai hardcore - actualizarea firmware-ului în sine pentru o versiune nouă, dar cu un produs funcțional. Voi da două exemple, dintre care unul a fost deja spus.
• Actualizarea obișnuită de securitate pentru Android 5.1, care a preluat și a dezactivat funcțiile pe viață ale sistemului de operare pe care le folosea aplicația
• După actualizarea Android 4.4 la Android 5.0, căile aplicațiilor instalate s-au schimbat. Anterior, aplicațiile instalate erau stocate într-o cale familiară (/data/app/com.package.name.apk). Unul dintre produsele noastre în scopuri de securitate internă verifică pentru a vedea din ce cale este accesibilă aplicația protejată și dacă s-a schimbat. A sosit o actualizare la 5.0 și căile absolute s-au schimbat pentru aplicațiile deja instalate (data/app/com.package.name/base.apk). Produsul a sunat un semnal de alarmă că aplicația a fost compromisă. Corectat, desigur.

Ei bine, asta e tot deocamdată. Acum scriu un raport despre probleme care sunt specifice doar pentru anumite versiuni de Android, doar pentru anumite firmware, doar pentru anumite dispozitive. Deci nu opriti! Cu toate acestea, știți deja unele dintre ele - sunt descrise direct în această serie de postări.
Pa! Pa!

De ce fac oamenii teste psihologice? Desigur, fiecare are propriile motive. Cineva vrea să se înțeleagă pe sine și „să înțeleagă cine sunt eu”. Cineva vrea să-și confirme opinia existentă despre caracterul său. Unii oameni își ucid timpul liber și se distrează. Dar toată lumea, deși adesea fără să-și dea seama, adică pur și simplu, vrea să audă ceva bun despre ei înșiși. Pentru ce? Da, pentru că asta ridică starea de spirit. Testul pe care ți-l sugerăm are unicul scop de a aduce un pic de pozitivitate în starea ta actuală. De fapt, acesta nu este deloc un test, ci ceva ca o predicție pozitivă. Și ele, după cum știți, se împlinesc foarte des!

06.10.2018 16947 +67

Vrei să știi cum vă percep alții numele? Serviciul online gratuit de analiză fonosemantică vă permite să aflați cum este perceput un anumit cuvânt la nivel subconștient. Cu ajutorul acestuia, puteți, de exemplu, să alegeți un nume pentru un copil sau un nume pentru o companie.
Află cum te vei simți într-o lună! Chiar acum, pe site-ul nostru, vă puteți calcula bioritmurile absolut gratuit. Pe baza rezultatelor calculelor, veți primi recomandări personale și un program de modificări ale bioritmurilor pentru luna următoare.
Teste psihologice populare Un număr mare de teste psihologice populare pentru fiecare gust. Pentru bărbați, pentru femei, ezoteric, profesional... Și toate acestea sunt online, gratuite și fără înregistrare!

· Testarea fumului. În această etapă, este necesar să se verifice dacă sistemul funcționează deloc (dacă funcționează corect, tratează corect erorile etc.). Acest lucru se face pentru a înțelege dacă aplicația este potrivită pentru teste ulterioare sau dacă inițial funcționează incorect.

· Testare „pozitivă””. În această etapă, este necesar să se verifice ieșirea aplicației atunci când primește datele de intrare „corecte”.

· Testare „negativă”. Aceasta este etapa finală a testării inițiale. Este necesar să vedem cum se comportă aplicația atunci când furnizează date „incorecte” ca intrare. Dacă o astfel de opțiune este descrisă în specificație (și ar trebui descrisă), atunci este necesar să comparați rezultatul așteptat cu cel obținut.

În etapa studierii specificației, se determină când și cum ar trebui să funcționeze aplicația în sine, când și cum ar trebui să reacționeze la erori, adică modul în care sistemul sau modulele sale ar trebui să reacționeze la datele incorecte sau la comportamentul incorect al utilizatorului.

Documentația face posibilă înțelegerea principalelor etape ale testării unei aplicații: unde și cum ar trebui să funcționeze corect aplicația, cum să gestionați situațiile de eroare: emiteți mesaje de eroare, scrieți o eroare în fișierul jurnal de operațiuni, opriți execuția etc.

1) verificați cum funcționează aplicația atunci când primește intrare corectă;

2) dacă totul funcționează corect, așa cum este descris în caietul de sarcini, următorul pas este verificarea valorilor limită (valorile minime și maxime ale datelor corecte);

3) verificați funcționarea aplicației atunci când introduceți date care nu se încadrează în intervalul de valori acceptabile (verificarea procesării valorilor de intrare incorecte).

Primele două paragrafe descriu un proces numit testare „pozitivă”.

« Pozitiv» testarea– aceasta este testarea pe date sau scenarii care corespund comportamentului normal (standard, așteptat) al sistemului testat. Scopul principal al testării „pozitive” este de a verifica dacă sistemul poate face ceea ce a fost conceput pentru a face.

« Negativ» testarea– este vorba de testare pe date sau scenarii care corespund unui comportament anormal al sistemului testat, precum și emiterea de diverse mesaje de eroare, situații excepționale, stări „exorbitante” etc.

Scopul principal al testării „negative” este verificarea rezistenței sistemului la influențe de tip „negativ”: verificarea unui set de date incorect, verificarea procesării situațiilor excepționale (atât în ​​implementarea algoritmilor software în sine, cât și în logica regulile de afaceri), etc.

Testele „pozitive” și „negative” ar trebui să fie precedate de lucrări de efectuat „ fum» testarea, în timpul căreia se efectuează testarea rapidă și superficială a funcționalității celei mai critice pe scenarii simple, adică tipice, cu un minim de verificări („astfel încât să nu fie fum”). Poate fi efectuată atât pe date „pozitive” cât și „negative”.

Definiți testele funcționale, de sarcină, de stres și de stabilitate.

Testare funcțională constă în testarea sistemului în vederea verificării fezabilității cerințelor funcționale, i.e. capacitatea programului, în anumite condiții, de a rezolva problemele necesare utilizatorilor. Cerințele funcționale definesc ce face programul și ce probleme rezolvă.

Testare de sarcină.În general, utilizarea așteptată a unei aplicații este simulată prin emularea muncii mai multor utilizatori în același timp. O astfel de testare este cea mai potrivită pentru sistemele multi-utilizator și în special pentru cele care utilizează arhitectura client-server (de exemplu, servere Web).

Testarea de stres– un tip de testare software care evaluează fiabilitatea și stabilitatea unui sistem atunci când limitele de funcționare normală sunt depășite. Testarea de stres este necesară în special pentru software-ul „critic pentru misiune”. Testarea la stres este de obicei mai bună la detectarea calităților precum robustețea, disponibilitatea și gestionarea excepțiilor unui sistem sub sarcină mare decât ceea ce este considerat a fi indicativ al comportamentului corect în condiții normale.

Testare de stabilitate. Acest tip de testare constă în verificarea funcționalității programului în timpul funcționării pe termen lung cu nivelul de sarcină așteptat. Înainte de a începe să verificați funcționarea sistemului la sarcini maxime și critice, este necesar să verificați funcționarea acestuia în condițiile specificate în cerințele funcționale, adică să rulați sistemul în modul normal pentru o lungă perioadă de timp. Obiectivul principal al unei astfel de teste este de a detecta scurgerile de memorie, precum și de a verifica dacă viteza de procesare și timpul de răspuns al aplicației au fost aceleași la începutul și la sfârșitul testului.

Întrebări pentru subiectul 18