eroshenkoam 31 окт 2013 в 16:00

Опыт от Яндекса. Как делать свой отчет для автотестов

15 мин

22K

Блог компании ЯндексТестирование IT-систем*

Туториал

Хочу поделиться опытом, о том, как создавать хорошие отчёты об автотестах и одновременно пригласить вас на первое мероприятие Яндекса специально про тестирование.

Сначала пару слов о событии. 30 ноября в Санкт-Петербурге мы проведём Тестовую среду — своё первое мероприятие специально для тестировщиков. Там мы расскажем, как у нас устроено тестирование, что мы сделали для его автоматизации, как работаем с ошибками, данными и графиками и о многом другом. Участие бесплатное, но мест всего 100, поэтому надо успеть зарегистрироваться.

Тестовая среда для нас в первую очередь — площадка для общения. Мы хотим не только рассказать о себе, но и поговорить с участниками о том, как работают они, обменяться знаниями, ответить на какие-то вопросы. Думаем, общих тем будет много, но чтобы вы начали обдумывать их уже сейчас, мы начинаем серию публикаций о тестировании в Яндексе.

Автоматизации тестирования на Тестовой среде будет посвящено несколько докладов, в том числе мой. Итак, начну.

Бывают unit-тесты, а бывают высокоуровневые. И когда их количество начинает расти, анализ результатов запусков становится проблемой. Скажите честно, кто из вас не думал сделать свой отчет?

С подробными логами, скриншотами, дампами запросов/ответов и прочей дополнительной информацией (которая, к слову, существенно облегчает обнаружение конкретных причин ошибки). Уверен, что некоторые даже преуспели в этом деле. Проблема заключается в том, что сделать один универсальный отчет для всех типов тестов сложно, а делать отдельный отчет под конкретную задачу — долго. Если, конечно, вы случайно не используете jUnit и Maven. В таком случае сделать простенький отчет для конкретного типа тестов можно за несколько часов. Давайте разберемся, зачем же нам нужен отчет тестов, отличный от xUnit?

Высокоуровневые тесты отличаются от unit-тестов и обладают рядом особенностей:

Они затрагивают гораздо больше функциональности, что затрудняет локализацию проблемы. Так, например, тест через web-интерфейс затрагивает функциональность API, которая в свою очередь затрагивает функциональность базы, которая в свою очередь… ну, вы поняли.
Такие тесты воздействуют на систему через посредников. Это может быть браузер, http-сервер, proxy, third-party системы, в которых в тоже содержится своя логика.
Подобных тестов обычно довольно много и зачастую приходится вводить дополнительную категоризацию. Это могут быть компоненты, области функциональности, критичность.

Все эти факторы существенно замедляют скорость локализации проблемы. Например, вот что может означать ошибка в тесте на web-интерфейс «Can not click on element «Search Button»»:

страница не загрузилась по таймауту;
на странице отсутствует элемент Search Button;
элемент Search Button присутствует, но кликнуть на него невозможно;
на дата центр, в котором крутится сервис, упал метеорит.

Если же к результатам данного теста добавить скриншот, исходники страницы, сетевой лог и сводку новостей по космической активности в районе датацентра, то указать на конкретную проблему будет гораздо легче, а значит, мы потратим меньше времени. В таком случае возникает и потребность в специфическом отчете с дополнительной информацией.

Жил-был тест

В качестве подопытного для наших экспериментов возьмем совершенно обычный тест:

public class ScreenShotDifferTest {

    private final long DEVIATION = 20L;

    private WebDriver driver = new FirefoxDriver();

    public ScreenShooter screenShooter = new ScreenShooter();

    @Test
    public void originPageShouldBeSameAsModifiedPage() throws Exception {
        BufferedImage originScreenShot = screenShooter.takeScreenShot("http://www.yandex.ru", driver);
        BufferedImage modifiedScreenShot = screenShooter.takeScreenShot("http://beta.yandex.ru", driver);
        long diffPixels = screenShooter.diff(originScreenShot, modifiedScreenShot);
        assertThat(diffPixels, lessThan(DEVIATION);
    }

    @After
    public void closeDriver() {
        driver.quit();
    }
}

Пройдемся по коду:

инициализируем driver;
инициализируем screenShooter;
снимаем скриншот страницы-оригинала;
снимаем скриншот страницы-кандидата;
считаем количество различающихся пикселей;
проверяем, что количество различающихся пикселей не превышает допустимое отклонение;
закрываем driver.

В таком виде тестом можно пользоваться и без красивого отчета, так как он всегда сравнивает одну и ту же страницу с собой. Но этот тест будет значительно эффективнее, если в него добавить стандартную jUnit параметризацию:

