Mainframe-testaus – täydellinen opetusohjelma

Ennen kuin opimme keskustietokonetestauksen käsitteitä, katsotaanpa ensin alustaa, jolla testit suoritetaan.

Mikä on Mainframe?

Keskustietokone on tehokas ja nopea tietokonejärjestelmä. Sitä käytetään laajamittaiseen laskentaan, joka vaatii korkeaa käytettävyyttä ja vahvaa tietoturvaa. Sitä käytetään enimmäkseen aloilla, kuten rahoitus, vakuutus, vähittäiskauppa ja muilla kriittisillä aloilla, joilla käsitellään valtavia tietomääriä useita kertoja päivässä.

Mainframe testaus

Mainframe testaus on prosessi, jossa testataan keskustietokonejärjestelmiin perustuvia ohjelmistosovelluksia ja -palveluita. Keskustietokonetestauksen tarkoituksena on varmistaa ohjelmistosovelluksen tai -palvelun suorituskyky, luotettavuus ja laatu todentamis- ja validointimenetelmien avulla ja tarkistaa, onko se käyttövalmis.

Suorittaessaan keskustietokonetestausta testaajan on pääasiassa tiedettävä CICS-näyttöjen navigointi. Nämä näytöt on räätälöity tiettyjä sovelluksia varten. Kun koodiin tehdään muutoksia COBOL-, JCL- ja vastaavilla kielillä, testaajan ei tarvitse huolehtia koneen emulaattoriasetuksista, koska yhdessä pääteemulaattorissa toimivat muutokset toimivat myös muissa.

• Keskustietokonesovellusta (jota kutsutaan myös työeräksi) testataan vaatimusten avulla kehitettyjä testitapauksia vasten.
• Mainframe Testaus suoritetaan yleensä käyttöön otetulle koodille käyttämällä erilaisia ​​syötetiedostoon asetettuja tietoyhdistelmiä.
• Keskustietokoneella ajettavia sovelluksia voidaan käyttää pääteemulaattorin kautta. Emulaattori on ainoa ohjelmisto, joka tarvitsee asentaa asiakaskoneelle.

Koska alusta käyttäytyy eri tavalla kuin verkkopino, on hyödyllistä tietää, mitkä keskustietokoneiden ominaisuudet ohjaavat testisuunnittelua. Keskustietokonetestaus sijoittuu siksi muiden ominaisuuksien rinnalle. ohjelmistotestauksen tyypit sen sijaan, että korvaisi jonkun niistä.

Mainframe-attribuutit

1. Virtuaalinen tallennustila
   • Se on tekniikka, jonka avulla prosessori simuloi päämuistia, joka on suurempi kuin todellinen tallennustilan todellinen määrä.
   • Se on tekniikka käyttää muistia tehokkaasti erikokoisten tehtävien tallentamiseen ja suorittamiseen.
   • Se käyttää levytallennustilaa todellisen tallennustilan laajennuksena.
2. Moniohjelmointi
   • Tietokone suorittaa useampaa kuin yhtä ohjelmaa samanaikaisesti. Mutta millä tahansa hetkellä vain yksi ohjelma voi hallita suoritinta.
   • Se on toiminto, joka on tarkoitettu CPU:n tehokkaaseen käyttöön.
3. Eräkäsittely
   • Se on tekniikka, jolla mikä tahansa tehtävä suoritetaan yksiköissä, jotka tunnetaan työtehtävinä.
   • Työ voi saada yhden tai useamman ohjelman suorittamaan peräkkäin.
   • 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.
   • Eräkäsittelyyn tarvittavat tiedot saadaan JCL:n (JOB CONTROL LANGUAGE) kautta. JCL kuvaa eräajon — tarvittavat ohjelmat, tiedot ja resurssit.
4. Ajan jakaminen
   • 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.
   • Tästä syystä tätä kutsutaan "vuorovaikutteiseksi käsittelyksi". Sen avulla käyttäjä voi olla suoraan vuorovaikutuksessa tietokoneen kanssa.
   • Aikaosuuskäsittely tunnetaan nimellä "Foreground Processing" ja eräkäsittely tunnetaan nimellä "Background Processing".
5. spooling
   • SPOOLing tarkoittaa samanaikaista perifeeristä Operations Online.
   • SPOOL-laitetta käytetään ohjelman tai sovelluksen tulosteen tallentamiseen. Jonotettu tuloste ohjataan tulostuslaitteisiin, kuten tulostimeen (tarvittaessa).
   • Se on ominaisuus, joka hyödyntää puskuroinnin etua tulostuslaitteiden tehokkaaseen hyödyntämiseen.

Manuaalisen testauksen luokitus keskustietokoneessa

Nämä ominaisuudet jakavat manuaalisen testaustyön keskustietokoneella kahteen selkeästi erilliseen osaan.

keskuskone Manuaalinen testaus voidaan luokitella kahteen tyyppiin:

1. Erätyötestaus —

• Testausprosessiin kuuluu eräajotehtävien suorittaminen nykyisessä versiossa toteutetuille toiminnoille.
• Testitulokset esim.tracTulostetiedostoista ja tietokannasta saadut tiedot tarkistetaan ja tallennetaan.

2. Verkkotestaus —

• Verkkotestaus viittaa CICS-näyttöjen testaamiseen, joka on samanlaista kuin verkkosivun testaaminen.
• 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ä keskustietokoneiden testausta

1. Liiketoimintatiimi valmistelee vaatimusasiakirjat, jotka määrittävät, miten tiettyä tuotetta tai prosessia muokataan julkaisusyklin aikana.
2. Testaustiimi ja kehitystiimi vastaanottavat vaatimusdokumentin. He selvittävät, kuinka moneen prosessiin muutos vaikuttaa. Yleensä julkaisussa vain 20–25 % sovelluksesta on suoraan mukautetun vaatimuksen kohteena. Loput 75–80 % julkaisutyöstä menee valmiisiin toimintoihin, kuten ympäröivien sovellusten ja prosessien testaamiseen.
3. Mainframe-sovellus on siis testattava kahdessa osassa:
   • Testausvaatimukset — Sovelluksen testaaminen vaatimusasiakirjassa mainitun toiminnallisuuden tai muutoksen osalta.
   • Integraation testaus — Koko prosessin tai muiden sovellusten testaaminen, jotka vastaanottavat tai lähettävät tietoja kyseiseen sovellukseen. Regressiotestaus on tämän testaustoiminnan pääpaino.

Mainframe Automation Testing Tools

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

• REXX — z/OS:n mukana toimitettu komentosarjakieli, jota käytetään laajalti toistuvien töiden lähettämiseen ja tulosten tarkistuksiin.
• kunnostautua — käytetään makroiden kanssa testidatan ja tulostiedostojen rakentamiseen, vertailuun ja raportointiin.
• OpenText UFT yksi — työkalun nykyinen nimi, jota teollisuus edelleen kutsuu QTP tai QuickTest Professional; se automatisoi 3270 päätenäyttöä.
• Galasa — avoimen lähdekoodin, Open Mainframe Projectin syväintegraatiotestauskehys joka ohjaa 3270 näyttöä, JCL-eräajotöitä ja Db2:ta CI/CD-putken kautta.
• Toimittajan z/OS-testipaketit - IBM Test Accelerator for Z ja BMC AMI DevX Total Test kattavat COBOL-yksikkötestauksen ja virtualisoidut testiympäristöt.

Olipa valittu työkalu mikä tahansa, se kannattaa takaisin vasta, kun se on huolletussa tilassa. testiautomaatiokehys sen sijaan, että se olisi irrallinen kasa skriptejä.

Mainframe-testauksen metodologia

Tarkastellaan esimerkkiä: XYZ-vakuutusyhtiöllä on jäsenten rekisteröintimoduuli. Se ottaa tietoja sekä jäsenten rekisteröintinäytöltä että offline-rekisteröinnistä. Kuten aiemmin käsiteltiin, siinä on kaksi lähestymistapaa keskustietokonetestaukseen: online-testaus ja erätestaus.

