Testowanie aplikacji [internetowych]

Przetestowałem 17 19 przeglądarek pod kątem szybkości interpretowania kodu JavaScript. Użyłem do tego najpopularniejszego benchmarka JavaScript: SunSpider JavaScript Benchmark.

Testy były przeprowadzone w miarę niezmiennym środowisku z domyślnymi ustawieniami przeglądarek i dodatkami, których używam na codzień. Każdy z testów był przeprowadzony dwa razy, a wyniki obliczone na podstawie średniej.

Pod uwagę wziąłem także najnowsze bety najpopularniejszych przeglądarek – w przypadku każdej z nich widać wyraźną poprawę wydajności – co cieszy…

Najpierw wyniki dla systemu Windows XP.

Legenda:

• Przeglądarka – nazwa przeglądarki
• Wersja – wersja przeglądarki
• Średnia – średnia czasów (w milisekundach) wykonywania testów
• Wskaźnik – pokazuje ile razy przeglądarka jest wolniejsza od najszybszej w tabeli

Teraz wyniki dla Mac OS X.

I jeszcze uwspólnione dane w jednej tabeli. Dane zostały przeliczone na podstawie uśrednionego wskaźnika (aby były wiarygodne, ponieważ testy dla Mac OS X i Win XP były przeprowadzane na różnej klasy komputerach).

Myślę, że dane mówią same za siebie, a komentarz jest zbędny. Zastanawiające jest to, że Apple potrafi zrobić najszybszą przeglądarkę na swój system i system konkurencji, natomiast Microsoft sobie nie poradził jak trzeba.

Napawające optymizmem są wyniki wersji beta przeglądarek – widać, że deweloperzy przykadają do szybkości dużą wagę.

OWASP – The Free And Open Web Application Security Project

Najpierw prezentacja Filipa o wtyczkach do Firefoxa, później prezentacja organizacyjna, o OWASPIE.

Wtyczki o których była mowa:

napisać kilka zdań o OWASPIE i poruszanym tematcie: jak zwrócić uwagę użytkowników na to, że bezpieczeństwo aplikacji jest ważne. A kiedy jest ważne?

• w konkursach, gdzie jest regulamin – i nie powinno się dać oszukiwać
• w miejscach gdzie podajemy swoje adresy e-mail (żeby spamboty ich nie przechwyciły)
• w bankach…
• w miejscach gdzie podajemy dane osobiste – żeby nie zostały wykradzione

Link do listy projektów OWASP

http://www.owasp.org/index.php/Main_Page

Dwa dni temu W3C ogłosiło, że Web Content Accessibility Guidelines 2.0 (WCAG) dotarło do momentu, kiedy stało się oficjalną rekomendacją. Trwało to bardzo długo, prace nad WCAG 2.0 rozpoczęły się bardzo dawno temu.

Dla osób, które pierwszy raz spotykają się ze skrótem – WCAG jest zestawem wytycznych, dzięki którym, po ich spełnieniu nasza strona będzie bardziej dostępna (dla użytkowników niepełnosprawnych), WCAG definiuje 3 poziomy dostępności, najłatwiejszy do osiągnięcia “A”, i dwa kolejne, “AA” i “AAA”. Sama witryna W3C osiąga poziom “AA”.

Na pierwszy rzut oka WCAG 2.0 różni się od poprzedniej wersji ilością przykładów, pozytywnych jak i negatywnych – co jest moim zdaniem bardzo przydatne.

ab (Apache Benchmark), to dołączana do dystrybucji Apache aplikacja testująca wydajność serwera http.

Apache Benchmark na podstawie wprowadzonej liczby zapytań do serwera (z czego część może być realizowana jednoczenie) wyświetla nam raport czasowy realizacji poszczególnych zapytań.

Przykładowe zapytanie: jk$ ab -n1000 -c200 -k http://webascrazy.net/ (Uwaga! Ważne, aby pamiętać o końcowym slashu, w przypadku wpisywania samej domeny!) Spowoduje odpytanie serwera na którym jest http://webascrazy.net 1000 razy, z czego, z czego jednokrotnie będzie wysłanych 200 zapytań. Wynik takiego zapytania będzie wyglądać mniej więcej tak:

http://httpd.apache.org/docs/2.0/programs/ab.html

a x zapytańhttp://www.netcoffee.pl/pogodzinach/2006/02/11/kontrola-wydajnosci-apache-benchmark/

Kilka dni temu W3C udostępniło kolejny  walidator stron internetowych. Nowe narzędzie sprawdzi nam, czy nasza strona nadaje się do przeglądania w telefonach komórkowych: http://validator.w3.org/mobile/

Logo W3C mobileOK Checker

Zasada działania jest podobno do pozostałych walidatorów, po wpisaniu strony uzyskujemy czytelny raport. Bardzo przydatne narzędzie – jednak aktualnie są jakieś problemy z wydajnością (duże zainteresowanie?).

W związku z tym, możemy się pewnie wkrótce spodziewać aktualizacji Web Developer Toolbara z dodaną opcją walidacji serwisu za pomocą tego walidatora.

Jednocześnie dopisuję ten walidator, do listy z checkami przed uruchomieniem nowej aplikacji internetowej. Tutaj możesz zobaczyć całą listę.

Z Fiddlera z Firefoxem można korzystać na kilka sposobów. Wszystkie wymagają jednak >10 minut czasu na skonfigurowanie, poustawianie itd.

Mała ikonka dodatku w pasku stanu Firefoxa

Dzisiaj kolega z pracy pokazał mi bardzo fajny dodatek: Fiddler Switch (pobierz Fiddler Switch). Dodatek ten instaluje się jako ikonka w pasku stanu Firefoxa, i za pomocą jednego kliknięcia uruchamia Fiddlera, oraz zmienia odpowiednio ustawienia proxy. Bardzo wygodne, bardzo łatwe, bardzo przyjemne.

Dodatkowo:

• przeczytaj o programie Fiddler
• obejrzyj listę narzędzi niezbędnych każdemu testerowi/webmasterowi

Często podczas testowania nowego systemu korzystającego np. z bazy danych natykamy się na problem braku danych testowych. Część z nas ma napisane i opatentowane skrypty, które generują nam najczęściej wykorzystywane dane, jednak wiele testów jest przeprowadzanych nierzetelnie właśnie ze względu na brak realnych danych.

Interface generatora danych testowaych na Testerzy.pl

Z pomocą przychodzi tutaj rewelacyjny skrypt ze strony Testerzy.pl: http://generatordanych.testerzy.pl. Generator daje nam możliwość wygenerowania do 5000 wierszy danych.

Przykładowe testowe dane wygenerowane przez generator

Danym możemy zdefiniować dużo (ponad 100) kolumn, do których wartości będą wygenerowane na podstawie wielu reguł, które możemy dowolnie definiwać: hasła, daty, adresy, nazwiska, losowe treści, numery, adresy e-mail. Bardzo dobre narzędzie – polecam i dodaję do listy niezbędnych narzędzi.

FogBugz (oficjalna strona FogBugz) – system zarządzania projektami ułatwiający komunikację zespołom projektowym. Główne funkcjonalności systemu (których jest sporo na rynku) to:

• wiki
• zarządzanie zadaniami
• system bug-trackingowy
• system komunikacji mailowej, z rozbudowanym systemem filtrów
• grupy dyskusyjne
• system harmonogramowania i estymacji czasu realizacji projektu

Muszę się przyznać, że nie korzystałem jeszcze z tego systemu, ale urzekło mnie video reklamujący FogBugz. Polecam obejrzenie, nawet jeżeli nie jesteście zainteresowani zakupem. Trwa 12 minut i jest prowadzony w bardzo luźnym stylu – sporo śmiechu.

FogBugz nie jest tani, kosztuje 25$ / użytkownik / miesiąc – w przypadku hostowania na serwerach FogBugz, lub 1899$ za licencje na 10 użytkowników, kiedy uruchamiamy aplikację na naszych serwerach.

Można przetestować FogBugz, bez ograniczeń funkcjonalnych, przez 45 dni, i to zamierzam zrobić ze swoim zespołem w ciągu najbliższego miesiąca. Pod koniec stycznia napiszę jak się sprawuje – chyba, że wyniki będą szybciej!

Dodam jeszcze, że narzędzie to jest autorstwa firmy, jednego z moich ulubionych publicystów: Joela Spolskyego (Fog Creek Software).

Programowanie ekstremalne – podstawowe zasady

http://msdn.microsoft.com/en-us/library/ms182613(VS.80).aspx

Smoke testing is done by developers before the build is released or by testers before accepting a build for further testing. Microsoft claims[1] that next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.

In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.

In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a “shallow and wide” approach to the application. The tester “touches” all areas of the application without getting too deep, looking for answers to basic questions like, “Can I launch the test item at all?”, “Does it open to a window?”, “Do the buttons on the window do things?”. The purpose is to determine whether or not the application is so badly broken that testing functionality in a more detailed way is unnecessary. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself. This is sometimes referred to as “rattle” testing – as in “if I shake it does it rattle?”