пятница, 9 ноября 2012 г.

Почему 100%-е прохождение тестов - это плохо.[перевод]


Why 100% Test Pass Rates Are Bad by Andrew Schiano

Когда тест показывает оценку 100%, как правило есть причина для ликования. Это означает, что у вашего продукта высокое качество. Тесты, которые так тщательно разработаны, проходят, доказывая, что продукт работает так, как ожидалось. Также показывает, что ваши тестовые случаи высокого качества; результаты воспроизводимы, и они успешно проверяют функциональность продукта. Эта та цель, к которой ты стремился с начала тестирования, правильно? Если это так, то вы выбрали неверную цель.
100%-е прохождение подразумевает, что ваш продукт работает точно, как ожидалось. Задача тестирования, однако, не доказывать, что приложение работает, как ожидалось. В сущности, эта цель может даже не достижима, потому что все сложные приложения имеют дефекты. Какой смысл всё это делать, имея цель, которая не может быть достигнута? Ваша цель должна быть в написании тестов, которые обнажают эти дефекты так, чтобы можно было сделать обоснованное решение об их исправлении.
Другая причина неверной цели 100%-го прохождения в заключается том что, когда все ваши тесты последовательно проходят, они прекращают обеспечивать вас новой информацией. Вы можете наблюдать прекрасный проход тестов каждое утро, и в дальнейшем не обращать внимание на них. Другими словами, как только вы достигнете своей "цели", ваши тесты перестанут помогать вам улучшить ваш продукт.
Чтобы быть справедливым, с точки зрения управления 100%-й проход тестов это верная цель. Так как это убеждает менеджера в качестве продукта. Но если менеджер и тестировщик оба стремятся к совершенному проходу тестов, это не вызывает доверия. В этом случае, никто не ищет баги и 100% проход тестов мало чего значит.
Теперь предположим у вас прекрасный проход тестов, но тестировщики должны стремится доказать, что приложение не работает как ожидалось. Прекрасный проход тестов показывает руководству, что несмотря на факт о том, что вы ищете баги, вы всё ещё не можете найти их. Это дает уверенность руководству в области качества программного обеспечения.
Если у вас 100%-й проход тестов, и есть ещё время до Завершения Всего Тестирования, не думайте что это конец игры. В продукте есть ошибки, и ваши тесты не могут найти их. Измените тесты. Напишите новые. Но продумайте каждый тестовый случай с целью доказать, что программное обеспечение не работает как ожидалось.  Рекомендации могут показаться очевидными, а некоторые тестировщики не подумают в таком плане; они очень сильно заинтересованны иметь гладкий тест и по плану.
Edsger Dijkstra писал, "Тестирование может показать присутствие ошибок, но не их отсутствие." Как только вы измените ваш тип мышления и напишите тесты доказывающие, что продукт не работает, вместо того, чтобы доказывать, что он работает, вы будете удивлены, как насколько больше ошибок вы обнаружите. Это простое изменение сделает из вас лучшего тестировщика, и вашим продуктам будет лучше от этого.

вторник, 6 ноября 2012 г.

Page Object Pattern быстрая визуализация

Сценарий нашего будущего приложения будет вот такой, заметьте я ещё не написал ни строчки кода [Есть такая умная мысль: "A carelessly planned project takes three times longer to complete thanexpecteda carefully planned project takes only twice as long."], Итак приступим:
1. заходим на страницу google.ru;
2. набираем в поиске Selenium;
3. дёргаем список все найденные ответы, возможно бегаем ещё на пять страниц в глубину(организуем постраничный переход), при нахождении Хабрахабра  переходим по его ссылке;
4. проверяем действительно ли мы туда попали, куда хотели, проверяем жёстко с вылетом теста если будет коллизия;
5. на странице habrahabra выбираем статью с названием "Что такое Selenium?";
6. собираем все комментарии к этой статье и сохраняем в файл.

Вот такую схему я быстро накидал в paint, сам я делаю это обычно на бумажке карандашиком, быстренько и без затей. Читается она очень просто, прямоугольники - это страницы сайта, а овалы - это методы которые либо ведут к другой странице[как например:Set Search Request, Gone Link Text], либо остаются на той же странице[как например: Gone On Number Page, Comments Save File]. В схему я намеренно не включаю проверки, они просто захламляют, да и надобавлять их уже после написания "кода" не проблема.




понедельник, 8 октября 2012 г.

Перевёл тесты Selenium WebDriver на браузер Google Chrome

Для работы нам понадобится
1. Java тут всё довольно тривиально, просто всегда делее;
2. Необходимо установить JDK
рис.1
На следующей странице принимаем соглашение и качаем нужный установочный файл(в моём случае это jdk-7u7-windows-x64.exe)
рис.2

3. Eclipse скачиваем в зависимости от нужд могу лишь посоветовать одну из первых трёх(для этого проекта)
рис.3

Сразу к сути дела,  тесты выполняю в Eclipse, распишу всё подетально:
1. Создаём проект, правой кнопкой на молоке New > Java Project,
рис.4
обзываем его exampleProject > Finish 
рис.5

2. Добавляем в проект новый класс

рис.6

 и называем его exampleGoTOGoogle

рис.7

3. Открываем свойства проекта, 
рис.8
далее в Java Build Path > вкладка Libraries > кнопка Add Library > выбираем User Library
рис.9
после нажатия кнопки Next открывается окно User Library > тыкаем на кнопку User Libraries... > кнопку New > даём любое произвольное название, в данном случае sel > кликаем на Ok > Finish.
рис.10

4. Так теперь необходимо добавить в эту пользовательскую библиотеку selenium 
- открываем сайт selenium и скачиваем:
рис.11
после распаковываем, желательно на C:\ диск (в данном примере так "C:\selenium-2.25.0"). Добавляем в пользовательскую библиотеку selenium-java-2.25.0.jar : Выбираем sel > кнопка Edit >  User Libraries > выбираем sel > Add External Jars >  в диалоговом окне отмечаем selenium-java-2.25.0.jar > Открыть
рис.12
ok> Finish >ok. Ещё необходимо добавить всё, что есть в папке lib(находится она в той же папке что и selenium-java-2.25.0.jar), алгоритм действий аналогичен предыдущему добавлению:
рис.13

5. Добавим в наш проект пакет и назовем его start:
рис.14


перетаскиваем наш класс exampleGoTOGoogle в только что созданный пакет start посредством Drag&Drop'а (зажимаем левой кнопкой мыши на классе, тащим его на пакет и отпускаем левую кнопку мыши). В итоге получаем:
рис.15

Приступим к созданию теста, на Selenium WebDriver в браузере Google Chrome.
1.  Вот скрин всего кода
рис.16
как видите "программка" не очень большая. 
Сценарий:
- заходим на страницу www.google.ru;
- набираем в поиске "Selenium";
- дергаем в список(грубо говоря в массив строк) все найденные ссылки;
- из полученного списка выбираем ссылку на Хабрахабр и переходим по ней;
- естественно "жёстко" проверяем(с завалом теста), что страница открылась именно habrahabr;
- чуть чуть ждём. 
1. Сначала цепляем все эти модули 
import static org.junit.Assert.*;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.JavascriptExecutor;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import static org.junit.Assert.*; - необходим для жёсткой проверки в конце теста;
import java.util.List; - позволит создать список (массив строк) ссылок на странице результата поиска;
import java.util.concurrent.TimeUnit; - тут из названия ясно что работает с time, необходимо для организации задержки;
import org.junit.After; - этот модуль позволяет как бы обозначить метод [в нашем случае это public void tearDown() ] который заработает после окончания теста [After - после];
import org.junit.Before; - этот модуль позволяет как бы обозначить метод [в нашем случае это public void setUp() ] который заработает перед началом теста [Before - перед, до];
import org.junit.Test; - ну этот метод объясняет JUnit что последующий метод и есть тест[у меня это - public void testGoogle()];
import org.openqa.selenium.Keys; - позволяет работать с клавишами;
import org.openqa.selenium.JavascriptExecutor; - открывает возможность вставлять Javascript код в тело WebDriver теста;
import org.openqa.selenium.chrome.ChromeDriver; - это драйвер Google Chrome;
в остальном и так понятно. Вот так это выглядит:

рис.17

Далее создаём переменную[с типом WebDriver] под будущий браузер.
public WebDriver driver;
рис.18

и Метод @Before  который его и инициализирует
рис.19
Тут очень важный момент чтобы тесты запустились в Google Chrome необходимо скачать Драйвер для Google Chrome  у него такая особенность, распакуйте в папку с селениумом, я выбрал вот этот:
рис.20
в коде метода @Before есть строка которая указывает где этот chromedriver лежит
System.setProperty("webdriver.chrome.driver","C:\\selenium-2.25.0\\chromedriver.exe");
только учтите что один символ \ должен экранироваться повторным \, и желательно в пути к файлу не иметь папок с русскими именами, Eclipse не поймёт(у меня не одобряет выдаёт ошибки). Далее мы оговариваем что создаётся новый экземпляр хрома:
driver = new ChromeDriver();
 и задаём ожидание элемента на странице, если его по какой то причине не оказалось(сайт долго грузится, элемент тяжёлый и долго подтягивается и т.п.) задержка в 10 секунд:
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
Вот код метода, где и происходит самое интересное:
рис.21
 По порядку:
driver.get("http://www.google.ru/");  - открываем браузер и заходим на сайт google.ru
driver.findElement(By.name("q")).sendKeys("selenium"); - на полученной странице находим элемент с параметром name равным "q",  здесь find - поиск Element - элемент, внутри скобок применяется механизм By у которого есть метод name("text") - в свою очередь он ищет все элементы с именем text. sendKeys("selenium"); - тут всё опять просто (send - послать Keys - клавиши) это метод который просто печатает поклавишно принимаемый текст.
driver.findElement(By.name("q")).sendKeys(Keys.ENTER); - после набора текста в этом же поле нажимается клавиша ENTER, она "дёргается" из модуля Keys.
List<WebElement> urls = driver.findElements(By.tagName("h3")); - тут создаётся список веб-элементов(WebElement) с именем urls, в него запихиваются все найденные элементы с тегом h3 (tagName - поиск по тегу). В данном случае все найденные будут содержать ссылки по запросу h3>a.
for (WebElement url : urls) {
if (url.getAttribute("textContent").contains("Хаб")) {
driver.navigate().to(
url.findElement(By.tagName("a")).getAttribute("href"));
break;
}
}
Тут организуется цикл по списку, который посматривает у h3 элемента контекстный текст на присутствие "Хаб"[.contains("Хаб")], в итоге будет переход по отсеянной ссылке[driver.navigate().to()] и дальнейший выход из цикла [break]. Перейдя на искомую страницу нам необходимо дёрнуть JavaScript'ом адрес открывшейся страницы:
String getUrlOpenPage = (String) ((JavascriptExecutor) driver)
.executeScript("return window.document.location.toString();");
 Далее проверяем полученную от JavaScript'а строку на присутствие в ней адреса сайта habrahabr.:
assertTrue(getUrlOpenPage.contains("habrahabr.ru"));
После всех приключений подождём чуть чуть, а именно, 8 секунд:
try {
Thread.sleep(8000);
} catch (InterruptedException e) {
e.printStackTrace();
 Заключительная стадия "программы" завершает работу браузера
рис.22
Вот в принципе всё, только ещё один момент, у вас на компьютере должен быть установлен браузер Google Chrome.

Да чуть не забыл, тесты запускаются
рис.23
правой кнопкой на проекте или классе-теста > Run As > # Junit Test.
Но может оказаться так, что JUnit'а нет в Eclipse, его можно установить через Help > Install New Software
рис.24
Хотя скорее всего он уже будет в сборке Eclipse.