Mainframe-testaus – täydellinen opetusohjelma

Ennen kuin opit keskustietokoneiden testauskäsitteitä, opetellaan

Mikä on Mainframe?

Keskusyksikkö on tehokas ja nopea tietokonejärjestelmä. Sitä käytetään suuremman mittakaavan laskentatarkoituksiin, jotka vaativat suurta käytettävyyttä ja turvallisuutta. Sitä käytetään enimmäkseen aloilla, kuten rahoitus, vakuutus, vähittäiskauppa ja muilla kriittisillä aloilla, joilla valtavia tietoja käsitellään useita kertoja.

Mainframe testaus

Mainframe testaus on prosessi, jossa testataan ohjelmistosovelluksia ja palveluita, jotka perustuvat Mainframe Systems -järjestelmiin. Mainframe-testauksen tarkoituksena on varmistaa ohjelmistosovelluksen tai palvelun suorituskyky, luotettavuus ja laatu varmennus- ja validointimenetelmin sekä tarkistaa, onko se valmis käyttöönotettavaksi.

Mainframe-testauksen aikana testaajan tarvitsee vain tietää CICS-näyttöjen navigoinnista. Ne on räätälöity tiettyihin sovelluksiin. Kaikkien COBOL-, JCL- jne. testerin koodiin tehtyjen muutosten ei tarvitse huolehtia koneeseen asennetusta emulaattorista. Muutokset, jotka toimivat yhdessä pääteemulaattorissa, toimivat myös muissa.

• Mainframe-sovellus (toisin sanoen työerä) testataan vaatimusten mukaisesti kehitettyjen testitapausten perusteella
• Mainframe Testaus suoritetaan yleensä käyttöön otetulle koodille käyttämällä erilaisia ​​syötetiedostoon asetettuja tietoyhdistelmiä.
• Pääkoneessa toimivia sovelluksia voidaan käyttää pääteemulaattorin kautta. Emulaattori on ainoa ohjelmisto, joka on asennettava asiakaskoneeseen.

Mainframe-attribuutit

1. Virtuaalinen tallennustila
   1. Se on tekniikka, jonka avulla prosessori simuloi päämuistia, joka on suurempi kuin todellinen tallennustilan todellinen määrä.
   2. Se on tekniikka käyttää muistia tehokkaasti erikokoisten tehtävien tallentamiseen ja suorittamiseen.
   3. Se käyttää levytallennustilaa todellisen tallennustilan laajennuksena.
2. Moniohjelmointi
   1. Tietokone suorittaa useampaa kuin yhtä ohjelmaa samanaikaisesti. Mutta kulloinkin vain yksi ohjelma voi hallita CPU:ta.
   2. Se on toiminto, joka on tarkoitettu CPU:n tehokkaaseen käyttöön.
3. Eräkäsittely
   1. Se on tekniikka, jolla mikä tahansa tehtävä suoritetaan yksiköissä, jotka tunnetaan työtehtävinä.
   2. Työ voi saada yhden tai useamman ohjelman suorittamaan peräkkäin.
   3. Työn ajoittaja päättää, missä järjestyksessä työt tulee suorittaa. Keskimääräisen suorituskyvyn maksimoimiseksi työt ajoitetaan niiden prioriteetin ja luokan mukaan.
   4. Eräkäsittelyyn tarvittavat tiedot toimitetaan JCL:n (JOB CONTROL LANGUAGE) kautta. JCL kuvaa erätyötä – tarvittavat ohjelmat, tiedot ja resurssit.
4. Ajan jakaminen
   1. Aikajakojärjestelmässä jokaisella käyttäjällä on pääsy järjestelmään päätelaitteen kautta. Sen sijaan, että käyttäjä lähettäisi työt, jotka on ajoitettu myöhempään suoritukseen, käyttäjä antaa komennot, jotka käsitellään välittömästi.
   2. Tästä syystä tätä kutsutaan "vuorovaikutteiseksi käsittelyksi". Sen avulla käyttäjä voi olla suoraan vuorovaikutuksessa tietokoneen kanssa.
   3. Aikaosuuskäsittely tunnetaan nimellä "Foreground Processing" ja eräkäsittely tunnetaan nimellä "Background Processing".
5. spooling
   1. SPOOLING tarkoittaa Samanaikainen oheislaite Operaverkossa.
   2. SPOOL-laitetta käytetään ohjelman/sovelluksen tulosteen tallentamiseen. Taustatulostus ohjataan tulostuslaitteisiin, kuten tulostimeen (tarvittaessa).
   3. Se on ominaisuus, joka hyödyntää puskuroinnin etua tulostuslaitteiden tehokkaaseen hyödyntämiseen.

Manuaalisen testauksen luokitus keskustietokoneessa

keskuskone Manuaalinen testaus voidaan luokitella kahteen tyyppiin:

1. Erätyön testaus -

• Testausprosessi sisältää erätöiden suorittamisen nykyisessä julkaisussa toteutetuille toiminnoille.
• Tulostiedostoista ja tietokannasta poimitut testitulokset tarkistetaan ja tallennetaan.

2. Online-testaus -

• Online-testaus viittaa CICS-näyttöjen testaamiseen, joka on samanlainen kuin verkkosivun testaus.
• Olemassa olevien näyttöjen toimintoja voitaisiin muuttaa tai uusia näyttöjä voitaisiin lisätä.
• Eri sovelluksissa voi olla kyselynäyttöjä ja päivitysnäyttöjä. Näiden näyttöjen toimivuus on tarkistettava osana online-testausta.

Kuinka tehdä Mainframe-testaus

1. Liiketoimintatiimi valmistelee vaatimusasiakirjat. Mikä määrittää, kuinka tiettyä tuotetta tai prosessia muutetaan julkaisujaksossa.
2. Testausryhmä ja kehitystyö saavat vaatimusasiakirjan. He selvittävät kuinka moneen prosessiin muutos vaikuttaa. Yleensä julkaisussa räätälöity vaatimus vaikuttaa suoraan vain 20-25 %:iin sovelluksesta. Loput 75 % julkaisusta on tarkoitettu ulostulotoimintoihin, kuten sovellusten ja prosessien testaamiseen.
3. Mainframe-sovellus on siis testattava kahdessa osassa:
   1. Testausvaatimukset – Sovelluksen toiminnallisuuden tai vaatimusasiakirjassa mainitun muutoksen testaus.
   2. Integraation testaus – Koko prosessin tai muun sovelluksen testaus, joka vastaanottaa tai lähettää tietoja kyseiselle sovellukselle. Regressiotestaus on tämän testaustoiminnan pääpaino.

Mainframe Automation Testing Tools

Alla on luettelo työkaluista, joita voidaan käyttää keskuskoneessa Automaatiotestaus.

• REXX
• kunnostautua
• QTP

Mainframe-testauksen metodologia

Tarkastellaanpa esimerkkiä: XYZ-vakuutusyhtiössä on jäsenrekisteröintimoduuli. Se ottaa tietoja sekä jäsenrekisteröitymisnäytöltä että offline-ilmoittautumiselta. Kuten aiemmin keskustelimme, Mainframe-testaukseen, online-testaukseen ja erätestaukseen tarvitaan kaksi lähestymistapaa.

• Online-testaus tehdään jäsenrekisteröitymisnäytössä. Aivan kuten web-sivu, tietokanta tarkistetaan näyttöjen kautta syötetyillä tiedoilla.
• Offline-ilmoittautuminen voi olla paperinen ilmoittautuminen tai rekisteröinti kolmannen osapuolen verkkosivustolla. Offline-tiedot (kutsutaan myös eräksi) syötetään yrityksen tietokantaan erätöinä. Syötetty litteä tiedosto valmistetaan määrätyn tietomuodon mukaisesti ja syötetään erätöiden sarjaan. Joten keskustietokonesovellusten testaamiseen voimme käyttää seuraavaa lähestymistapaa.
• Erätöiden rivin ensimmäinen työ vahvistaa syötetyt tiedot. Oletetaan esimerkiksi erikoismerkki, aakkoset vain numerokentissä jne.
• Toinen tehtävä validoi tietojen johdonmukaisuuden liiketoimintaolosuhteiden perusteella. Esimerkiksi lapsiilmoittautuminen ei saa sisältää riippuvaisia ​​tietoja, jäsenen postinumeroa (joka ei ole saatavilla rekisteröidyn paketin palveluun) jne.
• Kolmas työ muuttaa tietoja sellaisessa muodossa, joka voidaan syöttää tietokantaan. Esimerkiksi suunnitelman nimen poistaminen (tietokanta tallentaa vain suunnitelman tunnuksen ja vakuutussopimuksen nimen), merkintäpäivämäärän lisääminen jne.
• Neljäs työ lataa tiedot tietokantaan.
• Erätyön testaus tämä prosessi tehdään kahdessa vaiheessa -
• Jokainen työ validoidaan erikseen, ja
• Töiden välinen integrointi vahvistetaan syöttämällä tasainen syötetiedosto ensimmäiseen työhön ja tarkistamalla tietokanta. (Välitulokset on validoitava erityisen varovaisuuden vuoksi)

Mainframe-testauksessa noudatetaan seuraavaa menetelmää:

Vaihe 1) Shakedown/Savun testaus

Pääpaino tässä vaiheessa on varmistaa, onko käytetty koodi oikeassa testiympäristössä. Se myös varmistaa, että koodissa ei ole kriittisiä ongelmia.

Vaihe 2) Järjestelmän testaus

Alla on osana järjestelmätestausta tehtyjä testaustyyppejä.

1. Erätestaus – Tämä testaus tehdään validoimalla tulostiedostojen testitulokset ja testauksen piiriin kuuluvien erätöiden tekemät datamuutokset ja kirjaamalla ne.
2. Verkkotestaus – Tämä testaus tehdään keskustietokonesovelluksen etupäässä. Täällä testataan sovelluksen oikean syöttökentän, kuten vakuutussopimuksen, suunnitelman koron jne.
3. Online-eräintegraation testaus – Tämä testaus tehdään järjestelmissä, joissa on eräprosessit ja online-sovellus. Tietovirta ja vuorovaikutus online-näyttöjen ja erätöiden välillä validoidaan.

   (Esimerkki tämän tyyppisestä testauksesta – Harkitse suunnitelman yksityiskohtien, kuten koron korotuksen, päivittämistä. Kiinnostuksen muutos tapahtuu päivitysnäytössä, ja vaikutusten kohteena olevien tilien saldotietoja muokataan vain iltaisin erätyönä. Testaus suoritetaan tässä tapauksessa vahvistamalla Suunnitelman tiedot -näyttö ja erätyö, joka suoritetaan kaikkien tilien päivittämiseksi).

4. Tietokannan testaus – Tietokannat, joissa keskustietokonesovelluksen tiedot (IMS, IDMS, DB2, VSAM/ISAM, peräkkäiset tietojoukot, GDG:t) tarkistetaan niiden asettelun ja tallennustilan osalta.

Vaihe 3) järjestelmä Integraation testaus

Tämän testauksen ensisijaisena tarkoituksena on vahvistaa niiden järjestelmien toimivuus, jotka ovat vuorovaikutuksessa testattavan järjestelmän kanssa.

Vaatimukset eivät suoraan vaikuta 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 Työ onnistunut, Työ epäonnistui, Tietokanta päivitetty jne.), jotka voivat kulkea järjestelmien välillä ja niistä aiheutuvia yksittäisten järjestelmien toimintoja.

Tässä vaiheessa tehtävät testityypit ovat

1. Erätestaus
2. Verkkotestaus
3. Online – Eräintegraatiotestaus

Vaihe 4) Regressiotestaus

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

Jotta regressiotestaus olisi tehokasta, tietty joukko testitapauksia tulisi valita niiden monimutkaisuuden mukaan ja luoda regressiopeti (Test case repository). Tämä sarja tulee päivittää aina, kun julkaisuun tulee uusia toimintoja.

Vaihe 5) Suorituskykytestaus

Tämä testaus tehdään pullonkaulojen tunnistamiseksi suurilla hittialueilla, kuten käyttöliittymän datassa, online-tietokantojen päivittämisessä ja sovelluksen skaalautuvuuden projisoimiseksi.

Vaihe 6) Suojaustestaus

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

Järjestelmälle tulisi tehdä kaksinkertainen tietoturvatestaus – keskustietoturva ja verkkosuojaus.

Testattavia ominaisuuksia ovat

1. Integrity
2. Luottamuksellisuus
3. Lupa
4. Authentication
5. Saatavuus

Erätestaukseen liittyvät vaiheet

1. Kun laadunvarmistustiimi on vastaanottanut hyväksytyn paketin (paketti sisältää menettelyt, JCL:n, ohjauskortit, moduulit jne.), testaajan tulee esikatsella ja hakea sisältö PDS:ään tarpeen mukaan.
2. Muunna tuotanto-JCL tai kehitys-JCL QA JCL:ksi, jota kutsutaan muuten JOB SETUP -asetukseksi.
3. Tuotantotiedoston kopiointi ja testitiedostojen valmistelu.
4. Jokaiselle toiminnalle on määritetty työjärjestys. (Kuten on selitetty esimerkissä Metodologia-osiossa Mainframe).Työt tulee lähettää SUB-komennolla testidatatiedostojen kanssa.
5. Tarkista välitiedosto selvittääksesi syyt tietojen puuttumiseen tai virheisiin.
6. Tarkista lopullinen tulostiedosto, tietokanta ja kela vahvistaaksesi testitulokset.
7. 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

1. Valitse Online-näyttö testiympäristössä.
2. Testaa jokaisesta kentästä hyväksyttävät tiedot.
3. Testaa Testiskenaario näytöllä.
4. Tarkista tietokanta tietojen päivityksiä varten online-näytöstä.

Testiraportointi – Vika tulee kirjata lokiin, jos todellinen tulos poikkeaa odotetusta.

Online - Eräintegraatiotestauksen vaiheet

1. Suorita työ a Testiympäristössä ja validoi tiedot online-näytöissä.
2. Päivitä tiedot online-näytöissä ja tarkista, onko erätyö suoritettu oikein päivitetyillä tiedoilla.

Mainframe-testauksessa käytetyt komennot

1. LÄHETÄ – Lähetä taustatyö.
2. CANCEL – Peruuta taustatyö.
3. ALLOCATE – Varaa tietojoukko
4. COPY – Kopioi tietojoukko
5. RENAME – Nimeä tietojoukko uudelleen
6. DELETE – Poista tietojoukko
7. 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 mainframe-testauksen aloittamiseen

Mainframe-testaukseen tarvittavat perustiedot ovat:

• Kirjautumistunnus ja salasana sovellukseen kirjautumista varten.
• Lyhyt tietoa ISPF-komennoista.
• Tiedostojen nimet, tiedoston tarkenteet ja tyypit.

Ennen mainframe-testauksen aloittamista alla olevat näkökohdat tulee tarkistaa.

1. Job
   1. Suorita työn tarkistus (komento – JOBSCAN) tarkistaaksesi virheet ennen sen suorittamista.
   2. CLASS-parametri tulee osoittaa testiluokkaan.
   3. Ohjaa työn tulos spooliin tai JHS:ään tai tarvittaessa käyttämällä MSGCLASS-parametria.
   4. Ohjaa työn sähköposti uudelleen kelaukseen tai testipostitunnukseen.
   5. Kommentoi FTP-vaiheet alkutestausta varten ja osoita sitten työ testipalvelimelle.
   6. Jos työssä luodaan IMR (Incident Management -tietue), lisää työhön tai parametrikorttiin kommentti "TESTAUSTAVOITE".
   7. Kaikki työssä olevat tuotantokirjastot tulisi muuttaa ja osoittaa testikirjastoihin.
   8. Työtä ei saa jättää vartioimatta.
   9. Jotta työ ei toimiisi äärettömässä silmukassa virheiden sattuessa, TIME-parametri tulee lisätä määritetyllä ajalla.
   10. Tallenna työn tulos, mukaan lukien kela. Kela voidaan tallentaa XDC:n avulla.

2. filee
   1. Luo vain tarvittavan kokoinen testitiedosto. Käytä tarvittaessa GDG:itä (sukupolvitietoryhmät – tiedostot, joilla on sama nimi, mutta peräkkäiset versionumerot – MYLIB.LIB.TEST.G0001V00,MYLIB.LIB.TEST.G0002V00 jne.) tarvittaessa tallentaaksesi tiedot peräkkäisiin samannimisisiin tiedostoihin.
   2. Tiedostojen DISP (Disposition) -parametrin tulee olla oikein koodattu.
   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:llä, varmista, että oikea versio on osoitettu.
3. tietokanta
   1. Kun suoritat työtä tai online-ohjelmaa, varmista, että tahattomia tietoja ei lisätä tai päivitetä tai poisteta.
   2. Varmista myös, että testaukseen käytetään oikeaa DB2-aluetta.
4. Testata tapauksia
   1. Testaa aina reunaehtoja, 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 tarkistuspisteen uudelleenkäynnistys, Abend-moduulit, ohjaustiedostot jne., sisällytä testitapaukset tarkistamaan, onko moduuleja käytetty oikein.
