Mainframe Testing – Πλήρες σεμινάριο

Με: Τόμας Χάμιλτον Τόμας Χάμιλτον
Hours Ενημερώθηκε

Πριν μάθουμε έννοιες δοκιμής mainframe, ας μάθουμε

Τι είναι ένα Mainframe;

Ο κεντρικός υπολογιστής είναι ένα σύστημα υπολογιστή υψηλής απόδοσης και υψηλής ταχύτητας. Χρησιμοποιείται για υπολογιστικούς σκοπούς μεγαλύτερης κλίμακας που απαιτούν μεγάλη διαθεσιμότητα και ασφάλεια. Χρησιμοποιείται κυρίως σε τομείς όπως τα χρηματοοικονομικά, οι ασφάλειες, το λιανικό εμπόριο και άλλοι κρίσιμοι τομείς όπου τεράστια δεδομένα υποβάλλονται σε επεξεργασία πολλές φορές.

Δοκιμή Mainframe

Δοκιμή Mainframe είναι μια διαδικασία δοκιμής εφαρμογών και υπηρεσιών λογισμικού που βασίζονται σε συστήματα Mainframe. Ο σκοπός της δοκιμής mainframe είναι να διασφαλίσει την απόδοση, την αξιοπιστία και την ποιότητα της εφαρμογής ή της υπηρεσίας λογισμικού με μεθόδους επαλήθευσης και επικύρωσης και να ελέγξει εάν είναι έτοιμο για ανάπτυξη.

Κατά την εκτέλεση δοκιμών Mainframe, ο ελεγκτής χρειάζεται μόνο να γνωρίζει για τις πλοηγήσεις των οθονών CICS. Είναι προσαρμοσμένα κατασκευασμένα για συγκεκριμένες εφαρμογές. Τυχόν αλλαγές στον κώδικα στον ελεγκτή COBOL, JCL κ.λπ. δεν χρειάζεται να ανησυχείτε για τον εξομοιωτή που έχει ρυθμιστεί στο μηχάνημα. Οι αλλαγές που λειτουργούν σε έναν εξομοιωτή τερματικού θα λειτουργήσουν και σε άλλους.

  • Η εφαρμογή Mainframe (αλλιώς ονομάζεται παρτίδα εργασιών) δοκιμάζεται έναντι των δοκιμαστικών περιπτώσεων που αναπτύχθηκαν χρησιμοποιώντας απαιτήσεις
  • Η δοκιμή Mainframe συνήθως εκτελείται στον αναπτυγμένο κώδικα χρησιμοποιώντας διάφορους συνδυασμούς δεδομένων που έχουν οριστεί στο αρχείο εισόδου.
  • Οι εφαρμογές που εκτελούνται στον κεντρικό υπολογιστή μπορούν να προσπελαστούν μέσω του εξομοιωτή τερματικού. Ο εξομοιωτής είναι το μόνο λογισμικό που πρέπει να εγκατασταθεί στον υπολογιστή-πελάτη.

Χαρακτηριστικά Mainframe

  1. Εικονική αποθήκευση
    1. Είναι μια τεχνική που επιτρέπει σε έναν επεξεργαστή να προσομοιώνει την κύρια αποθήκευση που είναι μεγαλύτερη από την πραγματική ποσότητα της πραγματικής αποθήκευσης.
    2. Είναι μια τεχνική για την αποτελεσματική χρήση της μνήμης για την αποθήκευση και την εκτέλεση εργασιών διαφόρων μεγεθών.
    3. Χρησιμοποιεί την αποθήκευση δίσκου ως επέκταση της πραγματικής αποθήκευσης.
  2. Πολυπρογραμματισμός
    1. Ο υπολογιστής εκτελεί περισσότερα από ένα προγράμματα ταυτόχρονα. Αλλά ανά πάσα στιγμή μόνο ένα πρόγραμμα μπορεί να έχει τον έλεγχο της CPU.
    2. Είναι μια δυνατότητα που παρέχεται για την αποτελεσματική χρήση της CPU.
  3. Επεξεργασία παρτίδας
    1. Είναι μια τεχνική με την οποία κάθε εργασία ολοκληρώνεται σε μονάδες γνωστές ως εργασίες.
    2. Μια εργασία μπορεί να προκαλέσει την εκτέλεση ενός ή περισσότερων προγραμμάτων σε μια ακολουθία.
    3. Ο προγραμματιστής εργασιών λαμβάνει μια απόφαση σχετικά με τη σειρά με την οποία θα πρέπει να εκτελεστούν οι εργασίες. Για να μεγιστοποιηθεί η μέση απόδοση, οι εργασίες προγραμματίζονται σύμφωνα με την προτεραιότητα και την κατηγορία τους.
    4. Οι απαραίτητες πληροφορίες για την επεξεργασία παρτίδων παρέχονται μέσω του JCL (JOB CONTROL LANGUAGE). Το JCL περιγράφει τη μαζική εργασία – απαιτούνται προγράμματα, δεδομένα και πόροι.
  4. Μοιράσμα χρόνου
    1. Σε ένα σύστημα χρονομερισμού, κάθε χρήστης έχει πρόσβαση στο σύστημα μέσω της τερματικής συσκευής. Αντί να υποβάλλει εργασίες που έχουν προγραμματιστεί για μεταγενέστερη εκτέλεση, ο χρήστης εισάγει εντολές που επεξεργάζονται αμέσως.
    2. Ως εκ τούτου, αυτό ονομάζεται «Διαδραστική Επεξεργασία». Επιτρέπει στον χρήστη να αλληλεπιδρά απευθείας με τον υπολογιστή.
    3. Η επεξεργασία χρονομερισμού είναι γνωστή ως "Επεξεργασία στο προσκήνιο" και η επεξεργασία ομαδικής εργασίας είναι γνωστή ως "Επεξεργασία στο παρασκήνιο".
  5. Τυλίξτε
    1. SPOOLing σημαίνει Ταυτόχρονη Περιφερειακή Operations Online.
    2. Η συσκευή SPOOL χρησιμοποιείται για την αποθήκευση της εξόδου του προγράμματος/εφαρμογής. Η έξοδος σε ουρά κατευθύνεται σε συσκευές εξόδου όπως ένας εκτυπωτής (αν χρειάζεται).
    3. Είναι μια εγκατάσταση που εκμεταλλεύεται το πλεονέκτημα της προσωρινής αποθήκευσης για να κάνει αποτελεσματική χρήση των συσκευών εξόδου.

Ταξινόμηση χειροκίνητων δοκιμών σε Mainframe

Μεγάλο σύστημα υπολογιστή Μη αυτόματη δοκιμή μπορούν να ταξινομηθούν σε δύο τύπους:

1. Δοκιμή εργασίας παρτίδας -

  • Η διαδικασία δοκιμής περιλαμβάνει εκτελέσεις ομαδικών εργασιών για τη λειτουργικότητα που εφαρμόζεται στην τρέχουσα έκδοση.
  • Τα αποτελέσματα της δοκιμής που εξάγονται από τα αρχεία εξόδου και τη βάση δεδομένων επαληθεύονται και καταγράφονται.

2. Διαδικτυακές δοκιμές -

  • Η διαδικτυακή δοκιμή αναφέρεται στη δοκιμή των οθονών CICS που είναι παρόμοια με τη δοκιμή της ιστοσελίδας.
  • Η λειτουργικότητα των υπαρχουσών οθονών θα μπορούσε να αλλάξει ή να προστεθούν νέες οθόνες.
  • Διάφορες εφαρμογές μπορούν να έχουν οθόνες ερωτήσεων και οθόνες ενημέρωσης. Η λειτουργικότητα αυτών των οθονών πρέπει να ελεγχθεί ως μέρος της διαδικτυακής δοκιμής.

Πώς να κάνετε τη δοκιμή Mainframe

  1. Η ομάδα Επιχειρήσεων προετοιμάζει τα έγγραφα απαιτήσεων. Αυτό καθορίζει τον τρόπο με τον οποίο ένα συγκεκριμένο στοιχείο ή διαδικασία πρόκειται να τροποποιηθεί στον κύκλο κυκλοφορίας.
  2. Η ομάδα δοκιμών και η ανάπτυξη λαμβάνουν το έγγραφο απαίτησης. Θα καταλάβουν πόσες διαδικασίες θα επηρεαστούν από την αλλαγή. Συνήθως, σε μια έκδοση, μόνο το 20-25% της εφαρμογής επηρεάζεται άμεσα από την προσαρμοσμένη απαίτηση. Το υπόλοιπο 75% της έκδοσης θα προορίζεται για τις λειτουργίες out-box, όπως η δοκιμή των εφαρμογών και των διαδικασιών.
  3. Έτσι, μια εφαρμογή Mainframe πρέπει να δοκιμαστεί σε δύο μέρη:
    1. Απαιτήσεις δοκιμών – Δοκιμή της εφαρμογής για τη λειτουργικότητα ή την αλλαγή που αναφέρεται στο έγγραφο απαίτησης.
    2. Δοκιμή ολοκλήρωσης – Δοκιμή ολόκληρης της διαδικασίας ή άλλης εφαρμογής που λαμβάνει ή στέλνει δεδομένα στην επηρεαζόμενη εφαρμογή. Δοκιμή παλινδρόμησης είναι ο πρωταρχικός στόχος αυτής της δοκιμαστικής δραστηριότητας.

ΣΧΕΤΙΚΑ ΑΡΘΡΑ

Εργαλεία δοκιμής αυτοματισμού Mainframe

Παρακάτω είναι η λίστα των εργαλείων που μπορούν να χρησιμοποιηθούν για mainframe Δοκιμές Αυτοματισμού.

  • REXX
  • Excel
  • QTP

Μεθοδολογία στο Mainframe Testing

Ας εξετάσουμε ένα παράδειγμα: Μια ασφαλιστική εταιρεία XYZ διαθέτει ενότητα εγγραφής μελών. Λαμβάνει δεδομένα τόσο από την οθόνη εγγραφής μελών όσο και από την εγγραφή εκτός σύνδεσης. Όπως συζητήσαμε νωρίτερα, χρειάζονται δύο προσεγγίσεις για τη δοκιμή Mainframe, τη διαδικτυακή δοκιμή και τη δοκιμή παρτίδας.

  • Διαδικτυακή δοκιμή γίνεται στην οθόνη εγγραφής μελών. Ακριβώς όπως μια ιστοσελίδα, η βάση δεδομένων επικυρώνεται με δεδομένα που εισάγονται μέσω των οθονών.
  • Εγγραφή εκτός σύνδεσης μπορεί να είναι έντυπη εγγραφή ή εγγραφή σε ιστότοπο τρίτων. Τα δεδομένα εκτός σύνδεσης (γνωστά και ως παρτίδα) θα εισαχθούν στη βάση δεδομένων της εταιρείας μέσω εργασιών παρτίδας. Ένα επίπεδο αρχείο εισόδου προετοιμάζεται σύμφωνα με την προβλεπόμενη μορφή δεδομένων και τροφοδοτείται στην ακολουθία των εργασιών παρτίδας. Έτσι, για τη δοκιμή εφαρμογών mainframe μπορούμε να χρησιμοποιήσουμε την ακόλουθη προσέγγιση.
  • Η πρώτη εργασία στη σειρά εργασιών παρτίδας επικυρώνει τα δεδομένα που έχουν εισαχθεί. Ας πούμε για παράδειγμα ειδικό χαρακτήρα, αλφάβητα σε πεδία μόνο αριθμού κ.λπ.
  • Η δεύτερη εργασία επικυρώνει τη συνέπεια των δεδομένων με βάση τις επιχειρηματικές συνθήκες. Για παράδειγμα, μια εγγραφή παιδιού δεν πρέπει να περιέχει εξαρτημένα δεδομένα, ταχυδρομικό κώδικα μέλους (ο οποίος δεν είναι διαθέσιμος για εξυπηρέτηση από το εγγεγραμμένο πρόγραμμα) κ.λπ.
  • Η τρίτη εργασία τροποποιεί τα δεδομένα στη μορφή που μπορούν να εισαχθούν στη βάση δεδομένων. Για παράδειγμα, η διαγραφή του ονόματος προγράμματος (η βάση δεδομένων θα αποθηκεύσει μόνο το αναγνωριστικό προγράμματος και το όνομα του ασφαλιστικού προγράμματος), την προσθήκη ημερομηνίας καταχώρισης κ.λπ.
  • Η τέταρτη εργασία φορτώνει τα δεδομένα στη βάση δεδομένων.
  • Δοκιμές εργασίας παρτίδας γίνεται σε αυτή τη διαδικασία σε δύο φάσεις –
  • Κάθε εργασία επικυρώνεται χωριστά και το
  • Η ενοποίηση μεταξύ των εργασιών επικυρώνεται παρέχοντας επίπεδο αρχείου εισόδου στην πρώτη εργασία και επικυρώνοντας τη βάση δεδομένων. (Τα ενδιάμεσα αποτελέσματα πρέπει να επικυρωθούν για ιδιαίτερη προσοχή)

Ακολουθεί η μέθοδος που ακολουθείται για τη δοκιμή Mainframe:

Βήμα 1) Shakedown/Δοκιμή καπνού

Η κύρια εστίαση σε αυτό το στάδιο είναι να επικυρωθεί εάν ο κώδικας που έχει αναπτυχθεί βρίσκεται στο σωστό περιβάλλον δοκιμής. Διασφαλίζει επίσης ότι δεν υπάρχουν κρίσιμα ζητήματα με τον κώδικα.

Βήμα 2) Δοκιμή συστήματος

Παρακάτω είναι οι τύποι δοκιμών που γίνονται στο πλαίσιο της δοκιμής συστήματος.

  1. Δοκιμή παρτίδας – Αυτή η δοκιμή θα γίνει με την επικύρωση των αποτελεσμάτων των δοκιμών στα αρχεία εξόδου και τις αλλαγές δεδομένων που πραγματοποιήθηκαν από τις εργασίες παρτίδας υπό το πεδίο δοκιμής και την καταγραφή τους.
  2. Διαδικτυακές δοκιμές – Αυτή η δοκιμή θα γίνει στο μπροστινό μέρος της εφαρμογής mainframe. Εδώ η εφαρμογή ελέγχεται για το σωστό πεδίο καταχώρισης όπως ένα ασφαλιστικό πρόγραμμα, τόκοι για το πρόγραμμα κ.λπ.
  3. Ηλεκτρονική δοκιμή ενσωμάτωσης παρτίδων – Αυτή η δοκιμή θα γίνει σε συστήματα που έχουν διαδικασίες παρτίδας και ηλεκτρονική εφαρμογή. Η ροή δεδομένων και η αλληλεπίδραση μεταξύ των διαδικτυακών οθονών και των ομαδικών εργασιών επικυρώνονται.

    (Παράδειγμα για αυτό το είδος δοκιμών – Εξετάστε μια ενημέρωση σχετικά με τις λεπτομέρειες του προγράμματος, όπως η αύξηση του επιτοκίου. Η αλλαγή ενδιαφέροντος γίνεται σε μια οθόνη ενημέρωσης και τα στοιχεία υπολοίπου στους επηρεαζόμενους λογαριασμούς θα τροποποιηθούν μόνο από μια νυχτερινή δέσμη εργασιών. Ο έλεγχος σε αυτήν την περίπτωση θα γίνει επικυρώνοντας την οθόνη Λεπτομέρειες σχεδίου και την εκτέλεση εργασιών δέσμης για την ενημέρωση όλων των λογαριασμών).

  4. Δοκιμή βάσης δεδομένων – Οι βάσεις δεδομένων όπου επικυρώνονται τα δεδομένα από την εφαρμογή mainframe (IMS, IDMS, DB2, VSAM/ISAM, Sequential databass, GDGs) για τη διάταξή τους και την αποθήκευση δεδομένων.

Βήμα 3) σύστημα Δοκιμή ολοκλήρωσης

Ο πρωταρχικός σκοπός αυτής της δοκιμής είναι να επικυρώσει τη λειτουργικότητα των συστημάτων που αλληλεπιδρούν με το υπό δοκιμή σύστημα.

Αυτά τα συστήματα δεν επηρεάζονται άμεσα από τις απαιτήσεις. Ωστόσο, χρησιμοποιούν δεδομένα από το υπό δοκιμή σύστημα. Είναι σημαντικό να ελέγξετε τη διεπαφή και τους διαφορετικούς τύπους μηνυμάτων (όπως Επιτυχής εργασία, Αποτυχία εργασίας, ενημερωμένη βάση δεδομένων κ.λπ.) που μπορεί να ρέουν μεταξύ των συστημάτων και των ενεργειών που προκύπτουν από τα μεμονωμένα συστήματα.

Οι τύποι δοκιμών που γίνονται σε αυτό το στάδιο είναι

  1. Δοκιμή παρτίδας
  2. Διαδικτυακές δοκιμές
  3. Online – Δοκιμή ενσωμάτωσης παρτίδας

Βήμα 4) Δοκιμή παλινδρόμησης

Ο έλεγχος παλινδρόμησης είναι μια κοινή φάση σε κάθε τύπο έργου δοκιμών. Αυτή η δοκιμή σε Mainframes διασφαλίζει ότι οι εργασίες παρτίδας και οι ηλεκτρονικές οθόνες που δεν αλληλεπιδρούν άμεσα με το υπό δοκιμή σύστημα (ή δεν εμπίπτουν στο εύρος των απαιτήσεων) δεν επηρεάζονται από την τρέχουσα έκδοση του έργου.

Προκειμένου να υπάρχει αποτελεσματικός έλεγχος παλινδρόμησης, θα πρέπει να επιλεγεί ένα συγκεκριμένο σύνολο δοκιμαστικών περιπτώσεων ανάλογα με την πολυπλοκότητά τους και να δημιουργηθεί ένα κρεβάτι παλινδρόμησης (αποθήκη υποθέσεων δοκιμής). Αυτό το σύνολο θα πρέπει να ενημερώνεται κάθε φορά που κυκλοφορεί μια νέα λειτουργικότητα στην κυκλοφορία.

Βήμα 5) Δοκιμές Απόδοσης

Αυτή η δοκιμή γίνεται για τον εντοπισμό των σημείων συμφόρησης σε περιοχές με μεγάλη επιτυχία, όπως τα δεδομένα εμπρός, η αναβάθμιση των διαδικτυακών βάσεων δεδομένων και η προβολή της επεκτασιμότητας της εφαρμογής.

Βήμα 6) Δοκιμή ασφαλείας

Αυτή η δοκιμή γίνεται για να αξιολογηθεί πόσο καλά έχει σχεδιαστεί και αναπτυχθεί η εφαρμογή για την αντιμετώπιση επιθέσεων κατά της ασφάλειας.

Θα πρέπει να πραγματοποιηθούν διπλές δοκιμές ασφαλείας στο σύστημα – Ασφάλεια Mainframe και Ασφάλεια Δικτύου.

Τα χαρακτηριστικά που πρέπει να δοκιμαστούν είναι

  1. Integrity
  2. Εμπιστευτικότητα
  3. εξουσιοδότηση
  4. Πιστοποίηση
  5. Διαθεσιμότητα

Βήματα που εμπλέκονται στις δοκιμές παρτίδων

  1. Αφού η ομάδα QA λάβει το εγκεκριμένο πακέτο (Το πακέτο περιέχει διαδικασίες, JCL, Κάρτες Ελέγχου, Μονάδες κ.λπ.), ο ελεγκτής θα πρέπει να κάνει προεπισκόπηση και να ανακτήσει τα περιεχόμενα στο PDS όπως απαιτείται.
  2. Μετατρέψτε το JCL παραγωγής ή το Development JCL σε QA JCL που ονομάζεται αλλιώς JOB SETUP.
  3. Αντιγραφή αρχείου παραγωγής και προετοιμασία αρχείων δοκιμής.
  4. Για κάθε λειτουργία, θα οριστεί μια σειρά εργασιών. (Όπως εξηγείται στο παράδειγμα στην ενότητα Μεθοδολογία στο Mainframe). Οι εργασίες πρέπει να υποβάλλονται χρησιμοποιώντας την εντολή SUB με τα αρχεία δεδομένων δοκιμής.
  5. Ελέγξτε το ενδιάμεσο αρχείο για να εντοπίσετε τους λόγους απώλειας ή σφάλματος δεδομένων.
  6. Ελέγξτε το τελικό αρχείο εξόδου, τη βάση δεδομένων και το Spool για να επικυρώσετε τα αποτελέσματα της δοκιμής.
  7. Εάν η εργασία αποτύχει, το καρούλι θα έχει τον λόγο για την αποτυχία της εργασίας. Αντιμετωπίστε το σφάλμα και υποβάλετε ξανά την εργασία.

Αναφορά δοκιμής - Ελάττωμα θα πρέπει να καταγραφεί εάν το πραγματικό αποτέλεσμα αποκλίνει από το αναμενόμενο.

Βήματα που εμπλέκονται στις διαδικτυακές δοκιμές

  1. Επιλέξτε την οθόνη Online σε ένα δοκιμαστικό περιβάλλον.
  2. Ελέγξτε κάθε πεδίο για τα αποδεκτά δεδομένα.
  3. Δοκιμάστε το Σενάριο δοκιμής στην οθόνη.
  4. Επαληθεύστε τη βάση δεδομένων για τις ενημερώσεις δεδομένων από την ηλεκτρονική οθόνη.

Αναφορά δοκιμής – Το ελάττωμα πρέπει να καταγράφεται εάν το πραγματικό αποτέλεσμα αποκλίνει από το αναμενόμενο.

Βήματα που εμπλέκονται στις δοκιμές Online – Batch Integration

  1. Εκτελέστε την εργασία σε ένα Περιβάλλον δοκιμής και επικυρώστε τα δεδομένα στις ηλεκτρονικές οθόνες.
  2. Ενημερώστε τα δεδομένα στις ηλεκτρονικές οθόνες και επικυρώστε εάν η ομαδική εργασία εκτελείται σωστά με τα ενημερωμένα δεδομένα.

Εντολές που χρησιμοποιούνται στο Mainframe Testing

  1. SUBMIT – Υποβάλετε μια εργασία παρασκηνίου.
  2. ΑΚΥΡΩΣΗ – Ακύρωση εργασίας στο παρασκήνιο.
  3. ALLOCATE – Εκχωρήστε ένα σύνολο δεδομένων
  4. ΑΝΤΙΓΡΑΦΗ – Αντιγράψτε ένα σύνολο δεδομένων
  5. RENAME – Μετονομασία συνόλου δεδομένων
  6. ΔΙΑΓΡΑΦΗ – Διαγραφή συνόλου δεδομένων
  7. ΣΑΡΩΣΗ ΕΡΓΑΣΙΑΣ – Για να συνδέσετε το JCL με το πρόγραμμα, τις βιβλιοθήκες, το αρχείο κ.λπ. χωρίς να το εκτελέσετε.

Υπάρχουν πολλές άλλες εντολές που χρησιμοποιούνται όταν απαιτείται, αλλά δεν είναι τόσο συχνές.

Προαπαιτούμενα για την έναρξη δοκιμών mainframe

Οι βασικές λεπτομέρειες που απαιτούνται για τη δοκιμή του mainframe είναι:

  • Αναγνωριστικό σύνδεσης και κωδικός πρόσβασης για τη σύνδεση στην εφαρμογή.
  • Σύντομη γνώση εντολών ISPF.
  • Ονόματα αρχείων, προσδιορισμός αρχείων και τύποι τους.

