Pengujian Mainframe – Tutorial Lengkap

Sebelum mempelajari konsep Pengujian Mainframe, mari kita lihat terlebih dahulu platform tempat pengujian dijalankan.

Apa itu Mainframe?

Komputer mainframe adalah sistem komputer berkinerja tinggi dan berkecepatan tinggi. Sistem ini digunakan untuk komputasi skala besar yang membutuhkan ketersediaan tinggi dan keamanan yang kuat. Mainframe banyak digunakan di sektor-sektor seperti keuangan, asuransi, ritel, dan bidang-bidang penting lainnya di mana volume data yang sangat besar diproses berkali-kali dalam sehari.

Pengujian Rangka Utama

Pengujian Rangka Utama Pengujian Mainframe adalah proses pengujian aplikasi dan layanan perangkat lunak berbasis Sistem Mainframe. Tujuan Pengujian Mainframe adalah untuk memastikan kinerja, keandalan, dan kualitas aplikasi atau layanan perangkat lunak melalui metode verifikasi dan validasi, serta untuk memeriksa apakah aplikasi atau layanan tersebut siap untuk digunakan.

Saat melakukan pengujian Mainframe, penguji terutama perlu mengetahui navigasi layar CICS. Layar-layar ini dibuat khusus untuk aplikasi tertentu. Ketika perubahan dilakukan pada kode dalam COBOL, JCL, dan bahasa serupa, penguji tidak perlu khawatir tentang emulator yang terpasang pada mesin, karena perubahan yang berfungsi pada satu emulator terminal akan berfungsi pada emulator lainnya.

• Aplikasi Mainframe (atau disebut juga batch pekerjaan) diuji terhadap kasus uji yang dikembangkan berdasarkan persyaratan.
• Pengujian Mainframe biasanya dilakukan pada kode yang diterapkan menggunakan berbagai kombinasi data yang ditetapkan dalam berkas input.
• Aplikasi yang berjalan di mainframe dapat diakses melalui emulator terminal. Emulator adalah satu-satunya perangkat lunak yang perlu diinstal pada mesin klien.

Karena platform ini berperilaku berbeda dari web stack, penting untuk mengetahui karakteristik mainframe mana yang mendorong desain pengujian. Oleh karena itu, Pengujian Mainframe berada di samping yang lainnya. jenis pengujian perangkat lunak daripada mengganti salah satu dari mereka.

Atribut Mainframe

1. Penyimpanan Virtual
   • Ini adalah teknik yang memungkinkan prosesor mensimulasikan penyimpanan utama yang lebih besar dari jumlah penyimpanan sebenarnya.
   • Ini adalah teknik untuk menggunakan memori secara efektif untuk menyimpan dan menjalankan berbagai tugas berukuran.
   • Ia menggunakan penyimpanan disk sebagai perpanjangan dari penyimpanan nyata.
2. multiprogram
   • Komputer menjalankan lebih dari satu program secara bersamaan. Namun, pada setiap saat tertentu, hanya satu program yang dapat mengendalikan CPU.
   • Ini adalah fasilitas yang disediakan untuk mengefisienkan penggunaan CPU.
3. Pemrosesan Batch
   • Ini adalah teknik dimana setiap tugas diselesaikan dalam unit yang dikenal sebagai pekerjaan.
   • Suatu pekerjaan dapat menyebabkan satu atau lebih program dijalankan secara berurutan.
   • Penjadwal Pekerjaan membuat keputusan tentang urutan pekerjaan yang harus dilaksanakan. Untuk memaksimalkan throughput rata-rata, pekerjaan dijadwalkan sesuai prioritas dan kelasnya.
   • Informasi yang diperlukan untuk pemrosesan batch disediakan melalui JCL (JOB CONTROL LANGUAGE). JCL menjelaskan pekerjaan batch — program, data, dan sumber daya yang dibutuhkan.
4. Berbagi waktu
   • Dalam sistem pembagian waktu, setiap pengguna memiliki akses ke sistem melalui perangkat terminal. Alih-alih mengirimkan pekerjaan yang dijadwalkan untuk dieksekusi nanti, pengguna memasukkan perintah yang diproses segera.
   • Oleh karena itu ini disebut “Pemrosesan Interaktif”. Ini memungkinkan pengguna untuk berinteraksi langsung dengan komputer.
   • Pemrosesan pembagian waktu dikenal sebagai “Pemrosesan Latar Depan” dan pemrosesan tugas batch dikenal sebagai “Pemrosesan Latar Belakang”.
