Mobile Enterprise -sovellusten testaaminen SAP: lle

(Alexander Ilg) (11. marraskuuta) , 2020)

Testaus on tärkeä osa jokaista ohjelmistokehitysprojektia – yksikkötestejä, integraatiotestejä, käyttäjien hyväksyntätestejä ja niin edelleen. Tässä blogissa haluan keskustella mobiiliyrityssovellusten testaamisesta, etenkin offline-käyttöä varten.

Mikään ohjelmisto ei ole täydellinen. Raketit lähetetään Marsille ja ne kaatuvat vikojen takia. Jotkut lentokoneet sammuvat, jos niitä ei ”käynnistetä uudelleen” ainakin 248 päivän välein (ja kysyt minulta, miksi pelkään lentämistä). div id = ”87e5789842”>

Pelkäätkö lentämistä? Älä katso lentokoneohjelmiston virheraportteja!

Luetteloa voidaan jatkaa ja jatkuu, on jopa Wikipedia-artikkeli, jossa on esimerkkejä virheistä kaikissa alueet – https://fi.wikipedia.org/wiki/List\_of\_software\_bugs .

Virheen löytäminen ja korjaaminen yhdessä keskeisessä paikassa kuten SAP-järjestelmä voi jo olla tuskaa (järjestelmän uudelleenkäynnistys, seisokit, onnettomat käyttäjät, kadonneet tiedot jne.). Virheen korjaaminen moniin tietokoneisiin asennetussa sovelluksessa (kuten esimerkiksi SAP-käyttöliittymä) on hieman hankalampaa, mutta silti hallittavissa, jos kaikki koneet ovat sisäisiä ja yhteydessä yritysverkkoon.

Se saa paljon aikaan älypuhelimille ja tableteille asennetun uuden yrityksen offline-sovelluksen version toimittaminen yrityksen toimiston ulkopuolelle on vaikeampaa. Vaikka sinulla olisi laitehallintaratkaisu, kuten Idaptive, SAP Mobile Secure, Mobile Iron tai Airwatch, se on silti paljon työtä. Jos käyttäjien verkkoyhteys on huono, uusien versioiden jakaminen on vaikeaa. Vielä pahempaa, jos mobiilisovelluksen ja palvelinpuolen ohjelmiston välillä on riippuvuuksia – siinä tapauksessa molemmat on päivitettävä samanaikaisesti, mikä voi olla todella hankalaa, jos käyttäjäkunta on useilla aikavyöhykkeillä ja jaettu ympäri maailmaa. Tämän vuoksi on tärkeää testata mobiiliyrityssovelluksia erittäin huolellisesti. Ei ole väliä mitä alustaa käytät – Agentry, SMP, SCP Mobile Services, MobiLink tai jokin muu. Testaus on suoritettava kaikille tasoille, mukaan lukien asiakas, väliohjelmisto ja backend. Seuraava on luettelo testeistä, jotka tulisi suorittaa jokaiselle sovellukselle.

Toiminnalliset testit

  • Kaikkien toimintojen testaus molempiin suuntiin – luo tietoja SAP: iin ja synkronoi ne mobiililaitteeseen. Luo tietoja mobiililaitteesta ja lähetä se SAP: lle. Päivitä molempien sivujen tietueet, poista tiedot ja tarkista, että ne on poistettu myös vastakkaisesta järjestelmästä.
  • Testaa vahvistus mobiililaitteella – saako käyttäjä oikean varoitus- / virheilmoituksen syöttäessään vääriä tietoja ?

Suorituskykytestit – synkronointi ja laitteella

  • Synkronoi odotetun suurimman tietomäärän kanssa. Ota myös huomioon, että datamäärä voi kasvaa ajan myötä.
  • Testaa mahdollisimman monella samanaikaisella laitteella, jotta näet, miten järjestelmä pystyy käsittelemään kuormaa.
  • Testaa laitetta enimmäismäärä tietoja – miten luettelot ja yksityiskohtaiset valintaikkunat toimivat? Kuinka sujuva navigointi sovelluksessa on? Kuinka nopea käynnistysaika on? Testaus simulaattorilla / emulaattorilla ei ole koskaan tarpeeksi hyvä, sinun on testattava se todellisella laitteella, jota käyttäjä pitää myöhemmin käsissään!

Testaa käyttäjän käyttöliittymän / käyttöjärjestelmän ohjeiden mukaisesti mobiilikäyttöjärjestelmä

  • Jos sinulla on natiivisovellus, noudattaako se Applen, Googlen ja Microsoftin UX-ohjeita?
  • Jos sinulla on hybridistä / alustasta riippumaton sovellus noudattaako se yleisiä ohjeita (esimerkiksi SAP Fiori UX -opas)?

Käytettävyystestit

  • Anna sovellus käyttäjille ja anna heidän testata sitä. Onko se intuitiivinen? Voivatko he selvittää, kuinka sitä käytetään myös ilman pieniä asiakirjoja tai vain vähän asiakirjoja?
  • Testaa ratkaisusi älypuhelimien / tablettien kanssa kokeneiden käyttäjien ja niiden kanssa, jotka eivät ole tottuneet nykyaikaiseen tekniikkaan.
  • Jos otat tuotteen käyttöön kansainvälisesti, testaa eri maiden käyttäjien kanssa, miten he reagoivat ohjelmistoon.
  • Testaa eri kielillä ja sijaintiasetuksilla varmistaaksesi, että kaikki näytetään oikein
  • Anna käännöksen tarkistaa ja testata äidinkielenään puhuva
  • Kuuntele testikäyttäjiäsi! Tämä on ylivoimaisesti paras palaute, jonka saat!

