Archiwa tagu: testowanie

Kiedy skończyć testowanie

Testowanie oprogramowania to proces teoretycznie nieskończony. Zawsze można znaleźć warunki lub ścieżki, które nie zostały jeszcze sprawdzone. W warunkach biznesowych proces testowania jest jednak ograniczony (czasem, budżetem, możliwościami). Często pojawia się pytanie: kiedy można zakończyć testowanie, uznając że produkt jest dostatecznie dobrze sprawdzony?

Odpowiedź nie jest jednoznaczna – zakończenie testów jest umowne i zależy od spełnienia jakiegoś warunku:

  • Budżet – kwestia dość prosta.
  • Czas – może produkt „pudełkowy” ze sztywną datą wydania, może wytwarzany w modelu kaskadowym (a może w Scrumie), może trzeba gonić konkurencję, a może po prostu osoba decyzyjna stwierdza, że czas na testy ubiegł – kończymy.
  • Metryki. Tu zaczyna się robić ciekawie, o czym w dalszej części wpisu.

Ciekawy materiał na ten temat od IBM:
[ftp://public.dhe.ibm.com] – kopia [IBM_Kiedy_mozna_zakonczyc_testowanie].

Metryki są pewnym założeniem i są to wartości dość względne. Mogą zostać ustalone na początku testowania. Niektóre z nich to np.:

  • Wykonanie założonego procentu przypadków testowych zakończyło się sukcesem (nie zostały wykryte błędy).
  • Ilość wykrytych błędów (lub krzywa wykrywanych błędów) spadła poniżej założonego progu.
  • Pokrycie funkcjonalności testami (manualnymi, automatycznymi) osiągnęło założony zakres, np.:
    • przetestowano ręcznie najważniejszą ścieżkę,
    • pokrycie testami jednostkowymi na poziomie 90%.

Różne linki o testowaniu (i nie tylko;))

  1. Forum Forum Stowarzyszenia Jakości Systemów Informatycznych, gdzie poruszane są różne tematy o jakości oprogramowania i testowaniu: http://sjsi.org/forum/index.php
  2. Blog o testowaniu: http://www.testingminded.com/
  3. WebInject, jedno z darmowych narzędzi do automatycznego testowania, podobne nieco do JMetera. Jeśli dobrze pamiętam, próbowałam się nim bawić, ale „chemii między nami nie było”, zwłaszcza że nie chciało współpracować z proxy;) http://www.webinject.org/ . Ale to było dawno (2014) i nieprawda. Może już zostało naprawione 🙂
  4. Ciekawy artykuł „Signs that you’re a bad programmer”https://sites.google.com/site/yacoset/Home/signs-that-you-re-a-bad-programmer .
  5. Przykład tzw. Yoda condition:
    !"".equals(id)
    co stanowi krótszą formę od:
    !(id == null || id.equals(""))
  6. Artykuł o equals w Java: http://www.jakubiak.eu/2007/06/prawdy-o-equals.html.
  7. Zbiór linków o wzorcach projektowania stron, w kontekście usabilityhttp://www.webusability.pl/2008/05/13/design-patterns-czyli-wzorce-projektowe/.
  8. I na deser – fajne przykłady animowanych wykresów stworzonych w TeX: http://tex.stackexchange.com/questions/158668/nice-scientific-pictures-show-off.

Dobre praktyki w testach Selenium

kawa_selenium

Dobre praktyki w automatycznych testach w Selenium:

  • Podstawowa zasada – używanie aktywnego czekania (WebDriverWait, wait.Until, ImplicitlyWait itd.) zamiast Thread.Sleep, który spowalnia testy, nie dając jednocześnie gwarancji, że zastosowana przerwa jest odpowiednio długa (jest wiele artykułów na ten temat w sieci).
  • Wyszukiwanie elementów na stronie za pomocą selektorów CSS (By.CssSelector) lub identyfikatorów ID lub name (By.Id, By.Name) – taka metoda jest o niebo szybsza niż wyszukiwanie przez XPATH.
  • Używanie wzorca Page Object.

Oraz kilka dobrych praktyk, które mogą być stosowane ogólnie w testach, nie tylko Selenium:

  • DRY – Don’t Repeat Yourself – niepowielanie tego samego kodu poprzez tworzenie np. zestawów funkcji bibliotecznych, dobre rozplanowanie architektury testów, korzystanie z dostarczanych przez framework metod jak Test Setup, Teardown (np. ustawienie przeglądarki przed testami, zamknięcie przeglądarki po testach).
  • Behaviour Driven Testing – testy będą „bliżej autentycznego użytkownika”.
  • Logowanie błędów! Bardzo przydatne w przypadku testów uruchamianych na środowiskach Continuous Integration, gdzie jeśli testy nie mają logów, jedyną informacją, jaką dostarczą będzie „test nie przeszedł, coś nie działa”. Warto logować ścieżkę wykonanych akcji wraz z parametrami metod oraz informacje o środowisku na którym uruchomiono testy: system, przeglądarka, baza danych itd., godzina – a nuż błąd pojawia się na przykład pomiędzy 23 a 1 dnia następnego?, itd.
  • Screenshoty – jeżeli jest taka możliwość (a w Selenium jest) – stanowią wspaniałe źródło informacji o błędach. Nie wszystko da się wyczytać z logu – informacja typu „nie da się kliknąć kontrolki x” niewiele mówi – tymczasem „obraz wyraża więcej niż tysiąc słów”, a na screenie dokładnie widać, co się wydarzyło.

Może się wydawać (nadal!), że testy są niepotrzebne, są stratą czasu. Tymczasem są one w stanie wykryć defekty już na bardzo niskim poziomie (testy jednostkowe). Jeżeli aplikacja boryka się z problemami dużego długu technicznego, złej architektury a klasy cechują się wysokim sprzężeniem, próby modyfikacji aplikacji „na siłę”, byle tylko pokryć ją testami mogą niestety narobić więcej szkody, niż pożytku. W takim przypadku lepiej sprawdzi się metoda małych kroków. Implementując nowe funkcjonalności w aplikacji warto rozważyć piszanie testów jednostkowych tylko do nowych partii aplikacji (TDD). Przymierzając się natomiast do dużych zmian w całej aplikacji warto przygotować jak najwięcej wysokopoziomowych testów czarnoskrzynkowych (funkcjonalnych, integracyjnych). Nawet jeśli ich implementacja byłaby kosztowna w sensie czasowym lub finansowym, warto to zrobić. Optymalnym rozwiązaniem jest zautomatyzowanie owych testów. Minimalnym – spisanie wszystkich wymagań stawianych aplikacji (np. w formie proponowanej przez BDD).

Inspirację do tworzenia nowych przypadków testowych można czerpać również z błędów zgłaszanych przez użytkowników. To bardzo dobre źródło informacji o tym, w jaki sposób użytkownicy naprawdę używają aplikacji. Dobrze zgłoszony błąd zawiera pełną ścieżkę czynności potrzebnych do zreprodukowania błędu. Po jego naprawieniu, warto ją zautomatyzować.

How to check if element is invisible in Ruby Selenium client

How to check if element is invisible in Ruby Selenium client? In Java or C# answer is easy. There is a mechanism called ExpectedCondition, which has got ready for use method: ExpectedConditions.invisibilityOfElementLocated. Example:

driverWait.until(ExpectedConditions.invisibilityOfElementLocated(element));

Unfortunatelly, Ruby client hasn’t got anything like this. Quick workaround – try to find element. When element is not displayed, catch exception and return false:

def check_if_not_exist(locator)
  begin
    wait = Selenium::WebDriver::Wait.new :timeout => 10
    wait.until { @driver.find_element(:name, 'elementName').displayed? }
  rescue
    false
  end
end

Not very elegant and quick, but works.

 

Sprawdzanie czy checkbox jest zaznaczony w Selenium (C#)

Każdy z obiektów znalezionych przez Selenium jest standardowym obiektem typu WebElement. Udostępnia on następujące metody (których wartość zwracana jest typu bool):

  • displayed – element jest widoczny.
  • enabled – element jest aktywny – można go kliknąć, wpisać mu wartość itd. W praktyce każdy element dostępny na stronie ma stan enabled, gdyż jest to stan domyślny. „Wyłączyć” można go jedynie poprzez celowe dodanie do HTML atrybutu disabled. Element z takim atrybutem będzie „wyszarzony”.
  • checked – element jest zaznaczony. Dotyczy pól typu input – zarówno typu radio jak i checkbox.

Kawałek kodu HTML-owego, do którego zastosuję Selenium:


<html>
<body>
<form>
<input type="checkbox" />
</form>
</body>
</html>

Oraz fragment kodu C# z wykorzystaniem Selenium:


[Test]
public void CheckboxIsChecked()
{
  driver.url="file:///C:/DOCUMENTS/test.html";
  var el = driver.FindElement(By.TagName("input"));
  var before = el.Selected;//false
  el.Click();
  var after = el.Selected;//true
}

Selenium: Exception „Compound class names are not supported”

Today something about one of exceptions that can occure in Selenium PageFactory.

IllegalLocatorException was unhadled by user code.
An exception of type „OpenQA.Selenium.IllegalLocatorException” occured in WebDriver.dll but was not handled in user code.
Additional information: Compound class names are not supported. Consider searching for one class name and filtering the results.

In my case, this exception was thrown in line:

PageFactory.InitElements(webDriver, pageElement);

This is probably a bug in Selenium. Solution is easy: just do not use:

[FindsBy(How=How.ClassName, Using="name_of_class"]

Instead of ClassName, try to use Css Selectors:

[FindsBy(How=How.CssSelector, Using=".name_of_class"]

Remember about a dot!

Testowanie – notatki

Pod rękę nawinęła mi się kartka z notatkami – bodajże do egzaminu ISTQB.

Negative testing scenarios – przykładowe:

  • testowanie błędnymi wartościami
  • niewypełnienie pól wymaganych
  • niepoprawny typ danych
  • więcej/mniej znaków niż wymagane
  • większy/mniejszy zakres danych, niż spodziewa się program
  • testy z manipulowaniem sesją w przeglądarce
  • zduplikowanie wartości, pól, brak pól (np. w webservisie)

Testowanie mutacyjne – sprawdzanie, na ile testy jednostkowe rzeczywiście sprawdzają kod. Automatyczne wprowadzanie losowych błędów w programie (posiewanie błędów) i uruchamianie testów jednostkowych, by sprawdzić, czy wykryły one wprowadzone błędy. Wymaga dużej mocy obliczeniowej.

Fuzz testing – wprowadzenie niepoprawnych, nieoczekiwanych, losowych danych, obserwacja i czekanie na awarię. Ma dwa rodzaje: fuzzing mutacyjny lub generacyjny. Tego typu testy mogą być wykonane na wielu poziomach, np. niskopoziomowe – na etapie np. mieszania w pamięci dzielonej lub nieco wyższe – na etapie danych wejściowych do komponentów programu.

Testowanie strony w różnych wersjach IE

Każdy, kto zajmował się aplikacjami webowymi pamięta problemy z kompatybilnością i różnym wyświetlaniem stron w przeglądarkach Internet Explorer. Wynika to z odmiennej interpretacji HTML, CSS czy JavaScript przez te przeglądarki. W jeszcze nie tak dawnych czasach, stanowiło to nie lada wyzwanie. Trudno było wówczas dysponować farmą komputerów z różnymi wersjami IE, zwłaszcza że pociągało to za sobą także posiadanie różnych systemów operacyjnych (Windows XP i różne service packi, Windows 7 itd.). Pamiętam programy, które miały emulować zachowanie różnych wersji IE, nie były one jednak wystarczająco miarodajne.

Od pewnego czasu, za pośrednictwem serwisu http://modern.ie Microsoft oferuje zestaw narzędzi ułatwiających owe zadanie. Jest to m.in. możliwość zalogowania się do zdalnych maszyn z różnymi wersjami przeglądarki, zrobienia screenshotów, jak strona wygląda pod rożnymi przeglądarkami:

screen-microsoft-ie-scan

Oraz, co najciekawsze, pakiet maszyn wirtualnych, dostępnych do ściągnięcia z adresu: Czytaj dalej

Recenzja – Dane testowe. Teoria i praktyka

Tytuł książki „Dane testowe. Teoria i praktyka” autorstwa Radosława Smilgina i Anny Piaskowy (wydawnictwo Helion), bardzo dokładnie mówi, czego możemy się spodziewać po lekturze. Tak – w dużej mierze – danych testowych.

dane_testowe

W pierwszej części książki autorzy wprowadzają kilka znanych z egzaminu ISTQB technik testowania (klasy równoważności, wartości brzegowe itd.) oraz definiują, czym są dane testowe. Przydatna ściągawka dla osób początkujących. Czytaj dalej