Πριν ξεκινήσετε τη δοκιμή του mainframe, θα πρέπει να επαληθευτούν οι παρακάτω πτυχές.

  1. Δουλειά
    1. Κάντε μια σάρωση εργασίας (Command – JOBSCAN) για να ελέγξετε για σφάλματα πριν την εκτελέσετε.
    2. Η παράμετρος CLASS πρέπει να αναφέρεται στην κατηγορία δοκιμής.
    3. Κατευθύνετε την έξοδο εργασίας σε καρούλι ή JHS ή όπως απαιτείται χρησιμοποιώντας την παράμετρο MSGCLASS.
    4. Επαναδρομολογήστε το email στην εργασία σε ουρά ή σε ένα δοκιμαστικό αναγνωριστικό αλληλογραφίας.
    5. Σχολιάστε τα βήματα FTP για την αρχική δοκιμή και, στη συνέχεια, υποδείξτε την εργασία σε έναν δοκιμαστικό διακομιστή.
    6. Σε περίπτωση που δημιουργηθεί ένα IMR (αρχείο διαχείρισης περιστατικών) στην εργασία, απλώς προσθέστε το σχόλιο «ΣΚΟΠΟΣ ΔΟΚΙΜΗΣ» στην εργασία ή την κάρτα παραμέτρου.
    7. Όλες οι βιβλιοθήκες παραγωγής στην εργασία πρέπει να αλλάξουν και να οδηγηθούν σε δοκιμαστικές βιβλιοθήκες.
    8. Η δουλειά δεν πρέπει να μένει αφύλακτη.
    9. Για να αποτραπεί η εκτέλεση της εργασίας σε έναν απεριόριστο βρόχο κάλυψης οποιουδήποτε σφάλματος, η παράμετρος TIME θα πρέπει να προστεθεί με καθορισμένο χρόνο.
    10. Αποθηκεύστε το αποτέλεσμα της εργασίας συμπεριλαμβανομένου του καρουλιού. Το καρούλι μπορεί να αποθηκευτεί χρησιμοποιώντας XDC.
  1. Αρχεία
    1. Δημιουργήστε αρχείο δοκιμής μόνο του απαιτούμενου μεγέθους. Χρησιμοποιήστε GDG (Ομάδες Δεδομένων Γενιάς – Αρχεία με το ίδιο όνομα αλλά με διαδοχικούς αριθμούς έκδοσης – MYLIB.LIB.TEST.G0001V00,MYLIB.LIB.TEST.G0002V00 ούτω καθεξής) όταν χρειάζεται για να αποθηκεύσετε δεδομένα σε διαδοχικά αρχεία με το ίδιο όνομα.
    2. Η παράμετρος DISP (Disposition – περιγράφει το σύστημα που θα εκτελέσει διατήρηση ή διαγραφή του συνόλου δεδομένων μετά από κανονικό ή μη φυσιολογικό τερματισμό του βήματος ή της εργασίας) για τα αρχεία πρέπει να κωδικοποιηθεί σωστά.
    3. Βεβαιωθείτε ότι όλα τα αρχεία που χρησιμοποιούνται για την εκτέλεση εργασιών είναι αποθηκευμένα και κλειστά σωστά για να αποτρέψετε τη μετάβαση της εργασίας σε HOLD.
    4. Κατά τη δοκιμή με χρήση GDG, βεβαιωθείτε ότι βρίσκεται η σωστή έκδοση.
  2. βάση δεδομένων
    1. Κατά την εκτέλεση της εργασίας ή του διαδικτυακού προγράμματος, βεβαιωθείτε ότι δεν εισάγονται, ενημερώνονται ή διαγράφονται ανεπιθύμητα δεδομένα.
    2. Επίσης, βεβαιωθείτε ότι χρησιμοποιείται η σωστή περιοχή DB2 για τη δοκιμή.
  3. Δοκιμαστικές περιπτώσεις
    1. Πάντα να ελέγχετε για οριακές συνθήκες όπως – Κενό αρχείο, Επεξεργασία πρώτης εγγραφής, Επεξεργασία τελευταίας εγγραφής κ.λπ.
    2. Να συμπεριλαμβάνετε πάντα θετικές και αρνητικές συνθήκες δοκιμής.
    3. Σε περίπτωση που χρησιμοποιούνται τυπικές διαδικασίες στο πρόγραμμα, όπως η επανεκκίνηση του σημείου ελέγχου, οι μονάδες Abend, τα αρχεία ελέγχου κ.λπ. περιλαμβάνουν περιπτώσεις δοκιμών για επικύρωση εάν οι μονάδες έχουν χρησιμοποιηθεί σωστά.
  4. Δεδομένα δοκιμής
    1. Η ρύθμιση των δεδομένων δοκιμής πρέπει να γίνει πριν από την έναρξη της δοκιμής.
    2. Ποτέ μην τροποποιείτε τα δεδομένα στην περιοχή δοκιμής χωρίς ειδοποίηση. Μπορεί να υπάρχουν άλλες ομάδες που εργάζονται με τα ίδια δεδομένα και η δοκιμή τους θα αποτύχει.
    3. Σε περίπτωση που απαιτούνται τα αρχεία παραγωγής κατά την εκτέλεση, θα πρέπει να ληφθεί η κατάλληλη εξουσιοδότηση πριν από την αντιγραφή ή τη χρήση τους.

καλυτερα Practices

  1. Σε περίπτωση εκτέλεσης Μαζικής Εργασίας, το MAX CC 0 είναι ένδειξη ότι η εργασία εκτελέστηκε με επιτυχία. Αυτό δεν σημαίνει ότι η λειτουργικότητα λειτουργεί καλά. Η εργασία θα εκτελεστεί με επιτυχία ακόμα και όταν η έξοδος είναι άδεια ή όχι σύμφωνα με την προσδοκία. Επομένως, είναι πάντα αναμενόμενο να ελέγχει όλα τα αποτελέσματα πριν δηλωθεί η εργασία επιτυχής.
  2. Είναι πάντα μια καλή πρακτική να κάνετε μια στεγνή εκτέλεση της εργασίας υπό δοκιμή. Η ξηρή εκτέλεση γίνεται με άδεια αρχεία εισόδου. Αυτή η διαδικασία θα πρέπει να ακολουθείται για τις εργασίες που επηρεάζονται από τις αλλαγές που έγιναν για τον κύκλο δοκιμής.
  3. Πριν ξεκινήσει ο κύκλος δοκιμής, η ρύθμιση της δοκιμαστικής εργασίας θα πρέπει να γίνει αρκετά εκ των προτέρων. Αυτό θα βοηθήσει στον εντοπισμό τυχόν σφάλματος JCL εκ των προτέρων, εξοικονομώντας χρόνο κατά την εκτέλεση.
  4. Κατά την πρόσβαση σε πίνακες DB2 μέσω του SPUFI (Επιλογή στον εξομοιωτή για πρόσβαση σε πίνακες DB2), ορίζετε πάντα την αυτόματη δέσμευση ως "ΟΧΙ" για να αποφύγετε τυχαίες ενημερώσεις.
  5. Η διαθεσιμότητα δεδομένων δοκιμής είναι η κύρια πρόκληση στις δοκιμές παρτίδας. Τα απαιτούμενα δεδομένα θα πρέπει να δημιουργούνται πολύ πριν από τον κύκλο δοκιμής και θα πρέπει να ελέγχονται για πληρότητα.
  6. Ορισμένες ηλεκτρονικές συναλλαγές και ομαδικές εργασίες ενδέχεται να εγγράψουν δεδομένα σε MQ (ουρά μηνυμάτων) για τη μετάδοση δεδομένων σε άλλες εφαρμογές. Εάν τα δεδομένα δεν είναι έγκυρα, ενδέχεται να απενεργοποιηθούν/διακόψουν τα MQ, αυτό θα επηρεάσει την όλη διαδικασία δοκιμής. Είναι καλή πρακτική να ελέγχετε ότι τα MQ λειτουργούν καλά μετά τη δοκιμή.

Δοκιμές Mainframe Προκλήσεις και αντιμετώπιση προβλημάτων

Προκλήσεις Προσέγγιση
Ελλιπείς / Ασαφείς Απαιτήσεις

Μπορεί να υπάρχει πρόσβαση στο εγχειρίδιο χρήστη/οδηγό εκπαίδευσης, αλλά αυτά δεν είναι ίδια με τις τεκμηριωμένες απαιτήσεις. 		Οι δοκιμαστές θα πρέπει να συμμετέχουν στο SDLC από τη φάση των απαιτήσεων και μετά. Αυτό θα σας βοηθήσει να επαληθεύσετε εάν οι απαιτήσεις είναι ελεγχόμενες.
Ρύθμιση/ Αναγνώριση δεδομένων

Μπορεί να υπάρχουν περιπτώσεις όπου τα υπάρχοντα δεδομένα θα πρέπει να επαναχρησιμοποιηθούν σύμφωνα με τις απαιτήσεις. Μερικές φορές είναι δύσκολο να προσδιοριστούν τα απαιτούμενα δεδομένα από τα υπάρχοντα δεδομένα. 		Για τη ρύθμιση δεδομένων, μπορούν να χρησιμοποιηθούν εγχώρια εργαλεία ανάλογα με τις ανάγκες. Για την ανάκτηση υπαρχόντων δεδομένων, τα ερωτήματα θα πρέπει να δημιουργηθούν εκ των προτέρων. Σε περίπτωση οποιασδήποτε δυσκολίας, μπορεί να υποβληθεί αίτημα στην ομάδα διαχείρισης δεδομένων για τη δημιουργία ή την κλωνοποίηση απαιτούμενων δεδομένων.
Ρύθμιση εργασιών

Μόλις οι εργασίες ανακτηθούν στο PDS, η εργασία πρέπει να ρυθμιστεί στην περιοχή QA. Για να μην υποβάλλονται οι θέσεις εργασίας με κριτήριο παραγωγής ή λεπτομέρεια διαδρομής. 		Τα εργαλεία ρύθμισης εργασιών πρέπει να χρησιμοποιούνται έτσι ώστε να ξεπερνιούνται τα ανθρώπινα λάθη που έγιναν κατά τη ρύθμιση.
Ad-hoc Αίτημα

Ενδέχεται να υπάρξουν περιπτώσεις κατά τις οποίες πρέπει να υποστηριχθούν οι δοκιμές από άκρο σε άκρο λόγω προβλήματος σε ζητήματα ανοδικής ή μεταγενέστερης εφαρμογής. Αυτά τα αιτήματα αυξάνουν τον χρόνο και την προσπάθεια στον κύκλο εκτέλεσης. 		Η χρήση σεναρίων αυτοματισμού, σεναρίων παλινδρόμησης και σεναρίων σκελετού θα μπορούσε να βοηθήσει στη μείωση του χρόνου και της προσπάθειας.
Έγκαιρες εκδόσεις για αλλαγή πεδίου

Μπορεί να υπάρξει μια κατάσταση όπου η επίδραση του κώδικα μπορεί να αλλάξει εντελώς την εμφάνιση και την αίσθηση του συστήματος. Αυτό μπορεί να απαιτεί αλλαγή σε περιπτώσεις δοκιμής, σενάρια και δεδομένα. 		Θα πρέπει να υπάρχει διαδικασία διαχείρισης αλλαγής πεδίου και ανάλυση επιπτώσεων.

Συναντήθηκαν κοινά Abends

  1. S001 – Παρουσιάστηκε σφάλμα I/O.

    Αιτία – Ανάγνωση στο τέλος του αρχείου, σφάλμα μήκους αρχείου, προσπάθεια εγγραφής σε αρχείο μόνο για ανάγνωση.

  2. S002 – Μη έγκυρη εγγραφή I/O.

    Αιτία – Προσπάθεια να γράψετε μια εγγραφή μεγαλύτερη από τη διάρκεια της εγγραφής.

  3. S004 – Παρουσιάστηκε σφάλμα κατά το OPEN.

    Αιτία – Μη έγκυρο DCB

  4. S013 – Σφάλμα κατά το άνοιγμα ενός συνόλου δεδομένων.

    Αιτία – Το μέλος PDS δεν υπάρχει, η διάρκεια εγγραφής στο πρόγραμμα δεν ταιριάζει με την πραγματική διάρκεια εγγραφής.

  5. S0C1 - OperaΕξαίρεση

    Αιτία – Δεν είναι δυνατό το άνοιγμα του αρχείου, λείπει η κάρτα DD

  6. S0C4 – Εξαίρεση προστασίας/ Παραβίαση αποθήκευσης
  7. Αιτία – Η προσπάθεια πρόσβασης στον αποθηκευτικό χώρο δεν είναι διαθέσιμος στο πρόγραμμα.
  8. S0C7 – Εξαίρεση ελέγχου προγράμματος – Δεδομένα
  9. Αιτία – Αλλαγή στη διάταξη εγγραφής ή διάταξη αρχείου.
  10. Sx22 – Η εργασία έχει ακυρωθεί
  11. S222 – Η εργασία ακυρώθηκε από τον χρήστη χωρίς ένδειξη.
  12. S322 – Ο χρόνος εργασίας ή βήματος υπερέβη το καθορισμένο όριο ή το πρόγραμμα βρίσκεται σε βρόχο ή ανεπαρκής παράμετρος χρόνου.
  13. S522 – Λήξη χρονικού ορίου περιόδου λειτουργίας TSO.
  14. S806 – Δεν είναι δυνατή η σύνδεση ή η φόρτωση.

    Αιτία – Το αναγνωριστικό εργασίας δεν μπορεί να βρει την καθορισμένη μονάδα φόρτωσης.

  15. S80A – Δεν υπάρχει αρκετός εικονικός χώρος αποθήκευσης για την ικανοποίηση αιτημάτων GETMAIN ή FREEMAIN.
  16. S913 – Προσπάθεια πρόσβασης στο σύνολο δεδομένων που ο χρήστης δεν είναι εξουσιοδοτημένος.
  17. Sx37 – Δεν είναι δυνατή η κατανομή αρκετού χώρου αποθήκευσης στο σύνολο δεδομένων.

Error Assist – Ένα πολύ δημοφιλές εργαλείο για να λαμβάνετε λεπτομερείς πληροφορίες για διάφορους τύπους abends.

Συνηθισμένο πρόβλημα που αντιμετωπίζεται κατά τη δοκιμή του mainframe

  • Τζομπ Άμπεντς – Για την επιτυχή ολοκλήρωση της εργασίας, θα πρέπει να ελέγξετε τα δεδομένα, το αρχείο εισόδου και τις μονάδες που υπάρχουν στη συγκεκριμένη τοποθεσία ή όχι. Abends μπορεί να αντιμετωπιστούν για πολλούς λόγους, οι πιο συνηθισμένοι είναι – Μη έγκυρα δεδομένα, Λανθασμένο πεδίο εισαγωγής, αναντιστοιχία ημερομηνιών, περιβαλλοντικά ζητήματα κ.λπ.
  • Το αρχείο εξόδου είναι κενό–Αν και η εργασία μπορεί να εκτελεστεί με επιτυχία (MaxCC 0), η έξοδος μπορεί να μην είναι η αναμενόμενη. Επομένως, πριν περάσει οποιαδήποτε δοκιμαστική περίπτωση, ο ελεγκτής πρέπει να βεβαιωθεί ότι η έξοδος είναι διασταυρούμενη επαλήθευση. Μόνο τότε προχωρήστε περαιτέρω.
  • Κενό αρχείο εισαγωγής – Σε ορισμένες εφαρμογές, θα λαμβάνονται αρχεία από τις ανοδικές διεργασίες. Πριν χρησιμοποιήσετε το ληφθέν αρχείο για τον έλεγχο της τρέχουσας εφαρμογής, τα δεδομένα θα πρέπει να διασταυρωθούν για να αποφευχθεί η επανεκτέλεση και η επανεπεξεργασία.

Σύνοψη

  • Η δοκιμή του βασικού πλαισίου είναι όπως κάθε άλλη διαδικασία δοκιμών, ξεκινώντας από τη συλλογή Απαιτήσεων, το σχεδιασμό δοκιμής, την εκτέλεση δοκιμών και την αναφορά αποτελεσμάτων.
  • Προκειμένου να δοκιμαστεί αποτελεσματικά η εφαρμογή, ο ελεγκτής θα πρέπει να συμμετέχει σε συναντήσεις σχεδιασμού που έχουν προγραμματιστεί από ομάδες ανάπτυξης και επιχειρήσεων.
  • Είναι υποχρεωτικό για τον ελεγκτή να εξοικειωθεί με διάφορες λειτουργίες δοκιμής mainframe. Όπως η πλοήγηση στην οθόνη, η δημιουργία αρχείων και PDS, η αποθήκευση των αποτελεσμάτων των δοκιμών κ.λπ. πριν από την έναρξη του κύκλου δοκιμής.
  • Η δοκιμή εφαρμογών κεντρικού πλαισίου είναι μια χρονοβόρα διαδικασία. Θα πρέπει να ακολουθείται ένα σαφές χρονοδιάγραμμα δοκιμών για το σχεδιασμό, τη ρύθμιση και την εκτέλεση των δεδομένων.
  • Οι δοκιμές παρτίδων και οι διαδικτυακές δοκιμές θα πρέπει να γίνονται αποτελεσματικά χωρίς να λείπει καμία λειτουργικότητα που αναφέρεται στο έγγραφο Απαιτήσεων και όχι Δοκιμαστική θήκη πρέπει να γλιτώσει.

Μπορεί να σας αρέσει: