Mobilvállalati alkalmazások tesztelése SAP-hoz

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

A tesztelés minden szoftverfejlesztési projekt fontos része – egységtesztek, integrációs tesztek, felhasználói elfogadási tesztek és így tovább. Ebben a blogban a mobil vállalati alkalmazások tesztelését szeretném megvitatni, különösen az offline használatra szánt alkalmazásokat.

Egyetlen szoftver sem tökéletes. Rakétákat küldenek a Marsra, és a hibák miatt lezuhannak. Néhány repülőgép leáll, ha legalább 248 naponta nem “indítják újra” őket (és azt kérdezi tőlem, miért félek a repüléstől). div id = “87e5789842”>

Tart a repüléstől? Ne nézze meg a repülőgépes szoftver hibajelentéseit!

A lista folytatódik, sőt van egy Wikipedia-cikk is, amely példákat mutat be a hibákra területek – https://hu.wikipedia.org/wiki/List\_of\_software\_bugs .

Hibának egy központi helyen történő javítása és javítása Az SAP rendszer már fájdalmat okozhat (a rendszer újraindítása, leállás, boldogtalan felhasználók, elveszett adatok stb.). A sok számítógépre telepített alkalmazás hibájának kijavítása (például az SAP GUI) kissé bonyolultabb, de mégis kezelhető, ha az összes gép házon belül van és csatlakozik a vállalati hálózathoz.

Sokat kap nehezebb a mobilvállalkozás offline alkalmazásának új verzióját szállítani, amelyet a vállalati irodán kívül telepítenek okostelefonokra és táblagépekre. Még akkor is, ha olyan eszközkezelési megoldása van, mint az Idaptive, az SAP Mobile Secure, a Mobile Iron vagy az Airwatch, mégis sok munka. Ha a felhasználók rossz hálózati kapcsolattal rendelkeznek, nehéz új verziókat terjeszteni. Még rosszabb, ha vannak függőségek a mobilalkalmazás és a szerveroldali szoftverek között – ebben az esetben mindkettőt egyszerre kell frissíteni, ami igazán bonyolult lehet, ha a felhasználói bázis több időzónában van, és az egész világon elosztva van. Emiatt fontos, hogy a mobil vállalati alkalmazásokat nagyon gondosan teszteljük. Nem számít, melyik platformot használja – Agentry, SMP, SCP Mobile Services, MobiLink vagy valami más. A tesztelést minden rétegen el kell végezni, beleértve az ügyfelet, a köztes szoftvert és a háttérprogramot is. Az alábbiakban felsoroljuk azokat a teszteket, amelyeket minden alkalmazásnál el kell végezni.

Funkcionális tesztek

  • Minden funkció tesztelése mindkét irányba – hozzon létre adatokat az SAP-ban, és szinkronizálja a következővel: a mobil eszköz. Hozzon létre adatokat a mobil eszközön, és küldje el az SAP-nak. Frissítse mindkét oldalon a rekordokat, törölje az adatokat, és ellenőrizze, hogy az ellentétes rendszeren is eltávolították-e azokat.
  • Tesztelje az érvényesítést a mobil eszközön – a felhasználó a megfelelő figyelmeztető / hibaüzenetet kapja-e, amikor rossz adatokat ír be ?

Teljesítménytesztek – szinkronizálás és eszközön

  • Szinkronizálás a várt maximális adatmennyiséggel. Vegye figyelembe azt is, hogy az adatmennyiség idővel növekedhet.
  • Tesztelje az egyidejű készülékek maximális számával, hogy lássa, hogyan képes a rendszer kezelni a terhelést.
  • Tesztelje az eszközt a maximális adatmennyiség – hogyan teljesít a listák és a részletek párbeszédpanelek Mennyire folyékony az alkalmazáson belüli navigáció? Mennyire gyors az indítási idő? A szimulátoron / emulátoron történő tesztelés soha nem elég jó, azt a valódi eszközön kell tesztelni, amelyet a felhasználó később a kezében fog tartani!

Tesztelje az UI / UX irányelvek alapján mobil operációs rendszer

  • Ha natív alkalmazásod van, akkor az Apple, a Google és a Microsoft UX irányelveit követi?
  • Ha hibrid / platformfüggetlen alkalmazásod van , követi-e a közös irányelveket (például az SAP Fiori UX útmutató)?

Használhatósági tesztek

  • Adja meg az alkalmazást a felhasználóknak, és hagyja, hogy teszteljék. Intuitív? Kitalálják, hogyan lehet használni még dokumentáció nélkül vagy csak kevés dokumentáció nélkül is?
  • Tesztelje megoldását okostelefonokkal / táblagépekkel tapasztalt felhasználókkal és olyanokkal, akik nem szoktak hozzá a modern technológiához.
  • Ha nemzetközileg indul, tesztelje a különböző országokbeli felhasználókkal, hogyan reagálnak a szoftverre.
  • Teszteljen különböző nyelvekkel és helybeállításokkal, hogy megbizonyosodjon róla, hogy minden helyesen jelenik meg
  • Hagyja, hogy a fordítást anyanyelvi beszélő vizsgálja felül és tesztelje.
  • Hallgassa meg a tesztfelhasználókat! Ez messze a legjobb visszajelzés, amelyet kaphat!

Tesztelje a függöny mögött – nem csak az UI, hanem a köztes és a backend integráció

  • köztes szoftver (ha van ilyen) és háttérprogram. Mindennek jól kell működnie.
  • Győződjön meg arról, hogy a három komponens közötti kommunikáció jól működik.

Tesztelje a pozitív és a negatív eseteket

  • Tesztelje megoldását olyan adatokkal és tesztelje az eseteket, amelyek várhatóan működni fognak
  • Tesztelje megoldását olyan adatokkal, amelyek várhatóan kudarcot vallanak.Mindannyian tudjuk, hogy a felhasználók a legváratlanabb információkat adják meg, és meg kell győződnie arról, hogy az alkalmazás nem összeomlik-e egy ilyen helyzetben.
  • Győződjön meg arról, hogy mindkét esetet sikeresen lefedik
  • Teszt az alkalmazás, amikor a köztes szoftver szerver leáll. Úgy viselkedik, mint várták? Tesztelje, ha az SAP sem érhető el.
  • Keményen megöli az alkalmazást egy mentési vagy szinkronizálási folyamat közepette. Még mindig működik? Elvesztette az adatait?

Ismerősen hangzik?

Tesztelje a laboratóriumon kívül / a valódi hálózattal

  • Tesztelje az alkalmazását azzal a valódi hálózattal, amelyet a felhasználók később használnak. A teljesítmény még mindig elég jó a GPRS vagy az Edge használatával? Elfogadható-e a teljesítmény távoli helyeken?
  • Tesztelje a szoftvert a valós eszközön, ne csak szimulátoron. Minden úgy jelenik meg, ahogy kell? Az elvárt teljesítmény?
  • Tesztelje a szoftvert a valós eszközzel, valós körülmények között. Elolvashatja a képernyőt erős napfényben? A készülék a szabadban működik melegben vagy hidegben?
  • Tesztelje a megoldást az összes többi telepített alkalmazással – vannak-e mellékhatások? Az Android és az iOS sandbox filozófiájával működnie kell, de jobb, ha teszteled.
  • Teszteld alacsony memóriahelyzetben – működik-e még az alkalmazás? Milyen a teljesítmény ebben az esetben? Mi történik, ha az alkalmazást eltávolítják a memóriából?
  • Tesztelje az alkalmazást az operációs rendszer régebbi verzióival. Ezenkívül tesztelje a jövőben megjelenő béta verziókkal is!
Dolgozhat elfogadható sebességgel a semmi közepén?

Automatizált tesztparancsok írása

Engedje meg a fejlesztőinek, hogy hozzon létre automatikus teszteseteket minden építkezés előtt futtatható. Ezzel csökkentheti a teszt erőfeszítéseit, és már az első hibákat elkapja, mielőtt az igazi tesztelők megkezdik tevékenységüket. Az automatizált egységtesztek azonban soha nem helyettesíthetik a „valódi” teszteket, csak kiegészíthetik azokat.

Tesztelés különböző eszközökön

Ha BYOD (hozd magaddal a saját eszközöd) stratégiát használd, próbáld meg tesztelni az alkalmazás különböző eszközökön. Az alkalmazás minden képernyőfelbontáson működik? Ha platformfüggetlen, akkor minden platformon működik?

Tesztelje a telepítést / frissítést

Tesztelje a mobilalkalmazás telepítését és frissítését. Letölthető az APK, az IPA vagy az XAP telefonkapcsolaton keresztül?

Tesztelje az alkalmazás biztonságát

  • Hálózati szippantóval ellenőrizze, hogy a bekapcsolt titkosítás aktív.
  • Próbálja meg megnyitni az eszközadatbázist, hogy megnézze, valóban titkosítva van-e.
  • Tesztelje a biztonságos tárhelyet, például az iOS kulcstartót – ezek az adatok csak lokálisak-e vagy sem elküldi a felhőbe?

Tesztelje az alkalmazás adminisztrációs részét

  • Létrehozhat-e új felhasználókat, eszközöket stb. a mobil táján?
  • Tudja törölni az eszközök regisztrációját / törlését?
  • Helyesen vannak beállítva a naplók? Van elegendő információ a problémák elemzéséhez? Elég alacsonyra van állítva, hogy a napló nem csökkenti a teljesítményt?

Nem számít, mennyi ideig és jól tesztel, hibákat lehet átcsúsztatni a repedéseken. Minél összetettebb az alkalmazás, annál valószínűbb, hogy ez megtörténik. Emiatt mindig rendelkeznie kell tartalék megoldással – ez lehet egy Excel lap vagy csak egy darab papír. Ideális esetben soha nem kell használnia.

A tesztelés kiemelt téma – mennyi tesztelés elegendő? Mennyi túl sok? Vitathatod, hogy az ember soha nem tud eleget tesztelni, azonban valakinek fizetnie kell érte. Mint mindenben, itt is meg kell találnia a megfelelő egyensúlyt.

Sok sikert a teszteléshez! Ha pedig kérdése van, vagy segítségre van szüksége a teszteléshez, vegye fel a kapcsolatot velem a [email protected] címen.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük