- Dūmu tests žargona failā
Wikimedia fonds. 2010 .
Skatiet, kas ir "Dūmu tests" citās vārdnīcās:
dūmu tests- lietvārds Noplūdes pārbaudes metode kanalizācijas caurulēs vai skursteņos, ieviešot blīvus dūmus, bieži izmantojot dūmu bumbu Galvenais ieraksts: dūmi … Noderīga angļu vārdnīca
dūmu tests- Tests veikts, lai noteiktu degšanas pilnīgumu … Automobiļu terminu vārdnīca
dūmu tests- 1. lietvārds a) Noplūžu pārbaude, kas saistīta ar dūmu iepūšanu caurulē vai caurulē. b) Jaunizveidotas elektroniskas iekārtas sākotnēja pārbaude, kas sastāv tikai no elektrības padeves, lai pārliecinātos, ka nav ārkārtīgu vadu… … Vikivārdnīca
dūmu pārbaude- ir termins, ko izmanto santehnikā, koka pūšaminstrumentu remontā, elektronikā, datoru programmatūras izstrādē, un izklaides industrija. Tas attiecas uz pirmo testu, kas veikts pēc remonta vai pirmās montāžas, lai sniegtu zināmu pārliecību, ka testējamā sistēma... … Wikipedia
dūmu pārbaude- bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Deutsch Wikipedia
Smēķēt- ir gaisā esošo cieto un šķidro daļiņu un gāzu kolekcija [SFPE rokasgrāmata par ugunsdrošības inženieriju], kas izdalās, kad materiāls tiek pakļauts... ... Wikipedia
testa komplekts- Programmatūras izstrādē testa komplekts, kas mazāk pazīstams kā validācijas komplekts , ir testa gadījumu kolekcija, ko paredzēts izmantot programmatūras testēšanai, lai parādītu, ka tai ir noteiktas darbības. Testu komplekts bieži… … Wikipedia
dūmu bumba- Dūmu bumba ir uguņošana, kas radīta dūmu aizdegšanās brīdī. Lai gan ir dūmus radošas ierīces, kas tiek nomestas no lidmašīnām, termins dūmu bumba tiek lietots, lai aprakstītu trīs veidu ierīces: # Dūmu bumba ir dobums, ķiršu... … Wikipedia
Dūmu un sanitārā pārbaude sākas tūlīt pēc nākamās projekta versijas izlaišanas. Daudziem jaunajiem testētājiem šis process šķiet absolūts haoss. Vai atpazini sevi? Tad šis raksts ir paredzēts jums. Tagad apskatīsim dūmu un veselības pārbaudes definīcijas, kā arī parādīsim atšķirību starp tām ar viegli saprotamiem piemēriem.
Dūmu pārbaude:
Dūmu testēšana tiek veikta, lai pārliecinātos, ka iegūtā konstrukcija ir piemērota pārbaudei. To sauc arī par nulles dienas čeku.
Tieši šāda veida pārbaude neļaus tērēt laiku. Loģiski, ka visas lietojumprogrammas pārbaudei nav jēgas, ja rodas problēmas galvenās iezīmes un kritiskās kļūdas nav novērstas.
Sanitārā pārbaude:
Sanitārā pārbaude tiek veikta izlaišanas stadijā, lai pārbaudītu lietojumprogrammas galveno funkcionalitāti. Viņi parasti netiek tālāk. Šāda pārbaude dažkārt tiek saukta par saīsinātu regresijas testēšanas versiju.
Kad atbrīvošana ir zem spiediena, rūpīgas regresijas pārbaudes ir gandrīz neiespējamas. Šajā gadījumā lielisku darbu veic saprāta pārbaude, kas pārbauda lietojumprogrammas galveno funkciju darbību.
Piemērs, lai labāk izprastu atšķirību starp dūmu un sanitārijas testēšanu:
Ir projekts, kuram ir plānota sākotnējā izlaišana. Izstrādes komanda izlaiž būvējumu testēšanai, testa komanda sāk darbu. Pati pirmā pārbaude ir piemērotības pārbaude. Jums ir jānoskaidro, vai varat strādāt ar šo versiju vai nē. Šī ir dūmu pārbaude. Ja komanda dod atļauju turpmākam darbam ar būvniecību, tā pāriet uz dziļākām testēšanas stadijām. Iedomājieties, ka būvei ir trīs moduļi: “Pieteikšanās”, “Administrators” un “Darbinieks”. Testa komanda pārbauda tikai katra moduļa galveno funkciju veiktspēju, neiedziļinoties detaļās. Tā būs veselības pārbaude.
Vēl dažas atšķirības starp dūmu un sanitārijas testēšanu:
- Dūmu testēšanu veic gan izstrādātāji, gan testētāji;
- Sanitāro pārbaudi veic tikai testētāji.
- Dūmu pārbaude aptver visas galvenās lietojumprogrammas funkcionalitātes no sākuma līdz beigām;
- Sanitārā pārbaude pārbauda tikai konkrētu lietojumprogrammas komponentu.
- Dūmu testēšana tiek veikta gan stabilās, gan nestabilās versijās;
- Salīdzinoši stabilai konstrukcijas versijai tiek veikta sanitārā pārbaude.
Kirils Fļagins, spēļu dizainers, kvalitātes nodrošināšanas vadītājs
Zīmēsim vasaras analoģiju ar šiem testēšanas veidiem. Pieņemsim, ka vēlaties iegādāties arbūzu. Dūmu pārbaude ir tad, kad to vizuāli pārbauda, skaties uz sloksnēm, saspiež, klauvē, novērtē. Ir meistari, kuriem šādi izdodas nopirkt patiešām garšīgu ogu. Veselības pārbaudē izgriež piramīdu augšpusē un pārbauda tās krāsu (kā vienu no sastāvdaļām), tajā pašā laikā nemaz nezinot, vai viss arbūzs tāds ir. Bet par griezuma daļu jūs esat pilnīgi pārliecināts.
Pēc nepieciešamo izmaiņu veikšanas, piemēram, kļūdas/defekta novēršanas, programmatūra ir atkārtoti jāpārbauda, lai apstiprinātu, ka problēma patiešām ir atrisināta. Tālāk ir norādīti testēšanas veidi, kas jāveic pēc programmatūras instalēšanas, lai pārliecinātos, ka lietojumprogramma darbojas vai defekts ir novērsts.
- Dūmu pārbaude(dūmu pārbaude)
- Regresijas pārbaude(Regresijas pārbaude)
- Būvējuma pārbaude(Būvējuma verifikācijas tests)
- Sanitārā pārbaude vai konsekvence/veselības pārbaude(Saprāta pārbaude)
koncepcija dūmu pārbaude nāca no inženierzinātnēm. Nododot ekspluatācijā jaunas iekārtas ("dzelzs"), tika uzskatīts, ka pārbaude bija veiksmīga, ja no iekārtas neizplūst dūmi. Programmatūras testēšanas jomā tā ir vērsta uz visu lietojumprogrammu moduļu virspusēju pārbaudi, vai tie darbojas un vai nav ātri atrasti kritiski un bloķējoši defekti. Pēc dūmu pārbaudes rezultātiem tiek izdarīts secinājums, vai tas ir pieņemts vai nē. instalētā versija programmatūra testēšanai, darbībai vai piegādei klientam. Lai atvieglotu darbu, ietaupītu laiku un cilvēkresursus, ieteicams ieviest dūmu pārbaudes testu scenāriju automatizāciju.
Regresijas pārbaude ir testēšanas veids, kura mērķis ir pārbaudīt lietojumprogrammā veiktās izmaiņas vai vidi(defekta novēršana, koda sapludināšana, migrēšana uz citu operētājsistēma, datubāze, tīmekļa serveris vai lietojumprogrammu serveris), lai apstiprinātu, ka esošā funkcionalitāte darbojas tāpat kā iepriekš (skatiet arī Sanitārā pārbaude vai Konsekvence/veselības pārbaude). Regresija var būt funkcionāls, tātad nefunkcionāls testiem.
Parasti regresijas testēšanai tiek izmantoti testa gadījumi, kas ierakstīti agrīnās stadijas izstrāde un testēšana. Tas nodrošina izmaiņas jauna versija lietotnes nesāpēja esošo funkcionalitāti. Regresijas testus ieteicams automatizēt, lai paātrinātu turpmāko testēšanas procesu un atklātu defektus programmatūras izstrādes sākumposmā.
Pats termins “regresijas pārbaude” atkarībā no lietošanas konteksta var būt ar dažādu nozīmi. Sems Kaners, piemēram, aprakstīja 3 galvenie veidi regresijas pārbaude:
- Kļūdu regresija ir mēģinājums pierādīt, ka izlabota kļūda faktiski nav novērsta.
- Veco kļūdu regresija- mēģinājums pierādīt, ka nesen veiktas koda vai datu izmaiņas pārtrauca veco kļūdu labošanu, t.i. atkal sāka spēlēt vecās kļūdas.
- Regresija blakusefekts(Blakusparādību regresija)- mēģinājums pierādīt, ka nesen veikta koda vai datu maiņa sabojāja citas izstrādātās lietojumprogrammas daļas.
Saprāta pārbaude vai konsekvences pārbaude (saprāta pārbaude) — tas ir šaurs tests, kas ir pietiekams, lai pierādītu, ka konkrēta funkcija darbojas saskaņā ar specifikācijā noteiktajām prasībām. Tā ir regresijas pārbaudes apakškopa. Izmanto, lai noteiktu konkrētas lietojumprogrammas daļas stāvokli pēc tam, kad tajā vai vidē ir veiktas izmaiņas. Parasti veic manuāli.
Atšķirība starp sanitāro pārbaudi un dūmu pārbaudi. Daži avoti kļūdaini uzskata, ka sanitārā un dūmu pārbaude ir viens un tas pats. Mēs uzskatām, ka šiem testēšanas veidiem ir "kustības vektori", virzieni dažādas puses. Atšķirībā no Smoke testing, Sanity testēšana ir vērsta dziļi pārbaudītajā funkcijā, savukārt dūmu pārbaude ir vērsta plašumā, lai pēc iespējas īsākā laikā aptvertu pēc iespējas vairāk funkcionalitātes ar testiem.
Būvējuma pārbaude(Build Verification Test) ir tests, kura mērķis ir noteikt, vai izlaista versija atbilst kvalitātes kritērijiem, lai sāktu testēšanu. Saskaņā ar saviem mērķiem tas ir dūmu pārbaudes analogs, kura mērķis ir pieņemt jaunu versiju turpmākai pārbaudei vai darbībai. Tas var iekļūt dziļumā, atkarībā no izlaistās versijas kvalitātes prasībām.
Instalācijas pārbaude - mērķis ir pārbaudīt veiksmīgu instalēšanu un konfigurāciju, kā arī programmatūras atjaunināšanu vai atinstalēšanu. Šobrīd visizplatītākā programmatūras instalēšana, izmantojot uzstādītājiem(īpašas programmas, kurām arī ir nepieciešama atbilstoša pārbaude). Reālos apstākļos uzstādītāju var nebūt. Šajā gadījumā programmatūra būs jāinstalē pašam, izmantojot dokumentāciju instrukciju vai readme failu veidā, soli pa solim aprakstot visas nepieciešamās darbības un pārbaudes. Sadalītās sistēmās, kur lietojumprogramma ir izvietota jau darbojošā vidē, var nepietikt ar vienkāršu instrukciju kopu. Lai to izdarītu, bieži tiek uzrakstīts izvietošanas plāns (Izvietošanas plāns), kurā ir iekļauti ne tikai lietojumprogrammas instalēšanas soļi, bet arī atcelšanas soļi (atgriešana) uz iepriekšējo versiju kļūmes gadījumā. Arī pašam uzstādīšanas plānam ir jāiziet testēšanas procedūra, lai izvairītos no problēmām, kad tas tiek nodots faktiskajai darbībai. Tas jo īpaši attiecas uz gadījumiem, kad uzstādīšana tiek veikta sistēmās, kur katra dīkstāves minūte ir reputācijas zaudēšana un liels līdzekļu apjoms, piemēram: bankas, finanšu uzņēmumi vai pat baneru tīkli. Tāpēc instalācijas testēšanu var saukt par vienu no svarīgākajiem uzdevumiem programmatūras kvalitātes nodrošināšanai.
Tieši šādi Sarežģīta pieeja ar plānu rakstīšanu, pakāpenisku instalācijas pārbaudi un instalācijas atcelšanu, to pamatoti var saukt par instalācijas testēšanu vai instalācijas testēšanu.
Ja vēlaties izveidot vienkāršu datorprogramma, kas sastāv no viena faila, jums vienkārši jāsavāc un jāsaista viss kods, ko ierakstījāt šajā failā. Patiesībā regulārs projekts, ko apstrādā izstrādes komanda, ir simtiem, pat tūkstošiem failu. Tas "veicina" to, ka izpildāmās programmas izveides process kļūst sarežģītāks un laikietilpīgāks: jums ir "jāsamontē" programma no dažādiem komponentiem.
Piemēram, Microsoft un dažos citos programmatūras izstrādes uzņēmumos izmantotā prakse ir katru dienu veidot programmu, kas tiek papildināta ar dūmu testēšanu. Ikdienā pēc katra faila kompilēšanas (uzbūvēšanas, uzbūves), saistīšanas (saites) un apvienošanas izpildāmā programmā pati programma tiek pakļauta diezgan vienkāršam testu kopumam, kura mērķis ir noskaidrot, vai programma "smēķē" darba laikā. Šos testus sauc par dūmu testiem (no angļu valodas smoke - smoke). Visbiežāk šis process ir diezgan labi automatizēts (vai tam vajadzētu būt).
PRIEKŠROCĪBAS. Šis vienkāršais process sniedz vairākas būtiskas priekšrocības.
Riska samazināšana integrācijas laikā
Viens no būtiskākajiem riskiem, ar ko saskaras izstrādes komanda, ir tas, ka paši izstrādātāji strādā pie koda atsevišķi, neatkarīgi viens no otra, kā rezultātā sarežģīta programma nedarbojas, kā paredzēts, veidojot izstrādāto kodu. Atkarībā no tā, kad projektā tika atklāta nesaderība, programmas atkļūdošana var aizņemt ilgāku laiku nekā ar iepriekšējo integrāciju, īpaši, ja ir mainījies programmas interfeiss vai pēc būtisku izmaiņu ieviešanas galvenajās programmas daļās.
Dūmu testu ikdienas montāža un izpilde ļauj samazināt integrācijas kļūdu risku, savlaicīgi reaģēt uz tām un novērst to uzkrāšanos.
Sliktas programmatūras produkta kvalitātes riska samazināšana
Produkta zemā kvalitāte ir tieši atkarīga no kļūmēm un problēmām integrācijas laikā. Veicot minimālu dūmu testu komplektu katru dienu, kļūdas un problēmas netiek pārņemtas projektu. Ja vienreiz nogādāsit projektu līdz stabilam stāvoklim, tas paliks stabils uz visiem laikiem. Tādā veidā jūs nekad neļausiet kvalitātei pazemināties līdz līmenim, kurā rodas kļūdas.
Palīdzība kļūdu diagnostikā
Ja kādu dienu produkts netika izveidots (būvēts ar kļūdām), ir daudz vieglāk atrast problēmas cēloni, katru dienu veidojot un veicot dūmu testu komplektu. Produkts, kas strādāja vakar un nedarbojās šodien, ir skaidrs mājiens, ka starp abām versijām kaut kas nogāja greizi.
Morāles uzlabošana
Ja produkts strādā un ar katru dienu iegūst arvien jaunas kvalitātes un funkcijas, izstrādātāju morālei teorētiski vajadzētu augt un pilnīgi vienalga, kas tieši šim produktam būtu jādara. Izstrādātājam vienmēr ir prieks vērot viņa darba "prāta bērnu", pat ja produkts ekrānā parāda taisnstūri :)
Izmantojot ikdienas konstrukcijas un dūmu testus
Šeit ir dažas šī principa detaļas.
Ikdienas lietotņu izveide
Būtiska ikdienas uzbūves sastāvdaļa ir tās daļas uzbūve, kas tika izgatavota pēdējā. Džims Makartijs darbā Dynamics of Software Development (Microsoft Press, 1995) nosauca projekta ikdienas veidošanu par savu sirdspukstu. Ja nav sirdspukstu, nav projekta, tas ir miris. Mazāk pārnestā nozīmē Maikls Kusumano un Ričards V. Selbijs ikdienas būvniecību raksturojuši kā projekta pulksteņa impulsu (Microsoft Secrets, The Free Press, 1995). Katrs izstrādātājs raksta kodu savā veidā, un viņš, kods, var pārsniegt projektā vispārpieņemto ietvaru - tas ir normāli, taču ar katru sinhronizācijas impulsa iedarbību kods atgriežas pie standarta. Uzstājot uz nepārtrauktu attīstību ar sinhronizācijas impulsu, jūs neļaujat projektam pilnībā izkļūt no sinhronizācijas.
Dažos uzņēmumos pieņemts projektu vākt nevis katru dienu, bet reizi nedēļā. Šī sistēma ir kļūdaina, jo gadījumā, ja projektā šonedēļ notiks “sabrukums”, var paiet vēl pāris nedēļas līdz nākamajai veiksmīgai būvei. Šajā gadījumā uzņēmums zaudē visas ikdienas projektu veidošanas sistēmas priekšrocības.
Pārbaudiet, vai nav izveidojušās neveiksmes
Ja projektu veido katru dienu, tiek pieņemts, ka projektam ir jādarbojas. Tomēr, ja projekts nedarbojas, tā labošana kļūst par uzdevumu ar 1. prioritāti.
Katram projektam ir savs standarts un zīme, ko sauc par "būvēšanas neveiksmi". Šajā standartā jānorāda kvalitātes līmenis, kas ir pietiekams, lai izsekotu nelieliem defektiem un nepamanītu defektus, kas "bloķē" projektu.
Laba konstrukcija ir tāda, kurā vismaz:
- visi faili, bibliotēkas un citi komponenti ir veiksmīgi apkopoti;
- saites uz visiem failiem, bibliotēkām un citiem komponentiem ir derīgas;
- nesatur nekādu stabilu sistēmisku, izslēdzot iespēju pareiza darbība lietojumprogrammu bloķēšanas kļūdas;
- visi dūmu testi iziet.
Ikdienas dūmu testi
Dūmu testi jāveic visam projektam no sākuma līdz beigām. Tiem nav jābūt izsmeļošiem un visaptverošiem, bet tajos jāietver visu galveno funkciju pārbaude. Dūmu pārbaudei ir jābūt pietiekami dziļai, lai, ja tā veiksmīgi izietu, projektu varētu saukt par stabilu un nosaukt par tādu, lai to varētu pakļaut dziļākai pārbaudei.
Ikdienas montāžas punkts tiek zaudēts bez dūmu pārbaudes. Šis process aizsargā produkta kvalitāti un nepieļauj integrācijas problēmas. Bez tā ikdienas veidošanas process ir laika izšķiešana, kuras mērķis ir pārbaudīt apkopojumu.
Dūmu testēšanai ir jāattīstās līdz ar projektu. Sākumā dūmu testos tiks pārbaudīts kaut kas tik vienkāršs kā, vai projekts var radīt ziņojumu "Sveika, pasaule!". Sistēmai attīstoties, dūmu testi kļūst padziļināti. Pirmajiem dūmu testiem pavadītais laiks tiek aprēķināts dažās sekundēs, taču, sistēmai augot, palielinās arī dūmu testēšanai nepieciešamais laiks. Projekta beigās dūmu pārbaude var ilgt vairākas stundas.
Veidot grupas definīciju
Lielākajā daļā projektu ir iecelta persona, kas ir atbildīga par sistēmas ikdienas uzbūves pārbaudi un dūmu testu veikšanu. Šis darbs ir daļa no šī darbinieka pienākumiem, bet tālāk lieli projekti tādu darbinieku var būt vairāk un šāds darbs ir viņu galvenā atbildība. Piemēram, Windows NT 3.0 projekta veidošanas komandā bija četri cilvēki (Pascal Zachary, parādīt aizbāzni!, The Free Press, 1994).
Pievienojiet versijai versiju tikai tad, ja tam ir jēga.
Parasti izstrādātāji individuāli raksta kodu pietiekami lēni, lai katru dienu sistēmai varētu pievienot nozīmīgas izmaiņas. Viņiem ir jāstrādā pie lielas koda daļas un ik pēc dažām dienām tas jāintegrē sistēmā.
|
Ievadiet sodu sistēmu par nākamā mezgla izlaišanas pārtraukšanu (nestrādājoša mezgla izlaišana). |
Lielākajai daļai projektu ir piemērota sodu sistēma par nākamās versijas neizdošanu. Jau pašā projekta sākumā ir vērts skaidri norādīt, ka darba uzmetuma saglabāšana ir augstākās prioritātes uzdevums. Nākamās versijas izlaišanas pārtraukšana var būt izņēmums, taču nekādā gadījumā ne noteikums. Pieprasiet izstrādātājiem atstāt visu, līdz sistēma atkal darbojas. Biežas būvniecības kļūmes gadījumā (nestrādājošas konstrukcijas izlaišana) ir diezgan grūti atjaunot projektu.
Nelieli naudas sodi uzsver augsta pakāpe nepieciešamība uzraudzīt sistēmas uzbūves kvalitāti. Dažos projektos izstrādātājiem, kas izraisa montāžas avāriju, tiek dotas konfektes par nestrādājoša mezgla atbrīvošanu. Šāda izstrādātāja biroja durvīm karājas atbilstoša zīme, līdz viņš salabo montāžu (ar nosacījumu, ka izstrādātājiem ir atsevišķi biroji :)). Citos projektos vainīgajiem izstrādātājiem ir jāvalkā mākslīgie kazas ragi vai jāiemaksā noteikta summa "morāles fondā" (piemēri ņemti no reālu uzņēmumu vēstures).
Bet dažiem projektiem tiek ieviesti nopietnāki sodi. Piemēram, Microsoft izstrādātāji augstas prioritātes projektos (Windows NT, Windows 95, Excel) izmantoja peidžerus, un viņiem bija jāziņo, lai strādātu, ja tika konstatēta pārbaude. Pat ja bojājums vai kļūda tika atklāta pulksten 3:00.
Izveidojiet sistēmu un "dūmojiet" to pat zem spiediena
Kad spiediens uz projekta izlaišanas grafiku pastiprinās, sistēmas izveides pārbaude katru dienu var šķist laika izšķiešana. Tomēr tā nav. IN stresa situācijas Izstrādātāji bieži pieļauj kļūdas. Viņi izjūt tādu spiedienu, lai atbrīvotu ieviešanu, kāda viņiem parastos apstākļos vienkārši nav. Viņi pārbauda savu kodu ar vienības testiem daudz mazāk rūpīgi nekā parasti. Šādās situācijās kods tiecas uz entropijas stāvokli daudz ātrāk nekā mazāk stresa situācijās.
Kas gūst labumu no šī procesa? Daži izstrādātāji protestē pret ikdienas būvēm, pamatojot savus protestus ar šīs darbības nepraktiskumu un lielajām laika izmaksām. Bet viss sarežģītas sistēmas nesen tika pakļauti ikdienas montāžas un dūmu pārbaudēm. Tās izlaišanas brīdī Microsoft Windows NT 3.0 saturēja 5,6 miljonus rindu 40 000 failos. Pilna izveide aizņēma 19 stundas un darbojās vairākos datoros. Neskatoties uz to, izstrādātājiem katru dienu izdevās salikt sistēmu. Kā profesionāla komanda NT izstrādes komanda lielu daļu panākumu ir parādā ikdienas jaunumiem. Izstrādātājiem, kuri strādā pie mazāk sarežģītiem projektiem un tāpēc neizmanto ikdienas veidošanas procesa priekšrocības, vajadzētu apsvērt iespēju pašiem piedāvāt dažus saprātīgus paskaidrojumus.
Vienkāršas kļūdas var būt liktenīgas jūsu vietnei — īpaši, ja esat SaaS (eng. Software as a Service) uzņēmums, piemēram, mēs. Ja lietotājs apmeklē jūsu vietni un nevar veikt vienkāršu uzdevumu, piemēram, reģistrēt vai atiestatīt savu aizmirsta parole, Jūs riskējat zaudēt šo lietotāju uz visiem laikiem.
Mēs to esam piedzīvojuši uz savas ādas. Protams, ir svarīgi, lai komandā būtu savi cilvēki, kas testē lietojumprogrammu un meklē kļūdas, taču ne vienmēr ir piemēroti vai nepietiekami rūpīgi. Šajā rakstā mēs vēlamies jūs, humānisti, iepazīstināt ar dūmu testēšanas pasauli.
Ja jums joprojām ir jautājumi, varat aizpildīt nepilnības, apmeklējot
Dūmu testēšana sākotnēji tika izstrādāta, lai izskaidrotu, kā elektroinženieri pārbaudīja, vai viņu ierīce darbojas - ieslēdza to un vai izdalās dūmi ...
Pagaidiet, kā tas var attiekties uz lietojumprogrammām?
Dūmu pārbaudes nozīme (un rentabilitāte) humanitāro zinātņu vadītājiem un līdzdibinātājiem parasti nav zināma. Sistemātisku dūmu pārbaudi var uzskatīt par būtisku daļu, lai novērstu uzlaušanas iespējamības palielināšanos. Tie samazina iespēju, ka jūsu tīmekļa vai tālruņa lietotne avarēs — un, kā mēs visi zinām, tikai viena kļūme, un jūs varat zaudēt klientu uz visiem laikiem.
Šis ir ievada ceļvedis par to, kas tas ir, kā to var ieviest, kādi resursi tiek izmantoti, lai to īstenotu, un piemēri, lai palīdzētu lasītājiem.
Dūmu testi ir paredzēti, lai pārbaudītu pamata funkcionalitāti, un tiem ir jābūt jūsu testēšanas procesa neatņemamai sastāvdaļai. Tie var ietvert kaut ko tik vienkāršu kā "Vai es varu reģistrēties?".
Dūmu pārbaude palīdz nodrošināt, ka neviena no galvenajām un acīmredzamajām kļūmēm netiek atstāta nejaušības ziņā. Jums nevajadzētu veikt padziļinātu pārbaudi, kamēr neesat veicis 100% dūmu testus, jo tie iztīra programmatūras galvenās kļūdas.
1. darbība. Izlemiet, ko pārbaudīt
Nosakiet, ko jūsu lietojumprogramma cenšas sasniegt. Kādi ir acīmredzamākie "mazuļa" soļi, kas jāveic, lai tajā iekļūtu? Kādas ir minimālās dzīvībai svarīgās prasības un kādā loģiskā secībā jūs tās uzskaitītu?
Izveidojiet testa komplektu. Testa komplekts ir grupēta testa gadījumu (testpiemēru) kolekcija, kas ir saistīta noteiktā veidā (piemēram, pēc funkcionalitātes).
Dūmu pārbaudē netiks iekļauti mainīgie vai jautājumi “kā būtu, ja?”. Tas pieņem tikai jā/nē atbildes, bet pirms pāriet uz detalizētāku testēšanu, visi testa gadījumi ir jānokārto ar pozitīvu rezultātu.
Ņemsim kā piemēru interaktīva foruma izveidi. Lai tas darbotos, man ir:
- reģistrēties.
- izveido lietotājvārdu.
- augšupielādējiet iemiesojuma fotoattēlu.
- rakstīt ziņas.
- atbildēt uz ziņām.
2. darbība: ierakstiet rezultātus tabulā
Iepriekš redzamais attēls ir piemērs no mūsu komandas. Jūs varat atrast modeli. Tas ir nepieciešams, lai saglabātu uzskaiti par to, kas mums der un kas nē - pamata organizācija vēlāk ietaupīs daudz laika. Mēs sadalījām savus punktus ieskaitītos, daļēji un nesekmīgos.
- Nokārtots: viss darbojas perfekti.
- Daļēji: sākotnēji var nesaprast, ka dažas darbības var iedalīt sīkāk, un tāpēc viena daļa darbojas, bet otra ne.
- Neizdevās: nedarbojas.
Mēs esam aprakstījuši precīzas darbības, kuras vēlējāmies reproducēt, un pēc tam nākamajā slejā esam pievienojuši īsu aprakstu par to, kādu rezultātu mēs sagaidām. Piemērs:
3. darbība: dūmu testu automatizācija
Ir ļoti svarīgi neuztvert to kā aksiomu, ka, ja kāda darbība tika pabeigta vienu reizi, tai vienmēr būs pozitīvs rezultāts. Dūmu testi ļauj pastāvīgi pārbaudīt, vai galvenās funkcijas laika gaitā nav cietušas vai nav bojātas ilgākā laika periodā.
Nepārtrauciet dūmu pārbaudi. Nekad.
Kad dūmu pārbaudes gadījumu komplekts ir veiksmīgi pabeigts 100%, apsveriet to automatizāciju. Ieteicamais dūmu pārbaužu biežums ir katru dienu, ja jūsu uzņēmums attīstās katru dienu.
Obligāts minimums ir veikt dūmu testus pirms katras izlaišanas un pēc katra plākstera.
Dūmu pārbaudes īkšķis:
- Minimālais laiks: 30 minūtes.
- Maksimālais laiks: 60 minūtes.
IN tālāka perspektīva dūmu testu automatizācija ietaupa laiku, taču, veicot vienus un tos pašus testus atkal un atkal, cilvēka acs var pārstāt pamanīt detaļas, bet mašīna to nedara.