A pontok vagy a kézikönyv hibákkal való visszaélése az Internet indításakor - i rész
Oldal 2/2
- MI A BAG
- A DECODÁLT VIZSGÁLAT CÉLJA
- A TESTSEYSOV létrehozásának művészete
- FEJLESZTÉSI CIKLUS
- A Baga definíciója
- Három életkörülmény és jólét Baga
- Mi a tesztelés?
- A várható eredmény forrása
- Funkcionális hibák és hibajavítások
A kirekesztett harmadik állam logikai törvénye szerint bármely dolog A vagy nem-A. A harmadik nem adódik, azaz nem. ha van egy Breguet karóra az 5-ös számra, akkor bármelyik dolog ebben a világban lesz vagy a Breguet óra az 5. szám után, vagy valami más.
Képzeljünk el egy szállítószalagot, amelynek végén állunk. A szállítószalag övje mozog, és előtte egyenként jelenik meg. A feladat egyszerű - számolni kell a Breguet órák megjelenését az 5-ös számon, és azt mondani, hogy "hiba", amikor bármely más elem nem jelenik meg.
Nem nehéz kitalálni, hogy az olyan elemek, mint a kefir csomag, a "Glory" ébresztőóra, az N. elnökjelölt választási ígéreteivel ellátott füzet lesz számunkra hiba.
Tovább. Vegyük fontolóra, mi egyesíti a következő helyzeteket.
Ha felemelkedünk a sült tojások felett, a három pont mindegyikében, és a nőkről, a kártyákról és a bortól elvonatkoztatva, látni fogjuk, hogy a teljes az eltérés a ténylegestől a várttól.
- Várható eredmény - a lány főzhet.
A tényleges eredmény a reggeli nélkül reggel. - A várt eredmény a tesztelés ismerete.
A tényleges eredmény a főzés ismerete. - A várt eredmény a rántotta.
A tényleges eredmény egy reggel, reggeli nélkül.
meghatározása bug
Tehát a hiba a tényleges eredmény eltérése a várt eredménytől.
A kizárt harmadik törvényének megfelelően hiba lép fel minden tényleges eredmény jelenlétében, ami eltér a várttól.
Három életkörülmény és a jólét a hiba
A konkrét hiba akkor él és virágzik, ha mindhárom feltétel egyszerre teljesül:
- A tényleges eredmény ismeretes;
- Várható eredmény ismert;
- Ismeretes, hogy az (1) bekezdés szerinti eredmény nem egyezik meg a (2) bekezdés eredményével.
A nap tippje: minden olyan alkalommal, amikor egy olyan helyzet merül fel, amely nem egyezik meg a tényleges és a várható, - a tényleges szó bélyegzője a "hiba" szóval. Fokozatosan megszokottá válik és reflexiává válik. A mentális tréning számára nem számít, mennyire apró, alacsony és pillanatnyi elvárásai vannak, a legfontosabb az automatizmus megszerzése.
Példák a hibákra az életben:
- A szendvics leesik.
- A cipők és a beszélők sokkal nagyobb valószínűséggel emelkednek, mint a szerény őszinte munkások.
- A szép megjelenés és a kígyó lényege nem egyezik.
- A papagáj a tulajdonos szavait legrosszabbul reprodukálja.
- Orosz autók.
- Cats Hippo a "Master és Margarita" filmben V. Bortko.
Mi a tesztelés?
Minden tesztelés hibák keresése. Függetlenül attól, hogy egy új gyümölcscentrifuga tesztet hajtottunk végre, akár egy barát viselkedését, akár önmegvalósítással foglalkozunk - hibákat keresünk. A hibák a következők:
- Tudni fogjuk (vagy már tudjuk) a várt eredményt;
- Megtanuljuk (vagy már tudjuk) a tényleges eredményt;
- Összehasonlítjuk az 1. tételt és a 2. tételt.
Mint látható, mindannyiunknak már teszter például különféle tudatos és a tudattalan által elvégzett vizsgálatokról minket, és velünk szemben szerves részét képezik az élet, csak mielőtt szakszerűtlen megrázta a fejét, és adta ki rants a igazságtalanságokat a világ, de most abban az esetben illesztési a tényleges és várható mi zsálya mosolyogva nézett amatőrök squishing orrukat a moszkvai szél, és csendesen, de szignifikánsan (Don Corleone) azt mondja: „Ta-ah-ig, egy másik bug”.
A helyes megközelítés szemléltetése érdekében példaként idézem egyik barátaimnak, aki a tézis bizonyításainak egész rendszerét felépítette, hogy az emberek és számítógépek ugyanabban a modellben lettek létrehozva. Érvelése alapja az volt, hogy mindkettő fizikai héjat (testet / vasat) és egy immateriális összetevőt tartalmaz, amely irányítja (lélek / PO). Ennek megfelelően felhívta a testtörzsek betegségét a mirigyben, és problémákat okozott a szoftverben található fejveszteségekkel kapcsolatban, és nagyon sajnálja, hogy a szoftver a világot kezelő emberek számára elsősorban hibákból áll.
Most emlékszünk arra, hogy van számítógépes szoftver, és meg kell tanulnunk, hogyan teszteljük.
A tényleges eredmény többé-kevésbé egyértelmű: meg kell hoznia a rendszert, és meg kell látnia, mi történik.
A várt eredményes helyzet bonyolultabb.
A várható eredmény forrása
A várt eredmény fő forrása:
Az első és a negyedik szerepkörre vonatkozó specifikáció nem hiba, hanem hangsúly a tesztelő specifikációjának:
A specifikáció a programozó és a tesztelő számára ugyanúgy fontos, mint a kommunista Központi Bizottság plenumának állásfoglalása.
A specifikáció egy olyan eszköz, amellyel felszabadíthatja a minőségi terméket, és fedheti le a hátát (az eredeti hangokon, mint például a CYA vagy fedezheti a seggét).
Szóval, milyen állat ez?
Specifikáció (vagy spec - olvasható "spec." Ezt követően a férfi nemi nyelven) - ez egy részletes leírás a szoftver működésének módjáról. Ez nem több, sem kevesebb.
A legtöbb esetben egy hiba eltér a specifikációtól (olyan vállalatokról beszélek, amelyekben a specifikációk elvben léteznek és használják őket).
19. pont a spec # 8724 "Új felhasználó regisztrálásakor": "A" Név "mezőnek kötelezőnek kell lennie. Ha a felhasználó elküldi a regisztrációs űrlapot a megadott mező kitöltése nélkül, hibaoldalt kell megjeleníteni. "
Általánosságban minden egyszerű:
- a tesztelő a regisztrációs űrlappal ellátja az oldalt;
- kattintson a "Regisztráció" linkre;
- kitölt minden szükséges mezőt, kivéve a "Név" mezőt;
- nyomja meg a "Regisztráció" gombot.
Ha nem jelenik meg hiba, és a regisztráció megerősítést nyer, akkor ez az igazság pillanat, és be kell jelentenie egy hibát (fájl hiba).
Ha hiba jelenik meg, akkor egy ideig lenyugodhat egy ideig. Meg fogjuk érteni, miért lehet csak egy ideig megnyugodni, amikor a regressziós tesztelésről beszélünk.
Funkcionális hibák és hibák
Tegyük fel, hogy a hiba nem látható, és van egy klasszikus esetben egy funkcionális hiba (funkcionális hiba vagy hiba rendes), azaz. bug, táplálta a kód tényleges munkája és a funkcionális specifikáció közötti ellentmondást.
Ha alaposan olvassa el a 19.a pontot, akkor nem lehetett észrevenni (vicc), hogy nem világos, hogy mi legyen a hibaüzenet, pl. valójában a döntés megmarad a programozónak, és biztosítja, hogy adott esetben a kód adja ki:
- Nem tájékoztató jellegű "Hiba" üzenet, és a felhasználó félrevezetővé teszi a rosszat, vagy
- tájékoztató üzenet "Kérjük, adja meg a nevét, és kattintson a" Regisztráció "gombra»
és mindenképpen formálisan igaza lesz, mivel a specifikáció nem részletezi a hiba szövegét.
Egyébként néhány évvel ezelőtt volt olyan eset, amikor az amerikai börtönök számára kifejlesztett speciális szoftverek programozói elhagyták a gomb "működő" nevét, és a börtönök annyira kedvelték az ötletet, hogy nem kértek semmit a helyesre. A gombon szereplő felirat: "engedje el a söpredék" szót.
Általánosságban elmondható, hogy a specifikációnak van egy problémája, hiszen elvárjuk (vagy legalábbis elvárható), hogy részletesen meg fogják adni a hiba szövegét a specifikációban, de valójában nincsenek ott. Így írunk - "hiba a specifikációban" (spec bug).
By the way, itt vannak a lehetőségek a fejlõdés a helyzet a probléma spec:
- Valószínűleg a programozó továbbra is informatív hibaüzenetet fog írni. Az Ön vállalkozásának e-mailt kell küldenie a gyártónak (az internetes cég gyártója nevezik elvtársaként, aki létrehozza a tortát), hogy beírja a programozó által már írt szöveget a 19.a. pontban.
- Ha a programozó a józan észzel vagy a cég által elfogadott szabványokkal ellentétesen ír valamit, jelezzen hibát.
- Lehet, hogy nem vette észre a problémát a specifikációban, és nem vette észre, hogy a programozó hogyan írta a hibajelentést, ellentétben a józan észzel vagy a vállalat által elfogadott standarddal.
By the way, itt két fontos politikai szempontból fontos dolog:
- Általános szabály, hogy a munka egy startup - egy egyedülálló tapasztalat, hogy a kemény munka kombinálva az alkotás örömét, nyugodt légkörben (például, már sok éve, hogy menjen dolgozni rövidnadrágban), és mások is szép, vicces emberek. De vannak vészhelyzetek (például a munkát időben, vagy nem történik minőségileg), és amikor meghatározzák a „ki a hibás” és a „mit kell tenni vele,” sok a kollégák veszti aranyos, vicces emberek és aktívan kezdődik lógó kutyák tetején egymásra. És így, hogy az egyik ilyen kutyák nem akasztotta fel akkor, küldjön e-mailt, kivéve azokat, és a választ, és az ügy, kérjük küldje el az érdekelt felek számára. Hasznos azoknak az e-mail a jövőben - nos, nem hasznos - még jobb, különösen azért, mert nem kért kása, és jelenleg nyugodtan ülni és gyáva saját mappák és nem vár semmit ebből az életből.
- Mindenkinek meg kell tennie a saját munkáját, és felelősséget kell vállalnia munkája helyszínéért. Abban az esetben, ha a specifikáció rosszul működik, akkor jobb, ha riasztást küld e-mail küldéssel, mint feltételezni, hogy a szoftver hogyan működik.
Mielőtt befejezte a témát a várható és tényleges eredményekről, vegye figyelembe a várt eredmény egyéb forrásait, kivéve a specifikációkat.
ÉLVÉTI TAPASZTALAT
Amint Boris Slutsky alaposan megjegyezte: "Nem csak sört rákot és lakkot fogyasztunk." Tanultunk és dolgoztunk, szerettünk és gyűlöltünk, hittünk politikusoknak és nem figyeltünk a szülőkre, általában életmódot szerzett (ideértve a munkatapasztalatot is). Tehát ez a tapasztalat annyira hasznos a mi fekete kapcsolatunkban, hogy a hasznosság eszméjének tiszteletben tartására (a logikával és a józan észvel együtt) a Bevezetésben egy epigráfra tettem. Az a kérdés, hogy a szoftvertesztelés ugyanaz a tesztelés (amit folyamatosan), de csak a szoftverek tekintetében. És az a feladatom, hogy az internetes tesztelés alapfogalmait és gyakorlati eszközeit nyújtsam, és segítsek nekik abban, hogy integrálódjanak már meglévő ismereteihez - élettapasztalattal.
A KÖZÖS SZEMÉLY (az élet tapasztalatának gyermeke és ennek megfelelően a "hibák nehézsége" unokája)
Ez egyike a legfontosabb szövetségeseinknek, néha még egy specifikációval is. Például tesztel egy olyan webhelyet, ahol a felhasználó feltöltheti digitális fényképeit. Speck szerint a felhasználó csak egyszer tölthet fel egy fényképet. Mi van, ha 200 fotója van? Boldog lesz? Mit csináljunk? Helyesen: e-mailt írunk a [email protected], azzal a javaslattal, hogy a spektrumfunkcióba beillesztjük, amely lehetővé teszi a felhasználó számára, hogy digitális fényképeket töltsön tömegesen. By the way, ez a racionalizációs terv hibája hipokritailag nem hibaként nevezhető, hanem egy szolgáltatáskérelemnek (miközben egy ilyen fordítást leállunk).
Még a legjobb specifikáció is szükségessé teszi a finomítást. És mi van, ha egyáltalán nincs szelet? Válaszunk: kommunikáció. Kérjen tanácsot kollégáitól Tisztázza és megvitassa. Egy fej jó, de kettő jobb.
STANDARDS SZABVÁNYOK
Rendszerint a regisztráció után a felhasználónak visszaigazolással ellátott e-mailt kell kapnia. Ha a spec nem említi ezt az e-mailt, kérheti, hogy hozzáadja a bevett gyakorlat alapján.
STATISZTIKAI ADATOK
Megállapítást nyert, hogy az átlagos felhasználó türelmet veszít, ha a weboldal (weboldal) 5 másodpercen belül nem töltődik be. Ezeket az adatokat a teljesítményvizsgálat elvégzésével lehet elvégezni (a teljes rendszer vagy összetevő sebességének tesztelése). Amint az amerikaiak azt mondják: "A felhasználó csak egy kattintásnyira van a versenytársától" ("A felhasználó egy kattintás van a versenytársától"). A projekt sikere boldog felhasználó. Több mint 5 másodperc elteltével a weboldal átalakítása elvárási csarnokává alakul, ahol alig van bárki is.
Ez lehet például a főnöke véleménye.
Vegyük észre, hogy a bug (bug) szó szerint "bug" -ként vagy "bug" -ként fordul elő.
Most, ahogy ígértem, van egy kis történelem.