5. Menggulung
   • SPOOLing adalah singkatan dari Simultaneous Peripheral (Pengambilan Data Periferal Secara Bersamaan). Operations Online.
   • Perangkat SPOOL digunakan untuk menyimpan output dari suatu program atau aplikasi. Output yang disimpan kemudian diarahkan ke perangkat output seperti printer (jika diperlukan).
   • Ini adalah fasilitas yang memanfaatkan keuntungan buffering untuk memanfaatkan perangkat keluaran secara efisien.

Klasifikasi Pengujian Manual di Mainframe

Atribut-atribut ini membagi pekerjaan pengujian manual pada mainframe menjadi dua aliran yang terpisah dengan jelas.

mainframe Pengujian Manual dapat digolongkan menjadi dua jenis:

1. Pengujian Pekerjaan Batch —

• Proses pengujian melibatkan eksekusi pekerjaan batch untuk fungsionalitas yang diimplementasikan dalam rilis saat ini.
• Hasil tes tersebut menunjukkantracData yang diambil dari file output dan database diverifikasi dan dicatat.

2. Tes Daring —

• Pengujian daring mengacu pada pengujian layar CICS, yang mirip dengan pengujian halaman web.
• Fungsi layar yang ada dapat diubah, atau layar baru dapat ditambahkan.
• Berbagai aplikasi dapat memiliki layar pertanyaan dan layar pembaruan. Fungsionalitas layar ini perlu diperiksa sebagai bagian dari pengujian online.

Cara Melakukan Pengujian Mainframe

1. Tim Bisnis menyiapkan dokumen persyaratan, yang menentukan bagaimana item atau proses tertentu akan dimodifikasi dalam siklus rilis.
2. Tim penguji dan tim pengembang menerima dokumen persyaratan. Mereka menentukan berapa banyak proses yang akan terpengaruh oleh perubahan tersebut. Biasanya, dalam sebuah rilis, hanya 20-25% dari aplikasi yang terpengaruh secara langsung oleh persyaratan yang disesuaikan. Sisanya, 75-80% dari upaya rilis, dialokasikan untuk fungsionalitas bawaan, seperti pengujian aplikasi dan proses di sekitarnya.
3. Jadi, aplikasi Mainframe harus diuji dalam dua bagian:
   • Persyaratan Pengujian — Menguji aplikasi untuk fungsionalitas atau perubahan yang disebutkan dalam dokumen persyaratan.
   • Integrasi Pengujian — Menguji keseluruhan proses atau aplikasi lain yang menerima atau mengirim data ke aplikasi yang terpengaruh. Pengujian Regresi adalah fokus utama dari kegiatan pengujian ini.

Alat Pengujian Otomasi Mainframe

Di bawah ini adalah daftar alat yang dapat digunakan untuk mainframe Pengujian Otomatisasi.

• REXX — bahasa skrip yang disertakan dengan z/OS, banyak digunakan untuk menjalankan pengiriman pekerjaan berulang dan pemeriksaan output.
• Excel — digunakan dengan makro untuk membangun, membandingkan, dan melaporkan data uji dan file keluaran.
• OpenText UFT Satu — nama terkini dari alat yang masih disebut-sebut oleh industri QTP atau QuickTest Professional; perangkat lunak ini mengotomatiskan 3270 layar terminal.
• Galasa — sumber terbuka, Kerangka kerja pengujian integrasi mendalam Open Mainframe Project yang menggerakkan 3270 layar, pekerjaan batch JCL, dan Db2 dari pipeline CI/CD.
• Rangkaian pengujian vendor z/OS - IBM Test Accelerator for Z dan BMC AMI DevX Total Test mencakup pengujian unit COBOL dan lingkungan pengujian virtual.

Apa pun alat yang dipilih, alat tersebut hanya akan memberikan hasil yang menguntungkan jika berada di dalam tempat yang terawat. kerangka kerja otomatisasi pengujian alih-alih tumpukan naskah yang berserakan.

Metodologi dalam Pengujian Mainframe

Mari kita pertimbangkan sebuah contoh: Sebuah perusahaan asuransi XYZ memiliki modul pendaftaran anggota. Modul ini mengambil data baik dari layar pendaftaran anggota maupun dari pendaftaran offline. Seperti yang telah dibahas sebelumnya, terdapat dua pendekatan untuk Pengujian Mainframe, yaitu pengujian online dan pengujian batch.

• Pengujian online dilakukan pada layar pendaftaran anggota. Sama seperti halaman web, basis data divalidasi dengan data yang dimasukkan melalui layar.
• Pendaftaran offline dapat berupa pendaftaran kertas atau pendaftaran melalui situs web pihak ketiga. Data offline (juga disebut sebagai batch) akan dimasukkan ke dalam basis data perusahaan melalui pekerjaan batch. Sebuah file input datar disiapkan sesuai dengan format data yang ditentukan dan dimasukkan ke dalam rangkaian pekerjaan batch. Jadi untuk pengujian aplikasi mainframe, kita dapat menggunakan pendekatan berikut.
  • Tugas pertama dalam rangkaian tugas batch memvalidasi data yang dimasukkan — misalnya karakter khusus, atau huruf alfabet dalam kolom yang hanya berisi angka.
  • Tugas kedua adalah memvalidasi konsistensi data berdasarkan kondisi bisnis. Misalnya, pendaftaran anak tidak boleh berisi data tanggungan, atau kode pos anggota yang tidak tersedia untuk layanan oleh paket yang terdaftar.
  • Tugas ketiga memodifikasi data ke dalam format yang dapat dimasukkan ke dalam basis data. Misalnya, menghapus nama paket (basis data hanya akan menyimpan ID paket dan nama paket asuransi), menambahkan tanggal entri, dan perubahan serupa lainnya.
  • Pekerjaan keempat memuat data ke dalam database.
• Pengujian pekerjaan batch dilakukan pada proses ini dalam dua fase —
  • Setiap pekerjaan divalidasi secara terpisah, dan
  • Integrasi antar pekerjaan divalidasi dengan memberikan file teks input ke pekerjaan pertama dan memvalidasi basis data. (Hasil sementara harus divalidasi untuk kehati-hatian ekstra.)

Berikut adalah metode yang digunakan untuk Pengujian Mainframe:

Langkah 1) Pengujian Awal/Uji Coba Asap

Fokus utama pada tahap ini adalah untuk memvalidasi apakah kode yang diimplementasikan berada di lingkungan pengujian yang tepat. Ini juga memastikan bahwa tidak ada masalah kritis pada kode tersebut. Ini adalah padanan mainframe dari... Pengujian Asap di platform lain mana pun.

Langkah 2) Pengujian Sistem

Di bawah ini adalah jenis pengujian yang dilakukan sebagai bagian dari Pengujian Sistem.

1. Pengujian Batch — Pengujian ini dilakukan dengan memvalidasi hasil pengujian pada file output dan perubahan data yang dilakukan oleh pekerjaan batch yang berada dalam lingkup pengujian, lalu mencatatnya.
2. Pengujian Online — Pengujian ini dilakukan di bagian depan aplikasi mainframe. Di sini, aplikasi diuji untuk memastikan kebenaran kolom input seperti rencana asuransi, bunga atas rencana tersebut, dan nilai-nilai serupa.
3. Pengujian Integrasi Batch Online — Pengujian ini dilakukan pada sistem yang memiliki proses batch dan aplikasi online. Alur data dan interaksi antara layar online dan pekerjaan batch divalidasi.

   (Contoh untuk jenis pengujian ini — Pertimbangkan pembaruan detail rencana seperti kenaikan suku bunga. Perubahan suku bunga dilakukan pada layar pembaruan, dan detail saldo pada akun yang terpengaruh hanya akan dimodifikasi oleh pekerjaan batch malam hari. Pengujian dalam hal ini dilakukan dengan memvalidasi layar detail rencana dan eksekusi pekerjaan batch untuk memperbarui semua akun.)

4. Pengujian Basis Data — Basis data tempat data dari aplikasi mainframe disimpan (IMS, IDMS, Db2, VSAM/ISAM, dataset sekuensial, GDG) divalidasi tata letak dan penyimpanan datanya.

Langkah 3) Sistem Tes integrasi

Tujuan utama pengujian ini adalah untuk memvalidasi fungsionalitas sistem yang berinteraksi dengan sistem yang diuji.

Sistem-sistem ini tidak secara langsung terpengaruh oleh persyaratan. Namun, sistem-sistem ini menggunakan data dari sistem yang sedang diuji. Penting untuk menguji sistem-sistem tersebut. antarmuka serta berbagai jenis pesan (seperti Pekerjaan Berhasil, Pekerjaan Gagal, Basis Data Diperbarui) yang dapat mengalir antar sistem, dan tindakan yang diambil oleh masing-masing sistem sebagai akibatnya.

Jenis pengujian yang dilakukan pada tahap ini adalah

1. Pengujian Batch
2. Pengujian Online
3. Pengujian Integrasi Batch Daring

Langkah 4) Pengujian Regresi

Pengujian regresi adalah fase umum dalam semua jenis proyek pengujian. Pengujian ini pada mainframe memastikan bahwa pekerjaan batch dan layar online yang tidak berinteraksi langsung dengan sistem yang sedang diuji (atau tidak termasuk dalam ruang lingkup persyaratan) tidak terpengaruh oleh rilis proyek saat ini.

Untuk melakukan pengujian regresi yang efektif, serangkaian kasus uji tertentu harus dipilih berdasarkan kompleksitasnya dan sebuah basis data regresi (repositori kasus uji) harus dibuat. Kumpulan ini harus diperbarui setiap kali fungsionalitas baru diluncurkan ke dalam rilis. Jika basis data regresi terlalu besar untuk dijalankan secara keseluruhan, Pengujian Berbasis Risiko Digunakan untuk menentukan pekerjaan dan tampilan mana yang akan dijalankan ulang terlebih dahulu.

Langkah 5) Pengujian Kinerja

Pengujian ini dilakukan untuk mengidentifikasi hambatan di area dengan beban kerja tinggi seperti entri data front-end dan pembaruan basis data online, serta untuk memproyeksikan skalabilitas aplikasi. Jendela batch yang berjalan lama biasanya diperiksa dengan Pengujian Tegangan terhadap volume puncak.

Langkah 6) Pengujian Keamanan

Pengujian ini dilakukan untuk mengevaluasi seberapa baik aplikasi dirancang dan dikembangkan untuk melawan serangan anti-keamanan.

Pengujian keamanan ganda harus dilakukan pada sistem — keamanan mainframe dan keamanan jaringan.

Fitur-fitur yang perlu diuji adalah:

1. Integrity
2. Kerahasiaan
3. Authorization
4. Otentikasi
5. Ketersediaan

Langkah-langkah yang Terlibat dalam Pengujian Batch

1. Setelah tim QA menerima paket yang disetujui (paket tersebut berisi prosedur, JCL, kartu kontrol, modul, dan item serupa), penguji harus meninjau dan mengambil konten ke dalam PDS sesuai kebutuhan.
2. Konversikan JCL produksi atau JCL pengembangan menjadi JCL QA, atau disebut juga JOB SETUP.
3. Salin file produksi dan siapkan file pengujian.
4. Untuk setiap fungsionalitas, akan ada urutan pekerjaan yang ditentukan (seperti yang dijelaskan dalam contoh di bagian Metodologi dalam Pengujian Mainframe). Pekerjaan tersebut harus dikirimkan menggunakan perintah SUB dengan file data pengujian.
5. Periksa file perantara untuk mengidentifikasi penyebab data yang hilang atau mengalami kesalahan.
6. Periksa file output akhir, basis data, dan Spool untuk memvalidasi hasil pengujian.
7. Jika pekerjaan gagal, spool akan mempunyai alasan kegagalan pekerjaan tersebut. Atasi kesalahan tersebut dan kirimkan kembali pekerjaan tersebut.

Pelaporan Uji - SEBUAH cacat Harus dicatat jika hasil aktual menyimpang dari hasil yang diharapkan.

Langkah-langkah yang Terlibat dalam Pengujian Online

1. Pilih layar Online di Lingkungan Uji.
2. Uji setiap bidang untuk data yang dapat diterima.
3. Uji Skenario Uji di layar.
4. Verifikasi database untuk pembaruan data dari layar online.

Pelaporan Uji — Cacat harus dicatat jika hasil aktual menyimpang dari hasil yang diharapkan.

Langkah-langkah yang Terlibat dalam Pengujian Integrasi Batch Online

