Programozás kategóriaarchívum

Két kellemetlen billentyű

Ha valaha szavazást rendeznének arról, hogy vajon melyik két billentyű okozta a legtöbb bosszúságot a számítástechnikában eltöltött hosszú évek alatt, én természetesen a két legelvetemültebbre adnám a voksomat. Ők ketten a Caps-Lock és az Insert.

A Caps-Lock még az írógép korszakában kezdte pályafutását, ezt a billentyűt lenyomva az írógép olyan reteszelt állapotba került, hogy gépeléskor a betűkarokon lévő nagybetűk érték el a festékszalagot, így a papíron csupa nagybetű jelent meg. Ennek például nyomtatványok kitöltésekor volt értelme, mert így nem kellett állandóan a Shift emelő billentyűt nyomni a nagybetűk előállításához. Az írógép akkor állt vissza az alapállapotába, amikor a reteszelő billentyűt újra lenyomtuk (akinek volt írógépe, az tudja, hogy az írógép billentyűk leütéséhez lényegesen nagyobb erő szükségeltetett, mint egy finom klaviatúrán történő szöveggépeléshez), ilyenkor a retesz kioldott, és újra a kisbetűk váltak alapértelmezetté.

Amikor a számítástechnika elindult hódító útjára, előbb a teletype-ok, majd a terminálok billentyűzetei vették át az írógépek billentyű-kiosztását, és persze ezzel együtt átvették a Caps-Lock billentyűt is. Ez is “Lock-Unlock” működésű, azaz egyszeri lenyomásra aktivizálja a nagybetűket, ilyenkor tehát a Shift egyidejű lenyomása nélkül is nagybetűket írunk, újbóli lenyomása pedig visszaállítja az eredeti állapotot, akárcsak az írógép esetében.

Közben azonban nagyot változott a világ, és számítógépen már egyre kevesebbszer volt arra szükség, hogy hosszabb, csupa nagybetűből álló szöveget kelljen írnunk. Sőt, ha erre mégis szükség lenne, jóval egyszerűbb, ha olyan szövegszerkesztővel dolgozunk, amellyel a kijelölt szöveg egy makróval, vagy paranccsal egyszerűen nagybetűsre váltható.

Míg tehát az írógép nem volt programozható, a számítógép viszont már igen, a Caps-Lock valójában mára már teljesen feleslegessé vált. Ennek ellenére mindmáig rajta van a számítógép billentyűzeten, és nemcsak, hogy rajta van, de ráadásul rendkívül rossz helyen található. Amíg az írógépnél teljesen logikus volt, hogy a Shift fölé tegyék a Caps-Lock-ot, addig a számítógépnél ez hihetetlen mennyiségű bosszúságot képes okozni.

Sokan vannak, akik nem tíz ujjal gépelnek a klaviatúrán, ők (és én is közéjük tatozom), többet nézik a klaviatúrát, mint a képernyőt. Így elég ha, – amikor a Shift felé nyúlnak – véletlenül megbökik a Caps-Lock-ot, és mire észreveszik, már tekintélyes mennyiségű csupa nagybetűs szöveget sikerült beírniuk.

Ilyenkor az első teendő egy mérgeset ütni a Caps-Lock-ra, majd helyreállítani a hibásan gépelt szöveget (ilyenkor jól jöhet egy intelligens szövegszerkesztő). Majd folytatjuk az írást a következő véletlen Caps-Lock lenyomásig, újra egy mérges ütés a Caps-Lock-ra, újra korrekció, majd kezdődik minden elölről.

A billentyűzet-gyártók tehetnék a Caps-Lock-ot egészen máshová, tehetnének a Num-Lock mellé egy Caps-Lock inaktivátort, de a software gyártók is inaktiválhatnák a Caps-Lock-ot opcionálisan a termékeikben. De senki nem tesz semmit. A 21. század első évtizedének közepe felé, ez az élősdi, még mindig ott éktelenkedik a billentyűzeteken.

