Keskusyksikön testaus

Antaa oppia ennen keskusyksikön testauskonseptien oppimista

Mikä on keskusyksikkö?

Keskusyksikkö on suorituskykyinen ja nopea tietokonejärjestelmä. Sitä käytetään laajempiin laskentatarkoituksiin, jotka edellyttävät suurta saatavuutta ja turvallisuutta. Sitä käytetään enimmäkseen sellaisilla aloilla kuin rahoitus, vakuutus, vähittäiskauppa ja muut kriittiset alueet, joilla valtavia tietoja käsitellään useita kertoja.

Mainframe Testing on prosessi, jolla testataan ohjelmistosovelluksia ja -palveluja, jotka perustuvat Mainframe Systems -järjestelmiin. Keskuskoneen testauksen tarkoituksena on varmistaa ohjelmistosovelluksen tai -palvelun suorituskyky, luotettavuus ja laatu tarkistamalla ja vahvistamalla menetelmiä ja tarkistamalla, onko se valmis käyttöönottoon.

Suorittaessaan keskusyksikön testausta testaajan on tiedettävä vain CICS-näyttöjen navigoinnit. Ne on räätälöity tietyille sovelluksille. COBOL-, JCL- jne. Testaajan koodiin tehtyjen muutosten ei tarvitse huolehtia koneeseen asennetusta emulaattorista. Yhdellä pääteemulaattorilla toimivat muutokset toimivat muilla.

Mainframe-sovellusta (muuten kutsutaan työeräksi) testataan vaatimuksia käyttäen kehitetyissä testitapauksissa
Keskusyksikön testaus suoritetaan yleensä käytetyllä koodilla käyttämällä erilaisia datayhdistelmiä, jotka on asetettu syötetiedostoon.
Keskuskoneella suoritettaviin sovelluksiin pääsee pääteemulaattorin kautta. Emulaattori on ainoa ohjelmisto, joka on asennettava asiakaskoneeseen.

Tässä aloittelijan opetusohjelmassa opit-

Mainframe-attribuutit
Manuaalisen testauksen luokittelu keskusyksikössä
Kuinka tehdä keskusyksikön testaus
Keskuskoneen automaation testaustyökalut
Metodologia suurkoneiden testauksessa
Erätestaukseen liittyvät vaiheet
Verkkotestaukseen liittyvät vaiheet
Vaiheet online - eräintegraation testauksessa
Mainframe-testauksessa käytetyt komennot
Edellytykset keskusyksikön testauksen aloittamiseksi
Parhaat käytännöt
Keskusyksikön testaushaasteet ja vianetsintä
Kohdatut yhteiset keskeytykset
Keskusyksikötestauksessa kohtaama yleinen ongelma

Mainframe-attribuutit

Virtuaalinen tallennustila
1. Se on tekniikka, jonka avulla prosessori voi simuloida päämuistia, joka on suurempi kuin todellisen tallennustilan todellinen määrä.
2. Se on tekniikka, jolla muistia käytetään tehokkaasti erikokoisten tehtävien tallentamiseen ja suorittamiseen.
3. Se käyttää levytallennusta todellisen tallennustilan laajennuksena.
Moniohjelmointi
1. Tietokone suorittaa useita ohjelmia samanaikaisesti. Mutta kulloinkin vain yksi ohjelma voi hallita suorittinta.
2. Se on tarjottu tila CPU: n tehokkaaseen käyttöön.
Eräkäsittely
1. Se on tekniikka, jolla mikä tahansa tehtävä suoritetaan yksiköinä, jotka tunnetaan työpaikoina.
2. Työ voi aiheuttaa yhden tai useamman ohjelman suorittamisen peräkkäin.
3. Työn ajoitus tekee päätöksen järjestyksestä, jossa tehtävät tulisi suorittaa. Keskimääräisen suorituskyvyn maksimoimiseksi työt ajoitetaan prioriteetin ja luokan mukaan.
4. Eräkäsittelyyn tarvittavat tiedot saadaan JCL: n (TYÖNHALLINTAKIELI) kautta. JCL kuvaa erätyöt - tarvittavat ohjelmat, tiedot ja resurssit.
Ajan jakaminen
1. Ajanjakojärjestelmässä jokaisella käyttäjällä on pääsy järjestelmään päätelaitteen kautta. Sen sijaan, että lähettäisit myöhempää suoritusta varten ajoitetut työt, käyttäjä syöttää välittömästi käsiteltävät komennot.
2. Tästä syystä tätä kutsutaan "vuorovaikutteiseksi prosessoinniksi". Sen avulla käyttäjä voi olla vuorovaikutuksessa suoraan tietokoneen kanssa.
3. Ajanjako-prosessointi tunnetaan nimellä "etualan käsittely" ja eräajotyö tunnetaan nimellä "taustankäsittely".
Kelaus
1. SPOOLing on lyhenne sanoista Simply Peripheral Operations Online .
2. SPOOL-laitetta käytetään ohjelman / sovelluksen tuotoksen tallentamiseen. Taustatuloste ohjataan tulostuslaitteisiin (tarvittaessa).
3. Se on laitos, jossa hyödynnetään puskuroinnin etua tulostuslaitteiden tehokkaaksi hyödyntämiseksi.

