Pengujian Mainframe – Tutorial Lengkap

Sebelum mempelajari konsep pengujian mainframe, mari belajar

Apa itu Mainframe?

Mainframe adalah sistem komputer berkinerja tinggi dan berkecepatan tinggi. Ini digunakan untuk tujuan komputasi skala besar yang memerlukan ketersediaan dan keamanan tinggi. Ini sebagian besar digunakan di sektor-sektor seperti keuangan, asuransi, ritel, dan bidang penting lainnya di mana data berukuran besar diproses berkali-kali.

Pengujian Rangka Utama

Pengujian Rangka Utama adalah proses pengujian aplikasi perangkat lunak dan layanan berdasarkan Sistem Mainframe. Tujuan pengujian mainframe adalah untuk memastikan kinerja, keandalan, dan kualitas aplikasi atau layanan perangkat lunak dengan metode verifikasi dan validasi dan memeriksa apakah sudah siap untuk diterapkan.

Saat melakukan pengujian Mainframe, penguji hanya perlu mengetahui navigasi layar CICS. Mereka dibuat khusus untuk aplikasi tertentu. Setiap perubahan yang dilakukan pada kode di COBOL, JCL, dll. Penguji tidak perlu khawatir tentang pengaturan emulator di mesin. Perubahan yang berfungsi pada satu emulator terminal akan berfungsi pada emulator terminal lainnya.

  • Aplikasi Mainframe (atau disebut juga job batch) diuji terhadap kasus uji yang dikembangkan menggunakan 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 terminal emulator. Emulator adalah satu-satunya perangkat lunak yang perlu diinstal pada mesin klien.

Atribut Mainframe

  1. Penyimpanan Virtual
    1. Ini adalah teknik yang memungkinkan prosesor mensimulasikan penyimpanan utama yang lebih besar dari jumlah penyimpanan sebenarnya.
    2. Ini adalah teknik untuk menggunakan memori secara efektif untuk menyimpan dan menjalankan berbagai tugas berukuran.
    3. Ia menggunakan penyimpanan disk sebagai perpanjangan dari penyimpanan nyata.
  2. multiprogram
    1. Komputer menjalankan lebih dari satu program secara bersamaan. Namun pada saat tertentu hanya satu program yang dapat mengontrol CPU.
    2. Ini adalah fasilitas yang disediakan untuk mengefisienkan penggunaan CPU.
  3. Pemrosesan Batch
    1. Ini adalah teknik dimana setiap tugas diselesaikan dalam unit yang dikenal sebagai pekerjaan.
    2. Suatu pekerjaan dapat menyebabkan satu atau lebih program dijalankan secara berurutan.
    3. Penjadwal Pekerjaan membuat keputusan tentang urutan pekerjaan yang harus dilaksanakan. Untuk memaksimalkan throughput rata-rata, pekerjaan dijadwalkan sesuai prioritas dan kelasnya.
    4. 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
    1. 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.
    2. Oleh karena itu ini disebut “Pemrosesan Interaktif”. Ini memungkinkan pengguna untuk berinteraksi langsung dengan komputer.
    3. Pemrosesan pembagian waktu dikenal sebagai “Pemrosesan Latar Depan” dan pemrosesan tugas batch dikenal sebagai “Pemrosesan Latar Belakang”.
  5. Menggulung
    1. SPOOLing adalah singkatan dari Periferal Simultan Operations Online.
    2. Perangkat SPOOL digunakan untuk menyimpan keluaran program/aplikasi. Keluaran spool diarahkan ke perangkat keluaran seperti printer (jika diperlukan).
    3. Ini adalah fasilitas yang memanfaatkan keuntungan buffering untuk memanfaatkan perangkat keluaran secara efisien.

Klasifikasi Pengujian Manual di Mainframe

mainframe Pengujian Manual dapat digolongkan menjadi dua jenis :

1. Pengujian Pekerjaan Batch -

  • Proses pengujian melibatkan eksekusi pekerjaan batch untuk fungsionalitas yang diterapkan pada rilis saat ini.
  • Hasil tes diekstraksi dari file keluaran dan database diverifikasi dan dicatat.

