Pokazywanie postów oznaczonych etykietą testowanie. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą testowanie. Pokaż wszystkie posty

9 lutego 2012

Narzędzia do pomiar wydajności i optymalizacji strony www

Istnieje wiele metod mierzenia wydajności naszejj strony internetowej. Najsensowniejsza wydaje się mierzona w regioniach geolokalizacyjnych, w których chcemy ją promomwać. Oczywiście są narzędzia, które testują naszą stronę z różnych serwerów z całego świata i podają rankingi wyników.
Najbardziej pożytecznymi argumentami, które stoją za pomiarem wydajności stron internetowych są czynniki oraz odczucia użytkownika.
Składają się one na aspekty typu:

  • czas wczytywania części strony widocznej na ekranie: czas, który upływa od momentu wysłania żądania nowej strony do momentu wyrenderowania części strony widocznej na ekranie przez przeglądarkę
  • czas pełnego wczytania strony: czas, który upływa od momentu, gdy użytkownik wysyła żądanie nowej strony do momentu, gdy strona zostanie w pełni wyrenderowana przez przeglądarkę
Okazuje się, że istnieje wiele czynników, które mogą zaburzać nam te jakżde oczywiste dwie metryki.
W narzędziach prezentowanych poniżej bardzo łatwo po znaczących kolorach i procencie dobrej roboty można obserwować, jak dużo pracy przed nami albo też za nami :-)

Chcąć się odnieść do kryteriów oceny warto wymienić niniejsze:

  • czy poprawnie działa cache
  • ilość plików CSS
  • ilość i JavaScript
  • kompresja i minimalizacja plików
  • czy obrazki są optymalnego formatu
  • czy obrazy załączone do strony są optymalne pod względem cachowania
  • jaki jest stopień optymalizacji wielkości obrazów w danym formacie + sugestie zmian formatu lub wielkości
  • jak stronę widzą typowe boty internetowe
  • jak możemy poprawić stronę pod kątem wygody dla nie w pełni sprawnych osób przeglądających naszą stronę

Gdybyście poszukiwali narzędzia wskazującego co dzieje się z Waszą stroną i gdzie można poszukać uchybień wydajności, polecam gtmetrix. W gtmetrix performance Report jaki można uzyskać z tego narzędzia składa się z wielu praktycznych wskazówek wyrażonych w punktach procentowych i klasyfikuje na tej podstawie do klasy wydajnościowej (skala od A do F, gdzie A to najlepsza ocena). Wygodnych ficzerem jest możliwość porównania z innymi wersjami strony lub innymi stronami.

Jednak na rynku króluje od pewnego czasu PageSpeed i temu narzędziu nie mam na prawdę niczego do zarzucenia. Przemyślane, wspierające urządzenia mobilne, darmowe i co najważniejsze wyniki testu są do przejrzenia pod linkiem przez innych. Ten ostatni ficzer czyni to narzędzie bardzo współczesnym i praktycznym.

Dzięki temu, że Page Speed Insights mierzy wydajność stron na urządzeniach przenośnych i komputerach. Dwukrotnie pobiera URL: poprzez komórkowego i komputerowego klienta użytkownika.


Oczywiście fani Firefoxa mogą zainstalować wtyczkę YSlow analizującą wydajność stron internetowych.

Wspominając o wydajności nie można pominać tzw. Waterfall Chart, czyli rejestru procesu ładowania stron przez przeglądarkę. Uzmysłowi nam to co tak naprawdę może być blokerem dla wydajności. Oto przykładowy widok takiego rejestru wodospadu:

Jeśli natomiast nie jesteśmy webmasterem i chcemy kilka zobaczyć kilka podstawowych kryteriów wydajności strony, możemy użyć page scoring. Oto bardzo czytelny i ogólny raport:

23 października 2008

Konsekwentne kodowanie i testowanie aplikacji internetowych

Wymiatający jest kod, który działa, ale taki, który działa w IE6 potrafi wymiatać podwójnie ...

