Testowanie mobilnych aplikacji korporacyjnych dla SAP

(Alexander Ilg) (11 listopada , 2020)

Testowanie jest ważną częścią każdego projektu tworzenia oprogramowania – testy jednostkowe, testy integracyjne, testy akceptacyjne użytkowników i tak dalej. Na tym blogu chcę omówić testowanie mobilnych aplikacji korporacyjnych, zwłaszcza tych do użytku offline.

Żadne oprogramowanie nie jest idealne. Rakiety są wysyłane na Marsa i rozbijają się z powodu błędów. Niektóre samoloty wyłączają się, jeśli nie są „restartowane” przynajmniej co 248 dni (i pytasz mnie, dlaczego boję się latać).

Boisz się latania? Nie patrz na raporty o błędach w oprogramowaniu samolotów!

Lista jest długa, jest nawet artykuł w Wikipedii, który pokazuje przykłady błędów we wszystkich obszary – https://en.wikipedia.org/wiki/List\_of\_software\_bugs .

Posiadanie i naprawianie błędu w jednym centralnym miejscu, np. System SAP może już być uciążliwy (restart systemu, przestój, niezadowoleni użytkownicy, utrata danych itp.). Naprawianie błędu w aplikacji zainstalowanej na wielu komputerach (jak na przykład SAP GUI) jest nieco trudniejsze, ale nadal możliwe do zarządzania, jeśli wszystkie komputery są w domu i podłączone do sieci korporacyjnej.

Robi się dużo trudniej jest dostarczyć nową wersję aplikacji mobilnej offline dla przedsiębiorstw, która jest instalowana na smartfonach i tabletach poza biurem firmy. Nawet jeśli masz rozwiązanie do zarządzania urządzeniami, takie jak Idaptive, SAP Mobile Secure, Mobile Iron lub Airwatch, nadal jest to dużo pracy. Jeśli użytkownicy mają złe połączenie sieciowe, trudno jest rozpowszechniać nowe wersje. Jeszcze gorzej, jeśli istnieją zależności między aplikacją mobilną a oprogramowaniem po stronie serwera – w takim przypadku oba muszą być aktualizowane w tym samym czasie, co może być naprawdę trudne, jeśli baza użytkowników znajduje się w wielu strefach czasowych i jest rozproszona na całym świecie. Z tego powodu ważne jest bardzo dokładne testowanie mobilnych aplikacji korporacyjnych. Nie ma znaczenia, z jakiej platformy korzystasz – Agentry, SMP, SCP Mobile Services, MobiLink czy coś innego. Testowanie należy przeprowadzić na wszystkich warstwach, w tym na kliencie, oprogramowaniu pośrednim i zapleczu. Poniżej znajduje się lista testów, które należy wykonać dla każdej aplikacji.

Testy funkcjonalne

  • Test wszystkich funkcjonalności w obu kierunkach – utwórz dane w SAP i zsynchronizuj je z urządzenie mobilne. Utwórz dane na urządzeniu mobilnym i wyślij je do SAP. Zaktualizuj rekordy po obu stronach, usuń dane i sprawdź, czy zostały usunięte również w przeciwnym systemie.
  • Przetestuj weryfikację na urządzeniu mobilnym – czy użytkownik otrzymuje właściwe ostrzeżenie / komunikat o błędzie podczas wprowadzania błędnych danych ?

Testy wydajności – synchronizacja i na urządzeniu

  • Synchronizuj z maksymalną ilością danych, jakiej oczekujesz. Weź również pod uwagę, że ilość danych może z czasem wzrosnąć.
  • Przetestuj z maksymalną liczbą jednoczesnych urządzeń, aby zobaczyć, jak system poradzi sobie z obciążeniem.
  • Przetestuj urządzenie za pomocą maksymalna ilość danych – jak wygląda wydajność list i szczegółowych okien dialogowych? Jak płynna jest nawigacja w aplikacji? Jak szybki jest czas uruchamiania? Testowanie na symulatorze / emulatorze nigdy nie jest wystarczająco dobre, musisz go przetestować na prawdziwym urządzeniu, które użytkownik będzie później trzymał w rękach!

Sprawdź zgodność z wytycznymi UI / UX w mobilny system operacyjny

  • Jeśli masz aplikację natywną, czy jest ona zgodna z wytycznymi UX firm Apple, Google i Microsoft?
  • Jeśli masz aplikację hybrydową / niezależną od platformy , czy postępuje zgodnie z typowymi wytycznymi (na przykład przewodnikiem SAP Fiori UX)?

Testy użyteczności

  • Przekaż aplikację użytkownikom i pozwól im ją przetestować. Czy to jest intuicyjne? Czy potrafią dowiedzieć się, jak go używać, nawet bez dokumentacji lub z niewielką ilością dokumentacji?
  • Przetestuj swoje rozwiązanie z użytkownikami posiadającymi doświadczenie w obsłudze smartfonów / tabletów oraz z tymi, którzy nie są przyzwyczajeni do nowoczesnych technologii.
  • Jeśli prowadzisz działalność międzynarodową, przetestuj z użytkownikami z różnych krajów, aby zobaczyć, jak reagują na oprogramowanie.
  • Przetestuj z różnymi językami i ustawieniami lokalizacji, aby upewnić się, że wszystko jest wyświetlane poprawnie.
  • Pozwól, aby tłumaczenie zostało przejrzane i przetestowane przez native speakera
  • Posłuchaj swoich testowych użytkowników! To zdecydowanie najlepsza opinia, jaką możesz uzyskać!