2. Pengujian Daring -

  • Pengujian Online 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.

Bagaimana melakukan Pengujian Mainframe

  1. Tim Bisnis menyiapkan dokumen persyaratan. Yang menentukan bagaimana item atau proses tertentu akan dimodifikasi dalam siklus rilis.
  2. Tim pengujian dan pengembangan menerima dokumen persyaratan. Mereka akan mencari tahu berapa banyak proses yang akan terpengaruh oleh perubahan tersebut. Biasanya, dalam sebuah rilis, hanya 20-25% aplikasi yang terpengaruh secara langsung oleh persyaratan yang disesuaikan. 75% rilis lainnya akan digunakan untuk fungsionalitas out-box seperti menguji aplikasi dan proses.
  3. Jadi, aplikasi Mainframe harus diuji dalam dua bagian:
    1. Persyaratan Pengujian – Menguji aplikasi untuk fungsionalitas atau perubahan yang disebutkan dalam dokumen persyaratan.
    2. Integrasi Pengujian – Menguji seluruh 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
  • Excel
  • QTP

Metodologi dalam Pengujian Mainframe

Mari kita perhatikan sebuah contoh: Sebuah perusahaan asuransi XYZ memiliki modul pendaftaran anggota. Dibutuhkan data baik dari layar pendaftaran anggota dan pendaftaran offline. Seperti yang telah kita bahas sebelumnya, dibutuhkan dua pendekatan untuk pengujian Mainframe, pengujian online, dan pengujian batch.

  • Pengujian daring dilakukan pada layar pendaftaran anggota. Sama seperti halaman web, database divalidasi dengan data yang dimasukkan melalui layar.
  • Pendaftaran offline dapat berupa pendaftaran kertas atau pendaftaran di situs web pihak ketiga. Data Offline (juga disebut batch) akan dimasukkan ke dalam basis data perusahaan melalui pekerjaan batch. File datar input disiapkan sesuai format data yang ditentukan dan dimasukkan ke dalam urutan pekerjaan batch. Jadi untuk pengujian aplikasi mainframe, kita dapat menggunakan pendekatan berikut.
  • Pekerjaan pertama di baris pekerjaan batch memvalidasi data yang dimasukkan. Katakanlah misalnya karakter khusus, huruf di bidang angka saja, dll.
  • Pekerjaan kedua memvalidasi konsistensi data berdasarkan kondisi bisnis. Misalnya, pendaftaran anak tidak boleh berisi data tanggungan, kode pos anggota (yang tidak tersedia untuk layanan oleh paket yang didaftarkan), dll.
  • Tugas ketiga memodifikasi data dalam format yang dapat dimasukkan ke dalam database. Misalnya, menghapus nama paket (database hanya akan menyimpan ID paket, dan nama paket asuransi), menambahkan tanggal masuk, dll.
  • 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 input flat file ke pekerjaan pertama dan memvalidasi database. (Hasil perantara harus divalidasi untuk kehati-hatian ekstra)

Berikut ini adalah metode yang diikuti untuk pengujian Mainframe:

Langkah 1) Penggeledahan/Pengujian Asap

Fokus utama dalam tahap ini adalah memvalidasi apakah kode yang diterapkan berada di lingkungan pengujian yang tepat. Tahap ini juga memastikan tidak ada masalah kritis pada kode tersebut.

