Ujian Kerangka Utama - Tutorial Lengkap

Isi kandungan:

Anonim

Sebelum mempelajari konsep pengujian kerangka utama, mari belajar

Apa itu Kerangka Utama?

Kerangka utama adalah sistem komputer berprestasi tinggi dan berkelajuan tinggi. Ia digunakan untuk tujuan pengkomputeran berskala besar yang memerlukan ketersediaan dan keselamatan yang besar. Ia banyak digunakan dalam sektor seperti kewangan, insurans, runcit dan bidang kritikal lain di mana data besar diproses berkali-kali.

Ujian Kerangka Utama

Mainframe Testing adalah proses menguji aplikasi dan perkhidmatan perisian berdasarkan Mainframe Systems. Tujuan pengujian kerangka utama adalah untuk memastikan prestasi, kebolehpercayaan dan kualiti aplikasi atau perkhidmatan perisian dengan kaedah pengesahan dan pengesahan dan periksa apakah itu siap digunakan.

Semasa menjalankan ujian Mainframe, penguji hanya perlu mengetahui tentang navigasi skrin CICS. Mereka dibina khas untuk aplikasi tertentu. Sebarang perubahan yang dibuat pada kod di COBOL, JCL, dan lain-lain penguji tidak perlu bimbang tentang pemasangan emulator pada mesin. Perubahan yang berlaku pada satu emulator terminal akan berlaku pada yang lain.

  • Aplikasi Mainframe (sebaliknya disebut batch pekerjaan) diuji terhadap kes ujian yang dikembangkan menggunakan syarat
  • Mainframe Testing biasanya dilakukan pada kod yang digunakan menggunakan berbagai kombinasi data yang diset ke dalam file input.
  • Aplikasi yang berjalan di kerangka utama dapat diakses melalui emulator terminal. Emulator adalah satu-satunya perisian yang perlu dipasang pada mesin pelanggan.

Dalam tutorial pemula ini, anda akan belajar-

  • Atribut Kerangka Utama
  • Klasifikasi Pengujian Manual dalam Mainframe
  • Cara melakukan Ujian Mainframe
  • Alat Ujian Automasi Kerangka Utama
  • Metodologi dalam Ujian Kerangka Utama
  • Langkah-langkah yang terlibat dalam ujian Batch
  • Langkah-langkah yang terlibat dalam Ujian Dalam Talian
  • Langkah-langkah yang terlibat dalam ujian Dalam Talian - Integrasi Batch
  • Perintah yang digunakan dalam Mainframe Testing
  • Prasyarat untuk memulakan ujian mainframe
  • Amalan terbaik
  • Mainframe menguji Cabaran dan Penyelesaian Masalah
  • Kebiasaan yang dihadapi
  • Masalah biasa yang dihadapi semasa ujian mainframe

Atribut Kerangka Utama

  1. Penyimpanan Maya
    1. Ini adalah teknik yang membolehkan pemproses mensimulasikan penyimpanan utama yang lebih besar daripada jumlah simpanan sebenar.
    2. Ini adalah teknik untuk menggunakan memori dengan berkesan untuk menyimpan dan melaksanakan pelbagai tugas bersaiz.
    3. Ia menggunakan penyimpanan cakera sebagai lanjutan penyimpanan sebenar.
  2. Pengaturcaraan pelbagai
    1. Komputer menjalankan lebih daripada satu program pada masa yang sama. Tetapi pada waktu tertentu hanya satu program yang dapat mengendalikan CPU.
    2. Ini adalah kemudahan yang disediakan untuk menggunakan CPU secara efisien.
  3. Pemprosesan Kumpulan
    1. Ini adalah teknik yang mana tugas dapat diselesaikan dalam unit yang dikenal sebagai pekerjaan.
    2. Pekerjaan boleh menyebabkan satu atau lebih program dijalankan secara berurutan.
    3. Penjadual Pekerjaan membuat keputusan mengenai urutan di mana pekerjaan harus dilaksanakan. Untuk memaksimumkan hasil rata-rata, pekerjaan dijadwalkan mengikut keutamaan dan kelas mereka.
    4. Maklumat yang diperlukan untuk pemprosesan kumpulan diberikan melalui JCL (JOB CONTROL LANGUAGE). JCL menerangkan tugas kumpulan - program, data dan sumber daya yang diperlukan.
  4. Perkongsian Masa
    1. Dalam sistem pembahagian masa, setiap pengguna memiliki akses ke sistem melalui perangkat terminal. Daripada menyerahkan pekerjaan yang dijadwalkan untuk pelaksanaan kemudian, pengguna memasukkan perintah yang diproses dengan segera.
    2. Oleh itu ini dipanggil "Pemprosesan Interaktif". Ia membolehkan pengguna berinteraksi secara langsung dengan komputer.
    3. Pemprosesan bahagian masa dikenali sebagai "Pemprosesan Foreground" dan pemprosesan kumpulan kerja dikenali sebagai "Pemprosesan Latar Belakang."
  5. Tunjang
    1. SPOOLing bermaksud Operasi Periferal Serentak Dalam Talian .
    2. Peranti SPOOL digunakan untuk menyimpan output program / aplikasi. Output spooled diarahkan ke peranti output seperti pencetak (jika diperlukan).
    3. Ini adalah kemudahan yang memanfaatkan kelebihan buffering untuk menggunakan peranti output dengan cekap.

Klasifikasi Pengujian Manual dalam Mainframe

Ujian Manual Mainframe boleh dikelaskan kepada dua jenis:

  1. Ujian Kerja Kumpulan -
    • Proses pengujian melibatkan pelaksanaan pekerjaan batch untuk fungsi yang dilaksanakan dalam siaran semasa.
    • Hasil ujian yang diekstrak dari fail output dan pangkalan data disahkan dan direkodkan.
  2. Ujian Dalam Talian -
    • Pengujian dalam talian merujuk kepada pengujian skrin CICS yang serupa dengan pengujian laman web.
    • Fungsi layar yang ada dapat diubah, atau layar baru dapat ditambahkan.
    • Berbagai aplikasi boleh mempunyai skrin pertanyaan dan skrin kemas kini. Fungsi skrin ini perlu diperiksa sebagai sebahagian daripada ujian dalam talian.

Cara melakukan Ujian Mainframe

  1. Pasukan Perniagaan menyediakan dokumen keperluan. Yang menentukan bagaimana item atau proses tertentu akan diubah dalam kitaran pelepasan.
  2. Pasukan penguji dan pengembangan menerima dokumen keperluan. Mereka akan mengetahui berapa banyak proses yang akan dipengaruhi oleh perubahan tersebut. Biasanya, dalam siaran, hanya 20-25% aplikasi yang dipengaruhi secara langsung oleh keperluan yang disesuaikan. 75% pelepasan yang lain adalah untuk fungsi luar kotak seperti menguji aplikasi dan proses.
  3. Oleh itu, aplikasi Mainframe harus diuji dalam dua bahagian:
    1. Keperluan Ujian - Menguji aplikasi untuk fungsi atau perubahan yang disebutkan dalam dokumen keperluan.
    2. Pengujian Integrasi - Menguji keseluruhan proses atau aplikasi lain yang menerima atau menghantar data ke aplikasi yang terlibat. Uji Regresi adalah fokus utama aktiviti pengujian ini.

Alat Ujian Automasi Kerangka Utama

Berikut adalah senarai alat yang boleh digunakan untuk Ujian Automasi kerangka utama.

  • REXX
  • Excel
  • QTP

Metodologi dalam Ujian Kerangka Utama

Mari kita pertimbangkan satu contoh: Syarikat insurans XYZ mempunyai modul pendaftaran ahli. Ia memerlukan data dari skrin pendaftaran ahli dan pendaftaran luar talian. Seperti yang telah kita bincangkan sebelumnya, diperlukan dua pendekatan untuk pengujian Mainframe, ujian dalam talian, dan pengujian kumpulan.

  • Ujian dalam talian dilakukan di skrin pendaftaran ahli. Sama seperti laman web pangkalan data disahkan dengan data yang dimasukkan melalui layar.
  • Pendaftaran luar talian boleh menjadi pendaftaran kertas atau pendaftaran di laman web pihak ketiga. Data Offline (juga disebut batch) akan dimasukkan ke dalam pangkalan data syarikat melalui pekerjaan batch. Fail rata input disiapkan mengikut format data yang ditentukan dan dimasukkan ke urutan kerja kumpulan. Jadi untuk ujian aplikasi mainframe kita boleh menggunakan pendekatan berikut.
    • Pekerjaan pertama dalam barisan pekerjaan kumpulan mengesahkan data yang dimasukkan. Katakan misalnya watak khas, huruf dalam bidang nombor sahaja, dll.
    • Pekerjaan kedua mengesahkan ketekalan data berdasarkan keadaan perniagaan. Sebagai contoh, pendaftaran kanak-kanak tidak boleh mengandungi data bergantung, poskod anggota (yang tidak tersedia untuk perkhidmatan oleh rancangan yang didaftarkan), dll.
    • Pekerjaan ketiga mengubah data dalam format yang dapat dimasukkan ke dalam pangkalan data. Contohnya, menghapus nama rancangan (pangkalan data hanya akan menyimpan ID pelan, dan nama pelan insurans), tarikh kemasukan tambahan, dll.
    • Pekerjaan keempat memuat data ke dalam pangkalan data.
  • Ujian kerja kumpulan dilakukan pada proses ini dalam dua fasa -
    • Setiap pekerjaan disahkan secara berasingan, dan
    • Integrasi antara pekerjaan disahkan dengan memberikan fail rata input ke pekerjaan pertama dan mengesahkan pangkalan data. (Hasil perantara harus disahkan untuk berhati-hati)

Berikut adalah kaedah yang diikuti untuk ujian Mainframe:

Langkah 1) : Ujian Shakedown / Asap

Fokus utama dalam tahap ini adalah untuk mengesahkan sama ada kod yang digunakan berada dalam persekitaran ujian yang betul. Ini juga memastikan bahawa tidak ada masalah penting dengan kod tersebut.

Langkah 2) : Ujian Sistem

Berikut adalah jenis ujian yang dilakukan sebagai sebahagian daripada Pengujian Sistem.

  1. Pengujian Batch - Pengujian ini akan dilakukan dengan mengesahkan hasil ujian pada fail output dan perubahan data yang dilakukan oleh pekerjaan batch di bawah skop pengujian dan rakamannya.
  2. Ujian Dalam Talian - Ujian ini akan dilakukan di bahagian depan aplikasi mainframe. Di sini aplikasi diuji untuk bidang kemasukan yang betul seperti rancangan insurans, minat pada rancangan, dll.
  3. Ujian Integrasi Batch Dalam Talian - Pengujian ini akan dilakukan pada sistem yang mempunyai proses kumpulan dan aplikasi dalam talian. Aliran data dan interaksi antara skrin dalam talian dan pekerjaan kumpulan disahkan.

    ( Contoh untuk jenis pengujian ini - Pertimbangkan kemas kini pada perincian Pelan seperti kenaikan kadar faedah. Perubahan minat dilakukan pada skrin kemas kini, dan perincian baki pada akaun yang terkena dampak hanya akan diubah oleh pekerjaan kelompok setiap malam. dalam kes ini akan dilakukan dengan mengesahkan skrin perincian Pelan dan tugas kumpulan dijalankan untuk mengemas kini semua akaun)

  4. Pengujian Pangkalan Data - Pangkalan data di mana data dari aplikasi kerangka utama (IMS, IDMS, DB2, VSAM / ISAM, set data Berurutan, GDG) disahkan untuk susun atur dan penyimpanan data mereka.

Langkah 3) : Ujian Integrasi Sistem

Tujuan utama pengujian ini adalah untuk mengesahkan fungsi sistem yang berinteraksi dengan sistem yang diuji.

Sistem ini tidak terjejas secara langsung oleh keperluan. Namun, mereka menggunakan data dari sistem yang diuji. Penting untuk menguji antara muka dan pelbagai jenis mesej (seperti Pekerjaan Berjaya, Gagal Pekerjaan, Pangkalan data dikemas kini, dll.) Yang mungkin berlaku antara sistem dan tindakan yang dihasilkan oleh sistem individu.

Jenis ujian yang dilakukan pada peringkat ini adalah

  1. Ujian Batch
  2. Ujian Dalam Talian
  3. Dalam Talian - Ujian Integrasi Batch

Langkah 4) : Ujian Regresi

Regression Testing adalah fasa biasa dalam semua jenis projek pengujian. Ujian ini dalam Mainframes memastikan bahawa pekerjaan kumpulan dan skrin dalam talian yang tidak berinteraksi secara langsung dengan sistem yang diuji (atau tidak termasuk dalam skop keperluan) tidak dipengaruhi oleh pengeluaran projek semasa.

Untuk menjalani ujian regresi yang berkesan, satu set kes ujian harus disenarai pendek bergantung pada kerumitannya dan tempat regresi (Test case repository) harus dibuat. Set ini harus dikemas kini setiap kali terdapat fungsi baru yang dilancarkan ke dalam rilis.

Langkah 5) : Ujian Prestasi

Ujian ini dilakukan untuk mengenalpasti kemacetan di kawasan yang dilanda tinggi seperti data muka depan, menaik taraf pangkalan data dalam talian dan untuk memproyeksikan skalabilitas aplikasi.

Langkah 6) : Ujian Keselamatan

Pengujian ini dilakukan untuk menilai seberapa baik aplikasi ini dirancang dan dikembangkan untuk melawan serangan anti-keselamatan.

Pengujian keselamatan dua kali ganda harus dilakukan pada sistem - Keselamatan kerangka utama dan keselamatan Rangkaian.

Ciri-ciri yang perlu diuji adalah

  1. Kesepaduan
  2. Kerahsiaan
  3. Kebenaran
  4. Pengesahan
  5. Ketersediaan

Langkah-langkah yang terlibat dalam ujian Batch

  1. Setelah pasukan QA menerima pakej yang disetujui (Pakej mengandungi prosedur, JCL, Kad Kawalan, Modul, dll.), Penguji harus melihat pratonton dan mengambil kandungannya ke dalam PDS seperti yang diperlukan.
  2. Tukarkan JCL pengeluaran atau JCL Pembangunan menjadi QA JCL atau dipanggil JOB SETUP.
  3. Menyalin fail pengeluaran dan menyediakan fail ujian.
  4. Untuk setiap fungsi, akan ada urutan kerja yang ditentukan. (Seperti yang dijelaskan dalam contoh Metodologi di bagian Mainframe). Pekerjaan harus diserahkan menggunakan perintah SUB dengan file data ujian.
  5. Periksa fail perantaraan untuk mengenal pasti sebab-sebab kehilangan atau kesalahan data.
  6. Periksa fail output akhir, pangkalan data dan Spool untuk mengesahkan hasil ujian.
  7. Sekiranya pekerjaan gagal, tunjang akan mempunyai sebab untuk kegagalan pekerjaan. Atasi ralat dan hantar semula tugas.

Pelaporan Ujian - Kecacatan harus dicatat sekiranya hasil sebenar menyimpang dari jangkaan.

Langkah-langkah yang terlibat dalam Ujian Dalam Talian

  1. Pilih skrin dalam talian dalam persekitaran ujian.
  2. Uji setiap medan untuk data yang boleh diterima.
  3. Uji Skenario Uji di skrin.
  4. Sahkan pangkalan data untuk kemas kini data dari skrin dalam talian.

Pelaporan Ujian - Kecacatan harus dicatat sekiranya hasil sebenar menyimpang dari jangkaan.

Langkah-langkah yang terlibat dalam ujian Dalam Talian - Integrasi Batch

  1. Jalankan tugas dalam Persekitaran Uji dan sahkan data di skrin dalam talian.
  2. Kemas kini data di skrin dalam talian dan sahkan jika tugas kumpulan dijalankan dengan betul dengan data yang dikemas kini.

Perintah yang digunakan dalam Mainframe Testing

  1. HANTAR - Hantar kerja latar belakang.
  2. BATAL - Batalkan kerja latar belakang.
  3. PERUNTUKAN - Peruntukkan set data
  4. SALINAN - Salin set data
  5. RENAME - Namakan semula set data
  6. HAPUS - Padam Set Data
  7. JOB SCAN -Untuk mengikat JCL dengan program, perpustakaan, fail, dll tanpa melaksanakannya.

Terdapat banyak perintah lain yang digunakan apabila diperlukan, tetapi tidak begitu kerap.

Prasyarat untuk memulakan ujian mainframe

Perincian asas yang diperlukan untuk ujian mainframe adalah:

  • ID masuk dan kata laluan untuk log masuk ke aplikasi.
  • Pengetahuan ringkas mengenai arahan ISPF.
  • Nama fail, kelayakan fail dan jenisnya.

Sebelum memulakan ujian kerangka utama, aspek di bawah harus disahkan.

  1. Pekerjaan
    1. Lakukan imbasan kerja (Command - JOBSCAN) untuk memeriksa kesilapan sebelum melaksanakannya.
    2. Parameter KELAS harus ditunjukkan ke kelas ujian.
    3. Arahkan output tugas ke dalam gulungan atau JHS atau seperti yang diperlukan dengan menggunakan parameter MSGCLASS.
    4. Ubah hala e-mel dalam tugas untuk menggulung atau ID surat ujian.
    5. Komen langkah FTP untuk ujian awal dan kemudian arahkan tugas ke pelayan ujian.
    6. Sekiranya IMR (rekod Pengurusan Insiden) dihasilkan dalam pekerjaan, cukup tambahkan komen "TUJUAN MENGUJI" dalam pekerjaan atau kad param.
    7. Semua perpustakaan produksi dalam pekerjaan harus diubah dan ditunjuk ke perpustakaan ujian.
    8. Pekerjaan tidak boleh dibiarkan tanpa pengawasan.
    9. Untuk mengelakkan tugas berjalan dalam gelung tak terhingga sekiranya berlaku sebarang kesalahan, parameter TIME harus ditambah dengan waktu yang ditentukan.
    10. Simpan output tugas termasuk kili. Gulungan boleh disimpan dengan menggunakan XDC.
  1. Fail
    1. Buat fail ujian dengan ukuran yang diperlukan sahaja. Gunakan GDG (Kumpulan Data Generasi - Fail dengan nama yang sama tetapi dengan nombor versi berurutan- MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 dan sebagainya) apabila perlu untuk menyimpan data ke dalam fail berturut-turut dengan nama yang sama.
    2. DISP (Disposition - menerangkan sistem untuk menjalankan menyimpan atau menghapus set data setelah penutupan langkah atau pekerjaan yang normal atau tidak normal) untuk fail harus dikodkan dengan betul.
    3. Pastikan semua fail yang digunakan untuk pelaksanaan tugas disimpan dan ditutup dengan betul untuk mengelakkan tugas masuk ke HOLD.
    4. Semasa menguji menggunakan GDG, pastikan versi yang tepat ditunjukkan.
  2. Pangkalan data
    1. Semasa menjalankan tugas atau program dalam talian, pastikan data yang tidak diinginkan tidak dimasukkan atau dikemas kini atau dihapus.
    2. Juga, pastikan kawasan DB2 yang betul digunakan untuk ujian.
  3. Kes ujian
    1. Sentiasa menguji keadaan sempadan seperti - Fail kosong, Pemprosesan rekod pertama, Pemprosesan rekod terakhir, dll.
    2. Selalu masukkan syarat ujian positif dan negatif.
    3. Sekiranya prosedur standard digunakan dalam program seperti Check point restart, Abend Modules, Control files, dll termasuk kes ujian untuk mengesahkan jika modul telah digunakan dengan betul.
  4. Data Ujian
    1. Penyediaan data ujian harus dilakukan sebelum permulaan ujian.
    2. Jangan sekali-kali mengubah data di kawasan ujian tanpa memberitahu. Mungkin ada pasukan lain yang bekerja dengan data yang sama, dan ujian mereka akan gagal.
    3. Sekiranya fail produksi diperlukan selama pelaksanaan, otorisasi yang tepat harus diperoleh sebelum menyalin atau menggunakannya.

Amalan terbaik

  1. Sekiranya menjalankan Batch Job, MAX CC 0 adalah petunjuk bahawa pekerjaan tersebut berjaya dijalankan. Ini tidak bermaksud bahawa fungsi berfungsi dengan baik. Tugas akan berjaya dijalankan walaupun outputnya kosong atau tidak mengikut jangkaan. Oleh itu, selalu diharapkan untuk memeriksa semua output sebelum menyatakan pekerjaan itu berjaya.
  2. Menjadi kebiasaan yang baik untuk melakukan pekerjaan yang sedang dalam ujian. Larian kering dilakukan dengan fail input kosong. Proses ini harus diikuti untuk pekerjaan yang dipengaruhi oleh perubahan yang dibuat untuk kitaran ujian.
  3. Sebelum kitaran ujian dimulakan, persediaan kerja ujian harus dilakukan dengan lebih awal. Ini akan membantu dalam mengetahui sebarang kesalahan JCL terlebih dahulu sehingga menjimatkan masa semasa pelaksanaan.
  4. Semasa mengakses jadual DB2 melalui SPUFI (Pilihan pada emulator untuk mengakses jadual DB2), selalu tetapkan komitmen automatik sebagai "TIDAK" untuk mengelakkan kemas kini secara tidak sengaja.
  5. Ketersediaan Data Ujian adalah cabaran utama dalam pengujian kumpulan. Data yang diperlukan harus dibuat lebih awal dari kitaran ujian dan harus diperiksa untuk kelengkapannya.
  6. Beberapa urus niaga dalam talian dan pekerjaan kumpulan dapat menulis data ke dalam MQ (Message Queue) untuk menghantar data ke aplikasi lain. Sekiranya data tidak sah, mungkin mematikan / menghentikan MQ, ini akan mempengaruhi keseluruhan proses pengujian. Merupakan amalan yang baik untuk memeriksa bahawa MQ berfungsi dengan baik selepas ujian.

Mainframe menguji Cabaran dan Penyelesaian Masalah

Cabaran Pendekatan
Keperluan Tidak Lengkap / Tidak Jelas Mungkin ada akses ke panduan pengguna / panduan latihan, tetapi itu tidak sama dengan keperluan yang didokumentasikan. Penguji harus terlibat dalam SDLC dari tahap keperluan dan seterusnya. Ini akan membantu untuk mengesahkan sama ada syarat tersebut dapat diuji.
Pengaturan / Pengenalan Data Mungkin ada situasi di mana data yang ada harus digunakan kembali sesuai dengan kebutuhan. Kadang-kadang sukar untuk mengenal pasti data yang diperlukan dari data yang ada. Untuk penyediaan data, alat homegrown dapat digunakan sesuai kebutuhan. Untuk mengambil data yang ada, pertanyaan harus dibuat terlebih dahulu. Sekiranya ada kesulitan, permintaan dapat diajukan kepada tim manajemen data untuk membuat atau mengklon data yang diperlukan.
Penyediaan Pekerjaan Setelah pekerjaan diambil ke PDS, pekerjaan tersebut perlu disiapkan di wilayah QA. Sehingga pekerjaan tidak diserahkan dengan kelayakan produksi atau perincian jalan. Alat persediaan pekerjaan harus digunakan untuk mengatasi kesalahan manusia yang dibuat semasa penyediaan.
Permintaan Ad-hoc Mungkin terdapat situasi ketika ujian akhir ke akhir perlu disokong kerana masalah dalam masalah aplikasi hulu atau hilir. Permintaan ini meningkatkan masa dan usaha dalam siklus pelaksanaan. Penggunaan skrip automasi, skrip regresi, dan skrip kerangka dapat membantu dalam mengurangi waktu dan biaya usaha.
Siaran Tepat Waktu untuk perubahan ruang lingkup Mungkin ada situasi di mana kesan kod dapat mengubah sepenuhnya tampilan dan nuansa sistem. Ini mungkin memerlukan perubahan untuk menguji kes, skrip, dan data. Proses pengurusan perubahan skop dan analisis Impak harus dilakukan.

Kebiasaan yang dihadapi

  1. S001 - Ralat I / O berlaku.

    Sebab - Membaca di akhir fail, ralat panjang fail, percubaan untuk menulis ke dalam fail hanya baca.

  2. S002 - Rekod I / O tidak sah.

    Sebab - Percubaan untuk menulis catatan lebih lama daripada panjang rekod.

  3. S004 - Ralat berlaku semasa DIBUKA.

    Sebab - DCB tidak sah

  4. S013 - Ralat semasa membuka set data.

    Sebab - Anggota PDS tidak ada, panjang rekod dalam program tidak sepadan dengan panjang rekod sebenar.

  5. S0C1 - Pengecualian Operasi

    Sebab -Tidak dapat membuka fail, kad DD hilang

  6. S0C4 - Pengecualian perlindungan / Pelanggaran penyimpanan
  7. Sebab - Mencuba penyimpanan akses tidak tersedia untuk program ini.
  8. SC07 - Pengecualian Pemeriksaan Program - Data
  9. Sebab - Perubahan susun atur rekod atau susun atur fail.
  10. Sx22 - Pekerjaan telah dibatalkan
  11. S222 - Pekerjaan dibatalkan oleh pengguna tanpa lambakan.
  12. S322 - Waktu kerja atau Langkah melampaui had yang ditentukan, atau program berada dalam gelung atau parameter waktu yang tidak mencukupi.
  13. S522 - Waktu tamat sesi TSO.
  14. S806 -Tidak dapat memaut atau memuatkan.

    Sebab - Id pekerjaan tidak dapat mencari modul beban yang ditentukan.

  15. S80A - Storan maya tidak mencukupi untuk memenuhi permintaan GETMAIN atau FREEMAIN.
  16. S913 - Mencuba mengakses set data yang tidak dibenarkan oleh pengguna.
  17. Sx37 - Tidak dapat memperuntukkan storan yang mencukupi ke set data.

Error Assist - Alat yang sangat popular untuk mendapatkan maklumat terperinci mengenai pelbagai jenis abends.

Masalah biasa yang dihadapi semasa ujian mainframe

  • Job Abends - Untuk berjaya menyelesaikan pekerjaan, anda harus memeriksa data, fail input dan modul yang ada di lokasi tertentu atau tidak. Abends boleh dihadapi kerana pelbagai sebab, yang paling umum - Data tidak sah, medan input yang salah, ketidakcocokan tarikh, masalah persekitaran, dll.
  • Fail keluaran kosong- Walaupun tugas mungkin berjaya dijalankan (MaxCC 0), output mungkin tidak seperti yang diharapkan. Oleh itu, sebelum melewati sebarang kes ujian, penguji harus memastikan bahawa hasilnya disahkan silang. Barulah terus berjalan lebih jauh.
  • Fail input kosong - Dalam beberapa aplikasi, fail akan diterima dari proses hulu. Sebelum menggunakan file yang diterima untuk menguji aplikasi saat ini, data harus disahkan silang untuk menghindari pelaksanaan dan pengerjaan ulang.

Ringkasan:

  • Pengujian kerangka utama adalah seperti prosedur pengujian lain mulai dari Pengumpulan Keperluan, reka bentuk ujian, pelaksanaan ujian dan pelaporan hasil.
  • Untuk menguji aplikasi dengan berkesan, penguji harus mengambil bahagian dalam mesyuarat reka bentuk yang dijadualkan oleh pasukan pembangunan dan perniagaan.
  • Wajib bagi penguji untuk membiasakan diri dengan pelbagai fungsi ujian kerangka utama. Seperti navigasi skrin, pembuatan fail dan PDS, menyimpan hasil ujian, dan lain-lain sebelum kitaran ujian bermula.
  • Pengujian aplikasi kerangka utama adalah proses yang memakan masa. Jadual ujian yang jelas harus diikuti untuk reka bentuk ujian, penyediaan dan pelaksanaan data.
  • Ujian kumpulan dan Pengujian dalam talian harus dilakukan dengan berkesan tanpa kehilangan fungsi yang disebutkan dalam dokumen Keperluan, dan tidak ada Kes Uji yang harus dihindarkan.