• Verkkotestaus tehdään jäsenten ilmoittautumisnäytöllä. Aivan kuten verkkosivu, tietokanta validoidaan näyttöjen kautta syötettyjen tietojen perusteella.
• Offline-ilmoittautuminen voi olla paperinen ilmoittautuminen tai ilmoittautuminen kolmannen osapuolen verkkosivustolla. Offline-tiedot (joita kutsutaan myös eräajoiksi) syötetään yrityksen tietokantaan eräajojen kautta. Syötetiedosto valmistellaan määrätyn tietomuodon mukaisesti ja syötetään eräajojen sarjaan. Joten suurtietokonesovellusten testauksessa voimme käyttää seuraavaa lähestymistapaa.
  • Erätyörivin ensimmäinen työ tarkistaa syötetyt tiedot – esimerkiksi erikoismerkit tai aakkoset vain numeroita sisältävissä kentissä.
  • Toinen tehtävä validoi tietojen johdonmukaisuuden liiketoimintaolosuhteiden perusteella. Esimerkiksi alirekisteröinnin ei tulisi sisältää riippuvaisia ​​tietoja tai jäsenen postinumeroa, jota rekisteröitynyt suunnitelma ei tarjoa.
  • Kolmas työ muokkaa tiedot tietokantaan syötettävään muotoon. Esimerkiksi suunnitelman nimen poistaminen (tietokanta tallentaa vain suunnitelman tunnuksen ja vakuutussuunnitelman nimen), syöttöpäivämäärän lisääminen ja vastaavat muutokset.
  • Neljäs työ lataa tiedot tietokantaan.
• Erätyötestaus tehdään tässä prosessissa kahdessa vaiheessa —
  • Jokainen työpaikka validoidaan erikseen, ja
  • Töiden välinen integrointi validoidaan antamalla syötetiedosto ensimmäiselle työlle ja validoimalla tietokanta. (Välivaihetulokset on validoitava lisävarmuuden vuoksi.)

Seuraavaa menetelmää käytetään suurtietokoneiden testauksessa:

Vaihe 1) Testaus/savutestaus

Tässä vaiheessa pääpaino on validoida, onko käyttöön otettu koodi oikeassa testiympäristössä. Se varmistaa myös, ettei koodissa ole kriittisiä ongelmia. Tämä on suurtietokoneen vastine Savun testaus millään muulla alustalla.

Vaihe 2) Järjestelmän testaus

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

1. Erätestaus — Tämä testaus tehdään validoimalla testitulokset tulostiedostoista ja testattavien eräajojen tekemistä tietomuutoksista ja tallentamalla ne.
2. Verkkotestaus — Tämä testaus tehdään keskustietokonesovelluksen käyttöliittymässä. Tässä sovelluksessa testataan oikeita syöttökenttiä, kuten vakuutussuunnitelmaa, suunnitelman korkoa ja vastaavia arvoja.
3. Online-eräintegraation testaus — Tämä testaus tehdään järjestelmillä, joissa on sekä eräprosesseja että online-sovellus. Online-näyttöjen ja eräajojen välinen tiedonkulku ja vuorovaikutus validoidaan.

   (Esimerkki tällaisesta testauksesta – Tarkastellaan suunnitelman tietojen päivitystä, kuten koron nousua. Koron muutos tehdään päivitysnäytössä, ja kyseisten tilien saldotietoja muokataan vain yöllä suoritettavalla eräajolla. Testaus tehdään tässä tapauksessa validoimalla suunnitelman tietojen näyttö ja suorittamalla eräajo kaikkien tilien päivittämiseksi.)

4. Tietokannan testaus — Tietokannat, joissa keskustietokonesovelluksen tietoja säilytetään (IMS, IDMS, Db2, VSAM/ISAM, peräkkäiset tietojoukot, GDG:t), validoidaan niiden asettelun ja tiedontallennuksen 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 vaikuta näihin järjestelmiin suoraan. Ne kuitenkin käyttävät testattavan järjestelmän tietoja. On tärkeää testata liitäntä ja erityyppiset viestit (kuten Työ onnistui, Työ epäonnistui, Tietokanta päivitetty), jotka voivat siirtyä järjestelmien välillä, sekä yksittäisten järjestelmien niistä johtuvat toimenpiteet.

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

1. Erätestaus
2. Verkkotestaus
3. Verkossa — Eräintegraatiotestaus

Vaihe 4) Regressiotestaus

Regressiotestaus on yleinen vaihe kaikenlaisissa testausprojekteissa. Tämä testaus suurtietokoneissa varmistaa, että eräajot ja online-näytöt, jotka eivät ole suorassa vuorovaikutuksessa testattavan järjestelmän kanssa (tai eivät kuulu vaatimusten piiriin), eivät vaikuta nykyiseen projektiversioon.

Tehokkaan regressiotestauksen suorittamiseksi tietty joukko testitapauksia tulisi valita niiden monimutkaisuuden perusteella ja tulisi luoda regressioalusta (testitapausvarasto). Tätä joukkoa tulisi päivittää aina, kun julkaisuun otetaan käyttöön uusia toimintoja. Jos regressioalusta on liian suuri toimimaan kokonaisuudessaan, Riskipohjainen testaus käytetään päättämään, mitkä työt ja näytöt suoritetaan uudelleen ensin.

Vaihe 5) Suorituskykytestaus

Tätä testausta tehdään pullonkaulojen tunnistamiseksi korkean tason alueilla, kuten käyttöliittymän tietojen syötössä ja online-tietokantapäivityksissä, ja sovelluksen skaalautuvuuden arvioimiseksi. Pitkäkestoisia eräajoikkunoita tarkastellaan yleensä Stressitestaus huippuvolyymeja vastaan.

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 – keskustietokoneen tietoturva ja verkon tietoturva.

Testattavat ominaisuudet ovat

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

Erätestauksen vaiheet

1. Kun laadunvarmistustiimi vastaanottaa hyväksytyn paketin (paketti sisältää proseduureja, JCL:n, ohjauskortit, moduulit ja vastaavat), testaajan tulee esikatsella ja hakea sisältö PDS:ään tarpeen mukaan.
2. Muunna tuotannon JCL tai kehitystyön JCL laadunvarmistuksen JCL:ksi eli TYÖN ASETUKSET -tiedostoksi.
3. Kopioi tuotantotiedosto ja valmistele testitiedostot.
4. Jokaiselle toiminnallisuudelle määritellään työjärjestys (kuten esimerkissä selitetään Suurtietokoneiden testausmenetelmät -osiossa). Työt tulee lähettää SUB-komennolla testidatatiedostojen kanssa.
5. Tarkista välitiedosto selvittääksesi puuttuvien tai virheellisten tietojen syyt.
6. Tarkista lopullinen tulostiedosto, tietokanta ja spool-tiedosto testitulosten validoimiseksi.
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 tuloksesta.

Verkkotestauksen vaiheet

1. Valitse Online-näyttö a:ssa 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, jos todellinen tulos poikkeaa odotetusta tuloksesta.

Online-testauksen vaiheet — eräintegraatiotestaus

1. Suorita työ testiympäristössä ja validoi online-näyttöjen tiedot.
2. Päivitä tiedot online-näytöillä ja tarkista, toimiiko eräajo oikein päivitetyillä tiedoilla.

Keskustietokoneiden testauksessa käytetyt komennot

Nämä vaiheet ajetaan terminaalista, joten lyhyt komentosanasto kattaa suurimman osan testaajan päivästä.

1. LÄHETÄ — Lähetä taustatyö.
2. PERUUTA — Peruuta taustalla suoritettava työ.
3. ALLOKOI — Varaa tietojoukko.
4. COPY — Kopioi tietojoukko.
5. NIMEÄ UUDELLEEN — Nimeä tietojoukko uudelleen.
6. POISTA — Poista tietojoukko.
7. TYÖSKANNAUSTA — Sido JCL ohjelmaan, kirjastoihin, tiedostoihin ja muihin resursseihin suorittamatta sitä.

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

Edellytykset keskustietokoneiden testauksen aloittamiselle

Keskustietokoneiden testaukseen tarvittavat perustiedot ovat:

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

Ennen keskustietokoneiden testauksen aloittamista on tarkistettava seuraavat seikat.

1. Job
   • Suorita työskannaus (komento — JOBSCAN) virheiden tarkistamiseksi ennen sen suorittamista.
   • CLASS-parametrin tulisi osoittaa testiluokkaan.
   • Ohjaa työn tuloste jonotiedostoon tai JHS-tiedostoon tai tarpeen mukaan käyttämällä MSGCLASS-parametria.
   • Ohjaa työssä oleva sähköposti uudelleen jonotuskansioon tai testisähköpostin tunnukseen.
   • Kommentoi FTP-vaiheet alkutestausta varten ja ohjaa sitten työ testipalvelimelle.
   • Jos työssä luodaan IMR (Incident Management Record), lisää työ- tai parametrikorttiin kommentti ”TESTAUKSEN TARKOITUS”.
   • Kaikki työssä olevat tuotantokirjastot tulisi muuttaa ja osoittaa testikirjastoihin.
   • Työtä ei saa jättää vartioimatta.
   • Jotta työ ei toimisi loputtomassa silmukassa virheen sattuessa, TIME-parametriin tulee lisätä tietty aika.
   • Tallenna työn tulos, mukaan lukien kela. Kela voidaan tallentaa XDC:n avulla.
2. filee
   • Luo vain tarvittavan kokoinen testitiedosto. Käytä tarvittaessa GDG-ryhmiä (Generation Data Groups — samannimisiä tiedostoja, joilla on peräkkäiset versionumerot, kuten MYLIB.LIB.TEST.G0001V00 ja MYLIB.LIB.TEST.G0002V00) tallentaaksesi tiedot peräkkäisiin samannimisiin tiedostoihin.
   • Tiedostojen DISP-parametri (Disposition — kertoo järjestelmälle, säilytetäänkö vai poistetaanko tietojoukko vaiheen tai työn normaalin tai epänormaalin päättymisen jälkeen) tulee koodata oikein.
   • Varmista, että kaikki työn suorittamiseen käytetyt tiedostot on tallennettu ja suljettu oikein, jotta työ ei siirry pitotilaan.
   • Kun testaat GDG-ryhmien avulla, varmista, että oikeaan versioon on osoitettu.
3. tietokanta
   • Työtä tai online-ohjelmaa suorittaessasi varmista, ettei vahingossa lisätä, päivitetä tai poisteta tietoja.
   • Varmista myös, että testauksessa käytetään oikeaa Db2-aluetta.
4. Testata tapauksia
   • Testaa aina reunaehtoja, kuten tyhjää tiedostoa, ensimmäisen tietueen käsittelyä ja viimeisen tietueen käsittelyä.
   • Sisällytä aina sekä positiiviset että negatiiviset testiolosuhteet.
   • Jos ohjelmassa käytetään vakiomenettelyjä, kuten tarkistuspisteen uudelleenkäynnistystä, moduulien tai ohjaustiedostojen abend-katkosta, sisällytä Testitapauss varmistaakseen, että moduuleja on käytetty oikein.
5. Testitiedot
   • Testitietojen asetukset tulee tehdä ennen testauksen aloittamista.
   • Älä koskaan muokkaa testialueen tietoja ilmoittamatta siitä muille. Muut tiimit saattavat työskennellä samojen tietojen parissa, ja heidän testinsä epäonnistuisivat.
   • Mikäli tuotantotiedostoja tarvitaan suorituksen aikana, on hankittava asianmukainen valtuutus ennen niiden kopioimista tai käyttöä.

Esimerkkikäytäntöjä

1. Eräajon tapauksessa MAX CC 0 osoittaa, että työ on suoritettu onnistuneesti. Se ei tarkoita, että toiminnallisuus toimii oikein. Työ suoritetaan onnistuneesti, vaikka tuloste olisi tyhjä tai ei vastaisi odotuksia. Siksi on aina odotettava, että kaikki tulosteet tarkistetaan ennen työn onnistuneeksi julistamista.
2. Testattavan työn koeajo on aina hyvä käytäntö. Koeajo tehdään tyhjillä syötetiedostoilla. Tätä prosessia tulisi noudattaa töissä, joihin testisyklin aikana tehdyt muutokset vaikuttavat.
3. Ennen testisyklin alkua testityön asetukset tulisi tehdä hyvissä ajoin etukäteen. Tämä auttaa havaitsemaan mahdolliset JCL-virheet etukäteen ja säästää siten aikaa suorituksen aikana.
4. Kun käytät Db2-taulukoita SPUFI:n kautta (emulaattorin asetus Db2-taulukoiden käyttämiseksi), aseta automaattisen vahvistuksen arvoksi aina ”EI” tahattomien päivitysten välttämiseksi.
5. Testidatan saatavuus on erätestauksen ensisijainen haaste. Vaadittu data tulisi luoda hyvissä ajoin ennen testisykliä ja sen täydellisyys tulisi tarkistaa. Tracking että valmistelu jaetussa testien hallinta repository pitää regressioalustan ja data-asetukset linjassa.
6. Jotkin verkkotapahtumat ja erätyöt saattavat kirjoittaa tietoja MQ-viesteihin (Message Queues) transmitdatan siirtämistä muihin sovelluksiin. Jos data ei ole kelvollista, se voi poistaa MQ:t käytöstä tai pysäyttää ne, ja tämä vaikuttaa koko testausprosessiin. On hyvä käytäntö tarkistaa, että MQ:t toimivat oikein testauksen jälkeen.

Keskustietokoneiden testauksen haasteet ja vianmääritys

Vaikka nämä käytännöt ovat käytössä, muutamia ongelmia toistuu lähes jokaisessa keskustietokoneen julkaisussa. Alla olevassa taulukossa on yhdistetty jokainen ongelma ja sen ratkaiseva lähestymistapa.

Haasteet	Lähestymistapa
Puutteelliset/epäselvät vaatimukset	Käyttöopas tai koulutusopas voi olla saatavilla, mutta ne eivät ole samoja kuin dokumentoidut vaatimukset. Testaajien tulisi olla mukana ohjelmistotestauksen elinkaari vaatimusvaiheesta eteenpäin. Tämä auttaa varmistamaan, ovatko vaatimukset testattavissa.
Tietojen määritys / tunnistaminen	Saattaa olla tilanteita, joissa olemassa olevaa dataa tulisi käyttää uudelleen tarpeen mukaan. Joskus on vaikea tunnistaa tarvittava data olemassa olevasta datasta. Datan määrittämiseen voidaan käyttää itse kehitettyjä työkaluja tarpeen mukaan. Olemassa olevan datan hakemiseen kyselyt tulisi luoda etukäteen. Vaikeuksien ilmetessä tiedonhallintatiimiltä voi pyytää tarvittavien tietojen luomista tai kloonaamista.
Työn asetukset	Kun työt on noudettu tuotetietojärjestelmään (PDS), ne on määritettävä laadunvarmistusalueella (QA), jotta työt eivät lähetetä tuotantotarkenteen tai polun tietojen kanssa. Työnmääritystyökaluja tulisi käyttää asennuksen aikana tapahtuvien inhimillisten virheiden välttämiseksi.
Ad-hoc-pyyntö	Saattaa olla tilanteita, jolloin alusta loppuun testaus tarvitsee tukea ylä- tai alavirran sovellusten ongelman vuoksi. Nämä pyynnöt lisäävät suoritussyklin aikaa ja vaivaa. Automaatioskriptien, regressioskriptien ja runkoskriptien käyttö voi auttaa vähentämään aika- ja vaivakustannuksia.
Ajanmukaiset julkaisut laajuuden muutoksille	Saattaa syntyä tilanne, jossa koodin vaikutus muuttaa täysin järjestelmän ulkoasun ja käyttökokemuksen. Tämä voi edellyttää muutoksia testitapauksiin, skripteihin ja dataan. Käytössä tulee olla laajuuden muutosten hallintaprosessi ja vaikutusanalyysi.