Langkah 2) Pengujian Sistem

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

  1. Pengujian Batch – Pengujian ini akan dilakukan dengan memvalidasi hasil pengujian pada file keluaran dan perubahan data yang dilakukan oleh pekerjaan batch dalam lingkup pengujian dan mencatatnya.
  2. Pengujian Online – Pengujian ini akan dilakukan pada front end aplikasi mainframe. Di sini aplikasi diuji untuk bidang entri yang benar seperti rencana asuransi, bunga atas rencana tersebut, dll.
  3. Pengujian Integrasi Batch Online – Pengujian ini akan dilakukan pada sistem yang memiliki proses batch dan aplikasi online. Aliran data dan interaksi antara layar online dan pekerjaan batch divalidasi.

    (Contoh untuk jenis pengujian ini – Pertimbangkan pembaruan pada detail Rencana seperti kenaikan suku bunga. Perubahan bunga dilakukan pada layar pembaruan, dan detail saldo pada akun yang terpengaruh hanya akan dimodifikasi oleh pekerjaan batch setiap malam. Pengujian dalam kasus ini akan dilakukan dengan memvalidasi layar detail Rencana dan menjalankan pekerjaan batch untuk memperbarui semua akun).

  4. Pengujian Basis Data – Basis data tempat data dari aplikasi mainframe (IMS, IDMS, DB2, VSAM/ISAM, kumpulan data Sequential, GDG) divalidasi untuk tata letak dan penyimpanan datanya.

Langkah 3) System Tes integrasi

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

Sistem ini tidak terpengaruh secara langsung oleh persyaratan. Namun, mereka menggunakan data dari sistem yang diuji. Penting untuk menguji antarmuka dan berbagai jenis pesan (seperti Pekerjaan Berhasil, Pekerjaan Gagal, Pembaruan Basis Data, dll.) yang mungkin dapat mengalir di antara sistem dan tindakan yang dihasilkan yang diambil oleh masing-masing sistem.

Jenis pengujian yang dilakukan pada tahap ini adalah

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

Langkah 4) Pengujian Regresi

Pengujian Regresi adalah fase umum dalam semua jenis proyek pengujian. Pengujian di Mainframe ini memastikan bahwa pekerjaan batch dan layar online yang tidak berinteraksi langsung dengan sistem yang diuji (atau tidak termasuk dalam cakupan persyaratan) tidak terpengaruh oleh rilis proyek saat ini.

Agar pengujian regresi berjalan efektif, serangkaian kasus uji tertentu harus dipilih berdasarkan kompleksitasnya dan basis regresi (Repositori kasus uji) harus dibuat. Rangkaian ini harus diperbarui setiap kali ada fungsionalitas baru yang diluncurkan ke dalam rilis.

Langkah 5) Pengujian Kinerja

Pengujian ini dilakukan untuk mengidentifikasi hambatan di area yang paling terkena dampak seperti data front-end, peningkatan basis data online, dan untuk memproyeksikan skalabilitas aplikasi.

Langkah 6) Pengujian Keamanan

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

Pengujian keamanan dua kali lipat 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 berisi prosedur, JCL, Kartu Kontrol, Modul, dll.), penguji harus melihat pratinjau dan mengambil konten ke dalam PDS sesuai kebutuhan.
  2. Mengubah JCL produksi atau JCL Pengembangan menjadi JCL QA atau disebut JOB SETUP.
  3. Menyalin file produksi dan menyiapkan file pengujian.
  4. Untuk setiap fungsi, akan ada urutan pekerjaan yang ditentukan. (Seperti yang dijelaskan dalam contoh di bagian Metodologi di Mainframe). Pekerjaan harus diserahkan menggunakan perintah SUB dengan file data pengujian.
  5. Periksa file perantara untuk mengidentifikasi alasan hilangnya atau kesalahan data.
  6. Periksa file keluaran akhir, database 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 Tes – Cacat harus dicatat jika hasil sebenarnya menyimpang dari yang diharapkan.

Langkah-langkah yang terlibat dalam Pengujian Online

  1. Pilih layar Online di lingkungan pengujian.
  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 Tes – Cacat harus dicatat jika hasil aktual menyimpang dari yang diharapkan.

Langkah-langkah yang terlibat dalam pengujian Online – Integrasi Batch

  1. Jalankan pekerjaan di a Lingkungan Uji dan memvalidasi data di layar online.
  2. Perbarui data di layar online dan validasi apakah pekerjaan batch dijalankan dengan benar dengan data yang diperbarui.

