TestLink

Ссылки сюда (2) →

Общая информация

TestLink это система управления тестами с веб-интерфейсом.

Вот типичный пример использования системы:

1. Администратор создает проект «Фаст-фуд» и двух пользователей: Адама, с правами «Leader» и Еву с правами «Senior tester».
2. Адам импортирует список требований к программному обеспечению, и для некоторых из этих требований создает пустые тесты. Вообще, более корректно говорить о сценариях тестов или тест-кейсах, но так как других тестов (автоматических, модульных, юнит-тестов) в системе нет, то далее мы будем называть эти сценарии тестирования тест-кейсами.
3. Тестировщица Ева пишет тестовые сценарии для этих тест-кейсов, и группирует тест-кейсы в группы тестов.
4. Адам создает ключевое слово «Регрессия» и привязывает его к десятку тестов.
5. Адам создает план тестирования «Рыба и Чипсы», сборку «Рыба 0.1» и включает в этот план тесты с ключевым словом «Регрессия».
6. Адам и Бела выполняют тесты и записывают результат: 5 пройдено, 1 провален, и 4 заблокировано (нет возможности выполнить требуемые проверки).
7. Разработчики формируют новую сборку «Рыба 0.2» и Бела тестирует только проваленные и заблокированные тесты. На удивление, все эти пять тестов успешно выполняются.
8. Руководитель команды желает взглянуть на результаты. Он самостоятельно заводит для себя пользователя, с гостевыми правами. Далее он смотрит отчеты по результатам: общую информацию, что все тесты пройдены, и конкретные проблемы сборки «Рыба 0.1». Но что-либо редактировать он не может.

• Общая структура

Три основных ключевых понятия: Проект, План тестирования и Пользователь. Все остальные данные представляют собой комбинации, отношения и атрибуты этих трех сущностей. Сначала, определим пару терминов, из профессионального лексикона тестировщиков, используемых в этой документации.

Основные понятия

Тест-кейс (Test Case)представляет собой элементарную задачу по тестированию, сформулированную для человека, в виде сценария, состоящего из последовательности шагов, и ожидаемых результатов. Тест-кейс являются фундаментальной сущностью TestLink'а.

Тест-сюита (Test Case Suite)группирует тест-кейсы в более крупные блоки, и используются для логической структуризации спецификации теста (Test Specification).

План тестирования (Test Plan)создан для исполнения тест-кейсов. План тестирования состоит из тест-кейсов одного или нескольких проектов. План тестирования включает в себя Сборки (Builds), Вехи (Milestones), назначения тестов тестировщикам, и результы тестов.

Проект (Test Project) включает в себя тестовую спецификацию (Test Specification) с тест-кейсами, требования и ключевые слова. Будучи создан, проект более не удаляется, хотя может быть деактивирован. Поддерживается версионность проекта. Пользователи внутри проекта получают определенную позицию-роль.

Пользователь ''(User): каждый пользователь имеет роль, которая определяет доступные для него функции системы.

• Спецификация тестов

Как уже говорилось, тесты могут быть структурированы с помощью групп тестов, которые могут включать элементарные тесты или другие группы тестов.

Создание тест-кейсов

Минимальная структура, необходимая тестировщику: это одна группа тестов состоящая из одного теста. Поэтому в каждом новом проекте нужно создать по крайней мере одну группу тестов (при её создании желательно заполнить описание). Далее можно создавать другие группы тестов и включать их друг в друга. Тесты можно создавать, копировать и перемещать из одной группы в другую.

Основные атрибуты теста:

• Заголовок (Title): очень краткое описание или аббревиатура, например «TL-USER-LOGIN».
• Резюме (Summary): максимально краткая, обзорная аннотация.
• Шаги (Steps): пошаговое описание тестового сценария (какие «входные» действия нужно предпринять тестировщику), включая условия их выполнения, а также действия, которые нужно выполнить по окончании (успешном или нет) теста.
• Ожидаемые результаты (Expected results): описывают контрольные точки для проверки, и ожидаемое поведение тестируемой системы.

