Μενού

Ένας απλός οδηγός για τη δοκιμή διαλειτουργικότητας (με παραδείγματα)

simple guide interoperability testing

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Πριν κατανοήσετε την τεχνική του 'Δοκιμή διαλειτουργικότητας' , Ας καταλάβουμε πρώτα τον όρο «Διαλειτουργικότητα».

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

Πολλές φορές η Διαλειτουργικότητα συγχέεται Ενσωμάτωση , συμβατότητα και φορητότητα. Λοιπόν, υπάρχουν διαφορές μεταξύ αυτών των τεχνικών.

Τι είναι ο έλεγχος διαλειτουργικότητας

Επιτρέψτε μου πρώτα να εξηγήσω τις διαφορές.

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

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

Η πρόθεση εδώ είναι να ελέγξουμε ότι τα δύο συστήματα εκτελούν τις αναμενόμενες εργασίες τους, χωρίς να παρεμβαίνουν το ένα στο άλλο, στο ίδιο περιβάλλον. Like - MS Word και Calculator είναι 2 διαφορετικές εφαρμογές και εκτελούν την αναμενόμενη συμπεριφορά τους ανεξάρτητα στο ίδιο λειτουργικό σύστημα. Λέμε λοιπόν ότι αυτές οι 2 εφαρμογές είναι συμβατές μεταξύ τους.

Φορητότητα - Είναι μια τεχνική όταν μια εφαρμογή ή ένα σύστημα συμπεριφέρεται όπως αναμένεται όταν μεταφέρεται σε άλλο περιβάλλον. Έτσι μέσα Φορητότητα δοκιμές, εξάγουμε την εφαρμογή σε κάποιο άλλο περιβάλλον και δοκιμάζουμε τη συμπεριφορά της. Όπως, εάν υπάρχει μια εφαρμογή που λειτουργεί καλά στα Windows XP, θα πρέπει επίσης να λειτουργεί καλά στα Windows 10.

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

Αυτό το συγκεκριμένο έγγραφο επικεντρώνεται στη δοκιμή διαλειτουργικότητας (IOT), οπότε ας διατηρήσουμε την εστίασή μας στη διαλειτουργικότητα. :)

Τι θα μάθετε:

Δοκιμή διαλειτουργικότητας - Μια σύντομη εισαγωγή

Διαλειτουργικότητα = Inter + λειτουργικό

μεταξύ - σημαίνει «μεταξύ μας», «ο ένας στον άλλο», «αμοιβαίος»

Εγχειρήσιμος - σημαίνει «ικανός να εκτελεί τη δεδομένη εργασία»

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

Παράδειγμα # 1:Πάρτε ένα παράδειγμα κράτησης της πτήσης σας. Σκεφτείτε ότι πρέπει να ταξιδέψετε από το Νέο Δελχί στη Νέα Υόρκη. Τώρα δεν έχετε απευθείας πτήση. Πρέπει να ταξιδέψετε από το Νέο Δελχί στο Λονδίνο και μετά να πάρετε πτήσεις με ανταπόκριση από το Λονδίνο προς τη Νέα Υόρκη. Επειδή έχετε κάποιους χρονικούς περιορισμούς, κάνετε κράτηση της πτήσης σας από το Νέο Δελχί προς το Λονδίνο στις αεροπορικές εταιρείες 'Jet Airways' και από το Λονδίνο προς τη Νέα Υόρκη στο 'Virgin Atlantic'. Αυτό σημαίνει ότι όλες οι λεπτομέρειες των επιβατών σας διασχίστηκαν από την Jet Airways στην Virgin Atlantic. Εδώ λοιπόν, η Jet Airways και η Virgin Atlantic, είναι και οι δύο ανεξάρτητη εφαρμογή μαζί και κατά την κράτηση της πτήσης σας, τα στοιχεία της κράτησής σας ανταλλάχθηκαν από την Jet Airways στην Virgin Atlantic με νόημα με πλήρη τρόπο, χωρίς προηγούμενη εκδήλωση.

Παράδειγμα # 2:Σε παρόμοιες γραμμές, σκεφτείτε το σύστημα διαχείρισης του νοσοκομείου, όπου τα αρχεία των ασθενών ανταλλάσσονται μεταξύ 1 τμήματος σε άλλο τμήμα. Έτσι εδώ το τμήμα μπορεί να συνδεθεί με μια εφαρμογή. Οι λεπτομέρειες του ασθενούς ανταλλάσσονται μεταξύ 1 αίτησης σε άλλη εφαρμογή χωρίς προηγούμενη ειδοποίηση.