A probléma legjobb megoldását én a Keytweak nevű programban találtam meg. Ez egy rendkívül hasznos program, – és ezen felül még ingyenes is – és arra jó, hogy a billentyűzet kiosztást dinamikusan megváltoztassuk. Ha csak annyit csinálunk, hogy a Caps-Lock-ot átváltoztatjuk valamilyen hasznosabb billentyűvé, már óriási hasznot hajthat nekünk ez a program. Mivel én magyar billentyűzetet használok, és nagyon sokat programozok, a programokban igen gyakori karaktereket ({}[];<>) csak az Alt-Gr segítségével tudom elérni. A ‘;’ pl. éppen ferdén az Alt-Gr felett van, két kézzel nehéz leütni, egy kézzel pedig két ujj kissé nyakatekert mozgatására van szükség a ‘;’ beírásához. Mondanom sem kell a programozási nyelvek forrásszövegeiben a ‘;’ az egyik leggyakoribb karakter, utasítások lezárásához, vagy elválasztásához használja szinte kivétel nélkül minden nyelv (van néhány ebből a szempontból példamutató programnyelv, mint amilyen a Groovy, de ezek sajnos más szempontból nem optimálisak). Én éppen ez imént elmondottak miatt választottam az Alt-Gr-t a Caps-Lock kiváltójának, így pl. a szögletes zárójelet Alt-Gr-rel és Caps-Lock-kal is be tudom vinni a szövegbe.

Régebben is léteztek már ilyen registry tippek a Caps-Lock helyettesítésére, de mennyivel egyszerűbb a Keytweak-kel hangolni a billentyűzetet, mint belenyúlkálni a registry-be. Minden elismerésem és köszönetem a Keytweak készítőjének, sok bosszúságtól kímélt már meg ez a rendkívül ügyes és jól megírt program.

1.ábra: A Keytweak segítségével “átmappelhetjük” a Caps-Lock billentyűt

Az Insert billentyűvel egészen más a helyzet. Ennek a billentyűnek nem volt írógépes múltja, valaki valamikor nagyon rosszul úgy döntött, hogy ez lesz az a billentyű, amivel több más funkciója mellett a “beszúrás-felülírás” üzemmódot váltani lehet. Az írógépen érthető módon nem volt beszúrás, felülírás is csak úgy, hogy egy festékes papírral eltüntettük a hibás karaktert, majd ráütöttük a jót, ha szerencsénk volt, nem nagyon látszott a javítás.

A számítógépen persze van rendes beszúrás, és felülírás is, és e két üzemmódot váltogatni lehet az Insert nyomogatásával. Idő közben aztán az emberek megszokták, hogy mindig beszúrás üzemmódban használják a szövegszerkesztőjüket, mert egyszerűbb törölni a hibás részt, majd beírni az újat, mint átváltani felülírás módba, és felülírni a hibás szöveget, majd visszaváltani újra a beszúrás módba. Persze erről az Insert billentyű nem vesz tudomást, ő hűségesen váltogatja a két módot minden egyes véletlen lenyomásra, márpedig az ember, programozás közben szorgalmasan ütögeti véletlenül ezt a túlbuzgó billentyűt is, mivel éppen a Delete felett van. Így amikor egy gyors törléshez a Delete felé nyúlunk, nyilván az Insert-et fogjuk megnyomni, így mire észrevesszük, nem csak a törlendő karaktert fogjuk még mindig a helyén látni, de azt fogjuk tapasztalni, hogy a program szöveg egy jelentékeny részét sikerült felülírnunk. Ilyenkor jönnek elő a csúnya szavak, és a derék programozó ilyenkor hirtelen nagyon kíváncsi lesz arra, hogy vajon kinek az áldásos tevékenysége révén van részünk eme földi nyomorúságban.

A jobb programfejlesztő környezetek (IDE) rendelkeznek az Insert billentő funkciója letiltásának lehetőségével is. A NetBeans pl. egy ilyen IDE, de a Delphi sajnos még mindig nem került olyan fejlett állapotba, hogy az Ins ilyen funkciója kikapcsolható legyen. Lehet, hogy most már iOS-re is írhatunk programot vele, de ha véletlenül megnyomjuk az Insert-et még mindig ugyanolyan csúnya szavak fogják elhagyni a szánkat, mint mondjuk 15 évvel ezelőtt. És ezt nevezik egyesek fejlődésnek. Gordon Moore törvénye szerint, a számítástechnikai kapacitás minden másfél évben duplázódik, viszont semmilyen tendencia nem látható egyelőre az “Insert-toggle” kihalásával kapcsolatban. Néha tényleg azt hiszem, hogy a számítástechnikai ipar mozgató erői nem használnak számítógépet.

2. ábra: A Netbeans lehetőséget ad az Ins “billentő” funkciójának kikapcsolására is. (Mindenkinek így kellene!)

A Keytweak segíthetne az Insert esetében is, viszont nem fog, mert a Shift-Insert és a Ctrl-Insert is átdefiniálódna az Insert-tel együtt, így kénytelenek lennénk a “másolás”-“beillesztés” funkcióhoz a Ctrl-C, Ctrl-V párost használni, ami nekem valahogy nem esik a kezemre. És ráadásul a Total Commader is az Insert-et használja a fájlok kijelöléséhez, – ez egy általam igen gyakran használt, nélkülözhetetlen funkció – tehát emiatt az Insert marad. És marad a véletlen felülírás is, egészen addig, míg az összes programban beállítható nem lesz az Insert váltó funkciójának a tiltása. Én például, amikor magamnak írok szövegszerkesztőt, eszembe sem jut, hogy a program ismerje a felülírás üzemmódot is, csak beszúrás üzemmódban hajlandó működni, így persze nem használja az Insert váltó funkcióját sem. És tökéletesen ellátja a szövegszerkesztési feladatokat.

Nem tudom, mi lenne az igazán jó megoldás. Attól tartok, hogy egy mindent szabályozó hivatal, – ami például megmondaná, hogy egy számítógép billentyűzetnek hogyan kell viselkednie – csak addig lenne jó, amíg jó szabályokat hozna, az első hülye szabály emberekre kényszerítése után elsöpörné őket a népharag. Viszont ez az abszolút szabályozatlanság sem jó, mert olyan logikátlan, megkövesedett hagyományokat követünk ennek következtében még mindig, amelyeknek az evolúció szabályai alapján már régen el kellet volna kopniuk a technika világából. Lehet, hogy ezért sem hiszek az evolúcióban? Mert nemcsak fejlődés van, hanem tehetetlenség is.

Néha az emberek annyira megszoknak bizonyos dolgokat, hogy már nem is tudják elképzelni, hogy másképp is lehetne, pl. Caps-Lock és Insert nélkül…

Ui: Volt valaha egy Power billentyű is a billentyűzeteken, ez mára már valahogy kikopott. Érdekes, hogy nekem semmi problémám nem volt vele (másokkal ellentétben). Ha valaki ezt munka közben véletlenül lenyomta, akkor leállította vele a számítógépét. Mivel ez a billentyű nem volt útban, én soha nem nyomtam meg véletlenül, sőt nagyon szerettem használni: ha este bekapcsolva maradt a gépem, és a leállításhoz nem akartam villanyt gyújtani, akkor csak kitapogattam a sötétben a Power gombot (tudtam merre van), és a gép máris leállt. Megmondom őszintén, ez a gomb nekem hiányzik, annak ellenére, hogy tényleg elég veszélyes volt ebben a formájában.

2013. június 30.

NetBeans: JDK frissítés

A Netbeans a Java fejlesztők ideális, ingyenes eszköze. Működéséhez nemcsak a Java futtató környezet, a JRE szükséges, hanem a Java fejlesztő készlet, a JDK is. Ahogy a Netbeans időről időre verziót vált és frissül, ugyanúgy változik és frissül a JRE és a JDK is. Változásaik azonban nincsenek szinkronban egymással, így ha mindig optimális környezetben szeretnénk fejleszteni, időről időre magunknak kell arról gondoskodnunk, hogy minden a legfrissebb legyen.

Szerencsére a JRE esetében egyszerű a dolgunk, letöltjük az aktuális verziót, majd elindítjuk a telepítőt. A JRE mindig ugyanabba a könyvtárba települ, tehát a friss verzió is ugyanott lesz, mint az előző, így a Netbeans oldaláról semmilyen beavatkozásra nincs szükség, a JRE frissítés után nyugodtan elindíthatjuk a Netbeans-t.

A JDK azért más, mert minden verzió a saját könyvtárába települ, mint azt a következő képen láthatjuk (emellett a régi verzió is a gépen marad, ennek eltávolításáról is nekünk kell gondoskodnunk).

jdk verziók

A Netbeans telepítésekor egyébként megadhatjuk a JDK helyét, így ilyenkor semmi további teendőnk nincsen:

NetBeans JDK

A JDK frissítés telepítése után, hogy ne foglalja a helyet feleslegesen, távolítsuk el a régi verziót, ebben az esetben az “Update 17”-et:

JDK eltávolítás

Ha nem frissen telepítettük a NetBeans-t, akkor ha ezután megpróbáljuk elindítani, akkor a következő hibaüzenetet kapjuk:

Nincs JDK

De bármit is válaszoljuk a kérdésre, a Netbeans ezekután már nem fog megfelelően futni. Meg kell keresnünk azt az állományt, ahová az első telepítéskor a Netbeans bejegyezte a JDK fellelhetőségét, és ezt az információt korrigálnunk kell. Rövid keresgélés után ráakadunk a Netbeans telepítési könyvtárában, az etc alkönyvtárban a netbeans.conf állományra:

netbeans.conf

Javítsuk ki a netbeans_jdkhome paramétert annak megfelelően, hogy hol található az aktuális JDK:

# Default location of JDK, can be overridden by using --jdkhome <dir>:	
netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_18"

Ezután természetesen a Netbeans már hiba nélkül elindítható.

De hogy ne végezzünk félmunkát, állítsuk be a JDK javadoc elérési útját is, azért, hogy a Netbeans futása közben a “Help” menüvel bármikor előhívhassuk a Java dokumentációt.

Ehhez előbb le kell töltenünk a Javadoc állományt, ez jelenleg a https://www.oracle.com/java/technologies/javase-jdk8-doc-downloads.html linken keresztül érhető el.

Csomagoljuk ki a zip fájlt egy erre alkalmas könyvtárba (pl. a Help\jdk6 könyvtárba).

Ezután már csak annyi a dolgunk, hogy a Netbeans “Tools” menüjének “Java Platforms” menüpontján klikkelve, a megjelenő dialógusban megadjuk a Javadoc állományok helyét:

Megjegyzés: ez a cikk több, mint 10 éve íródott, hol van már a Sun, a NetBeans eredeti fejlesztője, és hol van már a JDK 8? Mégis meghagytam ezt az írást, mert a NetBeans 8.2 számomra az eddig legjobban bevált verzió, és a JDK 8 is tökéletesen használható mind a mai napig. Nagyon sok mindenben számomra szimpatikusabb, mint a későbbi Java változatok, a modulokkal mind a mai napig nem tudtam megbarátkozni. Nagyon sok fejlesztéshez tökéletesen elég ez a több, mint 10 éves összeállítás, érdemes továbbra is – akár párhuzamosan más JDK és NetBeans verziókkal – használni, ehhez pedig jó, ha tudjuk, hogy mit kell tennünk egy JDK frissítés után.

2010. február 28.

25 éves a Delphi

Vele voltam a kezdetektől fogva. Amióta a Borland Pascal 7.0 után megjelent, mint Delphi 1.0, azóta dolgozok vele. A legkiemelkedőbb pillanataink: Delphi 1.0, Delphi 5.0, 6.0, 7.0, Delphi 2007, Delphi XE4, XE7, Delphi 10.1 Tokyo, 10.2 Rio. A számozási séma többször is változott, ahogy a tulajdonos is, először Borland Delphi, aztán Codegear Delphi, és most Embarcadero. De a legfontosabb jellemzők megmaradtak: a leggyorsabb fordító, könnyen tanulható nyelv, ami folyamatosan fejlődik, új nyelvi elemekkel bővül, és egy nagyszerű, intelligens, könnyen használható IDE. Egy kiváló kódszerkesztő, egy képernyő tervezővel. A tervező és a VCL nagyon fontos előrelépés volt a Borland Pascal Object Windows Library-ja után.

