Wysoce skuteczne, przy minimalnym wysiłku testowanie w różnych przeglądarkach

Testowanie w różnych przeglądarkach jest czasochłonne i pracochłonne. Jednak programiści są z natury leniwi: trzymają się zasady DRY, pisząc skrypty automatyzujące rzeczy, które w innym przypadku musielibyśmy robić ręcznie, korzystając z bibliotek innych firm; bycie leniwym czyni nas dobrymi programistami .

Tradycyjne podejście do „prawidłowego” testowania w różnych przeglądarkach polega na testowaniu we wszystkich głównych przeglądarkach używanych przez odbiorców, stopniowo przechodząc na starsze lub bardziej nieczytelne przeglądarki, aby stwierdzić, że je przetestowałeś. Lub, jeśli brakuje czasu i zasobów, przetestować mały podzbiór przeglądarek ad hoc i mieć nadzieję, że brak błędu da ci pewność co do integralności aplikacji. Pierwsze podejście uosabia „dobry” rozwój, ale jest nieefektywne, podczas gdy drugie uosabia lenistwo, ale jest zawodne.

Dalsze czytanie na SmashingMag:

• Przejście Noego na testy użyteczności mobilnej
• Podstawy automatyzacji testów aplikacji, gier i sieci mobilnej
• Jak stworzyć własny front-endowy plan testowania strony internetowej?
• Gdzie są najlepsze na świecie otwarte laboratoria urządzeń?

Mam nadzieję, że w ciągu następnych piętnastu minut oszczędzę Ci godzin zmarnowanego wysiłku, opisując strategię testowania, która jest nie tylko mniej pracochłonna , ale też bardziej skuteczna w wykrywaniu błędów. Chcę udokumentować realistyczną strategię testowania bardziej odpowiednią i wartościową niż po prostu „testuj WSZYSTKIE rzeczy!”, opierając się na moim doświadczeniu jako programisty w testowaniu w BBC Visual Journalism.

Kontekst

Na marginesie warto zaznaczyć, że w naszym zespole robimy coś więcej niż tylko testy ręczne. Testy w różnych przeglądarkach nie zastępują testów jednostkowych (Jasmine/QUnit), testów funkcjonalnych (Cucumber) i, w stosownych przypadkach, automatycznych testów regresji wizualnej (Wraith). Rzeczywiście, testy automatyczne są tańsze na dłuższą metę i są niezbędne, gdy aplikacja osiągnie określony rozmiar.

Jednak niektóre błędy pojawiają się tylko w niektórych przeglądarkach, a automatyzacja testów nie weszła jeszcze niezawodnie w dziedzinę testowania w różnych przeglądarkach. Skąd komputer może wiedzieć, że zdarzenie automatycznego przewijania właśnie przesłoniło połowę tytułu podczas oglądania na iPhonie 4? Skąd miałby wiedzieć, że to problem? Dopóki sztuczna inteligencja nie osiągnie punktu, w którym komputery zrozumieją , co zbudowałeś i docenią narrację i artyzm, które próbujesz zademonstrować, zawsze będzie potrzeba ręcznego testowania. Jako coś, co musi być wykonywane ręcznie, jesteśmy sobie winni, aby proces testowania w różnych przeglądarkach był jak najbardziej wydajny.

Jaki masz cel?

Zanim zagłębisz się na ślepo w testowanie w różnych przeglądarkach, zdecyduj, co chcesz z tego uzyskać. Testy w różnych przeglądarkach można podsumować jako mające dwa główne cele:

1. Wykrywanie błędów Wiąże się to z próbą zepsucia aplikacji w celu znalezienia błędów do naprawienia.
2. Sprawdzanie zdrowia Polega to na sprawdzeniu, czy większość odbiorców odbiera oczekiwane wrażenia.

Pierwszą rzeczą, którą chciałbym, abyście wynieśli z tego artykułu, jest to, że te dwa cele są ze sobą sprzeczne .

Z jednej strony wiem, że mogę zweryfikować doświadczenia prawie 50% naszych odbiorców w Wielkiej Brytanii po prostu testując w Chrome (Desktop), Chrome (Android) i Safari (iOS 9). Z drugiej strony, jeśli moim celem jest znajdowanie błędów, będę chciał rzucić moją aplikację internetową w najbardziej problematycznych przeglądarkach, które musimy aktywnie wspierać: w naszym przypadku IE8 i natywna przeglądarka Android 2.