Удаление тестов

Тесты и группы тестов могут быть удалены из планов тестирования пользователями с правами «lead». Однако удаление тестов приедет к удалению всех связанных результатов их выполнения, поэтому очень рекомендуется никогда этого не делать, разве что сразу после ошибочного создания теста.

Связь с требованиями

Если включить в проекте включить функциональность требований, то тесты могут быть связаны с зарегистрированными требованиями к ПО отношением «многие ко многим».

• Ключевые слова

Использование ключевых слов

Ключевые слова дают пользователям дополнительное «измерение с иерархией» при классификации тестов. С помощью ключевых слов удобно организовывать специфические коллекции тестов, например можно определить наборы:

• Регрессионных тестов;
• Тестов контроля стерильности;
• Тестов, определенных для конкретной платформы и т.п.

Создание ключевых слов

Ключевые слова могут быть созданы пользователями с правами «mgt_modify_key», которыми по умолчанию владеют только имеющие роль «Leaders». Как только ключевое слово или группировка ключевых слов создана, их можно привязывать к тестам.

Привязка ключевых слов

Ключевые слова можно массово привязывать к тестам через страницу привязки ключевых слов (ссылка «Привязать ключевые слова» с главной страницы) или индивидуально для каждого теста при управлении тестами.

Фильтрация по ключевому слову

Пользователи имеют возможность фильтрации (отбора) по ключевым словам:

• При поиске тестов в спецификации тестов.
• При группировке тестов в группы тестов и в планы тестирования.
• На странице выполнения тестов.
• Тестирование основанное на требованиях

Введение

Чтобы доказать, что программная система сделана как задумано, тестировщики используют тестирование основанное на требованиях. Для каждого требования, они проектируют один или более тестов. После выполнения тестов, руководитель тестирования может сформировать отчет, о том, какие требования покрыты тестированием, какие требования успешно проверены и выполнение каких требований провалено. Основываясь на этой информации, заказчик и остальные заинтересованные ЛПР (лица принимающие решения) решают, может ли система быть выпущена в эксплуатацию, или нужны дополнительные доработки и тестирование. При принятии решения, учитывается важность требований и учет требованиями технологических рисков проекта. Такой подход дает следующие преимущества:

• Связывание рисков и требований выявляет плохо сформулированные или отстутствующие требования.
• Тестирование может быть сфокусировано на наиболее важных частях информационной системы, «атакуя» самые опасные технологические риски.
• Работа и коммуникация идет «на едином языке» заказчика и других заинтересованных лиц. Например, заказчику будут понятны отчеты о ходе тестирования проекта, и будет легче принимать решение, инвестировать ли ресурсы в дополнительное тестирование, или риск уже приемлим и можно запускать систему в эксплуатацию.

Как включить функциональность требований

Регистрировать или не регистрировать требования решается индивидуально для каждого проекта. Т.е. администратор должен специально включить эту функциональность для каждого проекта, где она необходима (Ссылка «Управление проектами» на главной странице).

Относительно требований есть два уровня пользовательских прав. Большинство ролей пользовательских ролей могут видеть требования, но не могут их редактировать, а избранные роли могут их также и править (См. Раздел о пользователях).

Спецификации требований

Требования группируются в один или более системных/программных/пользовательских спецификаций требований.

Файл:Image 0 Illustration 1: Dependencies between requirement related objects

Создание документа с требованиями:

1. Выберите «спецификации требований» на главной странице. Будет показан список спецификаций требований.
2. Заполните «Заголовок», «Область действий», и при необходимости параметр «Всего треб.». Последний параметр используется исключительно для статистики, и нужен в том случае, если уже имеется набор требований, которые еще не введены в TestLink, но их количество хотелось бы указать. Неопределенное значение ('n/a') по умолчанию означает, что используется текущее количество требований в спецификации.
3. Нажмите кнопку «Создать» для создания документа. Спецификация будет создана и вам будет предложено создать еще одну спецификацию — вы окажитесь на странице создания спецификации требований.
4. Если вы ввели все желаемые спецификации, нажмите кнопку «Отменить», чтобы окончить ввод спецификаций.

Каждая спецификация требований имеет свою собственную статистику и отчет. Содержимое спецификаций — соответствующий набор требований, может быть отформатирован для печати, с помощью кнопки «Печать» (логотипы, копирайты, предупреждение о конфиденциальности — всё это настраивает администратор через конфигурационные файлы).

Требования

Каждое требование имеет:

•  :«Заголовок»: уникальный и максимум 100 символов;
•  :«Область действий»: текст в HTML-формате;
•  :«Состояние»: Может быть «актуально» или «не тестируемо» (в этом случае требование не учитывается в отчетах и метриках).

Требования можно создавать/править/удалять вручную, через интерфейс TestLink'а, или импортировать из CSV-файла.

Импорт требований

TestLink поддерживает два типа CSV-файлов:

•  :«простой»: имеет формат строки-записи («заголовок», «описание»).
•  :«экспорт из Doors»: пытается найти заголовок и выбрать правильные поля.

При импорте заголовки проверяются на уникальность, а конфликты предлагается разрешить тремя способами: обновление существующих требований, создание требований-дубликатов с таким же заголовком и игнорирование (пропуск) требований-дубликатов при импорте.

Связь требований с тест-кейсами

Между тест-кейсами и требованиями можно устанавливать «многие ко многим». Т.е вы можете не связывать тест-кейс или требование вообще, связывать тест-кейс с одним или более требованиями, и связывать требование с одним или более тест-кейсами. Чтобы попасть на страницу связывания тест-кейсов с требованиями, нажмите ссылку «привязать требования» на главной странице.

Отчет о покрытии спецификации можно получить кнопкой «Анализировать» на странице спецификации требований.

Отчеты по требованиям

Чтобы попасть на страницу отчетов и метрик, нужно использовать меню «Отчеты». На этой странице будет представлен анализ требований в текущих спецификации требований и плане тестирования. Т.е. для каждого требования обрабатываются последние результаты тестов в актуальном плане тестирования, и для каждого требования выбирается наиболее важный результат, а результаты по убыванию важности таковы: «сбой», «заблокирован», «не проверяли», «проверено».

Пример: Некоторое требование покрыто тремя тестами. Два из них включены в текущую группу тестов. Один тест проверен и один не проверялся для «сборки 1». Соответственно это требование — «не проверялось». В «сборке 2» наконец проверили второй тест с успешным результатом, и отчет для этого требования стал «проверено».

• Проекты

Как уже говорилось, проект — это ключевая сущность TestLink'а. Проекты — это те продукты и решения, которые выпускает ваша компания. Причем проекты желательно определить так, чтобы несмотря на эволюцию функциональности (и других свойств), основной массив свойств должен сохранять постоянство. Т.е. неправильно заводить слишком «широкие» проекты, такие как «Вся работа компании», или даже «веб-разработка». Проекты включают документированные требования, спецификации тестов, планы тестирования и ключевые слова.

Создание новых проектов

Для создания нового проекта требуются уровень прав «admin». Каждый проект должен иметь уникальное имя. Также, если соответствующая функциональность включена в конфигурационном файле, каждому проекту можно присвоить свой собственный цвет фона, чтобы надежно визуально отличать их друг от друга. Например, с помощью такой цветовой градации можно отличать важные проекты от некритичных.

Несколько замечаний:

• Удаление проекта из системы не рекомендуется, т.к. это приведет либо к большому числу «тестов-сирот», либо к удалению тестов из системы.
• Каждый план тестирования, является совокупностью тестов и представляет тестирование в проекте в разные моменты времени.
• TestLink поддерживает импорт CSV-данных в проект (будет рассмотрено далее, в разделе про импорт данных).

Правка и удаление проектов

Для редактирования и удаления проекта требуются уровень прав «admin». Можно изменить имя проекта, цвет фона (если такая функциональность включена) и доступность функциональности требований. Если проект устарел, его можно деактивировать — при этом он для всех кроме администратора, пропадет из верхнего навигационного списка выбора (администратор будет видеть такие проекты помеченными астериском '*').

Можно также удалить проект, с удалением всех связанных данных из БД. Но это действие необратимо и мы настоятельно рекомендуем использовать деактивацию вместо удаления.

• Планы тестирования

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

Разумно в описании плана, включать информацию о структуре команды тестировщиков, о видах тестирования, риски, что тестируется, что находится вне тестирования, подходы используемые при тестировании, и т.д.

Создание и удаление планов тестирования

Планы тестирования могут создать пользователи с уровнем привилегий «lead», на странице «Управление планами тестирования» (См. соответствующую ссылку на главной странице).

Планы тестирования являются основой для выполнения/прогона тестов. Они состоят из некоторого «среза»-подмножества тестов проекта, выбранных в определенное время. Планы тестирования можно создавать добавляя каждый тест вручную, или копировать-клонировать существующий план тестирования, а далее уже вносить инкрементальные изменения.

Права на просмотр планов тестирования выдаются пользователем с правами «lead» на странице «Управление пользователями/Назначить роли проекта». Важно об этом помнить, т.к. это главная причина жалоб тестировщиков, что они «не видят» тестов в проекте.

Хотя планы тестирования может удалить пользователь с уровнем привилегий «lead», то так же как и в случае проектов, мы настоятельно не рекомендуем это делать, т.к. необратимо будут уничтожена вся информация о результатах тестирования. Вместо этого, можно деактивировать план тестирования и он также будет скрыт из интерфейса.

Сборки

Сборка это определенный выпуск программного обеспечения. Каждый проект в компании наверняка имеет множество релизов/выпусков/сборок. В TestLink'е, выполнение тестов учитывается отдельно для каждой сборки, в частности, если ни одной сборки нет, выполнять тесты в проекте будет невозможно, и соответственно, будет пустой страница метрик.

Управление сборками осуществляется на одноименной странице «Управление сборками», пользователями с правами «lead».

Редактировать сборки нельзя, их можно только удалить, кликнув по иконке-«корзине» в таблице-списке зарегистрированных сборок.

• Заполнение планов тестирования

Добавление новых тестов

При добавлении тестов определяют шаги тестирования и ожидаемые результаты.

Данные из нескольких проектов, могут быть добавлены в один план тестирования. Спецификации тестов могут быть отфильтрованы по ключевым словам (настраивается в навигационной панели). Как только тесты попадают в план тестирования, они определенным образом помечаются. Таким образом, если тест уже импортировался, то при следующем импорте он будет проигнорирован.

Удаление тестов из плана тестирования

Тесты и группы тестов могут быть убраны из плана тестирования только пользователями с полномочиями «Leader», на странице «Удалить тест(ы)». Но не рекомендуется, кроме как в крайних случаях, удалять тесты из плана тестирования, особенно, если тесты выполнялись, т.к. будет потеряна информация о результатах прогона этих тестов. поэтому

Приоритеты

Пользователи с правами «Leader» могут для каждого теста назначить ответственного и приоритет, нумеруемый от «A» (наибольший) до «C» (наименьший). Вообще риски и важность задаются на уровне групп тестов. Риски имеют уровни «Низкий», «Высокий», «Средний», а уровни важность нумеруются цифрами «3» (наименьшая важность), «2», «1» (наибольшая важность). А далее, по рискам и важности определяются приоритеты, причем пользователи могут задать, по каким правилам их рассчитывать, т.е. какие комбинации риска и важности (например, «L1», «L2», «L3», «M1», «H2», «M3», «H1», «H2», «H3»), к какому приоритету («A», «B», «C») относятся. Если риски и важность не указывать специально, то по умолчанию используется приоритет «B».

Назначение тестов для выполнения

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

• Выполнение тестов

Общая информация

Выполнение тестов становится возможным, когда:

1. Сформирована спецификация тестов.
2. Создан план тестирования.
3. Тесты добавлены в план тестирования.
4. Создана сборка.
5. План тестирования назначен тестировщикам (в противном случае, у них не будет даже доступа к этому плану тестирования).

Выберите требуемый план тестирования на главной странице и перейдите по ссылке «выполнить тесты». Левая панель служит для навигации по группам тестов и их отбора, а также для определения тестируемой сборки.

Навигация

Навигационная панель состоит из блока «Параметры выборки» и иерархического дерева с группами тестов.

Параметры выборки

Эта таблица позволяет пользователю отбирать тесты для удобства навигации по меньшему множеству перед их выполнением:

• Ответственный: Можно отборать тесты по ответственному за них тестировщику.
• Ключевое слово: Пользователь может отбирать тесты по ключевому слову.
• Результат: Пользователи могут отбирать тесты по их результатам выполнения в конкретной сборке. Результаты могут быть «Блокирован», «Не запущен», «Сбой», «Пройден».
• Сборка: Можно отбирать тесты по сборкам. Сборки задают собой дискретность выполнения тестов, ведь каждый тест может быть запущен только один раз для каждой сборки, а сами сборки могут создавать только пользователи с правами «lead».

Иерархия групп тестов

Иерархическое меню в навигационной панели состоит из иерархии групп тестов, раскрашенных в соответствии с результатами выполнения.

Раскраска дерева: По умолчанию дерево сортируется по результатам выполнения для выбранной в пользователем сборки.

Примеры:

Пользователь выбрал сборку «2» в выпадающем списке (не проверив, что она является самой свежей). Соответственно, все тесты будут показаны в состоянии, которое они получили для сборки «2». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

Пользователь выбрал сборку «2» в выпадающем списк, но при этом выбрал отметку «текущая сборка». Соответственно, для всех тестов будет показано наиболее актуально состояние.

Выполнение

Состояние теста

Выполнение — это процесс присвоения результата («Блокирован», «Не запущен», «Сбой», «Пройден») для некоторых выбранных теста и сборки. Названия состояний-результатов, в общем, достаточно говорящие, разве что поясним, что «Блокирован» означает невозможность по любой причине пройти этот тест (например, тестируемый объект не доступен или не развернут на требуемой платформе и т.п.).

Ввод результатов тестов

Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов. Сначала показан заголовок теста, затем желтый блок с сценарием тестирования и цветной блок с результатом теста.

• Пользовательские поля

Реализация дополнительных (пользовательских) полей, основана на моделях реализации настраиваемых полей в проектах «Mantis» (http://www.mantisbt.org/) и «Dotproject» (http://www.dotproject.net/).

Пользовательские поля определяются единым образом для всей системы (а не для отдельного проекта). Поэтому вы не можете определить несколько пользовательских полей с одинаковым именем.

После определения дополнительного поля, можно привязать его к одному или более проектам, где предполагается его использование.

Атрибуты поля:

«Показывать при спецификации теста», «Показывать при выполнении теста» (смысл понятен из названий) и «Разрешить при спецификации теста», «Разрешить при выполнении теста» — можно менять значения в этом поле при спецификации или выполнении.

Примеры.

Поле «Дополнительные заметки» нужно редактировать только при спецификации теста, и нельзя менять в процессе выполнения (хотя можно и показать), а поле «Проверено на операционной системе» нужно задавать только при выполнении теста, а на этапе спецификации теста совершенно бесполезно.

• Отчеты и метрики

На страницу отчетов можно перейти по очевидной ссылке «Отчеты». Показываться имеющиеся отчеты и метрики будут для текущего плана тестирования (в данный момент нет отчетов, которые агрегируют информацию из нескольких планов тестирования), поэтому нужно выбрать нужный план тестирования еще до перехода на страницу отчетов.

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

Параметры отчетов следующие:

Активная сборка: Этот параметр действует только на отчет «Общий статус сборки», показывающий текущее состояние плана тестирования для выбранной сборки.

Формат отчета: все отчеты (кроме диаграмм) могут быть сформированы:

1. «normal»: обычный отчет на веб-страничке.
2. «MS Excel»: экспорт отчета в «Microsoft Excel».
3. «HTML Email»: отчет отправляется HTML-письмом на email-пользователя.

Далее, мы рассмотрим десяток доступных отчетов более подробно.

Общий статус сборки

Фиг знает. Не уверен, что написана актуальная информация.

This report shows the detailed results for a particular build defined by the “Active Build” control. It only takes into account executions performed on the selected build.

The following tables are displayed:

Results by top level Test Suites

Lists the results of each top level suite. Total cases, passed, failed, blocked, not run, and percent completed are listed. A “completed” test case is one that has been marked pass, fail, or block. Results for top level suites include all children suites.

Results by Test Suite

Lists metrics for all suites in test plan, not just top level suites.

Results By Keyword

Lists all keywords that are assigned to cases in the current test plan, and the results associated with them.

Общие метрики плана тестирования

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

Вообще понятие «последнего результата теста» используется в нескольких отчетах и определяется следующим образом:

1. Какая сборка считается последней определяется порядком добавления сборок в план тестирования. Соответственно результаты последней сборки имеют преимущество над результатами тестов остальных сборок.
2. Если тест выполняется несколько раз в одной сборке, то учитывается только последнее выполнение. Например если в сборке «3» с утра тестировщик Адам пометил тест как «пройден», а вечером тестировщик Ева пометила этот же тест как «провален», то тест будет показываться как проваленный.
3. Тесты в состоянии «не запущен» для какой-либо сборки просто не принимаются во внимание. Например, если тест был помечен «пройден» для сборки «1», и не выполнялся для сборки «2», то он будет считаться успешно выполненным.

Общий статус сборки

Показывает результаты выполнения для каждой сборки: «Всего тестов», сколько пройдено, провалено, блокировано и не запущено в абсолютной величине и процентах.

Запрос метрик

Этот отчет содержит поисково-запросную форму после заполнения параметров в которой, можно получить отчет по заданным срезам.

Страница параметров запроса

Можно задать следующие параметры, задающие условие-ограничение на выборку. Полное условие будет «логическое И» над всеми выбранными условиями, если некоторый параметр не задан/не выбран — то он не влияет на выборку, и выбираются тесты, вне зависимости от его значения.

Ключевое слово: можно выбрать только одно ключевое слово и или не выбрать ни одного.

Владелец: можно выбрать одного владельца-ответственного или не выбрать ни одного. В данный момент нет функциональности поиска по «неназначенным» тестам.

Группа тестов: можно выбрать любое количество групп (от нуля).

Сборки: можно выбрать любое количество сборок (от нуля).

Последний результат: выбирается состояние последнего результата по тесту (можно выбрать любое число состояний от нуля).

Нажмите кнопку «Выполнить запрос», для получения результата.

На странице-отчете показаны:

1. Параметры запроса, если был выбран параметр «Показать параметры запроса».
2. Сводная (агрегированная) информация по состояниям выбранных в отчет тестов, если был выбран параметр «Показать итоги по группе тестов».
3. Детальная информация по выполнению каждого теста.

Отчеты «Тесты Проваленные/Блокированные/Не запущенные»

Выводятся соответствующие списки тестов, для проваленных — с информацией о последнем запуске, и (опционально) с информацией о зарегистрированных багах.

Отчет по тестам

Показывает результаты всех тестов для всех сборок. Отчет, как правило получается большим, поэтому рекомендуем выгружать его в Excel, для последующего анализа.

Диаграммы

Для просмотра диаграмм (технология предоставлена http://www.maani.us) требуется поддержка Flash в броузере. Анимированной графикой показываются следующие диаграммы:

1. Круговая диаграмма по всем тестам в разбивке по последнему состоянию выполнения.
2. Столбиковая диаграмма результатов в разбивке по ключевым словам.
3. Столбиковая диаграмма результатов в разбивке по владельцам.
4. Столбиковая диаграмма результатов в разбивке по топовым группам тестов.

Всего багов по каждому тесту

Если Testlink интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

«Открыто», «Исправленных», «Всего», «Тестов с багами», плюс детальная информация о каждом тесте с зарегистрированными багами, с ссылками на эти баги в системе управления ошибками.