A Pascal volt az első komoly programozási nyelv, amit megtanultam, és a kedvenc programozási nyelvem maradt mind a mai napig. Natív string típus, ami könnyűvé teszi a szöveg kezelést, a túlcsordulás ellenőrzések megvédenek azoktól a biztonsági kockázatoktól, amikkel oly sok C-C++ program küzd mind a mai napig, rengeteg hibalehetőség, ami sok fejfájást okoz a felhasználóknak. A Delphi gazdag típus és komponens készlete mindenféle fejlesztésre alkalmassá teszi. A “class” típus megkönnyíti az objektumorientált programozást, ami így sokkal kényelmesebb és gyorsabb, mint a régi “object” típussal. A VCL komponensek könnyen használhatóak, logikus mező és metódus készleteik, a mezők és metódus elnevezések mind a minél egyszerűbb programozást segítik. Aktív felhasználói közösség járul hozzá a komponeneskészlet bővítéséhez, nem egyszer ingyenes és nyílt forrású megoldásokkal.

Számomra a Delphi 2007 volt a legjobb kiadás, szeretem, és mind a mai napig fejlesztek vele.A Delphi 6 szintén egy nagyon sikeres verzió volt, majdnem egy évtizedig dolgoztam vele a munkahelyemen. Azonban úgy gondolom, nagyon sok olyan szervezet van, az is, ahol én dolgoztam, akik beleragadtak a Delphi 6 fejlesztésbe, nem léptek tovább időben modernebb versiókra, és most már lehetetlen számukra a váltás. Valahogy olyan ez, mint a COBOL esetében, hatalmas mennyiségű COBOL kód van még a világon, egyszerűen amiatt, mert nem tudják a kódbázist átírni.

Codegear Delphi 2007

Az XE sorozatból az XE7-et szerettem a legjobban. Nagyon jó lépés volt a Starter Edition megjelenése, majd ingyenessé tétele is, amivel a tanulók, a programozással ismerkedők, és a kisvállalkozások kaptak kiváló fejlesztő eszközt. Van egy 10.1 Starter Edition a birtokomban, azzal a jó tulajdonsággal bír, hogy ingyenes marad, és nem jár le a használati engedély, mint a Starter helyébe lépő Community Edition esetében. Ez a kiadás szintén egy jó eszköz a kicsik számára, de az idő korlát bevezetése visszalépés a Starter Edition-höz képest.

És most a negatívumokról. Minden egyes verzió hozott újdonságokat, de hibákat is, az egyetlen verzió, amivel tökéletesen elégedett voltam, az a Codegear Delphi 2007, mindeddig nem találkoztam hibával ebben a verzióban. Jelenleg például, a függvény blokkokban történő közvetlen változó deklarálás hibajelzést generál az IDE felületen, ugyanakkor a kódot hibátlanul le lehet fordítani. És ez a hiba immár két egymás utáni verzióban is előfordul! Egyáltalán nem tesztelte senki ezt a funkciót és a hiba túlélt két kiadást is? A korábbi változatokban is elő-előfordult, hogy az IDE fordítója és a compiler nem működött szinkronban, és nem ugyanazokat a hibákat jelezték, ami persze eléggé bosszantó. És amit nagyon hiányolok, az a verem napló megjelenítése, és a Borland idők gyors súgója (jelenleg még a Delphi súgó is tele van C++ anyagokkal, ami senkit sem érdekel, hiszen Delphi-ben dolgozom!), a súgó hihetetlenül lassú a korábbi chm változathoz képest, csak nyomtam egy F1-et, és láss csodát, a súgó szöveg azonnal megjelent, tömérdek példával együtt! És a legnagyobb probléma, az a hatékony automatikus memória kezelés hiánya, jelenleg a fejlesztő szüntelen, és kilátástalan harcot folytat a memória szivárgással és a védelmi hibák felgöngyölítésével. Mind a mai napig ez a Delphi leggyengébb oldala. Alapvető hiányossága a Delphi-nek egy JavaDoc-hoz hasonló forrás dokumentáló eszköz, amivel html és chm súgókat lehetne előállítani a forráskódban lévő megjegyzésekből, oly módon, hogy ezeket a súgókat az IDE is használni tudja. Azaz, a saját kódjainkról ugyanolyan módon kaphassunk gyors információt programírás közben, mint a Delphi unit-ok tartalmáról.

