Dlaczego konieczne jest przetestowanie mojej aplikacji iPhone na rzeczywistym urządzeniu iPhone

Opracowałem jedną aplikację na iPhone'a, a teraz chcę ją w App Store. Tak wielu moich maniaków iOS-a kazało mi przetestować to na prawdziwym urządzeniu, tj. Na iPhonie.

Zastanawiam się więc, dlaczego konieczne jest przetestowanie mojej aplikacji iPhone na rzeczywistym urządzeniu iPhone, mimo że (Apple) dali „symulator”, który jest prawie taki sam jak moje urządzenie?

Musisz przetestować aplikację na prawdziwym urządzeniu, aby przynajmniej sprawdzić, jak działa:

• Prawdziwy sprzęt
• Prawdziwe połączenie z Internetem (w tym korzystanie z sieci komórkowej vs WiFi)
• Twoje palce zamiast myszy
• Wydajność z innymi aplikacjami działającymi w tle
• Ograniczenia iPhone'a, takie jak procesor, pojemność dysku i pamięć ( Symulator nie jest emulatorem ).
• Prawdziwy kontekst: czy korzystanie z aplikacji w pociągu jest łatwe, czy idąc ulicą? A może w jasnym świetle słonecznym lub w deszczu?

Programiści iOS, kontynuuj tę listę.

Jedną z rzeczy, których nigdy nie dowiesz się podczas testowania za pomocą emulatora, jest to, jak naprawdę czuje się użytkownik trzymający w dłoni prawdziwe urządzenie i przesuwający palcami po ekranie. W rezultacie działania użytkownika, które wydawały się płynne podczas symulacji za pomocą touchpada na laptopie, mogą okazać się dość kłopotliwe dla rzeczywistego użytkowania urządzenia. Aby upewnić się, że aplikacja działa poprawnie, przetestuj ją na prawdziwym urządzeniu.

Kolejną rzeczą wartą przetestowania na prawdziwym urządzeniu jest zużycie baterii. Testowanie na prawdziwym urządzeniu jest bezpieczniejsze niż poleganie na tym, jak dobrze twórcy symulatorów potrafili go odtworzyć w swoim narzędziu.

Mogą istnieć inne rzeczy, które po prostu nie są wystarczająco blisko w symulatorze. Na przykład głośność i równowaga dźwięku - sposób, w jaki brzmi na laptopie, może różnić się od tego, jak będzie na prawdziwym telefonie. Wibracje to kolejny przykład, który jest prawie niemożliwy do uzyskania w przypadku symulatora. Sposób działania czujników żyroskopowych na prawdziwym telefonie. GPS / rzeczy związane z lokalizacją. Itp itp. Itd ...

Testowanie symulatorów na rzeczywistych urządzeniach jest dość ważną kwestią. W jednym z moich wcześniejszych projektów ważną częścią komercyjnego sukcesu było staranne wyważenie tego rodzaju testów, które zasadniczo sprowadza się do ciągłego ponownego zadawania pytań, np. Dlaczego na urządzeniu?

Prawdziwa praca rozpoczyna się, gdy ktoś zapyta, dlaczego , wybierając powody wyboru między testowaniem na urządzeniu a symulatorem w określonych przypadkach i sytuacjach.

Zignorowanie testów urządzeń naraża Twój produkt na (dość wysokie) ryzyko włamania się w ręce użytkownika końcowego, całkowicie niszcząc wszystkie wysiłki włożone w rozwój. Rzecz w tym, że testy na symulatorze są znacznie DUŻO tańsze i łatwiejsze w automatyzacji. Jeśli ktoś ślepo trzyma się testów wyłącznie na urządzeniu, jego wydania mogą stać się znacznie późniejsze i droższe niż w przypadku konkurencji.

Z doświadczenia i startu z najlepiej głosowanej odpowiedzi:

• Największą różnicą były twoje palce zamiast myszy, gdy opracowaliśmy Decimation X2 dla Windows Phone 7. Został on zakodowany na emulatorze, ponieważ nie mieliśmy WP7 i było to przed wydaniem WP7. Moglibyśmy potencjalnie otrzymać bezpłatną WP7 przed wydaniem, na wypadek gdyby to ostatnie zdanie nie miało dla ciebie sensu, ponieważ Microsoft poprosił nas o tytuł uruchomienia na ich telefonie. Okazało się, że to, co chcieliśmy, aby użytkownik robił palcami, było bardzo trudne na prawdziwym telefonie, ale łatwe za pomocą myszy. I miało to związek z obudowami z ekranem. Niestety nasza gra wymagała ciągłego trzymania palców na krawędzi ekranu, co niektóre telefony utrudniały ze względu na zatopiony ekran oraz grube etui. Wydaliśmy łatkę, aby to naprawić. Oznacza to, że wszyscy nasi pierwsi użytkownicy zostali pokazani jako źli i potencjalnie nieużyteczni, wersja naszej gry. :(

• Kolejna największa różnica to inna prędkość sprzętowa. Musieliśmy dosłownie zgadywać z niedokładnej metody pobrania naszej wersji Xbox 360 gry i obniżenia jej odpowiednio do połowy liczby klatek na sekundę (60 klatek na sekundę do 30 klatek na sekundę) i jednej trzeciej GHz (3,0 GHz na 1,0 GHz) i zgadliśmy źle. Procesory były oczywiście inne i wiedzieliśmy o tym. Bez sprzętu pozostałyśmy kiepskie domysły. To nie był nasz wybór, ponieważ nie mieliśmy WP7, ale nauczyliśmy się lekcji, którą dzielę się teraz z tobą. Na niektórych telefonach, podczas najbardziej intensywnych części gry, opuszczała ramki. :( Nikt nie wydawał się tym przejmować, ponieważ zakładali, że spowolnienie jest odpowiednie dla tak intensywnych części. Więc to nie była wielka sprawa, ale chodzi o to: Gdyby to była wielka sprawa, „aplikacja” zostałaby zerwana z naszym kiepskim zgadywaniem.

Przetestuj na prawdziwym sprzęcie. Kiedy kodujesz różne urządzenia telefoniczne, sprawdź na niższych komputerach, czy wydajność jest problemem.

Symulator iPhone'a implementuje niektóre interfejsy API, których sam iPhone nie ma (głównym, który przychodzi na myśl, jest DOM API API, w którym iPhone obsługuje tylko SAX, o ile mi wiadomo, ale teraz mogło się to zmienić).

Pozwoli również „poczuć” aplikację, czy twoje przyciski mają odpowiedni rozmiar? Czy odpowiednie przyciski wpadają pod kciuk? Czy iPhone może uruchomić aplikację? Symulator nie jest emulatorem i działa po prostu dodając Cocoa Touch do komputera Mac dla tej aplikacji. Musisz zasymulować ostrzeżenia o braku pamięci i tym podobne.

Ponieważ nie będziesz miał wielu użytkowników spacerujących z symulatorem w kieszeni.

EDYCJA: Ilekroć testujesz swoją aplikację na symulatorze (lub emulatorze), używasz fałszywego urządzenia, które z definicji nie może być w 100% dokładnym odwzorowaniem rzeczywistości. Emulator może być dokładniejszy niż symulator, ale nadal będą występować różnice. Jedynym w 100% dokładnym emulatorem jest samo urządzenie.

Projektowanie, testowanie, optymalizacja kodu na symulatorze daje w rezultacie drobną modyfikację, która optymalnie działa na symulatorze. Twoi użytkownicy nie będą mieli symulatorów; celujesz w niewłaściwe urządzenie. Bardzo podobny; ale nie to samo urządzenie, z którego będą korzystać Twoi użytkownicy.

Może to prowadzić do szeregu problemów. Poważne problemy, takie jak błędy, awarie są z pewnością Twoim najwyższym priorytetem. Ale są też inni; takie jak ergonomia. Spróbuj trzymać symulator w dłoni. Spróbuj. Elementy interfejsu użytkownika są renderowane na innym ekranie, z prawdopodobnie różnym oddawaniem kolorów i z pewnością różnymi wymiarami (problem zaostrzony przez piękne wyświetlacze siatkówki, nie do końca rozwiązany przez użycie na przykład macbooka siatkówki). Czy te wykwintne odcienie szarości są równie widoczne na urządzeniu na słońcu?

Subtelne różnice prędkości i różne emisje czujników (lub ich brak) mogą czasem radykalnie zmienić wrażenia.

Jeśli aplikacja opiera się na łączności internetowej, nie ma możliwości przełączania się między LTE, 3G, EDGE lub GPRS, testowania różnych scenariuszy, a nawet testowania różnych operatorów.

Czy zamierzasz obsługiwać urządzenia z jailbreakiem? Być może nie jesteś, ale jeśli tak, prawdopodobnie chcesz przetestować swoją aplikację za pomocą jednego. A jeśli nie, czy jesteś pewien, że wykrywasz środowisko z jailbreakiem?

Czy gra na iPada, którą tworzysz na symulatorze, jest równie przydatna, gdy użytkownik trzyma swoją wagę i używa palców do gry? Czy niezamierzone wielokrotne dotknięcia mogą uszkodzić twoją aplikację, czego nie można było przewidzieć w bezpiecznym środowisku symulatora jednoprzyciskowego (lub symetrycznego podwójnego dotknięcia)?

Czy czułbyś się komfortowo wsiadając do samolotu dowodzonego przez pilota, który tak naprawdę nigdy nie opuścił ziemi?

Najważniejsze jest to: przed wysyłką używaj tego samego urządzenia, z którego będą korzystać Twoi użytkownicy. Żadne z nich nie będzie używać symulatora.

praktyczny powód:

1) Nie masz funkcji „wysyłaj pocztę”.

2) Nie możesz postawić urządzenia do góry nogami.

