XMLja ne rabiš pretvarjat v binarno obliko, zakaj bi ga? Če ga hočeš shranit, ga enostavno zapišeš kot neki.xml in je to to. Je pa res, da če moraš imet urejen elektronski arhiv, če hočeš ta dokument hranit, brez da bi ga moral natisnit na papir.

Glede arhiviranja je pa po mojem spominu (s tem sem delal 2 leti nazaj) tako: Arhiviraš lahko datoteke tipa xml in pdf/a (torej pdf, ki je primeren za arhiviranje). eSlog je zgolj ena od specifikacij (ne vem, če ravno standard) za elektronske račune.

S poštarco sicer nisem delal, ampak pri integraciji z enim od sistemov za arhiviranje, ki je prav tako rabil ovojnico, se je pa delalo sledeče: v ovojnico poleg naziva datoteke (in ostalih podatkov o datoteki) dodaš tudi hash vsebine. In potem se cela ovojnica tudi digitalno podpiše/žigosa.

Druga varianta (in verjetno dejanski odgovor na tvoje vprašanje), če pa res rabiš vsebino nekako prebrat, je pa Base64 encoding/decoding.

XML: <?xml version="1.0" encoding="utf-8"?>

XSLT: <?xml version="1.0" encoding="ISO-8859-1"?>

In za vse ostale: XSLT se ful pogosto uporablja za vizualizacijo XMLjev. Ni treba brihtovat o parsanju v HTML ipd.

Dejmo najprej probat ugotovit, kaj pomeni 'predlog Googla' - "Google suggestion".

In ne, pri meni ni na prvem mestu.

V uvodni objavi sem pač mislil, da se s testiranjem že ukvarjaš in da te zdej zanima, kako bi v čimvečji meri uporabil avtomatiko.

Glej, firmi je itak jasno, da tega še nisi počel in ti bodo razložil vse step-by-step, brez skrbi. Ponavadi ne grizejo - samo kakšen prepotenten developer je včasih mal težak :P

Verjetno bo na začetku zgledalo enostavno tako, da ti bojo povedal kaj mora aplikacija počet, ti jim boš pa z vso svojo kreativnostjo dokazoval, da nimajo prav :)

Pa daleč od tega, da bi te hotel kaj strašit okrog testiranja - zna bit prav zanimivo, pa še veliko stvari se naučiš. Najbolj pogoste napake, na kaj moraš bit kot razvijalec pozoren (če boš nadaljeval v tej smeri), naučiš se gledat na problem iz večih zornih kotov... in še in še...

Kot zanimivost: mene so najprej "porinili" za par tednov na testiranje in jst sem ves zagret vnašal bug reporte - potem so pa rekli "zdej boš pa še malo programiral", pa sem moral vse najdene buge popravit :) In nekaj časa se je ta cikel lepo vrtel, tako da sem spoznal projekt tako "spredaj" (kot uporabnik) kot "zadaj" (kot razvijalec). Res dobrodošla izkušnja, čeprav ti ni v prvih dneh nič jasno :)

Aja, pa še tole 3:

čim vsaj približno razmišljaš/razmišljate o avtomatiziranem testiranu, je treba najprej developerje nabutat, da naj ne kodirajo traparij - ampak pišejo "testable" kodo. Kot tester se boš veliko prekregal z njimi :)

Žal odgovor ni tako enostaven, kot je vprašanje :)

Odvisno od tipa projekta. Ko sem še kot študent delal v eni softverski firmi (nekje 6-7 let nazaj) kot tester, se je precej uporabljal nUnit za unit/regression teste in pa selenium oz. watin za web gui teste (govorim za asp.net/c# spletno aplikacijo). Seveda so to le orodja/frameworki, teste moraš pa skodirat sam.

Se je pa precej stvari po potrebi tudi spisalo 'iz nule'.

In ja, iz prve roke lahko povem, da je dobro QA orodje/okolje včasih težje sprogramirat, kot pa produkt sam. Niso testerji samo opice, ki slepo klikajo in poročajo errorje - vsaj tisti pravi ne :)

Aja, še tole: tako watin kot selenium mislim, da imata celo neke 'recorderje'. Tako, da si enostavno posnameš npr. nek test case (testni scenarij), ki ti ga potem recorder ponudi kot kodo, ki jo potem (teoretično) samo skopiraš v projekt. V praksi seveda mal počistiš, da iz 50 vrstic nastane 20 vrstic kode :)

Aja, še tole 2: kot rečeno, to so informacije izpred 6-7 let. :)

Jst grem pa sredi julija izzivat usodo v Izrael, yeah yeah :) Tko, da če me od takrat naprej ne slišite več, je šlo nekaj narobe: teroristi, vojna al pa infarkt :P

Dol je že od konca februarja 20°C, od aprila pa se že konstantno drži nad 30°C. Sploh si ne upam predstavljat, kako izgledajo top temperature :)

Da vam povem, za kaj so cookie-ji :)

falil, ignore pls :P