Hogyan kipróbálást és a hibakeresést az adatbázis
Theodore A. Samorodov. Hogyan kipróbálást és a hibakeresést az adatbázis
Automatikus tesztelés egység (unit teszt) alkalmazás kódját - ez egyszerű és egyértelmű. Hogyan kell ellenőrizni az adatbázis? Vagy olyan alkalmazás, amely működik az adatbázist. Végtére is, az alap - nem csak egy programkód, adatbázis - az objektum megtartja állapotát. És ha elkezdjük a tesztelési folyamat változtatni az adatokat az adatbázisban (anélkül, hogy milyen vizsgálatok fogunk?!), Akkor minden vizsgálat után alapján változhat. Ez megakadályozhatja a későbbi vizsgálatok és visszafordíthatatlanul károsítja az adatbázis.
A legfontosabb, hogy a probléma megoldásának - a tranzakciót. Egyik jellemzője ez a mechanizmus az, hogy mindaddig, amíg a tranzakció nem fejeződött be, akkor mindig vetni a módosításokat, és térjen vissza az adatbázist az állami elején a tranzakciót.
- nyitott ügylet;
- amennyiben szükséges, elvégzi az előkészítő lépéseket tesztelés;
- végezze egység teszt (vagy csak futtatni a programot, amely szeretné tesztelni a munkát);
- Megvizsgáljuk az eredmény a forgatókönyvet;
- törölje az ügyletet, visszatérve az adatbázis az eredeti állapotába.
Még ha a teszt kód marad lezáratlan ügyletek, külső ROLLBACK mindig visszaállíthatja az összes változtatást helyesen.
Nos, ha kell tesztelni az SQL-script vagy tárolt eljárás. És ha teszteljük az alkalmazást, amely maga az adatbázishoz csatlakozik, megnyitva egy új kapcsolat? Ezen kívül, ha részt veszünk a hibakeresés, akkor biztosan szeretné megnézni a szemét a bázis a kérelem hibakeresést. Hogyan lehet ebben az esetben?
Ne rohanjon levelet osztott tranzakció van egy egyszerű megoldás! Rendszeres segítségével SQL-szerver, akkor nyissa meg a tranzakció ugyanazt a kapcsolatot, és azt egy másikon folytathatja.
Ehhez csatlakozik a szerverhez, nyisson meg egy ügyletet, hogy a tranzakciós megszerezni a token, majd adja át ezt a jelzőt a kérelem szerinti vizsgálat. Ez az ülésén csatlakozzon tranzakciókat, és onnantól kezdve látni fogjuk az adatokat a debug session (érezhető, ahogy a zár), ahogy látják a kérelem szerinti vizsgálat.
A sorozat akciók a következő:
Start a tranzakció a debug session, tudnunk kell, hogy id. Ez egy egyedülálló karakterlánc, amelyen a kiszolgáló megkülönbözteti a tranzakciót. Ezt az azonosítót kell valahogy át a kérelem szerinti vizsgálat.
Most a feladat az alkalmazás - mielőtt elkezd csinálni, amit állítólag, ragaszkodunk a vezérlő tranzakciót.
Ezután az alkalmazás kezd dolgozni, többek között induló saját tárolt eljárásokat megnyitni az ügyleti változtatni a módot az elszigeteltség. De a debug session minden, ami idő lesz ugyanazon ügylet az alkalmazást.
Tegyük fel, hogy egy alkalmazás zárolja az asztalra, és változni kezd annak tartalmát. Ezen a ponton, nincs más kapcsolat, hogy vizsgálja meg a lezárt asztal nem. De nem a mi debug session! Belőle, akkor nézd meg a bázist ugyanúgy mint ahogy a kérelmet, így az SQL-szerver úgy véli, hogy mi vagyunk az egyetlen tranzakció.
Míg az összes többi ülés a melléklet rejtett zár.
a debug session van csendesen áthalad a zár (szerver azt hiszi, hogy a saját lock)!
Vagy képzeljük el, hogy az alkalmazás kezd dolgozni saját változatát a sorok a Snapshot mód. Hogyan néz ezekbe verziók? Még ez is lehetséges, ha csatlakozik egy közös tranzakciós!
Ne felejtsük el, a végén ezt a lenyűgöző folyamat visszaszorítása tranzakció-ellenőrző. Ezt meg lehet tenni a debug session (ha a tesztelési folyamat befejeződött normális), és az alkalmazás (ha ez történik valami váratlan).