Testaa verhon takana – paitsi käyttöliittymä, myös väliohjelmisto- ja backend-integraatio

  • Testaa asiakas, väliohjelmisto (jos sinulla on) ja backend. Kaikkien on toimittava hyvin yhdessä.
  • Varmista, että kolmen komponentin välinen viestintä toimii hyvin.

Testaa positiiviset ja negatiiviset tapaukset

  • Testaa ratkaisusi datalla ja testaa tapauksia, joiden olet todennäköisesti toimivan
  • Testaa ratkaisusi datalla, jonka olet todennäköisesti epäonnistuvan.Me kaikki tiedämme, että käyttäjät syöttävät odottamattomimmat tiedot, ja sinun on varmistettava, että sovellus ei kaatu tällaisessa tilanteessa.
  • Varmista, että molemmat tapaukset käsitellään onnistuneesti
  • Testaa sovellusta, kun väliohjelmistopalvelin on poissa käytöstä. Toimiiko se odotetusti? Testaa se, kun myös SAP ei ole käytettävissä.
  • Kova tappaa sovelluksen keskellä tallennus- tai synkronointiprosessia. Toimiiko se edelleen? Hävitkö tietoja?

Kuulostaa tutulta?

Testaa laboratorion ulkopuolella / todellisen verkon avulla

  • Testaa sovelluksesi aidolla verkossa, jota käyttäjät käyttävät myöhemmin. Onko suorituskyky silti tarpeeksi hyvä GPRS: n tai Edgen kanssa? Onko suorituskyky hyväksyttävä syrjäisissä paikoissa?
  • Testaa ohjelmisto oikealla laitteella, ei pelkästään simulaattorilla. Näkyykö kaikki niin kuin sen pitäisi olla? Onko suorituskyky odotettua?
  • Testaa ohjelmisto todellisella laitteella todellisissa olosuhteissa. Voitteko lukea näyttöä kirkkaassa auringonvalossa? Toimiiko laite ulkona kuumuudessa tai kylmässä?
  • Testaa ratkaisu kaikkien muiden asennettujen sovellusten kanssa – onko sivuvaikutuksia? Androidin ja iOS: n hiekkalaatikkofilosofian pitäisi toimia, mutta kokeile sitä paremmin.
  • Testaa sitä vähän muistia koskevissa tilanteissa – toimiiko sovellus edelleen? Kuinka suorituskyky tässä tapauksessa on? Mitä tapahtuu, jos sovellus poistetaan muistista?
  • Testaa sovellusta vanhemmilla käyttöjärjestelmän versioilla. Testaa sitä myös tulevaisuudessa julkaistavilla beetaversioilla!
Voitteko työskennellä hyväksyttävällä nopeudella keskellä ei mitään?

Kirjoita automaattisia testiskriptejä

Anna kehittäjien luoda automaattisia testitapauksia, jotka voidaan suorittaa ennen jokaista rakennusta. Tämän tekeminen voi vähentää testin vaivaa ja saada jo ensimmäiset virheet ennen kuin todelliset testaajat aloittavat toimintansa. Automaattiset yksikötestit eivät kuitenkaan koskaan voi korvata ”oikeita” testejä, vaan täydentää niitä.

Testaa eri laitteilla

Jos sinulla on BYOD-strategia (tuo oma laite), yritä testata sovelluksen eri laitteilla. Toimiiko sovellus kaikilla näytön tarkkuuksilla? Jos se on alustasta riippumaton, toimiiko se kaikilla alustoilla?

Testaa asennus / päivitys

Testaa mobiilisovelluksesi asennus ja päivitys. Voiko APK: n, IPA: n tai XAP: n ladata puhelinkytkennän kautta?

Testaa sovelluksen turvallisuus

  • Selvitä verkkoselaimella, onko kytkemäsi salaus on aktiivinen.
  • Yritä avata laitetietokanta nähdäksesi, onko se todella salattu.
  • Testaa suojattu tallennustila, kuten esimerkiksi iOS-avaimenperä – onko nämä tiedot vain paikallisia vai ovatko ne lähetetäänkö pilveen?

Testaa sovelluksen hallinto-osa

  • Voitko luoda uusia käyttäjiä, laitteita jne. mobiilimaisemallesi?
  • Voitko poistaa rekisteröinnin / poistaa laitteita?
  • Ovatko lokit asetettu oikein? Onko heillä tarpeeksi tietoa ongelmien analysoimiseksi? Onko se asetettu tarpeeksi matalalle, jotta loki ei heikennä suorituskykyä?

Riippumatta siitä, kuinka kauan ja hyvin testaat, virheitä livahtaa halkeamien läpi. Mitä monimutkaisempi sovellus on, sitä todennäköisemmin se tapahtuu. Tämän vuoksi sinulla on aina oltava vararatkaisu – tämä voi olla joko Excel-arkki tai vain pala paperia. Ihannetapauksessa sinun ei tarvitse koskaan käyttää sitä.

Testaus on kuuma aihe – kuinka paljon testausta riittää? Kuinka paljon on liikaa? Voit väittää, ettei koskaan voi testata tarpeeksi, mutta jonkun on maksettava siitä. Kuten kaikessa, myös sinun on löydettävä oikea tasapaino.

Onnea testauksessa! Ja jos sinulla on kysyttävää tai tarvitset apua testauksessa, ota yhteyttä minuun osoitteessa [email protected] .

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *