Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
mno, já zase po přečtění článku k Octane renderu, po letech na IGP v chipsetu AMD780G, o nějaké nVidii začínám uvažovat. http://www.3dsoftware.cz/3dportal/clanek.aspx?id=1722
Ono je Intelu a AMD ukradeny jestli se jejich integrovane GPU v pocitaci vyuzije nebo ne,hlavne ze za ne dostanou zaplaceno.
To není tak úplně pravda. Lepší zákazník, co grafiku využije a příště koupí další, než zákazník, kterému je to fuk a koupí u konkurence...
Meli by nabizet i CPU bez GPU, protoze nevidim duvod kupovat CPU s grafikou kterou stejne nevyuziju.AMD GPU aspon umi spolupracovat, ale u Intelu to nehrozi a dlouho asi jeste nebude.
to je prave ten vtip. za to GPU neni zadne price premium. je to feature ktera pomaha prodavat hlavni produkt. kdyz uz by to melo nejaky financni vliv, tak primo opacny a to ze pak ukroji prodeje entry level grafik nVidie a AMD. nejvetsi objemy budou asi v mainstreamu, takze ztraty v tomhle low endu asi nic hrozneho nebude. navic AMD samotne to vadit moc nemusi. komu to ale vadit musi jiste, jsou jeji dvorni vyrobci. je sice hezke, ze AMD nahradi low end grafiky svymi IGP, ale z IGP vyrobci jako Sapphire nemaji vubec nic. pro ne je to samozrejme ztrata
No IGP je ovšem důvod, proč se tak prodávají AMD Fusiony, kdyby je AMD nemělo, tak by tento prodej sežral Atom s Ionem.
Ion uz je pase a ani Atom to nebude mit snadny, protoze AMD se trefilo do spravnyho mista. Zakate a spol. jsou akorat tak dost rychly, aby na nich chodily 7ky stejne nebo lip, nez chodej XPcka na Atomu.
Jasne
spíš by ho Intel sežral sám, v grafikách se stále zlepšuje
evidentně jste neviděl Intel QuickSync.
"ale z IGP vyrobci jako Sapphire nemaji vubec nic"
Můžou vyrábět desky, to taky dělají i když u nás se moc neprodávají
http://www.sapphiretech.com/presentation/product/?cid=2&psn=000102
Zotac to tak dělá taky. Dřív dělal jenom grafiky, poslední dobou mi ale přijde, že hlavní jsou pro něj mini-ITX desky
To jen dokazuje, že pouze ze jména se žít nedá. Zdá se mi, že nVidia směřuje do stejných míst jako Physx :-)
to si leda muzes prat. je celkem logicke, ze podil celkoveho objemu grafik pujde proti nvidii, kdyz uz pomalu neni cpu nebo chipset bez IGP. ale je otazka, jestli se IGP opravdu "zaplati" jejim tvurcum. dle meho je to jen dalsi feature, ktery prichazi tak nejak samozrejme a nevsiml jsem si, ze se za nej neco plati. skoda jen, ze nejsou v tom prehledu zahrnuty i SoC grafiky. myslim, ze by to s temi procenty dost zahybalo a objevila by se nova a docela vyznamna jmena spolecnosti. ja osobne bych spis pockal na mercury research zpravu, ktera rozlisuje IGP a diskretky
Tak se dočkal? Oproti Q4/2010 žádné extra změny, nVidia polepšila v mobilních diskrétních grafikách (zde asi opravdu pomohl Optimus), v desktopech zase AMD. Celkově je to zaokrouhleně 51% nvidia, 49% AMD, takže prakticky stejně jako Q4.
mel bys link? me se to nejak nedari najit. google mi dava odkazy na stare ctvrtletni zpravy
Zatím to zpracoval DD, určitě jej nařkneš z fanatismu, ale já beru jen data z tabulek co převzal, ne jeho komentář. Stačí si počkat, během týdne to bude všude.
No zřejmě je to výhodnější v tom, že výroba grafiky přejde na divizi zabírající se CPU, zatímco se dá ušetřit na výrobě samostatných grafik na desku/čipsetu.
Alespoň z tohodle pohledu mi to dává smysl, že ty nejnáročnější operace výroby sjednotí v jednom procesu a ušetří nějaké chechtáky.
Pak je tady samozřejmě i mírná snaha nutit uživatele ke koupi nového procesoru jen když začně zastarávat grafika (pro uživatele, kteří nechtějí použít či nemůžou, dedikovanou gk). Protože až doteď se dalo s jedním procesorem přejít i na další generaci integrovaných grafik, když by CPU slot ok, ale to teď už nepůjde, protože grafika půjde s procesorem.
Poznamka nemate zlu fabru v poslednom stlpci v ridaku "nVidia"?
Anketa ;-D
V jakém roce koupí Intel nVidiu?
Vzhledem k tomu, že nová Windows mají běžet i na ARMech a nVidia umí vyrábět ARM procesory, si myslím, že současný hendikep je jenom dočasný a za nejkratší provaz může brzo tahat právě Intel, kterému vývoj grafárny, která dokáže rozběhat Stalker na plné detaily bude pravděpodobně trvat dýl, než nV čip, který bude umět rozběhat MS Office ;-).
to je docela zajimavy postreh :)
Tady se často vychází z nepochopitelné představy, že cokoliv s logem WIN (tedy i WIN8 pro ARM) znamená, že na tom automaticky poběží x86 aplikace. To je naprosto absurdní představa. Je to asi jako myslet si, že na Windows 2008 Server pro Itania se dají vesele pařit X86 hry. Věřte dál
I když takový přechod může vypadat hrozivě "řádově" to nebude o moc větší problém, než přechod na neemulovaný 64bit provoz nebo přechod Applu na Intel. Specielně u her jde spíš o ty grafické karty, které se s přechodem na jinou platformu nemění a grafické knihovny, kde DX Microsoft určitě pro ARM implementuje a OGL už pro ARM existuje.
podle mě jste až moc velký optimisa. Vemte si, jaké už jen Windows hry pod linuxem přes WINE mají problémy, je třeba každou hru zvlášť optimalizovat a odladit, funguje max DX9, výkon je horší, objevují se problémy atd. Co je ale nejdůležitější, pokoušíme se to rozběhat na stejné x86 architektuře!!! Tedy představa, že to bude snad větší pohodička na úplně jiné architektuře je jen vaše zbožné přání. Věřte dál ;-)
chapes to vubec? ty nejsi programator, vid? kod se da zkompilovat pro vice target platforem. kompilatory to umeji bez problemu. microsofti kompilator bude jiste umet kompilovat do arm kodu stejne jako do x86. nebo uz to umi, ale zatim jen pro windows mobile 7
problemy s wine a hrami jsou v necem ZCELA jinem a vubec to s timhle nesouvisi. ve wine se snazi poustet kod, ktery byl zkompilovan pro windows na jinem systemu, nez jsou windows. a problemy vychazeji z toho, jak moc se tomu softwaru dari odstinit specifikacni rozdily
neplet prosim jablka s hruskami
Kurna, musim poprve souhlasit s teroristou :-) Zde zalezi jen na MS, pokdu bude chtit, tak lze udelat prechod pomoci virtualizace a dalsich nastroju podobne, jako uz 2 zmenil architekturu APPLE, kdy krome mirneho snizeni vykonu zakaznik nepoznal. Ovsem zde je urcita nadeje, protoze mam pochybnosti, jestli by to MS programatori zvladli, kdyz se jim to zatim uplne dobre nepodarilo ani pro stare aplikace do windows.
tak je rozdil ve zpetne podpore a future podpore. nevidim to zas tak valne, ze by honem honem vydavali vsichny sve stare aplikace pro win8/arm. microsoft se v tomhle urcite taky nepretrhne. spis si myslim, ze pro ne neni zadny problem uvest pro win8/arm verze nove
jj všechny aplikace nové. To je ten problém. Navíc ne všichni budou vydávat verze svých aplikací pro x86 a zároveň ARM. Tvoje naivní představa, že na všechno stačí jen kompilátor je naprosto hloupá. Pokud si skutečně programátor, tak nejspíš jen nějaký akademický geek, který nemá představu co za reálnou komerční aplikací pro nějakou platformu stojí - více verzí znamená 2x více testování, prodražuje podporu atd. A proto řada firem bude své aplikace vydávat dále jen pro jednu platformu, tu nejrozšířenější a ta bude hádej která?
tak ti kdo budou na .net nebo jave to resit nebudou. ceckari samozrejme ano. a je videt ze programovani moc nerozumis. dnes se rucne testuje snad jen v prehistorickych splecnostech a tech, kde se vyuzivaji specificke hardwary (tiskarny, kasy atd.). vsechny velke firmy vyuzivaji masivne automaticke testy
Tak tohle je ještě větší blábol, než tvých 29 fps v SC2 na Atomu. Ten člověk, který o tom nic neví (já) zrovna ty testovací skripty píše. Ony jaksi jsou automatické až potom co je napíšu pane "chytrý", jen tak se nevezmou. Takže i to "automatické" vyžaduje často docela hodně práce, tj. lidských zdrojů
"dnes se rucne testuje snad jen v prehistorickych splecnostech a tech, kde se vyuzivaji specificke hardwary" - blábol číslo 2. Jde vidět že absolutně nemáš představu např. o komplexnosti systémů mobilních operátorů, kde se pro každý test musí ručně tvořit subscription a pod. automatizovat se dá minimálně
Moc by mě zajímalo čím se vlastně živíš. Jsou jen 2 možnosti, buď jsi hardcore akademik naprosto odtržený od reality, který nikdy ani nepřičichnul ke skutečné práci v IT firmě nebo jen ubohý chvastounek
tak ted uz je to definitivni. nic o tom nevis :)
kdyz napises automaticke testy pro svuj produkt, treba nejaky editor a pak ten produkt zkompilujes krome pro windows/x86 navic i pro windows/arm, nemusis uz psat zadne automaticke testy znovu. na venek totiz aplikace vypada uplne stejne a funguje taky uplne stejne. daji se na ni pouzit tim padem ty same testy. abych to rekl tak aby to tvuj intelekt pojmul:
ten softwarovy robutek tu aplikaci proklika uplne stejne na obou platformach - win/x86 i win/arm
to je konec koncu princip automatickych testu - napsat je jednou a mit je naporad. tva snaha do toho argumentu pridat nejake mobilni operatory je k popukani :D ty si snad myslis, ze nekdo zapomene ze se tu bavime o windows, ktere se systemy operatoru nemaji nic spolecneho? naivko :D
takze ocividne o tom nic NEVIS :D
Popsal si nám teorii hezky, nicméně to co uvádíš je idealstav, takže budeš ten nikdynečuchnuvší k práci akademik.
Uvedte mi 1 nastroj, kterym zvladnete pripravit testy na win/arm a na te stejne aplikaci je spustit proti win/x86 bez jakekoliv upravy test skriptu. Dale Vase predstava, ze skripty jednou udelate a uz je mate 'naporad' je velice usmevna - budouci upravy aplikace temer pokazde skripty rozhodi a na nejakem miste je nutne skripty upravit. A konecne Vas nazor nejvice vzdaleny od reality, totiz ze od rucniho testovani se upustilo a timto zpusobem se testuje pouze v prehistorickych spolecnostech, to snad ani nema smysl komentovat... Za prve nikdy nemuzete automatizovat uplne sechny oblasti (zejmena otazka penez a efektivity), za druhe nektere oblasti ani danym nastrojem automatizovat nemuzete. Kazda firma, vcetne MS, Oracle apod. ma velke teamy manualnich funkcnich testeru
Po nekolika Vasich nazorech na nVidii/AMD(ATI) jsem si myslel, ze jste pouze zaslepeny, ted se ujistuji, ze temto vecem skutecne nerozumite
to, ze vy to nechapete a neznate, v zadnem pripade neznamena, ze se to tak ve vetsine spolecnosti nedela.
"Dale Vase predstava, ze skripty jednou udelate a uz je mate 'naporad' je velice usmevna - budouci upravy aplikace temer pokazde skripty rozhodi a na nejakem miste je nutne skripty upravit."
ano, tak to je. ale pokud je aplikace stejna, jen kompilovana na jinou platformu, tak neni nutne automaticke testy upravovat na kazdou platformu zvlast. staci udelat jednu upravu pro obe platformy. a o to jde, to je pointa. vysoko-urovnovych klikacich nastorju je celkem dost. ja mam svuj postaveny na javovske tride Robot. nebudu si delat iluze, ze vam to neco rika. nizkourovnove testy typu JUnit testu jsou samozrejme bezproblemove, protoze se stejne jako zdrojovy kod aplikace kompiluji na konkretni platformu
"Kazda firma, vcetne MS, Oracle apod. ma velke teamy manualnich funkcnich testeru"
ted jste me pobavil. to totiz neni tak uplne pravda. tyto firmy maji velke skupiny testeru, ano. ale oni netestuji kod sami, ale pisi prave testovaci scenare. vy si vubec neuvedomujete komplexnost nekterych aplikaci. to nemuze testovat nejaky nimand. to musi testovat clovek, ktery tomu hluboce rozumi. vetsinou to byva programator. nebo to musi byt clovek, kteremu nekdo napise presny postup. ale to jsme tam, kde jsem rikal. kdyz umis napsat postup pro cloveka krok po kroku, nic ti nebrani napsat postup pro pocitac krok po kroku. vyuzivaji se k tomu nastroje typu Jameleon (pro weby - perfektni nastroj, doporucuji vyzkouset http://jameleon.sourceforge.net/), ktere dokazi klikat a cist obsahy webu nebo aplikace stejne jako clovek. dokonce se umeji pripojovat pres RDP a podobne. je jich opravdu cela skala
a ano, existuji oblasti, kde se takto testovat neda a to je prave hardware oblast, kde se testuje spoluprace softwaru s mnoha druhy hardware a nebo primo systemovy software pro dany hardware (low level). tam je testovani obtizne. ale takovych firem je minimum
"(zejmena otazka penez a efektivity"
proboha clovece uvedomte si, ze automatizovany stroj typy jameleon vam webovku v testu o 300 ukolech proklika za nekolik sekund. clovek to dela hodinu. jak muzete mluvit o "penezich a efektivite"? programatorovi trva takovy komplexnejsi test napsat tak dve tri hodiny. clovek to rucne testuje treba tak hodinu. ale ted si predstavte tu "prdel" (pardon), kdyz vam v tom kodu nekdo neco zmeni. tomu cloveku to bude pri kazde zmene trvat hodinu. klikaci stroj vam to po uvodni investici nekolika hodin proklika za par vterin
v neandertalskych firmach se to resi tak, ze se dusledne vedou informace o zmenach a testeri testuje jen ty casti, ktere se zmenily. ale problem je v tom, ze zmeny se casto projevuji na uplne necekanych mistech. a to pak testeri neotestuji, kdezto ten robot vam to projede vzdy, vsechno a vsude. v mem minulem projektu byl kod testu 3x vetsi nez kod samotne aplikace. chapete? ale zmeny byly bezpecne. a daly se delat a opravovat velmi rychle. a k zakaznikovi se jich dostalo naproste minimum. a chyby u zakaznika, jak by jste vedel, kdyby jste nemluvil o necem, co neznate, jsou ze vsech nejdrazsi
takze priste se plette jen do neceho, do ceho aspon trochu vidite
Ukazte mi prosim alespon jedinou SW spolecnost, ktera nepouziva manualni funkcni testery, jejichz prace je stale nenahraditelna, ale pouziva pouze praci teamu automatizovanych testeru
Robot, myslite Rational Robot odkoupeny firmou IBM (skriptovaci jazyk SQA Basic), nebo snad na Jave postaveny Rational Functional Tester? Oba znam, v obou pracuji
Ano, velke testovaci teamy netestuji, ale pisi testovaci scenare, to je pravda. Jenze podle tech scenaru to stejne potom nekdo musi otestovat, bud si na tento ukon firma najme 'klikace z ulice', pripadne to otestuji sami autori techto scenaru
Ano, ja si uvedomuji, ze automatizovane testovaci nastroje dokazou proklikat aplikaci mnohem rychleji nez clovek a z tohoto hlediska je to zdaleka nejefektivnejsi. Ale pri iterativnim testovani a iterativnim vyvoji aplikace byva zmen v aplikaci prilis mnoho na to, nez aby se jednoduse daly vsechny zahrnout v ramci automatizovancyh testu vsechny zmeny v aplikaci, samotne prizpusobeni vsech testu byva vetsinou slozitejsi (a drazsi), nez manualni pretestovani zmen
Jameleon neznam, pro testovani webu se nam docela osvedcilo Selenium, Jameleon po letmem zkouknuti webu vypada zajimave, dekuji za typ
Robot neprojede vsechno a vsude, robot projede jen to co mu naprogramujete. Pokud jste se dostal na projekt, kde kod automatizovanych testu byl 3x vetsi nez kod aplikace - super, bud jste testovali miniaturni aplikaci, nebo pisete kod automatizovanych testu zbytecne neefektivni
Ja na rozdil od Vas nejsem pouhy teoretik ale tyhle veci delam v praxi dnes a denne
"pripadne to otestuji sami autori techto scenaru"
odpovedel jste si sam
"Ale pri iterativnim testovani a iterativnim vyvoji aplikace byva zmen v aplikaci prilis mnoho na to, nez aby se jednoduse daly vsechny zahrnout v ramci automatizovancyh testu"
tak to potom iterativni vyvoj nezvladate dobre. jeho soucasti je prave psani testu. vase filosofie je prave tou, ktera je typicka pro neandertalske firmy. tam si neuvedomuji prave tu zakladni premisu, ze jakkoliv zanedbatelna zmena muze mit necekane a nicive dusledky. takze rucne pretestuji jen zmenenou cast
"Pokud jste se dostal na projekt, kde kod automatizovanych testu byl 3x vetsi nez kod aplikace - super, bud jste testovali miniaturni aplikaci, nebo pisete kod automatizovanych testu zbytecne neefektivni"
zrejme o tom nic nevite, stejne jako machina. chvili to vypadalo, ze se alespon okrajove chytate. pocitejte se mnou, co se na jednu featuru aplikace musi napsat:
1) JUnit testy (pro jine jazyky nez java pak JUnit klony) - testuji low-levelovou stabilitu kodu, spravny vystup metod
2) databazove testy - testuji konzistenci a integritu databaze po provedeni funkce dane featury (tzn. je tam vse co tam melo zustat? zmenilo se co se melo zmenit? atd.)
3) integracni testy - testuji spravnou funkci dane featury ve finalnim produktu, tedy po spojeni vsech casti (treba ten Jameleon to dela). i kdyz jednotlive dily funguji spolehlive a jsou otestovane, celek fungovat nemusi. a proto se integracni testy pisi
jedna featura - tri sady testu. tak to presne ma vypadat a kdyby jste to pouzivat, vedel by ste jak moc to za a) zkrati cas hledani chyby b) chyba se objevi mnohem drive c) cim drive ve vyvojovem cyklu se chyba objevi, tim mene penez stoji jeji oprava d) chyby muzou opravovat i mene znali programatori, protoze "co ten kod ma delat" je videt prave z toho testu a postupu v nem. miniprojekt typu kalkulacka lze jeste udrzet na rucnim testovani, ale bezne a enterprise aplikace rozhodne ne
"Ja na rozdil od Vas nejsem pouhy teoretik ale tyhle veci delam v praxi dnes a denne"
nezlobte se ale podle urovne znalosti problematiky soude z vasich prispevku vam to neverim
'odpovedel jste si sam' - ano, co je divneho na tom, ze autori testovacich scenaru si svoje testy exekuji sami, pripadne se po dobu testu najmou externi testeri? To nijak nevyvraci tvrzeni, ze ve firme existuje staly testovaci team
'tak to potom iterativni vyvoj nezvladate dobre' - kdyz mluvime o situaci, ze automatizovane testy pisete spolecne s vyvijenym produktem, tak pri pomerne slozite spolupraci je mozne zahrnout napr. na konci releasu do testu vsechny zmeny (zalezi na urovni dokumentace apod)
'takze rucne pretestuji jen zmenenou cast' - kde jsem prosim Vas uvedl, ze v ramci testu se maji testovat pouze zmenene casti??
ad 1) ano, a co ma byt? na vetsine projektu Unit testy pisi primo programatori, protoze je to pomerne rychlejsi, nez k tomu pustit testera kodu neznaleho testera. da se rict, ze tohle je zalezitost programatorskeho teamu a s testovacim teamem to nema moc co do cineni. jsou samozrejme vyjimky
ad 2) v poradku, DB Unit testy, +/- opet zalezitost programatoru. Bez poradne DB dokumentace nema tester sanci tohle napsat - nezna zmeny na urovni kodu
ad 3) integracni testy - na zaklade Vaseho predchoziho popisu 'ten softwarovy robutek tu aplikaci proklika...' je tohle jedina cast, kde v ramci automatizovanych testu simulujete cinnost uzivatele v aplikaci. jeste jsem nevidel uzivatele, ktery neco naklika v aplikaci a pak jde do DB zjistovat, zda se mu zmeny ulozili korektne
vytvoreni manualnich a/nebo automatizovanych testu zalezi zejmena na rozpoctu pro projekt. v okamziku kdy na 3 programatory mate 1 testera, nemate moc sanci udrzet body 1 a 2 v ramci testerskeho teamu. pokud jste na projektu, kde ma kazdy programator 3 testery, gratuluju
bod 1) se navic vetsinou nespousti 'na vyzadani' ale napr automaticky treba v ramci tvorby nocniho buildu. opet, s timto procesem testovaci team vetsinou nema nic moc spolecneho. stejne tak bod 2), ktery vetsinou spousti vyvojari pres noc
stejne by me zajimalo, jak muzete mit 3x vetsi kod testu nez samotne aplikace, kdyz unit testy (tedy v zasade body 1 a 2) delaji to, ze spusti metodu s definovanymi parametry, vi co z metody vypadne a potom to porovnaji? to je kod na 5 radek kdyz nepocitam komentar treba pro JavaDoc?
ehm, tak bych Vas rad videl jak byste poradne otestoval 'miniprojekt' typu kalkulacka bez pouziti automatizovanych testu
ja nerikam a ani jsem netvrdil, ze je spatne automatizovat. ale rozhodne si stojim za svym a tvrdim, ze ne vse lze automatizovat. jak uvadel Machina prave mobilni operatory - tam je typicky spousta situaci, kde se automatizace da s uspechem pouzit a pouziva se. ale na druhou stranu je tam jeste vetsi cast testu, kde automatizaci nemate sanci zavest, i kdyz by to rozhodne bylo vhodne
clovece vy jste mimo. protirecite si
"Ano, velke testovaci teamy netestuji, ale pisi testovaci scenare, to je pravda. Jenze podle tech scenaru to stejne potom nekdo musi otestovat, bud si na tento ukon firma najme 'klikace z ulice', pripadne to otestuji sami autori techto scenaru"
date mi tam dve moznosti. jedna z nich, testeri "z ulice" je totalni blbost. druha je ta realna stranka, tzn. ze si to programatori (scripteri) poprve otestuji sami. a vy mi tady i presto cpete nejake nesmysly o existenci testovaciho tymu. jasne ze existuje, ale ne proto aby manualne testoval, aby aby psal testovaci scenare
"'tak to potom iterativni vyvoj nezvladate dobre' - kdyz mluvime o situaci, ze automatizovane testy pisete spolecne s vyvijenym produktem, tak pri pomerne slozite spolupraci je mozne zahrnout napr. na konci releasu do testu vsechny zmeny (zalezi na urovni dokumentace apod)" verte mi, ze koordinovat pri kazdem releasu "rucni" testovani vsech novych featur je daleko horsi, nez koordinace vyvoje automatickych testu pri vyvoji. pointa je jasna: kdyz mezi releasem A a releasem B pridam 3 featury, musim k nim napsat jen 3 sady testu. pak se pouze zmackne tlacitko na spusteni testu (nebo se pocka, az se samy vybuildi pres noc). kdybys to ale chtel testovat rucne, musis otestovat rucne nejen ty tri featury, ale i tech 60 featur z predchozich releasu, jestli ti nova funkcionalita nejake z nich nerozbila. a to je extremne narocne na cas a pri samotnem rucnim testovani se delaji chyby, zapomene se na neco atd.
ad 1) 2) 3) vy jste fakt mimo. mluvime tady celou dobu o koze a vy najednou zmatene zacnete blabolit o voze. super. cela pointa bodu 1, 2 a 3 byla ukazat, proc je snadne mit 3x vic kodu v testech nez v samotne aplikaci. a vy do toho pletete nasmysly
"stejne by me zajimalo, jak muzete mit 3x vetsi kod testu nez samotne aplikace, kdyz unit testy (tedy v zasade body 1 a 2) delaji to, ze spusti metodu s definovanymi parametry, vi co z metody vypadne a potom to porovnaji? to je kod na 5 radek kdyz nepocitam komentar treba pro JavaDoc?"
je orpavdu videt, ze mate natestovano 0.00 nic. vase predstava, ze otestujete 50ti radkovou metodu 5ti radkami je opravdu naivni. samotna priprava dat, ktere se do metody vlozi, je narocna. analyza vysledku take. fakovani a mockovani vam zrejme nerika uz vubec nic. jinak by jste takovy nesmysl vubec nevypustil. i hloupy tutorialovy test je stejne dlouho jako testovana trida. viz. zde:
http://www.junit.org/node/477
"ehm, tak bych Vas rad videl jak byste poradne otestoval 'miniprojekt' typu kalkulacka bez pouziti automatizovanych testu"
co mi to cpete? ja tady celou dobu obhajuju automaticke testy a vy vyplodite tohle? vy tady neustale blabolite o rucnim testovani. ja napsal tohle:
"miniprojekt typu kalkulacka lze jeste udrzet na rucnim testovani, ale bezne a enterprise aplikace rozhodne ne" jestli nechapete obsah, tak je to vas problem. ale v tom pripade na to radeji nereagujte
"jak uvadel Machina prave mobilni operatory - tam je typicky spousta situaci, kde se automatizace da s uspechem pouzit a pouziva se." jezis to jsou blaboly na n-tou. machina nic takoveho nerekl. machina naopak tvrdil a pouzival v argumentaci, ze mobilni operatori testuji velkou spoustu veci rucne, viz. jeho prispevek nahore:
"'dnes se rucne testuje snad jen v prehistorickych splecnostech a tech, kde se vyuzivaji specificke hardwary' - blábol číslo 2. Jde vidět že absolutně nemáš představu např. o komplexnosti systémů mobilních operátorů, kde se pro každý test musí ručně tvořit subscription a pod. automatizovat se dá minimálně"
clovece, probudte se. vase argumenty jsou zmatene, protireci si, prekrucujete vyznam nejen mych ale i machinovo slov (a to je co rict) a jeste chcete, aby vam nekdo veril, ze se v dane problematice vyznate? tak na to zapomente :)
To ork: U nás ve firmě je automatických testů méně než těch manuálních, ale já už nemám sílu se s ním o tom bavit, buď mi řekne že lžu a ani v IT nepracuju nebo že jsme primitivní firma. Alespoň že lidi s takovým přístupem jako terrorist se nikdy nedostanou k vedení druhých neboť všechny kolem svým přebujelým egem a povýšeneckým přístupem jen nas..ou.
To terrorist: tvé představy o testingu jsou stejně akurátní asi jako tvých 29fps v SC2 na Atomu
Terrorista asi nepochopi, ze vyvoj a udrzba aut. testu je rozhodne narocnejsi nez vyvoj a udrzba manualnich testu. V exekuci jasne vedou aut. testy, to se asi nemusime bavit. Ale co nasledna analyza chyb (protoze v ramci aut. testu nelze pokryt vsechny chybove stavy aplikace apod.), co reporty chyb, to nastroj (vetsinou) sam neudela a musi to delat clovek. Navic jsme si ani nerekli, jestli mluvi o autom. testech pro 'stabilni' aplikaci (napr. servisovanou), nebo aplikaci ve vyvoji, tohle vsechno musi zohlednit. On samozrejme nemusi, ma pravdu za vsech okolnosti. Vzdavam to, s timto clovekem se bavit postrada jakykoliv smysl, ma jednu linii a po te jde sebestredne a slepe vpred.
"Terrorista asi nepochopi, ze vyvoj a udrzba aut. testu je rozhodne narocnejsi nez vyvoj a udrzba manualnich testu."
LOL a v cem je prosimvas levnejsi vyvoj a udrzba manualnich? pokud chcete zamestnat nejakeho joudu na testovani, nejdriv mu musite vysvetlit, co ma testovat. to stoji nejaky cas. dal mu musite udelat testovaci scenar, aby vedel jak ma testovat a co ocekavat za vystupy, protoze je to jouda z ulice a o9 tom, jak produkt vevnitr pracuje, nic netusi. a to stoji opet cas
jaky je rozdil mezi napsanim testovaciho scenare pro testera do nejakeho PDF a napsanim unit/integracniho testu sam? cas straveny timto postupem je ekvivalentni. ale jeste k tomu pridejte, ze kdyz programator sam pise unit/integracni test, tak tomu rozumi. ale nas jouda tester to muze take blbe pochopit a podelat. udrzovani testu je opet ekvivalentni - bud upravis kod unit/integracniho testu nebo u manualniho testovvani musis za a) testerovi vysvetlit, co se zmenilo b) zmenit mu testovaci scenar. vyvoj a udrzba jsou +- stejne. rozdil je prave a jen v exekuci:
unit/integracni test - doba trvani sekundy, nedela chyby, mesicni plat 0,-
manualni tester - doba trvani, desitky minut az hodiny, dela chyby, mesicni plat v radech 10.000,-
vic neni potreba dodavat. investice je jasna. a ty placas nesmysly. to ze stahujes ocas a utikas, kdyz ti dosly argumenty a snazis se to svest na nejake nesmyslne a nepodstatne charakterove vady, jedine ukazuje, ze tvoje argumenty nemaji vahu. ale to je celkem typicke, ze se kdyz se diskutujicimu nedari vyvratit argumenty, uchyluje se k vyvraceni kredibility oponenta :)
http://cs.wikipedia.org/wiki/Logick%C3%BD_klam#.C3.9Atok_na_.C4.8Dlov.C4...
clovek jako ty s takovouto argumentacni urovni nema pravo kritizovat nekoho jineho ;)
Vy mluvite o EXEKUCI manualnich testu, ja mluvim o uprave manualnich testu, ne o exekuci. Snazte se soustredit na danou vec prosim. Exekuce man. testu je samozrejme narocnejsi a drazsi nez autom. testy, o tom neni sporu. Na druhou stranu, co delate v pripade, kdy Vam nastroj selze, protoze objevil nejakou neznamou chybu? Pak musi prijit clovek a stejne identifikovat, kde je problem. Potom nastroj bud stoji, nebo zaloguje situaci a jede dal. Coz u webovych aplikaci nemusi byt problem, web toolem 'zrestartujete' a projedete dalsi dataset (u tlustych klientu tohle obcas dost dobre nejde), ale vznikly problem stejne musi analyzovat clovek. Autom. testy urychluji (i kdyz vyrazne) pouze exekuci
Co se tyce testeru 'z ulice' - zalezi samozrejme na tom, do jakeho detailu pisete manualni skripty. Daji se napsat (dlouze) do detailu, ze Vam aplikaci oklika skutecne kdokoliv, nicmene ten vyvoj potom bude drahy. Na druhou stranu, testerovi pro vyvoj autom. testu musite stejne rict, co ma testovat a s danou aplikaci se musi taky seznamit
Co se tyce Unit testu, nevim jak u Vas, ale v nasi i ve vsech okolnich firmach je prave zvykem nechat delat Unit tsty vyvojare, stejne tak DBUnit testy. Rozhodne neni pravda, ze je ekvivalentni uprava kodu autom. skriptu a uprava scenare manualniho testu, kde jste k tomuhle prisel? Autom. skript vyjde vetsinou na upravy jako narocnejsi zalezitost, vyplati se skutecne zejmena v exekuci
Co znamena ze integracni testy nedelaji chyby? Stejne jako muzete spatne napsat testovaci skript nebo scenar, muzete napsat spatne i integracni skript a nemusite na to dlouho prijit. A zase rikam, pokud je nasadite v rannych fazich vyvoje, kdy se kod meni doslova pod rukama, tak je udrzba dost slozita
Kdyz uz tady mluvite o investicich a o 10K mesicnich platech, nezapomente do toho taky pripocitat naklady na porizeni daneho nastroje pro autom. testy. Existuji i firmy, ktere pouzivaji volne siritelne nastroje, ale je taky spousta tech, ktere koupi nastroj od HP/IBM za pomerne hutne penize. Oproti temto penezum je mesicni plat nekolika testeru doslova smesnou zalezitosti. Zejmena kdyz licence musite napr. rok co rok obnovovat
Me nedosly argumenty, me pouze nebavi diskutovat s urazlivym egoistickym clovekem jako jste Vy. A netykejte mi prosim, od Vas to zni jako urazka
zase same nesmysly. dokonce si troufnete napsat odstavec, vydavat ho za reakci na muj text, kdyz pritom dokazuje moji pointu:
"Co se tyce testeru 'z ulice' - zalezi samozrejme na tom, do jakeho detailu pisete manualni skripty. Daji se napsat (dlouze) do detailu, ze Vam aplikaci oklika skutecne kdokoliv, nicmene ten vyvoj potom bude drahy. Na druhou stranu, testerovi pro vyvoj autom. testu musite stejne rict, co ma testovat a s danou aplikaci se musi taky seznamit"
"Rozhodne neni pravda, ze je ekvivalentni uprava kodu autom. skriptu a uprava scenare manualniho testu, kde jste k tomuhle prisel?"
pokud ty testy pisete jako amateri bez vyhledu do budoucna, tak celkem chapu, ze to pro vas neni ekvivalentni. ale v takovych neandertalskych firmach je to asi normalni. ale stejne jako se da napsat normalni kod aby se v budoucnu snadno upravoval, da se na snadne upravy v budoucnu pripravit i kod unit testu
"A zase rikam, pokud je nasadite v rannych fazich vyvoje, kdy se kod meni doslova pod rukama, tak je udrzba dost slozita"
opravdu se zda, ze mate s automatickym testovanim mizive zkusenosti, jestli vubec nejake. kdyby jste to zazil, tak by jste vedel, ze kdyz se psani testu nedodrzuje dusledne uz od zacatku, bude vase code coverage miziva, protoze vam ty testy nikdo psat nebude
bezplatne nastroje na automaticke testy jsou dostatecne kvalitni, naprosto ekvivalentni tem komercnim. a kdyz preci jen firma investuje do komercnich, jen to potvrzuje mou pointu. investice se jim vyplati vic. nedelali by to, pokud by o tom nebyli presvedceni. to dela jen vlada CR ;)
vam dosly argumenty. vzdyt si v kazdem druhem odstavci protirecite
Vy jste skutecne pan 'Nekdo'! Vyznam manualnich testu zcela opomijite a snazite se namluvit, ze vsechno jde otestovat za pomoci automatizovanych skriptu
O bodech 1, 2 a 3 jste zacal mluvit Vy, ja bych Unit testy a integracni testy do diskuze o autimatizovanem testovani vubec netahal, zacal jste s tim Vy. Pokud mluvime o automatizovanem testovani jako o 'nahrade' rucniho manualniho testovani, nechapu proc jste s tim zacal a proc jste body 1 a 2 vubec uvedl jako ukazku toho, ze Vami stvorene testy maji 3x vetsi velikost, nez cely zdrojak aplikace. Probrat byste se mel spis Vy.
Mobilni operatori - co mi sem cpete, ze jsem neobhajil Machinu - bud nechapete cteny text, cehoz si diskutujici zde jiz neklikrat vsimli, nebo zamerne lzete - ja jsem uvedl, ze spousta aplikaci u mobilnich operatoru se testuje jak automaticky, tak rucne, i kdyz by se zde nahrada v podobe automatizovanych testu hodila. Zkuste si to precist poradne, chapu, je leto, chlazeni uz neni co byvalo...
Kdyz uz jste zde zminil unit testy - kdyz nejste schopen napsat jednoduche jadro unit testu, ktere projde kod a projde definovane metody s nekolika typy vstupnich dat, nedivim se, ze Vase unit testy zabiraji stejne mnozstvi kodu jako zdrojak aplikace
Shrnul bych to tak, ze Vase teorie, ze automatizovane testy jsou jedine pouzitelne a ze pouze v prehistorickych firmach se testuje manualne, je zcela zcestna. Zrejme pracujete v te jedine spravne firme, ktera dela vsechno tak, jak by se delat melo a vyvoj a udrzba automatizovanych testu je levnejsi nez stejna prace na testech manualnich. Automatizovane testy samozrejme ano, ale nemuzete je pouzit vsude. Ale jak uz jsem zjistil z jinych diskuzi, s Vami je zbytecne se bavit nirmalne
"O bodech 1, 2 a 3 jste zacal mluvit Vy, ja bych Unit testy a integracni testy do diskuze o autimatizovanem testovani vubec netahal, zacal jste s tim Vy. Pokud mluvime o automatizovanem testovani jako o 'nahrade' rucniho manualniho testovani, nechapu proc jste s tim zacal a proc jste body 1 a 2 vubec uvedl jako ukazku toho, ze Vami stvorene testy maji 3x vetsi velikost, nez cely zdrojak aplikace. Probrat byste se mel spis Vy."
od kdy JUnit a DBUnit testy nepatri do automatickych testu, o kterych se tu celou dobu bavime, experte? :D
"Mobilni operatori - co mi sem cpete, ze jsem neobhajil Machinu - bud nechapete cteny text, cehoz si diskutujici zde jiz neklikrat vsimli, nebo zamerne lzete - ja jsem uvedl, ze spousta aplikaci u mobilnich operatoru se testuje jak automaticky, tak rucne, i kdyz by se zde nahrada v podobe automatizovanych testu hodila. Zkuste si to precist poradne, chapu, je leto, chlazeni uz neni co byvalo..."
tak to vase protireceni si jeste jednou vypichneme :)
machina napsal: "blábol číslo 2. Jde vidět že absolutně nemáš představu např. o komplexnosti systémů mobilních operátorů, kde se pro každý test musí ručně tvořit subscription a pod. automatizovat se dá minimálně"
dulezite je "AUTOMATIZOVAT SE DA MINIMALNE"
ty (ork) jsi napsal "jak uvadel Machina prave mobilni operatory - tam je typicky spousta situaci, kde se automatizace da s uspechem pouzit a pouziva se."
LOOOOL tohle nezakecas :)
"Kdyz uz jste zde zminil unit testy - kdyz nejste schopen napsat jednoduche jadro unit testu, ktere projde kod a projde definovane metody s nekolika typy vstupnich dat, nedivim se, ze Vase unit testy zabiraji stejne mnozstvi kodu jako zdrojak aplikace"
je mi jasne, ze jste o JUnitu jen nekde cetl a v praxi nikdy nepouzil. mozna az dostudujete stredni skolu, tak se k tomu dostanete. 5ti radkove testy se daji napsat tak mozna na metodu co scita dva integery a vraci vysledek. zbytek je pouze vase naivita :D
vyvoj automatickeho testu (at uz JUnit nebo integracniho) je jednorazova vec. pak uz se ve vetsine pripadu nemeni nebo se jen minimalne upravuje. zabere to jednorazovou investici v radu desitek minut. DAL UZ NIC. manualni test pri KAZDEM provedeni zabere dost casu. pokud tohle nevidite, tak jste ignorant
shrnul bych to tak, ze jste jeste student a zapojil jste se do neceho, na co ocividne nemate. nebo pracujete prave v nejake neandertalske firme a snazite si udrzet sam pred sebou tvar, co ja vim :) kazdopadne je vase snazeni velmi zabavne :D
Jenom kratce - v bodu diskuze 6. 5. 2011 16:55 jste tvrdil tohle: 'ten softwarovy robutek tu aplikaci proklika uplne stejne na obou platformach - win/x86 i win/arm'. Vzhledem k tomu, o cem jste s Machinou bavil predtim, vyplyva, ze myslite automatizovane testy, simulujici cinnost uzivatele v systemu. V tom pripade nechapu, proc jste do toho pozdeji zahrnul Vase 3x vetsi testy, do kterych jste uvedl i Unit a DBUnit testy. Z hlediska simulace cinnosti uzivatele v systemu tohle nejsou automatizovane testy a taky o tomhle se celou dobu bavim, to ze Vy skacete z tematu na tema neni muj problem. Potom se Vam mohlo zdat, ze jsem zmateny ja a pletu do toho nejake 3 body, ovsem s temi jste zacal Vy sam
Na reakci Vasi 'jak uvadel Machina prave mobilni operatory - tam je typicky spousta situaci, kde se automatizace da s uspechem pouzit a pouziva se' mohu uvest pouze to, ze jako vzdy vytrhavate vety z kontextu, k teto vete se vaze jeste nasledujici veta 'ale na druhou stranu je tam jeste vetsi cast testu, kde automatizaci nemate sanci zavest, i kdyz by to rozhodne bylo vhodne'. Stojim si za nazorem, ze u mobilnich operatoru je velka spousta casti, ktere automatizovat jdou, ale mnohem vice aplikaci, ktere z ruznych duvodu automatizovat nejdou, pripadne velice tezce. Dokud jsem u zadneho mob. operatora nepracoval, mel jsem podobny nazor jako Vy, ze automatizovat jde vsechno - nejde
Automatizce, o ktere zrejme mluvite (totiz jednoduche upravy v radech minut) neni lehce dosazitelna v prubehu vyvoje aplikace, je pouzitelna zejmena pro servisovane aplikace. Chapu ze kdyz vyvojari do aplikace dodelaji Login, muzete ho v autom. testech udelat jako jednu tridu a tu pouzijete vsude jinde. Ale kdyz Vam behem vyvoje v kazde iteraci zmenu jenom blbou homepage 30x, protoze klient si preje dalsi zmeny, ktere predtim nediskutoval, tak se vyvoj autom. testu prodrazi a bude mene efektivni, nez manualni testy.
Autom. testy by se samozrejme mely pouzivat, ale Vase tvrzeni, ze jsou nasaditelne vzdy a vsude, za vsehc situaci, je skutecne dost mylne. Pokud myslite ze neni, tak mi prosim odpovezte, zda jsou vsechny SW spolecnosti na svete prehistoricke (samozrejme krome Vasi), jelikoz vsichni na svete testuji i manualne?
o la la :D
ty si stale myslis, ze machinovo "AUTOMATIZOVAT SE DA MINIMALNE" a tvoje "tam je typicky spousta situaci, kde se automatizace da s uspechem pouzit a pouziva se" zakecas? navic nejakym vytrhnutim z kontextu? ne, v zadnem pripade. to jsou dve protirecici si vyjadreni. tvuj dovetek mi pripomina jednu nadhernou vec ze skveleho ceskeho filmu 'Vrat se do hrobu'
Valná většina dnešní mládeže již našla zodpovědný přístup k životu, existuje však ještě nejméně 50% těch, kteří životní zodpovědnost teprve hledají.
co se tyce tveho tvrzeni (nebo spis cilene lzi), ze s temi tremi body jsem prisel ja bez tveho pricineni, tak te rad exposnu:
"Pokud jste se dostal na projekt, kde kod automatizovanych testu byl 3x vetsi nez kod aplikace - super, bud jste testovali miniaturni aplikaci, nebo pisete kod automatizovanych testu zbytecne neefektivni"
a ja jsem temi tremi body krasne ukazal, ze nemas pravdu :) a je jedno, jestli JUnit/DBUnit testy pisou jen programatori a integracni testy programatori i testeri. oboji jsou automaticke testy. oboji se pousti pri nocmich buildech aplikace. ze se ti to nehodi do diskuze, protoze to vyvraci tvoje slabe argumenty, me vazne nezajima :)
"Autom. testy by se samozrejme mely pouzivat, ale Vase tvrzeni, ze jsou nasaditelne vzdy a vsude, za vsehc situaci, je skutecne dost mylne."
opet lzes. ja uz na zacatku psal:
"a ano, existuji oblasti, kde se takto testovat neda a to je prave hardware oblast, kde se testuje spoluprace softwaru s mnoha druhy hardware a nebo primo systemovy software pro dany hardware (low level). tam je testovani obtizne. ale takovych firem je minimum"
"Pokud myslite ze neni, tak mi prosim odpovezte, zda jsou vsechny SW spolecnosti na svete prehistoricke (samozrejme krome Vasi), jelikoz vsichni na svete testuji i manualne?"
dalsi logicky klam. ty se me ptas na otazku, jejiz podstata vychazi z lziveho argumentu "jelikoz vsichni na svete testuji i manualne?". to v zadnem pripade neni pravda. manualne se testuje jen v neandertalskych firmach, jako je ta ve ktere delas (nebo na strednich skolach, jako je ta tvoje). mozna by se zdejsim ctenarum vyplatilo si ten wikiclanek precist a pak si znovu procist tvoje prispevky. to se hned ukaze tvoje argumentacni uroven a ferovost
http://cs.wikipedia.org/wiki/Logick%C3%BD_klam
nashle priste :D
taky jedu v Seleniu :)
Selenium je hezka vecicka
Na projektech kde je to mozne pouzivam AutoIT (bohuzel Win only), zato pouzitelne i pro nektere tluste klienty (s Javovskymi tlustymi klienty si moc nerozumi, ale komunita dodala potrebne knihovny a podpurne tooly), zkuste, volne siritelny tool i pro komercni pouziti
moc děkuju, rád vyzkouším :-)
a kdo mi prosím znovu zkompiluje všechny mé "staré" x86 aplikace a hlavně několik let staré hry, které si z nostalgie občas zahraji?
M$ pro tebe udělal virtualPC abys mu neutekl jinam :D
My to asi nevyřešíme, takže prostě uvidíme, jak to bude...
(Ale já osobně jsem si dost jistý, že právě na funkčnost her se MS dost zaměří).
No zde by hodně mohla pomoci virtualizace
Virtualizace??? Na ARMu???? To má být vtip, ne???!! Virtualizované Windows 95 na PXA270 @ 624MHz se načetly po dvaceti minutách bootování!! A to jsem jim byl milostiv a dal 24MB RAM!!! Pro srovnání, vlastnil jsem notebook s Pentium 90MHz a 8MB RAM, tam mi Win95 naběhly do minuty. Představa, že na nějakém čtyřjádrovém 2.5GHz ARM ořezávátku se snažím rozjet virtualizované GTA Vice City mě naprosto děsí a zcela odrazuje od této skutečnosti, to už bych raději hral GTA IV na mobilním Sempronu s HD4225...
Jo a pro rejpaly, podpora hardwarové virtualizace není možná, leda že by procesor uměl nativně spouštět x86. instrukce
No myslel jsem spíš na další generace ARMU ..
Na ARMU to ale bude zázrak a virtualizovaně všechno poběží ještě rychleji než nevirtualizovaně, to nevíš? :-D, zeptej se zdejších ARM-věřících
machino, kdyz microsoft vyda windows 8 i pro arm, bud si jisty, ze svuj druhy nejvyznamejsi produkt pro arm vyda take. o tom muze pochybovat jen ignorant
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.