i oczywiście już powiedział powód:

3) niska przepustowość

4) bardzo mała moc obliczeniowa w porównaniu do symulatora

5) Otwarte wywołania GL są zaimplementowane nieco inaczej w symulatorze

6) miejsce na dysku / RAM ..

Chociaż wspomniano, że wydajność sprzętu jest ogólnie gorsza, należy zauważyć, że nie jest tak w przypadku OpenGL ES. Symulator implementuje go w oprogramowaniu, więc nie jest rzadkością, aby zauważyć ogromny wzrost wydajności podczas działania na samym urządzeniu.

Co więcej, istnieją pewne niewielkie różnice między oprogramowaniem a implementacją sprzętową Open GL ES, np. Wskazówki dotyczące precyzji modułu cieniującego mogą mieć różne wyniki.

Kiedy wdrażamy rzeczy dla iOS (lub Androida, lub Windows Phone), rozwijamy nie dla komputerów stacjonarnych, ale dla urządzeń. W przypadku niektórych aplikacji obliczeniowych / obciążających zasoby może to oznaczać normalne zachowanie na symulatorze, ALE problemy na rzeczywistym urządzeniu.

Takie sytuacje mogą wystąpić w późniejszych etapach, jeśli od początku nie testujemy na urządzeniu: -

• Ostrzeżenia / awarie pamięci
• Jednocyfrowe liczby klatek na sekundę OpenGL

Istnieje kilka funkcji, takich jak PushNotification , używanie aparatu itp., Które możemy przetestować tylko na urządzeniu; są to funkcje, których nie można przetestować na symulatorze.

A testowanie aplikacji na rzeczywistym urządzeniu przed przesłaniem do App Store zmniejsza ryzyko odrzucenia aplikacji; czasami aplikacja działa poprawnie w symulatorze, ale ulega awarii na rzeczywistym urządzeniu, co jest głównym powodem odrzucania aplikacji.

Mogą występować rzeczywiste różnice wydajności między rzeczywistym urządzeniem a emulatorem. Odkryliśmy, że tylko testowanie za pomocą emulatora skutkowało bardzo powolną aplikacją w wielu przypadkach, czego się nie spodziewaliśmy.

Doświadczenie użytkownika różni się w zależności od urządzenia i systemu operacyjnego

specyfikacje sprzętu. Dlatego konieczne jest przetestowanie aplikacji iPhone na faktycznym

urządzenia - urządzenia mobilne z różnymi wersjami iOS na rynku.

Chociaż symulator jest przydatny w identyfikowaniu problemów napotykanych przez użytkownika końcowego,

testowanie aplikacji na oryginalnym urządzeniu pomoże w identyfikacji głównych adresatów

obawy użytkownika.