De bárhogyan is, számomra ez a legjobb programozási nyelv és fejlesztő eszköz, amit ismerek, és persze nagyon várom a következő, 10.4-es kiadást, ami talán éppen a memória kezelés terén fog újdonságokat hozni. És természetesen kívánok a Delphi-nek hasonlóan sikeres következő 25 évet! Együtt, tovább!

Nyíregyháza, 2020. február 15. – 2020. március 22.

A software tesztelés problémái

Mindig is bosszant, amikor akár egy operációs rendszerben, akár egy felhasználói programban bukkanok rá valamilyen hibára. Minél ostobább egy hiba, annál inkább tűnik érthetetlennek, hogy a mai korszerű programfejlesztő eszközökkel hogyan maradhatnak ilyen hibák egy termékben.

Talán mégsem annyira fejlett a programírás elmélete és gyakorlata, mint amennyire hinni szeretnénk ebben? Talán a kapkodás, a pénzhajhászás magyarázza a primitív hibák jelenlétét? Vagy valami egészen másról van szó?

Elkezdtem ezen gondolkodni, és elképzelni egy olyan tesztelő rendszert, amivel ki lehetne szűrni minden programozási és rendszer hibát. És arra jöttem rá, hogy ilyen rendszer nem készíthető, legalábbis ami a tesztek egyik fajtáját, a “black-box” (fekete-doboz, vagy külső) tesztelést illeti.

Ez olyan tesztelési technika, amikor a tesztelő nem rendelkezik a forrásprogrammal, csak a végleges termék van a kezében. Erről kell megállapítania, hogy hibátlan-e vagy sem. Mondjuk, hogy a kezében van a specifikáció, sorban ellenőrzi az abban foglalt elvárásokat, ha mindegyiket sorra vette, és nem talált a futtatás során hibát, akkor ugye hibátlannak tekinthető a vizsgált termék. Egyáltalán nem. A specifikáció ugyanis nem biztos, hogy tartalmazza a különleges eseteket is. Elfogy a hely a lemezen, elfogy a memória, megszakad a hálózati kapcsolat, a felhasználó olyan adatokat ad a programnak, amit a specifikáció szerint nem adhatna, de a felhasználó már csak ilyen, szándékosan, vagy véletlenül olyan feltételek közé viheti a programot, amire a specifikáció készítői nem gondoltak.

De még ha rendelkezünk is egy teljes specifikációval, amely minden határesetre és különleges helyzetre tartalmaz viselkedési leírást, akkor sem teljesíthetjük tökéletesen a tesztelési feladatunkat.

Ennek belátásához nézzünk meg egy nagyon egyszerű esetet, kapunk valahonnan egy max() függvényt (mondjuk egy DLL-ben), ami két egészet vár, és visszaadja a kettő közül a nagyobbikat. Le tudjuk-e úgy tesztelni black-box módszerrel ezt a függvényt, hogy kijelenthessük, a függvény 100%-osan hibamentes és minden körülmények között vissza fogja adni a két kapott egész érték közül a nagyobbat?

Írjunk egy tesztprogramot, tegyük bele a max(1, 2) és a max(2 ,1) hívást, mindkét esetben 2-t kell, hogy kapjunk eredményül. A biztonság kedvéért hívjuk meg a függvényt max(2, 2) módon is, ekkor is 2-t kell, hogy kapjunk. Készen vagyunk vajon a teszteléssel? A kód 100%-osan hibamentes?

