Δοκιμή Mainframe - Πλήρες σεμινάριο

Πίνακας περιεχομένων:

Anonim

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

Τι είναι το Mainframe;

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

Δοκιμή βασικού πλαισίου

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

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

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

Σε αυτό το σεμινάριο για αρχάριους, θα μάθετε-

  • Χαρακτηριστικά mainframe
  • Ταξινόμηση μη αυτόματων δοκιμών στο Mainframe
  • Πώς να κάνετε το Mainframe Testing
  • Εργαλεία δοκιμών αυτοματισμού Mainframe
  • Μεθοδολογία στη δοκιμή Mainframe
  • Βήματα που εμπλέκονται στη δοκιμή παρτίδας
  • Βήματα που εμπλέκονται στη διαδικτυακή δοκιμή
  • Βήματα που εμπλέκονται στο Διαδίκτυο - Batch Integration testing
  • Εντολές που χρησιμοποιούνται στη δοκιμή Mainframe
  • Προαπαιτούμενα για να ξεκινήσετε τη δοκιμή mainframe
  • Βέλτιστες πρακτικές
  • Δοκιμή βασικού πλαισίου Προκλήσεις και αντιμετώπιση προβλημάτων
  • Παρουσιάστηκαν κοινές Abends
  • Συνηθισμένο πρόβλημα που αντιμετωπίστηκε κατά τη δοκιμή 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. Η επεξεργασία μεριδίου χρόνου είναι γνωστή ως "Foreground Processing" και η batch job processing είναι γνωστή ως "Background Processing".
  5. Πηνία
    1. Το SPOOLing σημαίνει ταυτόχρονες περιφερειακές λειτουργίες στο διαδίκτυο .
    2. Η συσκευή SPOOL χρησιμοποιείται για την αποθήκευση της εξόδου προγράμματος / εφαρμογής. Η εξουδετερωμένη έξοδος κατευθύνεται σε συσκευές εξόδου όπως ένας εκτυπωτής (εάν απαιτείται).
    3. Είναι μια εγκατάσταση που εκμεταλλεύεται το πλεονέκτημα της προσωρινής αποθήκευσης για αποτελεσματική χρήση των συσκευών εξόδου.

Ταξινόμηση μη αυτόματων δοκιμών στο Mainframe

Το Mainframe Manual Testing μπορεί να ταξινομηθεί σε δύο τύπους:

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

Πώς να κάνετε το Mainframe Testing

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

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

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

  • REXX
  • Προέχω
  • QTP

Μεθοδολογία στη δοκιμή Mainframe

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

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

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

Βήμα 1) : Δοκιμή Shakedown / Smoke

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

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

Ακολουθούν οι τύποι δοκιμών που πραγματοποιούνται στο πλαίσιο της δοκιμής συστήματος.

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

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

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

Βήμα 3) : Δοκιμή ενοποίησης συστήματος

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

Αυτά τα συστήματα δεν επηρεάζονται άμεσα από τις απαιτήσεις. Ωστόσο, χρησιμοποιούν δεδομένα από το υπό δοκιμή σύστημα. Είναι σημαντικό να δοκιμάσετε τη διεπαφή και τους διαφορετικούς τύπους μηνυμάτων (όπως Job Successful, Job Failed, Database updated, etc.) που μπορούν να κάνουν πιθανή ροή μεταξύ των συστημάτων και των ενεργειών που προκύπτουν από τα μεμονωμένα συστήματα.

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

  1. Μαζική δοκιμή
  2. Διαδικτυακές δοκιμές
  3. Online - Δοκιμές ολοκλήρωσης παρτίδων

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Βήματα που εμπλέκονται στο Διαδίκτυο - Batch Integration testing

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

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

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

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

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

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

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

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

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

Βέλτιστες πρακτικές

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

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

Προκλήσεις Πλησιάζω
Ατελείς / Ασαφείς Απαιτήσεις Μπορεί να υπάρχει πρόσβαση στο εγχειρίδιο χρήστη / οδηγός εκπαίδευσης, αλλά αυτές δεν είναι ίδιες με τις τεκμηριωμένες απαιτήσεις. Οι δοκιμαστές πρέπει να συμμετέχουν στο SDLC από τη φάση απαιτήσεων και μετά. Αυτό θα σας βοηθήσει να επαληθεύσετε εάν οι απαιτήσεις είναι ελεγχόμενες.
Ρύθμιση δεδομένων / Ταυτοποίηση Μπορεί να υπάρχουν καταστάσεις όπου τα υπάρχοντα δεδομένα πρέπει να επαναχρησιμοποιηθούν σύμφωνα με την απαίτηση. Μερικές φορές είναι δύσκολο να προσδιοριστούν τα απαιτούμενα δεδομένα από τα υπάρχοντα δεδομένα. Για τη ρύθμιση δεδομένων, τα οικιακά εργαλεία μπορούν να χρησιμοποιηθούν ανάλογα με τις ανάγκες. Για τη λήψη υπαρχόντων δεδομένων, τα ερωτήματα πρέπει να δημιουργηθούν εκ των προτέρων. Σε περίπτωση δυσκολίας, μπορεί να υποβληθεί αίτημα στην ομάδα διαχείρισης δεδομένων για τη δημιουργία ή κλωνοποίηση απαιτούμενων δεδομένων.
Ρύθμιση εργασίας Μόλις οι εργασίες ανακτηθούν σε PDS, η εργασία πρέπει να ρυθμιστεί στην περιοχή QA. Για να μην υποβληθούν οι εργασίες με προσδιοριστικό παραγωγής ή λεπτομέρεια διαδρομής. Τα εργαλεία ρύθμισης εργασίας πρέπει να χρησιμοποιούνται για να ξεπεραστούν τα ανθρώπινα λάθη που έγιναν κατά την εγκατάσταση.
Αίτημα ad-hoc Ενδέχεται να υπάρχουν καταστάσεις κατά τις οποίες πρέπει να υποστηρίζεται δοκιμή από άκρο σε άκρο λόγω προβλήματος σε προβλήματα εφαρμογών ανάντη ή κατάντη. Αυτά τα αιτήματα αυξάνουν το χρόνο και την προσπάθεια στον κύκλο εκτέλεσης. Η χρήση σεναρίων αυτοματισμού, σεναρίων παλινδρόμησης και σεναρίων σκελετού θα μπορούσε να βοηθήσει στη μείωση του χρόνου και της προσπάθειας.
Έγκαιρες εκδόσεις για αλλαγή πεδίου Μπορεί να υπάρχει μια κατάσταση όπου ο αντίκτυπος του κώδικα μπορεί να αλλάξει εντελώς την εμφάνιση και την αίσθηση του συστήματος. Αυτό μπορεί να απαιτεί αλλαγή στις δοκιμαστικές περιπτώσεις, σενάρια και δεδομένα. Η διαδικασία διαχείρισης αλλαγών πεδίου και η ανάλυση αντικτύπου πρέπει να είναι σε ισχύ.

Παρουσιάστηκαν κοινές Abends

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

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

  2. S002 - Μη έγκυρη εγγραφή εισόδου / εξόδου.

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

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

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

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

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

  5. S0C1 - Εξαίρεση λειτουργίας

    Λόγος - Δεν είναι δυνατό το άνοιγμα του αρχείου, λείπει κάρτα DD

  6. S0C4 - Εξαίρεση προστασίας / Παραβίαση αποθήκευσης
  7. Αιτιολογία - Η προσπάθεια αποθήκευσης πρόσβασης δεν είναι διαθέσιμη στο πρόγραμμα.
  8. SC07 - Εξαίρεση ελέγχου προγράμματος - Δεδομένα
  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 - Για επιτυχή ολοκλήρωση της εργασίας, θα πρέπει να ελέγξετε τα δεδομένα, το αρχείο εισαγωγής και τις ενότητες που υπάρχουν στη συγκεκριμένη τοποθεσία ή όχι. Το Abends μπορεί να αντιμετωπιστεί για πολλούς λόγους, τα πιο συνηθισμένα είναι - Μη έγκυρα δεδομένα, εσφαλμένο πεδίο εισαγωγής, αναντιστοιχία ημερομηνίας, περιβαλλοντικά ζητήματα κ.λπ.
  • Το αρχείο εξόδου είναι κενό - Αν και η εργασία μπορεί να εκτελεστεί με επιτυχία (MaxCC 0), η έξοδος ενδέχεται να μην είναι όπως αναμενόταν. Επομένως, πριν περάσει οποιαδήποτε δοκιμαστική θήκη, ο ελεγκτής πρέπει να βεβαιωθεί ότι η έξοδος έχει επαληθευτεί. Μόνο τότε προχωρήστε περαιτέρω.
  • Κενό αρχείο εισαγωγής - Σε ορισμένες εφαρμογές, τα αρχεία θα ληφθούν από τις διεργασίες ανάντη. Πριν από τη χρήση του ληφθέντος αρχείου για τη δοκιμή της τρέχουσας εφαρμογής, τα δεδομένα πρέπει να επαληθευτούν διασταυρωμένα για να αποφευχθεί η εκ νέου εκτέλεση και η επανεπεξεργασία.

Περίληψη:

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