Testuj za kurtyną – nie tylko interfejs użytkownika, ale także integracja oprogramowania pośredniego i zaplecza

  • Testuj klienta, oprogramowanie pośredniczące (jeśli takie posiadasz) i zaplecze. Wszystko musi ze sobą dobrze współpracować.
  • Upewnij się, że komunikacja między trzema komponentami działa prawidłowo.

Przetestuj przypadki pozytywne i negatywne

  • Przetestuj swoje rozwiązanie, korzystając z danych i przypadków testowych, które według Ciebie będą działać
  • Przetestuj swoje rozwiązanie, korzystając z danych, które mogą się nie powieść.Wszyscy wiemy, że użytkownicy będą wprowadzać najbardziej nieoczekiwane informacje i musisz się upewnić, że aplikacja nie ulega awarii w takim scenariuszu.
  • Upewnij się, że oba przypadki są objęte pomyślnie.
  • Test aplikacji, gdy serwer oprogramowania pośredniego nie działa. Czy zachowuje się zgodnie z oczekiwaniami? Przetestuj, gdy SAP również nie jest dostępny.
  • Trudno zabić aplikację w środku procesu zapisywania lub synchronizacji. Czy to nadal działa? Czy zgubiłeś jakieś dane?

Brzmi znajomo?

Testuj poza laboratorium / z rzeczywistą siecią

  • Przetestuj swoją aplikację w prawdziwej sieci, z której Twoi użytkownicy będą korzystać później. Czy wydajność jest nadal wystarczająco dobra z GPRS lub Edge? Czy wydajność jest akceptowalna w odległych lokalizacjach?
  • Przetestuj oprogramowanie na prawdziwym urządzeniu, a nie tylko na symulatorze. Czy wszystko jest wyświetlane tak, jak powinno? Czy wydajność jest zgodna z oczekiwaniami?
  • Przetestuj oprogramowanie na prawdziwym urządzeniu w rzeczywistych warunkach. Czy potrafisz czytać na ekranie w jasnym świetle słonecznym? Czy urządzenie działa na zewnątrz w upale lub mrozie?
  • Przetestuj rozwiązanie z wszystkimi innymi zainstalowanymi aplikacjami – czy są jakieś skutki uboczne? Dzięki filozofii piaskownicy systemu Android i iOS powinno działać, ale lepiej ją przetestuj.
  • Przetestuj w sytuacjach, gdy brakuje pamięci – czy aplikacja nadal działa? Jak wygląda wydajność w tym przypadku? Co się stanie, jeśli aplikacja zostanie usunięta z pamięci?
  • Przetestuj aplikację na starszych wersjach systemu operacyjnego. Przetestuj go również z wersjami beta, które zostaną wydane w przyszłości!
Czy potrafisz pracować z akceptowalną szybkością w szczerym polu?

Pisanie automatycznych skryptów testowych

Pozwól swoim programistom tworzyć automatyczne przypadki testowe, które można uruchomić przed każdą kompilacją. Może to zmniejszyć wysiłek związany z testowaniem i wykryć pierwsze błędy, zanim prawdziwi testerzy rozpoczną swoje działania. Zautomatyzowane testy jednostkowe nigdy jednak nie zastąpią „prawdziwych” testów, po prostu je uzupełniają.

Testuj na różnych urządzeniach

Jeśli masz strategię BYOD (przynieś własne urządzenie), spróbuj przetestować aplikacja na różnych urządzeniach. Czy aplikacja działa na wszystkich rozdzielczościach ekranu? Jeśli jest niezależny od platformy, czy działa na wszystkich platformach?

Przetestuj instalację / aktualizację

Przetestuj instalację i aktualizację swojej aplikacji mobilnej. Czy plik APK, IPA lub XAP można pobrać przez połączenie telefoniczne?

Przetestuj bezpieczeństwo aplikacji

  • Użyj sniffera sieciowego, aby sprawdzić, czy włączone szyfrowanie jest aktywny.
  • Spróbuj otworzyć bazę danych urządzenia, aby sprawdzić, czy jest naprawdę zaszyfrowana.
  • Przetestuj bezpieczną pamięć, na przykład pęku kluczy iOS – czy te dane są tylko lokalne, czy też wysłać do chmury?

Przetestuj część administracyjną aplikacji

  • Czy możesz tworzyć nowych użytkowników, urządzenia itp. w środowisku mobilnym?
  • Czy możesz wyrejestrować / usunąć urządzenia?
  • Czy dzienniki są skonfigurowane prawidłowo? Czy mają wystarczająco dużo informacji, aby przeanalizować problemy? Czy jest ustawiony na tyle nisko, że dziennik nie zmniejsza wydajności?

Bez względu na to, jak długo i dobrze będziesz testować, przez pęknięcia będą się pojawiać błędy. Im bardziej złożona aplikacja, tym większe prawdopodobieństwo, że tak się stanie. Z tego powodu zawsze powinieneś mieć rozwiązanie awaryjne – może to być arkusz Excela lub po prostu kawałek papieru. W idealnym przypadku nigdy nie musisz go używać.

Testowanie to gorący temat – ile testów wystarczy? Jak dużo jest za dużo? Można argumentować, że nigdy nie można wystarczająco przetestować, jednak ktoś musi za to zapłacić. Jak ze wszystkim, musisz znaleźć odpowiednią równowagę.

Powodzenia w testowaniu! Jeśli masz jakieś pytania lub potrzebujesz pomocy przy testowaniu, skontaktuj się ze mną pod adresem [email protected] .

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *