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 membutuhkan ketersediaan dan keamanan yang tinggi. Ini sebagian besar digunakan di sektor-sektor seperti keuangan, asuransi, ritel, dan area penting lainnya di mana data besar diproses beberapa kali.
Pengujian Mainframe
Pengujian Mainframe adalah proses pengujian aplikasi dan layanan perangkat lunak 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 tentang navigasi layar CICS. Mereka dibuat khusus untuk aplikasi tertentu. Setiap perubahan yang dilakukan pada kode di COBOL, JCL, dll. Penguji tidak perlu mengkhawatirkan pengaturan emulator di mesin. Perubahan yang bekerja pada satu emulator terminal akan bekerja pada yang lain.
- Aplikasi Mainframe (atau disebut batch pekerjaan) diuji terhadap kasus uji yang dikembangkan menggunakan persyaratan
- Pengujian Mainframe biasanya dilakukan pada kode yang diterapkan menggunakan berbagai kombinasi data yang ditetapkan ke dalam file input.
- Aplikasi yang berjalan di mainframe dapat diakses melalui emulator terminal. Emulator adalah satu-satunya perangkat lunak yang perlu diinstal di mesin klien.
Dalam tutorial pemula ini, Anda akan belajar-
- Atribut Mainframe
- Klasifikasi Pengujian Manual di Mainframe
- Bagaimana melakukan Pengujian Mainframe
- Alat Pengujian Otomasi Mainframe
- Metodologi dalam Pengujian Mainframe
- Langkah-langkah yang terlibat dalam pengujian Batch
- Langkah-langkah yang terlibat dalam Pengujian Online
- Langkah-langkah yang terlibat dalam Online - pengujian Integrasi Batch
- Perintah yang digunakan dalam Pengujian Mainframe
- Prasyarat untuk memulai pengujian mainframe
- Praktik terbaik
- Pengujian Mainframe Tantangan dan Pemecahan Masalah
- Abends umum ditemui
- Masalah umum yang dihadapi selama pengujian mainframe
Atribut Mainframe
- 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.
- Ini menggunakan penyimpanan disk sebagai perpanjangan dari penyimpanan nyata.
- Multiprogramming
- Komputer menjalankan lebih dari satu program secara bersamaan. Tetapi pada saat tertentu hanya satu program yang dapat mengontrol CPU.
- Ini adalah fasilitas yang disediakan untuk menggunakan CPU secara efisien.
- 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 pelaksanaan pekerjaan. Untuk memaksimalkan throughput rata-rata, tugas dijadwalkan sesuai dengan 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.
- Berbagi waktu
- Dalam sistem pembagian waktu, setiap pengguna memiliki akses ke sistem melalui perangkat terminal. Alih-alih mengirimkan pekerjaan yang dijadwalkan untuk eksekusi nanti, pengguna memasukkan perintah yang segera diproses.
- Karenanya ini disebut "Pemrosesan Interaktif". Ini memungkinkan pengguna untuk berinteraksi langsung dengan komputer.
- Pemrosesan berbagi waktu dikenal sebagai "Pemrosesan Latar Depan" dan pemrosesan pekerjaan batch dikenal sebagai "Pemrosesan Latar Belakang".
- Spooling
- SPOOLing adalah singkatan dari Simultan Peripheral Operations Online .
- Perangkat SPOOL digunakan untuk menyimpan hasil keluaran program / aplikasi. Output spooled diarahkan ke perangkat output seperti printer (jika diperlukan).
- Ini adalah fasilitas yang memanfaatkan keuntungan buffering untuk membuat penggunaan perangkat keluaran secara efisien.
Klasifikasi Pengujian Manual di Mainframe
Pengujian Manual Mainframe dapat diklasifikasikan menjadi dua jenis:
- Pengujian Tugas Batch -
- Proses pengujian melibatkan eksekusi tugas batch untuk fungsionalitas yang diterapkan dalam rilis saat ini.
- Hasil tes yang diekstrak dari file output dan database diverifikasi dan dicatat.
- Pengujian Online -
- Pengujian Online mengacu pada pengujian layar CICS yang mirip dengan pengujian halaman web.
- Fungsionalitas 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
- Tim Bisnis menyiapkan dokumen persyaratan. Yang menentukan bagaimana item atau proses tertentu akan dimodifikasi dalam siklus rilis.
- Tim penguji 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 langsung oleh kebutuhan yang disesuaikan. 75% lainnya dari rilis akan digunakan untuk fungsi out-box seperti pengujian aplikasi dan proses.
- Jadi, aplikasi Mainframe harus diuji dalam dua bagian:
- Persyaratan Pengujian - Menguji aplikasi untuk fungsionalitas atau perubahan yang disebutkan dalam dokumen persyaratan.
- 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 Pengujian Otomasi mainframe.
- REXX
- Unggul
- QTP
Metodologi dalam Pengujian Mainframe
Mari kita pertimbangkan contoh: Sebuah perusahaan asuransi XYZ memiliki modul pendaftaran anggota. Dibutuhkan data baik dari layar pendaftaran anggota dan pendaftaran offline. Seperti yang kita bahas sebelumnya, dibutuhkan dua pendekatan untuk pengujian Mainframe, pengujian online, dan pengujian batch.
- Pengujian online 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 sebagai batch) akan dimasukkan ke dalam database perusahaan melalui pekerjaan batch. File datar masukan disiapkan sesuai format data yang ditentukan dan diumpankan ke urutan pekerjaan batch. Jadi untuk pengujian aplikasi mainframe kita bisa menggunakan pendekatan berikut.
- Pekerjaan pertama di baris pekerjaan batch memvalidasi data yang dimasukkan. Katakanlah misalnya karakter khusus, huruf dalam bidang angka saja, dll.
- Pekerjaan kedua memvalidasi konsistensi data berdasarkan kondisi bisnis. Misalnya, pendaftaran anak tidak boleh berisi data dependen, kode pos anggota (yang tidak tersedia untuk layanan oleh paket terdaftar), dll.
- Pekerjaan 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 antara pekerjaan divalidasi dengan memberikan input file datar ke pekerjaan pertama dan memvalidasi database. (Hasil perantara harus divalidasi untuk ekstra hati-hati)
Berikut ini adalah metode yang diikuti untuk pengujian Mainframe:
Langkah 1) : Pengujian Penggeledahan / Asap
Fokus utama dalam tahap ini adalah untuk memvalidasi apakah kode yang diterapkan berada di lingkungan pengujian yang benar. Ini juga memastikan bahwa tidak ada masalah kritis dengan kode.
Langkah 2) : Pengujian Sistem
Di bawah ini adalah jenis pengujian yang dilakukan sebagai bagian dari Pengujian Sistem.
- Pengujian Batch - Pengujian ini akan dilakukan dengan memvalidasi hasil pengujian pada file output dan perubahan data yang dilakukan oleh pekerjaan batch di bawah cakupan pengujian dan merekamnya.
- Pengujian Online - Pengujian ini akan dilakukan di bagian depan aplikasi mainframe. Di sini aplikasi diuji untuk bidang entri yang benar seperti rencana asuransi, minat pada rencana tersebut, dll.
- 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 minat dilakukan pada layar pembaruan, dan rincian saldo pada akun yang terpengaruh hanya akan diubah dengan pekerjaan batch setiap malam. Pengujian dalam hal ini akan dilakukan dengan memvalidasi layar detail Rencana dan pekerjaan batch dijalankan untuk memperbarui semua akun).
- Pengujian Basis Data - Basis data tempat data dari aplikasi mainframe (IMS, IDMS, DB2, VSAM / ISAM, Sequential dataset, GDGs) divalidasi untuk tata letak dan penyimpanan datanya.
Langkah 3) : Pengujian Integrasi Sistem
Tujuan utama dari pengujian ini adalah untuk memvalidasi fungsionalitas sistem yang berinteraksi dengan sistem yang diuji.
Sistem ini tidak secara langsung dipengaruhi oleh persyaratan. Namun, mereka menggunakan data dari sistem yang diuji. Penting untuk menguji antarmuka dan jenis pesan yang berbeda (seperti Pekerjaan Berhasil, Pekerjaan Gagal, Database diperbarui, dll.) Yang mungkin mengalir antara sistem dan tindakan yang dihasilkan oleh masing-masing sistem.
Jenis pengujian yang dilakukan pada tahap ini adalah
- Pengujian Batch
- Pengujian Online
- Online - Pengujian Integrasi Batch
Langkah 4) : Pengujian Regresi
Pengujian Regresi adalah fase umum dalam semua jenis proyek pengujian. Pengujian dalam Mainframes ini memastikan bahwa tugas batch dan layar online yang tidak berinteraksi langsung dengan sistem yang diuji (atau tidak termasuk dalam lingkup persyaratan) tidak terpengaruh oleh rilis proyek saat ini.
Untuk mendapatkan pengujian regresi yang efektif, serangkaian kasus uji tertentu harus diciutkan tergantung pada kompleksitasnya dan tempat tidur regresi (Repositori kasus uji) harus dibuat. Kumpulan ini harus diperbarui setiap kali ada fungsi baru yang diluncurkan ke rilis.
Langkah 5) : Pengujian Kinerja
Pengujian ini dilakukan untuk mengidentifikasi kemacetan di area yang terkena dampak tinggi seperti data ujung depan, meningkatkan 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 yang perlu diuji adalah
- Integritas
- Kerahasiaan
- Otorisasi
- Autentikasi
- Ketersediaan
Langkah-langkah yang terlibat dalam pengujian Batch
- Setelah tim QA menerima paket yang disetujui (Paket berisi prosedur, JCL, Kartu Kontrol, Modul, dll.), Penguji harus melihat dan mengambil konten ke dalam PDS sesuai kebutuhan.
- Ubah produksi JCL atau Development JCL menjadi QA JCL atau disebut JOB SETUP.
- Menyalin file produksi dan menyiapkan file pengujian.
- Untuk setiap fungsionalitas, akan ada urutan pekerjaan yang ditentukan. (Seperti yang dijelaskan dalam contoh di Metodologi di bagian Mainframe). Pekerjaan harus dikirimkan menggunakan perintah SUB dengan file data pengujian.
- Periksa file perantara untuk mengidentifikasi alasan data hilang atau error.
- Periksa file keluaran akhir, database, dan Spool untuk memvalidasi hasil pengujian.
- Jika pekerjaan gagal, spul akan memiliki alasan kegagalan pekerjaan. Atasi kesalahan dan kirim ulang pekerjaan.
Pelaporan Tes - Cacat harus dicatat jika hasil sebenarnya menyimpang dari yang diharapkan.
Langkah-langkah yang terlibat dalam Pengujian Online
- Pilih layar Online di lingkungan pengujian.
- Uji setiap bidang untuk data yang dapat diterima.
- Uji Skenario Uji di layar.
- Verifikasi database untuk pembaruan data dari layar online.
Pelaporan Tes - Cacat harus dicatat jika hasil sebenarnya menyimpang dari yang diharapkan.
Langkah-langkah yang terlibat dalam Online - pengujian Integrasi Batch
- Jalankan pekerjaan di Test Environment dan validasi data di layar online.
- Perbarui data di layar online dan validasi jika pekerjaan batch dijalankan dengan benar dengan data yang diperbarui.
Perintah yang digunakan dalam Pengujian Mainframe
- KIRIM - Mengirim pekerjaan latar belakang.
- BATAL - Batalkan pekerjaan latar belakang.
- ALOKASI - Alokasikan set data
- COPY - Salin set data
- RENAME - Ubah nama kumpulan data
- HAPUS - Hapus Set Data
- JOB SCAN -Untuk mengikat JCL dengan program, perpustakaan, file, dll. Tanpa menjalankannya.
Ada banyak perintah lain yang digunakan saat diperlukan, tetapi tidak sesering itu.
Prasyarat untuk memulai pengujian mainframe
Detail dasar yang diperlukan untuk pengujian mainframe adalah:
- ID login dan kata sandi untuk masuk ke aplikasi.
- Pengetahuan singkat tentang perintah ISPF.
- Nama file, pengualifikasi file, dan tipenya.
Sebelum memulai pengujian mainframe, aspek di bawah ini harus diverifikasi.
- Pekerjaan
- Lakukan pemindaian pekerjaan (Command - 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.
- Ubah rute email dalam pekerjaan ke spool atau ID email uji.
- Beri komentar langkah-langkah FTP untuk pengujian awal dan kemudian arahkan pekerjaan ke server pengujian.
- Jika IMR (catatan Manajemen Insiden) dibuat dalam pekerjaan, cukup tambahkan komentar "TUJUAN PENGUJIAN" di pekerjaan atau kartu parameter.
- Semua pustaka produksi dalam pekerjaan harus diubah dan diarahkan ke pustaka pengujian.
- Pekerjaan itu tidak boleh dibiarkan begitu saja.
- Untuk mencegah pekerjaan berjalan dalam pengulangan tak terbatas jika terjadi kesalahan, parameter TIME harus ditambahkan dengan waktu yang ditentukan.
- Simpan hasil pekerjaan termasuk spul. Kumparan dapat disimpan menggunakan XDC.
- Mengajukan
- Buat file pengujian dengan ukuran yang dibutuhkan saja. Gunakan GDG (Grup Data Generasi - File dengan nama yang sama tetapi dengan nomor versi berurutan- MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00, dll.) Bila perlu untuk menyimpan data ke dalam file yang berurutan dengan nama yang sama.
- DISP (Disposition - menjelaskan sistem untuk melakukan menyimpan atau menghapus dataset setelah penghentian normal atau abnormal dari langkah atau pekerjaan) parameter untuk file harus dikodekan dengan benar.
- Pastikan semua file yang digunakan untuk pelaksanaan pekerjaan disimpan dan ditutup dengan benar untuk mencegah pekerjaan masuk ke HOLD.
- Saat menguji menggunakan GDG, pastikan bahwa versi yang tepat ditujukan.
- Database
- Saat menjalankan pekerjaan atau program online, pastikan bahwa data yang tidak diinginkan tidak dimasukkan atau diperbarui atau dihapus.
- Juga, pastikan bahwa wilayah DB2 yang benar digunakan untuk pengujian.
- Kasus uji
- Selalu uji untuk kondisi batas seperti - File kosong, Pemrosesan rekaman pertama, Pemrosesan rekaman terakhir, dll.
- Selalu sertakan kondisi tes positif dan negatif.
- 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.
- Uji Data
- Penyiapan data pengujian harus dilakukan sebelum awal pengujian.
- Jangan pernah mengubah data di wilayah pengujian tanpa memberi tahu. Mungkin ada tim lain yang bekerja dengan 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
- Jika Batch Job dijalankan, MAX CC 0 merupakan indikator bahwa job telah berjalan dengan sukses. Ini tidak berarti bahwa fungsinya berfungsi dengan baik. Pekerjaan akan berjalan dengan sukses bahkan saat output kosong atau tidak sesuai harapan. Jadi selalu diharapkan untuk memeriksa semua output sebelum menyatakan pekerjaan berhasil.
- Itu selalu merupakan praktik yang baik untuk melakukan uji coba pekerjaan yang sedang diuji. Proses kering dilakukan dengan file input kosong. Proses ini harus diikuti untuk pekerjaan yang dipengaruhi oleh perubahan yang dibuat untuk siklus pengujian.
- Sebelum siklus tes dimulai, pengaturan pekerjaan tes harus dilakukan dengan baik sebelumnya. Ini akan membantu dalam mengetahui kesalahan JCL sebelumnya sehingga menghemat waktu selama eksekusi.
- Saat mengakses tabel DB2 melalui SPUFI (Opsi pada emulator untuk mengakses tabel DB2), selalu setel komit otomatis sebagai "TIDAK" untuk menghindari update yang tidak disengaja.
- Ketersediaan Data Uji adalah tantangan utama dalam pengujian batch. Data yang diperlukan harus dibuat dengan baik sebelum siklus pengujian dan harus diperiksa kelengkapannya.
- Beberapa transaksi online dan pekerjaan batch dapat menulis data ke dalam MQ (Antrian Pesan) untuk mengirimkan data ke aplikasi lain. Jika data tidak valid, ini dapat menonaktifkan / menghentikan MQ, ini akan mempengaruhi keseluruhan proses pengujian. Merupakan praktik yang baik untuk memeriksa apakah MQ berfungsi dengan baik setelah pengujian.
Pengujian Mainframe Tantangan dan Pemecahan Masalah
Tantangan | Pendekatan |
Persyaratan Tidak Lengkap / Tidak Jelas Mungkin ada akses ke manual pengguna / panduan pelatihan, tetapi itu tidak sama dengan persyaratan yang didokumentasikan. | Penguji harus dilibatkan dalam SDLC dari tahap persyaratan dan seterusnya. Ini akan membantu memverifikasi apakah persyaratan dapat diuji. |
Penyiapan / 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 rumahan dapat digunakan sesuai kebutuhan. Untuk mengambil data yang ada, kueri harus dibuat terlebih dahulu. Jika ada kesulitan, permintaan dapat diajukan ke tim manajemen data untuk membuat atau mengkloning data yang diperlukan. |
Pengaturan Pekerjaan Setelah pekerjaan diambil ke PDS, pekerjaan 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 dibuat selama pengaturan. |
Permintaan Ad-hoc Mungkin ada situasi ketika pengujian ujung ke ujung perlu didukung karena masalah dalam masalah aplikasi hulu atau hilir. Permintaan ini meningkatkan waktu dan tenaga dalam siklus eksekusi. | Penggunaan skrip otomatisasi, skrip regresi, dan skrip kerangka dapat membantu mengurangi overhead waktu dan tenaga. |
Rilis Tepat Waktu untuk perubahan cakupan Mungkin ada situasi di mana dampak kode dapat sepenuhnya mengubah tampilan dan nuansa sistem. Ini mungkin memerlukan perubahan untuk menguji kasus, skrip, dan data. | Proses manajemen perubahan ruang lingkup dan analisis dampak harus ada. |
Abends umum ditemui
- S001 - Terjadi kesalahan I / O.
Alasan - Membaca di akhir file, kesalahan panjang file, mencoba menulis ke file read-only.
- S002 - Data I / O tidak valid.
Alasan - Mencoba menulis rekaman lebih panjang dari panjang rekaman.
- S004 - Terjadi kesalahan selama OPEN.
Alasan - DCB tidak valid
- S013 - Kesalahan membuka set data.
Alasan - Anggota PDS tidak ada, panjang record dalam program tidak sesuai dengan panjang record sebenarnya.
- S0C1 - Pengecualian Operasi
Alasan -Tidak dapat membuka file, kartu DD tidak ada
- S0C4 - Pengecualian perlindungan / Pelanggaran penyimpanan
- Alasan - Mencoba penyimpanan akses tidak tersedia untuk program.
- SC07 - Pengecualian Pemeriksaan Program - Data
- Alasan - Perubahan tata letak rekaman atau tata letak file.
- Sx22 - Pekerjaan telah dibatalkan
- S222 - Pekerjaan dibatalkan oleh pengguna tanpa dump.
- S322 - Waktu Pekerjaan atau Langkah melebihi batas yang ditentukan, atau program berada dalam loop atau parameter waktu tidak mencukupi.
- S522 - batas waktu sesi TSO.
- S806 -Tidak dapat menghubungkan atau memuat.
Alasan - ID pekerjaan tidak dapat menemukan modul beban yang ditentukan.
- S80A - Penyimpanan virtual tidak cukup untuk memenuhi permintaan GETMAIN atau FREEMAIN.
- S913 - Mencoba mengakses set data yang tidak diizinkan oleh pengguna.
- Sx37 - Tidak dapat mengalokasikan penyimpanan yang cukup ke set data.
Error Assist - Alat yang sangat populer untuk mendapatkan informasi mendetail tentang berbagai jenis abends.
Masalah umum yang dihadapi selama pengujian mainframe
- Job Abends - Untuk berhasil menyelesaikan pekerjaan, Anda harus memeriksa data, file input dan modul yang ada di lokasi tertentu atau tidak. Abends dapat dihadapi karena berbagai alasan, yang paling umum - Data tidak valid, kolom input salah, ketidakcocokan tanggal, masalah lingkungan, dll.
- File keluaran kosong -Meskipun pekerjaan mungkin berhasil berjalan (MaxCC 0), keluarannya mungkin tidak seperti yang diharapkan. Jadi sebelum melewati kasus uji apa pun, penguji harus memastikan bahwa hasilnya diverifikasi silang. Baru kemudian melangkah lebih jauh.
- File input kosong - Dalam beberapa aplikasi, file akan 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.
Ringkasan:
- Pengujian mainframe 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, penyiapan data, dan pelaksanaan.
- Pengujian batch dan pengujian Online harus dilakukan secara efektif tanpa kehilangan fungsionalitas apa pun yang disebutkan pada dokumen Persyaratan, dan tidak ada Kasus Uji yang harus disimpan.