Manuaalisen testauksen luokittelu keskusyksikössä

Keskusyksikön manuaalinen testaus voidaan jakaa kahteen tyyppiin:

Erätyötestaus -
- Testausprosessi sisältää erätöiden suorittamisen nykyisessä julkaisussa toteutetulle toiminnallisuudelle.
- Tulostiedostoista ja tietokannasta otetut testitulokset tarkistetaan ja tallennetaan.
Verkkotestaus -
- Verkkotestauksella tarkoitetaan CICS-näyttöjen testausta, joka on samanlainen kuin verkkosivun testaus.
- Nykyisten näyttöjen toimintoja voidaan muuttaa tai uusia näyttöjä voidaan lisätä.
- Eri sovelluksissa voi olla kysely- ja päivitysnäyttöjä. Näiden näyttöjen toimivuus on tarkistettava osana online-testausta.

Kuinka tehdä keskusyksikön testaus

Liiketoimintaryhmä laatii vaatimusasiakirjat. Mikä määrittää kuinka tiettyä kohdetta tai prosessia muutetaan julkaisusyklissä.
Testausryhmä ja kehitystyö saavat vaatimusasiakirjan. He selvittävät, kuinka moniin prosesseihin muutos vaikuttaa. Yleensä julkaisussa vain 20-25% sovelluksesta vaikuttaa suoraan räätälöityyn vaatimukseen. Loput 75% julkaisusta on tarkoitettu out-box-toimintoihin, kuten sovellusten ja prosessien testaamiseen.
Joten Mainframe-sovellus on testattava kahdessa osassa:
1. Vaatimusten testaaminen - Sovelluksen testaaminen vaatimusasiakirjassa mainitun toiminnallisuuden tai muutoksen suhteen.
2. Integraation testaus - Testataan koko prosessi tai muu sovellus, joka vastaanottaa tai lähettää tietoja kyseiseen sovellukseen. Regressiotestaus on tämän testauksen ensisijainen painopiste.

Keskuskoneen automaation testaustyökalut

Alla on luettelo työkaluista, joita voidaan käyttää keskusyksikköautomaation testauksessa.

REXX
Excel
QTP

Metodologia suurkoneiden testauksessa

Tarkastellaan esimerkkiä: XYZ-vakuutusyhtiöllä on jäsenten ilmoittautumismoduuli. Se vie tietoja sekä jäsenen ilmoittautumisnäytöltä että offline-ilmoittautumisesta. Kuten aiemmin keskustelimme, Mainframe-testaukseen, online-testaukseen ja erätestaukseen tarvitaan kaksi lähestymistapaa.