Rozpoczynający dzisiejszą wypowiedź cytat/frazes nie jest przechwalaniem się jakiej to przeglądarki używam, ale raczej powieloną na mój sposób przestrogą, że w określonych okolicznościach warto pomyśleć o archaizmach. Ponoć każdy wytwór ludzkiej wyobraźni ma swój kres, gdyż rodzi się kolejny. Każda kolejna imaginacja może być jakościowo inna. Każdy produkt powinien pasować do marki i ją reprezentować. Moim zdaniem IE6 pasuje idealnie do marki M$ i ją także świetne reprezentuje.
Tak sobie spojrzałem i nawet specjaliści od testowania posiadają ratujący ich przed IE6 komentarz, który pozwolę sobie przytoczyć:


Testerzy kontra przeglądarki


Starając się dotrzeć do jak największej ilości odbiorców, dostarczając najlepszą jakość Testerzy.pl wyświetlają się poprawnie w:

* IE 7.0 i 8.0
* FireFox 2.0 i 3.0
* Opera 9.5 i wcześniejsze

Robimy wiele aby wyświetlać się poprawnie również w IE 6.0 jednak wymaga to od nas anielskiej cierpliwości i testów po każdej aktualizacji strony.



Oczywiście jest to przykłądowy i zupełnie przypadkowo odnaleziony komunikat informujący o tym, że nawet profesjonaliści od kontroli jakości mogą mieć IE6 w d.... bo powodów jest cała masa i rozmawiać można o nich wypijając przy tym skrzynkę ciemnego miodowego trunku. Oczywiście są tacy, którzy stają w obronie i udają, że im się udaje sprostać wymaganiom IE6. Ludzie, nie tędy droga :) Gdzie są wasze wymagania, założenia projektowe, konsekwencja w trzymaniu się założeń, hahahaaa ... niektórzy skomentują to śmiechem, ale wiele wielkich firm kupuje produkty działające tylko pod jedną przeglądarką. Pytanie, czy tylko nie są aplikacje intranetowe, w których problem jest z góry załatwiony.

W dobie ogólnej GPL, GPL2, *BSD i wszelkichj OpenSourcowych dowolności niekiedy zapominamy o tym, że pisząc coś dla publikacji w internecie warto się liczyć ze statystykami. Na co dzień pojawiają się wielce znaczące artykuły, które podają udział przeglądarek w rynku, lecz to często poszlaki. Nie jest tajemnicą, że tylko giganci internetowi mogą takie realne statystyki posidać, kiedy na ich portalach i stronach są treści różne i przyciągają użytkowników w różnym wieku oraz wszelakich zainteresowaniach. Ta wiedza tajemna jest też na sprzedaż i nie oszukujmy się, że z koleji inni giganci ją po prostu kupują i artykuły jakie na jej podstawie się rodzą będą bardziej na tą a mniej na tą psioczące i nie koniecznie obiektywne. Chciałbym pominąć artykuły zlecane przez M$, bo to są sztuczki marketingowe, ale nie pomijam bo to są działania skutecznie utrudniające życie teserom i deweloperom aplikacji internetowych. O tych właśnie grupach zawodowych będzie poniżej mowa :)

Z deweloperką aplikacji internetowych spotykam się na co dzień i z testerami także. Każdy ma swój zakres obowiązków oraz zakreśla fragment koła wokół którego obraca się internet. Patrząc z punktu widzenia praktycznego jeden i drugi boryka się często z problemem zakresów, w ramach których jest coś realizowane. Tak też można egzystować, ale pytanie jak długo ... pewnie do pierwszego grubego klienta, który ewidentnie powie dość i straty spowodują koniec zabawy. Dokładniej, czy czasem robienie aplikacji bez określonych wytycznych nie jest zabawą ? Na to pytanie spróbujmy sobie sami odpowiedzieć ...

Osobiście zachęcam do kartki papieru, ołówka i trzeźwego myślenia w kwestiach zasadniczych, które dotyczą przyszłego projektu. Wiele spraw, które założymy na wstępie pojawi się w trakcie, a te których nie założyliśmy zależnie od naszej konsekwencji pewnie też się pojawią. Trzymanie się ram jest o tyle ciężkim zajęciem, że zarówno indywidualnie jak i w grupie projektowej jest mnóstwo zajęć rozpraszających. Także pośrednio jesteśmy skazani na robienie wszystkiego i niczego pod warunkiem, że wiemy co znaczy konsekwencja. Dzięki niej wiele projektów jest kończonych na czas i ich jakość jest na wysokim poziomie.
Pomyślałem, że umieszczę link do wikipedii, bo nam wszystkim się przyda. Przypominanie sobie o niej uratowało niejeden projekt, więc zachęcam do kodowania konsekwentnego, któro po kodowaniu zwinnym ma tą zaletę, że nikt nam nie zarzuci, że coś mu nie działa w IE6 :-)

Kilka linków:
Testowanie w agile 2
Wojna przeglądarek
Przeglądarki używane przez internautów łączących się z polskimi witrynami z obszaru Polski. Ranking jest tworzony na podstawie liczby odsłon.

Exciting times in python testing world

Python Testing Tools Taxonomy

Agile Testing Articles and Tutorials

15 lutego 2008

Ciągła integracja + testy automatyczne przy pomocy Selenium i Hudson (Jenkins)

Od zawsze programiści marzyli o produkcji oprogramowania bez jego pisania :-)
Niestety o ile programiści dalej sobie marzą o tym,
ich koledzy teserzy, psujący dzieła programistów mają do wyboru automaty do testowania.

Automatyczne testowanie jest jednym z głównych postulatów eXtreme Programming (XP). Automatyzacja polega na użyciu oprogramowania do sterowania wykonaniem testów, porównywania ich wyników z oczekiwanymi, czy raportowania.

W dobie zaawansowania dedykowanych aplikacji internetowych i pozornie prostych w budowie systemów aukcyjnych oraz sklepów interenetowych, wymagania stawiane testerom stale rosną. Od testerów wymaga się podstawowych zdolności programistycznych, zwłaszcza, gdy używa się narzędzi testujących w sposób automatyczny.

Gdyby nie Selenium oraz Hudson / Jenkins testerzy stali by się w sposób naturalny świetnymi programistami. Na szczęście mogą nadal skupiać się na testowaniu jakości i zwracaniu uwagi na dziwne i "na niby bezpieczne" rozwiązania. Poniżej wyjaśnię na czym polega trick ;-)

Wszystko zaczyna się od zmiany podejścia i zastosowania:
  • pomysłodawcy funkcjonalności powinni myśleć o optymalnych krokach możliwych do wykonania w produkcji, które można w zrozumiały sposób przetestować - bez budowania wzmocnionych mostów dla testerów, gdy potrzebujemy wykonać funkcjonalnie kładkę :-)
  • TDD - programowanie ukierunkowane testami (Test-Driven Development) opierające się na technice automatycznego testowania, zaczynając od testu wynikającego ze specyfiki funkcjonalności, po czym realizowanie małymi krokami funkcjonalności, aby zapewnić poprawne wykonywania testu
  • ciągłej integracji - po każdej zmianie, raz na wydanie, ciągle w repozytorium SVN/trunk lub GIT/master wykonywanie testów automatycznych, analizy statycznej kodu oraz wszelkich weryfikacji wykrywających
  • reagownie na zmiany i błędy w trakcie procesu tworzenia a nie tylko incydentalnie po wydaniach
  • świadome myślenie o lawinowym charakterze strat, gdy błąd który można usunąć w trakcie produkcji znajdzie klient po wydaniu wersji
  • automaty służą do testów systemowych i integracji całości systemu a nie tylko, aby sobie budowały w nocy kod tak dla draki; aby ktoś z jakiegośtam działu nie zepsuł pracy kogoś z któregoś tam działu :-)

Tak mi się wydaje, że dopiero po uświadomieniu w drużynie projektowej od biznesu po produkujących kod, dlaczego warto automatyzować testy można przejść do zabawy z Selenium IDE, Selenium RC oraz Hudson ew. Hudson. Cytuje mądrą wypowiedź znawców kontroli jakości:

Ciągła integracja to przede wszystkim sztuka szybkiego przepływu informacji w procesie produkcji. Im szybciej wiemy o problemie, tym więcej czasu i za mniejsze pieniądze zareagujemy. Im później, tym większe ryzyko.

Materiały: http://www.thinkvitamin.com/features/webapps/easy-automated-web-application-testing-with-hudson-and-selenium

http://agilesurfing.pl/2011/programowanie/automatyczne-testowanie-kodu-jak-to-robic/

http://test-driven-development.com/