Пре учења концепата за тестирање главног рачунара, дозволите да научимо
Шта је Маинфраме?
Главни рачунар је рачунарски систем високих перформанси и велике брзине. Користи се за рачунарство већих размера које захтева велику доступност и сигурност. Углавном се користи у секторима попут финансија, осигурања, малопродаје и другим критичним областима где се огромни подаци обрађују више пута.
Испитивање главног рачунара
Маинфраме тестирање је процес тестирања софтверских апликација и услуга заснованих на Маинфраме системима. Сврха тестирања главног рачунара је да се методама верификације и валидације осигурају перформансе, поузданост и квалитет софтверске апликације или услуге и да се провери да ли је спремна за примену.
Током извођења Маинфраме тестирања, тестер мора само да зна о навигацији на ЦИЦС екранима. Прилагођени су за специфичне примене. Било какве промене у коду у ЦОБОЛ-у, ЈЦЛ, итд. Тестеру не морају да брину због емулатора постављеног на машини. Промене које раде на једном емулатору терминала радиће и на другима.
- Апликација Маинфраме (иначе названа батцх батцх) тестирана је на основу тестова развијених уз коришћење захтева
- Тестирање главног рачунара обично се изводи на постављеном коду користећи различите комбинације података постављене у улазну датотеку.
- Апликацијама које се изводе на главном рачунару може се приступити преко емулатора терминала. Емулатор је једини софтвер који треба да се инсталира на клијентском рачунару.
У овом упутству за почетнике научићете-
- Атрибути главног рачунара
- Класификација ручног тестирања у главном рачунару
- Како се врши тестирање главног рачунара
- Алати за тестирање аутоматизације главног рачунара
- Методологија у испитивању главног рачунара
- Кораци укључени у серијско тестирање
- Кораци укључени у мрежно тестирање
- Кораци укључени у тестирање интернетске - батцх интеграције
- Команде коришћене у Маинфраме тестирању
- Предуслови за започињање тестирања главног рачунара
- Најбоље праксе
- Испитивање главног рачунара Изазови и решавање проблема
- Наишли су на уобичајене Абенде
- Уобичајени проблем са којим се суочавало током тестирања главног рачунара
Атрибути главног рачунара
- Виртуал Стораге
- То је техника која омогућава процесору да симулира главну меморију која је већа од стварне количине стварне меморије.
- То је техника ефикасне употребе меморије за чување и извршавање задатака различитих величина.
- Користи меморију на диску као продужетак стварне меморије.
- Мултипрограмирање
- Рачунар истовремено извршава више програма. Али у било ком тренутку само један програм може имати контролу над ЦПУ-ом.
- То је могућност која омогућава ефикасну употребу ЦПУ-а.
- Групна обрада
- То је техника којом се било који задатак обавља у јединицама познатим као послови.
- Посао може узроковати извршавање једног или више програма у низу.
- Планер послова доноси одлуку о редоследу извршавања послова. Да би се повећала просечна пропусност, послови се распоређују према приоритету и класи.
- Потребне информације за серијску обраду пружају се путем ЈЦЛ (ЈЕЗИК ЗА КОНТРОЛУ ПОСЛА). ЈЦЛ описује серијски посао - потребне програме, податке и ресурсе.
- Тиме Схаринг
- У систему за поделу времена, сваки корисник има приступ систему преко терминалног уређаја. Уместо да подноси послове који су предвиђени за касније извршавање, корисник уноси наредбе које се одмах обрађују.
- Отуда се ово назива „Интерактивна обрада“. Омогућава кориснику директну интеракцију са рачунаром.
- Обрада временским уделом позната је под називом „Обрада у предњем плану“, а серијска обрада посла је позната као „Обрада у позадини“.
- Споолинг
- СПООЛинг означава симултане периферне операције на мрежи .
- СПООЛ уређај се користи за складиштење резултата програма / апликације. Споол излаз је усмерен на излазне уређаје попут штампача (ако је потребно).
- То је објекат који користи предност међуспремника да би ефикасно искористио излазне уређаје.
Класификација ручног тестирања у главном рачунару
Главно рачунарско тестирање може се класификовати у две врсте:
- Серијско тестирање посла -
- Процес тестирања укључује извршавање серијских послова за функционалност имплементирану у тренутном издању.
- Резултати теста извучени из излазних датотека и базе података се верификују и бележе.
- Онлине тестирање -
- Онлајн тестирање односи се на тестирање ЦИЦС екрана, што је слично тестирању веб странице.
- Функционалност постојећих екрана може се променити или додати нови екрани.
- Разне апликације могу имати екране са упитима и екране за ажурирање. Функционалност ових екрана треба проверити у оквиру мрежног тестирања.
Како се врши тестирање главног рачунара
- Пословни тим припрема документацију са захтевима. Што одређује како ће се одређена ставка или процес изменити у циклусу објављивања.
- Тим за тестирање и развој добијају документ о захтевима. Схватиће на колико ће процеса промена утицати. Обично у издању прилагођени захтев директно утиче на само 20-25% апликације. Преосталих 75% издања односиће се на функционалности попут тестирања апликација и процеса.
- Дакле, апликација Маинфраме мора бити тестирана из два дела:
- Захтеви за тестирање - Тестирање апликације ради функционалности или промене поменуте у документу захтева.
- Тестирање интеграције - Тестирање целокупног процеса или друге апликације која прима или шаље податке у погођену апликацију. Испитивање регресијом је примарни фокус ове активности испитивања.
Алати за тестирање аутоматизације главног рачунара
Испод је листа алата који се могу користити за тестирање аутоматизације главног рачунара.
- РЕКСКС
- Екцел
- КТП
Методологија у испитивању главног рачунара
Размотримо пример: КСИЗ осигуравајуће друштво има модул за упис чланова. Потребни су подаци са екрана за регистрацију чланова и ван мреже. Као што смо раније разговарали, потребна су два приступа за тестирање главног рачунара, мрежно тестирање и серијско тестирање.
- Онлајн тестирање се врши на екрану за упис чланова. Баш као и веб страница, база података се потврђује подацима унетим преко екрана.
- Учлањење ван мреже може бити упис на папир или упис на независну веб локацију. Ванмрежни подаци (који се називају и групни) уносиће се у базу података компаније путем серијских послова. Улазна равна датотека се припрема према прописаном формату података и убацује у редослед серијских послова. Дакле, за тестирање апликација на главном рачунару можемо користити следећи приступ.
- Први посао у низу серијских послова провјерава унесене податке. Рецимо на пример специјални знак, абецеде у пољима само са бројевима итд.
- Други посао потврђује доследност података на основу услова пословања. На пример, упис детета не би требало да садржи зависне податке, поштански број члана (који уписаним планом није доступан за услугу) итд.
- Трећи посао модификује податке у формату који се може унети у базу података. На пример, брисање назива плана (база података чува само ИД плана и назив плана осигурања), додавање датума уноса итд.
- Четврти посао учитава податке у базу података.
- Групно тестирање посла врши се у овом процесу у две фазе -
- Сваки посао се потврђује одвојено, а
- Интеграција између послова провјерава се пружањем уноса равне датотеке првом послу и провјером базе података. (Посреднички резултати морају бити потврђени ради додатног опреза)
Следи метода која се примењује за тестирање главног рачунара:
Корак 1) : Схакедовн / тестирање дима
Главни фокус у овој фази је да се провери да ли је постављени код у правом тест окружењу. Такође обезбеђује да са кодом нема критичних проблема.
Корак 2) : Тестирање система
Испод су врсте испитивања која се раде у оквиру системског тестирања.
- Групно тестирање - Ово тестирање ће се извршити валидацијом резултата теста на излазним датотекама и променама података које су извршили серијски послови у опсегу тестирања и њихово снимање.
- Онлајн тестирање - Ово тестирање ће се обавити на предњем крају апликације на главном рачунару. Овде се апликација тестира на тачно поље уласка попут плана осигурања, камате на план итд.
- Тестирање интернетске батцх интеграције - Ово тестирање ће се обавити на системима који имају батцх процесе и онлине апликацију. Проверава се проток података и интеракција између мрежних екрана и скупних послова.
( Пример за ову врсту тестирања - размотрите ажурирање детаља плана, попут повећања каматне стопе. Промена камате врши се на екрану за ажурирање, а детаљи стања на погођеним рачунима биће измењени само ноћним пакетним послом. Тестирање у овом случају ће се то извршити потврђивањем екрана детаља плана и покретања серијског посла за ажурирање свих рачуна).
- Тестирање базе података - базе података у којима се подаци из апликације главног рачунара (ИМС, ИДМС, ДБ2, ВСАМ / ИСАМ, секвенцијални скупови података, ГДГ) валидирају за њихов изглед и складиштење података.
Корак 3) : Тестирање интеграције система
Примарна сврха овог испитивања је да потврди функционалност система који су у интеракцији са системом који се тестира.
Захтеви не утичу директно на ове системе. Међутим, они користе податке из система који се тестира. Важно је тестирати интерфејс и различите врсте порука (као што је посао успешан, посао неуспешан, база података ажурирана итд.) Које могу да се крећу између система и резултирајућих радњи које појединачни системи предузимају.
Врсте испитивања која се раде у овој фази су
- Групно тестирање
- Интернет тестирање
- Онлајн - серијско тестирање интеграције
Корак 4) : Испитивање регресије
Регресијско тестирање је уобичајена фаза у било којој врсти пројекта тестирања. Ово тестирање у Маинфрамес-у осигурава да тренутно издање пројекта не утиче на серијске послове и мрежне екране који нису у директној интеракцији са системом који се тестира (или не спадају у опсег захтева).
Да би се постигло ефикасно регресијско тестирање, одређени скуп тест случајева треба да се уђе у ужи избор у зависности од њихове сложености и треба направити регресијско лежиште (Репозиторијум тест случајева). Овај сет треба ажурирати сваки пут када се у издање уведе нова функционалност.
Корак 5) : Испитивање перформанси
Ово тестирање се врши како би се идентификовала уска грла у погођеним областима као што су подаци са предњег дела, надоградња интернетских база података и пројекција скалабилности апликације.
Корак 6) : Испитивање сигурности
Ово тестирање се врши како би се процијенило колико је добро апликација дизајнирана и развијена за супротстављање анти-сигурносним нападима.
На систему треба обавити двоструко тестирање безбедности - сигурност главног рачунара и мрежна сигурност.
Карактеристике које треба тестирати су
- Интегритет
- Повјерљивост
- Овлашћење
- Аутентикација
- Доступност
Кораци укључени у серијско тестирање
- Након што КА тим прими одобрени пакет (пакет садржи процедуре, ЈЦЛ, контролне картице, модуле итд.), Испитивач треба да прегледа и преузме садржај у ПДС по потреби.
- Претворите производни ЈЦЛ или ЈЦЛ за развој у КА ЈЦЛ, који се иначе назива ЈОБ СЕТУП.
- Копирање производне датотеке и припрема тест датотека.
- За сваку функционалност биће дефинисан редослед послова. (Као што је објашњено у примеру у одељку Методологија у главном оквиру). Послови се предају помоћу наредбе СУБ са датотекама тест података.
- Проверите посредничку датотеку како бисте идентификовали разлоге због којих недостају подаци или грешке.
- Проверите коначну излазну датотеку, базу података и Споол да бисте потврдили резултате теста.
- Ако посао не успе, калем ће имати разлог за неуспех посла. Решите грешку и поново пошаљите посао.
Извештавање о испитивању - Дефект треба евидентирати ако стварни резултат одступа од очекиваног.
Кораци укључени у мрежно тестирање
- Изаберите екран На мрежи у тестном окружењу.
- Тестирајте свако поље за прихватљиве податке.
- Тестирајте тестни сценарио на екрану.
- Проверите базу података за ажурирање података са мрежног екрана.
Извештавање о испитивању - Дефект треба евидентирати ако стварни резултат одступа од очекиваног.
Кораци укључени у тестирање интернетске - батцх интеграције
- Покрените посао у тест окружењу и потврдите податке на мрежним екранима.
- Ажурирајте податке на мрежним екранима и потврдите да ли је пакетни посао правилно покренут са ажурираним подацима.
Команде коришћене у Маинфраме тестирању
- ПРИЈАВА - Пошаљите посао у позадини.
- ОТКАЖИ - Откажите позадински посао.
- ДОДЕЛИТИ - Доделити скуп података
- ЦОПИ - Копирајте скуп података
- РЕНАМЕ - Преименуј скуп података
- ИЗБРИШИ - Избриши скуп података
- СЦАН ЈОБ -Да бисте повезали ЈЦЛ са програмом, библиотекама, датотекама итд. Без извршења.
Постоје и многе друге команде које се користе по потреби, али нису тако честе.
Предуслови за започињање тестирања главног рачунара
Основни детаљи потребни за тестирање главног рачунара су:
- ИД за пријављивање и лозинка за пријављивање у апликацију.
- Кратко знање о ИСПФ наредбама.
- Имена датотека, квалификатор датотека и њихови типови.
Пре почетка тестирања главног рачунара, следећи аспекти треба да се верификују.
- Посао
- Направите скенирање посла (наредба - ЈОБСЦАН) да бисте проверили грешке пре него што га извршите.
- Параметар КЛАСЕ треба усмерити на класу теста.
- Излаз посла усмерите у споол или ЈХС или према захтеву помоћу параметра МСГЦЛАСС.
- Преусмерите е-пошту у послу у намотај или тестни ИД поште.
- Коментирајте ФТП кораке за почетно тестирање, а затим усмјерите посао на тест сервер.
- У случају да се у послу генерише ИМР (евиденција управљања инцидентима), само додајте коментар „ТЕСТИРАЊЕ СВРХЕ“ у посао или параметарску картицу.
- Све продукцијске библиотеке у послу треба променити и указати на пробне библиотеке.
- Посао не треба остављати без надзора.
- Да бисте спречили да се посао изводи у бесконачној петљи у случају било какве грешке, ТИМЕ параметар треба додати са наведеним временом.
- Сачувајте излазне задатке, укључујући калем. Калем се може сачувати помоћу КСДЦ.
- Филе
- Направите тест датотеку само потребне величине. Користите ГДГ-ове (Генерационе групе података - датотеке са истим именом, али са секвенцијалним бројевима верзија - МИЛИБ.ЛИБ.ТЕСТ.Г0001В00, МИЛИБ.ЛИБ.ТЕСТ.Г0002В00 итд.) Када је потребно за чување података у узастопне датотеке са истим именом.
- Параметар ДИСП (Диспозиција - описује систем за извођење задржавања или брисања скупа података након нормалног или абнормалног завршетка корака или посла) треба правилно кодирати.
- Уверите се да су све датотеке коришћене за извршавање посла правилно сачуване и затворене како бисте спречили да посао пређе у ХОЛД.
- Током тестирања помоћу ГДГ-ова, уверите се да се указује на праву верзију.
- База података
- Током извршавања посла или мрежног програма, уверите се да ненамерни подаци нису уметнути, ажурирани или избрисани.
- Такође, осигурајте да се за тестирање користи тачна ДБ2 регија.
- Тест случајева
- Увек тестирајте граничне услове као што су - Празна датотека, Прва обрада записа, Последња обрада записа итд.
- Увек укључите и позитивне и негативне услове испитивања.
- У случају да се у програму користе стандардни поступци попут поновног покретања контролне тачке, Абенд модули, контролне датотеке итд. Укључују испитне случајеве за потврду да ли су модули коришћени исправно.
- Тест подаци
- Подешавање података о тестирању треба обавити пре почетка тестирања.
- Никада не мењајте податке у тестној регији без обавештења. Можда постоје и други тимови који раде са истим подацима, а њихов тест не би успео.
- У случају да су производне датотеке потребне током извршења, потребно је добити одговарајуће овлашћење пре копирања или употребе.
Најбоље праксе
- У случају покретања серијског посла, МАКС ЦЦ 0 је показатељ да је посао успешно изведен. То не значи да функционалност ради у реду. Посао ће се успешно изводити чак и када је излаз празан или није према очекивањима. Дакле, увек се очекује да проверимо све излазе пре проглашавања посла успешним.
- Увек је добра пракса да се посао на тестирању изврши суво. Суво покретање се врши са празним улазним датотекама. Овај поступак треба следити за послове на које утичу промене направљене за циклус испитивања.
- Пре него што започне циклус тестирања, постављени тест посао треба обавити унапред. Ово ће вам помоћи да унапред откријете било какву ЈЦЛ грешку, а тиме и уштеду времена током извршавања.
- Док приступате ДБ2 табелама путем СПУФИ (опција на емулатору за приступ ДБ2 табелама), увек поставите аутоматско урезивање као "НЕ" како бисте избегли случајна ажурирања.
- Доступност података о испитивању је примарни изазов у групном тестирању. Потребне податке треба створити много пре циклуса испитивања и проверити их у потпуности.
- Неке мрежне трансакције и скупни послови могу уписивати податке у МК (Мессаге Куеуе) за пренос података у друге апликације. Ако подаци нису важећи, могу онемогућити / зауставити МК-ове, то ће утицати на цео процес тестирања. Добра је пракса проверити да ли МК раде добро након тестирања.
Испитивање главног рачунара Изазови и решавање проблема
| Изазови | Приступ |
| Непотпуни / нејасни захтеви Можда постоји приступ корисничком приручнику / водичу за обуку, али они нису исти као документовани захтеви. | Испитивачи би требали бити укључени у СДЛЦ од фазе захтева надаље. Ово ће помоћи да се провери да ли се захтеви могу тестирати. |
| Постављање података / идентификација Постоје случајеви у којима би постојеће податке требало поново користити према захтеву. Понекад је тешко идентификовати потребне податке из постојећих података. | За подешавање података могу се користити домаћи алати према потреби. За дохваћање постојећих података, упите треба направити унапред. У случају било каквих потешкоћа, тиму за управљање подацима може се поставити захтев за креирање или клонирање потребних података. |
| Постављање посла Након што се послови преузму у ПДС, посао треба подесити у КА регији. Тако да се послови не предају са производним квалификатором или детаљима путање. | Треба користити алате за подешавање посла како би се превазишле људске грешке направљене током подешавања. |
| Ад-хоц захтев Можда постоје ситуације када треба подржати тестирање од краја до краја због проблема у проблемима са апликацијама изнад или низводно. Ови захтеви повећавају време и напор у циклусу извршења. | Коришћење скрипти за аутоматизацију, регресионе скрипте и скрипте за скелет могу помоћи у смањењу времена и напора. |
| Правовремена издања за промену опсега Можда постоји ситуација када утицај кода може у потпуности променити изглед и осећај система. Ово може захтевати промену тест случајева, скрипти и података. | Требало би да постоје поступак управљања променом обима и анализа утицаја. |
Наишли су на уобичајене Абенде
- С001 - Дошло је до И / О грешке.
Разлог - Читање на крају датотеке, грешка у дужини датотеке, покушај писања у датотеку само за читање.
- С002 - Неисправан И / О запис.
Разлог - Покушај писања записа дужег од записа.
- С004 - Дошло је до грешке током ОТВОРЕНОГ.
Разлог - неважећи ДЦБ
- С013 - Грешка при отварању скупа података.
Разлог - члан ПДС-а не постоји, дужина записа у програму не одговара стварној дужини записа.
- С0Ц1 - Изузетак за рад
Разлог-Није могуће отворити датотеку, недостаје ДД картица
- С0Ц4 - Изузетак од заштите / кршење складишта
- Разлог - покушај приступа складишном простору који није доступан програму.
- СЦ07 - Изузетак за проверу програма - Подаци
- Разлог - промена у распореду записа или распореду датотека.
- Ск22 - Посао је отказан
- С222 - Посао отказао корисник без думп-а.
- С322 - Време посла или корака премашило је наведено ограничење или је програм у петљи или је недовољан временски параметар.
- С522 - Истек времена сесије ТСО.
- С806 -Не може се повезати или учитати.
Разлог - ИД посла не може пронаћи наведени модул учитавања.
- С80А - Нема довољно виртуелног складишта за задовољавање ГЕТМАИН или ФРЕЕМАИН захтева.
- С913 - Покушај приступа скупу података који корисник није овлашћен.
- Ск37 - Није могуће доделити довољно простора за складиштење података.
Помоћ при грешкама - веома популаран алат за добијање детаљних информација о разним врстама абенда.
Уобичајени проблем са којим се суочавало током тестирања главног рачунара
- Напусти посао - Да бисте успешно завршили посао, требало би да проверите податке, улазну датотеку и модуле који су присутни на одређеној локацији или не. Абендови се могу суочити из више разлога, а најчешћи су - Неисправни подаци, Нетачно поље за унос, неусклађеност датума, еколошки проблеми итд.
- Излазна датотека празна -Иако се посао можда успешно изводи (МакЦЦ 0), излаз можда није онакав какав се очекивао. Дакле, пре него што прође било који тест случај, испитивач мора да се увери да је излаз укрштен. Тек онда наставите даље.
- Улазна датотека празна - У неким апликацијама датотеке ће се примати из узлазних процеса. Пре употребе примљене датотеке за тестирање тренутне апликације, податке треба унакрсно верификовати како би се избегло поновно извршавање и прерада.
Резиме:
- Испитивање главног рачунара је попут било којег другог поступка испитивања почев од прикупљања захтева, дизајна теста, извршења теста и извештавања о резултатима.
- Да би ефикасно тестирао апликацију, испитивач треба да учествује на састанцима за дизајн који су заказали развојни и пословни тимови.
- Обавезно је да се испитивач навикне на различите функције тестирања главног рачунара. Попут навигације на екрану, креирања датотека и ПДС-а, чувања резултата теста итд. Пре почетка циклуса теста.
- Тестирање апликација на главном рачунару траје дуго. Јасан распоред испитивања треба следити за дизајн теста, подешавање података и извршење.
- Групно тестирање и мрежно тестирање требало би да се обављају ефикасно, а да се не пропусти ниједна функционалност наведена у захтеву, а ниједан тест случај не сме бити поштеђен.