|
|
| (не показаны 3 промежуточные версии 1 участника) |
| Строка 1: |
Строка 1: |
| − | [[Category:TestLink]]
| + | #REDIRECT [[TestLink (версия 1.6)]] |
| − | | + | |
| − | [[TestLink]] — это система управления тестами с веб-интерфейсом.
| + | |
| − | | + | |
| − | Вот типичный пример использования системы:
| + | |
| − | | + | |
| − | # Администратор создает ''проект'' «Фаст-фуд» и двух пользователей: Адама, с правами «Leader» и Еву с правами «Senior tester». | + | |
| − | # Адам импортирует список ''требований'' к программному обеспечению, и для некоторых из этих требований создает пустые ''тесты.'' Вообще, более корректно говорить о ''тест-''кейсах (т.е. тестах со сценарием тестирования), но так как других тестов (автоматических, модульных, юнит-тестов) в системе нет, то далее мы будем называть тест-кейсы просто тестами.
| + | |
| − | # Тестировщица Ева пишет ''тестовые сценарии'' для этих тестов, и группирует тесты в ''группы тестов''.
| + | |
| − | # Адам создает ''ключевое слово'' «Регрессия» и привязывает его к десятку тестов.
| + | |
| − | # Адам создает ''план тестирования'' «Рыба и Чипсы», ''сборку'' «Рыба 0.1» и включает в этот план тесты с ключевым словом «Регрессия».
| + | |
| − | # Адам и Бела выполняют тесты и записывают результат: 5 ''пройдено'', 1 ''провален'', и 4 ''заблокировано'' (нет возможности выполнить требуемые проверки).
| + | |
| − | # Разработчики формируют новую сборку «Рыба 0.2» и Бела тестирует только проваленные и заблокированные тесты. На удивление, все эти пять тестов успешно выполняются.
| + | |
| − | # Руководитель команды желает взглянуть на результаты. Он самостоятельно заводит для себя пользователя, с гостевыми правами. Далее он смотрит отчеты по результатам: общую информацию, что все тесты пройдены, и конкретные проблемы сборки «Рыба 0.1». Но что-либо редактировать он не может.
| + | |
| − | | + | |
| − | = Общая структура =
| + | |
| − | Три основных ключевых понятия: ''Проект'', ''План тестирования'' и ''Пользователь''. Все остальные данные представляют собой комбинации, отношения и атрибуты этих трех сущностей. Сначала, определим пару терминов, из профессионального лексикона тестировщиков, используемых в этой документации.
| + | |
| − | | + | |
| − | == Основные понятия ==
| + | |
| − | | + | |
| − | <graph>
| + | |
| − | digraph G{
| + | |
| − | node[shape="box", style="filled", fillcolor="yellow"];
| + | |
| − | edge[arrowhead="crow"];
| + | |
| − | | + | |
| − | | + | |
| − | Product [label="Проект"];
| + | |
| − | TestSpec [label="Спецификация тестирования"];
| + | |
| − | Group1 [label="Группа тестов"];
| + | |
| − | Group2 [label="..."];
| + | |
| − | Group3 [label="Группа тестов"];
| + | |
| − | TestCase [label="Тест кейс"];
| + | |
| − | TestPlan [label="План тестирования"];
| + | |
| − | RequirementSpecification [label="Спецификация требований"];
| + | |
| − | Requirement [label="Требование"];
| + | |
| − | Keyword [label="Тэг (ключевое слово)"];
| + | |
| − | | + | |
| − | Product->TestSpec [arrowhead=""];
| + | |
| − | TestSpec->Group1->Group2->Group3->TestCase;
| + | |
| − | Product->TestPlan->TestCase;
| + | |
| − | Keyword->TestCase [arrowtail="crow"];
| + | |
| − | Product->RequirementSpecification->Requirement;
| + | |
| − | Requirement->TestCase[arrowtail="crow"];
| + | |
| − |
| + | |
| − | }
| + | |
| − | </graph>
| + | |
| − | | + | |
| − | ;Тест (Test Case): представляет собой элементарную задачу по тестированию, сформулированную для человека, в виде сценария, состоящего из последовательности шагов, и ожидаемых результатов. Тест являются фундаментальной сущностью TestLink'а.
| + | |
| − | | + | |
| − | ;Группа тестов (Test Case Suite): группирует тест-кейсы в более крупные блоки, и используются для логической структуризации спецификации теста (''Test Specification'').
| + | |
| − | | + | |
| − | ;План тестирования (Test Plan): создан для исполнения тест-кейсов. План тестирования состоит из тест-кейсов одного или нескольких проектов. План тестирования включает в себя ''Сборки ''(''Builds''), ''Вехи ''(''Milestones''), назначения тестов тестировщикам, и результы выполнения тестов.
| + | |
| − | | + | |
| − | ;Проект (Test Project): включает в себя тестовую спецификацию (Test Specification) с тест-кейсами, ''Требования''(''Requirements''), ''Ключевые слова''(''Keywords''). Будучи создан, проект более не удаляется, хотя может быть деактивирован. Поддерживается версионность проекта. Пользователи внутри проекта получают определенную позицию-роль.
| + | |
| − | | + | |
| − | ;Пользователь (User): каждый пользователь имеет глобальную роль, и так же роль в каждом проекте, которая определяет доступные для него функции системы. Глобальная роль может быть унаследована в проекте.
| + | |
| − | | + | |
| − | = Спецификация тестов =
| + | |
| − | Как уже говорилось, тесты могут быть структурированы с помощью групп тестов, которые могут включать элементарные тесты или другие группы тестов.
| + | |
| − | | + | |
| − | == Создание тестов ==
| + | |
| − | Минимальная структура, необходимая тестировщику: это одна группа тестов состоящая из одного теста. Поэтому в каждом новом проекте нужно создать по крайней мере одну группу тестов (при её создании желательно заполнить описание). Далее можно создавать другие группы тестов и включать их друг в друга. Тесты можно создавать, копировать и перемещать из одной группы в другую.
| + | |
| − | | + | |
| − | Основные атрибуты теста:
| + | |
| − | | + | |
| − | ;Заголовок (Title): очень краткое описание или аббревиатура, например «TL-USER-LOGIN».
| + | |
| − | ;Резюме (Summary): максимально краткая, обзорная аннотация.
| + | |
| − | ;Шаги (Steps): пошаговое описание тестового сценария (какие «входные» действия нужно предпринять тестировщику), включая условия их выполнения, вводимые данные, а также действия, которые нужно выполнить по окончании (успешном или нет) теста.
| + | |
| − | ;Ожидаемые результаты (Expected results): описывают контрольные точки для проверки, и ожидаемое поведение тестируемой системы.
| + | |
| − | | + | |
| − | Дополнительно можно привязать тест к нескольким ключевым словам. Если у вас достаточно прав, вы так же можете перейти к списку ключевых слов и редактированить его. Подробнее о ключевых словах написано в [[#Ключевые_слова|этом разделе]]
| + | |
| − | | + | |
| − | == Удаление тестов ==
| + | |
| − | Тесты и группы тестов могут быть удалены из планов тестирования пользователями с правами «lead». Однако удаление тестов приедет к удалению всех связанных результатов их выполнения, поэтому очень рекомендуется никогда этого не делать, разве что сразу после ошибочного создания теста.
| + | |
| − | | + | |
| − | == Связь с требованиями ==
| + | |
| − | Если включить в проекте функциональность требований, то тесты могут быть связаны с зарегистрированными требованиями к ПО отношением «многие ко многим». Эта функциональность позволит в дальнейшем получать отчет о выполнении требований, на основе результатов выполненных тестов.
| + | |
| − | | + | |
| − | = Ключевые слова =
| + | |
| − | == Использование ключевых слов ==
| + | |
| − | Ключевые слова дают пользователям дополнительное «измерение с иерархией» при классификации тестов. С помощью ключевых слов удобно организовывать специфические коллекции тестов, например можно определить наборы:
| + | |
| − | * Регрессионных тестов;
| + | |
| − | * Тестов контроля стерильности;
| + | |
| − | * Тестов, определенных для конкретной платформы и т. п.
| + | |
| − | | + | |
| − | == Создание ключевых слов ==
| + | |
| − | Ключевые слова могут быть созданы пользователями с правами «mgt_modify_key», которыми по умолчанию владеют только имеющие роль «Leaders». Как только ключевое слово или группировка ключевых слов создана, их можно привязывать к тестам.
| + | |
| − | | + | |
| − | == Привязка ключевых слов ==
| + | |
| − | Ключевые слова можно массово привязывать к тестам через страницу привязки ключевых слов (ссылка «Привязать ключевые слова» с главной страницы) или индивидуально для каждого теста при управлении тестами.
| + | |
| − | | + | |
| − | == Фильтрация по ключевому слову ==
| + | |
| − | Пользователи имеют возможность фильтрации (отбора) по ключевым словам:
| + | |
| − | | + | |
| − | * При поиске тестов в спецификации тестов.
| + | |
| − | * При группировке тестов в группы тестов и в планы тестирования.
| + | |
| − | * На странице выполнения тестов.
| + | |
| − | * Тестирование основанное на требованиях
| + | |
| − | | + | |
| − | =Требования =
| + | |
| − | Чтобы доказать, что программная система сделана как задумано, тестировщики используют тестирование основанное на требованиях. Для каждого требования, они проектируют один или более тестов. После выполнения тестов, руководитель тестирования может сформировать отчет, о том, какие требования покрыты тестированием, какие требования успешно проверены и выполнение каких требований провалено. Основываясь на этой информации, заказчик и остальные заинтересованные ЛПР (лица принимающие решения) решают, может ли система быть выпущена в эксплуатацию, или нужны дополнительные доработки и тестирование. При принятии решения, учитывается важность требований и учет требованиями технологических рисков проекта. Такой подход дает следующие преимущества:
| + | |
| − | | + | |
| − | * Связывание рисков и требований выявляет плохо сформулированные или отстутствующие требования.
| + | |
| − | * Тестирование может быть сфокусировано на наиболее важных частях информационной системы, «атакуя» самые опасные технологические риски.
| + | |
| − | * Работа и коммуникация идет «на едином языке» заказчика и других заинтересованных лиц. Например, заказчику будут понятны отчеты о ходе тестирования проекта, и будет легче принимать решение, инвестировать ли ресурсы в дополнительное тестирование, или риск уже приемлим и можно запускать систему в эксплуатацию.
| + | |
| − | | + | |
| − | == Как включить функциональность требований ==
| + | |
| − | Регистрировать или не регистрировать требования решается индивидуально для каждого проекта. Т.е. администратор должен специально включить эту функциональность для каждого проекта, где она необходима (Ссылка «Управление проектами» на главной странице).
| + | |
| − | | + | |
| − | Относительно требований есть два уровня пользовательских прав. Большинство пользовательских ролей могут видеть требования, но не могут их редактировать, а избранные роли могут их также и править (См. Раздел о пользователях).
| + | |
| − | | + | |
| − | == Спецификации требований ==
| + | |
| − | Требования группируются в один или более системных/программных/пользовательских спецификаций требований.
| + | |
| − | | + | |
| − | Создание документа с требованиями:
| + | |
| − | | + | |
| − | # Выберите «спецификации требований» на главной странице. Будет показан список спецификаций требований.
| + | |
| − | # Заполните «Заголовок», «Область действий», и при необходимости параметр «Всего треб.». Последний параметр используется исключительно для статистики, и нужен в том случае, если уже имеется набор требований, которые еще не введены в TestLink, но их количество хотелось бы указать. Неопределенное значение ('n/a') по умолчанию означает, что используется текущее количество требований в спецификации.
| + | |
| − | # Нажмите кнопку «Создать» для создания документа. Спецификация будет создана и вам будет предложено создать еще одну спецификацию — вы окажитесь на странице создания спецификации требований.
| + | |
| − | # Если вы ввели все желаемые спецификации, нажмите кнопку «Отменить», чтобы окончить ввод спецификаций.
| + | |
| − | | + | |
| − | Каждая спецификация требований имеет свою собственную статистику и отчет. Содержимое спецификаций — соответствующий набор требований, может быть отформатирован для печати, с помощью кнопки «Печать» (логотипы, копирайты, предупреждение о конфиденциальности — всё это настраивает администратор через конфигурационные файлы).
| + | |
| − | | + | |
| − | == Требования ==
| + | |
| − | Каждое требование имеет:
| + | |
| − | | + | |
| − | ;Заголовок: уникальный и максимум 100 символов;
| + | |
| − | ;Описание: текст в HTML-формате;
| + | |
| − | ;Состояние: Может быть «актуально» или «не тестируемо» (в этом случае требование не учитывается в отчетах и метриках).
| + | |
| − | | + | |
| − | Требования можно создавать/править/удалять вручную, через интерфейс TestLink'а, или импортировать из файла.
| + | |
| − | | + | |
| − | === Импорт требований ===
| + | |
| − | [[TestLink]] поддерживает два типа CSV-файлов:
| + | |
| − | | + | |
| − | ;простой: имеет формат строки-записи («заголовок», «описание»).
| + | |
| − | ;экспорт из Doors: пытается найти заголовок и выбрать правильные поля.
| + | |
| − | | + | |
| − | При импорте заголовки проверяются на уникальность, а конфликты предлагается разрешить тремя способами: обновление существующих требований, создание требований-дубликатов с таким же заголовком и игнорирование (пропуск) требований-дубликатов при импорте.
| + | |
| − | | + | |
| − | === Связь требований с тест-кейсами ===
| + | |
| − | Между тест-кейсами и требованиями можно устанавливать «многие ко многим». Т.е вы можете не связывать тест-кейс или требование вообще, связывать тест-кейс с одним или более требованиями, и связывать требование с одним или более тест-кейсами. Чтобы попасть на страницу связывания тест-кейсов с требованиями, нажмите ссылку «привязать требования» на главной странице.
| + | |
| − | | + | |
| − | Отчет о покрытии спецификации можно получить кнопкой «Анализировать» на странице спецификации требований.
| + | |
| − | | + | |
| − | === Отчеты по требованиям ===
| + | |
| − | Чтобы попасть на страницу отчетов и метрик, нужно использовать меню «Отчеты», после этого выбрать «Отчет о выполнении требований». На этой странице будет представлен анализ требований в текущей спецификации требований и плане тестирования. Т.е. для каждого требования обрабатываются последние результаты тестов в актуальном плане тестирования, и для каждого требования выбирается наиболее важный результат, а результаты по убыванию важности таковы: «сбой», «заблокирован», «не проверяли», «проверено».
| + | |
| − | | + | |
| − | Пример: Некоторое требование покрыто тремя тестами. Два из них включены в текущую группу тестов. Один тест проверен и один не проверялся для «сборки 1». Соответственно это требование — «не проверялось». В «сборке 2» наконец проверили второй тест с успешным результатом, и отчет для этого требования стал «выполнено».
| + | |
| − | | + | |
| − | = Проекты =
| + | |
| − | Как уже говорилось, проект — это ключевая сущность TestLink'а. Проекты — это те продукты и решения, которые выпускает ваша компания. Причем проекты желательно определить так, чтобы несмотря на эволюцию функциональности (и других свойств), основной массив свойств должен сохранять постоянство. Т.е. неправильно заводить слишком «широкие» проекты, такие как «Вся работа компании», или даже «веб-разработка». Проекты включают документированные требования, спецификации тестов, планы тестирования и ключевые слова.
| + | |
| − | | + | |
| − | == Создание новых проектов ==
| + | |
| − | Для создания нового проекта требуются уровень прав «admin». Каждый проект должен иметь уникальное имя. Также, если соответствующая функциональность включена в конфигурационном файле, каждому проекту можно присвоить свой собственный цвет фона, чтобы надежно визуально отличать их друг от друга. Например, с помощью такой цветовой градации можно отличать важные проекты от некритичных.
| + | |
| − | | + | |
| − | Несколько замечаний:
| + | |
| − | | + | |
| − | * Удаление проекта из системы не рекомендуется, т. к. это приведет либо к большому числу «тестов-сирот», либо к удалению тестов из системы.
| + | |
| − | * Каждый план тестирования, является совокупностью тестов и представляет тестирование в проекте в разные моменты времени.
| + | |
| − | * TestLink поддерживает импорт CSV-данных в проект (будет рассмотрено далее, в разделе про импорт данных).
| + | |
| − | | + | |
| − | == Правка и удаление проектов ==
| + | |
| − | Для редактирования и удаления проекта требуются уровень прав «admin». Можно изменить имя проекта, цвет фона (если такая функциональность включена) и доступность функциональности требований. Если проект устарел, его можно ''деактивировать — ''при этом он для всех кроме администратора, пропадет из верхнего навигационного списка выбора (администратор будет видеть такие проекты помеченными астериском '*').
| + | |
| − | | + | |
| − | Можно также удалить проект, с удалением всех связанных данных из БД. Но это действие необратимо и мы настоятельно рекомендуем использовать деактивацию вместо удаления.
| + | |
| − | | + | |
| − | = Планы тестирования =
| + | |
| − | План тестирования имеет имя, описание, набор выбранных тестов, сборки, результаты тестирования, вехи, назначения тестировщикам и определения приоритетов.
| + | |
| − | | + | |
| − | Разумно в описании плана, включать информацию о структуре команды тестировщиков, о видах тестирования, о рисках, о том что тестируется и что находится вне тестирования, описывать подходы используемые при тестировании, и т. д.
| + | |
| − | | + | |
| − | | + | |
| − | == Создание и удаление планов тестирования ==
| + | |
| − | Планы тестирования могут создать пользователи с уровнем привилегий «lead», на странице «Управление планами тестирования» (См. соответствующую ссылку на главной странице).
| + | |
| − | | + | |
| − | Планы тестирования являются основой для выполнения/прогона тестов. Они состоят из некоторого «среза»-подмножества тестов проекта, выбранных в определенное время. Планы тестирования можно создавать добавляя каждый тест вручную, или копировать-клонировать существующий план тестирования, а далее уже вносить инкрементальные изменения.
| + | |
| − | | + | |
| − | Права на просмотр планов тестирования выдаются пользователем с правами «lead» на странице «Управление пользователями/Назначить роли проекта». Важно об этом помнить, т. к. это главная причина жалоб тестировщиков, что они «не видят» тестов в проекте.
| + | |
| − | | + | |
| − | Хотя планы тестирования может удалить пользователь с уровнем привилегий «lead», то так же как и в случае проектов, мы настоятельно не рекомендуем это делать, т. к. необратимо будут уничтожена вся информация о результатах тестирования. Вместо этого, можно деактивировать план тестирования и он также будет скрыт из интерфейса.
| + | |
| − | | + | |
| − | == Сборки ==
| + | |
| − | Сборка это определенный выпуск программного обеспечения. Каждый проект в компании наверняка имеет множество релизов/выпусков/сборок. В TestLink'е, прогон (выполнение) тестов учитывается отдельно для каждой сборки, в частности, если ни одной сборки нет, выполнять тесты в проекте будет невозможно, и соответственно, будет пустой страница метрик и отчетов.
| + | |
| − | | + | |
| − | Управление сборками осуществляется на одноименной странице «Управление сборками», пользователями с правами «leader».
| + | |
| − | Сборки можно
| + | |
| − | ; редактировать: Можно изменить название и описание сборки.
| + | |
| − | ; активировать: Если сборка не активирована, невозможно выполнять тест с привязкой результатов к этой сборке. Т.е. TestLink считает, что все тестирование по данной сборке проведено и дальнейшего тестирования не требуется.
| + | |
| − | ; открыть:
| + | |
| − | | + | |
| − | == Заполнение планов тестирования ==
| + | |
| − | === Добавление новых тестов ===
| + | |
| − | | + | |
| − | Тесты попадают в план тестирования проекта из спецификации тестов (''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».
| + | |
| − | | + | |
| − | == Назначение тестов для прогона ==
| + | |
| − | Назначение тестов для прогона (выполнения) на конкретного пользователя влияет и на само выполнение и на страницу отчетов. На странице прогона тестов пользователи имеют возможность упорядочить выполняемые тесты по ответственному за исполнение. На странице отчетов и метрик есть отчет, который показывает прогресс тестировщиков по выполнению тестов: сколько тестов выполнено, и сколько осталось прогнать.
| + | |
| − | | + | |
| − | = Прогон тестов =
| + | |
| − | == Общая информация ==
| + | |
| − | Прогон (выполнение) тестов становится возможным, когда:
| + | |
| − | | + | |
| − | # Сформирована спецификация тестов.
| + | |
| − | # Создан план тестирования.
| + | |
| − | # Тесты добавлены в план тестирования.
| + | |
| − | # Есть (создана) сборка в статусе "активная".
| + | |
| − | # План тестирования назначен тестировщикам (в противном случае, у них не будет даже доступа к этому плану тестирования).
| + | |
| − | | + | |
| − | Выберите требуемый план тестирования на главной странице и перейдите по ссылке «выполнить тесты». Левая панель служит для навигации по группам тестов и их отбора, а также для определения тестируемой сборки.
| + | |
| − | | + | |
| − | == Навигация ==
| + | |
| − | Навигационная панель состоит из блока «Параметры выборки» и иерархического дерева с группами тестов.
| + | |
| − | | + | |
| − | === Параметры выборки ===
| + | |
| − | Эта таблица позволяет пользователю отбирать тесты для удобства навигации по меньшему множеству перед их выполнением:
| + | |
| − | | + | |
| − | ;Ответственный: Можно отборать тесты по ответственному за их выполнение тестировщику.
| + | |
| − | ;Ключевое слово: Пользователь может отбирать тесты по ключевому слову.
| + | |
| − | ;Результат: Пользователи могут отбирать тесты по их результатам выполнения в конкретной сборке. Результаты могут быть «Блокирован», «Не запущен», «Сбой», «Пройден».
| + | |
| − | ;Сборка: Можно выбирать сборку, к которой привязываются результаты выполненых тестов. Одновременно более одной ''активной'' сборки (смотрите )может проходить тестирование, т.о. разные тестировщики могут одновременно тестировать разные сборки.
| + | |
| − | | + | |
| − | {{note}} Заметим, что в предыдущей версии TestLink 1.6 такая возможность отстутствовала и создание новой сборки автоматически означало прекращение тестирования предыдущей. Т.е. регистрировать результаты в TestLink для «устаревшей» сборки становилось невозможно.
| + | |
| − | | + | |
| − | Для каждой сборки можно зарегистрировать неограниченное число результатов выполнения одного и того же теста, но в отчетах по результатам сборки, покрытия требований и других будет фигурировать только последний результат.
| + | |
| − | | + | |
| − | === Иерархия групп тестов ===
| + | |
| − | Иерархическое меню в навигационной панели состоит из иерархии групп тестов. Это дерево можно фильтровать по ключевому слову, результам выполнения, ответственному.
| + | |
| − | | + | |
| − | Выбор сборки хоть и находиться в той же форме, но несет другой смысл, не фильтра. В данном случае выбирается сборка с которой будут связаны результаты выполнения.
| + | |
| − | | + | |
| − | Примеры:
| + | |
| − | | + | |
| − | * Пользователь выбрал сборку «2» в выпадающем списке. Соответственно, все результаты проведенных им тестов будут привязаны к этой сборке. И в отчетах они будут показаны для сборки 2.
| + | |
| − | | + | |
| − | * Пользователь выбрал свой логин в поле «ответственный» в этом случае будут показаны только те тесты которые были ему назначены (таких может и не быть).
| + | |
| − | {{note}} Заметим, что для сохранения результатов выполнения тестов не обязательно быть ответственным за тест, нужно только иметь соответствующий права.
| + | |
| − | | + | |
| − | == Прогон ==
| + | |
| − | === Состояние теста ===
| + | |
| − | Прогон теста (выполнение) — это процесс присвоения результата («Блокирован», «Сбой», «Пройден») для некоторых выбранных тестов и сборки. Названия состояний-результатов, в общем, достаточно говорящие, разве что поясним, что «Блокирован» означает невозможность по любой причине пройти этот тест (например, тестируемый объект не доступен или не развернут на требуемой платформе или выполнение теста невозможно из-за того что не пройден другой тест и т. п.).
| + | |
| − | | + | |
| − | === Ввод результатов тестов ===
| + | |
| − | Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
| + | |
| − | На этой странице изображены:
| + | |
| − | * Заметки по плану тестирования;
| + | |
| − | * Описание сборки;
| + | |
| − | * Панель массового управления состоянием тестов;
| + | |
| − | : служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
| + | |
| − | * История выполнения теста или результаты последнего выполнения;
| + | |
| − | * Описание теста:
| + | |
| − | ** резюме;
| + | |
| − | ** шаги выполнения;
| + | |
| − | ** ожидаемые результаты.
| + | |
| − | * Настраиваемые поля;
| + | |
| − | * Поле для заметок;
| + | |
| − | * Радиокнопка для выбора результата теста.
| + | |
| − | | + | |
| − | Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''bug tracking system''). Привязку результата к багу можно осуществить не только для теста который не прошел, но и для теста в состоянии "Блокирован" или даже "Пройден".
| + | |
| − | | + | |
| − | Так же после регистрации результата по выполнению теста, можно сделать вложения для каждого факта выполнения.
| + | |
| − | | + | |
| − | = Настраиваемые поля =
| + | |
| − | Реализация настраиваемых (дополнительных, расширенных, и т. п.) полей, основана на моделях реализации настраиваемых полей в проектах «Mantis» (http://www.mantisbt.org/) и «Dotproject» (http://www.dotproject.net/).
| + | |
| − | | + | |
| − | Каждое настраиваемое поле может быть привязано к объектам одного из следующих типов: тест, группа тестов, план тестирования.
| + | |
| − | Настраиваемые поля определяются для всей системы (а не для отдельного проекта). Поэтому вы не можете определить несколько настраиваемых полей с одинаковым именем. После определения дополнительного поля, можно привязать его к одному или более проектам, где предполагается его использование.
| + | |
| − | | + | |
| − | {{note}} Число настраиваемых полей неограничено.
| + | |
| − | | + | |
| − | Атрибуты поля: «Показывать при спецификации теста», «Показывать при выполнении теста» (смысл понятен из названий) и «Разрешить при спецификации теста», «Разрешить при выполнении теста» — можно менять значения в этом поле при спецификации или выполнении.
| + | |
| − | | + | |
| − | Например, поле «Дополнительные заметки» нужно редактировать только при спецификации теста, и нельзя менять в процессе выполнения (хотя можно и показать), а поле «Проверено на операционной системе» нужно задавать только при выполнении теста, а на этапе спецификации теста совершенно бесполезно.
| + | |
| − | | + | |
| − | Рассмотрим остальные атрибуты настраиваемых полей:
| + | |
| − | ;Имя: Должно быть уникально для в рамках TestLink-системы.
| + | |
| − | ;Метка: Текстовое название поля, которое показывается в интерфейсе показа и редактирования поля.
| + | |
| − | ;Тип поля: Перечисление:
| + | |
| − | :* string;
| + | |
| − | :* numeric;
| + | |
| − | :* float;
| + | |
| − | :* email;
| + | |
| − | :* checkbox;
| + | |
| − | :* list;
| + | |
| − | :* multiselection list;
| + | |
| − | :* date;
| + | |
| − | :* text area.
| + | |
| − | ;Возможные значения: Атрибут показывается (и имеет смысл) для списков, и представляет собой перечисление возможных значений (например, «красный|желтый|зеленый»), т. е. различные значения разделяются символом '|'. Допустимым значением в перечислении может быть и пустая строка.
| + | |
| − | ;Доступно для: Выбор, к какому типу объектов должно быть привязано поле: тест, группа тестов или план тестирования.
| + | |
| − | | + | |
| − | = Отчеты и метрики =
| + | |
| − | На страницу отчетов можно перейти по очевидной ссылке «Отчеты». Показываться имеющиеся отчеты и метрики будут для текущего плана тестирования (в данный момент нет отчетов, которые агрегируют информацию из нескольких планов тестирования), поэтому нужно выбрать нужный план тестирования еще до перехода на страницу отчетов.
| + | |
| − | | + | |
| − | Левая панель страницы предназначена для выбора типа отчета и его параметров, а на правой находится либо инструкция по формированию отчетов, либо сформированных отчет.
| + | |
| − | | + | |
| − | Параметры отчетов следующие:
| + | |
| − | | + | |
| − | ;Активная сборка: Этот параметр действует только на отчет «Общий статус сборки», показывающий текущее состояние плана тестирования для выбранной сборки.
| + | |
| − | | + | |
| − | Формат отчета: все отчеты (кроме диаграмм) могут быть сформированы:
| + | |
| − | | + | |
| − | ;normal: обычный отчет на веб-страничке.
| + | |
| − | ;MS Excel: экспорт отчета в «Microsoft Excel».
| + | |
| − | ;HTML Email: отчет отправляется HTML-письмом на email-пользователя.
| + | |
| − | | + | |
| − | Далее, мы рассмотрим десяток доступных отчетов более подробно.
| + | |
| − | | + | |
| − | == Общие метрики плана тестирования ==
| + | |
| − | Показывает наиболее актуальное состояние (в смысле последней выполненной сборки) плана тестирования в срезах по группам тестов, тестировщикам и ключевым словам.
| + | |
| − | | + | |
| − | Вообще понятие «последнего результата теста» используется в нескольких отчетах и определяется следующим образом:
| + | |
| − | | + | |
| − | # Какая сборка считается последней определяется порядком добавления сборок в план тестирования. Соответственно результаты последней сборки имеют преимущество над результатами тестов остальных сборок.
| + | |
| − | # Если тест выполняется несколько раз в одной сборке, то учитывается только последний прогон. Например если в сборке «3» с утра тестировщик Адам пометил тест как «пройден», а вечером тестировщик Ева пометила этот же тест как «провален», то тест будет показываться как проваленный.
| + | |
| − | # Тесты в состоянии «не запущен» для какой-либо сборки просто не принимаются во внимание. Например, если тест был помечен «пройден» для сборки «1», и не выполнялся для сборки «2», то он будет считаться успешно выполненным.
| + | |
| − | | + | |
| − | == Общий статус сборки ==
| + | |
| − | Показывает результаты выполнения для каждой сборки: «Всего тестов», сколько пройдено, провалено, блокировано и не запущено в абсолютной величине и процентах.
| + | |
| − | | + | |
| − | | + | |
| − | == Запрос метрик ==
| + | |
| − | Этот отчет содержит поисково-запросную форму после заполнения параметров в которой, можно получить отчет по заданным срезам.
| + | |
| − | | + | |
| − | === Страница параметров запроса ===
| + | |
| − | | + | |
| − | Можно задать следующие параметры, задающие условие-ограничение на выборку. Полное условие будет «логическое И» над всеми выбранными условиями, если некоторый параметр не задан/не выбран — то он не влияет на выборку, и выбираются тесты, вне зависимости от его значения.
| + | |
| − | | + | |
| − | ;Ключевое слово: можно выбрать только одно ключевое слово и или не выбрать ни одного.
| + | |
| − | | + | |
| − | ;Владелец: можно выбрать одного владельца-ответственного или не выбрать ни одного. В данный момент нет функциональности поиска по «неназначенным» тестам.
| + | |
| − | | + | |
| − | ;Группа тестов: можно выбрать любое количество групп (от нуля).
| + | |
| − | | + | |
| − | ;Сборки: можно выбрать любое количество сборок (от нуля).
| + | |
| − | | + | |
| − | ;Последний результат: выбирается состояние последнего результата по тесту (можно выбрать любое число состояний от нуля).
| + | |
| − | | + | |
| − | Нажмите кнопку «Выполнить запрос», для получения результата.
| + | |
| − | | + | |
| − | На странице-отчете показаны:
| + | |
| − | | + | |
| − | # Параметры запроса, если был выбран параметр «Показать параметры запроса».
| + | |
| − | # Сводная (агрегированная) информация по состояниям выбранных в отчет тестов, если был выбран параметр «Показать итоги по группе тестов».
| + | |
| − | # Детальная информация по выполнению каждого теста.
| + | |
| − | | + | |
| − | == Отчеты «Тесты Проваленные/Блокированные/Не запущенные» ==
| + | |
| − | Выводятся соответствующие списки тестов, для проваленных — с информацией о последнем запуске, и (опционально) с информацией о зарегистрированных багах.
| + | |
| − | | + | |
| − | | + | |
| − | == Отчет по тестам ==
| + | |
| − | Показывает результаты всех тестов для всех сборок. Отчет, как правило получается большим, поэтому рекомендуем выгружать его в Excel, для последующего анализа.
| + | |
| − | | + | |
| − | == Диаграммы ==
| + | |
| − | Для просмотра диаграмм (технология предоставлена [http://www.maani.us/ http://www.maani.us]) требуется поддержка Flash в броузере. Анимированной графикой показываются следующие диаграммы:
| + | |
| − | | + | |
| − | # Круговая диаграмма по всем тестам в разбивке по последнему состоянию выполнения.
| + | |
| − | # Столбиковая диаграмма результатов в разбивке по ключевым словам.
| + | |
| − | # Столбиковая диаграмма результатов в разбивке по владельцам.
| + | |
| − | # Столбиковая диаграмма результатов в разбивке по топовым группам тестов.
| + | |
| − | | + | |
| − | == Всего багов по каждому тесту ==
| + | |
| − | Если [[TestLink]] интегрирован с системой управления ошибками (bug tracking system), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:
| + | |
| − | | + | |
| − | «Открыто», «Исправленных», «Всего», «Тестов с багами», плюс детальная информация о каждом тесте с зарегистрированными багами, с ссылками на эти баги в системе управления ошибками.
| + | |
| − | | + | |
| − | == Отчет о выполнении требований ==
| + | |
| − | Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
| + | |
| − | Возможны следующие статусы требований:
| + | |
| − | ; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
| + | |
| − | : Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
| + | |
| − | : Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
| + | |
| − | : Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».
| + | |