Elvileg igen. A gyakorlatban számolnunk kell a rosszindulatú kódoló esetével, ez egy olyan programozó, aki szándékosan hibát rejt el a kódban, ezt ráadásul nagyon fondorlatos módokon tudja megtenni. Az elvileg 100%-osan hibamentes kódunk tehát valójában rengeteg hibát rejthet magában.

Mert mi van, ha a kódban van egy részlet, ami a kapott argumentumoktól függően működik, és ha valamelyik argumentum mondjuk 1 000 000, akkor nem a nagyobb, hanem a kisebb argumentumot adja vissza. Ezt csak úgy tudjuk tesztelni és a hibát detektálni, ha 1 000 000-ig mindenféle kombinációban meghívjuk a max() függvényt. És mivel nem tudhatjuk, hogy hol van a hiba elrejtve, ki kell próbálnunk nemcsak 1 000 000-ig, hanem a gépen ábrázolható maximális nagyságú egész számig minden hívás kombinációt.

Ez a teszt már tovább fog tartani, mint a legelső, lefuttatjuk, nem találunk hibát. Vajon 100%-osan hibátlannak nyilváníthatjuk most a függvényt?

Nem, még nem. A programozónk lehet még ennél is rosszindulatúbb, és elrejthet dátumhoz és időponthoz kötött hibát is. Ennek megtalálásához az összes elképzelhető dátumra és időpontra be kell állítanunk a gépünk óráját, és meg kell ismételnünk az összes lehetséges egész szám kombinációra a tesztet, hiszen a programozó a dátum-, és az argumentum vizsgálatot össze is kapcsolhatta úgy, hogy a függvény elképzelhető, hogy csak az elkövetkező ötven év egyetlen bizonyos másodpercében egyetlen kombinációra fog hibás választ adni, a többi esetben hibátlan lesz. De elég egyetlen hiba ahhoz, hogy a kódot ne tekinthessük tökéletesen hibamentesnek.

Azt hiszem, már látjuk a reménytelen jövőt. A rosszindulatú kódolónk az argumentumok és a rendszeridő mellé odaveheti a program méretét, az összes-, és a szabad memória méretét, azt, hogy egy bizonyos regiszterben páros-, vagy páratlan szám van-e éppen, letárolhatja, hogy hányszor hívták már meg, és ettől függően működik jól, vagy rosszul. Gyakorlatilag végtelenek a lehetőségek, emiatt pedig teljesen esélytelen, hogy emberi idő alatt végezzünk.

Persze mondhatjuk, hogy ezek a példák eléggé abszurd rosszindulatot tételeznek fel a kódolónk részéről, de mi most nem azt vizsgáltuk, hogy mennyire életszerű ez az elképzelés, hanem annak szerettünk volna utánajárni, hogy elvileg lehetséges-e a tökéletes black-box tesztelés.

Én az eddig elmondottak alapján bizonyítottnak látom, hogy külső eszközökkel nem állapítható meg egy programról, vagy kódról, hogy az hibátlan-e vagy sem. Még százalékos becslést sem tudunk mondani, hiszen nem tudjuk, hogy egy-egy felderített hibára hány felderítetlen jut.

Ezzel nem szeretném még véletlenül sem azt a látszatot kelteni, hogy felmentést érdemelnek mindazok, akik hibás kódot adnak ki a kezükből. Szó sincs erről. Egyszerűen tény, hogy a black-box tesztelés nem adhat nekünk teljes biztonságot.

Hogy akkor hol keressük a teljes biztonságot? Elsősorban a saját magunk számára készített saját kódunkban bízhatunk meg, hiszen arról tudjuk, hogy nem egy rosszindulatú kódoló írta, és nem abból a célból, hogy kárt okozzon vele. Másrészt fokozottan megbízhatunk azokban a nyílt forrású kódokban, amiket elvileg sokan ellenőrizhetnek, így kiderülhet, ha esetleg rosszindulatú kód van benne. Bár attól, hogy valami nyílt forrású, még nem biztos, hogy ellenőrzött. Elvileg minden nyílt forrású kód mellé kapnunk kellene egy ellenőrzési listát arról, hogy ki, mikor, milyen részeket, és milyen mélységig elemezte a kódot. Mondanom sem kell, ilyen manapság nem létezik, és elképzelni is nehéz hány ember-év kellene egy-egy nyílt forrású program ellenőrzési listájának elkészítéséhez. És ez a lista, csak az első módosításig lenne megbízható, utána felül kellene vizsgálni minden egyes módosítás után.

Mivel láttuk, hogy a black-box tesztelés milyen határok között megbízható, nézzük meg, hogy vajon javíthatunk-e a megbízhatóságán. Ehhez a “black-box”-ot valamennyire ki kell nyitnunk, azaz bele kell néznünk a kódba is. Ehhez nyomkövetőt, visszafordítót, vagy automatikus elemző programot használhatunk. Így már némileg több esélyünk van arra, hogy rátaláljunk egy-egy furcsa konstansra, vagy feltételes ugró utasításra, ami rosszindulatú kódra utalhat. Ez például egy max() függvény esetében még működhet is, de hát egy max() függvényt mi magunk is megírhatunk ahelyett, hogy a rengeteg időt az elemzésére fordítanánk. Csakhogy a kódok legtöbbször sokkal-sokkal bonyolultabbak a példánkban szereplő max() függvénynél. Egy nagyobb programban nyomkövetéssel, vagy visszafejtéssel rátalálni valamilyen rejtett kódra anélkül, hogy a teljes program működését megértenénk, nagyon nagy feladat.

Úgy néz ki tehát, hogy a “nyitott black-box” technikával, vagy akár a nyílt forrású kód elemzésével sem fogunk tudni eljutni a 100%-os bizonyosságig.

Hogy más eszközökkel juthatunk-e ennél messzebbre, arra példaként a legjobb, ha a víruskeresőket vizsgáljuk meg egy kicsit közelebbről, vajon ők milyen szintre jutottak a rosszindulatú kódok automatikus felderítésében. Sajnos azt mondhatjuk, nagyon sok a bizonytalanság. Amikor egy amúgy népszerű, széles körben használt, megvásárolt kereső heurisztikus elemzését kell kikapcsolni, mert olyan programokat töröl le, amik nélkül nem tudunk dolgozni (nem egyet saját magunk írtunk), akkor úgy tűnik, az elemzés vagy olyan kódot is gyanúsnak talál, ami nem az, vagy pedig túl engedékeny és elnéző, ezzel a valóban vírusos kódot is veszélytelennek mutatja.

Talán az automatikus kódelemzéstől 100%-os teljesítményt várni ugyanolyan lehetetlen elvárás, mint olyan program megírásában bízni, amely bármely másik programról megmondja, hogy végtelen ciklusba kerül-e, vagy megáll majd valamikor. Erről már tudjuk, hogy lehetetlen. Talán a kártékony kód és a programhibák automatikus elemzéssel történő 100%-os detektálása is ugyanilyen lehetetlen feladat. Erre persze nem tudok bizonyítással szolgálni.

Itt lenne az ideje annak, hogy valaki elkészítsen egy, Hilbert 23 pontos listájához (ami a matematika megoldandó problémáit sorolta fel) hasonló listát a nyitott, még megoldandó számítástechnikai problémákról, ezen a listán szerepelhetne a kérdés: “Lehetséges-e programhelyesség bizonyító programot írni, ha nem, akkor miért nem?”. Talán már látjuk is a választ a kérdésre, valószínűleg a megállási probléma megoldhatatlansága a kulcs itt is.

Tudom, hogy ha elkészülne egy ilyen program, akkor először ennek a helyességéről kellene meggyőződni, és talán ez az az ok, ami miatt soha nem fog elkészülni ez a program sem…

Nyíregyháza, 2018. szeptember 27 – 2019. április 7.