Prema zvaničnoj definiciji koju je predložio OSHWA.org: „Otvorena hardverska rješenja su rješenja čiji je dizajn javan i otvoren za proučavanje, modifikaciju, distribuciju, prodaju. Ovo se odnosi i na samo rješenje i njegove derivate i komponente. Početni podaci projekta i njegove komponente moraju biti predstavljeni u formatu koji omogućava njihovu dalju promjenu. U idealnom slučaju, otvoreni hardver koristi lako dostupne alate i materijale, standardne procese, otvorenu infrastrukturu, besplatan sadržaj i alate za razvoj otvorenog koda kako bi korisnicima pružio maksimalnu slobodu da ga koriste.”

Ovdje je vrijedno napomenuti da otvorene hardverske platforme nisu potrebne da nude besplatne razvojne alate. „Razvojni alati“ se odnose na širok spektar alata za dizajn i otklanjanje grešaka, u rasponu od mernih instrumenata (multimetara, osciloskopa) i integrisanih okruženja (IDE), do uslužnih programa zasnovanih na vebu koji pružaju funkcionalno upravljanje projektima. Važno je napomenuti da mnoge od poznatih platformi otvorenog koda kao što su Arduino, LaunchPad, BeagleBone i STM Nucleo pružaju besplatne softverske biblioteke, uzorke koda, pa čak i čitave okvire kao što su Arduino IDE ili mbed.org.

Neki razvojni alati su sami po sebi otvorene platforme, što ih čini vrlo pristupačnim zbog njihove relativno niske cijene. Primjer je Red Pitaya univerzalna mjerna ploča koja pokreće Linux. Zapravo, Red Pitaya je mjerni kompleks koji zamjenjuje laboratorijsku opremu koja je zbog visoke cijene nedostupna običnim korisnicima. Red Pitaya nudi dizajnerskim uslugama 125 MSPS analognih ulaza i 100 KSPS izlaza. Ovaj svestrani instrument može djelovati kao niz standardnih instrumenata, kao što su: osciloskop sa propusnim opsegom od oko 50 MHz, analizator spektra, LCR metar impedanse, Bode analizator, teslametar, generator funkcija sa 14-bitnom rezolucijom, uključujući one pogodne za audio itd. Za prikaz rezultata mjerenja, Red Pitaya se povezuje na tablet, PC ili pametni telefon. Dodajte modul za proširenje senzora i možete povezati Red Pitaya na Arduino ploče i SEEED Studio Grove senzore da dodatno proširite funkcionalnost ovog mjernog sistema.

Rice. 1. Univerzalni mjerni sistem Red Pitaya je primjer otvorene hardverske platforme i odlikuje se maksimalnom dostupnošću. Crvena Pitaya ima funkcionalnost osciloskopa, analizatora spektra, merača impedance, Bode analizatora, teslametra, generatora funkcija itd.

Red Pitaya ploča je predstavljena na Kickstarter Internet platformi 2013. godine. To je postalo spin-off za kompaniju koja razvija instrumente za akceleratore čestica. Dakle, Red Pitaya je open source alat za mjerenje i kontrolu i softver s podrškom za vizualno programiranje. Red Pitaya podržavaju Matlab, LabView, Python i Scilab. Sa otvorenim izvornim kodom, mogućnosti Red Pitaya mogu se proširiti dodatnim funkcijama i uslužnim programima koje kreiraju korisnici.

Mnoge otvorene platforme se također mogu pretvoriti u razvojne alate. Na primjer, koristeći Arduino UNO, možete kreirati digitalni logički analizator. Međutim, vrijedno je napomenuti da to nije glavna funkcija takvih platformi. U osnovi, većina rješenja otvorenog koda dizajnirana je da pomogne u testiranju, otklanjanju grešaka i rješavanju problema. U isto vrijeme, čak i najbolja ploča za otklanjanje grešaka je beskorisna ako za nju nema potpune i detaljne dokumentacije.

Razmotrite najčešće alate koji se koriste pri radu sa otvorenim hardverskim platformama.

1. Prvi alat za dizajn je možda najvažniji i najmanje "tehnički". Ovo je obična olovka. To je olovka koja vam omogućava da trenutno "utjelovite" zamišljene ideje na papiru, označite rezultate testiranja i popravite promjene kako biste dodatno vratili cjelokupnu sliku projekta mjesecima ili čak godinama kasnije.
2. Oprema. Ovo uključuje širok spektar alata, u rasponu od mjernih instrumenata (multimetara, osciloskopa) do organizatora za pohranjivanje elektronskih komponenti. Nažalost, oprema je daleko od besplatne, ali ako ste bliski zajednici programera, onda posuđivanje jednog ili drugog mjernog uređaja neće biti problem. Osim toga, mnogi alati su sada dostupni putem internetskih trgovina i prodaju se po vrlo niskim cijenama.
3. Programiranje u izvornom kodu nije lako, pa se kompajleri i tumači koriste za kreiranje ugrađenog softvera, omogućavajući programerima da pišu programe koristeći jezike visokog nivoa ili čak izvode grafičko programiranje.

Integrisana okruženja (IDE) su još jedan alat za razvoj ugrađenog softvera. IDE su softverske platforme koje kombinuju uređivač izvornog koda, kompajler/interpretator, debuger, alat za automatizaciju izgradnje, a ponekad i alate za testiranje. Mnoga integrisana okruženja vam omogućavaju da otklonite greške koda i analizirate njegov rad na stvarnim uređajima. Postoje alati koji pomažu u vizualizaciji uređaja i pokretanju simulacija prije nego što se sastavi pravi prototip. IDE u velikoj mjeri optimiziraju i ubrzavaju proces razvoja.

Alati za razvoj i uređivanje softvera obično se kreiraju za specifične procesorske jezgre. Za većinu ploča, proizvođači određuju koje razvojno okruženje će koristiti.

Razmotrite glavne tipove IDE-a koji se koriste za kreiranje ugrađenog softvera:

1. Besplatna integrisana razvojna okruženja (IDE), kao što su Arduino IDE, Energia IDE za TI LaunchPads, koja se mogu besplatno preuzeti sa veb lokacije proizvođača i instalirati na vaš računar.
2. Online IDE za koje nije potrebna instalacija na računaru, ali im je potreban pristup Internetu. Njihove prednosti su što ne zahtijevaju ažuriranja i ne zauzimaju prostor na vašem tvrdom disku. Primjer takvih programa je Mbed.org.
3. Plaćena razvojna okruženja. Kao što je već spomenuto, kompajleri vam omogućavaju rad sa određenim tipom procesorskih jezgri, a da budemo precizni, sa određenim skupom specifičnih procesora/mikrokontrolera. Na primjer, ako se koristi par procesora sa ARM® Cortex® -M4 jezgrom, onda može biti situacija u kojoj jedan procesor podržava IDE, a drugi ne. Stoga, prije kupovine IDE, trebali biste provjeriti da li je ciljni procesor na listi podržanih uređaja. Primjeri plaćenih razvojnih okruženja su, na primjer, Keil iz ARM-a i IAR Embedded Workbench iz IAR Systems.
4. Besplatne probne verzije plaćenih okruženja sa vremenskim ograničenjem. Mnogi IDE-ovi, kao što su IAR i Keil, imaju besplatne probne verzije sa ograničenim besplatnim probnim periodom. Nakon isteka probnog perioda, program se blokira i zahtijeva kupovinu licence.
5. Besplatne verzije plaćenih okruženja sa ograničenom funkcionalnošću. Postoje ograničene verzije plaćenih okruženja sa smanjenom funkcionalnošću. Primjer takvog okruženja je Keil build za STM32L0 mikrokontrolere s ograničenjem veličine koda.
6. Slobodna i otvorena okruženja, kao što su različita GNU rješenja. Primjer slobodnog okruženja je Eclipse IDE. Eclipse IDE vam omogućava da dodate dodatke koji podržavaju različite programske jezike, posebno C++ ili Python. Vrijedi napomenuti da su u većini slučajeva besplatni prevodioci inferiorni u odnosu na komercijalne kolege u pogledu kvaliteta optimizacije koda. Međutim, ovaj jaz se vremenom smanjuje.
7. Mikrokontroleri dolaze od proizvođača u neprogramiranom obliku. Za fizički "firmver" programa potreban je poseban uređaj - programator. Izuzetak su mikrokontroleri koji imaju ugrađeni bootloader (bootloader). Bootloader je mali ugrađeni program koji vam omogućava da programirate mikrokontrolere koristeći jedan od popularnih USB, UART, CAN, itd. interfejsa.

Razmotrite opcije za programiranje mikrokontrolera bez ugrađenog pokretača.

• Mnoge popularne ploče (kao što su LaunchPad i Nucleo) imaju ugrađene programere. Ovo vam omogućava da ih povežete sa računarom preko USB-a i izvršite programiranje.
• Za ploče koje nemaju ugrađeni programator, morate koristiti programiranje u krugu (In-System Programming, ISP). Za ovo je potreban eksterni programer. Obično se programator povezuje na PC preko USB ili COM porta, a na mikrokontroler preko posebnog programskog interfejsa (SWIM, JTAG, SPI, UART, itd.). Primeri uključuju ST-LINK/V2-1 programator za STM32/STM8 mikrokontrolere kompanije STMicroelectronics, Atmel programatore za AVR mikrokontrolere, Microchip programere za PIC mikrokontrolere.

Rice. 2. STM32 Nucleo je odličan primjer otvorene platforme. Nucleo ploče dolaze sa ugrađenim ST-LINK/V2-1 debugerom (označeno crvenom bojom)

1. Debuggers. Debugger je skup alata koji omogućava programerima da nadgledaju izvršavanje programa i pronađu greške u kodu. Debager se sastoji od tri glavna dijela: softverskog dijela koji radi u IDE-u, hardverskog dijela koji je implementiran u mikrokontroler i hardverskog dijela koji je implementiran u posebnom uređaju, koji se još naziva i debuger. Ovdje je vrijedno napomenuti da za sve moderne mikrokontrolere programator i debuger predstavljaju isti uređaj. Stoga, na primjer, za programiranje i otklanjanje grešaka STM32 / STM8, ST-LINK / V2-1 programator / debugger će biti dovoljan.

Pogledajmo neke od ključnih elemenata i alata koji se koriste prilikom otklanjanja grešaka u ugrađenim sistemima:

• GDB ili GNU Debugger su popularni softverski programi za otklanjanje grešaka koji se koriste za rad sa različitim programskim jezicima. Mnogi od njih podržavaju "remote mode", koji vam omogućava da kontrolišete uređaj na kojem se otklanja greške pomoću aplikacije koja radi na računaru.
• JTAG je interfejs koji je prvobitno razvijen za testiranje ugrađenih sistema, ali je kasnije "de facto" postao industrijski standard. Trenutno se JTAG široko koristi, uključujući i otvorene platforme.
• Tačke prekida se koriste za prekid programa na pravim mjestima. Ova funkcija je neophodna za detaljno razmatranje konteksta, na primjer, status I/O portova, sadržaj registara itd. Još jedna korisna karakteristika debuggera je mogućnost otklanjanja grešaka u programu korak po korak.
• Open OCD (Open On-Chip Debugger) je paket otvorenog koda koji pruža ugrađeno otklanjanje grešaka, programiranje u krugu i testiranje za veliki izbor platformi, čineći Open OCD privlačnim za mnoge proizvođače čipova. Open OCD podržava mnoge programe za otklanjanje grešaka, uključujući JTAG.

1. Alati za praćenje grešaka i kontrolu verzija

• Posjedovanje alata za praćenje grešaka je neophodno za otvorene platforme, bez obzira na broj programera i korisnika. Postoji mnogo alata za praćenje grešaka. Na primjer, Bugzilla ili Mantis BT se mogu besplatno preuzeti i instalirati na servere, osim toga, postoje usluge koje mogu pružiti hosting uz nominalnu naknadu.
• Sistemi kontrole verzija su još jedan alat koji je kritičan za otvorene platforme, posebno zato što otvorene platforme uključuju više korisnika i programera koji rade zajedno. Alati kao što su Git i Subversion su popularni sistemi za upravljanje verzijama i sadržajem. Usluge kao što je GitHub pružaju hosting sadržaja projekta, praćenje grešaka i kolaborativne preglede koda.

Otvorene hardverske platforme pomažu u pojednostavljenju procesa razvoja i značajnom smanjenju troškova. Istovremeno, platforma mora imati pouzdane i jeftine alate za razvoj i otklanjanje grešaka, inače je malo vjerovatno da će izazvati interes među korisnicima.

Umjesto zaključka, još jedna misao poslije

Vrlo često se programeri ograničavaju na to da postanu stručnjaci unutar jednog procesora ili mikrokontrolera. Naravno, temeljno proučavanje svih registara i karakteristika procesorskog jezgra je veliki plus za određeni projekat. Međutim, vrijedi napomenuti da tehnologija ne miruje, a sposobnost brzog prilagođavanja različitim platformama mnogo je vrijednija vještina od poznavanja svih zamršenosti jednog rješenja. Otvoreni projekti uvelike pojednostavljuju tako veliku obuku smanjujući troškove i vrijeme. Pokušajte steći iskustvo sa Arduinom, stavite svoje ruke na PIC mikrokontrolere, radite sa eksternim programatorom! Ovaj samoobrazovni proces može čak pomoći da se zaposle, na primjer, neiskusni studenti, ako im se "upali" na bilo kojem forumu. Ovladavanje različitim rješenjima i arhitekturama usavršit će vaše vještine samoučenja, što će biti ključ duge i uspješne karijere.

Preliminarna priprema

- Molimo da se svi pridržavate vezanih sigurnosnih pojaseva i da nisu uključeni znakovi za zabranjeno pušenje. Zavalite se i uživajte u vožnji.

Dakle, redom.
Ispitivanje se provodi u svim fazama životnog vijeka opreme. Testiranje može biti početno (bringup), komponentno, funkcionalno, opterećenje, proizvodno, pa čak i testiranje na kupcima.

Čak iu fazi razvoja opreme, inženjer razmišlja o tome kako će oživjeti svoje potomstvo. Ploče su posute test točkama, debug konektorima, džamperima, otiscima za rezervne komponente i slično. Skup mogućnosti testiranja ugrađenih u opremu naziva se DFT (Design for Testability). Ploča puštena u DFT fazi može sadržavati dvostruko više komponenti od ploče puštene u promet. Naravno, po principu „radi – ne diraj“, onda ga niko ne prepravlja, a krajnji korisnik zbunjeno pregledava prazna mjesta na matičnoj ploči iz trgovine, smišljajući razne teorije zavjere o njihovoj namjeni.

Dakle, naša ploča je uzeta iz fabrike - šta dalje? Pa, naravno - uključite ga u utičnicu i pustite sav bijeli dim iz njega.

- Svi padaju prvi put.

Fotografija sa interneta, nismo pronašli nijednu izgorjelu ploču, ali priznajem - ponekad se to radi. Postoji duga istorija u mom sećanju kada je radoznali sistemski arhitekta sedeo i nasumično birao u koje konektore da uključi fazu, neutralnu i uzemljenje (pa, nije imao vremena da pogleda u kolo), a programer je sedeo sledeći njemu i uhvatio blijedog.

Ali obično stvari stoje drugačije. Prva faza testiranja je odgoj (popularno „oživljavanje“).

Revitalization Birth

- Probudi se Neo...

Za podizanje, obično se napravi 3-5 uzoraka (pod pretpostavkom da će najmanje dva biti uništena u delirijumu za otklanjanje grešaka). Ako uređaj sadrži skupe čipove, oni nisu instalirani na jedan od uzoraka. Fab vam može ponuditi da uštedite na zlatu - NEMOJTE SE SLAŽATI NI U KOM SLUČAJU (pa, samo morate mnogo i često lemiti).

Daska bez čipa je prvi kandidat za klanje. Provjerava redoslijed uključivanja, resetiranja, ocjene napona i tako dalje. Onda je takva tabla donator organa i/ili poligon za testiranje svih vrsta hipoteza. Također, prije nego što nešto uključite, morate:

• zazvonite uzemljenje, tamo često dolazi do kratkog spoja;
• vizualno pregledajte ploču - tamo se polaritet kondenzatora lako obrće, čipovi su naopaki, postoje čipovi, lako možete pronaći pasivne komponente koje su otkinute;
• proučite odvojeno - i jeste li stavili komponente na ploču za koje ste tražili da se ne instaliraju (life hack: ne pravite crnu masku na prvim uzorcima - ne možete vidjeti da li su na njoj ugrađeni otpornici za čip ili ne).

Dosta smo se igrali s prvom žrtvom - otpuhnut ćemo dim sa borbene table. U ovom slučaju, potrebno je opskrbiti se pilotom s gumbom za isključenje struje i termovizirom. Pilot se mora staviti ispod noge, u slučaju da 220 V udari u ruke (pa, ili su samo ruke zauzete), a na termoviziji se može vidjeti kratki spoj.

Ali generalno, kada ga uključite prvi put, obično se ne morate plašiti - najverovatnije se neće uključiti, jer ste verovatno zaboravili da ponovo zalemite komponente koje imaju pomešane noge u dizajnu :

I zalemite neke žice:

Vruće ljepilo je naše sve, najbolji prijatelj programera, skoro kao selotejp u svakodnevnom životu.
Odmah nakon Dremela:

A čekići koji moraju da zakucaju bonke u dasku ne izlaze uvijek uredno.

Ponekad je pacijentu potrebno uraditi rendgenski snimak ili tomografiju. izgleda ovako:

Ispostavilo se da skeniranje filma nije lako. Snimljeno telefonom ispred prozora.

Konkretno, na ovoj slici se ništa ne vidi - nemojte viriti. Ali općenito, na rendgenskom snimku možete vidjeti nelemljenje, pukotine i slične stvari.

Zasebno, vrijedi spomenuti i dovođenje matičnih ploča, jer se to radi drugačije. DFT uzorci majke obično se naručuju puno - oko 20 komada. To je skupo, tako da postoji strategija.

Programeri se uzimaju i šalju u fabriku. Oko 5 ploča je sastavljeno i transporter se zaustavlja. Tada programeri imaju oko 30 minuta da uključe ploču (za x86 sisteme, kriterijum uspeha je učitavanje BIOS-a). Ako svi imaju sreće, prikupljaju se ostali uzorci. Ako ne, proizvodnja se otkazuje, a programeri idu kući da razmišljaju. Novac potrošen na PCB je izgubljen, ali komponente čekaju u skladištu za sljedeći pokušaj.

U redu - pokrenuli smo našu ploču, pa čak i druge koji bi trebali raditi s njom. Šta je sledeće? Sakupljamo štand.
I onda vjerovatno očekujete da ćete ovo vidjeti?

Ovo je sve izloga za zamjenike ministara. Pravi stalak treba sastaviti od štapića i žira, a izgleda ovako:

- Nisam rekao da će biti lako, Neo, samo sam rekao da će to biti istina.
(čaša za protuteg, flomaster - tako da radijator čvrsto sjedi - tu je namotana žicom)

Ova horda se gura u laboratoriju:

I svi počinju da se utrkuju da zašiju svoj firmver, programe, i da pipaju svuda osciloskopom.
Ponekad se u tom procesu pojavi ljubazan zahtjev "Dragi kolega, molim te makni mi lemilicu iz ruke - jako je vruće" ili "Budite tako ljubazni - nemojte ponovo uključivati ​​napajanje kada zašrafim ploču na šasiju."

U našem konkretnom slučaju, glavna svrha provjere kompatibilnosti nekoliko uređaja je da se utvrdi da li PCI Express radi, da li je u skladu sa standardom. U osnovi možete živjeti bez svega ostalog. Obično je funkcionalnost stavljena u komad željeza suvišna. Tone GPIO pinova, I2C/SPI sabirnica, termalnih senzora, leda i drugih stvari po pravilu ostaju nepotražene, jer se njihovo otklanjanje grešaka odlaže do posljednjeg trenutka koji nikada ne dolazi.

Naravno, nemamo mjernu opremu vrijednu nekoliko miliona rubalja za svaku životnu priliku - ovo je za slabašne. Testni softver proizvođača komponenti žuri nam u pomoć. Gotovo svi moderni čipovi sa sučeljima velike brzine imaju digitalni osciloskop unutra. Oslanja se na specijalizovani softver koji vam omogućava da pročitate njegovo svedočenje. Počinjemo i gledamo dijagrame oka. vidimo ovo:

Ponekad vidimo opasno žmirkanje:

A ponekad lovimo i lignje:

Lignje su najopasnije. To su nelinearna izobličenja, a ugrađeni ekvilajzeri nisu posebno u stanju da se izbore s tim. Lignje znače da je negdje u komunikacijskom kanalu nešto jako loše - predugačak prolaz, značajan pad impedanse, neka vrsta neravnomjernosti u 1/4 ili 1/2 talasne dužine nekih harmonika u korisnom opsegu itd. slično.

Moglo bi se primijetiti da je squid pomalo sličan onome što radi sa primljenim DFE signalom u ekvilajzeru PCIe prijemnika. Ali u ovom slučaju, ovo je još uvijek squid, a ne rezultat DFE operacije (softver koji koristimo ne može prikazati rezultat DFE operacije).

Odvojeno, treba reći o testnom softveru, koji takođe može biti izuzetno podmukao. Na primjer, za snimanje dijagrama očiju koristimo dvije verzije istog programa - jedna verzija crta slike, ali ne upisuje vrijednosti otvaranja očiju, druga radi suprotno.

Pa, da – ako planirate da pucate u oči koristeći I2C interfejs – zaboravite, to će biti veoma, veoma sporo. Samo u bendu. Problem je u tome što da biste uklonili in-band, vaš uređaj mora imati ispravnu PCIe vezu sa računarom na kojem je pokrenut test softver, što je vrlo problematično kada vaš hardver nije instaliran u standardni PCIe slot. A smiješno je što bi već trebao imati barem neki radni link na kanalu koji ispravljaš i to tačno u načinu rada (gen2/3) u kojem ti treba (jer u različitim modovima postoje različite oči i ekvilajzeri rade drugačije ). Bez nogu, bez karikatura, bez očiju - tako hoćeš, i izlazi.

O tome kako se izvući sa PCIe - prethodno sam pisao odvojeno.

Općenito, pri razvoju servera, naravno, podrška proizvođača korištenih komponenti je vrlo važna, jer je danas složenost čak i relativno jednostavnih čipova tolika da je malo vjerovatno da će biti moguće u potpunosti provjeriti i otkloniti greške u sistemu. bez korištenja testnih stvari ugrađenih u njih. Generatori takta, regulatori napona, mrežni kontroleri, PCI Express prekidači, reddriveri - sve to ima ugrađene alate za konfiguraciju, dijagnostiku i potreban je određeni set programa i kablova za povezivanje za potpunu konfiguraciju i testiranje, bez kojih razvoj postaje jednostavno nemoguć .

U procesu provođenja inspekcijskog nadzora ponekad se ispostavi da negdje nešto nije u redu. I tada počinje uzbudljiv proces lokalizacije greške tako da se može popraviti u sljedećoj reviziji. I dobro je ako se ovo "nije tako" stalno ponavlja - tada obično nije teško otkriti šta je tačno uzrok greške. Ali ponekad su stvari mnogo gore. Na primjer, na nekim instancama ploča, tokom dugog trajanja testova, na sabirnici se javljaju pojedinačne neispravljive greške (što uopće ne bi trebalo biti). I ovdje je često već potrebno primijeniti metodu "bližeg pogleda" - to jest, samo sjediti, hipotetički gledajući u kolo, pogoditi koji bi točno mogao biti razlog, pokušati eliminirati ovaj hipotetički razlog u krugu, i već provjeriti sa testira da li smo dobro pogodili ili ne.

Susreli smo se s tim prije nekoliko godina, kada su NVIDIA testovi (da, mnogi proizvođači pružaju specifične skupove testova koji vam omogućavaju da provjerite stvari koje nisu programski dostupne pomoću standardnih uslužnih programa) dali su rijetke pojedinačne greške tokom dugog (dnevnog ili više) rada na nekim pločama . Onda se cijela stvar pokazala kao neuspješno praćenje referentnog takta (100 MHz) - iako je prije nego što smo došli do ovoga provjereno dosta stvari, počevši od kvaliteta napajanja pa do dijagrama oka za sve linije.

I usput, dobro je. Najveća noćna mora programera je kada sve radi odjednom. To znači samo jedno - negdje je zakopan rudnik koji će raditi nakon isporuke 100.500 komada opreme kupcu. Činjenica je da se u procesu traženja uzroka nekog globalnog problema provjerava nekoliko hipoteza i po pravilu se otkrivaju mnoge sitne kvarove koji nisu u vezi s nastalim problemom. Nema velikog problema - nećete naći male. Vaši kupci će ih pronaći za vas.

Provjera liste

- Sve što radim je ono što mi on kaže.

Nakon završetka testova komponenti, počinje funkcionalno testiranje - provjera operativnosti kompleksa u cjelini i ispravnog rada svih ugrađenih funkcija. To obično radi QA. Opseg za kreativnost ovde je, naravno, veoma širok, ali generalno gledano, glavni naglasak je na ispravnom radu sistema kada se igraju standardni scenariji upotrebe. Ovdje otkrivene greške mogu već biti i hardverske i softverske prirode, pa je važno prije svega saznati šta je tačno uzrokovalo grešku. Često prve pretpostavke mogu biti pogrešne, odnosno očito hardverski problem na prvi pogled može biti uzrokovan nepravilnim radom firmvera. Značajan dio funkcionalnog testiranja je provjera kako sistem rješava različite greške koje se mogu pojaviti tokom rada. Moderni alati za otklanjanje grešaka omogućuju vam da umjetno ubacite greške u standardna sučelja procesora, jer je na hardverskoj razini prilično problematično kreirati mnoge od njih namjerno (pa, nemojte kidati memorijske čipove u hodu ili kratko spajati PCI Express linije sabirnice) .

Ah... Nisam rekao da funkcionalno testiranje ne znači sastavljen sistem spreman za borbu. I ovdje ne ide sve glatko. U nekom trenutku se ispostavilo da nemamo na lageru OcuLink kablove potrebne dužine, a server se pojavio iznutra.

I iz nekog razloga, u takvoj konfiguraciji, tokom testa opterećenja, sve se počelo pregrijati. Još uvijek se pitamo zašto. Kablovi su se zagrejali, pretpostavljam.

Možete li nositi dvije lubenice u svakoj ruci?

- Brži si od ovoga. Nemoj misliti da jesi, znaj da jesi...

U nekom trenutku, paralelno s funkcionalnim testiranjem, počinje testiranje opterećenja – važno je osigurati da server nastavi ispravno raditi u ekstremnim radnim režimima. Štaviše, testovi opterećenja se provode kako u odnosu na pojedinačne podsisteme (diskovi, memorija, procesori, I/O), tako i na cijeli sistem u cjelini. U pravilu, lokalizirani testovi vam omogućavaju da učitate jedan određeni modul više nego što se to može učiniti uz maksimalno opterećenje cijelog sistema.

Osim toga, ovdje pomažu alati za otklanjanje grešaka proizvođača hardverske platforme (na primjer, Hardware Tests Executive iz IBM-a). Tako je moguće dovesti procesor u potpuno ograničavajuće režime, koji su u osnovi nedostižni kada se izvršavaju prave aplikacije. Glavni problemi otkriveni tokom testiranja opterećenja su pregrijavanje, nestabilnost napajanja ili maksimalno strujno preopterećenje, greške tokom aktivnog rada sa I/O interfejsima.

Merila takođe priskaču u pomoć. Jer kada su stvarne vrijednosti ​​benchmarka veoma različite od predviđenih, onda je nešto pošlo po zlu. Dobar razlog da probijete dasku štapom.

U fazi testiranja uglavnom koristimo mikrobenchmarkove:
Za procesore, to su obično jednonitna opterećenja, kao npr spec2006(već sada speccpu2017), parsec, ali općenito postoji ogroman broj njih od sklapanja linux kernela i kompresije ( lzma, gzip), prije množenja matrica i izračunavanja brze Fourierove transformacije ( fftw).
Dugi niz godina se ništa nije promijenilo u sjećanju: POTOK,RAMspeed SMP, lmbench.

Za diskove: fio, iozon.

Ako su svi testovi funkcionalnosti i opterećenja uspješno prošli, ostaje još nekoliko stvari koje treba provjeriti - stabilnost rada u cijelom temperaturnom rasponu, otpornost na vibracije, provjeru kompatibilnosti sa određenim skupom standardnih komponenti (memorija, diskovi, PCI Express kontroleri).

P.S.: Nakon što smo sve provjerili i radovali se funkcionalnim testovima prve revizije servera, tri servera su se iznenada srušila u našoj laboratoriji. Počeli smo provjeravati napajanje i na 1.2V liniji (napajanje za PCIe sabirnicu procesora) vidjeli smo ovo:

Fokusiram vašu pažnju - jedna ćelija 500mV. Nominalna vrijednost je 1,2 V. Otpornik je pogriješio u kompenzacijskom kolu jednog od VRM-a. S takvim napajanjem, svi testovi opterećenja, mjerila, pečenje i druge slične stvari uspješno su prošli, a dizajn je radosno otišao u drugu reviziju.
Dakle, kada se na vašem udobnom kućnom računaru poznatog brenda iznenada pojavi ekran smrti, ne biste trebali misliti da je ovo sigurno „Windows buggy“.

Tehnologije virtuelizacije se sada koriste u mnogim oblastima IT-a, kako u proizvodnom okruženju, tako i od strane entuzijasta i kućnih korisnika za različite zadatke. Nekoliko virtuelnih sistema koji istovremeno rade na jednoj fizičkoj mašini značajno povećavaju fleksibilnost IT infrastrukture i povećavaju efikasnost korišćenja hardverskih resursa. Testiranje softvera je jedan od najčešćih slučajeva korištenja virtualizacijskih platformi. Nije iznenađujuće što virtuelne mašine imaju mnogo korisnih karakteristika koje značajno smanjuju vreme razvoja i testiranja i povećavaju efikasnost ovih procesa.

U klasičnom modelu razvoja softvera, programeri i inženjeri kvaliteta softvera većinu vremena morali su testirati softverski proizvod na jednoj platformi gotovo cijelo vrijeme razvoja, a tek na kraju ga testirati u različitim operativnim sistemima i korisničkim okruženjima (tj. -naziva se testiranje konfiguracije, testiranje konfiguracija). ). Osim toga, nije bilo toliko fizičkih računara na raspolaganju odjelima za testiranje i razvoj, a na jednoj mašini, u jednom operativnom sistemu, nemoguće je, na primjer, instalirati više verzija jednog softverskog proizvoda istovremeno, sa sa kojima razvijeni program mora biti u interakciji. Kao rezultat toga, u softveru, posebno u malim razvojnim timovima, često je dolazilo do grešaka vezanih za posebnosti korisničkih konfiguracija, jer nije bilo dovoljno vremena i resursa za potpuno testiranje konfiguracije. Osim toga, inženjeri kvaliteta morali su provesti dosta vremena postavljajući set softverskih proizvoda na testne stolove i konfigurirajući svoj rad u mrežnoj infrastrukturi.

Naravno, jedan od najozbiljnijih problema u razvoju softvera je činjenica da u ranim fazama razvoja sklopovi softverskog proizvoda tokom svog rada mogu uzrokovati nepopravljivu štetu sistemu (na primjer, razni drajveri uređaja). Stoga je potrebno planirati restauraciju operativnih sistema i njihovih postavki nakon kvarova iz sigurnosnih kopija i potrošiti dosta vremena na njihovu restauraciju.

Treba napomenuti da postoji još jedan problem koji je prilično čest u razvoju softvera i koji zahtijeva dosta vremena za njegovo rješavanje. Svi programeri koji imaju iskustva u interakciji s timovima za testiranje znaju sljedeću situaciju: u sistemu praćenja grešaka, tester popravlja defekt koji programer ne može ponoviti ni na koji način. Nakon što programer postavi status problema kao riješen, tester ga poziva na svoju mašinu i vizuelno demonstrira grešku. U ovoj situaciji dolazi do toga da programer mora da ugradi mnogo debagera i drugih nepotrebnih gluposti na mašinu testera i „uhvati“ kvar, potpuno zaustavljajući rad testera. Ako ovome dodamo vrijeme da tester ukloni programske programe, dobijamo ozbiljan gubitak timskog vremena.

Osim toga, karakteristike rada nekih softverskih proizvoda zahtijevaju provjeru njihovog rada pod određenim uvjetima (različita količina RAM-a, propusnost komunikacijskog kanala, frekvencija procesora itd.). U ovom slučaju, testni tim možda neće imati potrebnu hardversku konfiguraciju na raspolaganju (što ako nam treba deset tvrdih diskova?). Prilikom određivanja sistemskih zahtjeva proizvoda za takve faktore, ova potreba može biti kritična.

U zaključku nabrajanja liste problema koji se javljaju u procesu razvoja i testiranja treba dati još jedan. Često postoji takva situacija kada je potrebno provjeriti sklop softverskog proizvoda "na dim" (tzv. dimno testiranje, Smoke Testing), što znači brzo izvođenje najvažnijih testova. Ali šta ako razvijamo aplikaciju koja zahtijeva različite verzije Internet Explorera? U tom slučaju, dosta vremena će se potrošiti na učitavanje odgovarajućeg sistema na kojem je instalirana potrebna verzija.

Sumirajući opisane situacije, sumiramo probleme koji se često susreću u procesu razvoja i testiranja softverskih proizvoda:

• potreba za testiranjem softvera u više korisničkih konfiguracija nego što je dostupno za testiranje fizičkih računara
• veliki vremenski troškovi za postavljanje i konfiguraciju testnih stolova koji sadrže mnogo različitih komponenti, između kojih je omogućena mrežna interakcija
• veliki vremenski troškovi za pravljenje rezervnih kopija sistema i njihovih konfiguracija, kao i oporavak nakon kvara usled nestabilnog rada sklopova softverskih proizvoda
• nemogućnost reprodukcije kvara koji je pronašao tester na mašini programera i gubitak vremena da se pronađe, popravi
• potreba za testiranjem programa u hardverskom okruženju koje nije dostupno timu za testiranje
• potreba za testiranjem softverskog proizvoda u uvjetima koji zahtijevaju brzo prebacivanje između korisničkih konfiguracija

Ako izračunate koliko je vremena i sredstava utrošeno na rješavanje ovih problema, dobijate vrlo, vrlo impresivnu cifru koja, izražena u novcu, čini prilično veliki dio budžeta projekta.

Tehnologije virtuelizacije, pravilno primenjene u procesu razvoja i testiranja, mogu značajno smanjiti troškove rada i značajno povećati efikasnost procesa, što će pozitivno uticati na kvalitet objavljenog softverskog proizvoda. Dakle, konkretno virtuelizacija vam omogućava da uradite ovo:

• testeri u procesu rada sa virtuelnim mašinama mogu kreirati neograničen broj korisničkih konfiguracija na svojoj fizičkoj mašini, pokrećući, ako je potrebno, najpovoljniju u ovom trenutku
• kada se jednom kreiraju, konfiguracije više mašina mogu se konfigurisati pomoću alata platforme za virtuelizaciju i jednostavno preneti na drugi hardver, bez potrebe za njihovim ponovnim konfigurisanjem
• virtuelna mašina se može napraviti rezervna kopija kopiranjem fascikle ili kreiranjem trenutne snimke stanja ("snimka")
• nakon što tester pronađe grešku, virtuelna mašina sa defektom koji se ponavlja može se preneti na programera, uz oslobađanje resursa za dalje testiranje
• potrebni uslovi za testiranje mogu se brzo stvoriti zahvaljujući fleksibilnoj konfiguraciji parametara hardverskog okruženja virtuelne mašine (količina RAM-a, broj virtuelnih procesora, ograničenja resursa)
• mogućnost brzog vraćanja na sačuvano stanje virtuelne mašine sa potrebnom konfiguracijom ili prebacivanje između nekoliko istovremeno pokrenutih gostujućih sistema smanjuje vreme testiranja

Sva gore navedena rješenja treba razmotriti u svjetlu činjenice da je virtuelna mašina sa instaliranim softverom u njoj vrlo fleksibilan objekat koji se može brzo postaviti na klijentske mašine iz centralizovanog spremišta predložaka korisničke konfiguracije i konfigurisati što fleksibilnije. što je moguće u odnosu na postavke gostiju.sistem i njegovo okruženje. Jednostavna prenosivost na drugi hardver i nezavisnost od hardverske platforme ključna je prednost virtuelnih mašina.

Virtualni alatni strojevi za testiranje i razvoj

Prilikom implementacije virtuelne infrastrukture za potrebe razvoja i testiranja softvera potrebno je, prije svega, odabrati najprikladniju, pouzdanu i efikasnu platformu za virtuelizaciju koja ispunjava sve zahtjeve za razvojni proces u organizaciji. Postoje dva najčešća načina korištenja virtualnih mašina za testiranje softverskih proizvoda:

• Neupravljana implementacija virtuelnih mašina na klijentske mašine ili servere za testiranje, u kojoj testeri ili kreiraju konfiguracije koje su im potrebne ili kopiraju šablone virtuelnog sistema na svoje računare iz centralne biblioteke virtuelnih šablona (file server). Prednost ovakvog pristupa je jeftinost rješenja, možete koristiti jedan od mnogih besplatnih sistema virtuelizacije (VMware Server, Virtual PC, VirtualBox i drugi). Glavni nedostaci - spontano postavljanje virtuelnih mašina generiše konflikte u mrežnoj infrastrukturi, nedostatak kontrole nad korišćenjem licenci za operativne sisteme i aplikativni softver, nemogućnost integracije u postojeće IT okruženje organizacije.
• Upravljana implementacija virtuelnih sistema iz centralizovanih biblioteka virtuelnih šablona, ​​uz punu kontrolu nad korišćenjem virtuelnih mašina u okviru IT infrastrukture kompanije. Prednosti ovog pristupa uključuju mogućnost rješavanja sukoba između virtualnih i fizičkih sistema na mreži, kontrolu korištenja licenci, mogućnost praćenja korištenja virtuelne infrastrukture i stvaranje zajedničkog prostora između različitih učesnika u procesu razvoja i testiranja, integraciju u stvarnu IT infrastrukturu preduzeća. Glavni nedostatak ovog pristupa je visoka cijena rješenja. Primeri proizvoda koji obezbeđuju upravljanu implementaciju virtuelnih mašina: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.

Platforme za virtuelizaciju, kojih sada postoji veliki broj na tržištu, razvijaju se velikom brzinom i korisnicima pružaju sve veći skup alata za poboljšanje efikasnosti procesa razvoja i testiranja. Za rješavanje svakog od ovih problema, virtualizacijske platforme različitih proizvođača imaju vlastite alate koji korisnicima omogućavaju da efikasno testiraju softverske proizvode u virtuelnim mašinama.

1. Kreiranje mnogih prilagođenih konfiguracija.

   Ako na mašini testera postoji velika količina slobodnog prostora na disku, pomoću platforme za virtuelizaciju možete kreirati neograničen broj virtuelnih sistema, od kojih se svaki može pokrenuti na zahtev, bez zaustavljanja rada radnika na host sistemu. Virtuelne mašine se takođe mogu koristiti na specijalizovanim test serverima zasnovanim na VMware ESX Server, XenEnterprise ili Virtual Iron platformama. Istovremeno se mogu dodijeliti određena prava korisnicima virtualnih sistema, kao i ograničeni fizički resursi servera koje može koristiti određeni korisnik. Datotečni server sa virtuelnim predlošcima može da skladišti unapred instalirane virtuelne mašine koje se postavljaju na test servere ili radne stanice. U ovom slučaju morate uzeti u obzir posebnosti korištenja virtualnih mašina u skladu s licencom. U većini slučajeva, svaka virtuelna mašina zahteva posebnu licencu, ali postoje izuzeci: na primer, licenca za Windows Server 2003 Datacenter Edition omogućava vam da pokrenete neograničen broj virtuelnih instanci OS-a.

   Ako je konfigurisano testno okruženje već raspoređeno na fizičkom računaru, može se migrirati na virtuelno korišćenjem proizvoda dobavljača platforme za virtuelizaciju i programera treće strane. Takva rješenja uključuju PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit proizvode.

2. Kreiranje više-mašinskih konfiguracija na jednom fizičkom serveru.

   Virtualizacijske platforme fokusirane na testiranje softvera (VMware Workstation, Virtual PC, VirtualBox, Xen) omogućavaju vam da kreirate čitave virtuelne infrastrukture sa različitim vrstama umrežavanja unutar jednog fizičkog hosta. Na primjer, možete kreirati nekoliko „blokova“ virtuelnih servera (server baze podataka, server aplikacija, klijentsko okruženje), konfigurisati mrežne adaptere virtuelne mašine (jedna mašina može imati nekoliko, do deset u VMware Workstation) i pokrenuti testiranu gomilu serveri. Istovremeno, platforme za virtuelizaciju vam omogućavaju da povežete mrežne adaptere virtuelne mašine na različite virtuelne mrežne segmente.
   

   Nakon što se kreira probna virtuelna infrastruktura, možete konfigurisati parametre komunikacijskih kanala između virtuelnih mašina.
   

   Treba napomenuti da virtuelne mreže nisu prenosive na svim platformama za virtuelizaciju, a ponekad ih je potrebno rekonfigurisati kada se virtuelne mašine prebacuju na drugi hardver.

3. Backup virtuelnih mašina tokom testiranja.

   Ako testeri koriste virtuelne mašine na svojim radnim stanicama, mogu ih napraviti rezervnu kopiju kopiranjem fascikle datoteka virtuelne mašine. U slučaju pada sistema, sačuvanu kopiju nije potrebno vraćati - već je potpuno spremna za upotrebu. Pored toga, mnoge platforme za virtuelizaciju vam omogućavaju da kreirate više snimaka stanja virtuelne mašine, od kojih se svaki može vratiti za nekoliko minuta.

   Ako se testiranje vrši na namenskim test serverima, dobavljači virtuelnih mašina kao što su vRanger Pro iz Vizioncore, VMware Consolidated Backup (VCB) ili Microsoft Data Protection Manager za virtuelni server 2005 koji tek treba da bude objavljeni mogu se koristiti za sigurnosno kopiranje virtuelnih R2, koji vam omogućavaju pravljenje rezervnih kopija virtuelnih mašina bez zaustavljanja.

4. Demonstracija nedostataka programerima.

   Kada se pronađe kvar, tester može jednostavno snimiti stanje sistema u kojem se greška pojavila i nastaviti s testiranjem sistema. Ako je potrebno pokazati kvar, virtuelna mašina se može prenijeti na programera koji može raditi s njom bez straha da će oštetiti okruženje testera. Pored toga, na platformi VMware Workstation, virtuelne mašine mogu da deluju kao VNC serveri bez potrebe za instaliranjem dodatnog softvera za pristup udaljenoj radnoj površini.
   

5. Fleksibilna konfiguracija hardverskog okruženja.

   Često, kada testirate softver, potrebna vam je veća fleksibilnost u pogledu konfigurisanja hardverskih komponenti. Na primjer, tokom testiranja na stres (Stress Testing) potrebno je provjeriti rad softverskog proizvoda u ekstremnim ili ograničenim uvjetima (nedostatak prostora na disku, neuspjeh mrežne veze). U ovom slučaju, koristeći virtuelnu platformu za virtuelnu mašinu, možete dodati nove virtuelne uređaje ili ograničiti resurse koji su im dodeljeni.

   Istovremeno, ako dodamo virtuelni disk u gostujući sistem, možemo ga kreirati kao dinamički širi, što nam omogućava da uštedimo slobodan prostor na disku, kao i kreiramo takozvane Undo diskove čije promene važe samo tokom rada. sa virtuelnom mašinom i po završetku sesije se može otkazati, što je veoma zgodno za testiranje.
   

   Što se tiče kontrole resursa, mnoge platforme za virtuelizaciju omogućavaju vam da ograničite resurse virtuelne mašine ili skup resursa virtuelne mašine, što vam omogućava da simulirate stvarne uslove korisničkog okruženja.

   Moderne platforme za virtuelizaciju podržavaju USB 2.0 standard, veliki broj virtuelnih mrežnih adaptera u virtuelnoj mašini, emulaciju SCSI diskova i predstavljanje različitog broja procesora u gostujućem sistemu kroz virtuelni SMP (Symmetric Multi Processing).

6. Rad sa nekoliko virtuelnih sistema istovremeno.

   Ova funkcija omogućava testerima ne samo da koriste instance različitih gostujućih sistema prilikom testiranja, već i da lako razmjenjuju datoteke između glavnog i gostujućeg OS-a, kao i između gostujućeg OS-a koristeći mehanizam Drag&Drop. U isto vrijeme, neke platforme za virtuelizaciju omogućavaju vam laku razmjenu datoteka ili kroz dijeljene mape glavnog sistema (Shared Folders), ili “prevucite i ispustite” datoteke između gostujućih sistema (VMware Workstation).

   Mnoge platforme za virtuelizaciju vam omogućavaju da koristite zajednički međuspremnik sa glavnim sistemom, što uveliko pojednostavljuje, posebno, kopiranje poruka o greškama programa u sistem za praćenje grešaka.

Alati za razvoj i testiranje za neupravljanu implementaciju

Osnova za upravljanu implementaciju virtuelnih mašina su specijalizovana rešenja za kreiranje i održavanje virtuelnih testnih laboratorija (Virtual Labs), u okviru kojih se vrši kontrola korišćenja virtuelnih sistema od strane različitih grupa korisnika, automatizovano postavljanje virtuelnih mašina na računare projekta. učesnika i stvaranje zajedničkog radnog okruženja. Ova rješenja su prilično skupa (na primjer, VMware LabManager infrastruktura će koštati najmanje 15.000 dolara), ali se opravdavaju velikom količinom upotrebe. Velike kompanije kao što je Dell u velikoj meri koriste virtuelne mašine u okviru virtuelnih laboratorija za testiranje softverskih proizvoda. Ovi sistemi koriste SAN-ove, gdje zajednička biblioteka virtuelnih šablona sadrži šablone virtuelnih mašina koji se postavljaju na zahtev na besplatnim test serverima zasnovanim na platformama za virtuelizaciju. Korištenje virtuelnih laboratorija pruža sljedeće prednosti:

• Rad sa konfiguracijama više mašina kao jedan modul, mogućnost objavljivanja ovih modula
• Smanjeno vrijeme utrošeno na konfigurisanje sistema
• Razlikovanje pristupa virtuelnim mašinama i demonstracija kvarova prenošenjem linkova na problemsku situaciju sačuvanu kao snimak stanja gostujućeg sistema
• Generička biblioteka uzoraka s mogućnošću rješavanja mrežnih sukoba pri implementaciji (SID-ovi, dodjeljivanje jedinstvenih MAC adresa virtualnim mrežnim sučeljima)
• Centralizovano održavanje i implementacija ažuriranja u test okruženjima
• Praćenje opterećenja servera za testiranje

Trenutno, najpopularnija rješenja za upravljano postavljanje virtualne testne infrastrukture su VMware LabManager (za ESX Server platformu) i VMLogix LabManager (za Microsoft, VMware i XenSource platforme).

VMware LabManager testne laboratorije

VMware nudi velikim kompanijama da koriste virtuelnu infrastrukturu za testiranje zasnovanu na rješenju (bivši razvoj preuzete kompanije Akimbi), koje omogućava brzo postavljanje virtualnih mašina na test servere i kontrolu korištenja virtualnih sistema, dok proces izgleda kao korisnik radi sa fizičkim računarom. U nastavku je predstavljen model virtuelne laboratorije:

Pored svih gore navedenih prednosti sistema upravljanja virtuelnim laboratorijama, VMware LabManager omogućava integraciju sa popularnim alatima za testiranje i ima mogućnost postavljanja šablona u nekoliko klikova mišem, podržava LDAP protokol, lako se integriše sa drugim VMware virtuelnim infrastrukturnim rešenjima i ima mogućnost automatizacije operacija preko sopstvenog API-ja (Aplikacijski programski interfejs). Glavni nedostatak ovog proizvoda je mogućnost opsluživanja virtuelnih servera samo na VMware platformama.

VMLogix LabManager testne laboratorije

Za razliku od VMware rješenja, proizvod podržava virtualizacijske platforme različitih proizvođača. Platforme Microsoft (Virtualni server), Xen (XenEnterprise) i VMware (ESX Server i Server) mogu se koristiti kao osnova virtuelne testne laboratorije. Osim toga, VMLogixov LabManager podržava održavanje fizičkih servera organizacije. Arhitektura VMLogix LabManager rješenja je prikazana u nastavku:

LabManager korisnicima pruža samouslužni portal preko kojeg korisnici mogu implementirati virtuelne mašine iz centralizovane biblioteke šablona operativnog sistema i ISO-a, kao i upravljanje licencama, podešavanja zone IP adrese i mogućnosti revizije bezbednosti virtuelne infrastrukture za testiranje. Osim toga, VMLogix LabManager također uključuje API automatizaciju, mogućnosti postavljanja i održavanja na više mašina, te funkcije za demonstriranje problematičnih situacija dijeljenjem snimaka virtuelnih mašina.

Zaključak

Model za organizaciju procesa razvoja i testiranja pomoću virtuelnih mašina može značajno smanjiti troškove implementacije testnih korisničkih okruženja i konfigurisanja testnih okruženja. Prema statistikama, prilikom testiranja softverskih proizvoda na fizičkim serverima i radnim stanicama, ovi zadaci oduzimaju do 50 posto vremena tima za testiranje. Virtuelne mašine na platformama različitih proizvođača mogu ovo vreme smanjiti za nekoliko puta, do 5% ukupnih troškova testiranja. Povećana fleksibilnost virtuelnih sistema i njihova nezavisnost od opreme omogućavaju vam da sa njima radite kao sa određenim blokovima od kojih je izgrađena virtuelna testna infrastruktura kompanije. Mogućnost zajedničkog pristupa pronađenim nedostacima članovima razvojnog tima i korisnicima proizvoda može značajno ubrzati pretragu i ispravljanje grešaka. U mnogim kompanijama testiranje sa virtuelnim mašinama je već postalo de facto standard.

Međutim, proces testiranja na virtuelnim sistemima ima neka ograničenja: na primer, virtuelni sistemi se ne preporučuju za testiranje performansi (Performance Testing), kao ni testiranje aplikacija koje postavljaju visoke zahteve za fizičke resurse računara. Za druge vrste testiranja, virtuelna infrastruktura za testiranje je jedno od najboljih rešenja za povećanje efikasnosti procesa razvoja, kao i za pojednostavljenje interakcije između članova tima.

Hardverske platforme

Kompatibilnost prema hardverskoj platformi znači da se računari sastoje od čvorova i uređaja koji imaju isti komandni sistem i kodiranje podataka, pa se stoga mogu zamijeniti. Iako to nije potrebno - ako se uređaji uvelike razlikuju po tehničkim karakteristikama, onda se jedan ne može zamijeniti drugim. Ali za različite hardverske platforme, sve komponente su potpuno različite i nekompatibilne.

Za PC, sada su preostale samo dvije konkurentne hardverske platforme: IBM PC I Apple Macintosh(Slika 3) Štaviše, IBMPC jasno dominira, preko 90% računara pripada ovoj platformi. Nekada je Apple Macintosh bio pogodniji za grafiku i izdavaštvo, ali sada su mogućnosti obje platforme ovdje jednake. ipak,

Apple računari ne nestaju, ali se i dalje koriste.
Za servere visokih performansi, ili obrnuto - primitivne čipove, postoje i druge hardverske platforme: SunMicrosystems, Compaq, HewlettPackard, itd.

U hardverskoj konfiguraciji računara važnu ulogu igra princip otvorene arhitekture. Ovo je konstrukcija računara po modularnom principu, kada svi isti tip računarskih uređaja imaju:

1. međusobno usaglašeni protokoli (standardi) za prenos podataka;

2. standardne geometrijske dimenzije i objedinjeni konektori za spajanje.

Otvorena arhitektura dozvoljava Nadogradite(Nadogradnja), tj. nadogradnju računara jednostavnom zamjenom jednog uređaja drugim bez utjecaja na sve ostalo.

Umjesto zastarjelog uređaja, stavljaju novi sa boljim parametrima i spajaju ga na isti konektor. Operativni sistem registruje novi uređaj i određuje najbolje drajvere za njega. Ako nisu unutar OS-a, tada se potrebni drajveri preuzimaju sa eksternog medija ili sa interneta. Nakon toga računar počinje da radi sa nekoliko puta boljim parametrima. Jednostavna i efikasna procedura.

Zamjena nekih hardverskih uređaja drugim s boljim karakteristikama vrši se u određenoj mjeri u svim tehničkim uređajima, ali nigdje ne dostiže takve razmjere kao u kompjuterskoj tehnici. Na primjer, teško je zamisliti automobil u kojem se novi dijelovi motora i mjenjača stavljaju na mjesto zastarjelih, zbog čega se snaga automobila povećava nekoliko puta.

Nadogradnja ima svoja ograničenja i ne možete staviti sve najnovije na veoma star računar. S vremena na vrijeme se pojavljuju fundamentalno novi standardi povezivanja, stare sistemske sabirnice se više ne proizvode, mijenjaju se standardi osnovnih uređaja, kao što je, na primjer, matična ploča. I tada nadogradnja postaje besmislena, lakše je kupiti novi računar.

IBMPC platforma ima otvorenu arhitekturu, dok Apple ima zatvorenu.

Otvorena arhitektura ¾ je upravo ono što je omogućilo IBM platformi da zauzme vodeću poziciju u proizvodnji računara i u jednom trenutku porazi konkurente. I sada u svijetu dominiraju računari bazirani na IBM platformi.