Γιατί λοιπόν πρέπει να κάνουμε το IOT;

Θα πρέπει να κάνουμε τον έλεγχο διαλειτουργικότητας για να το διασφαλίσουμε

  • Οι εφαρμογές στο δίκτυο εκτελούν την αναμενόμενη συμπεριφορά τους ανεξάρτητα,
  • Μπορεί να ανταλλάσσει πληροφορίες χωρίς προηγούμενη ειδοποίηση
  • Οι πληροφορίες / δεδομένα ανταλλάσσονται χωρίς να διακόπτεται η μεμονωμένη αναμενόμενη συμπεριφορά
  • Τα δεδομένα / πληροφορίες που ανταλλάσσονται δεν τροποποιούνται ούτε τροποποιούνται

Πώς να κάνετε δοκιμές διαλειτουργικότητας;

Μπορούμε να ακολουθήσουμε τον τροχό Deeming (τον κύκλο PDCA) για να πραγματοποιήσουμε τον έλεγχο διαλειτουργικότητας.

# 1) Σχέδιο

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

Πρέπει να γνωρίζουμε για όλες τις εφαρμογές - τη λειτουργικότητα, τη συμπεριφορά, την εισαγωγή που λαμβάνει και την έξοδο που αποκαλύπτει.

Θα συνιστούσα επίσης ότι κάθε εφαρμογή έχει δοκιμαστεί πλήρως λειτουργικά χωρίς ελαττώματα, πριν την προετοιμάσετε για τον έλεγχο διαλειτουργικότητας. Έτσι, όταν σχεδιάζετε, μην σκέφτεστε απλώς 1 ή 2 εφαρμογή, σκεφτείτε όλη την εφαρμογή ως μία ενότητα. Πρέπει να έχετε μια πανοραμική θέα όταν σχεδιάζετε αυτήν την τεχνική δοκιμών. Περιττό να το πω αυτό - τεκμηριώστε το σχέδιό σας.

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

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

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

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

# 2) Κάνε

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

# 3) Ελέγξτε

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

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

# 4) Πράξη

Πράξη - Είναι να ενεργήσει στα αναδρομικά στοιχεία. Τα σημεία που προσδιορίστηκαν ως «καλές πρακτικές», συνεχίζουν να εκτελούν αυτά και τα σημεία που θα μπορούσαν να λειτουργήσουν καλύτερα, προσδιορίζουν τα βήματα για να τα διορθώσουν και να ενεργήσουν ανάλογα. Έχετε κατά νου 1 ότι οι περιοχές ή τα βήματα που δεν λειτούργησαν καλά, ΔΕΝ πρέπει να επαναλαμβάνονται. Μετά από όλα, πρέπει να μάθουμε από τα λάθη μας και να μην τα επαναλάβουμε.

Τα βήματα 5::

  1. Προσδιορίστε όλες τις εφαρμογές που αποτελούν μέρος του δικτύου.
  2. Προσδιορίστε τις αντίστοιχες λειτουργίες τους.
  3. Για κάθε εφαρμογή, προσδιορίστε την είσοδο που παίρνει και την έξοδο που επιστρέφει.
  4. Προσδιορίστε εκείνα τα δεδομένα που θα διασχίζουν όλες / τις περισσότερες εφαρμογές.
  5. Προσδιορίστε την αναμενόμενη συμπεριφορά για κάθε συνδυασμό εφαρμογής και ημερομηνίας που πρέπει να επικυρωθεί

½ Τεκμηριώστε το.

καλύτερη δωρεάν αφαίρεση ιών και κακόβουλων προγραμμάτων

Εξετάστε το παρακάτω σχήμα:

5 ½ βήματα