Perintah yang digunakan dalam Pengujian Mainframe

  1. KIRIM – Kirimkan pekerjaan latar belakang.
  2. BATAL – Membatalkan pekerjaan latar belakang.
  3. ALOKASI – Mengalokasikan kumpulan data
  4. SALINAN – Menyalin kumpulan data
  5. GANTI NAMA – Ganti nama kumpulan data
  6. HAPUS – Hapus Kumpulan Data
  7. JOB SCAN –Untuk mengikat JCL dengan program, perpustakaan, file, dll. tanpa menjalankannya.

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

Prasyarat untuk memulai pengujian mainframe

Rincian 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 di bawah ini harus diverifikasi.

  1. Pekerjaan
    1. Lakukan pemindaian pekerjaan (Command – JOBSCAN) untuk memeriksa kesalahan sebelum menjalankannya.
    2. Parameter CLASS harus diarahkan ke kelas pengujian.
    3. Arahkan output pekerjaan ke spool atau JHS atau sesuai kebutuhan dengan menggunakan parameter MSGCLASS.
    4. Arahkan ulang email dalam pekerjaan ke spool atau ID email uji.
    5. Komentari langkah-langkah FTP untuk pengujian awal dan kemudian arahkan pekerjaan ke server pengujian.
    6. Jika IMR (catatan Manajemen Insiden) dihasilkan dalam pekerjaan, cukup tambahkan komentar “TUJUAN PENGUJIAN” dalam pekerjaan atau kartu param.
    7. Semua perpustakaan produksi dalam pekerjaan harus diubah dan diarahkan ke perpustakaan pengujian.
    8. Pekerjaan itu tidak boleh dibiarkan begitu saja.
    9. Untuk mencegah pekerjaan berjalan dalam loop tak terbatas jika terjadi kesalahan, parameter TIME harus ditambahkan dengan waktu yang ditentukan.
    10. Simpan keluaran pekerjaan termasuk spool. Spool dapat disimpan menggunakan XDC.
  1. File
    1. Buat file uji dengan ukuran yang dibutuhkan saja. Gunakan GDGs(Grup Data Generasi – File dengan nama yang sama tetapi dengan nomor versi berurutan– MYLIB.LIB.TEST.G0001V00,MYLIB.LIB.TEST.G0002V00 seterusnya) bila diperlukan untuk menyimpan data ke dalam file berurutan dengan nama yang sama.
    2. Parameter DISP (Disposisi – menjelaskan sistem untuk menyimpan atau menghapus kumpulan data setelah penghentian langkah atau pekerjaan secara normal atau tidak normal) untuk file harus diberi kode dengan benar.
    3. Pastikan semua file yang digunakan untuk pelaksanaan pekerjaan disimpan dan ditutup dengan benar untuk mencegah pekerjaan masuk ke HOLD.
    4. Saat pengujian menggunakan GDG, pastikan versi yang ditunjukkan adalah yang tepat.
  2. Basis Data
    1. Saat menjalankan pekerjaan atau program online, pastikan bahwa data yang tidak diinginkan tidak dimasukkan, diperbarui, atau dihapus.
    2. Selain itu, pastikan wilayah DB2 yang benar digunakan untuk pengujian.
  3. Uji kasus
    1. Selalu uji kondisi batas seperti – File kosong, Pemrosesan rekaman pertama, Pemrosesan rekaman terakhir, dll.
    2. Selalu sertakan kondisi pengujian positif dan negatif.
    3. Jika prosedur standar digunakan dalam program seperti Check point restart, Abend Modules, Control files, dll. sertakan kasus uji untuk memvalidasi apakah modul telah digunakan dengan benar.
  4. Data Uji
    1. Penyiapan data pengujian harus dilakukan sebelum pengujian dimulai.
    2. Jangan pernah mengubah data di wilayah pengujian tanpa pemberitahuan. Mungkin ada tim lain yang bekerja dengan data yang sama, dan pengujian mereka akan gagal.
    3. Jika file produksi diperlukan selama eksekusi, otorisasi yang tepat harus diperoleh sebelum menyalin atau menggunakannya.