Verkkotestaus tehdään jäsenten ilmoittautumisnäytöllä. Aivan kuten verkkosivu, myös tietokanta validoidaan näyttöjen kautta syötetyillä tiedoilla.
Offline-ilmoittautuminen voi olla ilmoittautumista paperilla tai ilmoittautumista kolmannen osapuolen verkkosivustolle. Offline-tiedot (kutsutaan myös eräksi) syötetään yritystietokantaan erätöiden kautta. Litteä syötetiedosto valmistellaan määrätyn datamuodon mukaisesti ja syötetään erätyösarjaan. Joten keskusyksikön sovellusten testauksessa voimme käyttää seuraavaa lähestymistapaa.
- Erätyöt-rivin ensimmäinen työ vahvistaa syötetyt tiedot. Sanotaan esimerkiksi erikoismerkki, aakkoset vain numerokentissä jne.
- Toinen työ vahvistaa tietojen yhdenmukaisuuden liiketoimintaolosuhteiden perusteella. Esimerkiksi lapsen ilmoittautuminen ei saa sisältää riippuvaisia tietoja, jäsenen postinumero (joka ei ole käytettävissä ilmoittautuneen suunnitelman mukaan) jne.
- Kolmas työ muuttaa tietoja muodossa, joka voidaan syöttää tietokantaan. Esimerkiksi suunnitelman nimen poistaminen (tietokanta tallentaa vain suunnitelman tunnuksen ja vakuutussuunnitelman nimen), liittämispäivämäärä jne.
- Neljäs työ lataa tiedot tietokantaan.
Erätyötestaus tehdään tälle prosessille kahdessa vaiheessa -
- Jokainen työ validoidaan erikseen, ja
- Työn välinen integraatio vahvistetaan toimittamalla ensimmäiselle työlle tasainen syötetiedosto ja validoimalla tietokanta. (Välittäjän tulokset on vahvistettava erityisen varoen)

Mainframe-testauksessa noudatetaan seuraavaa menetelmää:

Vaihe 1) : Shakedown / savutestaus

Tämän vaiheen päätavoitteena on tarkistaa, onko käyttöönotettu koodi oikeassa testiympäristössä. Se varmistaa myös, että koodissa ei ole kriittisiä ongelmia.

Vaihe 2) : Järjestelmän testaus

Alla on testityyppejä, jotka tehdään osana järjestelmätestausta.

Erätestaus - Tämä testaus tehdään vahvistamalla testitulosten testitulokset ja testausalueen erätöiden tekemät datamuutokset ja tallentamalla ne.
Online-testaus - Tämä testaus tehdään keskusyksikköohjelman etupäässä. Täällä testataan hakemuksen oikea kenttä, kuten vakuutussuunnitelma, kiinnostus suunnitelmaan jne.
Online-Batch Integration -testaus - Tämä testaus tehdään järjestelmissä, joissa on eräprosessit ja online-sovellus. Online-näyttöjen ja erätöiden välinen tietovirta ja vuorovaikutus vahvistetaan.
( Esimerkki tämäntyyppiselle testaukselle - Harkitse päivitystä suunnitelman tiedoissa, kuten koron korotus. Koron muutos tehdään päivitysnäytössä, ja vain öisin suoritettava erätyö muuttaa kyseisten tilien saldotietoja. tässä tapauksessa tehdään tarkistamalla Suunnitelman tiedot -näyttö ja erätyön ajo kaikkien tilien päivittämiseksi).
Tietokannan testaus - Tietokannat, joissa mainframe-sovelluksen tiedot (IMS, IDMS, DB2, VSAM / ISAM, peräkkäiset tietojoukot, GDG: t) vahvistetaan niiden asetteluille ja tietojen tallennukselle.

Vaihe 3) : Järjestelmän integraatiotestaus

Tämän testauksen ensisijaisena tarkoituksena on validoida testattavan järjestelmän kanssa vuorovaikutuksessa olevien järjestelmien toiminnallisuus.

Vaatimukset eivät vaikuta suoraan näihin järjestelmiin. He käyttävät kuitenkin testattavan järjestelmän tietoja. On tärkeää testata käyttöliittymä ja erityyppiset viestit (kuten onnistunut työ, epäonnistunut työ, tietokanta päivitetty jne.), Jotka voivat kulkeutua järjestelmien ja niistä johtuvien toimintojen välillä.

Tässä vaiheessa tehdyt testaustyypit ovat

Erätestaus
Verkkotestaus
Online - eräintegraation testaus

Vaihe 4) : Regressiotestaus

Regressiotestaus on yleinen vaihe minkä tahansa tyyppisessä testausprojektissa. Tämä mainframe-testaus varmistaa, että nykyinen projektijulkaisu ei vaikuta eräajoihin ja online-näyttöihin, jotka eivät ole suoraan vuorovaikutuksessa testattavan järjestelmän kanssa (tai jotka eivät kuulu vaatimusten piiriin).

Jotta regressiotestaus olisi tehokasta, tietyt testitapaukset olisi valittava niiden monimutkaisuudesta riippuen ja olisi luotava regressiopohja (testitapausten arkisto). Tämä sarja on päivitettävä aina, kun julkaisuun otetaan käyttöön uusi toiminto.

