Zaščita testnih podatkov pri testiranju z UI
Neuspešen avtomatiziran test se navadno hitro popravi. Posnetek zaslona iz testnega zagona, ki vsebuje podatke o strankah, cenike ali aktivno sejo in konča pri zunanji AI storitvi, je drugačen problem. Kdor želi zaščititi testne podatke pri testiranju z UI, mora zato upoštevati ne le testne primere, temveč celotno pot podatkov: vhode, promet brskalnika, dnevnike, slike, UI vrednotenje in obdobje hrambe.
Zlasti pri spletnih aplikacijah, notranjih portalih in Windows programski opremi hitro nastane lažen občutek varnosti. Okolje se sicer lahko imenuje „testno“, vendar pogosto uporablja kopije produkcijskih baz podatkov, prave uporabniške vloge ali vmesnike do odpreme, ERP-ja in arhivov dokumentov. Testiranje s podporo UI naredi te podatke še posebej vredne za analizo — in s tem še posebej potrebne zaščite.
Zakaj testiranje z UI zahteva lasten pogled na varstvo podatkov
Klasična avtomatizacija testov običajno preverja jasno definirane korake: prijava, ustvarjanje naročila, generiranje dobavnice, preverjanje odjave. Testiranje s podporo UI ta postopek razširi. Sistem lahko razlaga uporabniške vmesnike, ocenjuje anomalije, primerja posnetke zaslona in dokumentira rezultate v razumljivem jeziku. To prihrani čas pri regresijskih testih, a ustvarja dodatne podatkovne artefakte.
Ti artefakti so pogosto bolj zgovorni kot običajen testni dnevnik. Posnetek zaslona lahko prikaže imena, naslove, pogodbene vrednosti, količine naročil ali zdravstvene podatke. Omrežni dnevnik lahko vsebuje seje-tokene in odgovore API-ja. Sporočilo o napaki lahko razkrije notranje poti do datotek, strukture baz podatkov ali različice. Ko model dela s temi informacijami, mora biti jasno, kje poteka obdelava in kdo ima dostop do nje.
Odločilno vprašanje torej ni: „Ali uporabljamo UI pri testiranju?“ Temveč prej: „Kateri podatki zapuščajo katero varnostno cono — in zakaj?“ Za mnoga podjetja v regiji DACH zunanja obdelava v oblaku ni načeloma izključena. Vendar mora ustrezati zahtevam varstva pogodbeno, tehnično in organizacijsko. Za razvojne, produkcijske ali podatke o strankah je pogosto lokalno nadzorovano izvajanje bolj pragmatična odločitev.
Zaščita testnih podatkov pri testiranju z UI se začne pred prvim zagonom
O varstvu podatkov pri testiranju se pogosto govori šele pri izbiri orodja. To je prepozno. Najprej je potreben preprost, zanesljiv popis podatkov. Kateri sistemi se testirajo? Katera polja se pojavljajo v uporabniških vmesnikih? Katere priloge, izvozi in odgovori API-ja se lahko pojavijo v testu? In kateri podatki samodejno pristanejo v posnetkih zaslona, videoposnetkih ali sporočilih o napakah?
Tu se izplača delitev v tri skupine. Nekritične testne podatke je mogoče prosto generirati in hraniti dlje. Osebni ali poslovno zaupni podatki zahtevajo maskiranje, omejitve dostopa in kratka obdobja hrambe. Dostopni podatki, tokeni, ključi in produkcijske konfiguracijske vrednosti ne sodijo v testne dokaze niti v zahteve modelu — tudi če so le po naključju vidni v oknu brskalnika.
Pri mnogih srednje velikih aplikacijah podatkovna situacija ni jasno ločena. Skladiščna ekipa testira nov prevzem blaga z izvlečkom iz baze podatkov, ker so le tam prisotne prave strukture artiklov, dobaviteljska pravila in posebni primeri. To je lahko tehnično smiselno. Posledica pa ne sme biti, da ta izvleček nespremenjen preide v vsako testno okolje.
Boljši je ponovljiv postopek: izvoz podatkov, ciljno psevdonimiziranje občutljivih polj, odstranitev nepotrebnih tabel in zagotavljanje nastale testne podatkovne osnove v verzionirani obliki. Tako se ohranijo tipične napake v procesu, ne da bi bili resnični kupci ali zaposleni vidni v testnih zagonih. Pri zapleteni logiki cen ali razpolaganja povsem sintetični podatki pogosto ne zadostujejo. Takrat je skrbno očiščena kopija ponavadi boljši kompromis.
Maskiranje mora ohraniti poslovno logiko
Maskiranje, ki vsak e-poštni naslov nadomesti z istim nadomestnim znakom, lahko poškoduje testne primere. Preverjanja podvojenosti, logika vlog, funkcije iskanja ali procesi obračunavanja se obnašajo drugače kot v produkciji. Dobro maskiranje zato ohrani oblike, razmerja in porazdelitve. Številka stranke postane druga veljavna številka stranke. Naslov postane verjeten, a fiktiven naslov. Datum dobave ostane datum znotraj realističnega planskega obdobja.
To zahteva nekaj priprav. V zameno preprečuje klasično napako, pri kateri so testi tehnično „zeleni“, a ne odražajo več dejanskih delovnih procesov v skladišču, prodaji ali službi za stranke. Varstvo podatkov in funkcionalno uporabni testi niso nasprotja — če je priprava podatkov del testne arhitekture.
Lokacija izvajanja odloča o nadzoru
Kdor prepusti avtomatizirane teste zunanji storitvi, prepusti — odvisno od konfiguracije — več kot le testne korake. Vsebine brskalnika, DOM strukture, posnetki zaslona, videoposnetki, dnevniki konzole in vrednotenja se lahko obdelujejo in hranijo zunaj lastne infrastrukture. Ali je to sprejemljivo, je odvisno od konkretnega primera: kategorij podatkov, pogodbenega okvira, lokacije hrambe, ločitve najemnikov, koncepta brisanja in notranjih smernic.
Pri aplikacijah z visokimi zahtevami po zaščiti je samostojno gostovano testno okolje pogosto lažje ocenljivo. Izvajalec testov, UI komponenta in shramba dokazov ostajajo znotraj lastnega omrežja podjetja ali v nadzorovani evropski infrastrukturi. Omrežna pravila lahko omejijo zunanje povezave. Dostop je mogoče povezati z obstoječimi identitetami, vlogami in beleženjem. Hramba slik in poročil s tem postane lastna odločitev, ne privzeta nastavitev ponudnika platforme.
COCO sledi natanko temu pristopu: strežnik UI izvaja teste za spletne in Windows aplikacije nadzorovano, dokumentira dokaze in generira razumljiva vrednotenja, ne da bi bilo treba notranje podatke aplikacije privzeto predati zunanjemu UI oblaku. To ne nadomesti revizije varstva podatkov. Ustvarja pa tehnično osnovo, na kateri se IT, informacijska varnost in poslovni oddelek lahko dogovorijo o sledljivih pravilih.
Posnetki zaslona, dnevniki in skrivnosti so najpogostejši uhajanja
Mnoge ekipe ščitijo testno bazo podatkov, a spregledajo stranske produkte testiranja. V praksi se prav tam skrivajo večja tveganja. Neuspešen test prijave lahko prikaže geslo v vnosnem polju. API test lahko izpiše token nosilca v dnevnik. Samodejni videoposnetek dokumentira celotno naročilo, vključno z naslovom stranke. Robusten koncept zato ureja vsaj pet točk:
- Posnetki zaslona in videoposnetki nastajajo samo po potrebi in se izbrišejo po fiksnih rokih.
- Skrivnosti se vključujejo prek shrambe skrivnosti ali zaščitenih spremenljivk izvajalnega okolja, nikoli shranjene v testni kodi.
- Dnevniki pred shranjevanjem filtrirajo tokene, gesla, ID-je sej in občutljiva polja.
- Testni računi imajo le pravice, potrebne za posamezen delovni proces.
- Testni sistemi ne smejo sprožiti produkcijskih e-poštnih sporočil, nalepk, plačil ali skladiščnih premikov, razen če je to izrecno zavarovano.
Ta pravila zvenijo trezno. Prav v tem je njihova prednost. Ekipi ni treba upati na pozornost ali dobre namene, temveč lahko zlorabo tehnično omeji. Posebej učinkoviti so ločeni servisni računi za avtomatizacijo testov, kratka življenjska doba tokenov in jasen postopek za preklic ogroženih dostopnih podatkov.
Tudi UI vrednotenje potrebuje meje
UI modeli se pogosto uporabljajo za pojasnjevanje odstopanj: „Gumb ni bil viden,“ „Aplikacija se je odzivala počasneje kot pričakovano“ ali „Proces se je končal pri preverjanju pravic.“ Za takšne ocene model nujno ne potrebuje popolnega nabora podatkov o strankah.
Zato določite, katere informacije smejo vstopiti v vrednotenje. Ali zadošča anonimiziran posnetek zaslona? Ali namesto celotnega odgovora strežnika zadošča tehnični razred napake? Je mogoče polja pred analizo zakriti? Prava globina je odvisna od cilja testa. Pri primerjavi postavitve je ime redko relevantno. Pri preverjanju personalizirane predloge dokumenta je lahko relevantno — takrat mora biti obdelava ustrezno zavarovana.
Zaščitni ukrepi morajo ostati preverljivi v obratovanju
Koncept je robusten le, če ga je mogoče nadzorovati v vsakdanjem delovanju. Sem sodijo redna naključna preverjanja testnih dokazov, pregledi pravic in vpogled v dejansko shranjene podatke. Ali so se v posnetke zaslona prikradla nova polja? Ali še obstajajo stari testni računi? Ali se izvleček iz baze podatkov hrani dlje, kot je bilo predvideno? Takšna vprašanja sodijo v redno operativno rutino, ne le v revizijo.
Enako pomembna je jasna odgovornost. QA pozna testne procese, razvoj pozna tehnične vmesnike, poslovni oddelek pozna kritične procese, IT varnost pa določa okvir. Če teh vidikov nihče ne poveže, nastane bodisi tvegana bližnjica bodisi varnostna specifikacija, ki onemogoča prave teste. Majhen, dokumentiran postopek odobritve je običajno učinkovitejši od obsežnega nabora pravil, ki jih nihče ne uporablja.
Na koncu ne gre za to, da bi vsak test umetno zapletli. Dobra zaščita testnih podatkov pomeni zavestno odstranjevanje resničnih tveganj iz avtomatizacije ob hkratnem ohranjanju funkcionalne veljavnosti testov. Ko ekipe natančno vedo, katere podatke sme test videti, kje se nahajajo njegovi dokazi in kdaj izginejo, postane testiranje z UI nadzorovano orodje namesto dodatne negotovosti.