Praktik Terbaik

  1. Jika Pekerjaan Batch dijalankan, MAX CC 0 merupakan indikator bahwa pekerjaan telah berjalan dengan sukses. Ini tidak berarti bahwa fungsinya berfungsi dengan baik. Pekerjaan akan berjalan dengan sukses meskipun outputnya kosong atau tidak sesuai harapan. Jadi selalu diharapkan untuk memeriksa semua keluaran sebelum menyatakan pekerjaan berhasil.
  2. Itu selalu merupakan praktik yang baik untuk melakukan pekerjaan yang sedang diuji. Uji coba dilakukan dengan file input kosong. Proses ini harus diikuti untuk pekerjaan yang terkena dampak perubahan yang dibuat untuk siklus pengujian.
  3. Sebelum siklus pengujian dimulai, pengaturan pekerjaan pengujian harus dilakukan terlebih dahulu. Ini akan membantu dalam mengetahui kesalahan JCL terlebih dahulu sehingga menghemat waktu selama eksekusi.
  4. Saat mengakses tabel DB2 melalui SPUFI (Opsi pada emulator untuk mengakses tabel DB2), selalu setel komit otomatis sebagai “TIDAK” untuk menghindari pembaruan yang tidak disengaja.
  5. Ketersediaan Data Uji adalah tantangan utama dalam pengujian batch. Data yang diperlukan harus dibuat jauh sebelum siklus pengujian dan harus diperiksa kelengkapannya.
  6. Beberapa transaksi online dan pekerjaan batch mungkin menulis data ke dalam MQ (Antrian Pesan) untuk mengirimkan data ke aplikasi lain. Jika data tidak valid, hal ini dapat menonaktifkan/menghentikan MQ, hal ini akan mempengaruhi keseluruhan proses pengujian. Merupakan praktik yang baik untuk memeriksa apakah MQ berfungsi dengan baik setelah pengujian.

Tantangan dan Pemecahan Masalah pengujian mainframe

Tantangan Pendekatan
Persyaratan Tidak Lengkap/Tidak Jelas

Mungkin terdapat akses ke panduan pengguna/panduan pelatihan, namun hal tersebut tidak sama dengan persyaratan yang terdokumentasi.
Penguji harus dilibatkan dalam SDLC mulai dari tahap persyaratan dan seterusnya. Ini akan membantu memverifikasi apakah persyaratan dapat diuji.
Pengaturan/Identifikasi Data

Mungkin ada situasi di mana data yang ada harus digunakan kembali sesuai kebutuhan. Terkadang sulit untuk mengidentifikasi data yang dibutuhkan dari data yang ada.
Untuk penyiapan data, alat buatan sendiri dapat digunakan sesuai kebutuhan. Untuk mengambil data yang ada, kueri harus dibuat terlebih dahulu. Jika terjadi kesulitan, permintaan dapat diajukan ke tim manajemen data untuk membuat atau mengkloning data yang diperlukan.
Pengaturan Pekerjaan

Setelah pekerjaan diambil ke PDS, pekerjaan tersebut perlu diatur di wilayah QA. Sehingga pekerjaan 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 ketika pengujian ujung ke ujung perlu didukung karena masalah pada aplikasi hulu atau hilir. Permintaan ini meningkatkan waktu dan tenaga dalam siklus eksekusi.
Penggunaan skrip otomatisasi, skrip regresi, dan skrip kerangka dapat membantu mengurangi waktu dan tenaga yang berlebihan.
Rilis Tepat Waktu untuk perubahan cakupan

Mungkin ada situasi di mana dampak kode dapat mengubah tampilan dan nuansa sistem sepenuhnya. Ini mungkin memerlukan perubahan pada kasus pengujian, skrip, dan data.
Proses manajemen perubahan ruang lingkup dan analisis dampak harus dilakukan.

Abends yang umum ditemui

  1. S001 – Terjadi kesalahan I/O.

    Alasan – Membaca di akhir file, kesalahan panjang file, mencoba menulis ke file read-only.

  2. S002 – Catatan I/O tidak valid.

    Alasan – Mencoba menulis rekaman yang lebih panjang dari panjang rekaman.

  3. S004 – Terjadi kesalahan saat OPEN.

    Alasan – DCB tidak valid

  4. S013 – Kesalahan saat membuka kumpulan data.

    Alasan – Anggota PDS tidak ada, panjang rekaman dalam program tidak sesuai dengan panjang rekaman sebenarnya.

  5. S0C1 – OperaPengecualian

    Alasan –Tidak dapat membuka file, kartu DD hilang

  6. S0C4 – Pengecualian perlindungan/Pelanggaran penyimpanan
  7. Alasan – Mencoba mengakses penyimpanan tidak tersedia untuk program.
  8. S0C7 – Pengecualian Pemeriksaan Program – Data
  9. Alasan – Perubahan tata letak rekaman atau tata letak file.
  10. Sx22 – Pekerjaan telah dibatalkan
  11. S222 – Pekerjaan dibatalkan oleh pengguna tanpa dump.
  12. S322 – Waktu tugas atau langkah melebihi batas yang ditentukan, atau program berada dalam satu putaran atau parameter waktu tidak mencukupi.
  13. S522 – Batas waktu sesi TSO.
  14. S806 –Tidak dapat menghubungkan atau memuat.

    Alasan – Id pekerjaan tidak dapat menemukan modul beban yang ditentukan.

  15. S80A – Penyimpanan virtual tidak cukup untuk memenuhi permintaan GETMAIN atau FREEMAIN.
  16. S913 – Mencoba mengakses kumpulan data yang tidak diotorisasi oleh pengguna.
  17. Sx37 – Tidak dapat mengalokasikan penyimpanan yang cukup ke kumpulan data.

Error Assist – Alat yang sangat populer untuk mendapatkan informasi rinci tentang berbagai jenis tikungan.

Masalah umum yang dihadapi selama pengujian mainframe

  • Pekerjaan Abends – Agar pekerjaan berhasil diselesaikan, Anda harus memeriksa data, file input, dan modul yang ada di lokasi tertentu atau tidak. Abends dapat terjadi karena berbagai alasan, yang paling umum adalah – Data tidak valid, kolom input salah, ketidakcocokan tanggal, masalah lingkungan, dll.
  • File keluaran kosong–Meskipun pekerjaan mungkin berjalan dengan sukses (MaxCC 0), outputnya mungkin tidak seperti yang diharapkan. Jadi sebelum lulus uji kasus apa pun, penguji harus memastikan bahwa keluarannya diverifikasi silang. Baru kemudian melangkah lebih jauh.
  • File masukan kosong – Dalam beberapa aplikasi, file akan diterima dari proses upstream. Sebelum menggunakan file yang diterima untuk menguji aplikasi saat ini, data harus diverifikasi silang untuk menghindari eksekusi ulang dan pengerjaan ulang.

Ringkasan

  • Pengujian mainframe sama seperti prosedur pengujian lainnya mulai dari pengumpulan Persyaratan, desain pengujian, pelaksanaan pengujian, dan pelaporan hasil.
  • Untuk menguji aplikasi secara efektif, penguji harus berpartisipasi dalam pertemuan desain yang dijadwalkan oleh tim pengembangan dan bisnis.
  • Penguji wajib membiasakan diri dengan berbagai fungsi pengujian mainframe. Seperti navigasi layar, pembuatan file dan PDS, menyimpan hasil pengujian, dll. sebelum siklus pengujian dimulai.
  • Pengujian aplikasi mainframe adalah proses yang memakan waktu. Jadwal pengujian yang jelas harus diikuti untuk desain pengujian, pengaturan data, dan pelaksanaan.
  • Pengujian batch dan pengujian online harus dilakukan secara efektif tanpa melewatkan fungsionalitas apa pun yang disebutkan pada dokumen Persyaratan, dan tidak Uji Kasus harus dihindarkan.