Yleisiä kohtaamia poikkeamia

Kun työ epäonnistuu, jono raportoi vikakoodin. Alla oleva luettelo kattaa koodit, joihin keskustietokoneiden testaaja törmää useimmin, sekä tavanomaisen syyn.

1. S001 — I/O-virhe tapahtui.

   Syy — Tiedoston lopun lukeminen, tiedoston pituusvirhe tai yritys kirjoittaa vain luku -tilassa olevaan tiedostoon.

2. S002 — Virheellinen I/O-tietue.

   Syy — Yritetään kirjoittaa tietue, joka on pidempi kuin tietueen pituus.

3. S004 — Virhe tapahtui OPEN-tilassa.

   Syy — Virheellinen suoraveloitus.

4. S013 — Virhe avattaessa tietojoukkoa.

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

5. S0C1 - Operapoikkeus.

   Syy — Tiedostoa ei voida avata tai DD-kortti puuttuu.

6. S0C4 — Suojauspoikkeus / tallennusrikkomus.

   Syy — Ohjelma ei pysty käyttämään tallennustilaa.

7. S0C7 — Ohjelmatarkistuksen poikkeus, tiedot.

   Syy — Tietueen tai tiedoston asettelun muutos.

8. Sx22 – Työ on peruttu.

   Syy — Työ päättyi ennen valmistumista; keskimmäinen numero osoittaa, kuka tai mikä sen peruutti.

9. S222 — Käyttäjä peruutti työn ilman vedosta.
10. S322 — Työn tai vaiheen aika ylitti määritetyn rajan, tai ohjelma on silmukassa tai TIME-parametri on riittämätön.
11. S522 — Siirtoverkonhaltijan istunnon aikakatkaisu.
12. S806 — Linkittäminen tai lataaminen ei onnistu.

    Syy — Työ ei löydä määritettyä latausmoduulia.

13. S80A — Virtuaalitallennustilaa ei ole riittävästi GETMAIN- tai FREEMAIN-pyyntöjen täyttämiseen.
14. S913 — Yritetään käyttää tietojoukkoa, jonka käyttöön käyttäjällä ei ole oikeutta.
15. Sx37 — Tietojoukolle ei voitu varata riittävästi tallennustilaa.

Virheiden avustaja — Erittäin suosittu työkalu yksityiskohtaisen tiedon hankkimiseen erityyppisistä poikkeamista.

Yleisiä ongelmia suurtietokoneiden testauksessa

• Job Abends — Työn onnistuneen suorittamisen varmistamiseksi sinun tulee tarkistaa tiedot, syöttötiedosto ja se, ovatko moduulit tietyssä paikassa. Poikkeamia voi esiintyä useista syistä, joista yleisimpiä ovat virheelliset tiedot, väärä syöttökenttä, päivämääräristiriita tai ympäristöongelmat.
• Tulostiedosto tyhjä — Vaikka työ saattaa toimia onnistuneesti (MaxCC 0), tulos ei välttämättä ole odotetun kaltainen. Joten ennen minkään testitapauksen läpäisemistä testaajan on varmistettava, että tuloste on ristiinvarmennettu. Vasta sen jälkeen testausta tulisi jatkaa.
• Syötetiedosto tyhjä — Joissakin sovelluksissa tiedostot vastaanotetaan ylävirran prosesseilta. Ennen kuin vastaanotettua tiedostoa käytetään nykyisen sovelluksen testaamiseen, tiedot tulisi tarkistaa uudelleen suorittamisen ja muokkaamisen välttämiseksi.

UKK