|
Персональные инструменты |
![]() |
||
|
![]() |
![]() TestLinkМатериал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. TestLink — это система управления тестами с веб-интерфейсом. Вот типичный пример использования системы:
СодержаниеОбщая структураТри основных ключевых понятия: Проект, План тестирования и Пользователь. Все остальные данные представляют собой комбинации, отношения и атрибуты этих трех сущностей. Сначала, определим пару терминов, из профессионального лексикона тестировщиков, используемых в этой документации. Основные понятия
Спецификация тестовКак уже говорилось, тесты могут быть структурированы с помощью групп тестов, которые могут включать элементарные тесты или другие группы тестов. Создание тестовМинимальная структура, необходимая тестировщику: это одна группа тестов состоящая из одного теста. Поэтому в каждом новом проекте нужно создать по крайней мере одну группу тестов (при её создании желательно заполнить описание). Далее можно создавать другие группы тестов и включать их друг в друга. Тесты можно создавать, копировать и перемещать из одной группы в другую. Основные атрибуты теста:
Удаление тестовТесты и группы тестов могут быть удалены из планов тестирования пользователями с правами «lead». Однако удаление тестов приедет к удалению всех связанных результатов их выполнения, поэтому очень рекомендуется никогда этого не делать, разве что сразу после ошибочного создания теста. Связь с требованиямиЕсли включить в проекте функциональность требований, то тесты могут быть связаны с зарегистрированными требованиями к ПО отношением «многие ко многим». Эта функциональность позволит в дальнейшем получать отчет о выполнении требований, на основе результатов выполненных тестов. Ключевые словаИспользование ключевых словКлючевые слова дают пользователям дополнительное «измерение с иерархией» при классификации тестов. С помощью ключевых слов удобно организовывать специфические коллекции тестов, например можно определить наборы:
Создание ключевых словКлючевые слова могут быть созданы пользователями с правами «mgt_modify_key», которыми по умолчанию владеют только имеющие роль «Leaders». Как только ключевое слово или группировка ключевых слов создана, их можно привязывать к тестам. Привязка ключевых словКлючевые слова можно массово привязывать к тестам через страницу привязки ключевых слов (ссылка «Привязать ключевые слова» с главной страницы) или индивидуально для каждого теста при управлении тестами. Фильтрация по ключевому словуПользователи имеют возможность фильтрации (отбора) по ключевым словам:
ТребованияЧтобы доказать, что программная система сделана как задумано, тестировщики используют тестирование основанное на требованиях. Для каждого требования, они проектируют один или более тестов. После выполнения тестов, руководитель тестирования может сформировать отчет, о том, какие требования покрыты тестированием, какие требования успешно проверены и выполнение каких требований провалено. Основываясь на этой информации, заказчик и остальные заинтересованные ЛПР (лица принимающие решения) решают, может ли система быть выпущена в эксплуатацию, или нужны дополнительные доработки и тестирование. При принятии решения, учитывается важность требований и учет требованиями технологических рисков проекта. Такой подход дает следующие преимущества:
Как включить функциональность требованийРегистрировать или не регистрировать требования решается индивидуально для каждого проекта. Т.е. администратор должен специально включить эту функциональность для каждого проекта, где она необходима (Ссылка «Управление проектами» на главной странице). Относительно требований есть два уровня пользовательских прав. Большинство пользовательских ролей могут видеть требования, но не могут их редактировать, а избранные роли могут их также и править (См. Раздел о пользователях). Спецификации требованийТребования группируются в один или более системных/программных/пользовательских спецификаций требований. Создание документа с требованиями:
Каждая спецификация требований имеет свою собственную статистику и отчет. Содержимое спецификаций — соответствующий набор требований, может быть отформатирован для печати, с помощью кнопки «Печать» (логотипы, копирайты, предупреждение о конфиденциальности — всё это настраивает администратор через конфигурационные файлы). ТребованияКаждое требование имеет:
Требования можно создавать/править/удалять вручную, через интерфейс TestLink'а, или импортировать из файла. Импорт требованийTestLink поддерживает два типа CSV-файлов:
При импорте заголовки проверяются на уникальность, а конфликты предлагается разрешить тремя способами: обновление существующих требований, создание требований-дубликатов с таким же заголовком и игнорирование (пропуск) требований-дубликатов при импорте. Связь требований с тест-кейсамиМежду тест-кейсами и требованиями можно устанавливать «многие ко многим». Т.е вы можете не связывать тест-кейс или требование вообще, связывать тест-кейс с одним или более требованиями, и связывать требование с одним или более тест-кейсами. Чтобы попасть на страницу связывания тест-кейсов с требованиями, нажмите ссылку «привязать требования» на главной странице. Отчет о покрытии спецификации можно получить кнопкой «Анализировать» на странице спецификации требований. Отчеты по требованиямЧтобы попасть на страницу отчетов и метрик, нужно использовать меню «Отчеты», после этого выбрать «Отчет о выполнении требований». На этой странице будет представлен анализ требований в текущей спецификации требований и плане тестирования. Т.е. для каждого требования обрабатываются последние результаты тестов в актуальном плане тестирования, и для каждого требования выбирается наиболее важный результат, а результаты по убыванию важности таковы: «сбой», «заблокирован», «не проверяли», «проверено». Пример: Некоторое требование покрыто тремя тестами. Два из них включены в текущую группу тестов. Один тест проверен и один не проверялся для «сборки 1». Соответственно это требование — «не проверялось». В «сборке 2» наконец проверили второй тест с успешным результатом, и отчет для этого требования стал «выполнено». ПроектыКак уже говорилось, проект — это ключевая сущность TestLink'а. Проекты — это те продукты и решения, которые выпускает ваша компания. Причем проекты желательно определить так, чтобы несмотря на эволюцию функциональности (и других свойств), основной массив свойств должен сохранять постоянство. Т.е. неправильно заводить слишком «широкие» проекты, такие как «Вся работа компании», или даже «веб-разработка». Проекты включают документированные требования, спецификации тестов, планы тестирования и ключевые слова. Создание новых проектовДля создания нового проекта требуются уровень прав «admin». Каждый проект должен иметь уникальное имя. Также, если соответствующая функциональность включена в конфигурационном файле, каждому проекту можно присвоить свой собственный цвет фона, чтобы надежно визуально отличать их друг от друга. Например, с помощью такой цветовой градации можно отличать важные проекты от некритичных. Несколько замечаний:
Правка и удаление проектовДля редактирования и удаления проекта требуются уровень прав «admin». Можно изменить имя проекта, цвет фона (если такая функциональность включена) и доступность функциональности требований. Если проект устарел, его можно деактивировать — при этом он для всех кроме администратора, пропадет из верхнего навигационного списка выбора (администратор будет видеть такие проекты помеченными астериском '*'). Можно также удалить проект, с удалением всех связанных данных из БД. Но это действие необратимо и мы настоятельно рекомендуем использовать деактивацию вместо удаления. Планы тестированияПлан тестирования имеет имя, описание, набор выбранных тестов, сборки, результаты тестирования, вехи, назначения тестировщикам и определения приоритетов. Разумно в описании плана, включать информацию о структуре команды тестировщиков, о видах тестирования, о рисках, о том что тестируется и что находится вне тестирования, описывать подходы используемые при тестировании, и т. д.
Создание и удаление планов тестированияПланы тестирования могут создать пользователи с уровнем привилегий «lead», на странице «Управление планами тестирования» (См. соответствующую ссылку на главной странице). Планы тестирования являются основой для выполнения/прогона тестов. Они состоят из некоторого «среза»-подмножества тестов проекта, выбранных в определенное время. Планы тестирования можно создавать добавляя каждый тест вручную, или копировать-клонировать существующий план тестирования, а далее уже вносить инкрементальные изменения. Права на просмотр планов тестирования выдаются пользователем с правами «lead» на странице «Управление пользователями/Назначить роли проекта». Важно об этом помнить, т. к. это главная причина жалоб тестировщиков, что они «не видят» тестов в проекте. Хотя планы тестирования может удалить пользователь с уровнем привилегий «lead», то так же как и в случае проектов, мы настоятельно не рекомендуем это делать, т. к. необратимо будут уничтожена вся информация о результатах тестирования. Вместо этого, можно деактивировать план тестирования и он также будет скрыт из интерфейса. СборкиСборка это определенный выпуск программного обеспечения. Каждый проект в компании наверняка имеет множество релизов/выпусков/сборок. В TestLink'е, прогон (выполнение) тестов учитывается отдельно для каждой сборки, в частности, если ни одной сборки нет, выполнять тесты в проекте будет невозможно, и соответственно, будет пустой страница метрик и отчетов. Управление сборками осуществляется на одноименной странице «Управление сборками», пользователями с правами «leader». Сборки можно
Заполнение планов тестированияДобавление новых тестовТесты попадают в план тестирования проекта из спецификации тестов (Test Specification). Включение тестов в проект происходит на Для того чтобы включить тест в план, необходимо перейти по ссылке "Добавить тест(ы)" из меню "Содержание плана тестирования" на главной странице. При добавлении тестов спецификация тестов может быть отфильтрована по ключевым словам (настраивается в навигационной панели). Как только тесты попадают в план тестирования, они определенным образом помечаются. Таким образом, если тест уже импортировался, то при следующем импорте он будет проигнорирован. Стоит отметить, что в план тестирования попадает определенная версия теста. И если описание теста изменилось, то при необходимости нужно провести обновление теста в плане. Для этого можно воспользоваться двумя ссылками:
Удаление тестов из плана тестированияТесты и группы тестов могут быть убраны из плана тестирования только пользователями с полномочиями «leader», на странице «Удалить тест(ы)». Но не рекомендуется, кроме как в крайних случаях, удалять тесты из плана тестирования, особенно, если тесты выполнялись, т. к. будет потеряна информация о результатах прогона этих тестов. ПриоритетыПользователи с правами «leader» могут для каждого теста назначить ответственного и приоритет, нумеруемый от «A» (наибольший) до «C» (наименьший). Так же риски и важность можно задавать на уровне групп тестов. Риски имеют уровни «Низкий», «Средний», «Высокий» (обозначаются соответственно L, M, H), а уровни важность нумеруются цифрами «3» (наименьшая важность), «2», «1» (наибольшая важность). А далее, по рискам и важности определяются приоритеты, причем пользователи могут задать, по каким правилам их рассчитывать, т. е. какие комбинации риска и важности (например, «L1», «L2», «L3», «M1», «H2», «M3», «H1», «H2», «H3»), к какому приоритету («A», «B», «C») относятся. Если риски и важность не указывать специально, то по умолчанию используется приоритет «B». Назначение тестов для прогонаНазначение тестов для прогона (выполнения) на конкретного пользователя влияет и на само выполнение и на страницу отчетов. На странице прогона тестов пользователи имеют возможность упорядочить выполняемые тесты по ответственному за исполнение. На странице отчетов и метрик есть отчет, который показывает прогресс тестировщиков по выполнению тестов: сколько тестов выполнено, и сколько осталось прогнать. Прогон тестовОбщая информацияПрогон (выполнение) тестов становится возможным, когда:
Выберите требуемый план тестирования на главной странице и перейдите по ссылке «выполнить тесты». Левая панель служит для навигации по группам тестов и их отбора, а также для определения тестируемой сборки. НавигацияНавигационная панель состоит из блока «Параметры выборки» и иерархического дерева с группами тестов. Параметры выборкиЭта таблица позволяет пользователю отбирать тесты для удобства навигации по меньшему множеству перед их выполнением:
Для каждой сборки можно зарегистрировать неограниченное число результатов выполнения одного и того же теста, но в отчетах по результатам сборки, покрытия требований и других будет фигурировать только последний результат. Иерархия групп тестовИерархическое меню в навигационной панели состоит из иерархии групп тестов, раскрашенных в соответствии с результатами выполнения. Раскраска дерева: По умолчанию дерево сортируется по результатам выполнения для выбранной в пользователем сборки. Примеры:
ПрогонСостояние тестаПрогон теста (выполнение) — это процесс присвоения результата («Блокирован», «Не запущен», «Сбой», «Пройден») для некоторых выбранных теста и сборки. Названия состояний-результатов, в общем, достаточно говорящие, разве что поясним, что «Блокирован» означает невозможность по любой причине пройти этот тест (например, тестируемый объект не доступен или не развернут на требуемой платформе и т. п.). Ввод результатов тестовСтраница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов. Сначала показан заголовок теста, затем желтый блок с сценарием тестирования и цветной блок с результатом теста.
Настраиваемые поляРеализация настраиваемых (дополнительных, расширенных, и т. п.) полей, основана на моделях реализации настраиваемых полей в проектах «Mantis» (http://www.mantisbt.org/) и «Dotproject» (http://www.dotproject.net/). Каждое настраиваемое поле может быть привязано к объектам одного из следующих типов: тест, группа тестов, план тестирования. Настраиваемые поля определяются для всей системы (а не для отдельного проекта). Поэтому вы не можете определить несколько настраиваемых полей с одинаковым именем. После определения дополнительного поля, можно привязать его к одному или более проектам, где предполагается его использование.
Атрибуты поля: «Показывать при спецификации теста», «Показывать при выполнении теста» (смысл понятен из названий) и «Разрешить при спецификации теста», «Разрешить при выполнении теста» — можно менять значения в этом поле при спецификации или выполнении. Например, поле «Дополнительные заметки» нужно редактировать только при спецификации теста, и нельзя менять в процессе выполнения (хотя можно и показать), а поле «Проверено на операционной системе» нужно задавать только при выполнении теста, а на этапе спецификации теста совершенно бесполезно. Рассмотрим остальные атрибуты настраиваемых полей:
Отчеты и метрикиНа страницу отчетов можно перейти по очевидной ссылке «Отчеты». Показываться имеющиеся отчеты и метрики будут для текущего плана тестирования (в данный момент нет отчетов, которые агрегируют информацию из нескольких планов тестирования), поэтому нужно выбрать нужный план тестирования еще до перехода на страницу отчетов. Левая панель страницы предназначена для выбора типа отчета и его параметров, а на правой находится либо инструкция по формированию отчетов, либо сформированных отчет. Параметры отчетов следующие:
Формат отчета: все отчеты (кроме диаграмм) могут быть сформированы:
Далее, мы рассмотрим десяток доступных отчетов более подробно. Общие метрики плана тестированияПоказывает наиболее актуальное состояние (в смысле последней выполненной сборки) плана тестирования в срезах по группам тестов, тестировщикам и ключевым словам. Вообще понятие «последнего результата теста» используется в нескольких отчетах и определяется следующим образом:
Общий статус сборкиПоказывает результаты выполнения для каждой сборки: «Всего тестов», сколько пройдено, провалено, блокировано и не запущено в абсолютной величине и процентах.
Запрос метрикЭтот отчет содержит поисково-запросную форму после заполнения параметров в которой, можно получить отчет по заданным срезам. Страница параметров запросаМожно задать следующие параметры, задающие условие-ограничение на выборку. Полное условие будет «логическое И» над всеми выбранными условиями, если некоторый параметр не задан/не выбран — то он не влияет на выборку, и выбираются тесты, вне зависимости от его значения.
Нажмите кнопку «Выполнить запрос», для получения результата. На странице-отчете показаны:
Отчеты «Тесты Проваленные/Блокированные/Не запущенные»Выводятся соответствующие списки тестов, для проваленных — с информацией о последнем запуске, и (опционально) с информацией о зарегистрированных багах.
Отчет по тестамПоказывает результаты всех тестов для всех сборок. Отчет, как правило получается большим, поэтому рекомендуем выгружать его в Excel, для последующего анализа. ДиаграммыДля просмотра диаграмм (технология предоставлена http://www.maani.us) требуется поддержка Flash в броузере. Анимированной графикой показываются следующие диаграммы:
Всего багов по каждому тестуЕсли TestLink интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах: «Открыто», «Исправленных», «Всего», «Тестов с багами», плюс детальная информация о каждом тесте с зарегистрированными багами, с ссылками на эти баги в системе управления ошибками. Отчет о выполнении требований |
![]() |
![]() |
![]() |