Użytkownicy tych dwóch przeglądarek stanowią malejący procent naszych odbiorców (obecnie około 1,5%), co sprawia, że ​​testowanie w tych przeglądarkach jest słabym wykorzystaniem naszego czasu, jeśli naszym celem jest sprawdzenie poprawności. Ale są to świetne przeglądarki do przetestowania, jeśli chcesz zobaczyć, jak zniekształcona może się Twoja dobrze zaprojektowana aplikacja, gdy zostanie rzucona na mało znany silnik renderujący.

Co zrozumiałe, tradycyjne strategie testowania kładą większy nacisk na testowanie w popularnych przeglądarkach. Jednak nieproporcjonalna liczba błędów występuje tylko w mniej znanych przeglądarkach, które w tradycyjnym modelu testowania wyjdą na jaw dopiero pod koniec testowania. Stajesz wtedy przed dylematem…

Co robisz, gdy znajdziesz błąd pod koniec fazy testowania długiego ogona?

1. Zignoruj ​​błąd.
2. Napraw błąd i miej nadzieję, że niczego nie zepsułeś.
3. Napraw błąd i ponownie przetestuj we wszystkich wcześniej testowanych przeglądarkach.

W idealnym świecie ostatnia opcja jest najlepsza, ponieważ jest to jedyny sposób, aby mieć pewność, że wszystkie przeglądarki nadal działają zgodnie z oczekiwaniami. Jednak jest to również potwornie nieefektywne – i jest to coś, co prawdopodobnie będziesz musiał zrobić wiele razy. Jest to odpowiednik ręcznego testowania sortowania bąbelkowego.

Dlatego znajdujemy się w sytuacji paragrafu 22: aby uzyskać maksymalną wydajność, chcemy naprawić wszystkie błędy przed rozpoczęciem testowania w różnych przeglądarkach, ale nie możemy wiedzieć, jakie błędy istnieją, dopóki nie zaczniemy testowania.

Odpowiedzią jest mądre podejście do tego, jak testujemy: spełnianie naszych celów polegających na wyszukiwaniu błędów i sprawdzaniu poprawności poprzez testowanie przyrostowe, w tym, co lubię nazywać atakiem trójfazowym .

Atak trójfazowy

Wyobraź sobie, że jesteś w strefie wojny. Wiesz, że źli faceci skuli się w kwaterze głównej po drugiej stronie miasta. Do Twojej dyspozycji masz agenta specjalnego, doborową drużynę zaprawionych w bojach partyzantów oraz liczną grupę lekko uzbrojonej lokalnej milicji. Rozpoczynasz trójfazowy atak, aby odzyskać miasto:

1. Rekonesans Wyślij szpiega do kwatery głównej wroga, aby sprawdzić, gdzie mogą się ukrywać źli ludzie, ilu jest ich i jaki jest ogólny stan pola bitwy.
2. Raid Wyślij swoją drużynę cracku prosto w samo serce wroga, eliminując większość złych facetów jednym gwałtownym atakiem z zaskoczenia.
3. Odprawa Wyślij lokalną milicję, aby zabrała pozostałych złoczyńców i zabezpieczyła teren.

Możesz wprowadzić tę samą strategię wojskową i dyscyplinę do testów w różnych przeglądarkach:

1. Rozpoznanie Przeprowadź testy eksploracyjne w popularnej przeglądarce na komputerze deweloperskim. Sprawdź, gdzie mogą się ukrywać błędy. Napraw wszelkie napotkane błędy.
2. Raid Ręczne testowanie na małej garstce problematycznych przeglądarek, które prawdopodobnie wykażą najwięcej błędów. Napraw wszelkie napotkane błędy.
3. Clearance Sanity – sprawdzenie, czy najpopularniejsze przeglądarki wśród Twoich odbiorców są wyczyszczone, aby uzyskać oczekiwane wrażenia.

