Mainframe testēšana - pilnīga apmācība

Satura rādītājs:

Anonim

Pirms mācīties lieldatoru testēšanas koncepcijas, ļauj mācīties

Kas ir lieldators?

Lielframe ir augstas veiktspējas un ātrgaitas datorsistēma. To izmanto lielāka mēroga skaitļošanas vajadzībām, kam nepieciešama liela pieejamība un drošība. To galvenokārt izmanto tādās nozarēs kā finanses, apdrošināšana, mazumtirdzniecība un citās kritiskās jomās, kur milzīgi dati tiek apstrādāti vairākas reizes.

Mainframe testēšana

Mainframe Testing ir programmatūras lietojumprogrammu un pakalpojumu testēšanas process, kura pamatā ir Mainframe Systems. Lielkadru testēšanas mērķis ir nodrošināt programmatūras lietojumprogrammu vai pakalpojumu veiktspēju, uzticamību un kvalitāti, izmantojot verifikācijas un validācijas metodes, un pārbaudīt, vai tā ir gatava izvietošanai.

Veicot lieldatora testēšanu, testētājam ir jāzina tikai par navigāciju CICS ekrānos. Tie ir pielāgoti īpašām lietojumprogrammām. Jebkurām izmaiņām, kas veiktas kodā COBOL, JCL utt. Testerī, nav jāuztraucas par mašīnā iestatīto emulatoru. Izmaiņas, kas darbojas vienā termināļa emulatorā, darbosies arī ar citiem.

  • Lietotne Mainframe (citādi saukta par darba paketi) tiek pārbaudīta, ņemot vērā testa gadījumus, kas izstrādāti, izmantojot prasības
  • Mainframe testēšana parasti tiek veikta izvietotajā kodā, izmantojot dažādas datu kombinācijas, kas iestatītas ievades failā.
  • Lietotnēm, kas darbojas lieldatorā, var piekļūt, izmantojot termināļa emulatoru. Emulators ir vienīgā programmatūra, kas jāinstalē klienta mašīnā.

Šajā apmācībā iesācējiem jūs uzzināsiet

  • Mainframe atribūti
  • Manuālās testēšanas klasifikācija lieldatorā
  • Kā veikt lieldatoru testēšanu
  • Lielframe automatizācijas testēšanas rīki
  • Metodoloģija lieldatoru testēšanā
  • Paketes testēšanā iesaistītie soļi
  • Tiešsaistes testēšanā iesaistītie soļi
  • Tiešsaistes - partijas integrācijas testēšanā iesaistītie soļi
  • Mainframe testēšanā izmantotās komandas
  • Priekšnosacījumi, lai sāktu lieldatora testēšanu
  • Labākā pieredze
  • Lielkadru testēšanas izaicinājumi un problēmu novēršana
  • Bieži sastopami Abends
  • Bieži sastopama problēma, ar kuru saskaras lieldatoru testēšanas laikā

Mainframe atribūti

  1. Virtuālā krātuve
    1. Tas ir paņēmiens, kas ļauj procesoram simulēt galveno atmiņu, kas ir lielāka par faktisko reālās atmiņas apjomu.
    2. Tā ir metode, kā efektīvi izmantot atmiņu dažāda lieluma uzdevumu glabāšanai un izpildei.
    3. Tas izmanto diska krātuvi kā reālās krātuves paplašinājumu.
  2. Daudzprogrammēšana
    1. Dators vienlaikus izpilda vairākas programmas. Bet jebkurā brīdī tikai viena programma var kontrolēt procesoru.
    2. Tā ir iespēja, lai efektīvi izmantotu CPU.
  3. Partijas apstrāde
    1. Tā ir tehnika, ar kuras palīdzību jebkuru uzdevumu izpilda vienībās, kuras dēvē par darbiem.
    2. Darbs var izraisīt vienas vai vairāku programmu secīgu izpildi.
    3. Darbu plānotājs pieņem lēmumu par darbu izpildes secību. Lai maksimāli palielinātu vidējo caurlaidspēju, darbi tiek plānoti atbilstoši viņu prioritātei un klasei.
    4. Nepieciešamā informācija pakešu apstrādei tiek nodrošināta, izmantojot JCL (DARBA KONTROLES VALODA). JCL apraksta pakešdarbu - programmas, nepieciešamos datus un resursus.
  4. Laika koplietošana
    1. Laika koplietošanas sistēmā katram lietotājam ir piekļuve sistēmai, izmantojot termināla ierīci. Tā vietā, lai iesniegtu darbus, kuri ir ieplānoti vēlākai izpildei, lietotājs ievada komandas, kas tiek apstrādātas nekavējoties.
    2. Tāpēc to sauc par "interaktīvo apstrādi". Tas ļauj lietotājam tieši mijiedarboties ar datoru.
    3. Laika koplietošanas apstrāde ir pazīstama kā "Priekšplāna apstrāde", un pakešdarba apstrāde ir pazīstama kā "Fona apstrāde".
  5. Spole
    1. SPOOLing apzīmē vienlaicīgas perifērās operācijas tiešsaistē .
    2. SPOOL ierīci izmanto, lai saglabātu programmas / lietojumprogrammas izvadi. Spolētā izvade tiek novirzīta uz izvades ierīcēm, piemēram, printeri (ja nepieciešams).
    3. Tas ir objekts, kas izmanto buferizācijas priekšrocības, lai efektīvi izmantotu izvades ierīces.

