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

Πριν μάθουμε τις έννοιες των δοκιμών σε Mainframe, ας δούμε πρώτα την πλατφόρμα στην οποία εκτελούνται οι δοκιμές.

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

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

Δοκιμή Mainframe

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

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

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

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

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

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

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

Αυτά τα χαρακτηριστικά χωρίζουν την εργασία χειροκίνητων δοκιμών στο mainframe σε δύο σαφώς διαχωρισμένες ροές.

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

1. Δοκιμή μαζικής εργασίας —

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

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

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

Πώς να κάνετε δοκιμές σε mainframe

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

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

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

• REXX — η γλώσσα scripting που συνοδεύει το z/OS, η οποία χρησιμοποιείται ευρέως για την προώθηση επαναλαμβανόμενων υποβολών εργασιών και ελέγχων εξόδου.
• Excel — χρησιμοποιείται με μακροεντολές για τη δημιουργία, τη σύγκριση και την αναφορά δεδομένων δοκιμών και αρχείων εξόδου.
• OpenText UFT Ένας — το τρέχον όνομα του εργαλείου που εξακολουθεί να αποκαλεί η βιομηχανία QTP ή QuickTest Professional· αυτοματοποιεί 3270 οθόνες τερματικού.
• Γαλάσα — ένα λογισμικό ανοιχτού κώδικα, Πλαίσιο δοκιμών βαθιάς ενσωμάτωσης Open Mainframe Project που οδηγεί 3270 οθόνες, εργασίες δέσμης JCL και Db2 από μια διοχέτευση CI/CD.
• Σουίτες δοκιμών z/OS προμηθευτών - IBM Το Test Accelerator για Z και BMC AMI DevX Total Test καλύπτει δοκιμές μονάδων COBOL και εικονικά περιβάλλοντα δοκιμών.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Θα πρέπει να διενεργούνται διπλές δοκιμές ασφαλείας στο σύστημα — ασφάλεια mainframe και ασφάλεια δικτύου.

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

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

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

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

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

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

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

Αναφορά δοκιμών — Ένα ελάττωμα θα πρέπει να καταγράφεται εάν το πραγματικό αποτέλεσμα αποκλίνει από το αναμενόμενο.

Βήματα που εμπλέκονται στο Online — Δοκιμή Ολοκλήρωσης Μαζικής Ενοποίησης

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

Εντολές που χρησιμοποιούνται σε δοκιμές κεντρικών υπολογιστών

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

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

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

Προϋποθέσεις για την έναρξη δοκιμών σε κεντρικούς υπολογιστές

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

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

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

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

καλυτερα Practices

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

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

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

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

Συνήθεις ατέλειες που συναντήθηκαν

Όταν μια εργασία αποτύχει, η ουρά ανακοινώνει έναν κωδικό abend. Η παρακάτω λίστα καλύπτει τους κωδικούς που συναντά πιο συχνά ένας δοκιμαστής mainframe, μαζί με τη συνήθη αιτία.

1. S001 — Παρουσιάστηκε σφάλμα εισόδου/εξόδου.

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

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

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

3. S004 — Παρουσιάστηκε σφάλμα κατά το ΑΝΟΙΓΜΑ.

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

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

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

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

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

6. S0C4 — Εξαίρεση προστασίας / παραβίαση χώρου αποθήκευσης.

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

7. S0C7 — Εξαίρεση ελέγχου προγράμματος, δεδομένα.

   Αιτία — Αλλαγή στη διάταξη της εγγραφής ή του αρχείου.

8. Sx22 — Η εργασία ακυρώθηκε.

   Αιτία — Η εργασία τερματίστηκε πριν από την ολοκλήρωσή της. Το μεσαίο ψηφίο προσδιορίζει ποιος ή τι την ακύρωσε.

9. S222 — Η εργασία ακυρώθηκε από τον χρήστη χωρίς dump.
10. S322 — Ο χρόνος εργασίας ή βήματος υπερέβη το καθορισμένο όριο ή το πρόγραμμα βρίσκεται σε βρόχο ή η παράμετρος TIME δεν επαρκεί.
11. S522 — Χρονικό όριο συνεδρίας TSO.
12. S806 — Δεν είναι δυνατή η σύνδεση ή η φόρτωση.

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

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

Βοήθεια σφαλμάτων — Ένα πολύ δημοφιλές εργαλείο για να λαμβάνετε λεπτομερείς πληροφορίες σχετικά με διάφορους τύπους abends.

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

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

Συχνές Ερωτήσεις