A kiadás egy háló, nem egy verziószám
Csatlakozott játékok és alkalmazások ritkán frissítik, mint egy osztható objektum. A játékos nyithat egy régi kliens, miközben a szolgáltatás már megváltozott. A tartalom katalógus frissítheti előtt az ügyfél, hogy megértse az új elemet. A konfigurációs kimenet elérheti az egyik régió előtt egy másik. A backend is elfogadja mind a régi és az új kérési formák egy ideig, majd visszavonja az adapter. Kezelése mindezt, mint "verzió 42" elrejti a kapcsolatokat, hogy a legvalószínűbb, hogy összeomlik alatt valódi kigurulás feltételek.
Először is nevezze meg a verzió dimenziók külön. Legalább, rekord kliens épít, backend vagy szolgáltatás felülvizsgálata, protokoll verzió, séma vagy mentés verzió, tartalom katalógus verzió, konfigurációs verzió, és a migrációs állapot. Néhány termék is szüksége van a set- back verzió, favore- zászló set, operating- rendszer képesség, számla kohort, vagy régió. A cél nem az, hogy hozzon létre egy hatalmas táblázat a saját érdekében. Ez az, hogy felfedje, ha egy összetevő értelmezi egy másik komponens kimenete.
A hasznos kérdés nem az, hogy "vajon a legújabb kliens átmegy?" Ez ", mely kombinációk egymás mellett létezhetnek, mit kell minden kombinációnak tennie, és mely kombinációk tiltottak?" A kompatibilitási politika ezt a kérdést határolt tesztterületté változtatja. Megnevezi az elfogadott tartományokat, fordítókat, kill kapcsolókat, kecses elutasításokat, és a kiguruló kapukat, mielőtt egy gyártási esemény bekövetkezne, a csapatot arra készteti, hogy találgasson.
A kompatibilitás korlátozásai mindkét irányban
A kompatibilitás gyakran aszimmetrikus. Egy új backend elfogadhat kéréseket egy régi ügyféltől, míg egy régi backend nem érthet meg egy új ügyfelet. Egy új ügyfél olvashat egy régi mentést a migráció után, míg egy régi ügyfél nem nyithatja meg újra a vándorló verziót. Az új tartalom ártalmatlan lehet a régi ügyfelek számára, ha egy funkció zászló alatt rejtik el, de veszélyes, ha egy régi ügyfél egy ismeretlen terméktípust érvényes alapértelmezésként kezel.
Írjon le minden kényszert, mint kapcsolatot a várt viselkedéssel. Például: kliens 5 kézbesítés ellenében hitelesíthető 7 protokollon keresztül 2; ügyfél 4 olvashatja a katalógust 10 csak akkor, ha az X típusú tételeket kizárták; a séma mentése 3 lehet migrálódni 5 támogatott széleken keresztül; konfiguráció 12 nem szabad lehetővé tenni, hogy a kliensek a build alatt 6. Tartalmazza a nem támogatott kombinációk: blokk mutáció előtt, szolgálja a kompatibilis ábrázolás, útvonal a szükséges frissítést, vagy tartsa a változást, amíg a régi kohort lefolyók.
Ne hagyatkozzon csak a verziók összehasonlítására. Egy magasabb szám nem bizonyít képességet, és egy régebbi szám sem bizonyítja, hogy a funkció hiányzik. Használjon képességi tárgyalásokat vagy explicit kompatibilitási metaadatokat, ahol praktikus. A metaadatok tesztelésre szorulnak; a hiányzó zászló véletlenül nem jelenti azt, hogy "biztonságos".
Kockázatközpontú mátrix létrehozása
A teljes Cartesian termék lehet hatalmas. Négy kliens épít, három szolgáltatás, négy tartalomváltozat, és öt konfigurációs államok már létre 240 kombinációkat, mielőtt platform és a migrációs állapot mérlegelik. Tesztelés minden lehetséges tuple lehet lassabb, mint a felszabadítási ciklus, és még mindig hiányzik a határ, ami számít. Ehelyett készítsen egy kockázatorientált mátrix megszorítások és a változás hatása.
Mindig tartalmazza a legújabb kompatibilis útvonal, a legrégebbi still-támogatott út, és az átmeneti határok. Hozzáadás kombinációk, amelyek átlépik a megváltozott protokoll mező, migrációs széle, tartalom értelmezési szabály, jogosultsági út, vagy a funkció zászló. Tartalmazzon legalább egy görgős alakú útvonal: az ügyfél vagy szolgáltatás visszatér egy korábbi kompatibilis állapot után az új állam megfigyelt adatok. Ha a változás valóban elszigetelt, rögzítse, miért nem bővíti a mátrix helyett halkan feltételezve, hogy nem.
A páronkénti generáció segítheti a kölcsönhatásokat, de nem helyettesítheti az ítéleteket. Néhány hiba három vagy négy dimenziót igényel az összehangoláshoz: egy régi kliens, egy új katalógus, egy vándorló mentés, és egy konfigurációs zászló biztonságos lehet minden párban, mégis érvénytelen együtt. Adja hozzá a nevesített forgatókönyv teszteket ezekre a termékspecifikus kockázatokra. A mátrixot azoknak az embereknek kell átnézniük, akik megértik a funkciókat, nem csak egy tesztgenerátornak.
Tesztelje a régi és az új kliensek együtt
Az együttélés egy normális állapot. Szimulálni kell egy régi kliens létrehozása vagy módosítása állam, miközben egy új ügyfél olvassa, majd vissza a megrendelést. Test reconnects, párhuzamos ülések, megszakított frissítési letöltések, és a felhasználó, aki újra egy másik eszköz. Minden út, azonosítsa, melyik oldalon van hiteles értelmezés. Az ügyfél nem találhat ki egy új mező érték, hogy a szolgáltatás később úgy kezeli, mint megbízható, csak azért, mert mindkét frissítették egy helyi tesztfutás.
A protokoll változtatások kifejezett adaptereket érdemelnek. Ha egy mezőt átneveztek, kiterjesztenek, vagy több értékre osztanak, teszteljék a régi ábrázolást, az új ábrázolást és minden fordítási réteget. A fordításnak meg kell őriznie a dokumentált jelentést, vagy el kell utasítania a kérést egy nem biztonságos mutáció előtt. A hihető, de hibás alapértelmezést visszaadó szerver veszélyesebb lehet, mint egy egyértelmű inkompatibilitás, mert elterjed a csendes korrupció.
Ügyfél kompatibilitás magában foglalja a felhasználói élményt. Ha egy régi építmény nem képes biztonságosan folytatni, a frissítési útvonalat meg kell jeleníteni előtt egy nagyratörő művelet, nem után egy sikertelen tranzakció. Ha egy funkció van elrejtve a régi építmények, erősítse meg, hogy rejtve marad a menü, mély linkek, toló-szerű belépési pontok, és restaurált ülések. A helyes backend döntés még mindig úgy érzi, törött, ha az interfész bemutatja a művelet a jelenlegi kliens nem teljes.
A tartalom és a konfiguráció mint végrehajtható függések kezelése
Tartalomkatalógusok és távoli konfiguráció gyakran tekinthető operatív adatok helyett kódot. Egy élő rendszerben, ezek végrehajtható függések, mert megváltoztatják, hogy mit jelentenek az azonosítók, mely funkciók, és mely szabályok alkalmazandók. Teszteljenek egy új tartalomkatalógust régi és új ügyfelek. Teszteljenek egy állott konfigurációs cache egy új szolgáltatás. Tesztelje a funkció zászló, amely lehetővé teszi a kódsáv előtt az előírt tartalom van jelen. Teszteljen egy tartalomvisszaállítás után néhány játékos szerzett hivatkozások az új rekordra.
A katalógus bejegyzésnek ki kell jelölnie a megjelenítéshez vagy végrehajtáshoz szükséges mezőket és képességeket. A konfigurációs csomagnak azonosítania kell az általa elvárt klienst vagy szolgáltatástartományokat. Ha a rekord egy elérhetetlen képességtől függ, válassza ki a biztonságos viselkedést: rejtse el, helyettesítse a dokumentált defback-et, halassza el az aktiválást, vagy állítsa le a kijelentkezést. Ne használjon olyan általános alapértelmezést, amely véletlenül ad egy elemet, megkerüli a jogosultsági ellenőrzést, vagy megváltoztatja a progressziót.
A mentett állam, különböztesse meg a séma migráció a szemantikai migráció. A séma változás adhat hozzá egy mező egy alapértelmezett. Szemantikai változás visszavonhat egy elemet, megoszthatja a küldetést, vagy megváltoztathatja a gazdaság szabály. Az utóbbi szüksége van domain invariants és helyreállítási döntések, nem csak a deserializer teszt. Rekord, amely változata a katalógus és konfiguráció értelmezte a mentett állam, különösen, ha a visszajátszás vagy támogatás vizsgálat kell reprodukálni az eredményt.
Bizonyítsd be, mielőtt a kiadásnak szüksége lenne rá.
A Rollback nem csak régi kódot használ. Kérdezze meg, hogy egy régi ügyfél tud-e olvasni az új ügyfél által írt állapotot, hogy egy régi szolgáltatás képes-e értelmezni az új kéréseket, hogy a tartalomjegyzékek új bérlőt igényelnek-e, és hogy a migráció átlépett-e egy egyirányú határt. Néhány változás csak akkor érhető el. Ez elfogadható, ha bejelentik, de megváltoztatja a felszabadítási tervet: egy megrendezett kohortot, egy kompatibilitási ablakot, egy biztonsági vagy pillanatfelvételi politikát, és egy támogatási útvonalat az azonnali visszatérés helyett.
Teszt visszafordítási képesség, mint egy forgatókönyv. Kezdje a régi kompatibilis készlet, előre egy komponens, hogy egy reprezentatív állapot változás, majd mozgassa a kiválasztott komponens vissza. Szerezze meg a várt állapot: folyamatos kompatibilitás, csak olvasható biztonság, ellenőrzött elutasítás, vagy tervezett helyreállítás. Az eredmény meg kell nevezni, hogy mit hajtottak végre, és mi szimulált. A felülvizsgálat soha nem tévesztheti össze a tervezési diagram egy végrehajtható tekercs próba.
Tartsa a döntés kimenetét rövid és konkrét. A kiadás rekord lehet megadni: támogatott kompatibilitási tartományok, forgatókönyvek végrehajtott, ismert nem végrehajtott kockázatok, változások, amelyek csak, kigurulás kapuk, és feltételek a leállítás. Ez nem követelheti az egyetemes biztonságot, mert a mátrix átment. A becsületes eredmény egy bizonyítékkal támogatott felszabadítási határ.
A bizonyíték szétbontása a közösségi gazdasági ágazatban
Futass egy kis kompatibilitási füst be minden változás, amely érinti a megosztott szerződések. Futtatás kiterjesztett szilánkok, amikor az ügyfél, protokoll, mentés, tartalom, konfiguráció, vagy kigurulás kód változások. Darabok forgatókönyv szerinti család helyett véletlenszerű kombinációk: hitelesítés és session restauration, vásárlás és jogosultság, migráció és mentett állam, tartalom renderelés, tulajdoni-kötött viselkedés, és tekercs. Ez tartja a hibák jelentőségteljes, és teszi a költségek egy új dimenzió látható.
A CI jelentésnek meg kell őriznie a tuple alatt vizsgálat és az eredmény osztályozás. Tartalmazza kliens build, szolgáltatás felülvizsgálata, protokoll, tartalom és konfiguráció verziók, rögzítés vagy forgatókönyv ID, környezeti típus, és az első sikertelen kompatibilitás szabály. Kerülje a dömpingszámla vagy a játékos állapota. Ha egy forgatókönyv szimulált, címkét. Ha egy forgatókönyv fut szemben végrehajtható adapter vagy homokozó, címkézés, hogy is. Bizonyíték minősége része a kiadás döntés.
Ezeket a jelentéseket a kigurulás kiszélesítése előtt felül kell vizsgálni a kiadás tulajdonosaival; a kompatibilitási bizonyíték egy döntési alap, nem pedig egy dekoratív műszerfal.
Használjuk a hiba minimalizálását, ha egy mátrix eset megtörik. Az első meghibásodás tartalmazhat felesleges verziókat vagy zászlók. Tartsa a determinista környezet mozdulatlan, csökkenti a dimenziókat, miközben megőrzi a kompatibilitási hiba, és tárolja az így kapott minimális forgatókönyv regressziós esetben. Ez teszi a mátrix értékesebb idővel, ahelyett, hogy folyamatosan egy zajos gyűjteménye történelmi balesetek.
Gyakorlati ellenőrzőlista
- Név kliens, szolgáltatás, protokoll, séma, tartalom, konfiguráció, és a migráció dimenziók külön.
- Írjon támogatott, lefordított és tiltott kompatibilitási kapcsolatokat a várt viselkedéssel.
- Ide tartoznak a régi támogatású, az újonnan támogatott, az átmeneti és a visszaforgatott forgatókönyvek.
- Adja hozzá a megnevezett többdimenziós vizsgálatokat, ahol a páros lefedettség nem elegendő.
- Tesztelje a régi és új ügyfelek létrehozása, olvasás, és újra az állam ugyanazon szolgáltatási határon.
- A katalógus és a konfiguráció módosítása végrehajtható kompatibilitási függésekként kezelendő.
- Csak vándorlásokra vonatkozik, és megrendezett kivándorlási vagy helyreállítási tervet nyújt.
- Jegyezze fel, hogy a bizonyítékokat szimulálták-e, végrehajthatók-e helyben, homokoztak-e, vagy külső ellenőrzés alatt állnak-e.
- Tartsuk fenn a minimális sikertelen tuple, mint egy felülvizsgált regressziós forgatókönyv.
Gyakran feltett kérdések
A páros tesztelés elég a kioldáshoz?
Páronkénti lefedettség egy hasznos módja annak, hogy csökkentse a nagy mátrix, de nem tudja bizonyítani az összes többdimenziós korlátok. Használja széles körű interakció lefedettség, majd adjunk explicit forgatókönyveket a magas kockázatú kombinációk, mint például a vándorló állam plusz új tartalom plusz egy régi ügyfél, vagy egy visszaállítás után egy konfigurációs kapu megváltozott.
Mikor kell egy régi ügyfelet blokkolni?
Blokkolja a mutáció előtt, ha nem tudja biztonságosan értelmezni a szükséges tartalmat, kielégíteni a protokollszerződést, vagy olvasni a jelenlegi államhatárt. A világos frissítési követelmény biztonságosabb, mint folytatni egy alapértelmezett, ami megváltoztatja a jelentést. A pontos politika a termékspecifikus, de az állapotot és a felhasználóarcú viselkedést együtt kell tesztelni.
A funkció zászló megoldja kompatibilitás önmagában?
Nem. A zászló képes irányítani az expozíciót, de nem tudja, hogy egy összeegyeztethetetlen protokoll, séma, vagy tartalom rekord biztonságos. Tesztelje a zászló tárolt és frissített államok, a függőség az ügyfél képességek, és mi történik, ha változik, miközben a munkamenet aktív.
Mit jelent ez az Persistium-ről?
Persistium egy fejlesztetlen helyi-első megbízhatóság termék család. Ez a cikk leírja a teszt-design megközelítés, nem azt az állítást, hogy a kiadott termék automatikusan generál minden mátrix vagy biztosítja a házigazda kiadás menedzsment. Folytonosság iránya vizsgálja határolt bizonyítékokat a fajta kompatibilitási döntések itt leírt.