Manuālās testēšanas klasifikācija lieldatorā

Centrālā datora manuālo testēšanu var iedalīt divos veidos:

  1. Partijas darba pārbaude -
    • Testēšanas process ietver pakešdarbu izpildi pašreizējā laidienā ieviestajai funkcionalitātei.
    • Pārbauda un reģistrē testa rezultātus, kas iegūti no izvades failiem un datu bāzes.
  2. Tiešsaistes testēšana -
    • Tiešsaistes testēšana attiecas uz CICS ekrānu testēšanu, kas ir līdzīga tīmekļa lapas pārbaudei.
    • Varētu mainīt esošo ekrānu funkcionalitāti vai pievienot jaunus ekrānus.
    • Dažādās lietojumprogrammās var būt pieprasījumu ekrāni un atjaunināšanas ekrāni. Tiešsaistes testēšanas laikā jāpārbauda šo ekrānu funkcionalitāte.

Kā veikt lieldatoru testēšanu

  1. Biznesa komanda sagatavo prasību dokumentus. Kas nosaka, kā konkrētais vienums vai process tiks modificēts izlaišanas ciklā.
  2. Testēšanas grupa un izstrāde saņem prasību dokumentu. Viņi izdomās, cik daudz procesu ietekmēs izmaiņas. Parasti laidienā tikai 20-25% lietojumprogrammas ietekmē tieši pielāgotā prasība. Pārējie 75% izlaiduma būs paredzēti sākotnējām funkcijām, piemēram, lietojumprogrammu un procesu pārbaudei.
  3. Tātad lieldatora lietojumprogramma ir jāpārbauda divās daļās:
    1. Prasību pārbaude - lietojumprogrammas pārbaude attiecībā uz prasību dokumentā minēto funkcionalitāti vai izmaiņām.
    2. Integrācijas pārbaude - visa procesa vai citas lietojumprogrammas, kas saņem vai nosūta datus ietekmētajai lietojumprogrammai, pārbaude. Regresijas testēšana ir šīs testēšanas darbības galvenā uzmanība.

Lielframe automatizācijas testēšanas rīki

Zemāk ir saraksts ar rīkiem, kurus var izmantot lieldatoru automatizācijas testēšanai.

  • REXX
  • Excel
  • QTP

Metodoloģija lieldatoru testēšanā