Vaihe 5) : Suorituskyvyn testaus

Tämä testaus tehdään pullonkaulojen tunnistamiseksi suurten osumien alueilla, kuten käyttöliittymätiedot, verkkotietokantojen päivittäminen ja sovelluksen skaalautuvuuden heijastamiseksi.

Vaihe 6) : Suojaustestaus

Tämä testaus tehdään sen arvioimiseksi, kuinka hyvin sovellus on suunniteltu ja kehitetty torjumaan tietoturvan vastaisia hyökkäyksiä.

Järjestelmälle tulisi tehdä kaksinkertainen tietoturvatestaus - keskusyksikön ja verkon suojaus.

Testattavien ominaisuuksien on oltava

Rehellisyys
Luottamuksellisuus
Valtuutus
Todennus
Saatavuus

Erätestaukseen liittyvät vaiheet

Kun laadunvarmistusryhmä on saanut hyväksytyn paketin (paketti sisältää menettelyt, JCL, ohjauskortit, moduulit jne.), Testaajan tulisi esikatsella ja noutaa sisältö PDS: ään tarvittaessa.
Muunna tuotannon JCL tai Development JCL QA JCL: ksi, jota kutsutaan myös nimellä JOB SETUP.
Tuotantotiedoston kopiointi ja testitiedostojen valmistelu.
Jokaiselle toiminnolle määritetään työn järjestys. (Kuten selitettiin Mainframe-osion metodologian esimerkissä) .Työt tulee lähettää käyttämällä SUB-komentoa testitiedostojen kanssa.
Tarkista välitiedosto tietojen puuttumisen tai virheiden syiden selvittämiseksi.
Tarkista testitulokset tarkistamalla lopullinen tulostetiedosto, tietokanta ja taustatulostus.
Jos työ epäonnistuu, kelalla on syy työn epäonnistumiseen. Korjaa virhe ja lähetä työ uudelleen.

Testiraportointi - Vika tulee kirjata, jos todellinen tulos poikkeaa odotetusta.

Verkkotestaukseen liittyvät vaiheet

Valitse Online-näyttö testiympäristössä.
Testaa jokaisessa kentässä hyväksyttävät tiedot.
Testaa testiskenaariota näytöllä.
Tarkista tietokannan tietopäivitykset online-näytöltä.

Testiraportointi - Vika tulee kirjata, jos todellinen tulos poikkeaa odotetusta.

Vaiheet online - eräintegraation testauksessa

Suorita työ testiympäristössä ja vahvista tiedot online-näytöissä.
Päivitä online-näyttöjen tiedot ja tarkista, jos erätyö suoritetaan oikein päivitetyillä tiedoilla.

Mainframe-testauksessa käytetyt komennot

LÄHETÄ - Lähetä taustatyö.
PERUUTA - Peruuta taustatyö.
ALLOCATE - Määritä tietojoukko
COPY - Kopioi tietojoukko
RENAME - Nimeä tietojoukko uudelleen
POISTA - Poista tietojoukko
JOB SCAN - JCL: n sitominen ohjelmaan, kirjastoihin, tiedostoihin jne. Suorittamatta sitä.

Tarvittaessa käytetään monia muita komentoja, mutta ne eivät ole niin usein.

Edellytykset keskusyksikön testauksen aloittamiseksi

Mainframe-testauksessa tarvittavat perustiedot ovat:

Kirjautumistunnus ja salasana sovellukseen kirjautumista varten.
Lyhyt tieto ISPF-komennoista.
Tiedostojen nimet, tiedostomääritin ja niiden tyypit.

Ennen keskusyksikön testauksen aloittamista tulee tarkistaa seuraavat seikat.

Job
1. Suorita työn skannaus (komento - JOBSCAN) tarkistaaksesi virheet ennen sen suorittamista.
2. CLASS-parametri tulee osoittaa testiluokkaan.
3. Suorita työn ulostulo kelaan tai JHS: ään tai tarpeen mukaan käyttämällä MSGCLASS-parametria.
4. Suorita työn sähköposti uudelleen taustatulostukseen tai testipostitunnukseen.
5. Kommentoi FTP-vaiheita alkutestausta varten ja osoita sitten työ testipalvelimelle.
6. Jos työhön luodaan IMR (Incident Management -tietue), lisää kommentti "TESTITARKOITUS" työhön tai param-korttiin.
7. Kaikki työn tuotantokirjastot tulee vaihtaa ja osoittaa testikirjastoihin.
8. Työtä ei pidä jättää ilman valvontaa.
9. Jotta estetään työn suorittaminen virheettömässä silmukassa, TIME-parametri on lisättävä määritetyllä ajalla.
10. Tallenna työn tulos kela mukaan lukien. Kela voidaan tallentaa XDC: llä.

Tiedosto
1. Luo vain tarvittavan kokoinen testitiedosto. Käytä tarvittaessa GDG: itä (Generation Data Groups - Tiedostot, joilla on sama nimi, mutta peräkkäisillä versionumeroilla - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 jne.), Jos haluat tallentaa tietoja peräkkäisiin tiedostoihin, joilla on sama nimi.
2. Tiedostojen DISP (Disposition - kuvaa järjestelmää, joka suorittaa tietojoukon säilyttämisen tai poistamisen normaalin tai epänormaalin vaiheen tai työn lopettamisen jälkeen) tulisi koodata oikein.
3. Varmista, että kaikki työn suorittamiseen käytetyt tiedostot on tallennettu ja suljettu oikein, jotta työ ei mene HOLD-tilaan.
4. Kun testaat GDG: tä, varmista, että oikea versio on osoitettu.
Tietokanta
1. Työtä tai online-ohjelmaa suoritettaessa varmista, että tahattomia tietoja ei lisätä, päivittää tai poistaa.
2. Varmista myös, että testauksessa käytetään oikeaa DB2-aluetta.
Testitapaukset
1. Testaa aina rajaehdot, kuten - Tyhjä tiedosto, Ensimmäisen tietueen käsittely, Viimeisen tietueen käsittely jne.
2. Sisällytä aina sekä positiiviset että negatiiviset testiolosuhteet.
3. Jos ohjelmassa käytetään vakiomenettelyjä, kuten Check point restart, Abend Modules, Control files, jne., Testitapaukset vahvistetaan, jos moduuleja on käytetty oikein.
Testitiedot
1. Testitiedot on tehtävä ennen testauksen alkua.
2. Älä koskaan muokkaa testialueen tietoja ilmoittamatta siitä. Saattaa olla muita tiimejä, jotka työskentelevät samojen tietojen kanssa, ja heidän testi epäonnistuu.
3. Jos tuotantotiedostoja tarvitaan suorituksen aikana, on hankittava asianmukainen valtuutus ennen niiden kopiointia tai käyttöä.

Parhaat käytännöt

Erätyön suorittamisen jälkeen MAX CC 0 on merkki siitä, että työ on suoritettu onnistuneesti. Se ei tarkoita, että toiminnallisuus toimii hyvin. Työ suoritetaan onnistuneesti myös silloin, kun tulos on tyhjä tai ei odotusten mukaisesti. Joten odotetaan aina tarkistavan kaikki tuotokset ennen työn julistamista onnistuneeksi.
On aina hyvä tapa suorittaa testattava työ kuivalla ajona. Kuivakäynti suoritetaan tyhjillä syötetiedostoilla. Tätä prosessia on noudatettava töissä, joihin testisyklin muutokset vaikuttavat.
Ennen testisyklin alkua testityö tulisi tehdä hyvissä ajoin. Tämä auttaa selvittämään kaikki JCL-virheet etukäteen, mikä säästää aikaa suorituksen aikana.
Kun käytät DB2-taulukoita SPUFI: n kautta (emulaattorin mahdollisuus käyttää DB2-taulukoita), aseta automaattinen sitoutuminen aina "EI" -toiminnoksi tahattomien päivitysten välttämiseksi.
Testitietojen saatavuus on ensisijainen haaste erätestauksessa. Vaaditut tiedot on luotava hyvissä ajoin ennen testisykliä ja niiden täydellisyys on tarkistettava.
Jotkut verkkotapahtumat ja erätyöt voivat kirjoittaa tietoja MQ: iin (Message Queue) tietojen siirtämiseksi muihin sovelluksiin. Jos tiedot eivät ole kelvollisia, ne voivat poistaa / lopettaa MQ: t, tämä vaikuttaa koko testausprosessiin. On hyvä käytäntö tarkistaa, että MQ: t toimivat kunnolla testauksen jälkeen.