5. Testitiedot
   1. Testitietojen asetukset tulee tehdä ennen testauksen aloittamista.
   2. Älä koskaan muuta testialueen tietoja ilmoittamatta siitä. Saattaa olla muitakin ryhmiä, jotka työskentelevät samoilla tiedoilla, ja heidän testinsä epäonnistuu.
   3. Mikäli tuotantotiedostoja tarvitaan suorituksen aikana, on hankittava asianmukainen valtuutus ennen niiden kopioimista tai käyttöä.

Esimerkkikäytäntöjä

1. Erätyön suorittamisen tapauksessa MAX CC 0 osoittaa, että työ on suoritettu onnistuneesti. Se ei tarkoita, että toiminnallisuus toimisi hyvin. Työ suoritetaan onnistuneesti, vaikka tuloste olisi tyhjä tai ei odotusten mukaan. Joten on aina odotettavissa, että kaikki tulokset tarkistetaan ennen työn onnistuneen julistamista.
2. On aina hyvä käytäntö tehdä testattava työ kuivalla. Kuivakäynti tehdään tyhjillä syöttötiedostoilla. Tätä prosessia tulee noudattaa töissä, joihin testisykliin tehdyt muutokset vaikuttavat.
3. Ennen kuin testisykli alkaa, testityön asetukset tulee tehdä hyvissä ajoin etukäteen. Tämä auttaa selvittämään kaikki JCL-virheet etukäteen, mikä säästää aikaa suorituksen aikana.
4. Kun käytät DB2-taulukoita SPUFI:n kautta (emulaattorin vaihtoehto DB2-taulukoiden käyttämiseen), aseta automaattinen vahvistus aina arvoon "EI", jotta vältytään vahingossa tapahtuvilta päivityksiltä.
5. Testitietojen saatavuus on erätestauksen ensisijainen haaste. Vaaditut tiedot on luotava hyvissä ajoin ennen testisykliä, ja niiden täydellisyys on tarkistettava.
6. Jotkut online-tapahtumat ja erätyöt voivat kirjoittaa tietoja MQ:iin (Message Queue) tietojen siirtämistä varten muihin sovelluksiin. Jos tiedot eivät ole kelvollisia, se voi poistaa/pysäyttää MQ:t, mikä vaikuttaa koko testausprosessiin. On hyvä käytäntö tarkistaa, että MQ:t toimivat hyvin testauksen jälkeen.

Mainframe-testauksen haasteet ja vianetsintä

Haasteet	Lähestymistapa
Puutteelliset/epäselvät vaatimukset Käyttöoppaat/koulutusoppaat voivat olla käytettävissä, mutta ne eivät ole samoja kuin dokumentoidut vaatimukset.	Testaajien tulee olla mukana SDLC:ssä vaatimusvaiheesta lähtien. Tämä auttaa varmistamaan, ovatko vaatimukset testattavissa.
Tietojen määritys/tunnistus Saattaa olla tilanteita, joissa olemassa olevia tietoja tulee käyttää uudelleen vaatimusten mukaisesti. Joskus on vaikeaa tunnistaa tarvittavat tiedot olemassa olevista tiedoista.	Tietojen määrittämiseen voidaan käyttää kotimaisia ​​työkaluja tarpeen mukaan. Olemassa olevan tiedon hakemista varten kyselyt tulee rakentaa etukäteen. Ongelmatilanteissa voidaan esittää tiedonhallintatiimille pyyntö vaadittujen tietojen luomiseksi tai kloonaamiseksi.
Työn asetukset Kun työt on haettu PDS:ään, työ on määritettävä laadunvarmistusalueella. Jotta töihin ei lähetetä tuotantomääritteitä tai polkutietoja.	Työnmääritystyökaluja tulee käyttää, jotta voidaan välttää määrityksen aikana tehdyt inhimilliset virheet.
Ad-hoc-pyyntö Saattaa olla tilanteita, joissa päästä päähän -testausta on tuettava ylävirran tai loppupään sovellusten ongelman vuoksi. Nämä pyynnöt lisäävät suoritusjakson aikaa ja vaivaa.	Automaatioskriptien, regressiokomentosarjojen ja runkokomentosarjojen käyttö voi auttaa vähentämään aikaa ja vaivaa.
Ajanmukaiset julkaisut laajuuden muutoksille Saattaa olla tilanne, jossa koodin vaikutus voi muuttaa järjestelmän ulkoasua ja tuntumaa kokonaan. Tämä saattaa edellyttää muutosta testaustapauksiin, komentosarjoihin ja tietoihin.	Laajuusmuutosten hallintaprosessin ja vaikutusanalyysin tulisi olla käytössä.