Međutim, sam IBM je uvođenjem otvorene arhitekture za svoje proizvode uspješno rješavao taktičke probleme, ali je izgubio strateški. Uređaje sa otvorenom arhitekturom za IBM računare počele su da prave stotine kompanija širom sveta - u Americi, Evropi, Aziji. Za ovo nema zakonskih zabrana. A tehnički otvorena arhitektura sabirnice to čini prilično lakim.

Kao rezultat toga, IBM je prestao da bude jedini lider u proizvodnji računarske tehnologije. Postala je samo jedna od najvećih korporacija u prvih pet proizvođača.

Uvod Nakon što smo saznali mogućnosti modernih video kartica u 3DMAX-u, vrijeme je da izvršimo iste testove kako bismo uporedili moderne jednoprocesorske hardverske platforme.
Trenutno postoje samo dvije porodice procesora na masovnom tržištu koje se mogu smatrati "perspektivnim" - platforme Socket478 i Socket462 (SocketA). Neću razmatrati "zastarjele" platforme bazirane na Socket370 i Socket423 procesorima, jer nema smisla kupovati jednoprocesorske sisteme bazirane na ovim procesorima za rad u 3DMAX-u.
Naravno, već kupljeni sistemi bazirani na oba Socket370 procesora bazirani na Tualatin jezgri i 512Kb L2 keš memorije, kao i sistemi bazirani na starijim Socket423 procesorima omogućavaju vam produktivan rad u 3DMAX-u. Međutim, cijena ovih "zastarjelih" sistema danas ih čini neisplativim za kupovinu, jer sistemi bazirani na ovim procesorima nemaju prednost u performansama ili su čak inferiorni u odnosu na sisteme bazirane na procesorima Socket478 i Socket462 familije po istoj cijeni. To je posljedica Intelove politike zamjene "zastarjelih" procesorskih linija novim, "perspektivnim", što se manifestuje u bržem ažuriranju "perspektivnih" procesorskih linija i, shodno tome, bržem snižavanju cijena procesora ovih "perspektivnih" procesora. " linije.
Najproduktivniji čipsetovi za Socket478 i Socket462 procesore, na kojima su ploče trenutno dostupne za prodaju, su i850 i Apollo KT266A. Nema smisla sklapati platforme bazirane na i845D čipset pločama sa podrškom za PC2100 DDR SDRAM memoriju, pošto PC800 RDRAM memorija trenutno košta isto ili čak jeftinija od PC2100 DDR SDRAM memorije, a pruža primetno veće performanse.

Dakle, u ovom članku ćemo razmotriti performanse sistema zasnovanog na ploči sa i850 čipsetom (Abit TH7II) i Pentium4 procesorima - 2.2GHz, 2.0GHz sa 512Kb keš memorije drugog nivoa (Northwood jezgro) i Pentium4 procesorima - 2.0 GHz, 1,7 GHz sa nivoom keš memorije drugog nivoa od 256Kb (Willamette jezgro). Prije svega, zanima nas povećanje performansi, koje se može postići udvostručavanjem L2 keš memorije. da li povećanje frekvencije takta obezbeđuje uporedivi dobitak u performansama.
Za poređenje sa ovim sistemom, izabrao sam platformu koja se sastoji od matične ploče bazirane na Apollo KT266A čipsetu (Epox 8KHA+) i AthlonXP 2000+ procesora (stvarna brzina takta je 1667Mhz). Uzeo sam samo jedan procesor za Socket462 zbog činjenice da je AMD daleko iza Intela u procesu povećanja taktnih frekvencija svojih procesora, a frekvencija takta ovog "top" procesora je čak niža od frekvencije takta mlađeg Pentiuma4 procesora koji se razmatra u ovom materijalu.

Opis hardverskih konfiguracija

Za procjenu performansi brzine, koristio sam iste testove kao u prethodnim recenzijama. Da vas podsjetim da ove benchmarkove preporučuje za testiranje u 3D Studio MAX-u sam proizvođač programa.
Počevši od ovog članka, uzdržao sam se od testiranja s uključenim anti-aliasingom, budući da sve moderne video kartice obavljaju anti-aliasing bez gubitka performansi.

Platforma #1:

Procesor – Pentium 4 2,2GHz (512Kb L2), Pentium 4 2,0A GHz (512Kb L2), Pentium 4 2,0GHz (256Kb L2), Pentium 4 1,7GHz (256Kb L2).
Matična ploča - Abit TH7II (i850)
Memorija – 1024Mb PC800 RDRAM

Platforma #2:

Procesor - AthlonXP 2000+ (1667Mhz)
Matična ploča - Epox 8KHA+ (Apollo KT266A)
Memorija – 1024Mb PC2100 SDRAM
Video kartica - NVIDIA GeForce4 Ti4600 (Detonator verzija 27.51)
Hard disk – 20Gb IBM DTLA 7200rpm

softver:

Windows 2000 SP2
3ds max 4.26 (OpenGL renderiranje), 1280x1024 32bit

Ispitivanje karakteristika brzine pri radu u projekcijskim prozorima

1 . Prvi benchmark je “stres test” – animacija scene se reprodukuje u četiri projekcijska prozora. Međutim, način prikazivanja je drugačiji. U gornja dva prozora, scena je predstavljena kao "Wireframe" (to jest, u "wire" ili "wireframe" modu), u donjem lijevom "Smooth + HighLights" + "Eded Faces" (u osenčenom načinu rada sa odabranim ivicama ), u donjem desnom dnu - "Glatko + HighLights":

Ova scena sadrži vrlo malo poligona - samo 28 hiljada, međutim, zbog istovremene reprodukcije animacije u sva četiri prozora, "ukupni" fps je vrlo mali.

Poligoni: 28868
Izvori svjetlosti: 1
Način rada: Wireframe, Smooth+Highlights

Uz istovremeni prikaz animacije u sva četiri projekcijska prozora, najveći dio opterećenja pri renderiranju scene pada na CPU-memoriju. Kao što vidimo, u ovom benchmark-u, AMD procesor radi dobro, što potvrđuje svoju ocjenu. Dobitak od povećanja keš memorije drugog nivoa u Intelovim procesorima je vrlo mali i iznosi oko 5%

2 . Drugi benchmark je scena sa sedam osnovnih geometrijskih objekata, ukupne složenosti od deset hiljada poligona.

Šest objekata je statičnih, jedan se polako kreće po sceni, "prolazeći" kroz druge objekte. Ovaj benchmark provjerava ispravnost prikaza "presijecanja" objekata i brzinu kojom drajver i hardver video kartice to mogu podnijeti.

Poligoni: 9712
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

Za razliku od prethodnog, ovaj benchmark u ovom slučaju učitava AGP magistralu i pokazuje brzinu AGP porta matične ploče. U slučaju pogrešne implementacije AGP-a, vrijednost fps u ovom benčmarku pada na oko 80-100.
Dakle, vidimo da je implementacija AGP-a dobra na obje platforme. Međutim, u ovom benčmarku povećanje keš memorije daje mnogo veći porast nego u prethodnom - do 20%.

3 . Scena trećeg benčmarka sadrži loptu koja se kreće vrlo sporo na pozadini od 15.000 poligona.

Lopta nigdje ne siječe druge objekte. Pošto se lopta kreće veoma sporo, "ispravan" vozač će napraviti vrlo male promene u svakom kadru. Drugim riječima, ovaj benchmark testira sposobnost video kartice da ne iscrtava objekte koji se ne mogu osvježiti svaki kadar.

Poligoni: 15653
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

Ovaj benchmark je sličan prethodnom, a rezultati sistema su takođe slični rezultatima prikazanim u prethodnom benchmark-u - AthlonXP 2000+ ponovo pokazuje "poštenost" svog rejtinga i udvostručavanje L2 keš memorije u Pentium4 pruža primjetno povećanje brzine.

4 . Ovaj benchmark pokazuje sposobnost video kartice da rukuje veoma složenom geometrijom. Reper pokazuje performanse video kartica u režimu Smooth+HighLights u scenama sa složenom geometrijom.

Poligoni: 200270
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

U ovom geometrijskom benchmark-u rezultat ovisi o snazi ​​FPU-a (pošto je potrebno izračunati složenu geometriju) i propusnosti memorije (pošto je potrebno crtati površine u Smooth + HighLight modu). U prvom, Athlon ima jasnu prednost, međutim, propusnost RDRAM-a je mnogo veća, pa Socket462 platforma pokazuje rezultat koji je niži od Pentium4 2.0GHz sistema.

5 . Peti benchmark testira sposobnost video kartica da obrađuju izuzetno složenu geometriju. Ovaj put se broj poligona gotovo udvostručio i iznosio je skoro 376.000. Kuće sada stoje na istoj „površini“.

Ovaj benchmark je u stanju da "baci na koljena" bilo koju video karticu - prosječni fps ne prelazi tri okvira. Sam fajl je kreiran, naravno, ne na fps=3, kućice su kreirane odvojeno u različitim fajlovima, a prilikom “instaliranja na zemlju” neiskorišćeni deo geometrije je “isključen” radi povećanja performansi.

Poligoni: 376875
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