1. Jalankan tugas di Lingkungan Pengujian dan validasi data pada layar daring.
2. Perbarui data pada layar online dan validasi apakah tugas batch berjalan dengan benar dengan data yang telah diperbarui.

Perintah yang Digunakan dalam Pengujian Mainframe

Langkah-langkah ini dijalankan dari terminal, sehingga kosakata perintah yang sederhana dapat mencakup sebagian besar pekerjaan penguji sepanjang hari.

1. SUBMIT — Kirimkan permintaan pemeriksaan latar belakang.
2. MEMBATALKAN — Batalkan pekerjaan latar belakang.
3. ALOKASIKAN — Alokasikan dataset.
4. COPY — Salin sebuah dataset.
5. RENAME — Mengganti nama dataset.
6. DELETE — Menghapus dataset.
7. PEMINDAIAN PEKERJAAN — Mengikat JCL dengan program, pustaka, file, dan sumber daya lainnya tanpa mengeksekusinya.

Ada banyak perintah lain yang digunakan bila diperlukan, namun tidak sesering itu.

Prasyarat untuk Memulai Pengujian Mainframe

Detail dasar yang dibutuhkan untuk Pengujian Mainframe adalah:

• Login ID dan password untuk login ke aplikasi.
• Pengetahuan singkat tentang perintah ISPF.
• Nama file, kualifikasi file, dan tipenya.

Sebelum memulai Pengujian Mainframe, aspek-aspek berikut harus diverifikasi.

1. Pekerjaan
   • Lakukan pemindaian pekerjaan (perintah — JOBSCAN) untuk memeriksa kesalahan sebelum menjalankannya.
   • Parameter CLASS harus diarahkan ke kelas pengujian.
   • Arahkan output pekerjaan ke spool atau JHS, atau sesuai kebutuhan, dengan menggunakan parameter MSGCLASS.
   • Alihkan email dalam tugas tersebut ke antrean atau ke alamat email uji.
   • Nonaktifkan langkah-langkah FTP dengan menambahkan komentar untuk pengujian awal, lalu arahkan pekerjaan tersebut ke server pengujian.
   • Jika IMR (Incident Management Record) dihasilkan dalam pekerjaan, tambahkan komentar “TUJUAN PENGUJIAN” di pekerjaan atau kartu parameter.
   • Semua perpustakaan produksi dalam pekerjaan harus diubah dan diarahkan ke perpustakaan pengujian.
   • Pekerjaan itu tidak boleh dibiarkan begitu saja.
   • Untuk mencegah pekerjaan berjalan dalam perulangan tak terbatas jika terjadi kesalahan, parameter TIME harus ditambahkan dengan waktu yang ditentukan.
   • Simpan keluaran pekerjaan termasuk spool. Spool dapat disimpan menggunakan XDC.
2. File
   • Buat file uji hanya dengan ukuran yang dibutuhkan. Gunakan GDG (Generation Data Groups — file dengan nama yang sama tetapi dengan nomor versi berurutan, seperti MYLIB.LIB.TEST.G0001V00 dan MYLIB.LIB.TEST.G0002V00) bila perlu untuk menyimpan data ke dalam file berurutan dengan nama yang sama.
   • Parameter DISP (Disposition — memberi tahu sistem apakah akan menyimpan atau menghapus dataset setelah penghentian langkah atau pekerjaan secara normal atau abnormal) untuk file harus dikodekan dengan benar.
   • Pastikan semua file yang digunakan untuk eksekusi pekerjaan disimpan dan ditutup dengan benar untuk mencegah pekerjaan masuk ke status TERTUNDA (HOLD).
   • Saat melakukan pengujian menggunakan GDG, pastikan versi yang ditunjuk sudah benar.
3. Basis Data
   • Saat menjalankan pekerjaan atau program online, pastikan data yang tidak diinginkan tidak dimasukkan, diperbarui, atau dihapus.
   • Selain itu, pastikan wilayah Db2 yang benar digunakan untuk pengujian.
4. Uji kasus
   • Selalu uji kondisi batas seperti file kosong, pemrosesan rekaman pertama, dan pemrosesan rekaman terakhir.
   • Selalu sertakan kondisi pengujian positif dan negatif.
   • Jika prosedur standar digunakan dalam program, seperti restart checkpoint, modul abend, atau file kontrol, sertakan Uji Kasusuntuk memvalidasi apakah modul telah digunakan dengan benar.
5. Data Uji
   • Penyiapan data pengujian harus dilakukan sebelum pengujian dimulai.
   • Jangan pernah memodifikasi data di wilayah pengujian tanpa memberi tahu pihak lain. Mungkin ada tim lain yang mengerjakan data yang sama, dan pengujian mereka akan gagal.
   • Jika file produksi diperlukan selama eksekusi, otorisasi yang tepat harus diperoleh sebelum menyalin atau menggunakannya.

Praktik Terbaik

1. Dalam kasus eksekusi pekerjaan batch, MAX CC 0 merupakan indikator bahwa pekerjaan telah berjalan dengan sukses. Ini tidak berarti bahwa fungsionalitasnya berfungsi dengan baik. Pekerjaan akan berjalan sukses bahkan ketika output kosong atau tidak sesuai harapan. Oleh karena itu, selalu diharapkan untuk memeriksa semua output sebelum menyatakan pekerjaan berhasil.
2. Selalu merupakan praktik yang baik untuk melakukan uji coba (dry run) pada pekerjaan yang sedang diuji. Uji coba dilakukan dengan file input kosong. Proses ini harus diikuti untuk pekerjaan yang terpengaruh oleh perubahan yang dilakukan untuk siklus pengujian.
3. Sebelum siklus pengujian dimulai, pengaturan pekerjaan pengujian harus dilakukan jauh-jauh hari. Hal ini membantu menemukan kesalahan JCL terlebih dahulu, sehingga menghemat waktu selama eksekusi.
4. Saat mengakses tabel Db2 melalui SPUFI (opsi pada emulator untuk mengakses tabel Db2), selalu atur auto commit ke “NO” untuk menghindari pembaruan yang tidak disengaja.
5. Ketersediaan data uji merupakan tantangan utama dalam pengujian batch. Data yang dibutuhkan harus dibuat jauh sebelum siklus pengujian dan harus diperiksa kelengkapannya. Tracking persiapan bersama manajemen tes Repositori ini menjaga agar kerangka regresi dan pengaturan data tetap selaras.
6. Beberapa transaksi online dan pekerjaan batch mungkin menulis data ke dalam MQ (Antrian Pesan) untuk transmitMengirim data ke aplikasi lain. Jika data tidak valid, hal itu dapat menonaktifkan atau menghentikan MQ, dan ini akan memengaruhi seluruh proses pengujian. Sebaiknya periksa apakah MQ berfungsi dengan baik setelah pengujian.

Tantangan dan Pemecahan Masalah Pengujian Mainframe

Meskipun praktik-praktik tersebut telah diterapkan, beberapa masalah tetap muncul hampir di setiap rilis mainframe. Tabel di bawah ini memasangkan setiap masalah dengan pendekatan yang dapat menyelesaikannya.

Tantangan	Pendekatan
Persyaratan Tidak Lengkap/Tidak Jelas	Mungkin ada akses ke manual pengguna atau panduan pelatihan, tetapi itu tidak sama dengan persyaratan yang terdokumentasi. Penguji harus dilibatkan dalam proses tersebut. siklus hidup pengujian perangkat lunak Mulai dari fase persyaratan. Ini membantu memverifikasi apakah persyaratan tersebut dapat diuji.
Pengaturan/Identifikasi Data	Mungkin ada situasi di mana data yang sudah ada perlu digunakan kembali sesuai kebutuhan. Terkadang sulit untuk mengidentifikasi data yang dibutuhkan dari data yang sudah ada. Untuk pengaturan data, alat buatan sendiri dapat digunakan sesuai kebutuhan. Untuk mengambil data yang sudah ada, kueri harus dibuat terlebih dahulu. Jika mengalami kesulitan, permintaan dapat diajukan kepada tim manajemen data untuk membuat atau mengkloning data yang dibutuhkan.
Pengaturan Pekerjaan	Setelah pekerjaan diambil ke PDS, pekerjaan tersebut perlu diatur di wilayah QA, sehingga pekerjaan tersebut tidak dikirimkan dengan kualifikasi produksi atau detail jalur. Alat pengaturan pekerjaan harus digunakan untuk mengatasi kesalahan manusia yang terjadi selama pengaturan.
Permintaan Ad-hoc	Mungkin ada situasi di mana pengujian ujung ke ujung Permintaan dukungan diperlukan karena adanya masalah pada aplikasi hulu atau hilir. Permintaan ini meningkatkan waktu dan upaya dalam siklus eksekusi. Penggunaan skrip otomatisasi, skrip regresi, dan skrip kerangka dapat membantu mengurangi waktu dan upaya yang dibutuhkan.
Rilis Tepat Waktu untuk perubahan cakupan	Mungkin ada situasi di mana dampak perubahan kode sepenuhnya mengubah tampilan dan nuansa sistem. Hal ini mungkin memerlukan perubahan pada kasus uji, skrip, dan data. Proses manajemen perubahan ruang lingkup dan analisis dampak harus diterapkan.