Tavallisia abendeja

1. S001 – Tapahtui I/O-virhe.

   Syy – Lukeminen tiedoston lopussa, tiedoston pituusvirhe, yritys kirjoittaa vain luku -tiedostoon.

2. S002 – Virheellinen I/O-tietue.

   Syy – Yritä kirjoittaa tietue, joka on pidempi kuin tietue.

3. S004 – Virhe AUKI-tilassa.

   Syy – Virheellinen DCB

4. S013 – Virhe avattaessa tietojoukkoa.

   Syy – PDS-jäsentä ei ole olemassa, ohjelman tietueen pituus ei vastaa todellista tietueen pituutta.

5. S0C1 – Operapoikkeus

   Syy – Tiedostoa ei voi avata, DD-kortti puuttuu

6. S0C4 – Suojauspoikkeus/tallennusvirhe
7. Syy – Yritetään käyttää tallennustilaa, joka ei ole ohjelman käytettävissä.
8. S0C7 – Ohjelmatarkistuspoikkeus – Tiedot
9. Syy – Muutos tietueen tai tiedostoasettelussa.
10. Sx22 – Työ on peruutettu
11. S222 – Käyttäjä peruutti työn ilman tyhjennystä.
12. S322 – Työn tai vaiheen aika ylitti määritetyn rajan, tai ohjelma on silmukassa tai aikaparametri ei riitä.
13. S522 – TSO-istunnon aikakatkaisu.
14. S806 – Ei voida yhdistää tai ladata.

    Syy – Työtunnus ei löydä määritettyä latausmoduulia.

15. S80A – Virtuaalinen tallennustila ei riitä GETMAIN- tai FREEMAIN-pyyntöjen täyttämiseen.
16. S913 – Yritetään käyttää tietojoukkoa, jota käyttäjällä ei ole valtuutettu.
17. Sx37 – Tietojoukolle ei voi varata tarpeeksi tallennustilaa.

Error Assist – Erittäin suosittu työkalu saada yksityiskohtaista tietoa erityyppisistä taipumuksista.

Yleinen ongelma keskustietokonetestauksen aikana

• Job Abends – Työn onnistuneen suorittamisen varmistamiseksi sinun tulee tarkistaa tiedot, syöttötiedosto ja moduulit, jotka ovat tietyssä paikassa vai eivät. Poikkeamat voivat johtua useista syistä, joista yleisimmät ovat: Virheelliset tiedot, Virheellinen syöttökenttä, päivämäärän yhteensopimattomuus, ympäristöongelmat jne.
• Tulostiedosto tyhjä–Vaikka työ saattaa suorittaa onnistuneesti (MaxCC 0), tulos ei ehkä ole odotetun mukainen. Joten ennen testitapauksen läpäisemistä testaajan on varmistettava, että tulos on ristiin varmistettu. Jatka vasta sitten eteenpäin.
• Syötetiedosto tyhjä – Joissakin sovelluksissa tiedostoja vastaanotetaan alkupään prosesseista. Ennen kuin vastaanotettua tiedostoa käytetään nykyisen sovelluksen testaamiseen, tiedot tulee ristiinvarmentaa, jotta vältytään uudelleen suorittamiselta ja uudelleenkäsittelyltä.

Yhteenveto

• Mainframe-testaus on kuten mikä tahansa muu testausmenettely alkaen vaatimusten keräämisestä, testin suunnittelusta, testin suorittamisesta ja tulosraportoinnista.
• Jotta sovellus voidaan testata tehokkaasti, testaajan tulee osallistua kehitys- ja liiketoimintatiimien suunnittelemiin suunnittelukokouksiin.
• Testaajan on totuttava erilaisiin keskuskoneen testitoimintoihin. Kuten näytön navigointi, tiedostojen ja PDS-tiedostojen luominen, testitulosten tallentaminen jne. ennen testisyklin alkamista.
• Mainframe-sovellusten testaus on aikaa vievä prosessi. Selkeää testiaikataulua tulee noudattaa testin suunnittelussa, tietojen määrittämisessä ja suorittamisessa.
• Erätestaus ja online-testaus tulisi tehdä tehokkaasti ilman, että mitään vaatimusasiakirjassa mainittuja toimintoja jää puuttumaan. Testitapaus pitäisi säästää.