 @RunWith(Parameterized.class)
public class ScreenShotDifferTest {

    ...
    
    private String originPageUrl;
    
    private String modifiedPageUrl;
 
    public ScreenShotDifferTest (String originPageUrl, String modifiedPageUrl) {
        this.modifiedPageUrl = modifiedPageUrl;
        this.originPageUrl = originPageUrl;
    }

    @Parameterized.Parameters(name = "{0}")
    public static Collection<Object[]> readUrlPairs () {
        return Arrays.asList(
                new Object[]{"Yandex Main Page", "http://www.yandex.ru/", "http://beta.yandex.ru/"},
                new Object[]{"Yandex.Market Main Page", "http://market.yandex.ru/", "http://beta.market.yandex.ru/"}
        );
    }
    
    ...
}

Данные лучше подтягивать из хранилища, к которому имеет доступ человек, использующий тест. Но для наглядности приведенный способ подходит как нельзя лучше.

Итак, представим, что у нас не 2 параметра, а 20, или лучше 200. Стандартный отчет о прохождении теста будет выглядеть так:

Какой вывод можно сделать из отчета тестов?

Давайте вместе подумаем, какие данные нам нужны для того, чтобы быстро принять решение о наличие ошибок:

Скриншоты страницы оригинала и кандидата.
Скриншоты дифа (можно, например, все различающиеся пиксели пометить красным)
Исходники страницы оригинала и кандидата.

При наличии таких данных сделать выводы о проблемах будет значительно легче, а значит — дешевле.

Реализация отчета

Для того чтобы построить расширенный отчет тестов, нам нужно пройти три стадии:

Модель. В ней будет содержаться вся информация, необходимая для отображения в отчете.
Адаптер. Он должен собирать всю необходимую информацию из теста в модель.
Генерация отчета. По собранным данным генерируем отчет на основе шаблонов.

Итак, по порядку.

Модель

Для решения этой задачи мы будем использовать xsd-схемы для последующей генерации java-классов с помощью Java JAXB. К счастью, наша модель содержит немного данных и легко описывается схемой.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns:ns="urn:report.examples.qatools.yandex.ru" targetNamespace="urn:report.examples.qatools.yandex.ru" version="2.1">

    <xsd:element name="testCaseResult" type="ns:TestCaseResult"/> <!--Результат выполнения теста-->
    <xsd:complexType name="TestCaseResult">
        <xsd:sequence>
            <xsd:element name="description" type="xsd:string"/> <!--Чтобы понять что именно проверялось в тесте-->
            <xsd:element name="origin" type="ns:ScreenShotData" nillable="false"/> <!--Данные страницы эталона (обычно эталон или продакшен)-->
            <xsd:element name="modified" type="ns:ScreenShotData" nillable="false"/> <!--Данные страницы кандидата на релиз (обычно берется бета)-->
            <xsd:element name="diff" type="ns:DiffData" nillable="false"/> <!--Данные различий двух скриншотов-->
            <xsd:element name="message" type="xsd:string"/> <!--Сообщение об ошибке, если она есть-->
        </xsd:sequence>
        <xsd:attribute name="uid" type="xsd:string"/> <!--ID-шник теста-->
        <xsd:attribute name="title" type="xsd:string"/> <!--Краткое название теста, чтобы понимать что проверялось--> 
        <xsd:attribute name="status" type="ns:Status"/> <!--Статус завершения теста--> 
    </xsd:complexType>

    <xsd:complexType name="ScreenShotData">
        <xsd:sequence>
            <xsd:element name="pageUrl" type="xsd:string"/> <!--Урл страницы, с которой снят скриншот--> 
            <xsd:element name="fileName" type="xsd:string"/> <!--Название файла со скриншотом--> 
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="DiffData">
        <xsd:sequence>
            <xsd:element name="pixels" type="xsd:long" default="0"/> <!--Количество различающихся пикселей--> 
            <xsd:element name="fileName" type="xsd:string"/><!--Название файла с дифом--> 
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="Status">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="OK"/>
            <xsd:enumeration value="FAIL"/>
            <xsd:enumeration value="ERROR"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>

Схема готова! Теперь осталось сгенерировать по этой схеме классы. Для этого применим мощный maven-jaxb2-plugin. Плюс этого плагина в том, что классы генерируются при каждой компиляции. Таким образом, можно на 100% быть уверенным, что сгенерированный код соответствует схеме, и избавить себя от ошибок, типа «Ой, я забыл перегенерить...» Результатом работы плагина будут сгенерированные классы (осторожно — они огромные):

TestCaseReport

/**
 * <p>Java class for TestCaseResult complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * <complexType name="TestCaseResult">
 *   <complexContent>
 *     <restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       <sequence>
 *         <element name="message" type="{http://www.w3.org/2001/XMLSchema}string"/>
 *         <element name="description" type="{http://www.w3.org/2001/XMLSchema}string"/>
 *         <element name="origin" type="{urn:report.examples.qatools.yandex.ru}ScreenShotData"/>
 *         <element name="modified" type="{urn:report.examples.qatools.yandex.ru}ScreenShotData"/>
 *         <element name="diff" type="{urn:report.examples.qatools.yandex.ru}DiffData"/>
 *       </sequence>
 *       <attribute name="uid" type="{http://www.w3.org/2001/XMLSchema}string" />
 *       <attribute name="title" type="{http://www.w3.org/2001/XMLSchema}string" />
 *       <attribute name="status" type="{urn:report.examples.qatools.yandex.ru}Status" />
 *     </restriction>
 *   </complexContent>
 * </complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "TestCaseResult", propOrder = {
    "message",
    "description",
    "origin",
    "modified",
    "diff"
})
public class TestCaseResult {

    @XmlElement(required = true)
    protected String message;
    @XmlElement(required = true)
    protected String description;
    @XmlElement(required = true)
    protected ScreenShotData origin;
    @XmlElement(required = true)
    protected ScreenShotData modified;
    @XmlElement(required = true)
    protected DiffData diff;
    @XmlAttribute(name = "uid")
    protected String uid;
    @XmlAttribute(name = "title")
    protected String title;
    @XmlAttribute(name = "status")
    protected Status status;

    /**
     * Gets the value of the message property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getMessage() {
        return message;
    }

    /**
     * Sets the value of the message property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setMessage(String value) {
        this.message = value;
    }

    /**
     * Gets the value of the description property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getDescription() {
        return description;
    }

    /**
     * Sets the value of the description property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setDescription(String value) {
        this.description = value;
    }

    /**
     * Gets the value of the origin property.
     * 
     * @return
     *     possible object is
     *     {@link ScreenShotData }
     *     
     */
    public ScreenShotData getOrigin() {
        return origin;
    }

    /**
     * Sets the value of the origin property.
     * 
     * @param value
     *     allowed object is
     *     {@link ScreenShotData }
     *     
     */
    public void setOrigin(ScreenShotData value) {
        this.origin = value;
    }

    /**
     * Gets the value of the modified property.
     * 
     * @return
     *     possible object is
     *     {@link ScreenShotData }
     *     
     */
    public ScreenShotData getModified() {
        return modified;
    }

    /**
     * Sets the value of the modified property.
     * 
     * @param value
     *     allowed object is
     *     {@link ScreenShotData }
     *     
     */
    public void setModified(ScreenShotData value) {
        this.modified = value;
    }

    /**
     * Gets the value of the diff property.
     * 
     * @return
     *     possible object is
     *     {@link DiffData }
     *     
     */
    public DiffData getDiff() {
        return diff;
    }

    /**
     * Sets the value of the diff property.
     * 
     * @param value
     *     allowed object is
     *     {@link DiffData }
     *     
     */
    public void setDiff(DiffData value) {
        this.diff = value;
    }

    /**
     * Gets the value of the uid property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getUid() {
        return uid;
    }

    /**
     * Sets the value of the uid property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setUid(String value) {
        this.uid = value;
    }

    /**
     * Gets the value of the title property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getTitle() {
        return title;
    }

    /**
     * Sets the value of the title property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setTitle(String value) {
        this.title = value;
    }

    /**
     * Gets the value of the status property.
     * 
     * @return
     *     possible object is
     *     {@link Status }
     *     
     */
    public Status getStatus() {
        return status;
    }

    /**
     * Sets the value of the status property.
     * 
     * @param value
     *     allowed object is
     *     {@link Status }
     *     
     */
    public void setStatus(Status value) {
        this.status = value;
    }
}

Классы тоже готовы. Nеперь можно легко и просто сериализовать объекты в xml-файлы:

TestCaseResult testCaseResult = ...
JAXB.marshal(testCaseResult, file);

И зачитывать объекты из xml-файла

TestCaseResult testCaseResult = JAXB.unmarshal(file, TestCaseResult.class)

Адаптер

Напомню, что адаптер нам необходим для того, чтобы заполнять модель данными из теста во время его выполнения. Для реализации адаптера мы воспользуемся механизмом jUnit Rules, а если быть точнее, то TestWatcher Rule:

public abstract class TestWatcher implements org.junit.rules.TestRule {

    //обязательно вызывается перед началом теста
    protected void starting(org.junit.runner.Description description) {...}
    //этот метод вызывается в случае успешного завершения теста
    protected void succeeded(org.junit.runner.Description description) {...}
    //этот метод вызывается, если //вы используете// !!(сработает)!! assumeThat()
    protected void skipped(org.junit.internal.AssumptionViolatedException e, org.junit.runner.Description description) {...}
    //этот метод будет вызван в случае возникновения ошибки в тесте
    protected void failed(java.lang.Throwable e, org.junit.runner.Description description) {...}
    //обязательно вызывается после завершения теста
    protected void finished(org.junit.runner.Description description) {...}
}

Давайте последовательно рассмотрим каждый метод и подумаем где можно собрать необходимые данные.

```
protected void starting(org.junit.runner.Description description)
```
— добавим в него инициализацию модели TestCaseResult и создание всех необходимых файлов.
```
protected void succeeded(org.junit.runner.Description description)
```
— в нем проставим статус OK выполнения нашего теста.
```
protected void skipped(org.junit.internal.AssumptionViolatedException e, org.junit.runner.Description description)
```
— нас этот метод никак не интересует. Его можно оставить без изменения.
```
protected void failed(java.lang.Throwable e, org.junit.runner.Description description)
```
— здесь у нас будет условная логика. Если
```
e instanceOf AssertionViolatedException
```
, то в тесте произошла ошибка (FAIL), в любом другом случае — тест сломан (ERROR).
```
protected void finished(org.junit.runner.Description description) 
```
— тут сериализуем объект TestCaseResult в xml.

Кроме всего вышеперечисленного, наша рула должна уметь снимать и сохранять скриншоты, что описано в методах:

```
public BufferedImage takeOriginScreenShot(String url)
```
— снимаем скриншот страницы оригинала по урлу, сохраняем скриншот на файловую систему, линкуем к данным и возвращаем BufferedImage.
```
public BufferedImage takeModifiedScreenShot(String url)
```
— те же самые операции, только для страницы кандидата.
```
public DiffData diff(BufferedImage original, BufferedImage modified)
```
— получаем дифф двух скриншотов, сохраняем на файловую систему, линкуем к данным и возвращаем объект с информацией о различиях.

Все файлы будем складывать в директорию target/site/custom, так как она является дефолтной для отчетов.

После использования 'ScreenShotDifferRule', наш тест практически не изменится:

@RunWith(Parameterized.class)
public class ScreenShotDifferTest {

    private String originPageUrl;

    private String modifiedPageUrl;
    
    ...

    @Rule
    public ScreenShotDifferRule screenShotDiffer = new ScreenShotDifferRule(driver);

    public ScreenShotDifferTest(String title, String originPageUrl, String modifiedPageUrl) {
        this.modifiedPageUrl = modifiedPageUrl;
        this.originPageUrl = originPageUrl;
    }

    ...
    
    @Test
    public void originShouldBeSameAsModified() throws Exception {
        BufferedImage originScreenShot = screenShotDiffer.takeOriginScreenShot(originPageUrl);
        BufferedImage modifiedScreenShot = screenShotDiffer.takeModifiedScreenShot(modifiedPageUrl);
        long diffPixels = screenShotDiffer.diff(originScreenShot, modifiedScreenShot);

        assertThat(diffPixels, lessThan((long) 20));
    }
    
    ...
}

Теперь с помощью несложной ScreenShotDifferRule после выполнения каждого теста мы будем получать структурированные данные в таком виде:

1. {uid}-testcase.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testCaseResult status="OK" title="originShouldBeSameAsModified[0](ru.yandex.qatools.examples.report.ScreenShotDifferTest)" uid="ru.yandex.qatools.examples.report.ScreenShotDifferTest.originShouldBeSameAsModified[0]">
    <origin>
        <pageUrl>http://www.yandex.ru/</pageUrl>
        <fileName>{uid}-origin.png</fileName>
    </origin>
    <modified>
        <pageUrl>http://www.yandex.ru/</pageUrl>
        <fileName>{uid}-modified.png</fileName>
    </modified>
    <diff>
        <pixels>0</pixels>
        <fileName>{uid}-diff.png</fileName>
    </diff>
</testCaseResult>

2. {uid}-origin.png

3. {uid}-diff.png

Генерация отчета

Нам нужно реализовать Maven Report Plugin, который соберет все {{uid}}-testcase.xml-ки в одну и на ее основе сгенерирует html-страничку. Для этого в нашу модель добавим объект-агрегатор TestSuiteResult всех TestCaseResult-ов. Не буду глубоко закапываться в область создания плагинов для Maven — это тема для отдельной статьи. Вместо этого предлагаю рассмотреть уже готовый плагин, который решает нашу задачу.

Итак, у нас есть ScreenShotDifferReport Plugin. Сердцем плагина является метод public void exec (). В нашем случае он должен:

Найти все файлы с данными о прохождении тестов.
```
File[] testCasesFiles = listOfFiles(reportDirectory, ".*-testcase\\.xml");
```

Прочитать их и конвертировать в объекты.

List<TestCaseResult> testCases = convert(testCasesFile, new Converter<File, TestCaseResult>(){
   public TestCaseResult convert (File file) {
      return JAXB.unmarshall(file, TestCaseResult.xml);
   }  
});

На основе данных сгенерировать index.html. В качестве шаблонизатора можно использовать freemarker и этот шаблон.
```
String source = processTemplate(TEMPLATE_NAME, testCases);
```
Добавить информацию об этом отчете в группирующий maven-отчет.
```
Sink sink = new Sink();
sink.setHtml(source);
sink.close();((
```

Чтобы получить готовый отчет нам нужно выполнить команду mvn clean install. Для простоты можно выкачать проект github.com/yandex-qatools/tests-report-example и выполнить команду для него. В результате выполнения команды в модуле tests-report-example в директории target/site/ вы увидите отчет по проекту.

Проверка результата

Теперь нужно выполнить инсталляцию всего проекта. Для этого в корне проекта выполним команду mvn clean install. После её выполнения мы получим артефакты, готовые для использования. Подключаем наш новоиспеченный плагин к проекту автотестов вместе со стандартным surefire-плагином.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-site-plugin</artifactId>
   <version>3.2</version>
   <configuration>
      <reportPlugins>
         <plugin>
            <groupId>ru.yandex.qatools.examples</groupId>
            <artifactId>custom-report-plugin</artifactId>
            <version>${project.version}</version>
         </plugin>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-report-plugin</artifactId>
            <version>2.14.1</version>
         </plugin>
      </reportPlugins>  
   </configuration>
</plugin>

И выполняем команду mvn clean site.

Вуаля! После прохождения тестов выполнится фаза site, в рамках которой будет сгенерировано два отчета: SureFire Report и Custom Report.

«Зачем же строить два отчета?» — спросите вы. Дело в том, что механизм jUnit Rules не совершенен. Если в конструкторе теста или в методе параметризации вылетит исключение, то рула не будет создана, а значит, данные для построения отчета не будут собраны. Что в свою очередь означает, что тест в отчет не попадет. Можно усовершенствовать процесс сбора данных с помощью RunListener или Runner, но кажется, что это избыточная логика. Вся информация касательно сломанных тестов есть в SureFire отчете.

Итог

Итак, мы научились строить простенькие отчеты с помощью расширений фреймворков jUnit и Maven.

Плюсы

Бесплатно получаем все возможности jUnit-фреймворка для запуска и организации тестов (параллельный запуск, параметризация, категории).
Четко разделяем данные и представление. Вы можете сделать адаптер на другом языке (например, на python), но использовать тот же плагин для генерации представления. Или использовать разные плагины для одних и тех же данных.
Бесплатно получаем логику доставки отчетов в хранилище (ssh, https, ftp, webdav и т.д.) с помощью Maven Wagon Plugin.
Можем генерировать «частичный отчет». Это достигается благодаря разделению потоков выполнения тестов и построения отчетов. Один поток выполняет тесты (которые генерируют данные), а второй периодически строит отчет.

Минусы

Требуется хорошее знание технологий (XSD, JAXB, jUnit Rules, Maven Reporting Plugin). Если что-то пойдет не так, рискуете потерять много времени.
Довольно сложно тестировать весь цикл построения сложного отчета (от схемы до html)