U težem geometrijskom benchmarku, situacija je slična prethodnoj, međutim, s povećanjem obrađene geometrije, smanjuje se utjecaj keš memorije, a raste utjecaj FPU jedinice.

6 . Benchmark testiranje brzine obrade više izvora svjetlosti. Budući da većina video kartica ne podržava više od 8 svjetala, ovaj test i još dva naredna sadrže 8 izvora svjetlosti različitih tipova. U ovom testu, 8 SpotLight izvora svjetlosti, koji se kreću, osvjetljavaju neku vrstu “asteroida”:

Treba napomenuti da je prikazivanje rasvjete koju stvaraju Spotlights proces koji zahtijeva mnogo više resursa od prikazivanja rasvjete koju stvaraju Omni i Directional svjetla.

Poligoni: 39600
Izvori svjetlosti: 8
Način rada: Glatko + Istaknuto

7 . Isti "asteroid", samo što je sada osvijetljen sa osam usmjerenih izvora svjetlosti. Usmjerena svjetla su "sporija" od Omni, ali "brža" od Spotlight svjetala.

Poligoni: 39600
Izvori svjetlosti: 8
Način rada: Glatko + Istaknuto

8 . Opet isti "asteroid" i opet osam izvora svjetlosti. Sada su ovo svjetla tipa Omni, najbrža svjetla u 3DMAX-u.

Poligoni: 39600
Izvori svjetlosti: 8
Način rada: Glatko + Istaknuto

U testovima za osvetljenje, AthlonXP 2000+ pokazuje rezultate uporedive sa Pentium4 2.0GHz. Dobitak performansi od povećanja keš memorije ne prelazi 10%.

9 . Scena sa "svetlosnom" geometrijom i jednim izvorom svetlosti, samo četiri i po hiljade poligona, koji zauzimaju ceo prozor za projekciju, merilo je brzine rasterizacije u režimu Smoth + Highlights.

Prilikom pomicanja kamere, video kartica mora rasteriti velike i male poligone (u odnosu na veličinu ekrana)

Poligoni: 4684
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

U testu za rasterizaciju, AthlonXP 2000+ je pokazao loš rezultat - manji od Pentium4 iste frekvencije takta (1700MHz). To se objašnjava činjenicom da u ovom benchmarku sve ovisi o brzini prijenosa podataka na magistrali procesor-memorija.

10 . Benchmark koji pokazuje brzinu video kartica sa teksturama. Fajl sadrži puno tekstura i minimum geometrije. Merilo je rotirajuća lopta, sa 48 tekstura postavljenih na lice.

Minimalna geometrija i maksimalne teksture ove scene pokazuju maksimalnu brzinu obrade teksture od strane video kartice.

Poligoni: 224
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

11 . Prostorija s potpuno teksturom u kojoj se kamera kreće unutra. Ovaj benchmark je najbliži stvarnim aplikacijama, jer sadrži puno tekstura, složenu geometriju i nekoliko izvora svjetlosti. Ovaj benchmark pokazuje mogućnosti video kartica prilikom obrade složenih scena u načinu Smooth + Highlight.

Poligoni: 12413
Izvori svjetlosti: 8
Način rada: Glatko + Istaknuto

12 . Animirani teksturirani "valovi" pokazuju brzinu kojom se teksture obrađuju i modificiraju.

Poligoni: 880
Izvori svjetlosti: 1
Način rada: Glatko + Istaknuto

U tri benčmarka teksture, sistemi moraju izračunati rotirajuće teksture (u prvom testu teksture), ispraviti stacionarne teksture pomoću rotirajuće kamere (u drugom) i deformisati teksturu (u trećem).
Nije teško pretpostaviti da su u prvom benchmarku teksture propusni opseg memorije i veličina keš memorije najvažniji - zato Athlon "ne dostigne" Pentium4 2.2GHz.
Korekciju teksture vrši FPU, tako da se u drugom benchmarku Athlon2000+ približava Pentium4 2.2GHz. Takođe, povećanje keš memorije daje povećanje od 15%.
Proračun deformacije teksture takođe se bavi FPU, a u ovom benchmark-u AthlonXP 2000+ radi bolje od Pentium4 2.2GHz.

13 . Benchmark mjeri brzinu rada u Wireframe modu. 111 hiljada poligona u wireframe modu će biti ozbiljan test svake moderne video kartice.

Poligoni: 111270
Izvori svjetlosti: 1
Način rada: Wireframe

Ovaj test teksture sadrži istu scenu kao i benchmark #4, međutim, za razliku od četvrtog benchmarka, ovdje se ova scena prikazuje u Wireframe modu. Dakle, u ovom benchmarku sve zavisi od snage FPU-a - Ahtlon pokazuje rezultat uporediv sa rezultatima Pentium4 procesora koji rade na 2GHz, a povećanje količine keš memorije u ovom testu ne daje nikakav porast brzine.

Svi navedeni benčmarkovi su preporučeni za testiranje video kartica od strane proizvođača 3DMAX, međutim, kao što smo vidjeli, testiraju mogućnosti video kartica po pojedinačnim funkcijama, a među njima nema „generalnih“ testova. Zato sam dodao još jedan benchmark - ovo je scena sa osam svjetala, 61371 poligona i mnogo transparentnih ravnina. Složenost ovog fajla je prilično tipična za današnje vreme, ceo fajl zajedno sa teksturama zauzima više od 6Mb. Animacija je napravljena za najbolje moguće testiranje - kamera se kreće po prostoriji, hvatajući sve objekte. Evo kako izgleda prvi kadar nakon konačnog renderiranja:

Koristio sam ovu scenu da testiram video kartice u Wireframe i Smoth+Highlights modovima. Dakle, dobili smo dva mjerila:

14 . Scena u Wireframe modu

Poligoni: 61371
Izvori svjetlosti: 8
Način rada: Wireframe

Budući da je scena u ovom benchmark-u prikazana u Wireframe modu, kao iu prethodnom benchmark-u, količina keš memorije nema primjetan učinak, a rezultat AthlonXP2000+, zahvaljujući moćnom FPU-u, pokazao se jednak rezultatu Pentium4 2.2GHz, koji radi na višoj frekvenciji od 50% i ima dvostruko veću količinu keš memorije.

15 . Ista scena u načinu Smooth+HighLight

Poligoni: 61371
Izvori svjetlosti: 8
Režim: Glatko + Visoko svjetlo

Budući da se scena prikazuje u Smooth+HighLight modu, rezultati Athlona nisu tako dobri kao u prethodnom benchmark-u. Međutim, rezultati AthlonXP 2000+ su jednaki rezultatima Pentium4 2.0GHz, a Athlon ponovo potvrđuje svoju ocjenu.
512Kb keš memorije umjesto 256Kb, u ovom benchmark-u, kao iu većini benchmarka sa "srednjom" geometrijom i Smooth + HighLight modom, omogućava vam povećanje brzine za oko 15%.

Testiranje karakteristika brzine tokom finalnog renderovanja

Napravio sam finalno renderovanje tri scene iz 3ds max4 isporuke sa istim parametrima, na istoj rezoluciji 800x600, pošto je procenat rezultata testiranih platformi isti za sve rezolucije od 640x480 do 1600x1200. Evo tih scena:

Tabela rezultata (vrijeme u sekundama: što niže to bolje):

Brzina finalnog renderovanja prvenstveno zavisi od snage FPU-a, tako da je u finalnom renderovanju AthlonXP2000+ „izveo“ tek nešto lošije od Pentium4 2.2GHz.

zaključci

Zasnovano na ukupnosti rezultata u svim benčmarkovima testiranja rada u prozorima za projekciju, AthlonXP 2000+ pokazuje rezultate uporedive sa Pentium4 2.0A GHz. Štaviše, kada radi u Wireframe modu, AthlonXP2000+, zahvaljujući izuzetno moćnom FPU-u, pokazuje rezultat blizak ili jednak Pentium4 2.2GHz (uprkos činjenici da potonji radi na +50% brzine takta i ima duplo veću keš memoriju). Stoga, ako većinu svog vremena provodite radeći u Wireframe modu, onda je AthlonXP2000+ najbolji izbor. U konačnom testu brzine renderovanja, rezultati AthlonXP 2000+ su takođe približno jednaki onima Pentium4 2.2GHz. Dakle, po cijeni AthlonXP 2000+ procesora od 250 dolara. (i sa Pentium4 2.0AGHz i 2.2GHz po cijeni od 350 USD i 550 USD, respektivno) i jeftinijim matičnim pločama za njega, Socket462 platforma je daleko najprofitabilnija u kategoriji "cijena-performanse". Međutim, najbrži procesor za 3DMAX je Pentium4 2.2GHz.
Razlika u performansama Pentium4 procesora sa 256Kb i 512Kb keš memorije u velikoj većini testova koji simuliraju rad u prozorima projekcije i konačnom proračunu renderiranja ne prelazi 5%, tako da nema smisla mijenjati procesor sa 256Kb keš memorije na nove procesore sa 512Kb keš memorije. S druge strane, kupovina procesora sa manjom keš memorijom danas je takođe besmislena - cijene za procesore sa 265Kb i 512Kb keš memorije su skoro jednake.