Niezależnie od tego, czy jesteś na polu bitwy, czy testujesz urządzenia, fazy rozpoczynają się przy minimalnym nakładzie czasu i rozwijają się, gdy operacja staje się bardziej stabilna. Jest tylko tyle rekonesansu, który możesz zrobić – powinieneś być w stanie wykryć kilka błędów w bardzo krótkim czasie. Najazd jest bardziej intensywny i czasochłonny, ale przynosi bardzo wartościowe rezultaty i znacząco stabilizuje pole bitwy. Faza oczyszczenia jest najbardziej pracochłonna ze wszystkich i nadal musisz zachować rozsądek na wypadek, gdyby niezauważony złoczyńca pojawił się znikąd i wyrządził ci krzywdę – ale jest to niezbędny krok, aby móc śmiało twierdzić, że pole bitwy jest teraz bezpieczny.

Pierwsze dwa kroki naszego trójfazowego ataku spełniają nasz pierwszy cel: wykrywanie błędów . Gdy masz pewność, że Twoja aplikacja jest solidna, zechcesz przejść do trzeciej fazy ataku, testując na minimalnej liczbie przeglądarek, które pasują do większości zachowań związanych z przeglądaniem Twoich odbiorców, spełniając cel numer dwa: sprawdzanie poprawności. Możesz wtedy powiedzieć z popartą ilościowo pewnością, że Twoja aplikacja działa dla X% Twoich odbiorców.

Konfiguracja: poznaj swojego wroga

Nie przystępuj lekko do wojny. Zanim zaczniesz testować, sprawdź, w jaki sposób użytkownicy uzyskują dostęp do Twoich treści.

Znajdź statystyki swoich odbiorców (z Google Analytics lub innego używanego narzędzia) i uzyskaj dane w arkuszu kalkulacyjnym w formacie, który możesz przeczytać i zrozumieć. Będziesz chciał widzieć każdą kombinację przeglądarki i systemu operacyjnego z powiązanym procentem całkowitego udziału w rynku.

Statystyki użytkowania przeglądarki są przydatne tylko wtedy, gdy można je łatwo wykorzystać: nie chcesz, aby prezentowana była długa, zniechęcająca lista kombinacji przeglądarki/systemu operacyjnego/urządzenia, które musisz przetestować. Poza tym testowanie każdej możliwej kombinacji to zmarnowany wysiłek. Możemy wykorzystać naszą wiedzę programistów internetowych, aby heurystycznie skonsolidować nasze statystyki.

Uprość statystyki użytkowania przeglądarki

Jako twórcy stron internetowych nie obchodzi nas szczególnie, na którym systemie operacyjnym działa przeglądarka komputerowa – bardzo rzadko błąd przeglądarki dotyczy jednego systemu operacyjnego, a drugiego nie – dlatego łączymy statystyki dla przeglądarek stacjonarnych we wszystkich systemach operacyjnych.

Nie obchodzi nas również, czy ktoś używa Firefoksa 40 czy Firefoksa 39: różnice między wersjami są znikome, a aktualizacja wersji jest bezpłatna i często automatyczna. Aby ułatwić zrozumienie statystyk przeglądarek, łączymy wersje wszystkich przeglądarek komputerowych – z wyjątkiem IE. Wiemy, że starsze wersje IE są zarówno problematyczne, jak i rozpowszechnione, dlatego musimy śledzić ich dane dotyczące wykorzystania.

Podobny argument dotyczy przenośnych przeglądarek systemu operacyjnego. Nie przejmujemy się szczególnie wersją mobilną Chrome lub Firefox, ponieważ są one regularnie i łatwo aktualizowane – dlatego łączymy wersje. Ale znowu dbamy o różne wersje IE, więc osobno logujemy ich wersje.

Wersja systemu operacyjnego urządzenia nie ma znaczenia, jeśli mówimy o Androidzie; ważna jest używana wersja natywnej przeglądarki Androida, ponieważ jest to bardzo problematyczna przeglądarka. Z drugiej strony, która wersja systemu iOS jest uruchomiona na urządzeniu, jest bardzo istotna, ponieważ wersje Safari są nierozerwalnie powiązane z systemem operacyjnym. Poza tym istnieje cała gama natywnych przeglądarek dla innych urządzeń: stanowią one tak mały procent naszej ogólnej liczby odbiorców, że ich numery wersji również są scalone.

Wreszcie, mamy nową falę przeglądarek, które szybko zyskują na popularności: przeglądarki w aplikacjach, wdrażane głównie na platformach społecznościowych. Jest to dla nas wciąż nowy grunt, dlatego chętnie wymienimy wszystkie platformy przeglądarek w aplikacji i odpowiadające im systemy operacyjne.

Po wykorzystaniu naszej wiedzy eksperckiej w dziedzinie domen do scalania powiązanych statystyk, zawężamy listę dalej, usuwając każdą przeglądarkę, która stanowi mniej niż 0,05% naszych odbiorców (możesz dostosować ten próg zgodnie z własnymi wymaganiami).

Przeglądarki komputerowe

Przeglądarki przenośne

Przeglądarki w aplikacji

Gdy skończysz, Twój arkusz kalkulacyjny powinien wyglądać mniej więcej tak (na razie zignoruj ​​kolumnę „Priorytet” — zajmiemy się tym później):

Masz teraz uproszczony arkusz kalkulacyjny, pokazujący kluczowe przeglądarki z perspektywy programisty, z których każda jest powiązana z całkowitym udziałem w rynku. Pamiętaj, że powinieneś aktualizować ten arkusz kalkulacyjny; aktualizacja raz w miesiącu powinna wystarczyć.

Jesteś teraz gotowy do rozpoczęcia trójfazowego ataku.

1. Rekonesans: znajdź błędy niezależne od przeglądarki

Na długo przed tym, zanim pomyślisz o wyjęciu urządzenia do testowania, zrób najłatwiejszą rzecz, jaką możesz: otwórz aplikację internetową w ulubionej przeglądarce. Jeśli nie jesteś kompletnym masochistą, prawdopodobnie będzie to Chrome lub Firefox, które są stabilne i obsługują nowoczesne funkcje. Celem tego pierwszego etapu jest znalezienie błędów niezależnych od przeglądarki .

Błędy niezależne od przeglądarki to błędy implementacji, które nie mają nic wspólnego z przeglądarką lub sprzętem używanym do uzyskiwania dostępu do aplikacji. Załóżmy na przykład, że Twoja strona internetowa zostanie uruchomiona i zaczniesz otrzymywać niejasne raporty o błędach od osób, które skarżą się, że Twoja strona wygląda na śmieci na ich HTC One w trybie poziomym. Marnujesz dużo czasu, ustalając, która wersja przeglądarki była używana, korzystając z trybu debugowania USB Androida i szukając pomocy w StackOverflow, zastanawiając się, jak u licha zamierzasz to naprawić. Bez Twojej wiedzy ten błąd nie ma nic wspólnego z urządzeniem: raczej Twoja strona wygląda na błędną przy określonej szerokości widocznego obszaru, która akurat odpowiada szerokości ekranu danego urządzenia.

To jest przykład błędu niezależnego od przeglądarki, który fałszywie objawił się jako błąd specyficzny dla przeglądarki lub urządzenia. Zostałeś poprowadzony długą i nieekonomiczną ścieżką, a raporty o błędach działają jak szum, zaciemniając pierwotną przyczynę problemu. Zrób sobie przysługę i złap tego rodzaju bakcyla już na samym początku, z dużo mniejszym wysiłkiem i trochę większym przewidywaniem.

Naprawiając błędy niezależne od przeglądarki, jeszcze zanim zaczniemy testować różne przeglądarki, powinniśmy mieć do czynienia z mniejszą liczbą błędów. Lubię nazywać to efektem topnienia góry lodowej . Roztapiamy robaki, które są ukryte pod powierzchnią, ratując nas przed rozbiciem się i utonięciem w oceanie - a nawet nie zdajemy sobie sprawy, że to robimy.

Poniżej znajduje się krótka lista rzeczy, które możesz zrobić w swojej przeglądarce programistycznej, aby odkryć błędy niezależne od przeglądarki:

• Spróbuj zmienić rozmiar, aby zobaczyć responsywność. Czy gdzieś był jakiś funky breakpoint?
• Powiększ i pomniejsz. Czy pozycje tła twojego obrazka zostały przekrzywione?
• Zobacz, jak aplikacja zachowuje się z wyłączonym JavaScript. Czy nadal otrzymujesz podstawową zawartość?
• Zobacz, jak wygląda aplikacja z wyłączonym CSS. Czy semantyka znaczników nadal ma sens?
• Spróbuj wyłączyć JavaScript I CSS. Czy otrzymujesz zadowalające wrażenia?
• Spróbuj wejść w interakcję z aplikacją, używając tylko klawiatury. Czy można nawigować i zobaczyć całą zawartość?
• Spróbuj dławić połączenie i zobacz, jak szybko ładuje się aplikacja. Jak duże jest ładowanie strony?

Zanim przejdziesz do fazy 2, musisz naprawić napotkane błędy. Jeśli nie naprawimy błędów niezależnych od przeglądarki, w późniejszym czasie zgłosimy tylko wiele fałszywych błędów związanych z przeglądarką.

Być leniwym. Napraw błędy niezależne od przeglądarki. Następnie możemy przejść do drugiej fazy ataku.

2. Raid: najpierw przetestuj w przeglądarkach wysokiego ryzyka

Kiedy naprawiamy błędy, musimy uważać, aby nasze poprawki nie wprowadzały kolejnych błędów. Poprawienie naszego CSS w celu naprawienia dopełnienia w Safari może spowodować uszkodzenie dopełnienia w Firefoksie. Optymalizacja tego fragmentu kodu JavaScript, aby działał płynniej w Chrome, może całkowicie go zepsuć w IE. Każda wprowadzana przez nas zmiana niesie ze sobą ryzyko.

Aby być naprawdę pewnym, że nowe zmiany nie zepsuły doświadczenia w żadnej z przeglądarek, w których już testowaliśmy, musimy wrócić i ponownie przetestować te same przeglądarki. Dlatego, aby zminimalizować powielanie wysiłków, musimy mądrze podchodzić do tego, jak testujemy.

Analiza statystyczna dystrybucji błędów

Rozważ poniższą tabelę, gdzie ikona krzyżyka oznacza, że ​​przeglądarka ma błąd.

Załóżmy, że mamy testować nasze treści w porządku rosnącym ryzyka: przeglądarka niskiego ryzyka, przeglądarka średniego ryzyka, przeglądarka wysokiego ryzyka. Jeśli pomoże ci to zwizualizować, te przeglądarki mogą mapować odpowiednio do Google Chrome, IE 9 i IE 6.

Testując najpierw przeglądarkę Low Risk (Chrome), znajdziemy i naprawimy błąd nr 2. Kiedy przechodzimy do przeglądarki średniego ryzyka, błąd nr 2 jest już naprawiony, ale odkrywamy nowy błąd: nr 4. Zmieniamy nasz kod, aby naprawić błąd – ale skąd możemy mieć pewność, że nie zepsuliśmy czegoś w przeglądarce Low Risk? Nie możemy być całkowicie pewni, więc musimy wrócić i ponownie przetestować w tej przeglądarce, aby sprawdzić, czy wszystko nadal działa zgodnie z oczekiwaniami.

Teraz przechodzimy do przeglądarki wysokiego ryzyka i znajdujemy błędy nr 1, nr 3 i nr 5, które wymagają znacznych przeróbek w celu ich naprawienia. Co musimy zrobić po ich naprawieniu? Wróć i ponownie przetestuj przeglądarki o średnim i niskim ryzyku. To dużo powielania wysiłków. Musieliśmy przetestować nasze trzy przeglądarki w sumie sześć razy.

Zastanówmy się teraz, co by się stało, gdybyśmy przetestowali naszą zawartość w malejącej kolejności ryzyka.

Od razu znaleźliśmy błędy #1, #3, #4 i #5 w przeglądarce wysokiego ryzyka. Po naprawieniu tych błędów przejdziemy od razu do przeglądarki średniego ryzyka i odkryjemy błąd nr 2. Tak jak poprzednio, ta poprawka mogła pośrednio coś zepsuć, więc konieczne jest powrót do przeglądarki wysokiego ryzyka i ponowne przetestowanie. Na koniec testujemy w przeglądarce Low Risk i nie odkrywamy żadnych nowych błędów. W tym przypadku przetestowaliśmy nasze trzy przeglądarki w sumie przy czterech różnych okazjach, co oznacza znaczne skrócenie czasu potrzebnego do skutecznego wykrywania i naprawiania tej samej liczby błędów oraz sprawdzania zachowania tej samej liczby przeglądarek .

Może pojawić się presja na programistów, aby najpierw testowali w najpopularniejszych przeglądarkach, przechodząc pod koniec naszych testów w dół do mniej popularnych przeglądarek. Jednak popularne przeglądarki prawdopodobnie będą przeglądarkami niskiego ryzyka.

Wiesz, że musisz obsługiwać daną przeglądarkę wysokiego ryzyka, więc na samym początku usuń tę przeglądarkę. Nie marnuj wysiłku na testowanie przeglądarek, które są mniej podatne na błędy, ponieważ kiedy przełączysz się na przeglądarki, które generują więcej błędów, będziesz musiał tylko wrócić i ponownie spojrzeć na te przeglądarki o niskim ryzyku.

Naprawianie błędów w złych przeglądarkach sprawia, że ​​Twój kod jest bardziej odporny w dobrych przeglądarkach

Często można zauważyć, że błędy pojawiające się w tych problematycznych przeglądarkach są nieoczekiwanym skutkiem złego kodu z Twojej strony. Mogłeś niezręcznie zaprojektować div tak, aby wyglądał jak przycisk, lub włamałeś się w setTimeout przed wywołaniem jakiegoś arbitralnego zachowania; istnieją lepsze rozwiązania dla obu tych problemów. Naprawiając błędy, które są objawami złego kodu, prawdopodobnie naprawisz błędy w innych przeglądarkach, zanim je zobaczysz. Znowu ten efekt topnienia góry lodowej .

Sprawdzając obsługę funkcji, zamiast zakładać, że przeglądarka coś obsługuje, naprawiasz ten bolesny błąd w IE8, ale jednocześnie sprawiasz, że Twój kod jest bardziej odporny na inne trudne środowiska. Zapewniając tę ​​awarię obrazu dla Opery Mini, zachęcasz do korzystania z progresywnego ulepszania, a jako produkt uboczny ulepszasz swój produkt nawet dla użytkowników przeglądarek, które odcinają musztardę. Na przykład urządzenie mobilne może utracić połączenie 3G po pobraniu tylko połowy zasobów aplikacji: użytkownik uzyskuje teraz sensowne wrażenia, których nie miałby wcześniej.

Uważaj jednak: jeśli nie będziesz ostrożny, naprawienie błędów w mało znanych przeglądarkach może pogorszyć Twój kod . Oprzyj się pokusie sniffowania ciągu agenta użytkownika, aby na przykład warunkowo dostarczać zawartość do określonych przeglądarek. To może naprawić błąd, ale jest całkowicie niezrównoważoną praktyką. Nie naruszaj integralności dobrego kodu, aby obsługiwać niewygodne przeglądarki.

Identyfikowanie problematycznych przeglądarek

Czym więc jest przeglądarka wysokiego ryzyka? Odpowiedź jest trochę niejasna i zależy od funkcji przeglądarki, z których korzysta Twoja aplikacja. Jeśli Twój JavaScript używa indexOf , może się zepsuć w IE 8. Jeśli Twoja aplikacja używa position: fixed , sprawdź to w Safari na iOS 7.

Can I Use to nieoceniony zasób i dobry początek, ale jest to jeden z tych obszarów, który ponownie wywodzi się z doświadczenia i intuicji programisty. Jeśli regularnie wprowadzasz aplikacje internetowe, będziesz wiedzieć, które przeglądarki od czasu do czasu zgłaszają problemy, i możesz udoskonalić swoją strategię testowania, aby to uwzględnić.

Przydatną rzeczą w przypadku błędów, które można znaleźć w problematycznych przeglądarkach, jest to, że często się rozprzestrzeniają. Jeśli w IE9 jest błąd, istnieje prawdopodobieństwo, że błąd występuje również w IE8. Jeśli coś wygląda dziwnie w Safari na iOS 7, prawdopodobnie będzie wyglądało jeszcze bardziej na iOS 6. Zauważasz tutaj wzór? Problematyczne są zwykle starsze przeglądarki. To powinno pomóc ci wymyślić całkiem niezłą listę problematycznych przeglądarek.

Biorąc to pod uwagę, wykonaj kopię zapasową za pomocą statystyk użytkowania. Na przykład IE 6 jest bardzo problematyczną przeglądarką, ale nie zawracamy sobie głowy testowaniem jej, ponieważ jej całkowity udział w rynku jest zbyt niski. Czas spędzony na naprawie błędów specyficznych dla IE6 nie byłby wart wysiłku dla małej liczby użytkowników, których doświadczenie byłoby lepsze.

Nie zawsze starsze przeglądarki będziesz chciał przetestować w fazie raid. Na przykład, jeśli masz eksperymentalny projekt kanwy 3D WebGL z obrazem zastępczym, starsze przeglądarki po prostu otrzymają obraz zastępczy, więc jest mało prawdopodobne, aby znaleźć wiele błędów. Zamiast tego chcielibyśmy zmienić wybór problematycznej przeglądarki w oparciu o dostępną aplikację. W takim przypadku IE9 może być dobrą przeglądarką do przetestowania, ponieważ jest to pierwsza wersja IE obsługująca płótno.

Nowoczesne przeglądarki proxy (takie jak Opera Mini) mogą być również dobrym wyborem do testu raid, jeśli Twoja aplikacja korzysta z funkcji CSS3, takich jak gradienty lub border-radius. Częstym błędem jest renderowanie białego tekstu na nieobsługiwanym gradiencie, co skutkuje nieczytelnym tekstem białym na białym.

Wybierając problematyczne przeglądarki, kieruj się intuicją i staraj się uprzedzać, gdzie mogą się ukrywać błędy.

Zdywersyfikuj swoje problematyczne przeglądarki

Przeglądarki i wersje przeglądarek to tylko jedna część równania: sprzęt jest również ważnym czynnikiem. Będziesz chciał przetestować swoją aplikację na różnych rozmiarach ekranu i różnej gęstości pikseli, a także spróbuj przełączać się między trybem pionowym i poziomym.

Grupowanie powiązanych przeglądarek może być kuszące, ponieważ istnieje postrzegana zniżka na koszt wysiłku. Jeśli masz już otwarty VirtualBox do testowania IE8, teraz może się wydawać, że to dobry czas na przetestowanie również w IE9, IE10 i IE11. Jeśli jednak jesteś na wczesnym etapie testowania swojej aplikacji internetowej, będziesz chciał walczyć z tą pokusą i zamiast tego wybrać trzy lub cztery kombinacje przeglądarka-sprzęt, które znacznie różnią się od siebie, aby uzyskać jak największe pokrycie całości miejsce na błąd, jak to tylko możliwe.

Chociaż mogą się one różnić w zależności od projektu, oto moje aktualne problematyczne przeglądarki z wyboru:

• IE 8 na maszynie wirtualnej z systemem Windows XP;
• natywna przeglądarka Android 2 na tablecie z systemem Android średniej klasy;
• Safari na iPhonie 4 z systemem iOS 6;
• Opera mini (naprawdę warta testowania tylko z treściami, które powinny działać bez JavaScript, takie jak datapics).

Być leniwym. Znajdź jak najwięcej błędów, wrzucając swoją aplikację do najbardziej problematycznych obsługiwanych przeglądarek i urządzeń. Po naprawieniu tych błędów możesz przejść do ostatniej fazy ataku.

3. Odprawa: kontrola zdrowia

Przetestowałeś teraz swoją aplikację w najtrudniejszych przeglądarkach, które musisz obsługiwać, miejmy nadzieję, że wyłapałeś większość błędów. Ale Twoja aplikacja nie jest jeszcze całkowicie wolna od błędów. Ciągle jestem zaskoczony tym, jak różne, nawet najnowsze wersje Chrome i Firefox będą renderować tę samą zawartość. Nadal musisz zrobić jeszcze kilka testów.

To ta stara zasada 80:20. W przenośni naprawiłeś 80% błędów po przetestowaniu 20% przeglądarek. Teraz chcesz zweryfikować doświadczenie 80% swoich odbiorców poprzez przetestowanie różnych 20% przeglądarek.

Priorytetyzacja przeglądarek

Teraz prostym i oczywistym podejściem jest powrót do „tradycyjnych” testów w różnych przeglądarkach, poprzez rozwiązywanie problemów z każdą przeglądarką w porządku malejącym pod względem udziału w rynku. Jeśli zdarzy się, że komputery Chrome mają najwyższy udział w przeglądarce Twoich odbiorców, a następnie Safari na iOS 8, a następnie IE11, to warto testować w tej kolejności, prawda?

To w dużej mierze sprawiedliwy system i nie chcę zbytnio komplikować tego kroku, jeśli twoje zasoby są już napięte. Jednak faktem jest, że nie wszystkie przeglądarki są sobie równe. W moim zespole grupujemy przeglądarki według drzewa decyzyjnego, które uwzględnia użytkowanie przeglądarki, łatwość aktualizacji oraz to, czy przeglądarka jest domyślną wersją systemu operacyjnego.

Do tej pory Twój arkusz kalkulacyjny powinien mieć kolumnę dla przeglądarki i kolumnę dla jej udziału w rynku; potrzebujesz teraz trzeciej kolumny, określającej, na jaki priorytet przypada przeglądarka. Prawdę mówiąc, ta praca nad ustalaniem priorytetów powinna była zostać wykonana przed rozpoczęciem ataku trójfazowego, ale dla celów tego artykułu bardziej sensowne było opisanie tego tutaj, ponieważ priorytety nie są tak naprawdę potrzebne do fazy oczyszczenia.

Oto nasze drzewo decyzyjne:

Zaprojektowaliśmy nasze drzewo decyzyjne tak, aby przeglądarki P1 obejmowały około 70% naszych odbiorców. Łącznie przeglądarki P1 i P2 obejmują około 90% naszych odbiorców. Wreszcie przeglądarki P1, P2 i P3 zapewniają nam prawie pełne pokrycie odbiorców. Naszym celem jest testowanie we wszystkich przeglądarkach P1, następnie P2, a następnie P3, w porządku malejącym udziału w rynku.

Jak widać w arkuszu kalkulacyjnym we wcześniejszej części tego artykułu, mamy tylko kilka przeglądarek P1. Fakt, że tak szybko możemy zweryfikować doświadczenie ponad 70% naszych odbiorców, oznacza, że ​​nie mamy wymówek, by nie testować ponownie w tych przeglądarkach, jeśli zmieni się baza kodu. Przechodząc w dół do przeglądarek P2 i P3, musimy włożyć coraz większy wysiłek w weryfikację doświadczenia coraz mniejszej liczby odbiorców, więc musimy ustalić bardziej realistyczne ideały testowania dla przeglądarek o niższym priorytecie. Jako wskazówka:

• P1 . Musimy sprawdzić poprawność tych przeglądarek przed wylogowaniem się z aplikacji. Jeśli wprowadzimy niewielkie zmiany w naszym kodzie, powinniśmy ponownie sprawdzić poprawność tych przeglądarek.
• P2 . Powinniśmy sprawdzić poprawność tych przeglądarek przed wylogowaniem się z aplikacji. Jeśli wprowadzimy duże zmiany w naszym kodzie, powinniśmy ponownie sprawdzić poprawność tych przeglądarek.
• P3 . Powinniśmy raz sprawdzić poprawność w tych przeglądarkach, ale tylko wtedy, gdy mamy czas.

Nie zapomnij o dywersyfikacji sprzętu. Jeśli możesz testować na wielu różnych rozmiarach ekranu i na urządzeniach o różnych możliwościach sprzętowych, korzystając z tej listy, zrób to.

Podsumowanie: atak trójfazowy

Gdy już włożysz wysiłek w poznanie swojego wroga ( uproszczenie statystyk odbiorców i pogrupowanie przeglądarek według priorytetów ), możesz zaatakować w trzech krokach:

1. Rekonesans : testy eksploracyjne w Twojej ulubionej przeglądarce w celu znalezienia błędów niezależnych od przeglądarki .
2. Raid : testowanie na najbardziej problematycznych obsługiwanych przeglądarkach na różnym sprzęcie, aby znaleźć większość błędów .
3. Rozliczenie : weryfikacja doświadczenia Twojej aplikacji w najczęściej używanych i strategicznie ważnych przeglądarkach, aby powiedzieć z popartą ilościowo pewnością, że Twoja aplikacja działa .