Abends Umum yang Ditemui

Ketika suatu pekerjaan gagal, spool akan melaporkan kode abend. Daftar di bawah ini mencakup kode-kode yang paling sering ditemui oleh penguji mainframe, beserta penyebab umumnya.

1. S001 — Terjadi kesalahan I/O.

   Alasan — Membaca di akhir file, kesalahan panjang file, atau upaya untuk menulis ke file yang hanya dapat dibaca.

2. S002 — Rekaman I/O tidak valid.

   Alasan — Upaya untuk menulis rekaman yang lebih panjang dari durasi rekaman yang ditentukan.

3. S004 — Terjadi kesalahan saat membuka.

   Alasan — DCB tidak valid.

4. S013 — Terjadi kesalahan saat membuka dataset.

   Alasan — Anggota PDS tidak ada, atau panjang data dalam program tidak sesuai dengan panjang data sebenarnya.

5. S0C1 - OperaPengecualian.

   Alasan — Tidak dapat membuka file, atau kartu DD hilang.

6. S0C4 — Pengecualian perlindungan / pelanggaran penyimpanan.

   Alasan — Mencoba mengakses penyimpanan yang tidak tersedia untuk program.

7. S0C7 — Pengecualian pemeriksaan program, data.

   Alasan — Perubahan tata letak rekaman atau tata letak file.

8. Sx22 — Pekerjaan telah dibatalkan.

   Alasan — Pekerjaan dihentikan sebelum selesai; angka tengah mengidentifikasi siapa atau apa yang membatalkannya.

9. S222 — Pekerjaan dibatalkan oleh pengguna tanpa menyertakan data hasil.
10. S322 — Waktu eksekusi atau langkah melebihi batas yang ditentukan, atau program berada dalam perulangan, atau parameter TIME tidak mencukupi.
11. S522 — Waktu sesi TSO habis.
12. S806 — Tidak dapat menautkan atau memuat.

    Alasan — Pekerjaan tersebut tidak dapat menemukan modul pemuatan yang ditentukan.

13. S80A — Tidak cukup ruang penyimpanan virtual untuk memenuhi permintaan GETMAIN atau FREEMAIN.
14. S913 — Mencoba mengakses kumpulan data yang tidak diizinkan untuk digunakan oleh pengguna.
15. Sx37 — Tidak dapat mengalokasikan cukup ruang penyimpanan untuk dataset.

Bantuan Kesalahan — Alat yang sangat populer untuk mendapatkan informasi detail tentang berbagai jenis abend.

Masalah Umum yang Dihadapi Selama Pengujian Mainframe

• Pekerjaan Abends — Untuk keberhasilan penyelesaian pekerjaan, Anda harus memeriksa data, file input, dan apakah modul-modul tersebut ada di lokasi tertentu. Abend dapat terjadi karena berbagai alasan, yang paling umum adalah data tidak valid, kolom input yang salah, ketidaksesuaian tanggal, atau masalah lingkungan.
• File keluaran kosong — Meskipun pekerjaan mungkin berjalan dengan sukses (MaxCC 0), hasilnya mungkin tidak sesuai harapan. Jadi, sebelum menjalankan kasus uji apa pun, penguji harus memastikan bahwa hasilnya telah diverifikasi silang. Barulah setelah itu pengujian dapat dilanjutkan.
• File masukan kosong — Dalam beberapa aplikasi, file diterima dari proses hulu. Sebelum menggunakan file yang diterima untuk menguji aplikasi saat ini, data harus diverifikasi silang untuk menghindari eksekusi ulang dan pengerjaan ulang.

Pertanyaan Umum Demo Slot