Με βάση το σχήμα, ας προσπαθήσουμε να επαναλάβουμε τα 5 βήματα:

  1. Η εφαρμογή 1, η εφαρμογή 2, η εφαρμογή 3 και η εφαρμογή 4 είναι 4 διαφορετικά συστήματα.
  2. Κάθε ένα από αυτά τα συστήματα έχει το καθορισμένο σύνολο λειτουργιών που πρέπει να προσδιοριστούν.
  3. Η είσοδος και οι έξοδοι κάθε συστήματος πρέπει να προσδιοριστούν.
  4. Στην περίπτωση του Application1, αποδίδει 2 εξόδους. 1 έξοδος σχηματίζει την είσοδο της Εφαρμογής 3 και 1 εξόδους εξόδου της Εφαρμογής 2. Η έξοδος από την Εφαρμογή 2 σχηματίζει την είσοδο στην Εφαρμογή 3 και Εφαρμογή 4 και ούτω καθεξής.
  5. Ελέγχεται η εγκυρότητα για κάθε είσοδο και έξοδο. Το σημαντικότερο σημείο που πρέπει να ληφθεί υπόψη είναι ότι τα δεδομένα που διασχίζουν τη μορφή εισόδου και εξόδου δεν τροποποιούνται ΚΑΙ καλύπτεται όλη η εφαρμογή.

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

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

Ενα παράδειγμα:

Ας εξετάσουμε ένα παράδειγμα διεξαγωγής δοκιμών διαλειτουργικότητας για ένα «Σύστημα διαχείρισης νοσοκομείου»

Ένα νοσοκομείο αποτελείται από τα παρακάτω τμήματα και υπο-τμήματα.

Σύστημα διαχείρισης νοσοκομείων

Εδώ κάθε τμήμα είναι μια εφαρμογή από μόνη της. Κάθε τμήμα (εφαρμογή) έχει τη δική του υπο-ενότητα (ενότητες) και κάθε ενότητα έχει τις δικές του μονάδες.

Τώρα λοιπόν για να εξετάσετε το πεδίο εφαρμογής του IOT, ακολουθούν μερικές προϋποθέσεις δοκιμής:

  1. Ένας ασθενής που συναντήθηκε με τροχαίο ατύχημα (Τμήμα OPD - Ατύχημα), πρέπει να υποβληθεί σε χειρουργική επέμβαση ποδιών (ΩΡ - Γενική Χειρουργική), στη συνέχεια πρέπει να υποβληθεί σε φυσιοθεραπεία (τμήμα υποστήριξης - Φυσιοθεραπεία) και στη συνέχεια να πάρει έξοδο (Τμήμα υποστήριξης - Κλείσιμο)
  2. Ένα παιδί που έχει εισαχθεί σε κρίσιμη φροντίδα (Παιδιατρική - Κρίσιμη Φροντίδα) πρέπει να υποβληθεί σε χειρουργική επέμβαση (Παιδιατρική / ΩΡ - Γενική Χειρουργική) και στη συνέχεια να απολυθεί (Τμήμα Υποστήριξης - Κλείσιμο / PR)
  3. Ένας εξωτερικός ασθενής συμβουλεύεται έναν γενικό ιατρό (τμήμα OPD). παίρνει τα συνταγογραφούμενα φάρμακα (Τμήμα Υποστήριξης - Φαρμακείο) και περπατά μακριά.
  4. Μια μέλλουσα μητέρα έρχεται για τακτικούς ελέγχους (Γυναικολογικό τμήμα - Φροντίδα μητέρων και παιδιών), παίρνει το συνταγογραφούμενο φάρμακο (Τμήμα υποστήριξης - Φαρμακείο) και περπατά μακριά.
  5. Ένας οδοντικός ασθενής κάνει το ριζικό κανάλι (τμήμα οδοντιατρικής), παίρνει το συνταγογραφούμενο φάρμακο (τμήμα υποστήριξης - φαρμακείο) και περπατά μακριά.
  6. Ένας ασθενής έρχεται σε OPD (γενικός ιατρός), υποβάλλεται σε θεραπεία στο (τμήμα Μαιευτικής & Γυναικολογίας - Μαιευτήρες Υψηλού Κινδύνου) παίρνει το συνταγογραφούμενο φάρμακο (Τμήμα υποστήριξης - Φαρμακείο) και αποβάλλεται

Με αυτόν τον τρόπο εντοπίζουμε όλες τις συνθήκες δοκιμής. έχοντας υπόψη ότι το μεγαλύτερο μέρος του τμήματος πρέπει να καλυφθεί.

Μπορούμε να σχεδιάσουμε ένα RTM για να δείξουμε την κάλυψη ως:

RTM

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

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

Προκλήσεις:

  1. Δύσκολο να δοκιμάσετε όλη την εφαρμογή με όλες τις παραλλαγές και συνδυασμούς.
  2. Οι εφαρμογές αναπτύσσονται σε διαφορετικούς συνδυασμούς υλικού / λογισμικού και εγκαθίστανται σε διαφορετικά περιβάλλοντα, οπότε αν κάποιο από τα περιβάλλοντα είναι εκτός λειτουργίας, επηρεάζει τον έλεγχο.
  3. Λόγω των διαφορετικών λογισμικών και των περιβαλλόντων, ο καθορισμός της στρατηγικής δοκιμών και η εκτέλεση του είναι από μόνο του ένα μεγάλο έργο.
  4. Η τόνωση του περιβάλλοντος για τη διεξαγωγή της δοκιμής, είναι μια μεγάλη πρόκληση.
  5. Σε περίπτωση ελαττώματος, η ανάλυση Root Cause Analysis είναι μια μεγάλη πρόκληση.
  6. Επειδή οι εφαρμογές βρίσκονται σε δίκτυο, θα υπήρχαν στιγμές που το δίκτυο είναι εκτός λειτουργίας. Εξαιτίας αυτού, οι δοκιμές επηρεάζονται επίσης.

Πώς μπορώ να μετριάσω αυτές τις προκλήσεις;

1) Προσπαθήστε να χρησιμοποιήσετε τις τεχνικές δοκιμής εκ των προτέρων, όπως:

  • OATS (Τεχνική ορθογωνικής σειράς δοκιμών)
  • Διαγράμματα μεταβατικής κατάστασης,
  • Γραφήματα αιτίας και αποτελέσματος
  • Κατανομή ισοδυναμίας και ανάλυση οριακής τιμής.

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

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

3) ΣΧΕΔΙΟ - Χρησιμοποιήστε ιστορικά δεδομένα, προηγούμενες εμπειρίες, δεξιότητες της ομάδας, περιβαλλοντικούς παράγοντες για να προσδιορίσετε τη στρατηγική της δοκιμής. Όσο καλύτερο είναι το σχέδιό σας, τόσο καλύτερο θα ήταν η εκτέλεσή σας.

4) Ξεκινήστε να προετοιμάζετε το περιβάλλον πολύ πριν από την έναρξη της πραγματικής εκτέλεσης. Περιττό να πείτε - σχεδιάστε τα βήματά σας όταν προετοιμάζετε το περιβάλλον. Βεβαιωθείτε ότι το περιβάλλον σας είναι έτοιμο, έτοιμο και σε λειτουργία κατά την έναρξη της εκτέλεσης.

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

6) Όπως συζητήθηκε στο σημείο 2, Σχεδιάστε τη δραστηριότητά σας. Εάν πρόκειται για προγραμματισμένη διακοπή λειτουργίας, θα πρέπει να εξετάσετε αυτό το χρόνο διακοπής όταν προγραμματίζετε τη δοκιμή σας.

Δοκιμή διαλειτουργικότητας σε κινητά:

Στο Mobiles, κάνουμε δοκιμή διαλειτουργικότητας όποτε μια νέα εφαρμογή ( Εφαρμογή κινητού ξεκίνησε. Υπάρχουν πολλοί τομείς που πρέπει να λάβουμε υπόψη κατά τον προγραμματισμό αυτής της δοκιμής σε κινητές συσκευές:

  • Οι τύποι κινητών συσκευών που διατίθενται στην αγορά είναι τεράστιοι. Θα χρειαστεί να αναφέρετε όλους τους τύπους συσκευών που θα εξετάζατε για τη δοκιμή σας. Θα χρειαστεί να αντιστοιχίσετε έναν τύπο συσκευής μαζί με το λειτουργικό σύστημα που υποστηρίζει.
  • Όλα τα Mobile OS έχουν αναπτυχθεί σε διαφορετική γλώσσα προγραμματισμού. Ως εκ τούτου, η εφαρμογή πρέπει να δοκιμαστεί έναντι όλων των παραλλαγών του λειτουργικού συστήματος.
  • Κατανόηση των νομικών παραγόντων και των συμβάσεων που σχετίζονται με την περιοχή.
  • Το μέγεθος / ανάλυση διαφορετικών συσκευών είναι διαφορετικά.
  • Πρέπει επίσης να εξεταστεί ο αντίκτυπος στις ενσωματωμένες εφαρμογές για κινητά.

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

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

Συμπέρασμα:

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

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

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

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

Συνιστώμενη ανάγνωση

^