Apskatīsim piemēru: XYZ apdrošināšanas sabiedrībai ir dalībnieku uzņemšanas modulis. Tas ņem datus gan no dalībnieku uzņemšanas ekrāna, gan bezsaistes reģistrācijas. Kā mēs iepriekš apspriedām, lieldatoru testēšanai, tiešsaistes testēšanai un sērijveida testēšanai ir nepieciešamas divas pieejas.

  • Tiešsaistes pārbaude tiek veikta dalībnieku uzņemšanas ekrānā. Tāpat kā tīmekļa lapa, arī datu bāze tiek validēta ar datiem, kas ievadīti caur ekrāniem.
  • Bezsaistes reģistrācija var būt reģistrēšanās papīra formā vai reģistrēšanās trešās puses vietnē. Bezsaistes dati (saukti arī par pakešu) tiks ievadīti uzņēmuma datu bāzē, izmantojot pakešdarbus. Ievades vienotais fails tiek sagatavots atbilstoši norādītajam datu formātam un tiek ievadīts pakešdarbu secībai. Tāpēc lieldatoru lietojumprogrammu testēšanai mēs varam izmantot šādu pieeju.
    • Pirmais pakešdarbu rindas darbs apstiprina ievadītos datus. Teiksim, piemēram, īpašo rakstzīmi, alfabētus tikai skaitļu laukos utt.
    • Otrais darbs apstiprina datu konsekvenci, pamatojoties uz uzņēmējdarbības apstākļiem. Piemēram, bērna reģistrācijā nedrīkst būt atkarīgi dati, locekļa pasta indekss (kas nav pieejams pakalpojumam pēc reģistrētā plāna) utt.
    • Trešais darbs modificē datus tādā formātā, kuru var ievadīt datu bāzē. Piemēram, plāna nosaukuma dzēšana (datu bāzē tiks saglabāts tikai plāna ID un apdrošināšanas plāna nosaukums), pievienošanas datums utt.
    • Ceturtais darbs ielādē datus datu bāzē.
  • Partijas darba pārbaude šim procesam tiek veikta divos posmos -
    • Katrs darbs tiek apstiprināts atsevišķi, un
    • Darbu integrācija tiek apstiprināta, nodrošinot ievades plakano failu pirmajam darbam un validējot datu bāzi. (Īpaši piesardzīgi jāapstiprina starpnieku rezultāti)

Mainframe testēšanai tiek izmantota šāda metode:

1. solis) : Shakedown / dūmu pārbaude

Šajā posmā galvenā uzmanība ir jāapstiprina, vai izvietotais kods ir pareizajā testa vidē. Tas arī nodrošina, ka ar kodu nav kritisku problēmu.

2. solis) : sistēmas pārbaude

Tālāk ir norādīti testēšanas veidi, kas veikti kā daļa no sistēmas testēšanas.

  1. Sērijas pārbaude - šī pārbaude tiks veikta, pārbaudot izvades failu testēšanas rezultātus un datu izmaiņas, ko veic testēšanas jomā esošie pakešdarbi, un tos reģistrējot.
  2. Tiešsaistes testēšana - šī pārbaude tiks veikta lieldatora lietojumprogrammas priekšpusē. Šeit tiek pārbaudīts, vai pieteikumam ir pareizs ievadlauks, piemēram, apdrošināšanas plāns, interese par plānu utt.
  3. Tiešsaistes sērijas integrācijas testēšana - šī pārbaude tiks veikta sistēmās, kurās ir pakešu procesi un tiešsaistes lietojumprogramma. Tiek pārbaudīta datu plūsma un mijiedarbība starp tiešsaistes ekrāniem un pakešdarbiem.

    ( Piemērs šāda veida testēšanai. Apsveriet iespēju atjaunināt informāciju par plānu, piemēram, procentu likmes palielināšanu. Procentu maiņa tiek veikta atjaunināšanas ekrānā, un skarto kontu atlikuma informāciju modificēs tikai nakts paketes darbs. Testēšana šajā gadījumā tas tiks veikts, apstiprinot ekrānu Plāna informācija un pakešdarba palaišanu visu kontu atjaunināšanai).

  4. Datu bāzes pārbaude - datu bāzes, kurās dati no lieldatora lietojumprogrammas (IMS, IDMS, DB2, VSAM / ISAM, secīgas datu kopas, GDG) tiek apstiprināti to izkārtojumam un datu glabāšanai.

3. solis) : Sistēmas integrācijas pārbaude

Šīs pārbaudes galvenais mērķis ir apstiprināt to sistēmu funkcionalitāti, kuras mijiedarbojas ar testējamo sistēmu.

Prasības šīs sistēmas tieši neietekmē. Tomēr viņi izmanto datus no pārbaudāmās sistēmas. Ir svarīgi pārbaudīt saskarni un dažāda veida ziņojumus (piemēram, veiksmīgs darbs, neveiksmīgs darbs, atjaunināta datu bāze utt.), Kas var iespējami plūst starp sistēmām un no tām izrietošajām atsevišķo sistēmu veiktajām darbībām.

Šajā posmā veikto testu veidi ir

  1. Partijas pārbaude
  2. Tiešsaistes testēšana
  3. Tiešsaistē - pakešu integrācijas testēšana

4. solis) : regresijas testēšana

Regresijas testēšana ir izplatīta fāze jebkura veida testēšanas projektā. Šī pārbaude lieldatoros nodrošina, ka pašreizējais projekta izlaidums neietekmē pakešdarbus un tiešsaistes ekrānus, kas tieši nesadarbojas ar testējamo sistēmu (vai uz kuriem neattiecas prasības).

Lai panāktu efektīvu regresijas testēšanu, atkarībā no to sarežģītības jāizvēlas konkrēts testa gadījumu kopums un jāizveido regresijas slānis (Test cases repository). Šis komplekts ir jāatjaunina ikreiz, kad laidienā tiek ieviesta jauna funkcionalitāte.

5. solis) : veiktspējas pārbaude

Šī pārbaude tiek veikta, lai identificētu vājās vietas tādās jomās kā populāri, piemēram, priekšgala dati, tiešsaistes datu bāzu jaunināšana un lai projektētu lietojumprogrammas mērogojamību.

6. solis) : drošības pārbaude

Šī pārbaude tiek veikta, lai novērtētu, cik labi lietojumprogramma ir izstrādāta un izstrādāta, lai apkarotu pretdrošības uzbrukumus.

Sistēmā jāveic divkārša drošības pārbaude - lieldatoru drošība un tīkla drošība.

Pārbaudītajām īpašībām ir

  1. Integritāte
  2. Konfidencialitāte
  3. Atļauja
  4. Autentifikācija
  5. Pieejamība

Paketes testēšanā iesaistītie soļi

  1. Pēc tam, kad kvalitātes nodrošināšanas komanda ir saņēmusi apstiprinātu paketi (pakete satur procedūras, JCL, vadības kartes, moduļus utt.), Testētājam pēc nepieciešamības jāpārskata saturs un jāizgūst PDS.
  2. Konvertējiet ražošanas JCL vai Development JCL uz QA JCL, ko citādi sauc par JOB SETUP.
  3. Ražošanas faila kopēšana un testa failu sagatavošana.
  4. Katrai funkcionalitātei tiks noteikta darba secība. (Kā paskaidrots sadaļā Mainframe metodoloģijas piemērā). Darbi jāiesniedz, izmantojot komandu SUB kopā ar testa datu failiem.
  5. Pārbaudiet starpfailu, lai identificētu datu trūkuma vai kļūdu iemeslus.
  6. Pārbaudiet gala izvades failu, datu bāzi un spoli, lai apstiprinātu testa rezultātus.
  7. Ja darbs neizdodas, spolei būs iemesls, kāpēc darbs neizdevās. Novērsiet kļūdu un atkārtoti iesniedziet darbu.

Testa ziņošana - defekts jāreģistrē, ja faktiskais rezultāts atšķiras no gaidītā.

Tiešsaistes testēšanā iesaistītie soļi

  1. Pārbaudes vidē atlasiet ekrānu Tiešsaiste.
  2. Katrā laukā pārbaudiet pieņemamos datus.
  3. Pārbaudiet testa scenāriju ekrānā.
  4. Tiešsaistes ekrānā pārbaudiet datu bāzes datu atjauninājumus.

Testa ziņošana - defekts jāreģistrē, ja faktiskais rezultāts atšķiras no gaidītā.

Tiešsaistes - partijas integrācijas testēšanā iesaistītie soļi

  1. Palaidiet darbu testa vidē un pārbaudiet datus tiešsaistes ekrānos.
  2. Atjauniniet datus tiešsaistes ekrānos un pārbaudiet, vai pakešdarbs ir pareizi palaists ar atjauninātajiem datiem.

Mainframe testēšanā izmantotās komandas

  1. IESNIEGT - Iesniedziet fona darbu.
  2. CANCEL - Atcelt fona darbu.
  3. PIEŠĶIRT - Piešķiriet datu kopu
  4. COPY - kopēt datu kopu
  5. RENAME - pārdēvēt datu kopu
  6. DELETE - dzēst datu kopu
  7. DARBA SCAN - lai sasaistītu JCL ar programmu, bibliotēkām, failu utt., To neizpildot.

Nepieciešamības gadījumā tiek izmantotas daudzas citas komandas, taču tās nav tik biežas.

Priekšnosacījumi, lai sāktu lieldatora testēšanu

Mainframe testēšanai nepieciešamā pamatinformācija ir:

  • Pieteikšanās ID un parole, lai pieteiktos lietojumprogrammā.
  • Īsas zināšanas par ISPF komandām.
  • Failu nosaukumi, failu kvalifikators un to veidi.

Pirms lieldatora testēšanas uzsākšanas jāpārbauda tālāk minētie aspekti.

  1. Darbs
    1. Veiciet darba skenēšanu (komanda - JOBSCAN), lai pirms tā izpildes pārbaudītu kļūdas.
    2. CLASS parametrs jānorāda uz testa klasi.
    3. Novietojiet darba izvadi spolē vai JHS vai pēc nepieciešamības, izmantojot parametru MSGCLASS.
    4. Pārvirziet darba e-pastu uz spoli vai testa pasta ID.
    5. Komentējiet sākotnējās testēšanas FTP darbības un pēc tam norādiet darbu uz testa serveri.
    6. Gadījumā, ja darbā tiek ģenerēts IMR (Incident Management record), vienkārši pievienojiet komentāru "TESTING PURPOSE" darba vai param kartītē.
    7. Visas darba bibliotēkas, kas atrodas darbā, ir jāmaina un jānorāda uz testa bibliotēkām.
    8. Darbu nevajadzētu atstāt bez uzraudzības.
    9. Lai neļautu darbam darboties bezgalīgā cikla kļūdu gadījumā, TIME parametrs jāpievieno ar norādītu laiku.
    10. Saglabājiet darba rezultātu, ieskaitot spoli. Spoli var saglabāt, izmantojot XDC.
  1. Fails
    1. Izveidojiet tikai vajadzīgā izmēra testa failu. Izmantojiet GDG (Generation Data Groups - faili ar tādu pašu nosaukumu, bet ar kārtas numuriem - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 utt.), Ja nepieciešams, lai datus glabātu secīgos failos ar tādu pašu nosaukumu.
    2. Failu parametrs DISP (Disposition - apraksta sistēmu, kā veikt datu kopas saglabāšanu vai dzēšanu pēc normālas vai neparastas darbības vai darba pārtraukšanas) ir pareizi jākodē.
    3. Pārliecinieties, vai visi faili, kas izmantoti darba izpildei, ir pareizi saglabāti un aizvērti, lai novērstu darba iekļūšanu HOLD.
    4. Pārbaudot, izmantojot GDG, pārliecinieties, vai ir norādīta pareizā versija.
  2. Datu bāze
    1. Veicot darbu vai tiešsaistes programmu, pārliecinieties, ka neparedzēti dati netiek ievietoti, atjaunināti vai dzēsti.
    2. Pārliecinieties arī, vai testēšanai tiek izmantots pareizais DB2 reģions.
  3. Pārbaudes gadījumi
    1. Vienmēr pārbaudiet robežnosacījumus, piemēram, - tukšs fails, pirmā ieraksta apstrāde, pēdējā ieraksta apstrāde utt.
    2. Vienmēr iekļaujiet gan pozitīvus, gan negatīvus testa apstākļus.
    3. Gadījumā, ja programmā tiek izmantotas standarta procedūras, piemēram, Check point restart, Abend Modules, Control files utt., Iekļaujiet pārbaudes gadījumus, lai pārbaudītu, vai moduļi ir izmantoti pareizi.
  4. Testa dati
    1. Testa datu iestatīšana jāveic pirms testa sākuma.
    2. Nekad nemainiet datus par testa reģionu, par to nepaziņojot. Var būt citas komandas, kas strādā ar vieniem un tiem pašiem datiem, un viņu pārbaude neizdosies.
    3. Ja izpildes laikā ir nepieciešami ražošanas faili, pirms to kopēšanas vai izmantošanas jāsaņem atbilstoša atļauja.

Labākā pieredze

  1. Paketes darba izpildes ieskaite, MAX CC 0 ir rādītājs, ka darbs ir veiksmīgi izpildīts. Tas nenozīmē, ka funkcionalitāte darbojas labi. Darbs tiks veiksmīgi izpildīts pat tad, ja izvade būs tukša vai nē, kā paredzēts. Tāpēc vienmēr tiek gaidīts, lai visi rezultāti tiktu pārbaudīti pirms darba atzīšanas par veiksmīgu.
  2. Vienmēr ir laba prakse veikt pārbaudāmo darbu sausā režīmā. Sausā palaišana tiek veikta ar tukšiem ievades failiem. Šis process jāievēro attiecībā uz darbiem, kurus ietekmē testa ciklā veiktās izmaiņas.
  3. Pirms testa cikla sākuma iestatītais testa darbs jāveic savlaicīgi. Tas palīdzēs iepriekš uzzināt visas JCL kļūdas, tādējādi ietaupot laiku izpildes laikā.
  4. Piekļūstot DB2 tabulām, izmantojot SPUFI (emulatora opcija piekļūt DB2 tabulām), lai izvairītos no nejaušas atjaunināšanas, vienmēr iestatiet automātisko saistību iestatījumu kā "NĒ".
  5. Pārbaudes datu pieejamība ir galvenā problēma partijas testēšanā. Nepieciešamie dati jāizveido savlaicīgi pirms testa cikla, un jāpārbauda to pilnīgums.
  6. Daži tiešsaistes darījumi un pakešdarbi var ierakstīt datus MQ (Message Queue), lai pārsūtītu datus citām lietojumprogrammām. Ja dati nav derīgi, tie var atspējot / apturēt MQ, tas ietekmēs visu testēšanas procesu. Pēc pārbaudes ir laba prakse pārbaudīt, vai MQ darbojas labi.

Lielkadru testēšanas izaicinājumi un problēmu novēršana

Izaicinājumi Pieeja
Nepilnīgas / neskaidras prasības Var būt piekļuve lietotāja rokasgrāmatai / apmācības rokasgrāmatai, taču tās nav tādas pašas kā dokumentētās prasības. Testētājiem jābūt iesaistītiem SDLC, sākot ar prasību posmu. Tas palīdzēs pārbaudīt, vai prasības ir pārbaudāmas.
Datu iestatīšana / identifikācija Var būt situācijas, kad esošie dati jāizmanto atkārtoti, kā noteikts prasībā. Dažreiz ir grūti noteikt nepieciešamos datus no esošajiem datiem. Datu iestatīšanai pēc vajadzības var izmantot pašmāju rīkus. Lai iegūtu esošos datus, vaicājumi būtu jāveido iepriekš. Jebkuru grūtību gadījumā datu pārvaldības komandai var iesniegt pieprasījumu par nepieciešamo datu izveidošanu vai klonēšanu.
Darba iestatīšana Kad darbi ir izgūti PDS, tas ir jāiestata kvalitātes nodrošināšanas reģionā. Lai darbavietas netiktu iesniegtas ar ražošanas kvalifikāciju vai ceļa informāciju. Jāizmanto darba iestatīšanas rīki, lai pārvarētu iestatīšanas laikā pieļautās cilvēku kļūdas.
Ad-hoc pieprasījums Var būt situācijas, kad ir jāatbalsta testēšana no gala līdz galam, jo ​​ir problēmas ar augšējā vai pakārtotā lietojumprogrammu problēmām. Šie pieprasījumi palielina izpildes cikla laiku un piepūli. Automatizācijas, regresijas un skeleta skriptu izmantošana varētu palīdzēt samazināt laiku un piepūli.
Laika laidieni darbības jomas maiņai Var būt situācija, ka koda ietekme var pilnībā mainīt sistēmas izskatu. Tas var prasīt izmaiņas testa gadījumos, skriptos un datos. Jābūt ieviestai darbības jomas izmaiņu pārvaldības procesam un ietekmes analīzei.

Bieži sastopami Abends

  1. S001 - radās I / O kļūda.

    Iemesls - lasīšana faila beigās, faila garuma kļūda, mēģinājums ierakstīt tikai lasāmā failā.

  2. S002 - nederīgs I / O ieraksts.

    Iemesls - mēģinājums uzrakstīt ierakstu, kas ir garāks par ieraksta garumu.

  3. S004 - OPEN laikā radās kļūda.

    Iemesls - nederīgs DCB

  4. S013 - kļūda, atverot datu kopu.

    Iemesls - PDS dalībnieks nepastāv, ieraksta garums programmā neatbilst faktiskajam ieraksta garumam.

  5. S0C1 - Operācijas izņēmums

    Iemesls - nevar atvērt failu, trūkst DD kartes

  6. S0C4 - aizsardzības izņēmums / krātuves pārkāpums
  7. Iemesls - mēģināt piekļūt programmai pieejamai krātuvei.
  8. SC07 - programmas pārbaudes izņēmums - dati
  9. Iemesls - izmaiņas ieraksta izkārtojumā vai faila izkārtojumā.
  10. Sx22 - darbs ir atcelts
  11. S222 - darbu atcēla lietotājs bez izgāšanas.
  12. S322 - darba vai soļa laiks pārsniedz norādīto ierobežojumu, vai arī programma atrodas ciklā vai nepietiekams laika parametrs.
  13. S522 - PSO sesijas noildze.
  14. S806 - Nevar saistīt vai ielādēt.

    Iemesls - darba ID nevar atrast norādīto ielādes moduli.

  15. S80A - nepietiek virtuālās krātuves, lai apmierinātu GETMAIN vai FREEMAIN pieprasījumus.
  16. S913 - mēģina piekļūt datu kopai, kurai lietotājs nav pilnvarots.
  17. Sx37 - datu kopai nevar piešķirt pietiekami daudz krātuves.

Kļūdu palīgs - ļoti populārs rīks, lai iegūtu detalizētu informāciju par dažādiem bojājumu veidiem.

Bieži sastopama problēma, ar kuru saskaras lieldatoru testēšanas laikā

  • Darbs nepietiek - lai veiksmīgi pabeigtu darbu, jums jāpārbauda dati, ievades fails un moduļi, kas atrodas konkrētajā vietā vai nē. Abends var saskarties vairāku iemeslu dēļ, visbiežāk sastopami - nederīgi dati, nepareizs ievades lauks, datumu neatbilstība, vides problēmas utt.
  • Izejas fails ir tukšs - lai arī darbs varētu darboties veiksmīgi (MaxCC 0), izeja var nebūt tā, kā gaidīts. Tāpēc pirms jebkura testa gadījuma nokārtošanas testētājam ir jāpārliecinās, vai izeja ir savstarpēji pārbaudīta. Tikai pēc tam rīkojieties tālāk.
  • Ievades fails ir tukšs - dažās lietojumprogrammās faili tiks saņemti no iepriekšējiem procesiem. Pirms saņemtā faila izmantošanas pašreizējās lietojumprogrammas testēšanai dati jāpārbauda, ​​lai izvairītos no atkārtotas izpildes un pārstrādes.

Kopsavilkums:

  • Mainframe testēšana ir kā jebkura cita testēšanas procedūra, sākot no prasību apkopošanas, testa noformēšanas, testa izpildes un rezultātu ziņošanas.
  • Lai efektīvi pārbaudītu lietojumprogrammu, testētājam jāpiedalās izstrādes un biznesa komandu plānotajās sanāksmēs.
  • Testētājam ir obligāti jāpierod pie dažādām lieldatoru testa funkcijām. Tāpat kā ekrāna navigācija, failu un PDS izveidošana, testa rezultātu saglabāšana utt., Pirms testa cikls sākas.
  • Mainframe lietojumprogrammu testēšana ir laikietilpīgs process. Pārbaudes projektēšanā, datu iestatīšanā un izpildē jāievēro skaidrs testu grafiks.
  • Partijas testēšana un tiešsaistes pārbaude jāveic efektīvi, neizlaižot nevienu no funkcijām, kas minētas prasības dokumentā, un nevajadzētu ietaupīt nevienu testa gadījumu.